In message <20161121180641.79893.qm...@ary.lan>, "John Levine" writes:
> >> The point is that the current policy for the root precludes an
> >> unsecure delegation.
> >
> >Huh?  If by "insecure delegation" you mean "no DS record", then are are p
> lenty such delegations right now:
> 
> No, I think the point is that you want the equivalent of an NSEC3
> opt-out, but the root is currently signed with NSEC.
> 
> Having said that, I don't see why this name is any different from
> other special names.  If you want your cache to return DNS answers for
> any of them, you have to add special cases.  My cache (unbound)
> already does for localhost names.

Well they basically aren't.  The problem is that the IETF has not
been listening when its been told that DNSSEC has to be accounted
for and plunged ahead creating names which will result in "invalid"
being returned from the validator.

If you run a validating stub resolver talking to a recursive server
which return NXDOMAIN for the special name .onion and ask for
<hash>.onion the validation of that response will be "invalid".  If
the only intent is to stop the query leaking then that is "fine".
If you want the application to see the NXDOMAIN for <hash>.onion
then there should have been a insecure delegation for .onion as
well.

What "saves" .onion is that the lookup should be being made using
TOR and any failure is good enough at the DNS level.  Doing .onion
cleanly also requires a insecure delegation.

A similar argument can be made for .local and MDNS.

.localhost and .homenet don't have the escape to a different protocol
and any error from the DNS will do for those not worried about a
clean solution.  These namespace are intended to be looked up in
the DNS with local content.

There are a whole heap of RFCs that get/got DNSSEC issue wrong.
Others have been overtaken by the deployment of DNSSEC.  I've cleaned
up some of them by getting ammending RFCs issued.

        RFC 1918 addressed in RFC 6303
        RFC 2606 (.localhost being discussed in this thread)
        RFC 6147
        RFC 6598 addressed in RFC 7793
        RFC 7686
        RFC 7788 (.home)

.localhost is one where the deployment of DNSSEC broke existing
practice.  Most people do not notice this as they are not validating
at the client level.  Search lists and localhost.<search-entry>
records also helped to hide the issue.

Mark

> R's,
> John
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
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

Reply via email to