I bring this up because we recently received a message from kcclaffy, who falls squarely into that smart, accomplished demographic. kc works at SDSC, the San Diego Supercomputing Center, which means a) she’s wicked smart and 2) she has thegood sense to live in the lovely San Diego area. She’s done a lot of work with CAIDA, the Cooperative Association for Internet Data Analysis and whose acronym I imagine she pronounces very carefully when explaining what she does to a TSA agent including a fascinating study of the crazy mix of useless query traffic received by a root name server.
kc asked Matt and me for our opinion on an issue related to the expansion of the top-level namespace. As I’ve written, ICANN has begun adding more top-level domains. We recently saw the addition of TLD’s that use IDNA to encode non-ASCII characters, and ICANNs also planning to allow folks to register lots of the plain-Jane, ASCII variety of TLDs, too.
kc asked our thoughts on restricting the TLDs that could be registered. Why would ICANN do that? Well, there are quite a few reasons:
- Some prospective TLD names might be offensive. These are not just of the Seven Words You Can’t Say on Television variety; some names and even single characters may be offensive to certain groups. For example, I learned a few years ago that using the characters that represent the true name of the emperor of Japan is considered blasphemous by many Japanese.
- Some prospective TLD names might interfere with DNS infrastructure in some way. How? Well, here’s one: Some stub resolvers aren’t smart enough to recognize IP addresses when they’re handed to them and try to look them up as domain names. They’ll wastefully send a query to a recursive name server for the A record for the domain name 10.0.0.1, for example. (In the root name server study kc herself worked on, the researchers found a remarkable percentage of the queries to the roots were these A-for-A queries.) Today, of course, such aquery is answered with No such domain, and presumably the resolver either returns that error to the application or realizes the error of its ways and uses the address as an address. Imagine the havoc that a TLD registrant could wreak, then, if he we’re allowed to register 1 as a TLD. He could answer that query for the A record for 10.0.0.1 with another address. I shudder to think of the consequences.
- The search list can also generate queries in (what are currently) nonexistent TLDs. For example, when I ran hp.com, we had a corp.hp.com subdomain that served our corporate offices in Palo Alto. Since almost every stub resolver at HP had hp.com in its search list by default, we could instruct employees to access a server with a name like winnie.corp, knowing the search list would canonicalize that string to the servers real domain name, winnie.corp.hp.com. Nowadays, however, modern resolvers typically look up any string that contains a dot as-is before applying the search list, meaning that users typing winnie.corp will actually cause a query for winnie.corp before the resolver ever gets around to trying winnie.corp.hp.com. So if someone were to register corp as a TLD, well, that could have surprising results.
I’m sure there are other possibilities I’m not considering, which is actually why I’m writing this blog entry. What other issues can you see with opening up registration of TLDs? What potential conflicts are significant enough or threatening enough to warrant denying a registration? Add your thoughts as a comment and I’ll collect the best and forward them along to KC.