Re: DNS heirarchy, multiple roots, etc [was Re: Split the IANA functions?]

[Suzanne Woolf <[e-mail]>]

Colleagues, 

On the DNS discussion generally: I respectfully suggest it tends to be more productive if we are careful with terminology, in distinguishing among different facets or aspects of DNS.

1.There’s no hard limit on the number of physical devices or diverse locations where we can put nameservers to provide the service (IP-based anycast). There’s probably a limit beyond which adding more service points adds to administrative overhead without improving the service. I haven’t done the math; I suspect someone has, most likely a large DNS or CDN operator. The constraints on where they're measurably useful are also driven by operational concerns like available connectivity, which in the case of the root are tied to the contents of the zone and other larger policy concerns but very indirectly.

2. There’s a functional limit in the DNS to how many NS records one can have for a zone. It may be meaningful to say that number is larger than 13 for the root, now, if one assumes widespread usefulness of EDNS0 (essentially, full penetration e2e of the ability to handle larger packet sizes than originally specified in the DNS, since we have to be careful about the implementation details of response truncation, packet sizes, etc.), but there’s still likely an upper bound. There are also protocol consequences to selecting which NS set to share for a zone as a subset of possible ones (answers won’t always be consistent). Those are protocol issues, and not specific to the root. (The operational limitation above is also relevant to the number of NS records/service points, in that at some point the nth new service point is measurably useful and the n+1’th isn’t.) This is primarily a matter of the DNS protocol, and the IETF is where people work on the protocol.

3. What people are usually talking about when they argue about “alternate roots” is not how many servers or how many named service points we can have, which are operational and protocol matters, but the namespace— what goes in the tree, where, with what characteristics, and who decides. And traditionally, this is where IANA is most directly involved, and generally where the strictly policy-based tussles ICANN engages in appear. The way we’ve structured DNS data, including certain of its key advantages, there’s one such namespace, and bad things (relative to the original requirements, which seem to persist to a very meaningful degree today) start to happen if it’s fragmented or inconsistent. As John's comments note, there are also other characteristics of the namespace, chosen early, that have had significant policy consequences. Some are easily separable from the on-the-wire protocol and operational considerations; some aren't. 

We can discuss any or all of these things in the context of IANA and the root, but I suspect that the discussion will be more useful if we make some distinctions among them. Otherwise we’ll continue to have a world where, for example, people believe that having control of a named service point for DNS resolution service for the root of the namespace gives them some meaningful degree of control over what’s in the namespace as it appears in the public or global context, even though as a matter of both protocol and operations, that’s simply not true.

It's also probably useful to have further discussion in another venue. The DNSOP WG is meant for discussions/work on DNS operational characteristics, scalability, best practices, etc. The DNSEXT WG is closed but there's still a mailing list, probably best suited for protocol discussion on DNS. 

best,
Suzanne

On Jan 7, 2014, at 8:14 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> 
> What I was trying to object to is the use of 'mathematical possibility' as a slapdown as if the design of the DNS were so perfect that anyone proposing an alternative approach is a complete fool.
> 
> That sort of argument can work inside IETF but it looks really bad when it is made in an external forum where the audience does not start from the same assumptions as to what is immutable fact.
> 
> 
> The choices are constrained by the legacy technical infrastructure and the requirements.