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

Warren Kumari <> Sat, 27 January 2018 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D4AA126B7E for <>; Sat, 27 Jan 2018 09:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PDStYy_gYRHA for <>; Sat, 27 Jan 2018 09:57:07 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B69B6126B6D for <>; Sat, 27 Jan 2018 09:57:06 -0800 (PST)
Received: by with SMTP id 16so3092933wry.12 for <>; Sat, 27 Jan 2018 09:57:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=2iZOr5xovqexNrmXLkDkoBtXGzZfgYncDvlio/eKriA=; b=zkY+/LeM8KLjO09p99mH/1a+nmoEVEPhXjeIFqAILPxlRlKZOlAgqgjAKkeJ3iy9tJ TaEZ9gBZOriLw0zOmQNL5ziIZluMC4V4utr00WQLxnTkDKlU9RDdLXZOBk6qmBuN8ry2 YhztM/tGvwIYR76vsV59dvdQBtfM2YQTORTi06gVZlSLNKcoYVs4WUEKKmtJTqhn+j6c A7Gcu1VYq6qGYTqYCle5qEqEXc8gKPpq1LnDzMdmD5l+6V7vnfGYdrBQM/3brJnxILEw qWCBQS2DoSlY8hX+RjZK2Frcst3xYb1XeKa2O/hWKjKxhJeoufdE5P6PoREyqEFPioJ5 W/Lg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=2iZOr5xovqexNrmXLkDkoBtXGzZfgYncDvlio/eKriA=; b=C6E904DreTX8A19O3D99iwbTZZkqr12GD9trmd5aZP8tgobv4QlKEVcnKjqayqrCcn KSQZSAKISwCLiqKvaGTm2Dbhsijqlss5v1TDUSqdCdlR7Sv8wfd7OfsdOrJQE/A+jUgR y3A8clyJKwQY7QLAwAQKTKQtdKOZ0dr4bXx2KAvRHbVs/qo/bBhqZNkANvom66xvd2Mq U7UiPFJFN//gZpgOmt+T/46kqWwxSoX7qU4recsSeu0oTeqDwtwRRxiKNFovPcXYdK+W GNL/pwrI/2Ajgvt5LURuLSpw1Rly26qoSVC0olAI4VYOGrUoEreMcgzeA2IrheDKr+ml oIzQ==
X-Gm-Message-State: AKwxytcs7d6gdmdVT4emuQaGZLN4mdVLLzaziHhRZGtNxJzag+/dSEUe tzr5Pj6b/I7emb+I7z+WRAqKdNWxz7ODOJNpDiIvU/n3aNM=
X-Google-Smtp-Source: AH8x2245M7cBEP1N135fRItrvO56DNLDvgZWBdYw/PTBtcnL16aODDjZ5xqgWC17mFFLE4w8njyH8fk/tiLyHgTEMGk=
X-Received: by with SMTP id z11mr15245992wrh.109.1517075824538; Sat, 27 Jan 2018 09:57:04 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 27 Jan 2018 09:56:23 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Warren Kumari <>
Date: Sat, 27 Jan 2018 12:56:23 -0500
Message-ID: <>
To: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Sat, 27 Jan 2018 17:57:09 -0000

On Fri, Jan 26, 2018 at 6:03 PM, Viktor Dukhovni <> wrote:
> 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.

<no hats>

I've somewhat lost track of which exactly "such queries" are
('localhost', '*.localhost', with or without DO bit, etc), and what we
are considering as "rare", but, as mentioned in
'Around 0.3% of responses from Google Public DNS are for "localhost".'

If I opened a packet of M&Ms[0] and <0.3% of them were green I'd call
green M&Ms rare, but if 0.3% of people who went swimming got eaten by
sharks I'd likely not call shark attacks rare :-p

>  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.

... do they?

Google Public DNS:
$ dig  +dnssec localhost @
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62555
. 64929 IN SOA 2018012700
1800 900 604800 86400
. 64929 IN RRSIG SOA 8 0 86400 20180209050000 20180127040000 41824 .

Verisign Public DNS:
$ dig +dnssec localhost @
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8025
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
localhost. 10687 IN A

$ dig +dnssec localhost @
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22677
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
localhost. 86170 IN A

dig +dnssec localhost @
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14156
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
localhost. 604800 IN A

My local BIND instance:
# dig +dnssec localhost @
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62183
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;localhost.                     IN      A

.                       10800   IN      SOA 2018012700 1800 900 604800 86400
.                       10800   IN      RRSIG   SOA 8 0 86400
20180209050000 20180127040000 41824 . i1JPur/fqut5jJ...

(above examples edited for readability. No queries were harmed in the
making of this).

I'm not really sure anymore who's point I'm making here, but I
disagree that localhost queries hitting the DNS is rare, and that
iterative resolvers already return NXD - some do, and some don't.

</no hats>

[0]: For non-Americans, M&Ms are kind of like Rowntree (now Nestlé)
Smarties[0], but much less tasty.
[1]: For American readers, Rowntree Smarties are like much much better
M&M's, and *nothing* like the US Smarties (which are mainly sugar,
citric acid and calcium stearate, but always taste like chalk to
We'll be in London soon, you should really give them a try...

> 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.
> --
>         Viktor.
> _______________________________________________
> DNSOP mailing list

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.