DNS Problems

DNS Problems

"All problems in Computer Science come down to naming." I no longer remember who to attribute this quote to but it sure seems to be true. The other appropriate quote, from Butler Lampson, is "all problems in Computer Science can be solved by another level of indirection."

We have many different things to name with different requirements on the naming system. Sometimes we'll come up with an additional naming system just because of those different requirements even though we're naming the same thing.

In networking we want to name hosts, endpoints, networks, network interfaces, routes, people, network services, security principles, aggregations of any of the preceeding, and probably several other things I've haven't remembered to include in this list.

Here I'm talking about a global naming system for hosts or endpoints, in other words, the Domain Name System.

Problems

I'm not going to write a lot about the problem because right now I want to get some ideas down about how to think about solutions. Rob Austein has written some of this down [Note: I think it's on his home page, put in a pointer.] as well as a fascinating hack solution that could be built with the existing DNS software.

The short form of the problem is that the DNS does not scale. When we first got the DNS, it seemed infinitly expandable and compared to HOSTS.TXT it was, almost. We can now see the end of the "almost" part though. Look at the squabbles about top-level domains, how many to have and who controls them, to see a part of the problem. Look to the court cases over trademark infringement to see another part. Keep in mind the question "what happens when all the good names are gone?" and contemplate what DNS names would look like if the system had 100 or 1000 times more names in it than it does now. You'll get an idea why I say the DNS doesn't scale.

John Romkey notes that the problems come because we try and put meaning on the DNS names themselves and that database designers have found through painful trial and error that whenever you use a database key that has semantics beyond just being a key, you get problems.

Another problem is that the DNS is a heirarchy. Heirarchy seems to be the only real tool we've found to control complexity but for social systems it has the unfortunate side effect of concentrating power in those people nearer the top of the tree and whenever you have such a concentration of power you have a less stable system. This is stability in the sense of resilience or flexibility not in the sense of not changing. Because of the fact that we're imbuing DNS names with meaning, with semantics, we get a heirarchical social system surrounding and controlling the DNS and we see the instability that results.

Approach to Solutions

First, apply the rule about adding another level of indirection. Split the problem in two, put the difficult parts in one half, and solve the easy half, and leave the difficult bits for later.

Human Names/Computer Names

Computers really want names from a single namespace where each name is globally and deterministically unique. Humans use ambiguous names where the ambiguity is resolved by context. We need to decouple these two.

Each person has their own set of contexts for names. This suggests that we ought to have personal naming contexts that translate to some globally unique naming system.

The idea is that since the names that have to be globally unique are no longer used by humans, they don't have to look pretty. There's no longer a need for good names, names that try to reflect the company or person they refer to.

A really simple way to do this is just with a personal address book of some sort. Most MUA's already have something for this. It might have multiple contexts for names and it would translate from names the user likes to names the computer likes.

Rob Austein suggests a way to use the DNS as it's implemented now to build a system that gives each site a local namespace which then translates (using PTR records) to the global namespace.

By no longer having humans use the computer friendly names, we're no longer impelled to put semantics on those names. The legal system should be less interested in controlling names that people don't see. Finally, the destructive heirarchical social system that grows up around such things, is rendered largely irrelevant.

Note: By making the computer names somewhat ugly (probably numbers) I was hoping that people would become less attached to them. Avri points out the squealing of people who have their telephone area codes changed. Hopefully that's mostly because of the hassle of changing to a new phone number but in some cases people really do seem attached to the specific number. Sigh.

An objection to this is how do people find names they don't already know? Currently, with some amount of semantics being inserted into the names, if you want to find Microsoft's web page you have a pretty good bet of winning with www.microsoft.com. But if you try to do the same thing with Cessna Aircraft Company, you get James Cessna, a computer consultant. You have to be smart enough to know to look for cessnaaircraft.com or cessna-single.com. This is a lousy way to run a white pages system anyway and the right answer is, and always has been, a real white pages system.

Note that this decoupling fits in quite nicely with the Nimrod theme of keeping those things that have to be globally coordinated to a minimum. The computer namespace has to be globally coordinated but the white pages systems can be many and varied.

There's also the issue know as the business card problem. What do you put on your business card? Obviously it has to be the globally unique name. But that name is likely to be ugly, hard to remember, and typing it in likely to be error prone. I don't have an answer but I claim that DNS names are going that way anyway, they have to, so it's no worse. Bar codes or splats might be a partial answer but probably you'll just have to deal. Phone numbers aren't pretty or easy to remember either.

Note: Maybe a better way of dealing with the business card problem is to depend on directory services instead. Instead of trying to put an undecipherable DNS name on the business card, just put enough information that you can do a look up in the directory system.


David Bridgham <dab+nimrodweb@froghouse.org>

last updated: Fri Mar 4 17:00:13 2011 by David Bridgham