RE: Statements against

Y’know, I upon reading this again, I have to point something out: The current set of root servers is not administered by a unique naming authority. The root zone itself is administered by the unique naming authority.

The zone needs to have a Single Point of Contact. The root servers themselves need to have a unique PoC for each, and it is much more desirable to the Internet at large to each root server administered by a separate entity – be it,, APNIC, whatever and whoever has the bandwidth, knowledge, expertise, and money to support it. But the zone itself needs to have an entity who is ultimately responsible for what goes into the zone and what doesn’t.

Now, I’m going to say something here (and these are my own opinions):

In the context of Certifying Authorities for SSL certificates, we have multiple, unique roots. Lots of them. In Internet Explorer alone, there are more than 80 that are embedded upon installation, and my set of CA roots is different from your set of CA roots [this is a fact, since I run a CA internal to my company]. This is roughly akin to the idea of including a on each client, that makes it almost impossible to determine which roots each client trusts. [PLEASE do not say anything about ‘barrier to entry’ or ‘a trusted root can’t sign an intermediate root’ – the first is high indeed, and the second is patently false. I’m only bringing this up to explain a concept.]

Now, in the case a website has a CA that doesn’t match anything that’s in the browser, there’s an interactive dialog to determine which action to take – whether to accept it anyway, or to cancel the connection. In the event of multiple, conflicting TLDs, though, there’s no way for that interactive exchange with the user to occur. Say I have an email address of ‘winged@wolf.animal-lover’, and someone doesn’t like the way the ‘animal-lover.’ TLD is being run, so they set another root up with the ‘animal-lover.’ TLD and assign it to someone else. And one of my friends is on an ISP that uses this alternate root. And my friend tries to send me an email.

So, where will mail to my mail address ‘winged@wolf.animal-lover’ go to? The client on my friend’s system will send it to the ISP’s mail server, which will look up MX wolf.animal-lover on the conflicting root. Which will almost certainly not be the MX wolf.animal-lover that I use. So at best it gets bounced, at worst it goes to a completely uninvolved third party – and my friend would never even know. (And neither would I.) And the next time my friend saw me, he’d ask me about it, and I’d have to say “it works for me”, and then we’d spend a lot of time figuring out where the problem was. And then we’d yell and scream and curse and swear at the anarchy that led to Usenet being what it is today… and most likely create our own little VPN for the exchange of mail between our sites. Do we really -want- more VPN traffic flowing over the backbone?

An implicit assumption made on the Internet today is that “e-mail addresses will be unique and will route to the proper person unless there is a technical reason that that is impossible”. (Don’t laugh, this is the view of everyone I’ve ever talked with – they don’t think it’s possible that someone could take over their email account.) So ‘’ will always route to me, unless the MX is wrong or my mail server’s down. However, if we have conflicting zones, we’ll never be able to guarantee communication is going to work properly across the Internet, and we’ll be forced back to phone or pen&paper for REALLY important stuff. (Which will also have the effect of completely removing the trust essential for e-commerce to occur, since it’ll never be truly possible to determine which TLD root you’re going through.)

It may be possible for larger corporations to buy through ALL registries for a given TLD… but that is inefficient, and if someone set up a registry for net. or com. or org. or mil., and then set up an alternate root for it, and someone else used that root… can you imagine the carnage? (Especially given ~$20/year per registry.)

Name hijacking would be what it is, and there are laws against it (all the trademark laws, much less the fraud, malfeasance, misrepresentation, and many others) all around the world. Personally, I hope that the ICANN files a misrepresentation/fraud suit against, and soon… though ICANN’s way of doing things must not be condoned, at this moment the system is NOT the correct way to fix the issue.

-Mat Butler
Speaking for himself, not his company