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

Warren Kumari <warren@kumari.net> Mon, 09 October 2017 20:17 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA2E1321DF for <dnsop@ietfa.amsl.com>; Mon, 9 Oct 2017 13:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMuZCSYDEoxH for <dnsop@ietfa.amsl.com>; Mon, 9 Oct 2017 13:17:37 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED251342E5 for <dnsop@ietf.org>; Mon, 9 Oct 2017 13:17:36 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id b189so25465074wmd.4 for <dnsop@ietf.org>; Mon, 09 Oct 2017 13:17:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AC6APZWEy+NqYKQd04qOiSG3g8i/i5cTMW+pLuxGc24=; b=TyUzQHZMlxV5Wwxu7DmhKLceel8PeNgGnf6gI/XY4Pkh+vafMRPYKUcJGYwFNYQMn4 mFoW9QEg8cvB3+msrKpI1BDIhhsXNn5h4P6neUWicRxF1YVxZqFH/NHe3eK6RlBD0+vw jf0rMItx8QShxVQ4nfc2mrieCCvYVCo1kxLpmyzlWDSxy//T1VOyTgy+z2vjrEidRSd7 xcuQtzCZhGCiiu/LOY8KLEW6Tq/EoryS0bnV14zvVpDX1OBvNL5gxfa+ZhyveH7FLBPv e4I14VhTEkw2GfKEktdSWc5GIjbetIz+d0r+p/OQhi30dg8054cGPaKp6JwlfjLUAG8s WB2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AC6APZWEy+NqYKQd04qOiSG3g8i/i5cTMW+pLuxGc24=; b=tleAq74p663dKWiHKWbMgPhWkyowUZKhQ04PLZAY48rTmlVXnkBCP/9lHATWVvrcwv CJI3vdHSLt0NOn6LAzbYA0wCMUbl9BhSePFls3sLGhm9DEgpXj62/DOivVAApY9x5/W3 1yY2N9LCytiuMA7QPmbc5YAPlszZmuHOuDIlr7BX4Ez6xKUHqoh5HJLz4HE68KfQGIg1 y1h5PX3SgUodFF3xc4kfHPl2EqeSOtQp5K+jYPSzheSjBLf/Oqr6Bp34p0R7jrOEVMhj Cj6t3rHNffpmbRM0imtop/uW3eoC5QEdiaMYcguKu51lqc++GqDhlYF6omK+W+vAh41L GMBA==
X-Gm-Message-State: AMCzsaXbyqQWWAOldkfFEsi02gE9Zoxyt7K8wtadXM00RVQhA14l+6yX Lt9cI8wargGq0VAr1HAusF1UuDfim7BOGjCN5yUiQSMei8o=
X-Google-Smtp-Source: AOwi7QD97/enPgeIOdj9Ph62bbRrPgDQogKoIC/2MwGsE2/9k+e7OJS8Hl3f9eJ9GRvinP4G/jELZVfslwMB5gMHFDI=
X-Received: by 10.223.133.179 with SMTP id 48mr2460102wrt.184.1507580254924; Mon, 09 Oct 2017 13:17:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.187.12 with HTTP; Mon, 9 Oct 2017 13:16:54 -0700 (PDT)
In-Reply-To: <yblr2vcxzjn.fsf@w7.hardakers.net>
References: <20170911013510.17202.qmail@ary.lan> <yblr2vcxzjn.fsf@w7.hardakers.net>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 9 Oct 2017 13:16:54 -0700
Message-ID: <CAHw9_iKYefDLxbDBv7FAzqJyjgVpJHhkxqPbms8oHe2knOX6tA@mail.gmail.com>
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: John Levine <johnl@taugh.com>, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QV8pIEe_ssSC1IlMguqrR6Hegcc>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Oct 2017 20:17:41 -0000

[ 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