Subject: [DNSOP] draft-wkumari-dnsop-internal and DNAME

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Nov 2017 20:12:41 +0800

draft-wkumari-dnsop-internal-00 says "This document requests that the
.internal TLD be assigned to the IANA (similar to the way that
.example is) and 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 implies NS records in the root. Why not using the DNAMEs of RFC
7535 instead? I understand there is currently no ICANN process to add
DNAME in the root zone but there is no process to add .internal
either.

(draft-bortzmeyer-dname-root may be relevant here.)

---

From: Matt Larson <[email-masked]>
Date: Fri, 10 Nov 2017 08:53:06 -0500

> On Nov 10, 2017, at 7:12 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Without commenting on the contents of that particular draft, I'll note that from a technical/mechanical perspective, ICANN's and Verisign's root zone management systems already know how to deal with delegations. A DNAME in the root would require an unknown level of development by both parties.

While you're correct about no existing process (that I'm aware of) to add either .internal or a DNAME to the root, at least with a delegation there is only process work, not technical work, as well.

Adding new types of information to the root is certainly possible: I'm not trying to discourage that. But for planning and expectation-setting purposes, the community needs to take into account the long lead time that will be required for anything that requires technical modifications to the root zone management system.

Matt

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Nov 2017 22:28:18 +0800

On Fri, Nov 10, 2017 at 08:53:06AM -0500,
 Matt Larson <[email-masked]> wrote 
 a message of 32 lines which said:

> I'll note that from a technical/mechanical perspective, ICANN's and
> Verisign's root zone management systems already know how to deal
> with delegations. A DNAME in the root would require an unknown level
> of development by both parties.

I've never read the source code of the root zone management system,
but it seems surprising that it could be a non-trivial level of
development. I assume this system is complicated because it is highly
sensitive, and because it needs to incorporate a lot of defenses
against both mistakes and attacks, but they should be more or less the
same for DNAME and NS/A/AAAA, no?

> Adding new types of information to the root is certainly possible:
> I'm not trying to discourage that. But for planning and
> expectation-setting purposes, the community needs to take into
> account the long lead time that will be required for anything that
> requires technical modifications to the root zone management system.

Wild guess (and I pay beers if I'm wrong): the technical work will
take much less time than the process one.

---

From: Kim Davies <[email-masked]>
Date: Sun, 12 Nov 2017 10:50:51 +0800

> same for DNAME and NS/A/AAAA, no?
...
> take much less time than the process one.

I suspect that would be a distinction without a difference. Any process
changes need to be mapped into technical changes to the systems, as
the whole business process from beginning to end is processed in the
systems.

Allowing DNAME records in the root zone is adding a new concept into
root zone management that hasn't been catered to before. Just one of the
many things that would need to be looked at is how to transmit DNAME
provisioning requests via EPP. I don't know if there is even an EPP
mapping for this.

We haven't studied what would be involved, but I feel confident in
predicting the whole exercise would be non-trivial.

kim

---

From: Joe Abley <[email-masked]>
Date: Sun, 12 Nov 2017 11:26:42 +0800

On Nov 12, 2017, at 10:51, Kim Davies <[email-masked]> wrote:

It seems to me that you could implement this using lawyers as easily as you
could using developers; it is after all arguably a static change in
procedure that doesn't need to be especially repeatable. If the root zone
maintainer is contracted to include a record, surely the record will be
included.

However, I think the more general idea that queries for internal names
should be leaked towards unknown AS112 operators is problematic. As an
end-user I would prefer my leaked queries to be jealously hoarded by one of
twelve root server operators than an inbound number of anonymous and
potentially ephemeral AS112 operators.

The potential for complete data collection at the root servers goes down as
resolvers implement aggressive NSEC caching. In the case of a delegation or
redirection, that potential is reduced since the non-existence of
individual names under internal is then the thing that is cached, not the
non-existence of the right-most label in the namespace.

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 12 Nov 2017 20:05:44 +0800

On Sun, Nov 12, 2017 at 10:50:51AM +0800,
 Kim Davies <[email-masked]> wrote 
 a message of 32 lines which said:

> Just one of the many things that would need to be looked at is how
> to transmit DNAME provisioning requests via EPP. I don't know if
> there is even an EPP mapping for this.

Interesting remark. I indeed did not find one. It should probably be a
small extension of RFC 5731:

   C:      <domain:create
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.1">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:period unit="y">2</domain:period>
   C:        <domain:dname>empty.as112.arpa</domain:dname>
   C:        <domain:registrant>jd1234</domain:registrant>
   C:        <domain:contact type="admin">sh8013</domain:contact>
   C:        <domain:contact type="tech">sh8013</domain:contact>
   C:        <domain:authInfo>
   C:          <domain:pw>2fooBAR</domain:pw>
   C:        </domain:authInfo>
   C:      </domain:create>

I'll ask regext tomorrow about it :-)

> predicting the whole exercise would be non-trivial.

But there is no choice. If we decide to delegate .internal to AS112
(*if*: see Joe Abley's message), we cannot use NS records because the
AS112 servers won't recognize the new TLD, and there is no way to
change them all these servers (RFC 7535, section 1).

---

From: Joe Abley <[email-masked]>
Date: Sun, 12 Nov 2017 22:37:19 +0800

An unbounded number of AS112 operators, not an inbound number.

I apologise to all present for sending mail to dnsop from a phone without
taking more time to check for autocorrect lunacy.

On Nov 12, 2017, at 11:26, Joe Abley <[email-masked]> wrote:

Joe