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

Paul Vixie <> Tue, 12 September 2017 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11501133073 for <>; Tue, 12 Sep 2017 08:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sLpp38QRzWae for <>; Tue, 12 Sep 2017 08:04:21 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 217EF132335 for <>; Tue, 12 Sep 2017 08:04:21 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 62AC561FA2; Tue, 12 Sep 2017 15:04:19 +0000 (UTC)
Message-ID: <>
Date: Tue, 12 Sep 2017 08:04:17 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.19 (Windows/20170908)
MIME-Version: 1.0
To: Tony Finch <>
CC: Wes Hardaker <>,, John Levine <>
References: <20170911013510.17202.qmail@ary.lan> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost
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: Tue, 12 Sep 2017 15:04:23 -0000

Tony Finch wrote:
> Wes Hardaker<>  wrote:
>> 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.
> I think this makes sense, but it isn't the whole story. From my brief look
> at a small amount of traffic, localhost queries are basically all handled
> inside the stub, so it is de facto as you describe. But it has long been
> the case that DNS servers are also supposed to handle localhost, e.g.
> RFC 1537 section 10
> RFC 1912 section 4.1
> RFC 2606 section 2
> RFC 6761 section 6.3
> However, implementations differ - BIND requires explicit configuration,
> Unbound handles localhost by default.

while i've generally included a localhost.$ORIGIN A RR in zones that 
appear in my stub resolver search lists, in order that "localhost" be 
found, i believe that the host name lookup library which calls and/or 
depends upon, among other things, a DNS stub resolver, ought to handle 
the "localhost" convention. and indeed, most of these lookup libraries 
have a concept similar to "/etc/hosts" today, where "localhost" lives.

no standards-track RFC currently requires that "localhost" return NXD, 
to make explicit that it's the host name lookup library "SHOULD", and 
that the DNS "SHOULD NOT", handle this name to address translation. we 
didn't used to standardized behaviour that was not seen "on the wire" 
simply because interoperability testing would be hard to imagine. and i 
don't imagine i'll have my "localhost.$ORIGIN" RR's out of any zones.

P Vixie