[ Top-post - replying midway through because this seemed like the most related email :-) ]
So, I've been noodling over this for quite a while, and I've refined my views -- the more I think about it, the more I think that "querying the DNS for localhost (or <something>.localhost) is an error " -- and that NXDOMAIN is the correct answer. This name doesn't, and shouldn't exist in the DNS, and by happy coincidence ( :-P ) there is no root delegation for this, and so there is no action needed there. For the same reason, this shouldn't need to be added to locally served zones, no special handling should be performed by DNS servers[0], and all of section 4.3 can go away (the normal DNSSEC behavior is the "right" behavior). Some resolvers are currently replying with an address for 'localhost.' and this behavior should be removed. So, for foo.localhost.example.com -- I feel that it is unreasonable to retroactively declare that the string is somehow reserved all throughout the DNS namespace, and things like http://localhost.net/ exist (perhaps they "shouldn't", but...), but I could be convinced that I'm wrong here. Stub resolver libraries must return 127.0.0.1 or ::1 for localhost., or, probably <something>.localhost (but I could easily be convinced that only 'localhost' is valid). Stub resolvers must also not apply any sort of search list processing to these names. So, that's my (new) views, and the thread seemed to have stalled. I believe that the security implications of having localhost queries leak into the DNS is bad, and there is significant evidence that this is happening. I get that there is no answer that will make everyone happy, but now that we've had some time to mull over this, where did we end up? W On Mon, Sep 11, 2017 at 10:21 PM, Wes Hardaker <[email protected]> wrote: > "John Levine" <[email protected]> writes: > >> It seems to me that if someone has enough programming skill to write a >> DNSSEC verifier for her cache or stub resolver, she has enough skill >> to treat localhost as a special case. > > I've been trying to figure out for a few days now how to insert my > opinion. It's kinda like the above but not. Specifically, we have > multiple naming systems already, and I'd argue that localhost actually > isn't in the DNS naming system. There is no authoritative source for > it. In fact, DNSSEC proves this. > > Instead, localhost is a operating system convention, a /etc/hosts name, > an NIS name, or one of the other things that is able to resolve that > name. But the DNS is not where that resolution comes from. > > Now, how do we ensure that a conflict never happens? That's a better > discussion and there are a few options ranging from policy to ensure > it's never assigned, to actually registering it, to... > -- > Wes Hardaker > USC/ISI > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
