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 <hallam(_at_)gmail(_dot_)com>
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.