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

Andrew Sullivan <ajs@anvilwalrusden.com> Sat, 10 February 2018 23:53 UTC

Return-Path: <ajs@anvilwalrusden.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 558D01270A7 for <dnsop@ietfa.amsl.com>; Sat, 10 Feb 2018 15:53:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=F9+SP2Ds; dkim=pass (1024-bit key) header.d=yitter.info header.b=XP8CluIw
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 VrFierRYfNii for <dnsop@ietfa.amsl.com>; Sat, 10 Feb 2018 15:53:22 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776C4126E64 for <dnsop@ietf.org>; Sat, 10 Feb 2018 15:53:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 43AFDBD363 for <dnsop@ietf.org>; Sat, 10 Feb 2018 23:52:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1518306771; bh=3iU1wtdAZCbGQ7oTETUGIuXyK3aLT5+dzSMmaOPwNpI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=F9+SP2DsQa+EktTkjWNBo36rtECgmT/c+77+6oxwh6WMn6T24Usv7gMDOzBO8tzVZ jVxU6vNvcr/BixDFd+09YODg/VpkQkm3cr+qedEhzAwlV7KSm6IYA0enlTIJz7L5gx 9aG3kEI5HPhDkPulZyWwLgz7yk59WpFewCauTknQ=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSOA2zz0FXvl for <dnsop@ietf.org>; Sat, 10 Feb 2018 23:52:49 +0000 (UTC)
Date: Sat, 10 Feb 2018 18:52:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1518306769; bh=3iU1wtdAZCbGQ7oTETUGIuXyK3aLT5+dzSMmaOPwNpI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=XP8CluIwDYRRwZNnR0AHee9Hj2vQ93AS+JnrutwXUeV4UQ/DU5tCg0NBPrniDMORe 3753ewpH3pZMeSGV6LLXnw6qNZpXhrjDHyEvfijg3Obvv2qn7uZVhP5etRTjM6SaO5 M8q2ZHV+aYEegZlbRGJ6xyqA9d0qpEmhsd7hot/c=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20180210235247.GD974@mx4.yitter.info>
References: <E4C5AA7E-E9C1-4E53-ABE0-676A9B7B3269@isc.org> <618D31E1-8EC7-4F75-BD97-31D42CB1E681@fugue.com> <40992CF7-5740-43ED-8B78-8D8A9B50A15C@isc.org> <F28D0F1D-416E-4016-8A5A-95173FFFAA4E@fugue.com> <CANLjSvVd+vj8M+vBOokfpOL1fmq2iU9JAhSCd6eY_aoE1p5SMQ@mail.gmail.com> <97783B49-11C9-47F1-8F73-3D909C9B4DC4@fugue.com> <CANLjSvUV1RPR8nhLXCEL0WT9=2Lqb+4STh+7gSRPvv_Mmf-NTA@mail.gmail.com> <698033B2-09A6-4E66-82AD-04906D4DEA1B@fugue.com> <20180209225508.GC974@mx4.yitter.info> <CBC8CD1F-F6CC-4C2B-962B-121888F108A6@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CBC8CD1F-F6CC-4C2B-962B-121888F108A6@fugue.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HSvGRJXr9YkL7kHVuBSHaTxNkws>
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: Sat, 10 Feb 2018 23:53:24 -0000

Hi,

First, let me be clear that I am (personally) not now, nor have I ever
been, a member of the resolver implementation party; so my opinion is
biased about what is obvious.  If various resolver-writers were to
chime in to say that what is obvious to you is obvious to them too
(and I don't think we need perfect consensus, as usual), then I'll
cheerfully withdraw. Nobody ever wants to see samples of my C code,
including me.

On Fri, Feb 09, 2018 at 07:21:05PM -0500, Ted Lemon wrote:
> 
> This is really fascinating.   To me what this code requires it something like the following, in any affected stub resolver:
> 

One architectural point I _think_ I've been trying to make is exactly
that "in any affected stub resolver" is in fact the entire universe of
deployed resolvers (including stubs).  We have zero reason to suppose
that old habits will die -- hard, soft, or at all -- within another
generation, given the results we got with EDNS0.  So, I think I am
asking, "Why isn't the original 6761 advice better?"  That advice
would have the root zone return RDATA appropriate to the QNAME
"localhost" (depending on RRTYPE).  It has no advice about TTL, if I
recall correctly, so one could trivially set it to the maximum.  Maybe
if the roots did this, everyone else would follow 6761 too.

> resolve(name):
>   if (name == 'localhost'):
>     return [IPv4Addr('127.0.0.1'), IPv6Addr('::1')]

But what you have just done there is short-circuited the search
processing, thereby retroactively making "localhost" a restricted
_label_ in every network that relies on search processing.  Now, I
think that such networks are broken in deep ways[1].  Those ways are,
however, mostly unobserved by many network operators.  The operators we
are trying to sort out -- the ones who already aren't following 6761
-- are entirely unlikely to believe this advice either.

> So to me there is no obvious architectural superiority to what you think is correct.

I don't think it is _correct_.  I believe the existing state of
affairs is bad.  I also think that good architecture doesn't just come
along and smash existing practice, like some Corbusier Moses.  We have
an existing system, and what the document wants to do is make a number
of reservations (effectively across the entire DNS tree) in an effort
to solve a problem that would be _already solved_ by the existing RFC,
were it implemented.  But that RFC was apparently not implemented, and
therefore I think this I-D is dangerous because it entails rules about
a certain label that extend down the tree, even though it is solving a
problem that might already have been solved if 6761 were followed.  I
don't believe we should take greater action when the previous, lesser
action has not yet been implemented.

Best regards,

A

[1] To be clear, I say this with pretty full experience of my current
employer's "enterprise network(s)".  I used to think my picture of
such networks was a nasty parody, including every bad idea I could
think of.  As it turns out, I was short on bad ideas.

-- 
Andrew Sullivan
ajs@anvilwalrusden.com