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

Viktor Dukhovni <> Fri, 26 January 2018 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C1E012DA16 for <>; Fri, 26 Jan 2018 11:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RD0WA7kb4Oad for <>; Fri, 26 Jan 2018 11:54:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6E651275AB for <>; Fri, 26 Jan 2018 11:54:54 -0800 (PST)
Received: by (Postfix, from userid 1034) id 152097A330A; Fri, 26 Jan 2018 19:54:54 +0000 (UTC)
Date: Fri, 26 Jan 2018 19:54:54 +0000
From: Viktor Dukhovni <>
To: dnsop <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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: Fri, 26 Jan 2018 19:54:56 -0000

On Fri, Jan 26, 2018 at 08:22:18AM -0800, 神明達哉 wrote:

> Hmm, that's different from my interpretation of the draft.  According
> to my usual interpretation of IETF docs, I would interpret these from
> Section 3:
>    3.  Name resolution APIs and libraries MUST recognize localhost names
>        as special, and MUST always return an appropriate IP loopback
>        address for IPv4 and IPv6 address queries and negative responses
>        for all other query types.  Name resolution APIs MUST NOT send
>        queries for localhost names to their configured recursive DNS
>        server(s).
>        As for application software, name resolution APIs and libraries
>        MUST NOT use a searchlist to resolve a localhost name.
>    4.  (Caching) recursive DNS servers MUST respond to queries for
>        localhost names with NXDOMAIN.
>    5.  Authoritative DNS servers MUST respond to queries for localhost
>        names with NXDOMAIN.
> as these are requirements without a user-configurable knob.  If the
> actual intent was just to specify the default behavior with a
> configurable knob, I'd expect SHOULD-variants are used in cases like
> these.

Exactly.  The MUST language is asking implementations to remove
support for the existing knobs, which should stay.

I just talked to Christos Zoulas of NetBSD, as he's also the current
(or at least recent) upstream maintainer of libresolv.  He not only
supports my view that the MUST is extraneous, but indeed also has
localhost (forward) and loopback (reverse) zones configured on his
own machines.  This practice is reasonably widespread.

I should also note that there is some confusion in recent messages
between what is a stub (DNS) resolver and higher-level name resolution
facilities such as getaddrinfo(3).  Yes, getaddrinfo(3) and friends
on modern Unix-like systems use nsswitch and typically consult the
/etc/hosts file before using DNS, but that's not what this draft
is about.  It specifically describes "stub-resolver" behaviour, not
getaddrinfo() behaviour.  The stub resolver is libresolv, and does
not presently special-case "localhost".

If the intent is to require special handling of "localhost" in the
platform's name to address lookup library (getaddrinfo(),
gethostbyname(), ...), then the draft should say so, instead of
talking about stub resolvers, which are only the DNS component of
the platform's hostname resolution stack.