Future of BIND's built-in empty zone list

Mark Andrews marka at isc.org
Sun May 17 23:17:12 UTC 2015

In message <Prayer. at hermes-1.csi.cam.ac.uk>, Chris Tho
mpson writes:
> On May 16 2015, Mark Andrews wrote:
> [...]
> >When IANA and ARIN finally gets around to doing 64.100.IN-ADDR.ARPA
> >et al., which has been waiting over a year for the of DNSOP to write
> >up the last call of draft-ietf-dnsop-rfc6598-rfc6303 to be written
> >up, it should be done similar to this with a insecure delegation
> >to 64.100.IN-ADDR.ARPA, to allow the ISP's using this range and
> >others to server their own instances of 64.100.IN-ADDR.ARPA without
> >DNSSEC validation failures, and a DNAME to the AS112 traffic sink
> >for the leaked traffic.
> >
> >64.100.IN-ADDR.ARPA  SOA ...
> >64.100.IN-ADDR.ARPA  NS ...
> >64.100.IN-ADDR.ARPA  NS ...
> >
> >Note: there are no DNSKEY records.  This is deliberate.
> I notice, however, that this is not what RFC 7535 suggests (e.g. for
> the similar case of 2.0.192.IN-ADDR.ARPA). Instead a DNAME directly
> in the (signed) parent zone is described.

It said signed *could* be used.  It does not say signed *should* be used.

Which depends upon the use of the namespace.  For 64.100.IN-ADDR.ARPA
et al. it would be expected that ISP's would actually populate the
zones with PTR records.  Additionally draft-ietf-dnsop-rfc6598-rfc6303
actually calls for insecure delegations.

> Would this actually break a validating resolver with a locally defined
> (unsigned) empty zone 2.0.192.IN-ADDR.ARPA ? The parent zone can produce
> a proof that there is no signed delegation, but only by revealing the
> signed DNAME.

No, though it would be pointless to sign the zone.  DNAME can be
used in both signed and unsigned zones.

> -- 
> Chris Thompson
> Email: cet1 at cam.ac.uk
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

More information about the bind-users mailing list