In message <2ef550a8-3e55-7fa0-9e00-fdf07093b...@eff.org>, Jacob Hoffman-Andrew s writes: > On 08/02/2017 12:09 PM, Matthew Pounsett wrote: > > In the case where 'localhost' is being passed to DNS resolution > > software, a validating stub (for example inside a web browser) > Ah, this may be where we are finding a disconnect. I believe web > browsers never operate validating stub resolvers, but generally ask the > operating system resolver library. Do you have a counter-example? > > I think it's also rare for operating system resolver libraries to > validate DNSSEC (rather than leaving it to an upstream recursive > resolver). However, even if we take it as a given that operating system > stub resolvers should implement DNSSEC validation, they clearly already > treat localhost specially, so there is no reason to believe that they > would start trying to validate it with DNSSEC once this document is > finalized.
The deployment goal of DNSSEC was to have *every* machine/application validating DNSSEC responses or to have a crytographically secure path to one that did for which you knew and accepted its security policy. DNSSEC was designed with this in mind. DNSSEC also requires recursive servers to validate responses or else you can't handle certain threats DNSSEC is designed to handle. Turning on DNSSEC in resolvers also provides some protection from some threats to non-validating clients. Getting validation turned on in recursive servers is the first step in this multi-year plan. We are at about the 60% level for recursive servers and a few percent (maybe) for the machine/application level. Most OS's don't treat localhost specially. It is just a entry in /etc/hosts and/or a zone in the local recursive server and/or localhost.<zone> in a zone on the search list. The last of these is how localhost is actually resolved on my machine (MacOS 10.12.6) as the resolver doesn't treat "localhost" as special. It's processed the same way as any other single label name. When you look at foo.localhost the resolution mechanisms /etc/hosts and/or a zone in the local recursive server. If you are mad you apply the search list. Mark -- 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
