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.1.3.5.1505171630010.14877 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 ...
> >64.100.IN-ADDR.ARPA DNAME EMPTY.AS112.ARPA
> >
> >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