> 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

Reply via email to