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

From: Warren Kumari <[email-masked]>
Date: Mon, 9 Oct 2017 13:16:54 -0700

[ 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-masked]> wrote:
> "John Levine" <[email-masked]> 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-masked]
> 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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 9 Oct 2017 13:20:27 -0700

> happy, but now that we've had some time to mull over this, where did
My feeling of the list is that your view matches the rough consensus:
stub resolvers are responsible for resolving localhost to 127.0.0.1, and
queries for localhost should not hit the network, as described in the draft.

---

From: Petr Špaček <[email-masked]>
Date: Tue, 10 Oct 2017 11:12:32 +0200

> queries for localhost should not hit the network, as described in the draft.

I agree, consider it as one data point in your "rough consensus" estimation.

-- 
Petr Špaček  @  CZ.NIC

---

From: tjw ietf <[email-masked]>
Date: Mon, 23 Oct 2017 21:52:22 -0400

The Call For Adoption ended some time ago, and I spent some time reading
the comments.

There is consensus to adopt this, *but* there is also a enough of an
concern that some of the issues raised be addressed.   We'll want to make
sure all issues are addressed.

tim