Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Viktor Dukhovni <> Mon, 29 January 2018 16:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3A5012EC93 for <>; Mon, 29 Jan 2018 08:27:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fUioY2wyFChd for <>; Mon, 29 Jan 2018 08:27:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1607012D84C for <>; Mon, 29 Jan 2018 08:27:54 -0800 (PST)
Received: by (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 <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Jan 2018 16:27:56 -0000

On Jan 29, 2018, at 10:53 AM, wrote:

> To add more to this, Unbound by default returns, and so does
> Knot Resolver, because both decided to respect
> 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,  or as likely or more the user
will just stop using "localhost", and hard-code IPv4:].