In message <prayer.1.3.5.1505171630010.14...@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: c...@cam.ac.uk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
