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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 26 January 2018 16:19 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 E5490124BAC for <dnsop@ietfa.amsl.com>; Fri, 26 Jan 2018 08:19:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAxR3NM5uwC8 for <dnsop@ietfa.amsl.com>; Fri, 26 Jan 2018 08:19:34 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9FC12426E for <dnsop@ietf.org>; Fri, 26 Jan 2018 08:19:33 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 252D27A330A; Fri, 26 Jan 2018 16:19:33 +0000 (UTC)
Date: Fri, 26 Jan 2018 16:19:33 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20180126161932.GH3322@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <20180125203549.GD3322@mournblade.imrryr.org> <95B1FF6E-A9C3-4679-BE15-2066B9030CD6@fugue.com> <CANV=THh6bOxd_UW=TuLonWzz0KyGapkGWpMiNuu54W=45gFAvg@mail.gmail.com> <20180124205620.GZ3322@mournblade.imrryr.org> <alpine.DEB.2.11.1801251558440.5022@grey.csi.cam.ac.uk> <20180125203225.GC3322@mournblade.imrryr.org> <20180126004807.GE3322@mournblade.imrryr.org> <D34C1BCF-E281-4167-89C6-CFFA12191707@fugue.com> <20180126013725.GF3322@mournblade.imrryr.org> <1F773B1D-B1E6-4DF0-809B-F255CDA1B927@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1F773B1D-B1E6-4DF0-809B-F255CDA1B927@fugue.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EcMfvVxlg_1ENbwJeYr9DyZsyVU>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
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: Fri, 26 Jan 2018 16:19:36 -0000

On Thu, Jan 25, 2018 at 10:18:01PM -0500, Ted Lemon wrote:

> On Jan 25, 2018, at 8:37 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> > I showed examples, of uses of "localhost".  Some use the TLD itself
> > for the usual local IPs, others employ subdomains of "localhost"
> > as a sensibly convenient place to park "for my eyes only" local
> > DNS data.  These examples are not exhaustive.
> 
> That's not what I'm getting at.   What I'm getting at is that you are a
> consenting adult, and you are using localhost as a hack.   What you are
> doing is not the right way to do the hack it's the expedient way to do
> the hack.

A rather impolite characterization of well motivated practice.
Serving local data for "localhost" is no more a hack than synthesizing
NXDOMAIN.  Indeed it builds on long-standing advice and practice
to implement an authoritative zone for "localhost" with contents
along the lines of:

    $ORIGIN localhost.
    @ IN SOA localhost. root.localhost. ( 1 3600 1200 604800 1200 )
    @ IN NS localhost.
    @ IN A 127.0.0.1
    @ IN AAAA ::1

Once one (and many others) is doing this anyway, it makes a great
deal of sense to augment this zone (visible only at a loopback
listening local resolver) with additional data that is "for my eyes
only".  Indeed no other zone (homenet as you suggest) is nearly as
natural in this case.  This is data for and about "localhost".

Yet, if one dismisses my extended use of the localhost zone for
various local DNS records, the original use of providing local
resolution of "localhost." remains (however rarely needed in
practice, e.g. some Postfix configurations), and need not be
proscribed by this specification.

The MUST NXDomain, should be changed to a:

     SHOULD NXDomain in the absence of locally configured data.
     Either way, recursive queries for the "localhost" zone SHOULD
     [generally?, see below] not be forwarded.

> The right way to do the hack is with a real domain name.

Well, this draft recognizes the long-established fact that "localhost"
*is* a real domainname, just one that has a local meaning on every
host, which makes it precisely suitable for the purpose to which
it was put.

> You could for example use .homenet or something like it to address the
> problem.   Localhost is just a convenient top-level domain that you know
> you can safely use.

No, "homenet" is not a private per-host domain, it is a private
site-local domain of recent vintage.  It does not have the
long-standing track-record of "localhost" as being a portable
single-host authoritative domain.  A machine that uses "localhost"
privately on the loopback interface might still want to access its
site's "homenet".

> If it were the case that some end user who is not a consenting adult were
> going to have a problem as a result of this text, then I think that would
> be something we'd need to consider.   But in this case there's no problem.
> If you want to do the hack, do the hack.   It's a hack.   It wasn't kosher
> to begin with, and this doesn't make it any less kosher.

I find this retort noticeably patronizing, I hope that's not
intentional.  The "hack" was a natural extension of well-founded
long-standing practice.

> > I also note that the draft does not adequately discuss what to do
> > with queries with the DO bit set[1].  Presumably a forged NXDOMAIN
> > without appropriate root-zone NSEC records may not be adequate in
> > that case.  It probably (my opinion) makes more sense to obtain,
> > and cache the NSEC and RRSIG records from the root servers, than
> > to return a "bogus" reply.
> 
> The draft already addresses the DNSSEC use case.   What is the failure
> mode that you are concerned about here?   What would go wrong?

The draft does address DNSSEC in any detail, it just dismisses the
issue.  All it does is restate the fact that the root zone uses DNSSEC:

   The ".localhost" TLD is already assigned to IANA, as per [RFC2606],
   but does not have an entry in the root-zone.  This means that the
   root will return an NXDOMAIN response along with NSEC records
   constituting a secure denial of existence if queried.  That's
   consistent with the general principle that localhost names do not
   exist in the DNS, and the subsequent requirements to return NXDOMAIN
   that are laid out in Section 3.

And not surprisingly the change log shows:

    o  Explicitly waffling on DNSSEC.

This simply neglects to even consider what to do when the client's
recursive query sets the DO bit asking for DNSSEC-validation data
along with the recursive server's reply.

My suggestion is that given that such queries are by all accounts
going to be somewhat rare, and in the absence of local data, it
does no harm for the resolver in that case, instead of synthesizing
a "bogus" NXDOMAIN reply (sans valid NSEC records and RRSIGs) should
obtain, cache and serve the above mentioned root zone's DNSSEC-validated
NXDOMAIN response, this is basically status quo ante.  The synthesis
of NXDOMAIN would then be out of scope when the client requests a DNSSEC
validated response.

The DNSSEC-validated NXDomain could be cached for longer than the
advertised TTL, up to the expiration of the underlying NSEC RRSIGs,
but code to do may be not worth the effort.

If the group prefers that bogus NXDomain should be returned anyway
(in the absence of local data), the draft should at least say so,
noting clients may discard the "bogus" answer, and try another
server, and also repeat such queries more frequently.

What all this boils down to, is that I strongly support the draft's
recommendation to short-circuit A and AAAA lookups of "localhost"
in stub resolvers (DNS lookup libraries).  I also explain that
going further and requiring MUST NXDomain (for "localhost") in
recursive resolvers is undesirable, and by all accounts largely
unnecessary.  A more sensible prescription for recursive resolvers is:

     In the absence of locally configured data for "localhost",
     recursive queries that do not set the DO bit should not be
     forwarded, and NXDomain SHOULD be returned instead.

     When a recursive query does set the DO bit, the query should
     be forwarded and returned NSEC and RRSIG records cached and
     served in reply to future similar queries.  This avoids serving
     "bogus" replies to clients that are looking for DNSSEC-validated
     answers.

-- 
	Viktor.