Re: I-D Action: draft-west-let-localhost-be-localhost-00.txt

Mark Andrews <marka@isc.org> Tue, 27 September 2016 22:14 UTC

Return-Path: <marka@isc.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1972B12B35A for <ietf@ietfa.amsl.com>; Tue, 27 Sep 2016 15:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.217
X-Spam-Level:
X-Spam-Status: No, score=-9.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, 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 6TmbPWQND5xJ for <ietf@ietfa.amsl.com>; Tue, 27 Sep 2016 15:14:11 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617FD12B34D for <ietf@ietf.org>; Tue, 27 Sep 2016 15:14:11 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id AABB13493A2; Tue, 27 Sep 2016 22:14:07 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9718F160041; Tue, 27 Sep 2016 22:14:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 86480160081; Tue, 27 Sep 2016 22:14:07 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 50s0l8q9N9u4; Tue, 27 Sep 2016 22:14:07 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3A39B160041; Tue, 27 Sep 2016 22:14:07 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0504F5520B28; Wed, 28 Sep 2016 08:14:04 +1000 (EST)
To: John R Levine <johnl@taugh.com>
From: Mark Andrews <marka@isc.org>
References: <CAKXHy=fCoQPb4EJ2aS9Lfj6yKM-HotjhO_VsPk2PDeFATxpGdg@mail.gmail.com> <20160927184845.5034.qmail@ary.lan> <20160927211208.zrkp4txdpelw3at4@emily-tablet> <alpine.OSX.2.11.1609271717330.72382@ary.qy>
Subject: Re: I-D Action: draft-west-let-localhost-be-localhost-00.txt
In-reply-to: Your message of "27 Sep 2016 17:19:49 -0400." <alpine.OSX.2.11.1609271717330.72382@ary.qy>
Date: Wed, 28 Sep 2016 08:14:04 +1000
Message-Id: <20160927221405.0504F5520B28@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/RW1d275OVwy67EGkSS2EAtFO7ps>
Cc: IETF general list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2016 22:14:13 -0000

In message <alpine.OSX.2.11.1609271717330.72382@ary.qy>, "John R Levine" writes:
> > I'm probably not explaining myself well so I'll give an example. In the setup 
> > above, let's say you've set 127.0.1.1 to be your local DNS server, meaning 
> > that you might expect the following commands to work:
> >      $ dig mysite.localhost
> >   mysite.localhost IN A 127.0.0.1
> >
> >   $ dig myothersite.localhost
> >   myothersite.localhost IN A 127.200.200.200
> >
> > But, under this proposal wouldn't dig be obliged to refuse to forward the 
> > request onto 127.0.1.1? How does dig (or your browser or any other resolving 
> > API) know the difference between a bog standard caching DNS server and a 
> > local DNS server that has explicitly been set up to route local lookups?
> 
> I don't see why.  You're allowed to use common sense when interpreting 
> RFCs, and the message here is clearly that if you want to interoperate you 
> do not send queries for *.localhost out of your computer. The twisty way 
> my or your internal DNS setup works is out of scope.
> 
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

Well we really should ensure that there is a break in the DNSSEC
chain of trust between the root zone and the localhost zone.

i.e. a insecure delegation for localhost gets added to the root
zone pointing back to the root servers or another set of servers.

At least this is only changing how localhost is handled in the
special names registry rather than attempting to add it.

http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

I would just be asking for IANA to be creating the delegation
described above and for DNS recursive server vendors to be adding
a default localhost zone with SOA, NS, A and AAAA records at the
zone apex if none is otherwise configured in a manner similar to
RFC 6303.

The following will be consistent with RFC 6303.

localhost. 0 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
localhost. 0 IN NS localhost.
localhost. 0 IN A 127.0.0.1
localhost. 0 IN AAAA ::1

One could also just do a "empty" zone.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org