El 12 ag 2017, a les 14:36, Paul Hoffman <paul.hoff...@vpnc.org> va escriure:
> It's security through interop. It's causing systems that want to hope that 
> "localhost" has a particular meaning that has security implications to have a 
> better chance that their hope is fulfilled.

Yes, I get that, and I'm not sure that it's wrong, but you still haven't 
addressed the point that I raised.   That's fine—I don't know that you really 
need to.   But for some reason people keep replying to my point with statements 
that don't contradict it, as if they think they have contradicted it, which 
puzzles me.

To recap, my point is that fixing localhost and then relying on it doesn't fail 
safe, and there is reason not to be confident that implementations will 
conform, because they will appear to work even if they don't.   If we think 
that localhost is the right identifier to use to refer to the local host, then 
we ought to be taking steps to make it not be the case that broken 
implementations will appear to work: we should be systematically trying to 
ensure that as many environments in which such applications might run as 
possible produce failure when a broken resolver forwards a query for localhost 
to the local recursive resolver.

The document does the right thing on that front, as far as that goes, but if 
this is to be effective I think that it shouldn't be an aside, but should be 
the main point of the document.   That is, the title of the document should be 
"DNS servers should return NXDOMAIN for localhost" and the abstract should say 
why, and then the bit about stub resolvers translating "localhost" to a 
reachable identifier for the localhost such as 127.1 or ::1 should be the thing 
that's mentioned as an aside.

And then we should be socializing this to operators and filing bugs against it 
in the bug tracking systems of our favorite distros.

And after doing that, it will still be the case that references to "localhost" 
don't fail safe, but it will be more likely that they won't happen, so maybe my 
point will have been adequately addressed.   But I still think that it would be 
better to recommend some identifier that can't be looked up in the DNS.

DNSOP mailing list

Reply via email to