On Wed, Aug 2, 2017 at 2:02 PM, Robert Edmonds <edmo...@mycre.ws> wrote: > Ted Lemon wrote: >> But we are arguing that "localhost" should be treated specially by every >> piece of software that looks at it, when its default meaning is "look up >> localhost in the DNS and connect to one of the addresses that you get in >> response." > > RFC 6761 §6.3 already says that "localhost" should be treated specially > by pretty much every piece of software that looks at it. But especially: > > 2. Application software MAY recognize localhost names as special, or > MAY pass them to name resolution APIs as they would for other > domain names. > > 3. Name resolution APIs and libraries SHOULD recognize localhost > names as special and SHOULD always return the IP loopback address > for address queries and negative responses for all other query > types. Name resolution APIs SHOULD NOT send queries for > localhost names to their configured caching DNS server(s). > > (In practice, "localhost" already does get treated specially, especially > by operating systems that place a "Name Service Switch" or similar > component in front of the DNS stub resolver.
Yup, you would think so -- unfortunately, this seems less true than we'd expect (or hope!) Around 0.3% of responses from Google Public DNS are for "localhost". As an honest DNSSEC-validating resolver, Google Public DNS returns NXDOMAIN for queries of localhost. (and all its subdomains). If you ask with DO set, it returns the root NSEC records proving there is no such domain (yes, this disagrees with the SHOULD in 6.3.4 of RFC6761). As with many things in the DNS, the real world is messier than we'd -- I would have hoped that most systems would be answering locally for queries for localhost, and never asking the DNS, but this turns out not to be as true as we would have liked. I think that this supports the case for the localhost document; this behavior should be firmed up. It also exposes the fact that an application naively resolving "localhost" and trusting the answer (for security purposes) is not currently safe. W > If you put > "http://localhost/"; into your browser bar, you shouldn't see a DNS query > for "localhost" leave your machine.) > > Doesn't "Application software MAY recognize localhost names as special" > already give more than enough permission for browser developers to treat > "localhost" (and any subdomain of "localhost") specially, for instance > by hardcoding the names to a loopback address, or filtering the result > from the system's name resolver to verify that only a loopback address > is used? Or only allowing the "Secure Context" flag to be set when the > localhost name resolves to a loopback address. > > draft-west-let-localhost-be-localhost-03 upgrades the requirements in > RFC 6761 §6.3 to make them much stricter, for all applications, > converting SHOULDs to MUSTs, etc. So we're not arguing about whether > localhost "should" be treated specially, but whether it MUST be treated > specially, by all applications. Can the W3C not impose stricter > requirements on browser developers even if 6761 doesn't impose mandatory > treatment for "localhost"? > > Maybe a smaller addition to RFC 6761 §6.3 would be sufficient for the > W3C? Something like: > > Application software specifications MAY require that application > software recognize localhost names as special. > > But that seems weird because it's arguably just a specific case of > requirement #2. > > -- > Robert Edmonds > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
