Re: [DNSOP] Status of "let localhost be localhost"?

Mike West <mkwst@google.com> Mon, 14 August 2017 11:30 UTC

Return-Path: <mkwst@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE03D1321A7 for <dnsop@ietfa.amsl.com>; Mon, 14 Aug 2017 04:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC3q7vD6p3hJ for <dnsop@ietfa.amsl.com>; Mon, 14 Aug 2017 04:30:23 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5247713219E for <dnsop@ietf.org>; Mon, 14 Aug 2017 04:30:23 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id s6so49916962qtc.1 for <dnsop@ietf.org>; Mon, 14 Aug 2017 04:30:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q/pu3pQE7J0qCOHmyFk5H4lCsjP9Yu4ShUEtYcOV3Ic=; b=TNg3EdvSKxRsnL7pyxQt/EKKFgZe+OlKrP6OV6xLIO/pyM2AaQ8RdTTR2WsmClcZm7 74V+CNVEDzYEdQd/jrfZtiFM6FvEyBkn6quiTISE8I2FHFMjpU7At7EtS5gaWx/mdEeW Zu4k2+5Qgh93mmbyV7u7WaBsJChOQ+jlJLC0zypgMlg8hpis8OxoKPrLklGWeeCt1hGc 2/8EVyCdwCIh+ideCUh0ow9HS8bshKarstdbFE6C2Hk8mSypRyyTGa2B4wQ5vwsmTklh 0XAA1HYdj0LkBXHVBgN3HCEOWaxXtmoxOiUuNS0nFFLrtEclq3DZoyrcHSz1RNAGYjis vzXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q/pu3pQE7J0qCOHmyFk5H4lCsjP9Yu4ShUEtYcOV3Ic=; b=tMrliQYGI68OfLp6JWdTU6q+U3n/LxSBFMoFHWE86ch1yBIohMuDe2ZxvfFKB+Ulzz Bcqq+UMzYgv7yBKsW2Lr13OWmw7lHODJOV5BBb+TnqKORD+T8nJPOHf8SjXD7wUWWgQM WaglEKjJohFwL+80z+UExpcNgNbr5jgTlEHIeJQyggSS9d5OUPaXg6XuWchFCjd+lDEi 0I1OVCgkLURM6qVQXbeZLEmcye36pLGD6kf/s5ZaQDpKh9rCIfv/h1FtrA8XhRM0I1Cy CyQGiRfQjtDvKzGhJ4mAlfvq50vW7PbUF05G2WOqE3ZFplJ3l13qTCLvFdN0ESCPP3GY MkWw==
X-Gm-Message-State: AHYfb5jNYaeRpJHRZs8fWjkwBWpAISgvn1oUe+/WeXdIuWIHFcTq0mt0 l5rKGOjEsqBWpVMoMaUpKEA3E/J1JCVGiY/9iA==
X-Received: by 10.200.40.204 with SMTP id j12mr30378502qtj.139.1502710222069; Mon, 14 Aug 2017 04:30:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.25.236 with HTTP; Mon, 14 Aug 2017 04:30:01 -0700 (PDT)
In-Reply-To: <3617BEAA-8DCE-4BB5-9408-3AA78E986F27@dotat.at>
References: <20170812170958.14197.qmail@ary.lan> <B21C539E-75AF-43F1-B6B0-4BDC25C6D670@fugue.com> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> <C12D3CFC-74DF-49C1-8947-863D49EEEEA5@dotat.at> <D4C0F17B-A939-41BD-855A-77A6E7986941@vpnc.org> <3617BEAA-8DCE-4BB5-9408-3AA78E986F27@dotat.at>
From: Mike West <mkwst@google.com>
Date: Mon, 14 Aug 2017 13:30:01 +0200
Message-ID: <CAKXHy=doWBA8NbCfzV74zs71JBJjs3nET-kBJ0+ohY5EZLM=1Q@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Cc: Ted Lemon <mellon@fugue.com>, Tony Finch <dot@dotat.at>, Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary="001a114070dafd281d0556b4fc3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/J2ml2L1WpS7JhHdWlyptET0yCDQ>
Subject: Re: [DNSOP] Status of "let localhost be localhost"?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Aug 2017 11:30:26 -0000

I've uploaded an -05 draft
<https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-05> (diff
to -04
<https://tools.ietf.org/rfcdiff?url2=draft-west-let-localhost-be-localhost-05.txt>)
that addresses some of the feedback in this thread, Ted Lemon's in
particular. It attempts to spell out the rationale for the NXDOMAIN change
more clearly, boiling it down to Ted's suggestion that we ought to be
recommending that stub resolvers fail closed when they forward requests for
localhost names on to recursive resolvers.

The draft also follows up on recommendations that Mark and others have made
regarding DNSSEC by requesting an insecure delegation of `localhost.` in
the root-zone (I found Warren's notes on the topic in
https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4 quite
useful, btw).

Tony: I'd like to understand more clearly what justification you'd like the
draft to present. Do the changes in -05 give the reader enough context, or
does it need more work in that regard? Does shifting the application-level
requirements into the main body of the draft, out of the implementation
considerations section, make the requirements around security decisions for
localhost names clear enough?

-mike

On Mon, Aug 14, 2017 at 2:36 AM, Tony Finch <dot@dotat.at> wrote:

>
> > On 13 Aug 2017, at 23:51, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> >
> > On 13 Aug 2017, at 10:19, Tony Finch wrote:
> >>
> >>
> >> RFC 6761 requires recursive servers to return positive 127.0.0.1 and
> ::1 responses, not NXDOMAIN. I can't see an explanation in the draft for
> the change to NXDOMAIN.
> >
> > And there should be. Proposed addition to the last paragraph of Section
> 1:
> >
> > A consequence of the requirement that the resolver APIs MUST resolve
> "localhost." and any names falling within ".localhost." to loopback
> addresses is that caching DNS servers and authoritative DNS servers MUST
> NOT resolve those names at all, and always return NXDOMAIN.
>
> Well, that isn't really the kind of text I wanted.
>
> You have written a paragraph that is obvious from the internal logic of
> the draft, but it doesn't say why "a consequence" has changed from RFC 6761.
>
> What we really need is an informed analysis of the consequences of
> different ways of sinking localhost queries on recursive servers. The de
> facto way is NXDOMAIN (same as what happens when there is no special case
> in the resolver, except without the recursion to the root servers). The RFC
> 6761 way is to return locally authoritative positive responses.
>
> Either way, BIND (for instance) needs special configuration to be RFC 6761
> compliant or NXDOMAIN compliant, so some kind of code change is needed to
> make the Right Thing the default, but which Thing's Rightness needs
> justification.
>
> There are also missing security considerations. The whole draft is
> motivated by web security edge cases, so I would like to see a summary and
> citation of the same site scripting problem, and whatever other issues
> there might be.
>
> Does the change from positive responses to NXDOMAIN have some connection
> to the web security motivation? It isn't clear to me and it ought to be.
>
> There is also a weird compatibility awkwardness. RFC 6761 requires
> *.localhost to resolve to localhost, in stub and recursive resolvers. You
> can't implement this in traditional Unix libc resolvers. It's possible to
> implement this in a recursive server like BIND, but I realised this week
> that I had not implemented the wildcard in my config, so I bet proper RFC
> 6761 conformance is rare.
>
> The upshot of the draft's current text is that full system behaviour will
> vary depending on libc version, recursor version, recursor config, etc.
>
> I think it is still a good idea to tighten up the implementation
> requirements to MUST. That part of the draft is good, but trivial.
>
> The interesting part is not stated in the current text: it is that
> application software that makes security assumptions about localhost MUST
> internally resolve localhost without relying on the shifting historical and
> operational variability of stub resolvers and recursive servers.
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>