BUY THIS BOOK

Safari Books Online

What is this?

Looking to Reprint this content?

Envelope Tell a friend

DNS and BIND
DNS and BIND, Fourth Edition

By Paul Albitz, Cricket Liu

Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Background
Content preview·Buy reprint rights for this chapter
The White Rabbit put on his spectacles. "Where shall I begin, please your Majesty?" he asked.
"Begin at the beginning," the King said, very gravely, "and go on till you come to the end: then stop."
—
It's important to know a little ARPAnet history to understand the Domain Name System. DNS was developed to address particular problems on the ARPAnet, and the Internet—a descendant of the ARPAnet—remains its main user.
If you've been using the Internet for years, you can probably skip this chapter. If you haven't, we hope it'll give you enough background to understand what motivated the development of DNS.
In the late 1960s, the U.S. Department of Defense's Advanced Research Projects Agency, ARPA (later DARPA), began funding the ARPAnet, an experimental wide area computer network that connected important research organizations in the United States. The original goal of the ARPAnet was to allow government contractors to share expensive or scarce computing resources. From the beginning, however, users of the ARPAnet also used the network for collaboration. This collaboration ranged from sharing files and software and exchanging electronic mail—now commonplace—to joint development and research using shared remote computers.
The TCP/IP (Transmission Control Protocol/Internet Protocol) protocol suite was developed in the early 1980s and quickly became the standard host-networking protocol on the ARPAnet. The inclusion of the protocol suite in the University of California at Berkeley's popular BSD Unix operating system was instrumental in democratizing internetworking. BSD Unix was virtually free to universities. This meant that internetworking—and ARPAnet connectivity—was suddenly available cheaply to many more organizations than were previously attached to the ARPAnet. Many computers being connected to the ARPAnet were connected to local area networks (LANs), too, and very shortly the other computers on the LANs were communicating via the ARPAnet as well.
The network grew from a handful of hosts to tens of thousands of hosts. The original ARPAnet became the backbone of a confederation of local and regional networks based on TCP/IP, called the
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
A (Very) Brief History of the Internet
Content preview·Buy reprint rights for this chapter
In the late 1960s, the U.S. Department of Defense's Advanced Research Projects Agency, ARPA (later DARPA), began funding the ARPAnet, an experimental wide area computer network that connected important research organizations in the United States. The original goal of the ARPAnet was to allow government contractors to share expensive or scarce computing resources. From the beginning, however, users of the ARPAnet also used the network for collaboration. This collaboration ranged from sharing files and software and exchanging electronic mail—now commonplace—to joint development and research using shared remote computers.
The TCP/IP (Transmission Control Protocol/Internet Protocol) protocol suite was developed in the early 1980s and quickly became the standard host-networking protocol on the ARPAnet. The inclusion of the protocol suite in the University of California at Berkeley's popular BSD Unix operating system was instrumental in democratizing internetworking. BSD Unix was virtually free to universities. This meant that internetworking—and ARPAnet connectivity—was suddenly available cheaply to many more organizations than were previously attached to the ARPAnet. Many computers being connected to the ARPAnet were connected to local area networks (LANs), too, and very shortly the other computers on the LANs were communicating via the ARPAnet as well.
The network grew from a handful of hosts to tens of thousands of hosts. The original ARPAnet became the backbone of a confederation of local and regional networks based on TCP/IP, called the Internet.
In 1988, however, DARPA decided the experiment was over. The Department of Defense began dismantling the ARPAnet. Another network, funded by the National Science Foundation and called the NSFNET, replaced the ARPAnet as the backbone of the Internet.
Even more recently, in the spring of 1995, the Internet made a transition from using the publicly funded NSFNET as a backbone to using multiple commercial backbones, run by long-distance carriers like MCI and Sprint, and long-time commercial internetworking players like PSINet and UUNET.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
On the Internet and internets
Content preview·Buy reprint rights for this chapter
A word on "the Internet" and "internets" in general is in order. In print, the difference between the two seems slight: one is always capitalized, one isn't. The distinction in meaning, however, is significant. The Internet, with a capital "I," refers to the network that began its life as the ARPAnet and continues today as, roughly, the confederation of all TCP/IP networks directly or indirectly connected to commercial U.S. backbones. Seen close up, it's actually quite a few different networks—commercial TCP/IP backbones, corporate and U.S. government TCP/IP networks, and TCP/IP networks in other countries—interconnected by routers and high-speed digital circuits.
A lowercase internet, on the other hand, is simply any network made up of multiple smaller networks using the same internetworking protocols. An internet (little "i") isn't necessarily connected to the Internet (big "I"), nor does it necessarily use TCP/IP as its internetworking protocol. There are isolated corporate internets, and there are Xerox XNS-based internets and DECnet-based internets.
The relatively new term " intranet" is really just a marketing term for a TCP/IP-based "little i" internet, used to emphasize the use of technologies developed and introduced on the Internet within a company's internal corporate network. On the other hand, an "extranet" is a TCP/IP-based internet that connects partner companies to each other, or a company to its distributors, suppliers, and customers.
Through the 1970s, the ARPAnet was a small, friendly community of a few hundred hosts. A single file, HOSTS.TXT, contained all the information you needed to know about those hosts: it held name-to-address mappings for every host connected to the ARPAnet. The familiar Unix host table, /etc/hosts , was derived from HOSTS.TXT (mostly by deleting fields that Unix didn't use).
HOSTS.TXT was maintained by SRI's Network Information Center (dubbed "the NIC") and distributed from a single host, SRI-NIC. ARPAnet administrators typically emailed their changes to the NIC, and periodically FTPed to SRI-NIC and grabbed the current
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
The Domain Name System in a Nutshell
Content preview·Buy reprint rights for this chapter
The Domain Name System is a distributed database. This allows local control of the segments of the overall database, yet the data in each segment is available across the entire network through a client-server scheme. Robustness and adequate performance are achieved through replication and caching.
Programs called name servers constitute the server half of DNS's client-server mechanism. Name servers contain information about some segments of the database and make it available to clients, called resolvers. Resolvers are often just library routines that create queries and send them across a network to a name server.
The structure of the DNS database is very similar to the structure of the Unix filesystem, as shown in Figure 1-1. The whole database (or filesystem) is pictured as an inverted tree, with the root node at the top. Each node in the tree has a text label, which identifies the node relative to its parent. This is roughly analogous to a "relative pathname" in a filesystem, like bin. One label—the null label, or ""—is reserved for the root node. In text, the root node is written as a single dot ( .). In the Unix filesystem, the root is written as a slash ( / ).
Figure 1-1: The DNS database versus a Unix filesystem
Each node is also the root of a new subtree of the overall tree. Each of these subtrees represents a partition of the overall database—a "directory" in the Unix filesystem, or a domain in the Domain Name System. Each domain or directory can be further divided into additional partitions, called subdomains in DNS, like a filesystem's "subdirectories." Subdomains, like subdirectories, are drawn as children of their parent domains.
Like every directory, every domain has a unique name. A domain's domain name identifies its position in the database, much as a directory's "absolute pathname" specifies its place in the filesystem. In DNS, the domain name is the sequence of labels from the node at the root of the domain to the root of the whole tree, with dots separating the labels. In the Unix filesystem, a directory's absolute pathname is the list of relative names read from root to leaf (the opposite direction to DNS, as shown in Figure 1-2), using a slash to separate the names.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
The History of BIND
Content preview·Buy reprint rights for this chapter
The first implementation of the Domain Name System was called JEEVES, written by Paul Mockapetris himself. A later implementation was BIND, an acronym for Berkeley Internet Name Domain, which was written for Berkeley's 4.3 BSD Unix operating system by Kevin Dunlap. BIND is now maintained by the Internet Software Consortium.
BIND is the implementation we'll concentrate on in this book and is by far the most popular implementation of DNS today. It has been ported to most flavors of Unix and is shipped as a standard part of most vendors' Unix offerings. BIND has even been ported to Microsoft's Windows NT.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Must I Use DNS?
Content preview·Buy reprint rights for this chapter
Despite the usefulness of the Domain Name System, there are still some situations in which it doesn't pay to use it. There are other name resolution mechanisms besides DNS, some of which may be a standard part of your operating system. Sometimes the overhead involved in managing zones and their name servers outweighs the benefits. On the other hand, there are circumstances in which you have no other choice but to set up and manage name servers. Here are some guidelines to help you make that decision:
If you're connected to the Internet . . .
. . . DNS is a must. Think of DNS as the lingua franca of the Internet: nearly all of the Internet's network services use DNS. That includes the World Wide Web, electronic mail, remote terminal access, and file transfer.
On the other hand, this doesn't necessarily mean that you have to set up and run zones by yourself for yourself. If you have only a handful of hosts, you may be able to find an existing zone to become part of (see Chapter 3 ). Or you may be able to find someone else to host your zones for you. If you pay an Internet service provider for your Internet connectivity, ask if they'll host your zone for you, too. Even if you aren't already a customer, there are companies who will help out, for a price.
If you have a little more than a handful of hosts, or a lot more, then you'll probably want your own zone. And if you want direct control over your zone and your name servers, then you'll want to manage it yourself. Read on!
If you have your own TCP/IP-based internet . . .
. . . you probably want DNS. By an internet, we don't mean just a single Ethernet of workstations using TCP/IP (see the next section for that); we mean a fairly complex "network of networks." Maybe you have a forest of Appletalk nets and a handful of Apollo token rings.
If your internet is basically homogeneous and your hosts don't need DNS (say you have a big DECnet or OSI internet), then you may be able to do without it. But if you've got a variety of hosts, and especially if some of those run some variety of Unix, you'll want DNS. It'll simplify the distribution of host information and rid you of any kludgy host table distribution schemes you may have cooked up.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Chapter 2: How Does DNS Work?
Content preview·Buy reprint rights for this chapter
"... 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 "namespace." But 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 explain and illustrate the mechanisms that make DNS work. We also introduce the terms you'll need to know to read the rest of the book (and to converse intelligently with your fellow zone 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.
DNS's distributed database is indexed by domain names. Each domain name is essentially just a path in a large inverted tree, called the domain name space. The tree's hierarchical structure, shown in Figure 2-1, is similar to the structure of the Unix filesystem. The tree has a single root at the top. In the Unix filesystem, this is called the root directory, represented by a slash ( / ). DNS simply calls it "the root." Like a filesystem, DNS's tree can branch any number of ways at each intersection point, or node . The depth of the tree is limited to 127 levels (a limit you're not likely to reach).
Figure 2-1: The structure of the DNS namespace
Each node in the tree has a text label (without dots) that can be up to 63 characters long. A null (zero-length) label is reserved for the root. 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), with dots separating the names in the path.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
The Domain Name Space
Content preview·Buy reprint rights for this chapter
DNS's distributed database is indexed by domain names. Each domain name is essentially just a path in a large inverted tree, called the domain name space. The tree's hierarchical structure, shown in Figure 2-1, is similar to the structure of the Unix filesystem. The tree has a single root at the top. In the Unix filesystem, this is called the root directory, represented by a slash ( / ). DNS simply calls it "the root." Like a filesystem, DNS's tree can branch any number of ways at each intersection point, or node . The depth of the tree is limited to 127 levels (a limit you're not likely to reach).
Figure 2-1: The structure of the DNS namespace
Each node in the tree has a text label (without dots) that can be up to 63 characters long. A null (zero-length) label is reserved for the root. 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), with dots separating the names in the path.
If the root node's label actually appears in a node's domain name, the name looks as though it ends in a dot, as in "www.oreilly.com.". (It actually ends with a dot—the separator—and the root's null label.) When the root node's label 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 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 name 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—have different labels. This restriction guarantees that a domain name uniquely identifies a single node in the tree. The restriction isn't really a limitation, because the labels need to be unique only among the children, not among all the nodes in the tree. The same restriction applies to the Unix filesystem: you can't give two sibling directories or two files in the same directory the same name. Just as you can't have two
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
The Internet Domain Name Space
Content preview·Buy reprint rights for this chapter
So far, we've talked about the theoretical structure of the domain name space and what kind of data is 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 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, domain names follow certain traditions (not rules, really, as they can be and have been broken). These traditions help domain names from appearing totally chaotic. Understanding these traditions is an enormous asset if you're trying to decipher a domain name.
The original top-level domains divided the Internet domain name space organizationally into seven domains:
com
Commercial organizations, such as Hewlett-Packard (hp.com), Sun Microsystems (sun.com), and IBM (ibm.com).
edu
Educational organizations, such as UC Berkeley (berkeley.edu) and Purdue University (purdue.edu).
gov
Government organizations, such as NASA (nasa.gov) and the National Science Foundation (nsf.gov).
mil
Military organizations, such as the U.S. Army (army.mil ) and Navy (navy.mil ).
net
Formerly, organizations providing network infrastructure, such as NSFNET (nsf.net) and UUNET (uu.net). Since 1996, however, net, like com, has been open to any commercial organization.
org
Formerly, noncommercial organizations, such as the Electronic Frontier Foundation (eff.org ). Like net, however, restrictions on org were removed in 1996.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Delegation
Content preview·Buy reprint rights for this chapter
Remember that one of the main goals of the design of the Domain Name System was to decentralize administration? This is achieved through delegation. Delegating domains is a lot like delegating tasks at work. A manager may break up a large project 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 an organization becomes responsible for maintaining all the data in that subdomain. It can freely change the data, and even divide up its subdomain into more subdomains and delegate those. The parent domain retains 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, as shown in Figure 2-7.
Figure 2-7: stanford.edu is delegated to Stanford University
Not all organizations delegate away their whole domain, just as not all managers delegate all their work. A domain may have several delegated subdomains and also contain hosts that don't belong in the subdomains. For example, the Acme Corporation (which supplies a certain coyote with most of his gadgets) has a division in Rockaway and its headquarters in Kalamazoo, so it 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 to understand that the term delegation refers to assigning responsibility for a subdomain to another organization.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Name Servers and Zones
Content preview·Buy reprint rights for this chapter
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 (a zone), which they load from a file or from another name server. 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 important, but subtle. All top-level domains, and many domains at the second level and lower, such as berkeley.edu and hp.com, are broken into smaller, more manageable units by delegation. These units are called zones. The edu domain, shown in Figure 2-8, is divided into many zones, including the berkeley.edu zone, the purdue.edu zone, and the nwu.edu zone. At the top of the domain, there's also an edu zone. It's natural that the folks who run edu would break up the edu domain: otherwise, they'd have to manage the berkeley.edu subdomain themselves. It makes much more sense to delegate berkeley.edu to Berkeley. What's left for the folks who run edu? The edu zone, which would contain mostly delegation information for subdomains of edu.
Figure 2-8: The edu domain broken into zones
The berkeley.edu subdomain is, in turn, broken up into multiple zones by delegation, as shown in Figure 2-9. There are delegated subdomains called cc, cs, ce, me, and more. Each of these subdomains is delegated to a set of name servers, some of which are also authoritative for berkeley.edu. However, the zones are still separate, and may have a totally different group of authoritative name servers.
Figure 2-9: The berkeley.edu domain broken into zones
A zone and a domain may share the same domain name but contain different nodes. In particular, the zone doesn't contain any nodes in delegated subdomains. For example, the top-level domain ca (for Canada) has subdomains called ab.ca, on.ca, and qc.ca, for the provinces Alberta, Ontario, and Quebec. Authority for the ab.ca
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Resolvers
Content preview·Buy reprint rights for this chapter
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 the following tasks:
  • Querying a name server
  • Interpreting responses (which may be resource records or an error)
  • Returning the information to the programs that requested it
In BIND, the resolver is just a set of library routines linked into programs such as Telnet and FTP. It's not even a separate process. It has the smarts to put together a query, send it and wait for an answer, and 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 had smarter resolvers, which can do more sophisticated things such as 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.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Resolution
Content preview·Buy reprint rights for this chapter
Name servers are adept at retrieving data from the domain name space. They have to be, given the limited intelligence of most resolvers. Not only can they give you data from zones for which they're authoritative, they can also search through the domain name space to find data for which they're not authoritative. This process is called name resolution or simply resolution.
Because the namespace is structured as an inverted tree, a name server needs only one piece of information to find its way to any point in the tree: the domain 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 domain name in the domain name space, and the root name server starts the name server on its way.
The root name servers know where the authoritative name servers for each of the top-level zones are. (In fact, some of the root name servers are authoritative for the generic top-level zones.) Given a query about any domain name, the root name servers can provide at least the names and addresses of the name servers that are authoritative for the top-level zone that the domain name ends in. And the top-level name servers can provide the list of the authoritative name servers for the second-level zone that the domain name ends in. Each name server queried gives the querier information about how to get "closer" to the answer it's seeking, or it provides the answer itself.
The root name servers are clearly important to resolution. Because they're so important, DNS provides mechanisms—such as 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 13 root name servers (as of this writing) spread across different parts of the network. For example, one is on PSINet, a commercial Internet backbone; one is on the NASA Science Internet; two are in Europe; and one is in Japan.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Caching
Content preview·Buy reprint rights for this chapter
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. With Version 4.9 and all Version 8 and 9 BINDs, name servers even implement negative caching: if an authoritative name server responds to a query with an answer that says the domain name or datatype in the query doesn't exist, the local name server will temporarily cache that information, too. Name servers cache all 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. If the name server has cached the answer, positive or negative, 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 that are 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 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
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Chapter 3: Where Do I Start?
Content preview·Buy reprint rights for this chapter
"What do you call yourself?" the Fawn said at last. Such a soft sweet voice it had!
"I wish I knew!" thought poor Alice. She answered, rather sadly, "Nothing, just now."
"Think again," it said: "that won't do."
Alice thought, but nothing came of it. "Please, would you tell me what you call yourself?" she said timidly. "I think that might help a little."
"I'll tell you, if you come a little further on," the Fawn said. "I can't remember here."
—
Now that you understand the theory behind the Domain Name System, we can attend to more practical matters. Before you set up your zones, you may need to get the BIND software. Usually, it's included as a standard part of most Unix-based operating systems. Often, though, you'll want to seek out a more recent version with all the latest functionality and security enhancements.
Once you've got BIND, you need to decide on a domain name for your main zone—which may not be quite as easy as it sounds, since it entails finding an appropriate place in the Internet namespace. That decided, you need to contact the administrators of the parent of the zone whose domain name you've chosen.
One thing at a time, though. Let's talk about where to get BIND.
If you plan to set up your own zones and run name servers for them, you'll need the BIND software first. Even if you're planning on having someone else host your zones, it's helpful to have the software around. For example, you can use your local name server to test your data files before giving them to the administrator of your remote name servers.
Most commercial Unix vendors ship BIND with the rest of their standard TCP/IP networking software. And the networking software is usually included with the operating system, so you get BIND free. Even if the networking software is priced separately, you've probably already bought it, since you clearly do enough networking to need DNS, right?
If you don't have a version of BIND for your flavor of Unix, though, or if you want the latest, greatest version, you can always get the source code. As luck would have it, it's freely distributed. The source code for the most up-to-date versions of BIND as of this writing (the BIND 8.2.3 and 9.1.0 releases) is available via anonymous FTP from the Internet Software Consortium's web site,
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Getting BIND
Content preview·Buy reprint rights for this chapter
If you plan to set up your own zones and run name servers for them, you'll need the BIND software first. Even if you're planning on having someone else host your zones, it's helpful to have the software around. For example, you can use your local name server to test your data files before giving them to the administrator of your remote name servers.
Most commercial Unix vendors ship BIND with the rest of their standard TCP/IP networking software. And the networking software is usually included with the operating system, so you get BIND free. Even if the networking software is priced separately, you've probably already bought it, since you clearly do enough networking to need DNS, right?
If you don't have a version of BIND for your flavor of Unix, though, or if you want the latest, greatest version, you can always get the source code. As luck would have it, it's freely distributed. The source code for the most up-to-date versions of BIND as of this writing (the BIND 8.2.3 and 9.1.0 releases) is available via anonymous FTP from the Internet Software Consortium's web site, ftp.isc.org, in /isc/bind/src/cur/bind-8/bind-src.tar.gz and /isc/bind9/9.1.0/bind-9.1.0.tar.gz, respectively. Compiling these releases on most common Unix platforms is relatively straightforward. The ISC includes a list of Unix-ish operating systems that BIND is known to compile on in the file src/INSTALL, including several versions of Linux, Digital Unix, and Solaris 2. There's also a list of other Unix-ish and not-so-Unix-ish (MPE, anyone?) operating systems that BIND has supported in the past and that these most recent versions of BIND will probably compile on without much effort. Regardless of which category your operating system falls into, we strongly recommend reading all of the sections of src/INSTALL relevant to your OS. We also include instructions on compiling BIND 8.2.3 and 9.1.0 on RedHat Linux 6.2 as Appendix C. It's a remarkably short appendix.
Some of you may already have a version of BIND that came with your operating system, but you're wondering whether you need the latest, greatest version of BIND. What does it have to offer that earlier versions of BIND don't? Here's an overview:
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Choosing a Domain Name
Content preview·Buy reprint rights for this chapter
Choosing a domain name is more involved than it may sound because it entails both choosing a name and finding out who runs the parent zone. In other words, you need to find out where you fit in the Internet domain name space, then find out who runs that particular corner of that namespace.
The first step in picking a domain name is finding where in the existing domain name space you belong. It's easiest to start at the top and work your way down: decide which top-level domain you belong in, then which of that top-level domain's subdomains you fit into.
Note that to find out what the Internet domain name space looks like (beyond what we've already told you), you'll need access to the Internet. You don't necessarily need access to a host with name service already configured, but it would help a little. If you don't have access to a host with DNS configured, you'll have to "borrow" name service from other name servers (as in our previous ftp.isc.org example) to get you going.
Before we go any further, we need to define a few terms: registry, registrar,and registration. These terms aren't defined anywhere in the DNS specs. Instead, they apply to the way the Internet's namespace is managed today.
A registry is an organization responsible for maintaining a top-level domain's (well, zone's, really) data files, which contain the delegation to each subdomain of that top-level domain. Under the current structure of the Internet, a given top-level domain can have no more than one registry. A registrar acts as an interface between customers and the registry, providing registration and value-added services. It submits to the registry zone data and other data (including contact information) for each of its customers in a single top-level domain.
Registration , then, is the process by which a customer tells a registrar which name servers to delegate a subdomain to and provides the registrar with contact and billing information. The registrar then makes these changes through the registry.
Network Solutions Inc. acts as both the exclusive registry and as a registrar for the
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Chapter 4: Setting Up BIND
Content preview·Buy reprint rights for this chapter
"It seems very pretty," she said when she had finished it, "but it's rather hard to understand!" (You see she didn't like to confess, even to herself, that she couldn't make it out at all.) "Somehow it seems to fill my head with ideas—only I don't exactly know what they are!"
—
If you have been diligently reading each chapter of this book, you're probably anxious to get a name server running. This chapter is for you. Let's set up a couple of name servers. Others of you may have read the table of contents and skipped directly to this chapter. (Shame on you!) If you are one of those people, be aware that we may use concepts from earlier chapters and expect you to understand them already.
There are several factors that influence how you should set up your name servers. The biggest is what sort of access you have to the Internet: complete access (e.g., you can FTP to ftp.uu.net), limited access (restricted by a security firewall), or no access at all. This chapter assumes you have complete access. We'll discuss the other cases in Chapter 11.
In this chapter, we set up two name servers for a few fictitious zones as an example for you to follow in setting up your own zones. We cover the topics in this chapter in enough detail to get your first two name servers running. Subsequent chapters fill in the holes and go into greater depth. If you already have your name servers running, skim through this chapter to familiarize yourself with the terms we use or just to verify that you didn't miss something when you set up your servers.
Our fictitious zone serves a college. Movie University studies all aspects of the film industry and researches novel ways to distribute films. One of our most promising projects involves research into using IP as a film distribution medium. After visiting our registrar's web site, we have decided on the domain name movie.edu. A recent grant has enabled us to connect to the Internet.
Movie U. currently has two Ethernets, and we have plans to add another network or two. The Ethernets have network numbers 192.249.249/24 and 192.253.253/24. A portion of our host table contains the following entries:
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Our Zone
Content preview·Buy reprint rights for this chapter
Our fictitious zone serves a college. Movie University studies all aspects of the film industry and researches novel ways to distribute films. One of our most promising projects involves research into using IP as a film distribution medium. After visiting our registrar's web site, we have decided on the domain name movie.edu. A recent grant has enabled us to connect to the Internet.
Movie U. currently has two Ethernets, and we have plans to add another network or two. The Ethernets have network numbers 192.249.249/24 and 192.253.253/24. A portion of our host table contains the following entries:
127.0.0.1      localhost

# These are our killer machines

192.249.249.2  robocop.movie.edu robocop
192.249.249.3  terminator.movie.edu terminator bigt
192.249.249.4  diehard.movie.edu diehard dh

# These machines are in horror(ible) shape and will be replaced
# soon.

192.253.253.2  misery.movie.edu misery
192.253.253.3  shining.movie.edu shining
192.253.253.4  carrie.movie.edu carrie

# A wormhole is a fictitious phenomenon that instantly transports
# space travelers over long distances and is not known to be
# stable.  The only difference between wormholes and routers is
# that routers don't transport packets as instantly--especially
# ours.

192.249.249.1  wormhole.movie.edu wormhole wh wh249
192.253.253.1  wormhole.movie.edu wormhole wh wh253
And the network is pictured in Figure 4-1.
Figure 4-1: The Movie University network
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Setting Up Zone Data
Content preview·Buy reprint rights for this chapter
Our first step in setting up the Movie U. name servers is to translate the host table into equivalent DNS zone data. The DNS version of the data has multiple files. One file maps all the host names to addresses. Other files map the addresses back to host names. The name-to-address lookup is sometimes called forward mapping , and the address-to-name lookup reverse mapping . Each network has its own file for reverse-mapping data.
As a convention in this book, a file that maps host names to addresses is called db.DOMAIN . For movie.edu, this file is called db.movie.edu. The files mapping addresses to host names are called db.ADDR , where ADDR is the network number without trailing zeros or the specification of a netmask. In our example, the files are called db.192.249.249 and db.192.253.253; there's one for each network. The db is short for database. We'll refer to the collection of db.DOMAIN and db.ADDR files as zone data files . There are a few other zone data files: db.cache and db.127.0.0. These files are overhead. Each name server must have them, and they are more or less the same for each server.
To tie all the zone data files together, a name server needs a configuration file—for BIND Version 4, this file is usually called /etc/named.boot. For BIND Versions 8 and 9, it is usually called /etc/named.conf . The format of the zone data files is common to all DNS implementations: it's called the master file format. The format of the configuration files, on the other hand, is specific to the name server implementation—in this case, BIND.
Most entries in zone data files are called DNS resource records. DNS lookups are case-insensitive, so you can enter names in your zone data files in uppercase, lowercase, or mixed case. We tend to use all lowercase. However, even though lookups are case-insensitive, case is preserved. That way, if you add records for Tootsie.movie.edu to your zone data, people looking up
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Setting Up a BIND Configuration File
Content preview·Buy reprint rights for this chapter
Now that we've created the zone data files, a name server must be instructed to read each of the files. For BIND, the mechanism for pointing the server to its zone data files is the configuration file. Up to this point, we've been discussing files whose data and format are described in the DNS specifications. The configuration file, though, is specific to BIND and is not defined in the DNS RFCs.
The BIND configuration file syntax changed significantly between Version 4 and Version 8. Mercifully, it didn't change at all between BIND 8 and BIND 9. We'll first show you the BIND 4 syntax, and then the equivalent BIND 8 and 9 syntax. You'll have to check the named manual page to find out which you need to use. If you already have a BIND 4 configuration file, you can convert it to a BIND 8 or 9 configuration file by running the program named-bootconf, which is distributed with the BIND source code. In BIND 8, the program is in src/bin/named-bootconf . In BIND 9, it's in contrib/named-bootconf .
In BIND 4, comments in the configuration file are the same as in the zone data files—they start with a semicolon and stop at the end of the line:
; This is a comment
In BIND 8 and 9, you can use any of three styles of comments: C-style, C++-style, or shell-style:
/* This is a C-style comment */
// This is a C++-style comment
# This is a shell-style comment
Don't use a BIND 4-style comment in a BIND 8 or 9 configuration file—it won't work. The semicolon ends a configuration statement instead of starting a comment.
Usually, configuration files contain a line indicating the directory in which the zone data files are located. The name server changes its directory to this location before reading the zone data files. This allows the filenames to be specified relative to the current directory instead of as full pathnames. Here's how a BIND 4 directory line looks:
directory /var/named
Here's how a BIND 8 or 9 directory line looks:
options {
        directory "/var/named";
        // Place additional options here.
};
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Abbreviations
Content preview·Buy reprint rights for this chapter
At this point, we have created all the files necessary for a primary master name server. Let's go back and revisit the zone data files; there are shortcuts we didn't use. Unless you see and understand the long form first, though, the short form can look very cryptic. Now that you know the long form and have seen the BIND configuration file, we'll show you the shortcuts.
The second field of a primary directive (BIND 4) or zone statement (BIND 8 and 9) specifies a domain name. This domain name is the key to the most useful shortcut. This domain name is the origin of all the data in the zone data file. The origin is appended to all names in the zone data file that don't end in a dot, and will be different for each zone data file since each file describes a different zone.
Since the origin is appended to names, instead of entering robocop.movie.edu's address in db.movie.edu like this:
robocop.movie.edu.    IN A     192.249.249.2
we could have entered it like this:
robocop    IN A     192.249.249.2
In the db.192.24.249 file we entered this:
2.249.249.192.in-addr.arpa.  IN PTR robocop.movie.edu.
Since 249.249.192.in-addr.arpa is the origin, we could have entered:
2  IN PTR robocop.movie.edu.
Remember our earlier warning not to omit the trailing dot when using the fully qualified domain names? Suppose you forget the trailing dot. An entry like:
robocop.movie.edu    IN A     192.249.249.2
turns into an entry for robocop.movie.edu.movie.edu, not what you intended at all.
If a domain name is the same as the origin, the name can be specified as "@". This is most often seen in the SOA record in the zone data files. The SOA records could have been entered this way:
@ IN SOA terminator.movie.edu. al.robocop.movie.edu. (
                          1        ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 hour
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Host Name Checking (BIND 4.9.4 and Later Versions)
Content preview·Buy reprint rights for this chapter
If your name server is older than BIND 4.9.4 or is BIND 9 through 9.1.0, skip to the next section.
If your name server is BIND 4.9.4 or newer, you have to pay extra attention to how your hosts are named. Starting with Version 4.9.4, BIND checks host names for conformance to RFC 952. If a host name does not conform, BIND considers it a syntax error.
Before you panic, you need to know that this checking applies only to names that are considered host names. Remember, resource records have a name field and a data field; for example:
<name>      <class>  <type>  <data>
terminator  IN       A       192.249.249.3
Host names are in the name fields of A (address) and MX (covered in Chapter 5 ) records. Host names are also in the data fields of SOA and NS records. CNAMEs do not have to conform to the host naming rules because they can point to names that are not host names.
Let's look at the host naming rules. Host names are allowed to contain alphabetic characters and numeric characters in each label. The following are valid host names:
ID4            IN A 192.249.249.10
postmanring2x  IN A 192.249.249.11
A hyphen is allowed if it is in the middle of a label:
fx-gateway     IN A 192.249.249.12
Underscores are not allowed in host names.
Names that are not host names can consist of any printable ASCII character.
If a resource record data field calls for a mail address (as in SOA records), the first label, since it is not a host name, can contain any printable character, but the rest of the labels must follow the host name syntax just described. For example, a mail address has the following syntax:
<ASCII-characters>.<hostname-characters>
For example, if your mail address is key_grip@movie.edu, you can use it in an SOA record even with the underscore. Remember, in a mail address you replace the "@" with a "." like this:
movie.edu. IN SOA terminator.movie.edu. key_grip.movie.edu. (
                          1        ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 hour
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Tools
Content preview·Buy reprint rights for this chapter
Wouldn't it be handy to have a tool to translate your host table into master file format? There is such a beast, written in Perl: h2n, a host table-to-master file converter. You can use h2n to create your zone data files the first time and then maintain your data manually. Or you can use h2n over and over again. As you've seen, the host table's format is much simpler to understand and modify correctly than master file format. So, you could maintain /etc/hosts and rerun h2n to update your zone data files after each modification.
If you plan to use h2n, you might as well start with it, since it uses /etc/hosts—not your hand-crafted zone data—to generate the new zone data files. We could have saved ourselves a lot of work by generating the sample zone data files in this chapter with the following:
% h2n -d movie.edu -s terminator -s robocop \
            -n 192.249.249 -n 192.253.253 \
            -u al.robocop.movie.edu
(To generate a BIND 8 or 9 configuration file, add -v 8 to the option list.)
The -d and -n options specify the domain name of your forward-mapping zone and your network numbers. You'll notice that the names of the zone data files are derived from these options. The -s options list the authoritative name servers for the zones to use in the NS records. The -u (user) is the email address in the SOA record. We cover h2n in more detail in Chapter 7, after we've covered how DNS affects email.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Running a Primary Master Name Server
Content preview·Buy reprint rights for this chapter
Now that you've created your zone data files, you are ready to start a couple of name servers. You'll need to set up two name servers: a primary master name server and a slave name server. Before you start a name server, though, make sure that the syslog daemon is running. If the name server reads the configuration file and zone data files and sees an error, it logs a message to the syslog daemon. If the error is bad enough, the name server exits.
At this point, we assume the machine you are running on has the BIND name server and the support tool nslookup installed. Check the named manual page to find the directory the name server executable is in and verify that the executable is on your system. On BSD systems, the name server started its life in /etc, but may have migrated to /usr/sbin. Other places to look for named are /usr/etc/in.named and /usr/sbin/in.named. The following descriptions assume that the name server is in /usr/sbin.
To start up the name server, you must become root. The name server listens for queries on a reserved port, so it requires root privileges. The first time you run it, start the name server from the command line to test that it is operating correctly. Later, we'll show you how to start up the name server automatically when your system boots.
The following command starts the name server. We ran it on the host terminator.movie.edu:
# /usr/sbin/named
This command assumes that your configuration file is /etc/named.boot (BIND 4) or /etc/named.conf (BIND 8 or 9). You can put your configuration file elsewhere, but you have to tell the name server where it is using the -c command-line option:
# /usr/sbin/named -c conf-file
The first thing to do after starting your name server is to check the syslog file for error messages. If you are not familiar with syslog, look at the syslog.conf manual page for a description of the syslog configuration file, or the syslogd manual page for a description of the
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Running a Slave Name Server
Content preview·Buy reprint rights for this chapter
You need to set up another name server for robustness. You can (and probably will eventually) set up more than two authoritative name servers for your zones. Two name servers are the minimum—if you have only one name server and it goes down, no one can look up domain names. A second name server splits the load with the first server or handles the whole load if the first server is down. You could set up another primary master name server, but we don't recommend it. Instead, set up a slave name server. You can always change a slave name server into a primary master name server later if you decide to expend the extra effort it takes to run multiple primary master name servers.
How does a server know if it's the primary master or a slave for a zone? The named.conf file tells the name server whether it is the primary master or a slave on a per-zone basis. The NS records don't tell us which server is the primary master for a zone and which servers are slaves—they only say who the servers are. (Globally, DNS doesn't care; as far as the actual name resolution goes, slave servers are as good as primary master servers.)
What's the difference between a primary master name server and a slave name server? The crucial difference is where the server gets its data. A primary master name server reads its data from zone data files. A slave name server loads its data over the network from another name server. This process is called a zone transfer.
A slave name server is not limited to loading zones from a primary mastername server; it can also load from another slave server.
The big advantage of slave name servers is that you maintain only one set of zone data files for a zone, the ones on the primary master name server. You don't have to worry about synchronizing the files among name servers; the slaves do that for you. The caveat is that a slave does not resynchronize instantly—it polls to see if its zone data is current. The polling interval is one of those numbers in the SOA record that we haven't explained yet. (BIND Versions 8 and 9 support a mechanism to speed up the distribution of zone data, which we'll describe later.)
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Adding More Zones
Content preview·Buy reprint rights for this chapter
Now that you have your name servers running, you might want to support more zones. What needs to be done? Nothing special, really. All you need to do is add more primary or secondary statements (BIND 4) or zone statements (BIND 8 and 9) to your configuration file. You can even add secondary lines to your primary master server and primary lines to your slave server. (You may have already noticed that your slave server is primary master for 0.0.127.in-addr.arpa.)
At this point, it's useful to repeat something we said earlier in this book. Calling a given name server a primary master name server or a slave name server is a little silly. Name servers can be—and usually are—authoritative for more than one zone. A name server can be a primary master for one zone and a slave for another. Most name servers, however, are either primary master for most of the zones they load or slave for most of the zones they load. So if we call a particular name server a primary master or a slave, we mean that it's the primary master or a slave for most of the zones it loads.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
What Next?
Content preview·Buy reprint rights for this chapter
In this chapter, we showed you how to create name server zone data files by translating /etc/hosts to equivalent name server data, and also how to set up a primary master and a slave name server. There is more work to do to complete setting up your local zones, however: you need to modify your zone data for email and configure the other hosts in your zone to use your name servers. You may also need to start up more name servers. These topics are covered in the next few chapters.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Chapter 5: DNS and Electronic Mail
Content preview·