Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

[ 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 <wjhns1@hardakers.net> wrote:
> "John Levine" <johnl@taugh.com> 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
> DNSOP@ietf.org
> 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