Subject: [DNSOP] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP

From: Dan York <[email-masked]>
Date: Thu, 17 Nov 2016 03:00:16 +0000

DNSOP,

In SUNSET4 right now, Emily Stark from Google presented a draft from Mike West (also Google) asking to update the language in RFC 6761 around the resolution of localhost:

Draft: https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-02

Slides: https://www.ietf.org/archive/id/draft-west-let-localhost-be-localhost-02.txt

It was brought to SUNSET4 because they are interested in stopping the proliferation of IPv4 addresses.

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 17 Nov 2016 12:07:02 +0900

On 17 November 2016 at 12:00, Dan York <[email-masked]> wrote:

> DNSOP,
>
> In SUNSET4 right now, Emily Stark from Google presented a draft from Mike
> West (also Google) asking to update the language in RFC 6761 around the
> resolution of localhost:
>

This sounds like something we should consider adopting in DNSOP.

> [email-masked]   +1-802-735-1624
> Jabber: [email-masked]
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 12:46:15 +0900

Just to play the devil's advocate here, what does this have to do with DNS?

On Thu, Nov 17, 2016 at 12:07 PM, Matthew Pounsett <[email-masked]> wrote:
>> Draft:
>> https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-02
>>
>> Slides:
>> https://www.ietf.org/archive/id/draft-west-let-localhost-be-localhost-02.txt
>>

---

From: Dan York <[email-masked]>
Date: Thu, 17 Nov 2016 04:04:02 +0000

Ted,

> On Nov 17, 2016, at 12:46 PM, Ted Lemon <[email-masked]> wrote:
> 

>From the abstract:

   This document updates RFC6761 by requiring that the domain
   "localhost." and any names falling within ".localhost." resolve to
   loopback addresses.  This would allow other specifications to join
   regular users in drawing the common-sense conclusions that
   "localhost" means "localhost", and doesn't resolve to somewhere else
   on the network.

It's an update to RFC 6761 and all about resolution of "localhost".

To me that seems like a DNS issue... and since we already have a heap of open issues with 6761, this would seem to be one more thing to consider.

I should mention that Terry Manderson (INT AD) and Joel Jaeggli (OPS AD) were both in the SUNSET4 room and agreed they would have a discussion about which WG this document should live in. Both agreed that DNSOP should at least definitely look at it.

Peter Koch and I both recommended from the mic that it be brought to DNSOP (which I guess I then did by posting it here).

Peter also mentioned that there was a long history with the resolution around "localhost" and that this topic had been discussed at length multiple times. (I took it that he was not saying it should NOT be brought up again, but rather that the authors should be aware that it had a good bit of history.)

Dan

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 13:19:28 +0900

The reason I ask is that the document proposes /not/ to use DNS to resolve
it, which I think is correct. So it really doesn't sound like a dnsop
issue. It's sounds like an intarea issue, or else keep it in sunset4.

Additionally, the root zone will respond to queries for localhost with a
secure denial of existence.   This means that it is literally an error to
look up "localhost" with DNS--you will get a failure instead of an IPv4 or
IPv6 address.   I don't see any particular harm in having this reviewed in
DNSOP, but I hope it doesn't take too long.

On Nov 17, 2016 13:04, "Dan York" <[email-masked]> wrote:

> To me that seems like a DNS issue... and since we already have a heap of
> open issues with 6761, this would seem to be one more thing to consider.
>
> I should mention that Terry Manderson (INT AD) and Joel Jaeggli (OPS AD)
> were both in the SUNSET4 room and agreed they would have a discussion about
> which WG this document should live in. Both agreed that DNSOP should at
> least definitely look at it.
>
> Peter Koch and I both recommended from the mic that it be brought to DNSOP
> (which I guess I then did by posting it here).
>
> Peter also mentioned that there was a long history with the resolution
> around "localhost" and that this topic had been discussed at length
> multiple times. (I took it that he was not saying it should NOT be brought
> up again, but rather that the authors should be aware that it had a good
> bit of history.)
>
> Dan
>
>
>
>
>

---

From: Shane Kerr <[email-masked]>
Date: Thu, 17 Nov 2016 13:06:01 +0800

Ted,

Isn't this more-or-less the same as .ONION then? We're searching for a
label-based switch to disable DNS?

An alternate interpretation would be that this is something that could
be added to RFC 6303, "Locally Served DNS Zones". While that RFC is
only about reverse DNS now, one could step back a bit and squint and
think that maybe localhost is similar. :)

Cheers,

--
Shane

At 2016-11-17 13:19:28 +0900

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 14:23:18 +0900

RFC 6303 doesn't help, because locally-served zones are all under
.arpa, and hence can have secure delegations.   It is analogous to
.ONION, yes.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Nov 2016 00:33:41 -0500

> issue. It's sounds like an intarea issue, or else keep it in sunset4.

Perhaps changing a 30-ish year old DNS convention that has running
code basically on every computer in the known universe is something
that people with DNS operations experience might have some insight
about.  (Which is not to say they're wrong.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 14:40:32 +0900

Sure.   We could also ask the IAB--there's a ton of expertise on the IAB.   :)

However, in fact it's an accident of slow deployment of DNSSEC
validators that this has worked for thirty years, which would suggest
that that experience isn't going to help that much.

That said, I really was just being a devil's advocate.   It's fine
with me that DNSOP is being asked to review it.   I just thought it
was a bit ironic.

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 17 Nov 2016 01:03:30 -0500

Hi,

I wasn’t aware of this draft and will have to take a look at it, but note that the DNSOP charter includes:

6. Publish documents that attempt to better define the overlapping
area among the public DNS root, DNS-like names as used in local
or restricted naming scopes, and the 'special names' registry
that IETF manages, perhaps including how they might interact.
This work must take into consideration issues that are strictly
beyond the operation of the DNS itself, and the working group
will consult with IETF liaisons to other organizations as
appropriate.

Having Terry and Joel discuss sounds about right to me, and we’re happy to review the draft as appropriate.

Suzanne

> On Nov 16, 2016, at 11:04 PM, Dan York <[email-masked]> wrote:
> 
> Ted,
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 17 Nov 2016 15:25:10 +0900

This may seem a little strange, contrarian even, given how implacably
opposed to new things in this space pending some sanity, but I am
actually, broadly speaking, in favour of defining the world as it is,
regarding localhost.

If somebody seeks to invent something new, that is a discussion of its
own merits. but if we are saying the IETF has a long standing practice
of believing what localhost is, and we should account for that state,
I would be very happy.

It feels to me like state of .arpa, substates of .arpa (not all the
dots are zonecuts), state of localhost, lie in a space which *is*
about the IETF, and what we think we have definitional behaviour in
regarding the DNS and names-to-addresses

I don't entirely feel the same about ipv4only.arpa but since its off
the root, its less significant for me.

-g

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Nov 2016 08:52:07 +1100

As I said on the sunset4 mailing list this goes too far.

I don't know about you but I want to be able to lookup TLSA records,
SRV and other records types for foo.localhost and localhost.

And by the way this also requires a insecure delegation in the root
zone for DNSSEC to work with validating client.

This isn't a good idea.

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: Fri, 18 Nov 2016 07:14:36 +0900

Which do you want?   TLSA, or delegation?  You can't have both.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Nov 2016 07:16:13 +0900

(Actually, I think you can't have either!)

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Nov 2016 13:20:17 +1100

>From a technical perspective a insecure delegation for .localhost
back to the root servers to break the DNSSEC chain of trust.  You
can then populate a local .localhost how ever you see fit and have
the answers validate as secure / insecure depending on whether the
validator has a trust anchor for .localhost.

As for the rest, we should not inflict the broken security model
used here on every other use of domain names in this namespace.  It
does not belong to just one service.  It the web want a namespace
that is has these properties it can request one.  It shouldn't
highjack an existing space.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Sun, 20 Nov 2016 21:27:02 -0500

The point is that the current policy for the root precludes an
unsecure delegation.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Nov 2016 13:39:34 +1100

> The point is that the current policy for the root precludes an
 
Please quote the relevent documents that preclude this.  From
all I've seen this is a open issue.

Mark

---

From: Matt Larson <[email-masked]>
Date: Mon, 21 Nov 2016 10:31:12 -0500

> On Nov 20, 2016, at 9:27 PM, Ted Lemon <[email-masked]> wrote:
> 

Huh?  If by "insecure delegation" you mean "no DS record", then are are plenty such delegations right now:

$ comm -23 tlds tlds_with_ds | wc -l
     161

If you're referring to a policy for new delegations, there is indeed a requirement for the "Class of 2012" gTLDs that they be secure, i.e., have DS records.  So it happens that all recent new TLDs in the root have been secure delegations, but it doesn't follow that every new delegation has to be a secure one.  That's an issue we (the community) would have to decide upon and document in whatever document governed adding a hypothetical new TLD with an insecure delegation.

Personally, I think we'd better have a really good reason for adding a new TLD without a requirement for DNSSEC.  I further think that adding an insecure delegation in the root for localhost to permit DNSSEC validation of local names like foo.localhost is bad, because I think doing anything to encourage names like foo.localhost is a very bad idea.  When I see localhost in whatever context, I think 127.0.0.1 and ::1.  Any other answer would cause astonishment.

Matt

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Nov 2016 10:36:05 -0500

> Personally, I think we'd better have a really good reason for adding a new TLD without a requirement for DNSSEC.  I further think that adding an insecure delegation in the root for localhost to per…

Thanks, Matt.   I agree completely about subdomains of localhost, FWIW.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Nov 2016 10:39:25 -0500

On Mon, Nov 21, 2016 at 10:31:12AM -0500, Matt Larson wrote:

>  That's an issue we (the community) would have to decide upon and document in whatever document governed adding a hypothetical new TLD with an insecure delegation.
>

If by "we (the community)" you mean "the names community", then I
agree.  That's the main point I've been trying to make: the decisions
about what to put _in the root zone_ (which includes delegation data
of special-use names) is, as near as I can tell, entirely on ICANN's
turf.  (I don't think the creation of special-use names at the root of
the namespace _is_ entirely on their turf, but actual data in the root
zone is quite different.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Mon, 21 Nov 2016 15:50:08 +0000

> zone is quite different.)

It is different, but it does appear to be required if we ever want
functional DNSSEC validation of any special-use domain name that were to
exist at the root of the namespace.

Specifically, the main issue is that "normal" DNS servers will treat the
current signed DNSSEC proof of non-existence of such a name as
definitive (because of top-down validation rules) making it impossible
to use the name.

As has been mentioned before, there's (currently) no process for this,
but that doesn't mean we can't ask.  The lack of process doesn't mean
it's impossible.

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Nov 2016 12:16:41 -0500

> but that doesn't mean we can't ask.  The lack of process doesn't mean

No question.  As long as we recognise that we're asking another
community for them to do something following their processes, I have
no problem with it.  But it's clearly outside IETF change control.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 21 Nov 2016 18:06:41 -0000

>Huh?  If by "insecure delegation" you mean "no DS record", then are are plenty such delegations right now:

No, I think the point is that you want the equivalent of an NSEC3
opt-out, but the root is currently signed with NSEC.

Having said that, I don't see why this name is any different from
other special names.  If you want your cache to return DNS answers for
any of them, you have to add special cases.  My cache (unbound)
already does for localhost names.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2016 07:08:21 +1100

> already does for localhost names.

Well they basically aren't.  The problem is that the IETF has not
been listening when its been told that DNSSEC has to be accounted
for and plunged ahead creating names which will result in "invalid"
being returned from the validator.

If you run a validating stub resolver talking to a recursive server
which return NXDOMAIN for the special name .onion and ask for
<hash>.onion the validation of that response will be "invalid".  If
the only intent is to stop the query leaking then that is "fine".
If you want the application to see the NXDOMAIN for <hash>.onion
then there should have been a insecure delegation for .onion as
well.

What "saves" .onion is that the lookup should be being made using
TOR and any failure is good enough at the DNS level.  Doing .onion
cleanly also requires a insecure delegation.

A similar argument can be made for .local and MDNS.

.localhost and .homenet don't have the escape to a different protocol
and any error from the DNS will do for those not worried about a
clean solution.  These namespace are intended to be looked up in
the DNS with local content.

There are a whole heap of RFCs that get/got DNSSEC issue wrong.
Others have been overtaken by the deployment of DNSSEC.  I've cleaned
up some of them by getting ammending RFCs issued.

	RFC 1918 addressed in RFC 6303
	RFC 2606 (.localhost being discussed in this thread)
	RFC 6147
	RFC 6598 addressed in RFC 7793
	RFC 7686
	RFC 7788 (.home)

.localhost is one where the deployment of DNSSEC broke existing
practice.  Most people do not notice this as they are not validating
at the client level.  Search lists and localhost.<search-entry>
records also helped to hide the issue.

Mark

---

From: "John R Levine" <[email-masked]>
Date: 21 Nov 2016 15:21:27 -0500

> the DNS with local content.

Well, maybe.  On my computer, and on pretty much every computer running 
some flavor of Unix or Linux, localhost comes from /etc/hosts and never 
hits the DNS.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2016 07:55:14 +1100

In message <[email-masked]>, "John R Levine" wri
> some flavor of Unix or Linux, localhost comes from /etc/hosts and never 

"telnet foo.localhost" and look at your DNS server's logs.  I'm
willing to bet you will see a lookup for foo.localhost/A and with
high probability foo.localhost/AAAA.

"localhost" will likely be looked up in /etc/hosts after trying
every localhost.<search-list-element> in the DNS and before attempting
"localhost" in the DNS if it is missing from /etc/hosts.  This is
only for A and AAAA lookups.  Anything else which looks for something
other than A or AAAA will hit the DNS.

Mark

---

From: Shane Kerr <[email-masked]>
Date: Tue, 22 Nov 2016 11:24:21 +0800

Andrew,

At 2016-11-21 12:16:41 -0500

> no problem with it.  But it's clearly outside IETF change control.

Indeed. And clearly this idea cannot succeed in the ICANN context,
because my startup, "Local Host", will need the .localhost TLD.

We pick up where AirBNB leaves off! Not only do you get to have the
experience of visiting another city and stay in a friend's place, but
you also get the experience of them showing you around to all the
really cool things to do!!

Local Host: "Hip and cool city trips. Totally not creepy and weird."

--
Shane
CEO, CTO, CFO, President, MD, Chairman of the Board for Local Host BV

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2016 15:29:24 +1100

In message <[email-masked]>, Shane Ker
> Local Host: "Hip and cool city trips. Totally not creepy and weird."

Shane is the sarcasm really helpful here?  localhost is already out
of bounds for the gTLD processes at ICANN and you well know that.

As per the gTLD Applicant Guidebook, section 2.2.1.2.1 Reserved
Names in version 2012-01-11 [1].

Mark

[1] https://newgtlds.icann.org/en/applicants/agb/guidebook-full-11jan12-en.pdf

---

From: David Conrad <[email-masked]>
Date: Tue, 22 Nov 2016 11:08:09 -0800

> Shane is the sarcasm really helpful here?

It rarely is.

> localhost is already out of bounds for the gTLD processes at ICANN and you well know that.
> 

Sort of. The Applicants Guide Book referenced was for use with the "Class of 2012". A revised AGB will undoubtedly be prepared for the next round of new gTLDs (if one does occur), taking into account lessons learned.  I would guess it is _extremely_ likely that if the IETF were to define a list of top-level labels that were reserved for "technical uses", the ICANN community would incorporate that into the new version of the AGB. After all, if the community didn't, I suspect it'd be cause for the exercise of termination clause of RFC 2860.

Regards,
-drc
(speaking only for myself)