Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 26 January 2018 23:03 UTC
Return-Path: <ietf-dane@dukhovni.org>
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 94E5E12D7E3 for <dnsop@ietfa.amsl.com>; Fri, 26 Jan 2018 15:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AfOF6_cugray for <dnsop@ietfa.amsl.com>; Fri, 26 Jan 2018 15:03:44 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0A612AF83 for <dnsop@ietf.org>; Fri, 26 Jan 2018 15:03:44 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9EDB77A330A; Fri, 26 Jan 2018 23:03:43 +0000 (UTC)
Date: Fri, 26 Jan 2018 23:03:43 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20180126230343.GL3322@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <CANV=THh6bOxd_UW=TuLonWzz0KyGapkGWpMiNuu54W=45gFAvg@mail.gmail.com> <20180124205620.GZ3322@mournblade.imrryr.org> <alpine.DEB.2.11.1801251558440.5022@grey.csi.cam.ac.uk> <CAJE_bqf+GqYGFRAsXbBPymQLXoJRs_AxvVHhtcMJF1LEvTL7sQ@mail.gmail.com> <77B805CC-E8FE-4B09-A261-C5CB13707EE4@dotat.at> <CAJE_bqdCZ_vj2nncvEVpYunVmE=xxAiXqrzhu8BGxnSsLjy+3Q@mail.gmail.com> <37A9F504-A8BE-4F47-AAE9-AF2458206F03@fugue.com> <20180126201613.GK3322@mournblade.imrryr.org> <B17E9259-BC28-4861-8102-B716685C75B3@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <B17E9259-BC28-4861-8102-B716685C75B3@fugue.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8yA7cIMdjcof8Z6HhL4F2rJVEJ8>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
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: Fri, 26 Jan 2018 23:03:46 -0000
On Fri, Jan 26, 2018 at 02:24:26PM -0600, Ted Lemon wrote: > > Disagreed, with respect to recursive resolvers, because the > > requirement is neither necessary nor sufficient to achieve the > > stated security goals, is not required for interoperability, and > > is in conflict with existing uses of local data for localhost. > > The point of the requirement is that it breaks stacks that use DNS to look > up localhost. Multiple participants in this discussion have pointed out that such queries are rare. And, we must not forget that, absent local overrides, the iterative resolvers are *already* returning NXDomain, because the authoritative data from the root returns NXDomain. So what you seem to be asking for is to *require* implementations that currently serve local data with the expected loopback addresses (and don't forward towards the root) to stop doing as configured and return NXDomain. Despite the explicitly configured "knobs" that turn on this non-default behaviour. I claim that this is too big a hammer for too small a nail. There is simply no need to do this. A clear requirement to short-circuit localhost name -> address resolution *before* it gets to the resolver is quite sufficient. I'm breathlessly enthusiastic for this part of the draft. :-) > If you think there's no risk to applications that rely on > this, obviously it's not worth doing. The reason I'm being such a stickler > about this is that we have beaucoup experience over the past two decades > that if there is an attack surface, somebody will come up with an attack. > It's better to fail safe than fail unsafe. If apps are breaking all over > the place because they use DNS to look up localhost, then we all win in > the long run. Reports from the field seem to indicate that this is largely a non-problem, and perhaps the maintainers of glibc and the like will pay attention to this specification and ensure correct localhost resolution without asking even the (e.g. glibc) DNS stub resolver, let alone an upstream recursive resolver. > That said, I absolutely do not want to deprive you of the ability to do > your hack. I just don't think that the current text does that. The MUST says otherwise, and if we don't mean that, then we should not say so. > If the way the stack accomplishes the MUST is to have some code in > nsswitch.conf that does the right thing, I think that follows the MUST. It follows the MUST for the part I am breathlessly enthusiastic about, the requirements on the hostname -> address resolution library. No problems with that at all. My objection all along is with the MUST at the recursive resolver. > The reason I drilled down into your use case is that I don't think there's > ever going to be a time when Christos disables this behavior. So I don't > think this text is going to actually create an inconvenience for you. I'm fine with MUST NOT FORWARD, except when the DO bit is set in the query, in which case I'm inclined to say that a validated NXDomain from the root is better than a bogus NXDomain, and is still (or more) secure. > Is there a way we can change what the text says so that it's sufficiently > emphatic to make me happy, and sufficiently open to make you [not] unhappy? Yes. Keep the MUST for the platform library. Downgrade the MUST for the iterative resolver to a SHOULD (absent local data), and either exempt DNSSEC or explain why "bogus" local NXDomain is better than a cacheable validated NXDomain from the roots. -- Viktor.
- [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-b… Jeff Hodges
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Viktor Dukhovni
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Paul Vixie
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Mark Andrews
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Paul Vixie
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Joe Abley
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Paul Vixie
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Tony Finch
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Viktor Dukhovni
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… 神明達哉
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Tony Finch
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Viktor Dukhovni
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… A. Schulze
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Tony Finch
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Tony Finch
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… 神明達哉
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Ted Lemon
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Paul Vixie
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Viktor Dukhovni
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Ted Lemon
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Viktor Dukhovni
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Ted Lemon
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Warren Kumari
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Mark Andrews
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Viktor Dukhovni
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Petr Špaček
- Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localho… Viktor Dukhovni