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

Tony Finch <> Wed, 06 September 2017 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 409F8132D57 for <>; Wed, 6 Sep 2017 08:57:52 -0700 (PDT)
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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gqcoevH_IVoz for <>; Wed, 6 Sep 2017 08:57:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DDD5132D52 for <>; Wed, 6 Sep 2017 08:57:50 -0700 (PDT)
X-Cam-AntiVirus: no malware found
Received: from ([]:58413) by ( []:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dpcfi-000qvL-2v (Exim 4.89) (return-path <>); Wed, 06 Sep 2017 16:57:47 +0100
Date: Wed, 06 Sep 2017 16:55:21 +0100
From: Tony Finch <>
To: Ted Lemon <>
cc: Tim Wicinski <>, dnsop <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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: Wed, 06 Sep 2017 15:57:52 -0000

Ted Lemon <> wrote:
> It's whether the working group is willing, since returning NXDOMAIN is
> an actual change in behavior from the original specification in RFC
> 6761, and will likely result in some breakage, since it can safely be
> assumed that some stacks are currently following the RFC6761 advice.

I was looking at query traffic recently to prepare for deleting localhost
entries from our main zone

It was reassuring to see there were very few leaked localhost queries,
whether bare or with the search path appended. So it seems that stub
resolvers are successfully sinking localhost queries as they should.

I have configured the resolvers I run pedantically to include the empty
zones that aren't built-in to BIND, including localhost. So my setup is a
lot more RFC 6761 than the default. (But I'll happily delete most of it
when the cheese shop reaches production.)

Based on the low volume of localhost query traffic and the lack of
RFC 6761 conformance in at least one common recursive server, I think the
change from positive to negative responses will only affect a tiny
number of things that are already buggy.

A related thing that needs to be covered is the reverse DNS for
and ::1 - pedants like me have configured PTR records for those addresses,
which become useless when the forward domain goes away (if they aren't
useless already). BIND returns a built-in NXDOMAIN for them by default
which is justified by RFC 5735 though that spec doesn't mention the DNS.

Perhaps let-localhost-be-localhost should explicitly require reverse DNS
behaviour to match the forward DNS, i.e. positive answers generated in
stubs and NXDOMAIN from recursive servers.

f.anthony.n.finch  <>  -  I xn--zr8h punycode
Irish Sea: West 4 or 5, decreasing 3 for a time, backing southwest 5 or 6
later. Slight or moderate. Showers later. Good.