Re: Future of BIND's built-in empty zone list
On May 14 2015, Rob Foehl wrote: [...] Adding empty.as112.arpa to the list seems like a good idea, but removing the existing empty zones does not -- they also prevent leaking internal queries, which is both more noise for the root/IANA/AS112 infrastructure to sink and a potential privacy concern. Well, perhaps each case needs to be judged on its merits. There's also the minor benefit of fast responses from local resolvers, which still matters for determinism in the initial query. From where I sit, the nearest blackhole.as112.arpa is 90+ms and an ocean away (v4 or v6), and the existing AS112 nodes aren't much better. As long as empty.as112.arpa is served locally, there would be no need to access the as112 nameservers. It's the nameservers authoritative for the DNAMEs pointing to it that are relevant, and of course one also hopes these DNAMEs will have big TTLs so that they will remain cached. -- Chris Thompson Email: c...@cam.ac.uk ___ 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
Re: Future of BIND's built-in empty zone list
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
Re: Future of BIND's built-in empty zone list
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. 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. -- Chris Thompson Email: c...@cam.ac.uk ___ 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
