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

From: tjw ietf <[email-masked]>
Date: Wed, 6 Sep 2017 10:00:01 -0400

When the idea of having a Call for Adoption for this document came up, we
thought long and hard about this one.  However, the comments from the
working group focused this document to address the specific issue of the
local hostname.

This starts a formal Call for Adoption for
draft-west-let-localhost-be-localhost

The draft is available here:
https://datatracker.ietf.org/doc/draft-west-let-localhost-be-localhost/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 20 September 2017

Thanks,
tim wicinski
DNSOP co-chair

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Sep 2017 10:29:00 -0400

The document as written still waffles between insecure delegation and secure denial of existence.   I think that if the document were published with the recommendation of an insecure delegation, this would be actively harmful.   If it's published with the secure denial of existence, it would probably improve the state of the art.

Unfortunately I don't think that calls for adoption really give us a basis for stating such preferences.   But that's basically where I land on this.   I would be perfectly happy to support this document if it does the right thing, but I'm dead set against it if it doesn't.   I am of course willing to participate in working on the document if adopted—I've already sent some text, and am grateful to the author for having for the most part accepted my proposed changes.

---

From: tjw ietf <[email-masked]>
Date: Wed, 6 Sep 2017 10:33:26 -0400

Ted

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.

tim

On Wed, Sep 6, 2017 at 10:29 AM, Ted Lemon <[email-masked]> wrote:

> The document as written still waffles between insecure delegation and
> secure denial of existence.   I think that if the document were published
> with the recommendation of an insecure delegation, this would be actively
> harmful.   If it's published with the secure denial of existence, it would
> probably improve the state of the art.
>
> Unfortunately I don't think that calls for adoption really give us a basis
> for stating such preferences.   But that's basically where I land on this.
>  I would be perfectly happy to support this document if it does the right
> thing, but I'm dead set against it if it doesn't.   I am of course willing
> to participate in working on the document if adopted—I've already sent some
> text, and am grateful to the author for having for the most part accepted
> my proposed changes.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Sep 2017 10:35:47 -0400

On Sep 6, 2017, at 10:33 AM, tjw ietf <[email-masked]> 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 willing—he'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.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Sep 2017 10:45:27 -0400

I am strongly in support of the WG adopting this draft.  It will allow
applications to deliver a better developer experience and higher security.

As Ted notes, there is a possibility of breakage.  If something on a host
is relying on an external resolver to provide localhost resolution in
accordance with RFC 6761.  However, that behavior is almost certainly not
secure to start with, so this breakage is of the good, "increasing
security" kind.

--Richard

On Wed, Sep 6, 2017 at 10:35 AM, Ted Lemon <[email-masked]> wrote:

> The question I really have is not whether Mike is willing—he'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.
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 6 Sep 2017 16:55:21 +0100

Ted Lemon <[email-masked]> wrote:
>
> 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

I was looking at query traffic recently to prepare for deleting localhost
entries from our main zone
(http://news.uis.cam.ac.uk/articles/2017/09/01/deleting-localhost-entries-from-the-cam-ac-uk-dns-zone)

It was reassuring to see there were very few leaked localhost queries,
whether bare or with the search path appended. So it seems that stub
resolvers are successfully sinking localhost queries as they should.

I have configured the resolvers I run pedantically to include the empty
zones that aren't built-in to BIND, including localhost. So my setup is a
lot more RFC 6761 than the default. (But I'll happily delete most of it
when the cheese shop reaches production.)

Based on the low volume of localhost query traffic and the lack of
RFC 6761 conformance in at least one common recursive server, I think the
change from positive to negative responses will only affect a tiny
number of things that are already buggy.

A related thing that needs to be covered is the reverse DNS for 127.0.0.1
and ::1 - pedants like me have configured PTR records for those addresses,
which become useless when the forward domain goes away (if they aren't
useless already). BIND returns a built-in NXDOMAIN for them by default
which is justified by RFC 5735 though that spec doesn't mention the DNS.

Perhaps let-localhost-be-localhost should explicitly require reverse DNS
behaviour to match the forward DNS, i.e. positive answers generated in
stubs and NXDOMAIN from recursive servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: West 4 or 5, decreasing 3 for a time, backing southwest 5 or 6
later. Slight or moderate. Showers later. Good.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 6 Sep 2017 13:12:02 -0400

On Wed, Sep 6, 2017 at 10:35 AM, Ted Lemon <[email-masked]> wrote:
> 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

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

-- 
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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 6 Sep 2017 11:03:51 -0700

I support adopting this draft.

On 09/06/2017 07:00 AM, tjw ietf wrote:
> When the idea of having a Call for Adoption for this document came up,
> we thought long and hard about this one.  However, the comments from
> the working group focused this document to address the specific issue
> of the local hostname.     
>
> This starts a formal Call for Adoption
> for draft-west-let-localhost-be-localhost
>
> Please review this draft to see if you think it is suitable for
> adoption by DNSOP, and comments to the list, clearly stating your view.  
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Sep 2017 14:16:59 +1000

In message <CAHw9_iKBDY9hNThOY3GDeG7BbCkc8Ncy1T=rjpcQ=h5qdB7=[email-masked]>
, Warren Kumari writes:

> > The question I really have is not whether Mike is willinghe's stated
> that
> NXDOMAIN

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Sep 2017 00:42:09 -0400

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?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Sep 2017 14:59:34 +1000

> 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

> --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:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</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=
> [email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt; &gt; On Sep 6, 2017, at 10:33 AM, tjw ietf &lt;<a href=3D"mailto:tjw.i=
> [email-masked]">[email-masked]</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:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</a><br>
> </blockquote></div></div>
> 
> --089e0826f99c5cfff90558921502--

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Sep 2017 09:23:29 -0400

> tools.  Lookups should "just work" like they did before the root

Because...?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Sep 2017 10:05:59 +1000

> > tools.  Lookups should "just work" like they did before the root

Because there are things you can do with localhost as a DNS zone
that you can't do with /etc/hosts, NIS, etc. as they are limited
to addresses only.

Localhost should work just like home.arpa.  The tools we use shouldn't
need special knowledge.  Special knowledge means EVERYTHING needs
to be tested to see if it works with localhost as well and regular
names.  That testing will get missed.  If it doesn't get missed it
costs more money.  Workarounds for different behavior increases the
probability of bugs being introduced as there will be seperate code
paths.

If I want to add a local trust anchor for localhost I will then
need additional code to disable the workaround for the fact the
root doesn't have a insecure delegation.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Sep 2017 22:17:42 -0400

The discussion had covered the failure mode problem. There is substantial
agreement that it's better for a stub that issues a query for localhost to
fail than to succeed. You seem to disagree.

You haven't stated a reason for disagreeing—instead you've vigorously
asserted that this is true. It's fine for you to do this, but if you were
to get your way, that would be exactly the bad outcome I want to avoid.

So if there really is a problem here, it would be good for you to make it
clear. Your stated desire to preserve flexibility makes sense to me, but it
doesn't contradict the reason already given for *not *providing that
flexibility.

Is there some *other* reason why this is important to you, or is that it?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Sep 2017 12:27:47 +1000

> fail than to succeed. You seem to disagree.

There are lots of people that don't want to deal with ICANN politics
and that is clouding their technical judgements.

> to get your way, that would be exactly the bad outcome I want to avoid.

So you want to break EVERY protocol that uses SRV to localhost.  I
stated clearly that there is stuff that you can do with DNS that
you can't do with /etc/hosts, NIS, etc.  One shouldn't have to
itemise everything that will be broken because full functionality
is not being provided.

> --94eb2c05f4ca9dd1520558a42ee2
> <div dir=3D"auto">The discussion had covered the failure mode problem. Ther=
> e is substantial agreement that it&#39;s better for a stub that issues a qu=
> ery for localhost to fail than to succeed. You seem to disagree.<div dir=3D=
> "auto"><br></div><div dir=3D"auto">You haven&#39;t stated a reason for disa=
> greeing=E2=80=94instead you&#39;ve vigorously asserted that this is true. I=
> t&#39;s fine for you to do this, but if you were to get your way, that woul=
> d be exactly the bad outcome I want to avoid.=C2=A0</div><div dir=3D"auto">=
> <br></div><div dir=3D"auto">So if there really is a problem here, it would =
> be good for you to make it clear. Your stated desire to preserve flexibilit=
> y makes sense to me, but it doesn&#39;t contradict the reason already given=
>  for <i>not </i>providing that flexibility.=C2=A0</div><div dir=3D"auto"><b=
> r></div><div dir=3D"auto">Is there some <i>other</i> reason why this is imp=
> ortant to you, or is that it?</div></div><div class=3D"gmail_extra"><br><di=
> v class=3D"gmail_quote">On Sep 7, 2017 8:06 PM, &quot;Mark Andrews&quot; &l=
> t;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br type=3D"=
> attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
> order-left:1px #ccc solid;padding-left:1ex"><br>
> In message &lt;<a href=3D"mailto:BFAECDAF-8F4B-4C8D-AB7E-1615BD54EF93@fugue=
> .com">BFAECDAF-8F4B-4C8D-AB7E-<wbr>[email-masked]</a>&gt;, Ted Lemo=
> n writes:<br>
> &gt;<br>
> &gt; On Sep 7, 2017, at 12:59 AM, Mark Andrews &lt;<a href=3D"mailto:marka@=
> isc.org">[email-masked]</a>&gt; wrote:<br>
> &gt; &gt; I shouldn&#39;t BE FORCED to hard code special LOCALHOST rules in=
> to DNS<br>
> &gt; &gt; tools.=C2=A0 Lookups should &quot;just work&quot; like they did b=
> efore the root<br>
> &gt; &gt; zone was signed.<br>
> &gt;<br>
> &gt; Because...?<br>
> <br>
> Because there are things you can do with localhost as a DNS zone<br>
> that you can&#39;t do with /etc/hosts, NIS, etc. as they are limited<br>
> to addresses only.<br>
> <br>
> Localhost should work just like home.arpa.=C2=A0 The tools we use shouldn&#=
> 39;t<br>
> need special knowledge.=C2=A0 Special knowledge means EVERYTHING needs<br>
> to be tested to see if it works with localhost as well and regular<br>
> names.=C2=A0 That testing will get missed.=C2=A0 If it doesn&#39;t get miss=
> ed it<br>
> costs more money.=C2=A0 Workarounds for different behavior increases the<br=
> >
> probability of bugs being introduced as there will be seperate code<br>
> paths.<br>
> <br>
> If I want to add a local trust anchor for localhost I will then<br>
> need additional code to disable the workaround for the fact the<br>
> root doesn&#39;t have a insecure delegation.<br>
> <br>
> Mark<br>
> --<br>
> Mark Andrews, ISC<br>
> --94eb2c05f4ca9dd1520558a42ee2--

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Sep 2017 08:07:30 -0400

Do you know of protocols that use SRV to localhost in practice?

Anyway, this is like the question of whether to trust IP addresses when
using rsh. Remember rsh?  There's a reason we don't use it anymore, even
though it was definitely useful.

Localhost over DNS is analogous.

---

From: "John Levine" <[email-masked]>
Date: 11 Sep 2017 01:35:10 -0000

>tools.  Lookups should "just work" like they did before the root

It seems to me that if someone has enough programming skill to write a
DNSSEC verifier for her cache or stub resolver, she has enough skill
to treat localhost as a special case.

Or she could use unbound which has done this for ages.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Mon, 11 Sep 2017 10:07:12 -0400

> fail than to succeed. You seem to disagree.

I wonder if this is simply people talking past each other, and a lack
of agreement on what the behavior we actually want is.
When I first read the document, and at the beginning of this thread I
firmly believed that we would want an insecure delegation from the
root, but after more discussion on what we want the behavior of
'localhost' to be I've been convinced otherwise.

I think that this boils down to: It is an error to send a query for
localhost (or anything under localhost) to the DNS. The main reason
for this (at least from my reading of the thread) is a security
argument -- you want to be completely sure that 'localhost' will
always be 127.0.0.1 / ::1 / some local equivalent, and this is not a
guarantee we can expect from the DNS[0]. Because of this it is better
the have queries that accidentally *do* leak into the DNS get a
failure (NXDOMAIN) - this avoids having (security important) cases
work fine until there is an attacker.

Is this a reasonable summary? Perhaps once we agree if *is* the
behavior we want we'll have an easier time deciding exactly how...

W
[0]: Without at least DNSSEC, everyone validating, and a trusted
entity running a localhost zone.

> asserted that this is true. It's fine for you to do this, but if you were to
> get your way, that would be exactly the bad outcome I want to avoid.
>
> doesn't contradict the reason already given for not providing that
> flexibility.
>
> Is there some other reason why this is important to you, or is that it?
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 11 Sep 2017 11:37:45 -0700

At Wed, 6 Sep 2017 10:00:01 -0400,

> DNSOP, and comments to the list, clearly stating your view.

I've read draft-west-let-localhost-be-localhost-06.txt.  I don't have
a strong opinion on whether to adopt it, but if it's adopted I'm
willing to review subsequent versions.

I have one high-level comment: I wonder whether the name can be
different from "localhost".  My impression on some of the controversy
on this proposal is related to compatibility with the existing
practice with this name (e.g., some people may want to have their
preferred AAAA or A RDATA at their own risk).  If it can be a
completely new TLD we at least don't have to worry about that type of
conflict.  Of course this will require more procedural overhead such
as new registration for the special-use registry and doesn't help
any existing practice that assumes 'localhost' always means a
loopback address.  But such a practice is not 100% safe today anyway
(and in my understanding that's why this draft was written) and even
if the proposed new semantics for 'localhost' is standardized its
deployment will take time (and I suspect non-compliant behavior will
stay quite long).  So it might be even safer to introduce a new name
and have applications that need this property gradually migrate to it.

It's just a thought, I'm not pushing the idea.  But in any case, it
may be worth explaining in the draft why the name must be 'localhost'.

I have a couple of other minor comments on the current version.  All
of them are somehow related to how authoritative servers are supposed
to behave in the context of this draft:

- Section 1

   In addition, recursive and authoritative DNS servers are required to
   return "NXDOMAIN" for such queries.  This increases the likelihood

  Should authoritative servers other than the root server really be
  required to return NXDOMAIN?  Except for the root server, if an
  authoritative server receives a query for a name that doesn't belong
  to any zone it serves, it's generally considered a (some sense of)
  bogus query, and my understanding of common response to this kind of
  query is either REFUSED or a referral to the closest ancestor zone
  known to the server.  I don't see a reason for changing the behavior
  of these servers specifically for 'localhost'.

- Section 3

   5.  Authoritative DNS servers MUST respond to queries for localhost
       names with NXDOMAIN.

  Same comment applies.

- Section 4.2.1

   This document requests that a DNSSEC insecure delegation (that is, a
   delegation with no DS records) be inserted into the root-zone,
   delegated to "blackhole-[12].iana.org".

  This would violate the above 'MUST'.  If we choose this option (and
  if we also generally keep this MUST) some more clarification (such
  as making an exception) will be needed.

--
JINMEI, Tatuya

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 11 Sep 2017 22:21:16 -0700

> to treat localhost as a special case.

I've been trying to figure out for a few days now how to insert my
opinion.  It's kinda like the above but not.  Specifically, we have
multiple naming systems already, and I'd argue that localhost actually
isn't in the DNS naming system.  There is no authoritative source for
it.  In fact, DNSSEC proves this.

Instead, localhost is a operating system convention, a /etc/hosts name,
an NIS name, or one of the other things that is able to resolve that
name.  But the DNS is not where that resolution comes from.

Now, how do we ensure that a conflict never happens?  That's a better
discussion and there are a few options ranging from policy to ensure
it's never assigned, to actually registering it, to...
-- 
Wes Hardaker
USC/ISI

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Sep 2017 11:41:28 +0100

Wes Hardaker <[email-masked]> wrote:
>
> Specifically, we have multiple naming systems already, and I'd argue
> that localhost actually isn't in the DNS naming system.  There is no
> authoritative source for it.  In fact, DNSSEC proves this.
>

I think this makes sense, but it isn't the whole story. From my brief look
at a small amount of traffic, localhost queries are basically all handled
inside the stub, so it is de facto as you describe. But it has long been
the case that DNS servers are also supposed to handle localhost, e.g.

RFC 1537 section 10
RFC 1912 section 4.1
RFC 2606 section 2
RFC 6761 section 6.3

However, implementations differ - BIND requires explicit configuration,
Unbound handles localhost by default.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire, Forties, Cromarty, Forth: Westerly 5 or 6, becoming variable 3
or 4, then northerly or northeasterly 5 or 6, occasionally 7 in Forties.
Moderate occasionally rough in Forties. Rain. Good occasionally poor.

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 12 Sep 2017 16:06:51 +0200

Hello,

On 6 Sep 2017, at 16:00, tjw ietf wrote:

> we

I support adoption of this draft.

I would also like to take this opportunity to codify a related best 
operational practice. As Tony Finch mentioned elsewhere in the thread 
(linking to 
http://news.uis.cam.ac.uk/articles/2017/09/01/deleting-localhost-entries-from-the-cam-ac-uk-dns-zone), 
having a localhost entry in any zone file is an insecure practice.

Since we are doing a draft/RFC on what localhost is and is not, I 
suggest we put some text in there banning (MUST NOT) the practice of 
having localhost entries (at least those pointing to 127.0.0.1/::1?) in 
auth zones. If there is agreement on this I am happy to contribute text. 
This may mean having to say we are updating RFC 1912.

I am happy to review in any case.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Sep 2017 08:04:17 -0700

Tony Finch wrote:
> Wes Hardaker<[email-masked]>  wrote:

while i've generally included a localhost.$ORIGIN A RR in zones that 
appear in my stub resolver search lists, in order that "localhost" be 
found, i believe that the host name lookup library which calls and/or 
depends upon, among other things, a DNS stub resolver, ought to handle 
the "localhost" convention. and indeed, most of these lookup libraries 
have a concept similar to "/etc/hosts" today, where "localhost" lives.

no standards-track RFC currently requires that "localhost" return NXD, 
to make explicit that it's the host name lookup library "SHOULD", and 
that the DNS "SHOULD NOT", handle this name to address translation. we 
didn't used to standardized behaviour that was not seen "on the wire" 
simply because interoperability testing would be hard to imagine. and i 
don't imagine i'll have my "localhost.$ORIGIN" RR's out of any zones.

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Sep 2017 16:54:25 +0100

Paul Vixie <[email-masked]> wrote:
>
> while i've generally included a localhost.$ORIGIN A RR in zones that appear in
> my stub resolver search lists, in order that "localhost" be found,

I agree with the rest of your message but I want to highlight this bit
because it is directly related to the main reason this draft exists.

Your localhost records (like the ones I deleted from cam.ac.uk last week)
are troublesome for the web browser same origin security policy: they can
lead to vulnerabilites when your websites are accessed from multi-user
machines and in other more obscure circumstances - for details, see
http://seclists.org/bugtraq/2008/Jan/270

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Tyne, Dogger: Westerly backing southeastrly 4 or 5, occasionally 6 at first,
then becoming cyclonic, mainly northwesterly later, 6 to gale 8, occasionally
severe gale 9 later in south. Moderate or rough, occasionally very rough later
in south. Rain. Good occasionally poor.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Sep 2017 10:04:43 -0700

On Tue, Sep 12, 2017 at 8:54 AM, Tony Finch <[email-masked]> wrote:

> appear in

Cf.
https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00#section-4.1

When something shouldn't work, it shouldn't work.

--Richard

---

From: "John R Levine" <[email-masked]>
Date: 12 Sep 2017 13:11:32 -0400

> When something shouldn't work, it shouldn't work.

I agree but this is a tangent.  The draft is about localhost. or maybe 
<something>.localhost.  It's not about localhost.<something>.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Joe Abley <[email-masked]>
Date: Tue, 12 Sep 2017 15:08:33 -0400

On 12 Sep 2017, at 13:11, John R Levine <[email-masked]> wrote:

> I agree but this is a tangent.  The draft is about localhost. or maybe <something>.localhost.  It's not about localhost.<something>.

The problem with this clarification is that in practice "localhost." is almost always spelt "localhost".

Joe

---

From: "John R Levine" <[email-masked]>
Date: 12 Sep 2017 15:40:35 -0400

> The problem with this clarification is that in practice "localhost." is almost always spelt "localhost".

Well, OK, but I hope we can limit the advice to tne meaning of localhost 
as a TLD-ish name, and not rehash the well known problems with search 
lists.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Sep 2017 06:30:53 +1000

In message <[email-masked]>, "John R Levine" writes:
> >> I agree but this is a tangent.  The draft is about localhost. or maybe <so
> mething>.localhost.  It's not about localhost.<something>.
> >

Unfortunately they are all related.  "localhost" as a single label
gets the search list applied, then is tried as is.  "_foo._tcp.localhost"
as a multi-label string gets tried as is then the search list is
applied.  localhost is the one pre-hierachical hostname that we still
use.  Other single label hostnames are intended to be short cuts to
a heirachical hostnames.

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2017 22:17:38 -0000

>behavior we want we'll have an easier time deciding exactly how...

Sounds right to me.

With respect to Tim's suggestion that we invent
localhost-we-really-mean-it-this-time, the existing localhost isn't
going away, and it is my impression that more often than not software
already does what this draft suggests.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Sep 2017 15:42:24 -0700

Tony Finch wrote:
> Paul Vixie<[email-masked]>  wrote:
> > ...

huh. this web thing really wasn't any better thought out than this 
internet thing, was it? (same-origin, as a security policy, reeks of 
n00bism, even without this localhost defect.)

thanks for the heads-up. maybe i will delete it after all.

-- 
P Vixie

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2017 02:15:29 -0000

>This may mean having to say we are updating RFC 1912.

Believe it or not, there are real non-loopback localhost domain names,
like localhost.reddit.com.

I agree that localhost.<foo> pointing to loopback is generally asking
for trouble, but I am not at this point sufficiently confident that it
is never ever a good idea to say MUST NOT rather than SHOULD NOT.  I
can for example imagine ways that might make some kinds of debugging
easier.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Sep 2017 22:45:26 -0400

On Sep 12, 2017, at 10:15 PM, John Levine <[email-masked]> wrote:
> like localhost.reddit.com <http://localhost.reddit.com/>.
> 

When we look at edge cases like this, it's tempting to be swept away by the futility of trying to close every gap.   But it's still worth closing the ones we can close.   Trying to outlaw localhost.* is hopeless.  But outlawing *.localhost is certainly valid and viable, and as DNSSEC adoption increases, more and more it will be the case that we actually need do nothing to break it.   "localhost" + search list still fails unsafe.

This is just another reason to outlaw search lists.   I can't think what use case search lists address that's worth the security vulnerability they create.   The fact that hosts routinely use search lists provided by DHCP is something that just astonishes me, but even user-configured search lists serve no useful purpose to anyone but the statistically negligible set of geeks who actually type in domain names and yet haven't become paranoid enough to realize that search lists are bad yet.   There is no downside to deprecating them.

(Should someone reading this be one of those network operators who still puts search lists to some use inside of their firewall, please do not tell us about it.   I do not want to be the cause of your users being hacked.)

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Sep 2017 13:06:45 +1000

In message <[email-masked]>, Ted Lemon writes:
> When we look at edge cases like this, it's tempting to be swept away by
> the futility of trying to close every gap.   But it's still worth closing
> the ones we can close.   Trying to outlaw localhost.* is hopeless.  But
> outlawing *.localhost is certainly valid and viable, and as DNSSEC
> adoption increases, more and more it will be the case that we actually
> need do nothing to break it.   "localhost" + search list still fails
> unsafe.

Why would we want to outlaw *.localhost?  Just because it is
inconvient for the IAB and ICANN that they didn't address this issue
correctly years ago.

Oh sorry you can't use SRV with localhost to assign a port to this
protocol THAT HAS NO DEFAULT PORT and only a NAME.  Is this what you
REALLY want to do?

> This is just another reason to outlaw search lists.   I can't think what
> use case search lists address that's worth the security vulnerability
> they create.   The fact that hosts routinely use search lists provided by
> DHCP is something that just astonishes me, but even user-configured
> search lists serve no useful purpose to anyone but the statistically
> negligible set of geeks who actually type in domain names and yet haven't
> become paranoid enough to realize that search lists are bad yet.   There
> is no downside to deprecating them.
>
> (Should someone reading this be one of those network operators who still
> puts search lists to some use inside of their firewall, please do not
> tell us about it.   I do not want to be the cause of your users being
> hacked.)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Sep 2017 23:14:06 -0400

> protocol THAT HAS NO DEFAULT PORT and only a NAME.  Is this what you

Yes.

---

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 13 Sep 2017 10:20:45 +0200

Hello John,

> like localhost.reddit.com.

That’s why I had (at least ..) in there. Non-loopback localhost names 
are not a problem, unless, perhaps via search lists, they confuse 
browsers into wrong trust levels.

> can for example imagine ways that might make some kinds of debugging

I would settle for SHOULD NOT. Can you elaborate on the debugging?

Kind regards,

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2017 16:33:55 -0000

>I would settle for SHOULD NOT. Can you elaborate on the debugging?

There is something strange going on with my remote server, and I use
localhost.mydomain so a little debugging server on my own computer
can steal state and see whats going on.

On the other hand, I could do this just as well:

gazornplotz.mydomain IN A 127.0.0.1

so never mind.  Still not sure I haven't missed something, though.

R's,
John

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 13 Sep 2017 09:46:49 -0700

On 12 September 2017 at 20:14, Ted Lemon <[email-masked]> wrote:

> I thought the goal was to ensure that localhost names map to loopback.

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2017 17:19:15 -0000

>inconvient for the IAB and ICANN that they didn't address this issue

I concur with Mark that while localhost.<foo> is a problem,
<foo>.localhost is not.  I've occasionally used that hack to pass
traffice to various servers running on 127/8 addresses other than
127.0.0.1.

R's,
John

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 Sep 2017 10:36:02 -0700

Tony Finch <[email-masked]> writes:

> From my brief look at a small amount of traffic, localhost queries are
> basically all handled inside the stub, so it is de facto as you
> describe.

Just as an FYI data point:  On April 12th (a DITL day) B-root received
just shy of a million packets with ^localhost$ as the query name, which
amounted to .018% of the total traffic.
-- 
Wes Hardaker
USC/ISI

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Sep 2017 19:43:23 -0400

> I thought the goal was to ensure that localhost names map to loopback.   

No.  If that were the goal, we might well be proposing using DNS to provide that information.   The goal is to make localhost less of an attack surface.   At least that's _my_ goal!   :)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Sep 2017 19:45:32 -0400

> traffice to various servers running on 127/8 addresses other than

So we should expose end-users to attack because it's "occasionally" convenient for you to do this hack?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Sep 2017 10:54:46 +1000

In message <[email-masked]>, Ted Lemon writes:
> So we should expose end-users to attack because it's "occasionally" =
> convenient for you to do this hack?

The biggest problem is that HTTP says that hostnames in URLs may
be relative.  Close that grand canyon sized security hole.  There
is zero need for relative names in URL's in html documents, email
etc.  There is some need for them in address bars but that is UI.
What goes over the wire should be treated as absolute, always.

Treat "localhost" as always being absolute.  No searching if that
is the entered hostname.  Yes, this will break somethings that
depend on searching to find localhost.*.  It is the one hangover
from the flat global namespace we still have.

Have public DNS return unsigned NODATA for localhost (qtype != SOA,
NS, DS) and signed NODATA for localhost DS.

getaddrinfo() et al. is still free to hardcode localhost -> (::1,
127.0.0.1) if the implementation wants to.  Make it a requirement
for *browsers* (includes curl, fetch, lynx etc.) to do this if you
want.

Recommend that recursive servers have a "localhost." zone with ::1
and 127.0.0.1 for "localhost." built in by default.

You don't need to sabatage the DNS.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Sep 2017 21:04:58 -0400

You've made your position clear, thanks.

---

From: Lanlan Pan <[email-masked]>
Date: Thu, 14 Sep 2017 03:47:45 +0000

no only localhost.example.com : http://seclists.org/bugtraq/2008/Jan/270
if xxx.example.com is NXDOMAIN , there is similar risk cause by the
"nxdomain redirect" recursive dns (they return a hijack A RR ).
CA SSO (siteminder)  may be a solution.

localhost.  seems a new special-use TLD, like arpa. , local.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 14 Sep 2017 14:03:29 +0200

Hi John,

> so never mind.  Still not sure I haven't missed something, though.

But now (with either name) you are exposing users of your server to the 
exact problems described in http://seclists.org/bugtraq/2008/Jan/270. 
Why not use /etc/hosts instead, so you only expose yourself?

Kind regards,

---

From: Wendy Seltzer <[email-masked]>
Date: Wed, 20 Sep 2017 23:44:33 -0400

>From a W3C perspective, and for the further specification of components
of the web security model, it would be helpful to have this behavior of
the loopback interface specified.

I support adoption and will be willing to review text.

Thanks,
--Wendy

-- 
Wendy Seltzer -- [email-masked] +1.617.715.4883 (office)
Strategy Lead, World Wide Web Consortium (W3C)
https://wendy.seltzer.org/        +1.617.863.0613 (mobile)