[discuss] So-called alternate roots (was: Funding for developing economies as an Ig policy issue? was Re:[ ] Time to be ...)

[Andrew Sullivan]

Hi,

On Fri, Jan 03, 2014 at 11:45:50PM +0100, Michel Gauthier wrote:
> I am not a specialist Iike you. I just trust the people in charge
> and use their words and expertise.

Then I'm glad we have this list, so that specialists can share the
information they have with others not specialist in that area.  I'm
going to try to take that opportunity.  People who know about DNS
might want to skip this (or parts of this message, which I've called
out below) because it's long and will be tedious if you already know
about this.  (It might be tedious anyway.  Sorry about that.)

> "provides a facility for future extensions that accommodates the
> possibility of safely deploying multiple roots on the public
> Internet" 

Thanks for this quote and for the reference.  I'd actually forgotten
about that document!  It turns out that bit in that document was
probably too optimisitic given what we've learned.  The quote doesn't
get the whole context: the "facility" there is the DNS CLASS.

[people who know about the DNS details can skip this part until
---endskip below] 

Since you say you're not a specialist, you may not know what follows.
It's details of the protocol, but for this discussion they're
important to understand.  Apologies if this is all old hat.

All the data that you (or more likely, your computer) wants to look up
in the DNS comes in the form of Resource Records ("RRs").  These RRs
travel around in groups called RRsets.  

You can identify an RRset by the name (we say "owner name" or "QNAME"
a lot of the time), the class, and the type (often spelled "RRTYPE").
The other parts of an RR are the Time to Live or TTL, and the stuff
you were trying to get, which is called the RDATA.  They're irrelevant
for us in this discussion.

So, just for example, here is the RRset of the mail exchanger for this
list, which takes all the mail we send it:

1net.org.		3600	IN	MX	10 1net-mail.1net.org.

The name is "1net.org." (note the final dot: this is a _really_ fully
qualified domain), the TTL is 3600, the class is IN, the type is MX,
and the RDATA is "10 1net-mail.1net.org" (there are two fields in this
RDATA).  It so happens there's only one RR in this RRset, but there
could be more.  We identify the RRset by {1net.org, IN, MX}.

RFCs 1034 and 1035 (which are the current foundation standards for the
DNS, STD 13) defined four classes: Internet (IN), CSNET (CS), Chaos
(CH), and Hesiod (HS).  IN was for the Internet.  CS was already
obsolete.  CH was for a networking technology that didn't make it
(it's abused today for some informational queries by DNS admins), and
HS was for a directory service like NIS (which also didn't take off,
and which turns out to be usable in IN as well).  Essentially
everything on the Internet uses the IN class.

A key point is that RRTYPEs are supposed to be common across classes,
but zones are only defined for a single class.  So, suppose we added
a new class "XX" to the DNS.  It would be possible for the following
two RRsets for name servers to co-exist in the DNS in that case:

example.com.    3600    IN   NS  ns1.example.com.
example.com.    3600    IN   NS  ns2.example.com.

example.com.    3600    XX   NS  ns1.&&&&&&&.com.
example.com.    3600    XX   NS  àéîöæ.&&&&&&&.com.

The first of these uses the IN class, and it provides two name servers
for example.com.  But the second RRset uses some very unusual domain names
in the RDATA of the name server.  That domain name would be strictly
protocol legal under RFCs 1034 and 1035, but it'd be a bad idea
because those RFCs define a "preferred syntax".  That preferred syntax
is the well-known Letter Digit Hyphen (LDH) rule.  The new class might
not use that convention, and so it would be possible to do different
things in one class than in another.  And indeed, one thing you could
do in that different class is have a different NS RRset altogether.
That would indeed permit an "alternate root" in the sense that, if you
used a different class, you'd get a different set of root name
servers.  (In that case, the owner name would not be "example.com."
but "."  Now you can see why that final dot is there: it's how we
designate "root".)

Note that the original RRTYPE definitions were all in STD 13, too, so
it was originally easy to specify that RRTYPEs cut across all classes.
And the early RRTYPEs were all careful to specify that they were
defined for all classes.  It is not obvious that every RRTYPE has
always been so careful, though in principle RRTYPEs are
class-agnostic.

Exactly one new class has ever been defined in the DNS, and it's
acutally a query class rather than a class as such.

Finally, there is one other important thing to remember.  Looking
things up in the DNS is not like visiting a web page.  In the latter
case, your computer normally talks to the server that serves the web
page.  You make a more or less direct connection.  But in the DNS,
caches and "middleboxes" are everywhere.  So when you want to upgrade
something, you can't just upgrade yourself.  You need other things on
the Internet to change, too, and some of them will be out of your
control.

I hope this explanatory material is helpful.  If it's not clear,
please send me mail off list so I can explain more -- this is probably
too detailed to take up any more list bandwidth with.

---endskip

The text has a footnote that mentions an Internet Draft by John
Klensin.  The linked version is from 2001, but the final attempt with
it was in 2002 (you can still find it at
http://tools.ietf.org/html/draft-klensin-i18n-newclass-02).  This was
a proposal to use the class functionality of the DNS in order to
create a new structure in which IDNs could be used without special
tricks like IDNA.  

I don't know everything about why John abandoned the proposal, but I
have a feeling that the Internet-Draft itself actually contains part
of the answer: "At a relatively technical level, this would require
changing every DNS resolver and server, and application that accesses
either, on the Internet that wished to use non-ASCII names."  In fact,
later in the draft, he goes on to suggest that the new class would be
intended to replace IN.  So his proposal was, in fact, to replace the
name resolution system on the Internet.  This was option (3) that I
outlined in my previous message.  It's true we'd still be "using the
DNS", but because nobody has ever actually used any class except IN
for anything important, the IN class is built into assumptions all
over the place.  It would be no less work to use a new class than to
replace DNS altogether.

> as "ultimately there may be better architectures for
> getting the job done where the need for a single, authoritative root
> will not be an issue".

That sentence of course acknowledges that it is always possible that
someone will invent a new technology that will replace the DNS.  It
just requires upgrading everyone on the Internet, or else accepting
that different people on the Internet will have radically different
features available to them depending on where on the upgrade curve
they (and all the systems between them and the rest of the Internet)
are.  And of course, if different groups of people are looking up
names in completely different name spaces on the Internet at the same
time, they're not really networked to each other, are they?  So this
wouldn't really be a case of "alternate roots" on the Internet, but of
splitting the Internet into two mutually-invisible name spaces.

On Fri, Jan 03, 2014 at 04:50:52PM -0800, manning bill wrote:

> while andrew is correct from a protocol perspective, ICANN has, over
>the years done a neat trick, called the registry/registrar split.

While this is true, I don't understand how it has anything to do with
"alternate roots".  The mechanism by which names get _into_ a zone is
unrelated to the mechanism by which names are looked up.  After all,
there's more than one way to get a label into the root zone today.
One of them is to be a country on the ISO 3166-1 list.  Another one is
to be granted a TLD for other reasons.  Those are separate
registration protocols, but it's still one root zone.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs at anvilwalrusden.com