Introduction to Domain Name Service

Paul Mockapetris designed DNS in 1984 to solve escalating problems with the old name-to-address mapping system. The old system consisted of a single file, known as the host table, maintained by the Stanford Research Institute's Network Information Center (SRI-NIC). As new host names trickled in, SRI-NIC would add them to the table - a couple times a week. Systems administrators would grab the newest version (via FTP) and update their domain name servers.

But as the Net grew, the host table became unwieldy. Though it worked fine for name-to-address mapping, it wasn't the most practical or effective way to update and distribute the information. And since the stability of the rapidly growing Internet was at stake, Mockapetris and some other folks decided to find a better way.

Enter DNS. The great thing about the domain name system is that no single organization is responsible for updating it. It's what's known as a distributed database; it exists on many different name servers around the world, with no one server storing all the information. Because of this, DNS allows for almost unlimited growth.

The domain name space

In order to understand how a DNS server works, you should be familiar with what is called the domain name space. It sounds a little ominous, I know, but really it's quite simple. In fact, you've probably seen it at one time or another represented by an inverted tree that looks something like this:

Each node on the tree represents a domain. Everything below a node falls into its domain. One domain can be part of another domain. For example, the machine chichi is part of the .us domain as well as the .com domain. You'll see why this is important in just a minute.

How it works

A DNS server is just a computer that's running DNS software. Since most servers are Unix machines, the most popular program is BIND (Berkeley Internet Name Domain), but you can find software for the Mac and the PC as well.

DNS software is generally made up of two elements: the actual name server, and something called a resolver. The name server responds to browser requests by supplying name-to-address conversions. When it doesn't know the answer, the resolver will ask another name server for the information.

To see how it works, let's go back to the domain-name-space inverted tree.

When you type in a URL, your browser sends a request to the closest name server. If that server has ever fielded a request for the same host name (within a time period set by the administrator to prevent passing old information), it will locate the information in its cache and reply.

If the name server is unfamiliar with the domain name, the resolver will attempt to "solve" the problem by asking a server farther up the tree. If that doesn't work, the second server will ask yet another - until it finds one that knows. (When a server can supply an answer without asking another, it's known as an authoritative server.)

Once the information is located, it's passed back to your browser, and you're sent on your merry way. Usually this process occurs quickly, but occasionally it can take an excruciatingly long time (like 15 seconds). In the worst cases, you'll get a dialog box that says the domain name doesn't exist - even though you know damn well it does.

This happens because the authoritative server is slow replying to the first, and your computer gets tired of waiting so it times-out (drops the connection). But if you try again, there's a good chance it will work, because the authoritative server has had enough time to reply, and your name server has stored the information in its cache.