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

Viktor Dukhovni <> Thu, 25 January 2018 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 052AF126FDC for <>; Thu, 25 Jan 2018 09:54:20 -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 FkpzKLbDrI7J for <>; Thu, 25 Jan 2018 09:54:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E373127010 for <>; Thu, 25 Jan 2018 09:54:17 -0800 (PST)
Received: by (Postfix, from userid 1034) id C461D7A330A; Thu, 25 Jan 2018 17:54:16 +0000 (UTC)
Date: Thu, 25 Jan 2018 17:54:16 +0000
From: Viktor Dukhovni <>
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: Thu, 25 Jan 2018 17:54:20 -0000

On Fri, Jan 26, 2018 at 12:19:00AM +1100, Mark Andrews wrote:

> > RFC 6303 says that we should have empty domain for it, but this part is
> > confusing:
> >   The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not an
> >   attempt to discourage any practice to provide a PTR RR for
> > locally.
> > 
> > PTR is DNS-specific term, so I'm not sure if it is clumsy expression for
> > "stub should hardcode the answer" or something else.
> No. It says if there isn’t a zone configured then return NXDOMAIN rather than
> recurse to the servers. That is different to always /just return
> All the zones listed in RFC 6303 can be overridden locally. The point of RFC 6303
> is to stop traffic going to the public server if the zones are not otherwise
> configured locally.

And this precisely where I take issue with the current draft.  It
mandates NXDOMAIN without admitting the possibility of a local
override.  I'm fine with recursive resolvers not *forwarding*
"localhost.", but forbidding local answers is I think taking it
too far and counter-productive.  If a resolver has a working
"localhost." zone that serves the expected loopback answers, it
should be free to reply with those.

Indeed I would go further, and recommend that resolvers add such
local overrides if not present, and answer accordingly.  Sure, it
would also be great if stub resolvers never asked, but just in case
they do, there's no need to punish them, that's rarely effective.