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

Viktor Dukhovni <> Thu, 25 January 2018 20:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B6CE12EAA4 for <>; Thu, 25 Jan 2018 12:32:28 -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 KowvhcxZCspM for <>; Thu, 25 Jan 2018 12:32:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90F5412EA5A for <>; Thu, 25 Jan 2018 12:32:26 -0800 (PST)
Received: by (Postfix, from userid 1034) id D87FB7A330A; Thu, 25 Jan 2018 20:32:25 +0000 (UTC)
Date: Thu, 25 Jan 2018 20:32:25 +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: Thu, 25 Jan 2018 20:32:28 -0000

On Thu, Jan 25, 2018 at 04:03:08PM +0000, Tony Finch wrote:

> > I am not nearly so enthusiastic about an important component of
> > the draft.  Specifically, I'd like to suggest that while the
> > requirement for recursive resolvers to return NXDOMAIN for "localhost."
> > is well-intentioned, it will prove counter-productive to the
> > motivating goals of this draft.
> This is a legitimate worry, but it's based on incorrect information.
> Stub resolvers already sink localhost queries themselves - they don't rely
> on their recursive servers.

I don't see any mention of "localhost" in libresolv sources.  What
is true is that they generally append the default domain suffix to
"localhost", and some support a "no_tld_query" option that AFAIK is
off by default.

> Recursive servers frequently do not implement the localhost requirement in
> RFC 6761 - for example, BIND does not.

That's fine, but I've configured plenty of recursive resolvers that
are authoritative for the "localhost" zone.  I don't why the draft
should forbid resolvers from serving such zones.

> So in practice this draft is only a small tweak to current practice.

To be clear, I support requiring a short-circuit in stub resolvers.

My objection is to requiring NXDOMAIN from recursive resolvers.
They should not forward "localhost." lookups, but they should be
able to serve local answers for this zone.

The motivation of the draft is to make "localhost" behave more
predictably.  Having resolvers provide the boilerplate replies as
a last resort is as much or more compatible with that goal than
mandating that they return NXDOMAIN.

Note also that there may be a "localhost" zone with other data for
sub-domains of "localhost".  I've often used for private MX records
on an MTA: IN MX 0 IN MX 0 IN A IN A

    with a transport entry:

With localhost having local sub-domains, NXDomain is NOT an option,
though one might return NoData, it makes more sense to complete the
zone with:

	@ IN NS localhost.
	@ IN A
	@ IN AAAA ::1

Note, for example, that the SMTP client in the Postfix MTA performs
DNS lookups with the RES_DEFNAMES and RES_DNSRCH options unset (in
order to avoid unwanted search path application to MX hostnames
obtained from DNS).  Furthermore, for similar reasons, nexthop
resolution is by default exclusively via DNS, not getaddrinfo(3).
Consider that administrators may configure transport entries with
"localhost" as the nexthop domain, and you now get queries for
"localhost" sent to the local iterative resolver.  (Most Postfix
administrators use "smtp:[]" instead).

Based on this draft, Postfix should probably special-case "localhost"
internally, but that's not currently the case, and if some users
choose to implement a localhost zone in their iterative resolver
there's nothing wrong with that.