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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 26 January 2018 01:37 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 C9B8112D875 for <dnsop@ietfa.amsl.com>; Thu, 25 Jan 2018 17:37:28 -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 ZbqfpQMwUF7S for <dnsop@ietfa.amsl.com>; Thu, 25 Jan 2018 17:37:27 -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 DF3E612D859 for <dnsop@ietf.org>; Thu, 25 Jan 2018 17:37:26 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 314737A330A; Fri, 26 Jan 2018 01:37:26 +0000 (UTC)
Date: Fri, 26 Jan 2018 01:37:26 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20180126013725.GF3322@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <20180125175416.GA3322@mournblade.imrryr.org> <AB53330A-91CB-4F76-96A5-99743F12A955@fugue.com> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D34C1BCF-E281-4167-89C6-CFFA12191707@fugue.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rShGA7r3hMVo4CxEc7YjaDoTrLM>
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 01:37:29 -0000

On Thu, Jan 25, 2018 at 08:17:17PM -0500, Ted Lemon wrote:

> On Jan 25, 2018, at 7:48 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> > See my other upstream message quoted below.  There are deployed
> > uses of local "localhost" zones, and a mandate to break them is
> > not well motivated in this draft.
> 
> Okay, so if I understand you correctly, you are saying that:
> 
> Rather than setting up a unique domain name to solve a problem
> you had with postfix, you used localhost, for convenience
> You believe that this practice, or similar practices, are widespread

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.

> I think you acknowledge that you can still do this hack even if
> the document says you mustn't.

You say that, and I don't deny that, but I am not saying it, because
there should be no need to ignore a MUST in an RFC just to do as
the administrator asks and serve locally configured data.

> You also propose that recursive resolvers not forward localhost, but then
> there's actually no way to reply with anything other than NXDOMAIN,

No, a resolver can return any locally configured "localhost" data.
Many resolvers (BIND, unbound, ...) can serve some local data on
the side.

> because a recursive resolver won't have authoritative information.

Well, it BIND the data would be authoritative, while in unbound
"local-data" can take a variety of forms.

> Maybe you mean a hybrid server that is recursive for domains for
> which it isn't authoritative?

Yes.  All the recursive servers I've used can also serve some local
data.  They should be able to continue to do that even when for
the "localhost" TLD.

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 opionion) makes more sense to obtain,
and cache the NSEC and RRSIG records from the root servers, than
to return a "bogus" reply.

-- 
	Viktor.

P.S.

[1] I expect such queries to be rare, many on this list may be
aware of my stated preference to see DNSSEC handled almost always
in a loopback iterative resolver, with applications relying on the
returned AD bit, rather than doing their own DNSSEC validation.