From DNS and
by Paul Albitz & Cricket Liu
In this chapter:
The Domain Name Space
The Internet Domain Name Space
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.
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.
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.
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).
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:
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 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.
|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.
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. 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.
lithium.cchem.berkeley.eduYou'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.comThis 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.usHere 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.comWe'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.
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.
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.
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.
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.
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.
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.
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.
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.
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. 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.
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.
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 188.8.131.52, the corresponding in-addr.arpa subdomain is 184.108.40.206.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.
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.
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.
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.