From DNS and BIND, 2nd Edition
by Paul Albitz & Cricket Liu

Chapter 2

How Does DNS Work?

In this chapter:

The Domain Name Space
The Internet Domain Name Space
Further Down
Delegation
Name Servers
Resolvers
Resolution
Caching

"... and what is the use of a book," thought Alice, "without pictures or conversations?"

The Domain Name System is basically a database of host information. Admittedly, you get a lot with that: funny dotted names, networked name servers, a shadowy "name space." But you should keep in mind that, in the end, the service DNS provides is information about internet hosts.

We've already covered some important aspects of DNS, including its client-server architecture and the structure of the DNS database. However, we haven't gone into much detail, and we haven't explained the nuts and bolts of DNS's operation.

In this chapter, we'll explain and illustrate the mechanisms that make DNS work. We'll also introduce the terms you'll need to know to read the rest of the book (and to converse intelligently with your fellow domain administrators).

First, though, let's take a more detailed look at concepts introduced in the previous chapter. We'll try to add enough detail to spice it up a little.

The Domain Name Space

Each unit of data in DNS's distributed database is indexed by a name. These names are essentially just paths in a large inverted tree, called the domain name space. The tree's hierarchical structure, shown in Figure 21, is very similar to the structure of the UNIX filesystem. The tree has a single root at the top. In UNIX, this is called the root directory, represented by a slash ("/"). DNS simply calls it "the root," or occasionally "the root domain."[1] Like a filesystem, DNS's tree can branch any number of ways at each intersection point, called a node. The depth of the tree is limited to 127 levels (a limit you're not likely to run into).

Domain Names

Each node in the tree is labeled with a simple name (without dots). The label can be up to 63 characters in length. The root domain has a null (zero-length) label, which is reserved. The full domain name of any node in the tree is the sequence of labels on the path from that node to the root. Domain names are always read from the node toward the root ("up" the tree), and with dots separating the names in the path.

If the root domain actually appears in a node's domain name, the name looks as though it ends in a dot. (It actually ends with a dot – the separator – and a null label.) When the root domain appears by itself, it is written as a single dot, ".", for convenience. Consequently, some software interprets a trailing dot in a domain name to indicate that the domain name is absolute. An absolute domain name is written relative to the root, and it unambiguously specifies a node's location in the hierarchy. An absolute domain name is also referred to as a fully qualified domain name, often abbreviated FQDN. Names without trailing dots are sometimes interpreted as relative to some domain other than the root, just as directory names without a leading slash are often interpreted as relative to the current directory.

DNS requires that sibling nodes – nodes that are children of the same parent – be named uniquely. This restriction guarantees that a domain name uniquely identifies a single node in the tree. The restriction really isn't a limitation, since the names only need to be unique among the children, not among all the nodes in the tree. The same restriction applies to the UNIX filesystem: you can't name two sibling directories the same name. Just as you can't have two hobbes.pa.ca.us nodes in the name space, you can't have two /usr/bin directories (Figure 22). You can, however, have both a hobbes.pa.ca.us node and a hobbes.lg.ca.us, as you can have both a /bin directory and a /usr/bin directory.

Domains

A domain is simply a subtree of the domain name space. A domain's domain name is the same as the domain name of the root node of the subtree. That just means that the name of a domain is the name of the node at the very top of the domain. So, for example, the top of the purdue.edu domain is a node named purdue.edu, as shown in Figure 23.

Likewise, in a filesystem, at the top of the /usr directory, you'd expect to find a node called /usr, as shown in Figure 24.

Any domain name in the subtree is considered a part of the domain. Since a domain name can be in many subtrees, a domain name can also be in many domains. For example, the domain name pa.ca.us is part of the ca.us domain, and also part of the us domain, as shown in Figure 25.

So in the abstract, a domain is just a subtree of the domain name space. But if a domain is just made up of domain names and other domains, where are all the hosts? Domains are groups of hosts, right?

The hosts are there, but they're domains, too. Remember, domain names are just indexes into the DNS database. The "hosts" are the domain names that point to information about individual hosts. And a domain contains all the hosts whose domain names are within the domain. The hosts are related logically, often by geography or organizational affiliation, and not necessarily by network or address or hardware type. You might have ten different hosts, each of them on a different network, and each one perhaps even in a different country, all in the same domain.[2]

Domains at the leaves of the tree generally represent individual hosts. Their domain names may point to network addresses, hardware information, and mail routing information. Domain names in the interior of the tree can name a host and can point to structural information about the domain's children, or subdomains. Interior domain names aren't restricted to one or the other. They can represent both the domain they correspond to and a particular host on the network. For example, hp.com is both the name of the Hewlett-Packard Company's domain and the domain name of a host that forwards mail between HP and the Internet.

Which type of information – host or structural – a search retrieves depends on the context the domain name is used in. A search for the children of the node would return the structural data, while telneting to the domain name would look up the host information (in Figure 26, for example, hp.com's IP address).[3]

A simple way of deciding whether a domain is a subdomain of another domain is to compare their domain names. A subdomain's name ends with the name of its parent domain. For example, the domain la.tyrell.com must be a subdomain of tyrell.com since la.tyrell.com ends with tyrell.com. Similarly, it's a subdomain of com, as is tyrell.com.

Besides being referred to in relative terms, as subdomains of other domains, domains are often referred to by level. On mailing lists and in USENET newsgroups, you may see the terms top-level or second-level bandied about. This just refers to a domain's position in the domain name space:

Resource Records

The data associated with domain names are contained in resource records, or RRs for short. Records are divided into classes. Each class of records pertains to a type of network or software. Currently, there are classes for internets (any TCP/IP-based internet), networks based on the Chaosnet protocols, and networks that use Hesiod software. (Chaosnet is an old network of largely historic significance.)

The internet class is by far the most popular. (We're not really sure if anyone still uses the Chaosnet class, and use of the Hesiod class is mostly confined to MIT.) In this book, we'll concentrate on the internet class.

Records come in several types, which correspond to the different varieties of data that may be stored in the domain name space. Different classes may define different record types, though some types may be common to more than one class. For example, almost every class defines an address type. Each record type defines a particular record syntax, which all resource records of that type must adhere to. (For details on all internet resource record types and their syntaxes, see Appendix A, DNS Message Format and Resource Records.)

If this information seems sketchy, don't worry – we'll cover each record in more detail later. The common records are described in Chapter 4, Setting Up BIND, and a comprehensive list is included as part of Appendix A.

The Internet Domain Name Space

We've talked so far about the theoretical structure of the domain name space, and what sorts of data are stored in it, and we've even hinted at the types of names you might find in it with our (sometimes fictional) examples. But this won't help you decode the domain names you see on a daily basis on the Internet.

The Domain Name System doesn't impose many rules on the labels in domain names, and it doesn't attach any particular meaning to the labels at a particular level. When you manage a part of the domain name space, you can decide on your own semantics for your domain names. Heck, you could name your subdomains A through Z and no one would stop you (though they might strongly recommend against it).

The existing Internet domain name space, however, has some self-imposed structure to it. Especially in the upper-level domains, the domain names follow certain traditions (not rules, really, since they can and have been broken.) This helps domain names from appearing totally chaotic. Understanding these traditions is an enormous asset if you're trying to decipher a domain name.

Top-Level Domains

The original top-level domains divided the Internet domain name space organizationally. There are seven main top-level domains:

com Commercial organizations, like Hewlett-Packard (hp.com), Sun Microsystems (sun.com), and IBM (ibm.com)
edu Educational organizations, like U.C. Berkeley (berkeley.edu) and Purdue University (purdue.edu)
gov Government organizations, like NASA (nasa.gov) and the National Science Foundation (nsf.gov)
mil Military organizations, like the U.S. Army (army.mil) and Navy (navy.mil)
net Networking organizations, like NSFNET (nsf.net)
org Noncommercial organizations, like the Electronic Frontier Foundation (eff.org)
int International organizations, like NATO (nato.int)

There's also a top-level domain called arpa, which was originally used during the ARPANET's transition from host tables to DNS. All ARPANET hosts originally had host names under arpa, so they were easy to find. Later, they moved into various subdomains of the organizational top-level domains.

You may notice a certain nationalistic prejudice in the examples: all of them are primarily U.S. organizations. That's easier to understand – and forgive – when you remember that the Internet began as the ARPANET, a U.S.-funded research project. No one anticipated the success of the ARPANET, or that it would eventually become as international as the Internet is today.

To accommodate the internationalization of the Internet, the implementors of the Internet name space compromised. Instead of insisting that all top-level domains describe organizational affiliation, they decided to allow geographical designations, too. New top-level domains were reserved (but not necessarily created) to correspond to individual countries. Their domain names followed an existing international standard called ISO 3166. ISO 3166 establishes official, two-letter abbreviations for every country in the world. We've included the current list of top-level domains as Appendix C of this book.[4]

Further Down

Within these top-level domains, the traditions and the extent to which they are followed vary. Some of the ISO 3166 top-level domains follow the U.S.'s original organizational scheme closely. For example, Australia's top-level domain, au, has subdomains like edu.au and com.au. Some other ISO 3166 top-level domains follow the uk domain's lead, and have subdomains like co.uk for corporations, and ac.uk for the "academic community." In most cases, however, even these geographically oriented top-level domains are divided up organizationally.

That's not true of the us top-level domain, though. The us domain has fifty subdomains that correspond to – guess what? – the fifty U.S. states.[5] Each is named according to the standard two-letter abbreviation for the state – the same abbreviation standardized by the U.S. Postal Service. Within each state's domain, the organization is still largely geographical: most subdomains correspond to individual cities. Beneath the cities, the subdomains usually correspond to individual hosts.

Reading Domain Names

Now that you know what most top-level domains represent and how their name spaces are structured, you'll probably find it much easier to make sense of most domain names. Let's dissect a few for practice:

lithium.cchem.berkeley.edu
You've got a head start on this one, since we've already told you that berkeley.edu is U.C. Berkeley's domain. (Even if you didn't already know that, though, you could have inferred that the name belonged to a U.S. university, because it's in the top-level edu domain.) cchem is the College of Chemistry's subdomain of berkeley.edu. lithium, finally, is the name of a particular host in the domain – and probably one of about a hundred or so, if they've got one for every element.

winnie.corp.hp.com
This is a bit harder, but not much. The hp.com domain in all likelihood belongs to the Hewlett-Packard Company (in fact, we gave you this earlier, too). Their corp subdomain is undoubtedly their corporate headquarters. And winnie is probably just some silly name someone thought up for a host.

fernwood.mpk.ca.us
Here you'll need to use your understanding of the us domain. ca.us is obviously California's domain, but mpk is anybody's guess. In this case, it'd be awfully hard to know that it's Menlo Park's domain unless you knew your San Francisco Bay Area geography. (And no, it's not the same Menlo Park that Edison lived in.)

daphne.ch.apollo.hp.com
We've included this one just so you don't start thinking that all domain names have only four labels. apollo.hp.com is the former Apollo Computer's subdomain of the hp.com domain. (When HP acquired Apollo, they also acquired Apollo's Internet domain, apollo.com, which became apollo.hp.com.) ch.apollo.hp.com is Apollo's Chelmsford, Massachusetts site. And daphne is a host at Chelmsford.

Delegation

Remember that one of the main goals of the design of the Domain Name System was decentralizing administration? This is achieved through delegation. Delegating domains works a lot like delegating tasks at work. A manager may break a large project up into smaller tasks and delegate responsibility for each of these tasks to different employees.

Likewise, an organization administering a domain can divide it into subdomains. Each of those subdomains can be delegated to other organizations. This means that the organization delegated to becomes responsible for maintaining all the data in that subdomain. They can freely change the data, and can even divide their subdomain up into more subdomains and delegate those. The parent domain contains only pointers to sources of the subdomain's data, so that it can refer queriers there. The domain stanford.edu, for example, is delegated to the folks at Stanford who run the university's networks (Figure 27).

Not all organizations delegate their whole domain away, just as not all managers delegate all their work. A domain may have several subdomains and also contain hosts that don't belong in the subdomains. For example, the Acme Corporation (they supply a certain coyote with most of his gadgets), which has a division in Rockaway and its headquarters in Kalamazoo, might have a rockaway.acme.com subdomain and a kalamazoo.acme.com subdomain. However, the few hosts in the Acme sales offices scattered throughout the U.S. would fit better under acme.com than under either subdomain.

We'll explain how to create and delegate subdomains later. For now, it's only important that you understand that the term delegation refers to assigning responsibility for a subdomain to another organization.

Name Servers

The programs that store information about the domain name space are called name servers. Name servers generally have complete information about some part of the domain name space, called a zone. The name server is then said to have authority for that zone. Name servers can be authoritative for multiple zones, too.

The difference between a zone and a domain is subtle. A zone contains the domain names and data that a domain contains, except for domain names and data that are delegated elsewhere. For example, the top-level domain ca (for Canada) may have the subdomains ab.ca, on.ca, and qb.ca, for the provinces Alberta, Ontario, and Quebec. Authority for the ab.ca, on.ca, and qb.ca domains may be delegated to organizations in each of the provinces. The domain ca contains all the data in ca plus all the data in ab.ca, on.ca, and qb.ca. But the zone ca contains only the data in ca (see Figure 28).

However, if a subdomain of the domain isn't delegated away, the zone contains the domain names and data in the subdomain. So the bc.ca and sk.ca (British Columbia and Saskatchewan) subdomains of the ca domain may exist, but not be delegated. (Perhaps the provincial authorities in B.C. and Saskatchewan aren't yet ready to manage the domain, but the authorities running the top-level ca domain want to preserve the consistency of the name space and implement domains for all the Canadian provinces right away.) In this case, the zone ca has a ragged bottom edge, containing bc.ca and sk.ca, but not the other ca subdomains, as shown in Figure 29.

So why do name servers load zones instead of domains? Because a domain might contain more information than the name server would need: it could contain data delegated to other name servers.

If you're just starting out, though, your domain probably won't have any subdomains. In this case, since there's no delegation going on, your domain and your zone contain the same data.

Delegating Domains

Even though you may not need to delegate parts of your domain just yet, it's helpful to understand a little more about how the process of delegating a domain works. Delegation, in the abstract, involves assigning responsibility for some part of your domain to another organization. What really happens, though, is the assignment of authority for your subdomains to different name servers. (Note that we said "name servers," not just "name server.")

Your data, instead of containing information about the subdomain you've delegated, includes pointers to the name servers authoritative for that subdomain. Now if one of your name servers is asked for data in the subdomain, it can reply with a list of the right name servers to talk to.

Types of Name Servers

The DNS specs define two types of name servers, primary masters and secondary masters. A primary master name server gets the data for the zones it's authoritative for from files on the host it runs on. A secondary master name server gets its zone data from another name server authoritative for the zone. When a secondary starts up, it contacts the name server it updates from and, if necessary, pulls the zone data over. This is referred to as a zone transfer.

DNS provides these two types of name servers to make administration easier. Once you've created the data for your zone and set up a primary master name server, you don't need to fool with copying that data from host to host to create new name servers for the zone. You simply set up secondary master name servers that load their data from the primary. Once they're set up, the secondaries will periodically query the primary to keep the zone data up to date.

This is important because it's a very good idea to set up more than one name server for any given zone. You'll want more than one for redundancy, to spread the load around, and to make sure that all the hosts in the zone have a name server close by. Using secondary master name servers makes this administratively workable.

Calling a given name server a primary master name server or a secondary master name server is a little silly, though. We mentioned earlier that a name server can be authoritative for more than one zone. Similarly, a name server can be a primary master for one zone, and a secondary master for another. Most name servers, however, are either primary for most of the zones they load or secondary for most of the zones they load. So if we call a particular name server a primary or a secondary, we mean that it's the primary or a secondary master for most of the zones it loads.

Data Files

The files that primary master name servers load their zone data from are called, simply enough, data files or zone files. We often refer to them as db files, short for database files. Secondary master name servers sometimes load their zone data from data files too. Secondaries are often configured to back up the zone data they transfer from a primary master name server to data files. If the secondary is later killed and restarted, it will read the backup data files first, then check to see whether the data are current. This both obviates the need to transfer the zone data if it hasn't changed, and provides a source of the data if the primary is down.

The data files contain resource records that describe the zone. The resource records describe all the hosts in the zone, and mark any delegation of subdomains. BIND also allows special directives to include the contents of other data files in a data file, much like the #include statement in C programming.

Resolvers

Resolvers are the clients that access name servers. Programs running on a host that need information from the domain name space use the resolver. The resolver handles:

In BIND, the resolver is just a set of library routines that are compiled into programs like telnet and ftp. They're not even separate processes. They have the smarts to put together a query, to send it and wait for an answer, and to resend the query if it isn't answered, but that's about all. Most of the burden of finding an answer to the query is placed on the name server. The DNS specs call this kind of resolver a stub resolver.

Other implementations of DNS have smarter resolvers, which can do more sophisticated things like build up a cache of information already retrieved from name servers. But these aren't nearly as common as the stub resolver implemented in BIND.

Resolution

Name servers are adept at retrieving data from the domain name space. They have to be, given the limited intelligence of some resolvers. Not only can they give you data about zones they're authoritative for, they can also search through the domain name space to find data they're not authoritative for. This process is called name resolution or simply resolution.

Because the name space is structured as an inverted tree, a name server only needs one piece of information to find its way to any point in the tree: the names and addresses of the root name servers (is that more than one piece?). A name server can issue a query to a root name server for any name in the domain name space, and the root name server will start the name server on its way.

Root Name Servers

The root name servers know where name servers authoritative for all the top-level domains are. (In fact, most of the root name servers are authoritative for the top-level, U.S. organizational domains.) Given a query about any domain name, the root name servers can at least provide the names and addresses of the name servers authoritative for the top-level domain the domain name is in. And those top-level name servers can provide the list of name servers authoritative for the second-level domain the domain name is in. Each name server queried gives the querier information about how to get "closer" to the answer it's seeking, or provides the answer itself.

The root name servers are clearly very important to resolution. Since they're so important, DNS provides mechanisms – like caching, which we'll discuss a little later – to help offload the root name servers. But in the absence of other information, resolution has to start at the root name servers. This makes the root name servers crucial to the operation of DNS; if all the Internet root name servers were unreachable for an extended period, all resolution on the Internet would fail. To protect against this, the Internet has nine root name servers (as of this writing), spread across different parts of the network. Some are on the MILNET, the U.S. military's portion of the Internet; one is on SPAN, NASA's internet; one is in Europe; and one is run by a commercial Internet connectivity provider.

Being the focal point for so many queries keeps the roots busy; even with nine, the traffic to each root name server is very high. A 1992 study by U.S.C. reported that their root name server received as many as 20,000 query packets in an hour, or almost six queries per second. More recent statistics from InterNIC show that their root name server, ns.internic.net, receives 255,600 queries per hour, or almost 71 queries per second.

Despite the load placed on root name servers, resolution on the Internet works quite well. Figure 210 shows the resolution process for the address of a real host in a real domain, including how the process corresponds to traversing the domain name space tree.

The local name server queries a root name server for the address of girigiri.gbrmpa.gov.au and is referred to the au name servers. It asks an au name server the same question, and is referred to the gov.au name servers. The gov.au name server refers the local name server to the gbrmpa.gov.au name servers. Finally, the local name server asks a gbrmpa.gov.au name server for the address, and gets the answer.

Recursion

You may have noticed a big difference in the amount of work done by the name servers in the previous example. Four of the name servers simply returned the best answer they already had – mostly referrals to other name servers – to the queries they received. They didn't have to send their own queries to find the data requested. But one name server – the one queried by the resolver – had to follow successive referrals until it received an answer.

Why couldn't it simply have referred the resolver to another name server? Because a stub resolver wouldn't have had the intelligence to follow a referral. And how did the name server know not to answer with a referral? Because the resolver issued a recursive query.

Queries come in two flavors, recursive and iterative, or simply nonrecursive. Recursive queries place most of the burden of resolution on a single name server. Recursion, or recursive resolution, is just a name for the resolution process used by a name server when it receives recursive queries.

Iteration or iterative resolution, on the other hand, refers to the resolution process used by a name server when it receives iterative queries.

In recursion, a resolver sends a recursive query to a name server for information about a particular domain name. The queried name server is then obliged to respond with the requested data, or with an error stating that data of the requested type don't exist or that the domain name specified doesn't exist.[6] The name server can't just refer the querier to a different name server, because the query was recursive.

If the queried name server isn't authoritative for the data requested, it will have to query other name servers to find the answer. It could send recursive queries to those name servers, thereby obliging them to find the answer and return it (and passing the buck). Or it could send iterative queries, and possibly be referred to other name servers "closer" to the domain name it's looking for. Current implementations are generally polite and do the latter, following the referrals until an answer is found.[7]

Iteration

Iterative resolution, on the other hand, doesn't require nearly as much work on the part of the queried name server. In iterative resolution, a name server simply gives the best answer it already knows back to the querier. There's no additional querying required. The queried name server consults its local data (including its cache, which we're about to talk about), looking for the data requested. If it doesn't find the data there, it makes its best attempt to give the querier data that will help it continue the resolution process. Usually these are the names and addresses of name servers "closer" to the data it's seeking.

What this amounts to is a resolution process that taken as a whole looks like Figure 211.

A resolver queries a local name server, which then queries a number of other name servers in pursuit of an answer for the resolver. Each name server it queries refers it to another name server authoritative for a zone further down in the name space and closer to the data sought. Finally the local name server queries the authoritative name server, which returns an answer.

Mapping Addresses to Names

One major piece of functionality missing from the resolution process as explained so far is how addresses get mapped back to names. Address-to-name mapping is used to produce output that is easier for humans to read and interpret (in log files, for instance). It's also used in some authorization checks. UNIX hosts map addresses to host names to compare against entries in .rhosts and hosts.equiv files, for example. When using host tables, address-to-name mapping is trivial. It requires a straightforward sequential search through the host table for an address. The search returns the official host name listed. In DNS, though, address-to-name mapping isn't so simple. Data, including addresses, in the domain name space are indexed by name. Finding an address given a domain name is relatively easy. But finding the domain name that maps to a given address would seem to require an exhaustive search of every domain name in the tree.

Actually, there's a better solution that's both clever and very effective. Since it's easy to find data once you're given the name that indexes that data, why not create a part of the domain name space that uses addresses as names? In the Internet's domain name space, this portion of the name space is the in-addr.arpa domain.

Nodes in the in-addr.arpa domain are named after the numbers in the dotted-octet representation of IP addresses. (Dotted-octet representation refers to the common method of expressing 32-bit IP addresses as four numbers in the range 0 to 255, separated by dots.) The in-addr.arpa domain, for example, could have up to 256 subdomains, one corresponding to each possible value in the first octet of an IP address. Each of these subdomains could have up to 256 subdomains of its own, corresponding to the possible values of the second octet. Finally, at the fourth level down, there are resource records attached to the final octet giving the full domain name of the host or network at that IP address. That makes for an awfully big domain: in-addr.arpa, shown in Figure 212, is roomy enough for every IP address on the Internet.

Note that when read as a domain name, the IP address appears backwards, since the name is read leaf-to-root. For example, if winnie.corp.hp.com has the IP address 15.16.192.152, the corresponding in-addr.arpa subdomain is 152.192.16.15.in-addr.arpa, which maps back to the domain name winnie.corp.hp.com.

IP addresses could have been represented the opposite way in the name space, with the first octet of the IP address at the bottom of the in-addr.arpa domain. That way, the IP address would have read correctly (forward) in the domain name.

However, IP addresses are hierarchical, just like domain names. Network numbers are doled out much as domain names are, and administrators can then subnet their address space and further delegate numbering. The difference is that IP addresses get more specific from left to right, while domain names get less specific from left to right. Figure 213 shows what we mean.

Making the first octets in the IP address appear highest in the tree gives administrators the ability to delegate authority for in-addr.arpa domains along network lines. For example, the 15.in-addr.arpa domain, which contains the reverse mapping information for all hosts whose IP addresses start with 15, can be delegated to the administrators of network 15. This would be impossible if the octets appeared in the opposite order. If the IP addresses were represented the other way around, 15.in-addr.arpa would consist of every host whose IP address ended with 15 – not a practical domain to try to delegate.

Inverse Queries

The in-addr.arpa name space is clearly only useful for IP address-to-domain name mapping, though. Searching for a domain name that indexes an arbitrary piece of data – something besides an address – in the domain name space would require another specialized name space like in-addr.arpa, or an exhaustive search.

That exhaustive search is to some extent possible, and it's called an inverse query. An inverse query is a search for the domain name that indexes a given datum. It's processed solely by the name server receiving the query. That name server searches all of its local data for the item sought and returns the domain name that indexes it, if possible. If it can't find the data, it gives up. No attempt is made to forward the query to another name server.

Since any one name server only knows about part of the overall domain name space, an inverse query is never guaranteed to return an answer. For example, if a name server receives an inverse query for an IP address it knows nothing about, it can't return an answer, but it also doesn't know that the IP address doesn't exist, since it only holds part of the DNS database. What's more, the implementation of inverse queries is optional according to the DNS specification; BIND 4.9.4 still contains the code that implements inverse queries, but it's commented out by default. Paul Vixie, the current maintainer of BIND, speaks highly critically of the feature, and we expect that he'll drop it from the next version of BIND. That's fine with us, since only archaic versions of nslookup actually still use inverse queries.

Caching

The whole resolution process may seem awfully convoluted and cumbersome to someone accustomed to simple searches through the host table. Actually, though, it's usually quite fast. One of the features that speeds it up considerably is caching.

A name server processing a recursive query may have to send out quite a few queries to find an answer. However, it discovers a lot of information about the domain name space as it does so. Each time it's referred to another list of name servers, it learns that those name servers are authoritative for some zone, and it learns the addresses of those servers. And, at the end of the resolution process, when it finally finds the data the original querier sought, it can store that data for future reference, too. With version 4.9.3 of BIND, name servers even implement negative caching: if an authoritative name server responds to a query with an answer that says that the type of information the querier is looking for doesn't exist for the domain name specified, the local name server will temporarily cache that information, too. Name servers cache all of this data to help speed up successive queries. The next time a resolver queries the name server for data about a domain name the name server knows something about, the process is shortened quite a bit. The name server may have cached the answer, positive or negative, in which case it simply returns the answer to the resolver. Even if it doesn't have the answer cached, it may have learned the identities of the name servers authoritative for the zone the domain name is in, and be able to query them directly.

For example, say our name server has already looked up the address of eecs.berkeley.edu. In the process, it cached the names and addresses of the eecs.berkeley.edu and berkeley.edu name servers (plus eecs.berkeley.edu's IP address). Now if a resolver were to query our name server for the address of baobab.cs.berkeley.edu, our name server could skip querying the root name servers. Recognizing that berkeley.edu is the closest ancestor of baobab.cs.berkeley.edu that it knows about, our name server would start by querying a berkeley.edu name server, as shown in Figure 214. On the other hand, if our name server had found out there was no address for eecs.berkeley.edu, the next time it received a query for the address it could simply have responded appropriately from its cache.

In addition to speeding up resolution, caching prevented us from having to query the root name servers again. This means that we're not as dependent on the roots, and they won't suffer as much from all our queries.

Time to Live

Name servers can't cache data forever, of course. If they did, changes to that data on the authoritative name servers would never reach the rest of the network. Remote name servers would just continue to use cached data. Consequently, the administrator of the zone that contains the data decides on a time to live, or TTL, for the data. The time to live is the amount of time that any name server is allowed to cache the data. After the time to live expires, the name server must discard the cached data and get new data from the authoritative name servers. This also applies to negatively cached data; a name server must time out a negative answer after a period, too, in case new data has been added on the authoritative name servers. However, the time to live for negatively cached data isn't tunable by the domain administrator; it's hardcoded to ten minutes.

Deciding on a time to live for your data is essentially deciding on a trade-off between performance and consistency. A small TTL will help ensure that data about your domain is consistent across the network, because remote name servers will time it out more quickly and be forced to query your authoritative name servers more often for new data. On the other hand, this will increase the load on your name servers and lengthen resolution time for information in your domain, on the average.

A large TTL will shorten the average time it takes to resolve information in your domain, since the data can be cached longer. The drawback is that your information will be inconsistent for a longer time if you make changes to your data on your name servers.

Enough of this theory – I'll bet you're antsy to get on with this. There's some homework necessary before you can set up your domain and your name servers, though, and we'll assign it in the next chapter.

[1] Clearly this is a computer scientist's tree, not a botanist's.
[2] One note of caution: don't confuse domains in the Domain Name System with domains in Sun's Network Information Service (NIS). Though an NIS domain also refers to a group of hosts, and both types of domains have similarly structured names, the concepts are quite different. NIS uses hierarchical names, but the hierarchy ends there: hosts in the same NIS domain share certain data about hosts and users, but they can't navigate the NIS name space to find data in other NIS domains.
[3] Note: The terms domain and subdomain are often used interchangeably, or nearly so, in DNS and BIND documentation. In this book, we use subdomain only as a relative term: a domain is a subdomain of another domain if the root of the subdomain is within the domain.
[4] Except for Great Britain. According to ISO 3166 and Internet tradition, Great Britain's top-level domain should be gb. Instead, most organizations in Great Britain and Northern Ireland (the United Kingdom) use the top-level domain uk. They drive on the wrong side of the road, too.
[5] Actually, there are a few more domains under us: one for Washington, D.C., one for Guam, and so on.
[6] The BIND 4.9.3 name server gives name server administrators the ability to refuse recursive queries; see Chapter 10, Advanced Features and Security, for more information. Why would you want to do this in the first place? If you were setting up a name server solely for the purpose of giving out data about your zone to other name servers, and didn't have any resolvers using it, refusing recursive queries would eliminate the possibility that anyone could steal valuable cycles from your name server by pointing their resolvers at it.
[7] The exception is a name server configured to use a forwarder. See Chapter 10, Advanced Features and Security, for more information on using forwarders.
[Next]