G E E K   P A G E    Issue 2.09 - September 1996

The Domain Name System

By Tim Barkow

Let your resolver do the walking



Most folks have been stymied by Netscape's cryptic message that a server can't be located because its DNS entry could not be found. Now, computers speak in numbers, while people understand only words. What your browser is telling you is that without the DNS entry, it can't translate the English www.hotwired.com into the corresponding numerical IP address 204.62.130.17.

The hosts file

Back in the Arpanet days, a naming system was devised that would map a computer's IP address to a unique ASCII-based identifier (www.hotwired.com). The US Defence Department's Network Information Centre maintained a file named hosts.txt - a master list of each computer's address and its host name. Systems administrators would download hosts.txt periodically. If you knew a computer's name, you would simply look up its IP address in the hosts file.

But it soon became clear that the exploding number of hosts was putting too great a load on the NIC computer. At the same time, there was an eruption of small networks of workstations, which get reorganised often and are harder to track. Everyone wanted their computers on Arpanet, but they had to wait for NIC to update hosts.txt. Something else was needed. So in late 1987, Paul Mockapetris outlined the Domain Name System.

A big tree

DNS, as laid out by Mockapetris, is a general-purpose name service that can be used by Web browsers, email, telnet and other applications. It's like the Yellow Pages or 192 for computers. But instead of maintaining a single database - which would be impossible today because of the Internet's constant flux and growth - elements of DNS are distributed across thousands of name servers, each of which contains information about one branch of the Internet.

So, if your computer doesn't know where hotwired.com is, how can it find a computer that does? By climbing the tree.

The Internet, seen through DNS, resembles a hierarchical tree. At the top are the root name servers, which contain information about the contents of the top-level dom-ains: .net, .com, .edu, .org, .int, .gov, .mil and the two-letter country codes from ISO-3166 (.us, .uk, .fi, .jp, et cetera). Under each top-level domain, or TLD, the tree structure is basically flat - organisations like HotWired register their second-level domains (the hotwired of hotwired.com), then any further network structure is up to them. Inside hotwired.com, administrators can name computers what-ever they want - hard.hotwired. com, for instance. Each name reflects its place on the DNS tree: www.hotwired.com is a host computer (www) in the hotwired dom-ain which is inside the .com TLD.

The beauty of DNS is that the work of maintaining an accurate database is divvied up between the root name servers and the local, "authoritative" name servers. The root name servers, if they recognise hotwired.com, will point you to hotwired.com's name servers that contain the information on www.hotwired .com you seek.

This information is contained in the resource records held on every host computer with a domain name. A query response typically contains a computer's host name, its IP address, and the IP addresses of that computer's authoritative name servers.

Querying the roots

When looking up www.hotwired.com, your Web browser sends a message to its authoritative name server, asking it to translate the name into an IP address. Just as every host connected to the Internet is assigned an IP address, it is also assigned a name server by the network administrator for finding other IP addresses. Using a resolver program, the name server sends a message to one of the root name servers, asking it to look in its .com domain database for the IP address of hotwired.com's name server. If the root name server doesn't know, it returns the address of a second root name server, and the resolver asks again. This iterative querying process keeps the querying load off the root name servers, allowing them to give quick answers before moving on to the next query.

Currently there are eight root name servers in the US and one in Sweden that contain pointers to the name servers of all the top-level and most second-level domains. The querying process was built so that no one root name server has to know all of the domains on the Internet.

This resolver process works well, but DNS also includes two "smart" options to improve performance. Before contacting the root name servers when it receives a query, a resolver first looks in its local name database to see if the host is part of the resolver's own network. If not, the resolver looks in a cache file of recent query results to see if it can find the host's address there. To keep the cache up to date, each entry is tagged with a time-to-live value, or TTL, usually equal to a few hours or a week. Once the TTL expires, the entry is thrown out.

Dot whoopie

With the emergence of the Net as a mass market phenomenon, the generic TLDs - .com, .org, and .net - are growing unwieldy. For this reason, the Internet Assigning Numbers Authority, the group responsible for managing DNS, has been pushing new domain registerees toward the less used country-code domains. While some don't mind setting up shop in the .us domain, others wonder why they can't set up their own top-level domains - .sex, for instance.

They can. The only reason InterNIC holds power over DNS is that all the local name servers in the world are configured to query InterNIC's servers. There's no reason a name server can't query your root name server as well as InterNIC's servers. If enough name servers around the world know to look through your servers when they get a domain name ending in .sex, it would work fine. Truth is, there's nothing in DNS that precludes a little .sex.

Tim Barkow is a section editor at Wired US.