In message <86ac48c0-4dff-4286-a9b1-2a6be3d14...@hopcount.ca>, Joe Abley writes:
>
> On 13 Aug 2014, at 20:16, Mark Andrews <ma...@isc.org> wrote:
>
> > Can we please move on this.
> >
> > The reverse address are not yet insecurely delegated as
> > would be required for RFC 6598 compliance. This is starting
correction RFC 6303
> > to cause operational problems for ISP's that validate DNS
> > responses as they can't deploy local IN-ADDR.ARPA zones
> > until that insecure delegation is done.
> >
> > Also should I add a reminder to the IANA Considerations that
> > the insecure delegation needs to be performed?
> >
> > e.g.
> >
> > "IANA is reminded that a insecure delegation for these zones
> > is required for compliance with RFC 6598 to break the DNSSEC
> > chain of trust."
>
> I'm confused. We're talking about 100.64.0.0/10, I think. The only
> delegation under IANA's control is 100.in-addr.arpa to nameservers
> operated by ARIN, which is (and should be, I think) a secure delegation.
> What are you asking IANA to do? Make a request of ARIN? Something else?
The assignements go:
0.0.0.0/0 IANA (IN-ADDR.ARPA)
100.0.0.0/8 ARIN (100.IN-ADDR.ARPA)
100.64.0.0/10 IANA (64.100.IN-ADDR.ARPA through
127.100.IN-ADDR.ARPA)
The 100.64/10 address range is assigned to IANA. IANA has not yet
setup IN-ADDR.ARPA zones and servers for this range. IANA needs
to tell ARIN to delegate them to somewhere insecurely. A logical
place to delegate them to is the same servers that serve 100.IN-ADDR.ARPA
if ARIN is will to set up the zones on them otherwise IANA will
need to find a different set of servers to delegate to. In either
case this will change the answer returned from a secure NXDOMAIN
from 100.IN-ADDR.ARPA to a insecure NXDOMAIN from 64.100.IN-ADDR.ARPA
for the reverse of 100.64.x.y. Repeat for the other 63 zones in
the range.
This will break the DNSSEC chain of trust the same way as the
insecure delegation of 10.IN-ADDR.ARPA and the rest of the RFC 1918
reverse zones to the AS112 servers does.
RFC 6598 effectively says answer these locally with "don't forward
to the global internet". This cannot currently be done if you are
validating answers as the only answer that will validate is a
NXDOMAIN response from 100.IN-ADDR.ARPA. Once the insecure delegation
is in place these queries can be answered locally because the
validator will be told securely that there isn't a DS for
64.100.IN-ADDR.ARPA through 127.100.IN-ADDR.ARPA.
> More generally, if you are asking the chairs to facilitate the process of
> adoption of this draft by the dnsop wg, it might be as well to say so
> clearly (it's not obvious from your message above).
The draft is adopted. Went to last call then stalled. drc started
worrying about if there were other registries to be updated.
> Joe
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
