I've uploaded an -05 draft <https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-05> (diff to -04 <https://tools.ietf.org/rfcdiff?url2=draft-west-let-localhost-be-localhost-05.txt>) that addresses some of the feedback in this thread, Ted Lemon's in particular. It attempts to spell out the rationale for the NXDOMAIN change more clearly, boiling it down to Ted's suggestion that we ought to be recommending that stub resolvers fail closed when they forward requests for localhost names on to recursive resolvers.
The draft also follows up on recommendations that Mark and others have made regarding DNSSEC by requesting an insecure delegation of `localhost.` in the root-zone (I found Warren's notes on the topic in https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4 quite useful, btw). Tony: I'd like to understand more clearly what justification you'd like the draft to present. Do the changes in -05 give the reader enough context, or does it need more work in that regard? Does shifting the application-level requirements into the main body of the draft, out of the implementation considerations section, make the requirements around security decisions for localhost names clear enough? -mike On Mon, Aug 14, 2017 at 2:36 AM, Tony Finch <d...@dotat.at> wrote: > > > On 13 Aug 2017, at 23:51, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > > > > On 13 Aug 2017, at 10:19, Tony Finch wrote: > >> > >> > >> RFC 6761 requires recursive servers to return positive 127.0.0.1 and > ::1 responses, not NXDOMAIN. I can't see an explanation in the draft for > the change to NXDOMAIN. > > > > And there should be. Proposed addition to the last paragraph of Section > 1: > > > > A consequence of the requirement that the resolver APIs MUST resolve > "localhost." and any names falling within ".localhost." to loopback > addresses is that caching DNS servers and authoritative DNS servers MUST > NOT resolve those names at all, and always return NXDOMAIN. > > Well, that isn't really the kind of text I wanted. > > You have written a paragraph that is obvious from the internal logic of > the draft, but it doesn't say why "a consequence" has changed from RFC 6761. > > What we really need is an informed analysis of the consequences of > different ways of sinking localhost queries on recursive servers. The de > facto way is NXDOMAIN (same as what happens when there is no special case > in the resolver, except without the recursion to the root servers). The RFC > 6761 way is to return locally authoritative positive responses. > > Either way, BIND (for instance) needs special configuration to be RFC 6761 > compliant or NXDOMAIN compliant, so some kind of code change is needed to > make the Right Thing the default, but which Thing's Rightness needs > justification. > > There are also missing security considerations. The whole draft is > motivated by web security edge cases, so I would like to see a summary and > citation of the same site scripting problem, and whatever other issues > there might be. > > Does the change from positive responses to NXDOMAIN have some connection > to the web security motivation? It isn't clear to me and it ought to be. > > There is also a weird compatibility awkwardness. RFC 6761 requires > *.localhost to resolve to localhost, in stub and recursive resolvers. You > can't implement this in traditional Unix libc resolvers. It's possible to > implement this in a recursive server like BIND, but I realised this week > that I had not implemented the wildcard in my config, so I bet proper RFC > 6761 conformance is rare. > > The upshot of the draft's current text is that full system behaviour will > vary depending on libc version, recursor version, recursor config, etc. > > I think it is still a good idea to tighten up the implementation > requirements to MUST. That part of the draft is good, but trivial. > > The interesting part is not stated in the current text: it is that > application software that makes security assumptions about localhost MUST > internally resolve localhost without relying on the shifting historical and > operational variability of stub resolvers and recursive servers. > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
