Re: [DNSOP] Status of "let localhost be localhost"?

[Tony Finch <[e-mail]>]

> On 13 Aug 2017, at 23:51, Paul Hoffman <[e-mail]> 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  <[e-mail]>  http://dotat.at