Subject: [DNSOP] "let-localhost-be-localhost".

From: Mike West <[email-masked]>
Date: Wed, 23 Nov 2016 13:37:33 +0100

Hello, folks who know more about DNS than I do. :) Apologies in advance for
forking the existing thread at
https://www.ietf.org/mail-archive/web/dnsop/current/msg18639.html; I
haven't been subscribed to this list, so I don't have a thread to reply to.

Emily Stark presented "let-localhost-be-localhost" to sunset4 earlier this
week. Based on some feedback received during/after that presentation, it
seems like this group might be a better home for the discussion. I've
uploaded an -03 draft of "let-localhost-be-localhost" to
https://tools.ietf.org/html/draft-west-let-localhost-be-localhost, and I'd
appreciate feedback on the general concept, as well as next steps
(including whether or not this group would be willing to adopt the
document).

Judging by the existing thread, opinions abound. I admit that I'm not
fluent enough in the intricacies of DNSSEC to judge the merits of Mark's
objection. I believe the assertion in
https://www.ietf.org/mail-archive/web/sunset4/current/msg00456.html that
more nuance is required, and I'm happy to do more work to address those
concerns, but I'll need y'all's guidance to do so. :)

Thanks!

-mike

---

From: "John R Levine" <[email-masked]>
Date: 23 Nov 2016 09:40:50 -0500

> concerns, but I'll need y'all's guidance to do so. :)

I'd say Mark's objection is reasonable but not necessarily a deal breaker. 
As he points out, the two existing special top level .local and .onion are 
supposed to be resolved without using the DNS, by mDNS and TOR 
respectively.  For .localhost, depending on the implementation it might or 
might not use the DNS, which is why DNSSEC matters.

The problem is that the DNSSEC solution here is kind of complicated. 
What you'd want is an opt-out signature in the root, showing that there 
might be an insecure delegation to .localhost, but the root is signed with 
NSEC and there's only opt-out in NSEC3.  Technically it's not complicated 
to change from NSEC to NSEC3, but any change to the way the root is 
managed is a big deal since the consequences of screwing it up are so 
large.

On the third hand, .localhost has been special forever and this draft 
essentially codifies what we've assumed all along, so if we approve it 
things are no worse and arguably better than they are now.

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

---

From: Philip Homburg <[email-masked]>
Date: Wed, 23 Nov 2016 16:27:10 +0100

>managed is a big deal since the consequences of screwing it up are so 

What if localhost is just inserted in the root as the equivalent of
localhost. IN A 127.0.0.1
localhost. IN AAAA ::1

(of course this can be done by directly inserting those entries in the root, or
by using CNAME or DNAME tricks, or even delegating localhost. to something like
as112)

I assume that anyone who wants different values for localhost can edit /etc/hosts
or use one of the many dns resolution tricks. This may break local validating
resolvers, but so what?

---

From: "John R Levine" <[email-masked]>
Date: 23 Nov 2016 11:49:28 -0500

> localhost. IN A 127.0.0.1

Most systems I know special case a plain localhost name in the resolver or 
cache.  The more interesting bits are <blah>.localhost which some of us 
resolve to other addresses in 127/8.

Putting A and AAAA records in the root is another thing that is 
technically simple but would require a rule change at IANA, and I don't 
think it's worth the hassle.

Regards,

---

From: Philip Homburg <[email-masked]>
Date: Wed, 23 Nov 2016 20:36:18 +0100

>resolve to other addresses in 127/8.

I'm not sure how having something like 'localhost. IN AAAA ::1' has
any effect on resolving <blah>localhost

I.e., today if you ask the root for <blah>.localhost you get
something like:
loans.  86400   IN      NSEC    locker. NS DS RRSIG NSEC   
loans.  86400   IN      RRSIG   NSEC 8 1 86400 [...]

proving that localhost doesn't exist. You can add a localhost zone to your
resolver, but that works only if all stub resolvers use your resolver and
you can avoid client side validation.

After adding localhost to the root zone, the only thing that would change
is that asking the root zone for <blah>.localhost now results in
localhost. 86400   IN      NSEC    locker. A AAAA
localhost. 86400   IN      RRSIG   NSEC 8 1 86400 [...]

Which still proves that <blah>.localhost doesn't exist.

I'd say, no difference for that use case.

>think it's worth the hassle.

Does the MoU between the IETF and ICANN really say no A records in the root
zone? Or is there another policy document between IETF and IANA?

---

From: "John Levine" <[email-masked]>
Date: 22 Nov 2016 23:41:35 -0000

>I'd say, no difference for that use case.

Right.  That's why it'd need NSEC3 and opt-out.

>zone? Or is there another policy document between IETF and IANA?

IANA has a whole bunch of policies about the management of the root
that do not contemplate anything other than delegations and glue in
the root zone.  As I said, it wouldn't be impossible to change, but it
would be a lot of work.  It is my impression that just about
everyone's DNS resolvers already have a special case for plain
"localhost" so there is little point.

Start here:  https://www.iana.org/domains/root

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Nov 2016 07:33:08 +1100

> Start here:  https://www.iana.org/domains/root

Adding A and AAAA for localhost is not the correct solution.  Whether
there should be a A or AAAA or both or none is the local machines
decision not IANA's.

It's IANA's job to pass control of the namespace to the local
machine.  We do this in the DNS by adding a delegation.  That
delegation also needs to insecure.

localhost.	NS	a.root-servers.net.
localhost.	NS	b.root-servers.net.
localhost.	NS	c.root-servers.net.
...
localhost.	NS	m.root-servers.net.
localhost	NSEC	locker. NS
localhost.      RRSIG   NSEC 8 1 86400 [...]

and the root servers also have a "empty" zone for localhost with
the above set of NS records in it.

Mark

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]