IETF Logo Mail Archive

Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

Mark Andrews <marka@isc.org> Thu, 07 September 2017 04:59 UTC

Return-Path: <marka@isc.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 469C31321DC for <dnsop@ietfa.amsl.com>; Wed, 6 Sep 2017 21:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 QSQXmH_byBJY for <dnsop@ietfa.amsl.com>; Wed, 6 Sep 2017 21:59:43 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 7F9CF1321C7 for <dnsop@ietf.org>; Wed, 6 Sep 2017 21:59:43 -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.ams1.isc.org (Postfix) with ESMTPS id 9B75F24AE3D; Thu, 7 Sep 2017 04:59:30 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5C12D160043; Thu, 7 Sep 2017 04:59:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 431A2160071; Thu, 7 Sep 2017 04:59:37 +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 jskDaQQIxeUM; Thu, 7 Sep 2017 04:59:37 +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 97253160043; Thu, 7 Sep 2017 04:59:36 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C194B848328B; Thu, 7 Sep 2017 14:59:34 +1000 (AEST)
To: Ted Lemon <mellon@fugue.com>
Cc: Warren Kumari <warren@kumari.net>, dnsop WG <dnsop@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <CADyWQ+EZQY9i5-4Ce-NZykwC+sS6iY868Wg0crW6KAZTGQxFQg@mail.gmail.com> <24CD1C88-58C5-4D6C-9F00-E3A2CD8C657C@fugue.com> <CADyWQ+Ex23QVef3AegWB4Jgd-sjG-G4z7XmXL9guN8PeWtsssw@mail.gmail.com> <93C3A47F-07C4-443F-AB87-B5C29F6B6774@fugue.com> <CAHw9_iKBDY9hNThOY3GDeG7BbCkc8Ncy1T=rjpcQ=h5qdB7=UQ@mail.gmail.com> <20170907041659.ED0BB8482BFF@rock.dv.isc.org> <CAPt1N1kXeF0zj_VHuv00taZ+39hR6Nw19uZ5rdxJr3aUeS5RvQ@mail.gmail.com>
In-reply-to: Your message of "Thu, 07 Sep 2017 00:42:09 -0400." <CAPt1N1kXeF0zj_VHuv00taZ+39hR6Nw19uZ5rdxJr3aUeS5RvQ@mail.gmail.com>
Date: Thu, 07 Sep 2017 14:59:34 +1000
Message-Id: <20170907045934.C194B848328B@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YqosmSEo_s3-ubBwzScpa8ohNt0>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-west-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: Thu, 07 Sep 2017 04:59:46 -0000

In message <CAPt1N1kXeF0zj_VHuv00taZ+39hR6Nw19uZ5rdxJr3aUeS5RvQ@mail.gmail.com>
, Ted Lemon writes:
> 
> Mark, I really don't think this is a human rights issue. Is there something
> that will break for you if the secure denial of existence is left in place?

I shouldn't BE FORCED to hard code special LOCALHOST rules into DNS
tools.  Lookups should "just work" like they did before the root
zone was signed.

Mark

> On Sep 7, 2017 12:17 AM, "Mark Andrews" <marka@isc.org> wrote:
> 
> >
> > In message <CAHw9_iKBDY9hNThOY3GDeG7BbCkc8Ncy1T=rjpcQ=h5qdB7=
> > UQ@mail.gmail.com>
> > , Warren Kumari writes:
> >
> > > On Wed, Sep 6, 2017 at 10:35 AM, Ted Lemon <mellon@fugue.com> wrote:
> > > > On Sep 6, 2017, at 10:33 AM, tjw ietf <tjw.ietf@gmail.com> wrote:
> > > >
> > > > Thanks.  The document still waffles, but it 'waffles less' than it did
> > > > initially.  But Mike is committed to working that and any other issue
> > > which
> > > > may arise.
> > > >
> > > >
> > > > The question I really have is not whether Mike is willinghe's stated
> > > that
> > > > he is.   It's whether the working group is willing, since returning
> > > NXDOMAIN
> > > > is an actual change in behavior from the original specification in RFC
> > > 6761,
> > > > and will likely result in some breakage, since it can safely be assumed
> > > that
> > > > some stacks are currently following the RFC6761 advice.
> > > >
> > >
> > > Actually, I suspect that the breakage will be fairly minimal -- Google
> > > Public DNS appears to have been returning NXDOMAIN since launch:
> > > dig +nocmd +nostats localhost @8.8.8.8
> > > ;; Got answer:
> > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55075
> > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> > >
> > > ;; QUESTION SECTION:
> > > ;localhost. IN A
> > >
> > > ;; AUTHORITY SECTION:
> > > . 14208 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017090502
> > > 1800 900 604800 86400
> >
> > Which shows absolutely nothing.
> >
> > Is 'localhost.' assigned for use by my local machine?  I believe
> > the answer to that is: Yes.  If if is assigned for use then with
> > DNSSEC there MUST be a delegation in the root or is this working
> > group going to overstep its mandate and tell me how I can use the
> > name localhost.  ICANN stuffed up by not adding the delegation when
> > the root zone was signed.  It was necessary then and it is still
> > necessary now.
> >
> > If we want to create a alternative name and give it much more
> > restrictive properties than the current assignment of localhost has
> > then I'm fine with that.  It is actually the correct fix for the
> > problem statement.  Fiddling with the properties of localhost after
> > it has been in use for decades isn't the way to address this issue.
> >
> > Mark
> >
> > > and Verisign returns NOERROR (probably also since launch):
> > > dig +nocmd +nostats localhost @64.6.64.6
> > > ;; Got answer:
> > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44657
> > > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> > >
> > > ;; QUESTION SECTION:
> > > ;localhost. IN A
> > >
> > > ;; ANSWER SECTION:
> > > localhost. 10800 IN A 127.0.0.1
> > >
> > >
> > > This doesn't seem to have caused any breakage - or, at least, we
> > > haven't heard of any, and apparently basically no-one had noticed a
> > > difference :-)
> > >
> > > W
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > DNSOP mailing list
> > > > DNSOP@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/dnsop
> > > >
> > >
> > >
> > >
> > > --
> > > I don't think the execution is relevant when it was obviously a bad
> > > idea in the first place.
> > > This is like putting rabid weasels in your pants, and later expressing
> > > regret at having chosen those particular rabid weasels and that pair
> > > of pants.
> > >    ---maf
> > >
> > > _______________________________________________
> > > DNSOP mailing list
> > > DNSOP@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dnsop
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> >
> 
> --089e0826f99c5cfff90558921502
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"auto">Mark, I really don&#39;t think this is a human rights iss=
> ue. Is there something that will break for you if the secure denial of exis=
> tence is left in place?</div><div class=3D"gmail_extra"><br><div class=3D"g=
> mail_quote">On Sep 7, 2017 12:17 AM, &quot;Mark Andrews&quot; &lt;<a href=
> =3D"mailto:marka@isc.org">marka@isc.org</a>&gt; wrote:<br type=3D"attributi=
> on"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
> t:1px #ccc solid;padding-left:1ex"><br>
> In message &lt;CAHw9_<wbr>iKBDY9hNThOY3GDeG7BbCkc8Ncy1T=3D<wbr>rjpcQ=3Dh5qd=
> B7=3D<a href=3D"mailto:UQ@mail.gmail.com">UQ@mail.gmail.com</a><wbr>&gt;<br=
> >
> , Warren Kumari writes:<br>
> <br>
> &gt; On Wed, Sep 6, 2017 at 10:35 AM, Ted Lemon &lt;<a href=3D"mailto:mello=
> n@fugue.com">mellon@fugue.com</a>&gt; wrote:<br>
> &gt; &gt; On Sep 6, 2017, at 10:33 AM, tjw ietf &lt;<a href=3D"mailto:tjw.i=
> etf@gmail.com">tjw.ietf@gmail.com</a>&gt; wrote:<br>
> &gt; &gt;<br>
> &gt; &gt; Thanks.=C2=A0 The document still waffles, but it &#39;waffles les=
> s&#39; than it did<br>
> &gt; &gt; initially.=C2=A0 But Mike is committed to working that and any ot=
> her issue<br>
> &gt; which<br>
> &gt; &gt; may arise.<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; The question I really have is not whether Mike is willinghe&#39;s=
>  stated<br>
> &gt; that<br>
> &gt; &gt; he is.=C2=A0 =C2=A0It&#39;s whether the working group is willing,=
>  since returning<br>
> &gt; NXDOMAIN<br>
> &gt; &gt; is an actual change in behavior from the original specification i=
> n RFC<br>
> &gt; 6761,<br>
> &gt; &gt; and will likely result in some breakage, since it can safely be a=
> ssumed<br>
> &gt; that<br>
> &gt; &gt; some stacks are currently following the RFC6761 advice.<br>
> &gt; &gt;<br>
> &gt;<br>
> &gt; Actually, I suspect that the breakage will be fairly minimal -- Google=
> <br>
> &gt; Public DNS appears to have been returning NXDOMAIN since launch:<br>
> &gt; dig +nocmd +nostats localhost @<a href=3D"http://8.8.8.8" rel=3D"noref=
> errer" target=3D"_blank">8.8.8.8</a><br>
> &gt; ;; Got answer:<br>
> &gt; ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NXDOMAIN, id: 55075=
> <br>
> &gt; ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0<b=
> r>
> &gt;<br>
> &gt; ;; QUESTION SECTION:<br>
> &gt; ;localhost. IN A<br>
> &gt;<br>
> &gt; ;; AUTHORITY SECTION:<br>
> &gt; . 14208 IN SOA <a href=3D"http://a.root-servers.net" rel=3D"noreferrer=
> " target=3D"_blank">a.root-servers.net</a>. <a href=3D"http://nstld.verisig=
> n-grs.com" rel=3D"noreferrer" target=3D"_blank">nstld.verisign-grs.com</a>.=
>  <a href=3D"tel:2017090502" value=3D"+12017090502">2017090502</a><br>
> &gt; 1800 900 604800 86400<br>
> <br>
> Which shows absolutely nothing.<br>
> <br>
> Is &#39;localhost.&#39; assigned for use by my local machine?=C2=A0 I belie=
> ve<br>
> the answer to that is: Yes.=C2=A0 If if is assigned for use then with<br>
> DNSSEC there MUST be a delegation in the root or is this working<br>
> group going to overstep its mandate and tell me how I can use the<br>
> name localhost.=C2=A0 ICANN stuffed up by not adding the delegation when<br=
> >
> the root zone was signed.=C2=A0 It was necessary then and it is still<br>
> necessary now.<br>
> <br>
> If we want to create a alternative name and give it much more<br>
> restrictive properties than the current assignment of localhost has<br>
> then I&#39;m fine with that.=C2=A0 It is actually the correct fix for the<b=
> r>
> problem statement.=C2=A0 Fiddling with the properties of localhost after<br=
> >
> it has been in use for decades isn&#39;t the way to address this issue.<br>
> <br>
> Mark<br>
> <br>
> &gt; and Verisign returns NOERROR (probably also since launch):<br>
> &gt; dig +nocmd +nostats localhost @<a href=3D"http://64.6.64.6" rel=3D"nor=
> eferrer" target=3D"_blank">64.6.64.6</a><br>
> &gt; ;; Got answer:<br>
> &gt; ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 44657<=
> br>
> &gt; ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: =
> 0<br>
> &gt;<br>
> &gt; ;; QUESTION SECTION:<br>
> &gt; ;localhost. IN A<br>
> &gt;<br>
> &gt; ;; ANSWER SECTION:<br>
> &gt; localhost. 10800 IN A 127.0.0.1<br>
> &gt;<br>
> &gt;<br>
> &gt; This doesn&#39;t seem to have caused any breakage - or, at least, we<b=
> r>
> &gt; haven&#39;t heard of any, and apparently basically no-one had noticed =
> a<br>
> &gt; difference :-)<br>
> &gt;<br>
> &gt; W<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; ______________________________<wbr>_________________<br>
> &gt; &gt; DNSOP mailing list<br>
> &gt; &gt; <a href=3D"mailto:DNSOP@ietf.org">DNSOP@ietf.org</a><br>
> &gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dnsop" rel=3D"no=
> referrer" target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/dnso=
> p</a><br>
> &gt; &gt;<br>
> &gt;<br>
> &gt;<br>
> &gt;<br>
> &gt; --<br>
> &gt; I don&#39;t think the execution is relevant when it was obviously a ba=
> d<br>
> &gt; idea in the first place.<br>
> &gt; This is like putting rabid weasels in your pants, and later expressing=
> <br>
> &gt; regret at having chosen those particular rabid weasels and that pair<b=
> r>
> &gt; of pants.<br>
> &gt;=C2=A0 =C2=A0 ---maf<br>
> &gt;<br>
> &gt; ______________________________<wbr>_________________<br>
> &gt; DNSOP mailing list<br>
> &gt; <a href=3D"mailto:DNSOP@ietf.org">DNSOP@ietf.org</a><br>
> &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dnsop" rel=3D"norefer=
> rer" target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/dnsop</a>=
> <br>
> <br>
> --<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0INTERNET: <a href=3D"mailto:marka@isc.org">marka@isc.org</a><br>
> </blockquote></div></div>
> 
> --089e0826f99c5cfff90558921502--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email