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

Viktor Dukhovni <> Fri, 26 January 2018 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94E5E12D7E3 for <>; Fri, 26 Jan 2018 15:03:46 -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 AfOF6_cugray for <>; Fri, 26 Jan 2018 15:03:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE0A612AF83 for <>; Fri, 26 Jan 2018 15:03:44 -0800 (PST)
Received: by (Postfix, from userid 1034) id 9EDB77A330A; Fri, 26 Jan 2018 23:03:43 +0000 (UTC)
Date: Fri, 26 Jan 2018 23:03:43 +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: Fri, 26 Jan 2018 23:03:46 -0000

On Fri, Jan 26, 2018 at 02:24:26PM -0600, Ted Lemon wrote:

> > Disagreed, with respect to recursive resolvers, because the
> > requirement is neither necessary nor sufficient to achieve the
> > stated security goals, is not required for interoperability, and
> > is in conflict with existing uses of local data for localhost.
> The point of the requirement is that it breaks stacks that use DNS to look
> up localhost.

Multiple participants in this discussion have pointed out that such
queries are rare.  And, we must not forget that, absent local
overrides, the iterative resolvers are *already* returning NXDomain,
because the authoritative data from the root returns NXDomain.

So what you seem to be asking for is to *require* implementations
that currently serve local data with the expected loopback addresses
(and don't forward towards the root) to stop doing as configured and
return NXDomain.  Despite the explicitly configured "knobs" that turn
on this non-default behaviour.

I claim that this is too big a hammer for too small a nail.  There
is simply no need to do this.  A clear requirement to short-circuit
localhost name -> address resolution *before* it gets to the resolver
is quite sufficient.  I'm breathlessly enthusiastic for this part
of the draft. :-)

> If you think there's no risk to applications that rely on
> this, obviously it's not worth doing.   The reason I'm being such a stickler
> about this is that we have beaucoup experience over the past two decades
> that if there is an attack surface, somebody will come up with an attack.
> It's better to fail safe than fail unsafe.   If apps are breaking all over
> the place because they use DNS to look up localhost, then we all win in
> the long run.

Reports from the field seem to indicate that this is largely a
non-problem, and perhaps the maintainers of glibc and the like will
pay attention to this specification and ensure correct localhost
resolution without asking even the (e.g. glibc) DNS stub resolver,
let alone an upstream recursive resolver.

> That said, I absolutely do not want to deprive you of the ability to do
> your hack.   I just don't think that the current text does that.

The MUST says otherwise, and if we don't mean that, then we should
not say so.

> If the way the stack accomplishes the MUST is to have some code in
> nsswitch.conf that does the right thing, I think that follows the MUST.

It follows the MUST for the part I am breathlessly enthusiastic about,
the requirements on the hostname -> address resolution library.  No
problems with that at all.  My objection all along is with the MUST
at the recursive resolver.

> The reason I drilled down into your use case is that I don't think there's
> ever going to be a time when Christos disables this behavior.   So I don't
> think this text is going to actually create an inconvenience for you.

I'm fine with MUST NOT FORWARD, except when the DO bit is set in
the query, in which case I'm inclined to say that a validated
NXDomain from the root is better than a bogus NXDomain, and
is still (or more) secure.

> Is there a way we can change what the text says so that it's sufficiently
> emphatic to make me happy, and sufficiently open to make you [not] unhappy?

Yes.  Keep the MUST for the platform library.  Downgrade the MUST for
the iterative resolver to a SHOULD (absent local data), and either
exempt DNSSEC or explain why "bogus" local NXDomain is better than
a cacheable validated NXDomain from the roots.