Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 29 January 2018 16:27 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 A3A5012EC93 for <dnsop@ietfa.amsl.com>; Mon, 29 Jan 2018 08:27:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 fUioY2wyFChd for <dnsop@ietfa.amsl.com>; Mon, 29 Jan 2018 08:27:54 -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 1607012D84C for <dnsop@ietf.org>; Mon, 29 Jan 2018 08:27:54 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 52AAD7A330A; Mon, 29 Jan 2018 16:27:53 +0000 (UTC)
Date: Mon, 29 Jan 2018 16:27:53 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20180129162753.GO3322@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <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> <20180126230343.GL3322@mournblade.imrryr.org> <CAHw9_i+dM+MeMVt+et0t-xU-SKxK0nB_XSuPqP1DngmSTuYTqQ@mail.gmail.com> <eb96c2f5-8b35-d285-43ea-2c4151588580@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <eb96c2f5-8b35-d285-43ea-2c4151588580@nic.cz>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ixwtgLBetj2rCvVh9abHwzEkUTk>
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: Mon, 29 Jan 2018 16:27:56 -0000
On Jan 29, 2018, at 10:53 AM, dnsop-request@ietf.org wrote: > To add more to this, Unbound by default returns 127.0.0.1, and so does > Knot Resolver, because both decided to respect > https://tools.ietf.org/html/rfc6761#section-6.3 > > This is a security hole, and again, purpose of NXDOMAIN is to make it > fail safe instead of keeping insecure stub implementations doing what > they did up until now. By short-circuiting the lookup as early as possible these resovers avoid sending the query upstream. Thus eliminating part of the security exposure further upstream away from the user's device. Serving local data for "localhost" is NOT the security hole, it is an incomplete fix, and a secure one when the resolver is responding to loopback clients. The hole is in the platform's libraries, and that is the proper primary focus of the draft, not recursive resolvers, nor even stub resolvers (the DNS portion of the platform name resolution libraries). If you want to remove the band-aid, that is properly a SHOULD, not a MUST. It is not required for interoperability, nor does it address the security issue, [e.g. the next resolver in the forwarding chain may still return 127.0.0.1, or as likely or more the user will just stop using "localhost", and hard-code IPv4: 127.0.0.1]. -- 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