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.