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
