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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
