Subject: [DNSOP] Remarks about draft-wkumari-dnsop-internal-00

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Sep 2017 16:32:39 +0200

draft-wkumari-dnsop-internal-00 proposes to reserve .internal for
RFC1918-like domain names. There is clearly a strong demand for that.
(There is also a strong demand for happy sex, great food, excellent
wines and diamong rings, but let's ignore it for the moment).

The document clearly documents that it will not happen, since it
requires an entire new process at ICANN.

The draft requires a delegation to AS112. Since one of the goals is to
limit leaks, I'm not sure it is a good idea. During the development
of draft-bortzmeyer-dname-root, several people noticed that, unlike
the root, the AS 112 is managed by an unbounded set of unknown
operators. Not great for privacy.

Regarding section 4 (DNSSEC), I wonder if it would be a better idea to
have a name like that in the root:

shouldnotarriveattheroot.internal. IN TXT "Check your resolvers"

This way, requests for anything.internal which leaked at the root
would receive an insecure denial of existence (since there is no DS
for .internal). Problem solved, no?

% dig @localhost -p 9053 NS printer.internal                  
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53323
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
...
;; AUTHORITY SECTION:
intel.			86400 IN NSEC shouldnotarriveattheroot.internal. NS DS RRSIG NSEC
intel.			86400 IN RRSIG NSEC 13 1 86400 (
				20171005142909 20170907142909 6172 .
				RMtu2iXqWAO7LOuB2L/IgbfSuf3h6d7eTQdnEshw+uZT
				WDz0HuSHUeC5YJTxPc2qwGN8xa6dmeGGLX6rTkpWaQ== )
.			86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. (
				2017090702 ; serial
				1800       ; refresh (30 minutes)
				900        ; retry (15 minutes)
				604800     ; expire (1 week)
				86400      ; minimum (1 day)
				)
...

[Note it would not solve the ICANN problem.]

Also, it may be a good idea to add an "Internationalization
considerations" section. If people want a memorable domain name (and
not, say, the TLD .693268ed5948276cb48c3f3339ac465d, which would work
as well), it's because it is typable and rememberable), they may want
it in other languages.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 07 Sep 2017 07:48:08 -0700

> requires an entire new process at ICANN.

That is a non sequitur. ICANN regularly creates new processes at the 
request of its communities.

--Paul Hoffman, not speaking for ICANN, but speaking as someone who has 
seen ICANN do this for over a decade

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Sep 2017 16:53:32 +0200

On Thu, Sep 07, 2017 at 04:32:39PM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 57 lines which said:

> RFC1918-like domain names.

And I forgot to say that it could be a good idea to add a reference to
draft-lewis-user-assigned-tlds, for an alternative solution.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Sep 2017 11:21:07 -0400 (EDT)

> for .internal). Problem solved, no?

Wouldn't that be a secure denial of existence?

AFAIK, the root isn't using NSEC3/optout :)

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Sep 2017 17:31:34 +0200

On Thu, Sep 07, 2017 at 11:21:07AM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 11 lines which said:

> > would receive an insecure denial of existence (since there is no
> > DS for .internal). Problem solved, no?
> 

Yes, sorry.

[It may create funny interactions with RFC 8198 but I suspect that
resolvers that leak .internal queries won't implement RFC 8198 anyway.]

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 7 Sep 2017 17:20:18 -0400

> requires an entire new process at ICANN.

As WG chair: no reason I know of to assume this. 

As long-time observer of IETF and ICANN process: no reason I know of to assume this; such a request from the IETF, however, would involve the IESG (presumably armed with IETF consensus), the IAB (which manages the IETF liaison relationship with ICANN on behalf of the IETF), and some patience, since it amounts to a request that the ICANN community do work to accommodate a need of the IETF. This doesn't mean it can't be done or even that it won't be done, only that the implications need to be considered as far as possible. 

At the very least, I'd like to see an extremely strong rationale for making such a request; we should be working towards a statement something like "doing this solves the following large class of problems for a really long time, in a demonstrably better way than any of the alternatives."

> as well), it's because it is typable and rememberable), they may want

Agreed. This mechanism is intended, at least in part, to accommodate the common desire people seem to have for DNS names to act sort of like natural language objects and not just random strings. It seems to me that defining such a mechanism should consider the likelihood that not everyone who wants to use it will be native speakers of English who are happy to limit the available characters to US-ASCII.

Suzanne

---

From: George Michaelson <[email-masked]>
Date: Fri, 8 Sep 2017 08:13:38 +1000

It's not sensible to presume the action of an independent
decision-making body. It's sensible to discuss it, but it should only
inform our own process logic, not decide it categorically (I think)

I might share your expectation of the outcome, but I would hesitate to
reject a draft on a supposition.

-George