Inhaltsverzeichnis von DNS and BIND

Inhaltsvorschau

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). DNS was developed to address particular problems on the ARPAnet, and the Internet—a descendant of the ARPAnet—is still 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 Transmission Control Protocol/Internet Protocol (TCP/IP) 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—were suddenly available cheaply to many more organizations than were previously attached to the ARPAnet. Many of the computers being connected to the ARPAnet were being connected to local area networks (LANs), too, and very shortly the other computers on the LANs were communicating via the ARPAnet as well.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

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 Transmission Control Protocol/Internet Protocol (TCP/IP) 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—were suddenly available cheaply to many more organizations than were previously attached to the ARPAnet. Many of the computers being connected to the ARPAnet were being 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, the NSFNET, funded by the National Science Foundation, replaced the ARPAnet as the backbone of the Internet.

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 telecommunications companies such as SBC and Sprint, and long-time commercial internetworking players such as MFS and UUNET.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

A word on "the Internet," and on "internets" in general, is in order. In print, the difference between the two seems slight: one is always capitalized, one isn't. The distinction between their meanings, 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 up close, 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 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, for example.

An intranet, with a little i, is really just a TCP/IP-based internet, used to emphasize the use of technologies developed and introduced on the Internet on a company's internal corporate network. An extranet, on the other hand, is a TCP/IP-based internet that connects partner companies, 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 a name-to-address mapping for every host connected to the ARPAnet. The familiar Unix host table, /etc/hosts, was compiled from HOSTS.TXT (mostly by deleting fields 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 FTP'ed to SRI-NIC and grabbed the current HOSTS.TXT file. Their changes were compiled into a new

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Domain Name System is a distributed database. This structure allows local control of the segments of the overall database, yet 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 nameservers constitute the server half of DNS's client/server mechanism. Nameservers contain information about some segments of the database and make that information available to clients, called resolvers . Resolvers are often just library routines that create queries and send them across a network to a nameserver.

The structure of the DNS database, shown in Figure 1-1, is similar to the structure of the Unix filesystem. 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.

Every domain has a unique name, like every directory. A domain's

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

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, written by Kevin Dunlap for Berkeley's 4.3 BSD Unix. BIND is now maintained by the Internet Systems 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, Windows 2000, and Windows Server 2003.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Despite the usefulness of the Domain Name System, there are 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 nameservers outweighs the benefits. On the other hand, there are circumstances in which you have no other choice but to set up and manage nameservers. 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 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've only got a handful of hosts, you may be able to join an existing zone (see Chapter 3) or find someone else to host your zones for you. If you pay an Internet service provider for your Internet connectivity, ask if it'll host your zone for you, too. Even if you aren't already a customer, there are companies that will help out, for a price.

If you have a little more than a handful of hosts, or a lot more, you'll probably want your own zone. And if you want direct control over your zone and your nameservers, 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 if you thought that was what we meant); we mean a fairly complex "network of networks." Maybe you have several dozen Ethernet segments connected via routers, for example.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

" . . . 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 nameservers, 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'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 zone administrators).

First, though, let's take a more detailed look at the 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 namespace. 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 and is 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.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

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 namespace. 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 and is 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.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

So far, we've talked about the theoretical structure of the domain namespace and what sort 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 it doesn't attach any particular meaning to the labels at a given level of the namespace. When you manage a part of the domain namespace, 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 namespace, however, has some self-imposed structure to it. Especially in the upper-level domains, the domain names follow certain traditions (not rules, really, because they can be and have been broken). These traditions help to keep 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 namespace 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 U.C. Berkeley (berkeley.edu) and Purdue University (purdue.edu).
gov: Government organizations, such as NASA (nasa.gov) and the National Science Foundation (

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

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 works 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 subdomain can be delegated to other organizations, which means that an organization becomes responsible for maintaining all the data in that subdomain. It can freely change the data and even divide 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 (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 contain hosts that don't belong in the subdomains. For example, the Acme Corporation (it supplies 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 United States would fit better under acme.com than under either subdomain.

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

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The programs that store information about the domain namespace are called nameservers. Nameservers generally have complete information about some part of the domain namespace, called a zone, which they load from a file or from another nameserver. The nameserver is then said to have authority for that zone. Nameservers 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 contains mostly delegation information for the 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 subdomain is delegated to a set of nameservers, some of which are also authoritative for berkeley.edu. However, the zones are still separate and may have totally different groups of authoritative nameservers.

Figure 2-9: The berkeley.edu domain broken into zones

A zone contains all the domain names the domain with the same domain name contains, except for domain names in delegated subdomains. For example, the top-level domain

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

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

Querying a nameserver
Interpreting responses (which may be resource records or an error)
Returning the information to the programs that requested it

In BIND, the resolver is a set of library routines that is linked to programs such as ssh and ftp. It's not even a separate process. The resolver relies almost entirely on the nameservers it queries: it has 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 nameserver. The DNS specs call this kind of resolver a stub resolver.

Other implementations of DNS have had smarter resolvers that could do more sophisticated things that had more advanced capabilities, such as following referrals to locate the nameservers authoritative for a particular zone.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Nameservers are adept at retrieving data from the domain namespace. They have to be, given the limited intelligence of most resolvers. Not only can they give you data about zones for which they're authoritative, they can also search through the domain namespace 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 nameserver needs only one piece of information to find its way to any point in the tree: the domain names and addresses of the root nameservers (is that more than one piece?). A nameserver can issue a query to a root nameserver for any domain name in the domain namespace, and the root nameserver will start the nameserver on its way.

The root nameservers know where the authoritative nameservers for each of the top-level zones are. (In fact, some of the root nameservers are authoritative for some of the generic top-level zones.) Given a query about any domain name, the root nameservers can at least provide the names and addresses of the nameservers that are authoritative for the top-level zone the domain name ends in. In turn, the top-level nameservers can provide the list of authoritative nameservers for the second-level zone that the domain name ends in. Each nameserver queried either gives the querier information about how to get "closer" to the answer it's seeking or provides the answer itself. The root nameservers 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 nameservers. But in the absence of other information, resolution has to start at the root nameservers. This makes the root nameservers crucial to the operation of DNS; if all the Internet root nameservers were unreachable for an extended period, all resolution on the Internet would fail. To protect against this, the Internet has 13 root nameservers (as of this writing) spread across different parts of the network. One is on PSINet, a commercial Internet backbone; one is on the NASA Science Internet; two are in Europe; and one is in Japan.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

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 nameserver 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 namespace as it does so. Each time it's referred to another list of nameservers, it learns that those nameservers are authoritative for some zone, and it learns the addresses of those servers. 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. The BIND nameserver even implements negative caching: if a nameserver responds to a query with an answer that says the domain name or data type in the query doesn't exist, the local nameserver will also temporarily cache that information.

Nameservers cache all this data to help speed up successive queries. The next time a resolver queries the nameserver for data about a domain name the nameserver knows something about, the process is shortened quite a bit. The nameserver 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 nameservers that are authoritative for the zone the domain name is in and be able to query them directly.

For example, say our nameserver 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 nameservers (plus eecs.berkeley.edu's IP address). Now if a resolver were to query our nameserver for the address of baobab.cs.berkeley.edu, our nameserver could skip querying the root nameservers. Recognizing that berkeley.edu is the closest ancestor of baobab.cs.berkeley.edu that it knows about, our nameserver would start by querying a

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"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 standard in 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 have BIND, you need to decide on a domain name for your main zone; this may not be quite as easy as it sounds because it entails finding an appropriate place in the Internet namespace. With 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 nameservers for them, you first need the BIND software. Even if you plan to have someone else run the nameservers for your zones, it's helpful to have the software around. For example, you can use a local nameserver to test your zone datafiles before giving them to your remote nameserver administrator.

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.4.7 and 9.3.2 releases) is available via anonymous FTP from the Internet Software Consortium's web site,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

If you plan to set up your own zones and run nameservers for them, you first need the BIND software. Even if you plan to have someone else run the nameservers for your zones, it's helpful to have the software around. For example, you can use a local nameserver to test your zone datafiles before giving them to your remote nameserver administrator.

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.4.7 and 9.3.2 releases) is available via anonymous FTP from the Internet Software Consortium's web site, ftp.isc.org, in /isc/bind/src/8.4.7/bind-src.tar.gz and /isc/bind9/9.3.2/bind-9.3.2.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 (for BIND 8) and README (for BIND 9), including several versions of Linux, Unix, and even Windows. There's also a list of other Unix-ish and not-so-Unix-ish (MPE, anyone?) operating systems BIND has supported in the past, most recent versions of BIND will probably compile on these systems without much effort. Regardless of which category your operating system falls into, we strongly recommend reading all of the sections of the file that are relevant to your OS. In Appendix C, we also include instructions for compiling BIND 8.4.7 and 9.3.2 on Linux; it's a remarkably short appendix.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

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 namespace, then find out who runs that particular corner of the namespace.

The first step in picking a domain name is finding where in the existing domain namespace 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 in order to find out what the Internet domain namespace looks like (beyond what we've already told you), you'll need access to the Internet. You don't need access to a host that already has name service 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 nameservers (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 namespace is managed today.

A registry is an organization responsible for maintaining a top-level domain's (well, zone's, really) datafiles, 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 registries, providing registration and value-added services. Once a customer has chosen a subdomain of a top-level zone, the customer's registrar submits to the appropriate registry the zone data necessary to delegate that subdomain to the nameservers the customer specified. The registries act, more or less, as wholesalers of delegation in their top-level zone. The registrars then act as retailers, usually reselling delegation in more than one registry.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"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 nameserver running. This chapter is for you. Let's set up a couple of nameservers. 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 nameservers. The biggest is what sort of access you have to the Internet: complete access (e.g., you can FTP to ftp.rs.internic.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 nameservers 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 nameservers running. Subsequent chapters fill in the holes and go into greater depth. If you already have your nameservers 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 (legally) 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.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Our fictitious zone serves a college. Movie University studies all aspects of the film industry and researches novel ways to (legally) 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 main machines



192.249.249.2  shrek.movie.edu shrek

192.249.249.3  toystory.movie.edu toystory toys

192.249.249.4  monsters-inc.movie.edu monsters-inc mi



# 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

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Our first step in setting up the Movie U. nameservers 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 hostnames to addresses. Other files map the addresses back to hostnames. 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 hostnames to addresses is called db.DOMAIN. For movie.edu, this file is called db.movie.edu. The files mapping addresses to hostnames 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 datafiles. There are a few other zone datafiles: db.cache and db.127.0.0. These files are overhead. Each nameserver must have them, and they are more or less the same for each server.

To tie all the zone datafiles together, a nameserver needs a configuration file; for BIND versions 8 and 9, it is usually called named.conf. The format of the zone datafiles 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 nameserver implementation—in this case, BIND.

Most entries in zone datafiles are called DNS resource records. DNS lookups are case-insensitive, so you can enter names in your zone datafiles 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 Titanic.movie.edu to your zone data, people looking up titanic.movie.edu will find the records, but with a capital "T" in the domain name.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now that we've created the zone datafiles, a nameserver must be instructed to read each file. For BIND, the mechanism for pointing the server to its zone datafiles is the configuration file. Up to this point, we've been discussing files whose data and format are described in the DNS specifications. The syntax of 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. BIND 4 came out so long ago that we are not going to cover its configuration here. You'll have to find an earlier edition of our book (you should be able to find a cheap used copy) if you are still running one of those ancient beasts. In the configuration file, 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

Usually, configuration files contain a line indicating the directory in which the zone datafiles are located. The nameserver changes its directory to this location before reading the zone datafiles. This allows the filenames to be specified relative to the current directory instead of as full pathnames. Here's how a directory line looks in an options statement:


options {

        directory "/var/named";

        // Place additional options here.

};

Only one options statement is allowed in the configuration file, so any additional options mentioned later in this book must be added along with the directory option.

On a primary server, the configuration file contains one zone statement for each zone datafile to be read. Each line starts with the keyword zone followed by the zone's domain name and the class (in stands for Internet). The type master indicates this server is a primary nameserver. The last line contains the filename:


zone "movie.edu" in {

      type master;

      file "db.movie.edu";

};

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

At this point, we have created all the files necessary for a primary nameserver. Let's go back and revisit the zone datafiles; 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 zone statement 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 datafile. The origin is appended to all names in the zone datafile that don't end in a dot and will be different for each zone datafile because each file describes a different zone.

Since the origin is appended to names, instead of entering shrek.movie.edu's address in db.movie.edu like this:


shrek.movie.edu.    IN A     192.249.249.2

we could have entered it like this:


shrek    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 shrek.movie.edu.

Because 249.249.192.in-addr.arpa is the origin, we could have entered:


2  IN PTR shrek.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:


shrek.movie.edu    IN A     192.249.249.2

turns into an entry for shrek.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 datafiles. The SOA records could have been entered this way:


@ IN SOA toystory.movie.edu. al.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

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

If your nameserver is BIND 4.9.4 or newer (and most are), you have to pay extra attention to how your hosts are named. Starting with Version 4.9.4, BIND checks hostnames for conformance to RFC 952. If a hostname 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 hostnames. Remember, resource records have a name field and a data field—for example:


<name>      <class>  <type>  <data>

toystory    IN       A       192.249.249.3

Hostnames are in the name fields of A (address) and MX (covered in Chapter 5) records. Hostnames 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 hostnames.

Let's look at the host-naming rules. Hostnames are allowed to contain alphabetic characters and numeric characters in each label. The following are valid hostnames:


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 hostnames.

Names that are not hostnames 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 hostname, can contain any printable character, but the rest of the labels must follow the hostname 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 toystory.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

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

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 datafiles 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 the master file format. So, you could maintain /etc/hosts and rerun h2n to update your zone datafiles after each modification.

If you plan to use h2n, you might as well start with it, because it uses /etc/hosts—not your hand-crafted zone data—to generate the new zone datafiles. We could have saved ourselves a lot of work by generating the sample zone datafiles in this chapter with the following:


% h2n -d movie.edu -s toystory -s shrek \

-n 192.249.249 -n 192.253.253 \

-u al.movie.edu

(To generate a BIND 4 configuration file, add -v 4 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 datafiles are derived from these options. The -s options list the authoritative nameservers 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.

If you are running BIND 9, you have handy new tools to help maintain your nameserver files: named-checkconf and named-checkzone. These tools reside in /usr/local/sbin. As you might guess, named-checkconf checks the configuration file for syntax errors, and named-checkzone checks a zone file for syntax errors.

First, run named-checkconf, which checks /etc/named.conf by default:


% named-checkconf

If you have an error, named-checkconf displays an error message, such as this one:


/etc/named.conf:14: zone '.': missing 'file' entry

If there are no errors, you won't see any output.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now that you've created your zone datafiles, you are ready to start a couple of nameservers. You'll need to set up two nameservers: a primary nameserver and a slave nameserver. Before you start a nameserver, though, make sure that the syslog daemon is running. If the nameserver reads the configuration file and zone datafiles and sees an error, it logs a message to the syslog daemon. If the error is bad enough, the nameserver exits. If you've run the BIND 9 named-checkconf and named-checkzone, you should be all set, but check for syslog errors anyway, just to be safe.

At this point, we assume the machine you are running on has the BIND nameserver and the support tool nslookup installed. Check the named manual page to find the directory the nameserver executable is in and verify that the executable is on your system. On BSD systems, the nameserver 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 nameserver is in /usr/sbin.

To start up the nameserver, you must become root. The nameserver listens for queries on a reserved port, so it requires root privileges. The first time you run it, start the nameserver from the command line to test that it is operating correctly. Later, we'll show you how to start up the nameserver automatically when your system boots.

The following command starts the nameserver. We ran it on the host toystory.movie.edu.


# /usr/sbin/named

This command assumes that your configuration file is called /etc/named.conf. You can put your configuration file elsewhere, but then you have to tell the nameserver where it is using the -c command-line option:


# /usr/sbin/named -c conf-file

The first thing to do after starting your nameserver 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

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

You need to set up another nameserver for robustness. You can (and probably will eventually) set up more than two authoritative nameservers for your zones. Two nameservers are the minimum; if you have only one nameserver, and it goes down, no one can look up domain names. A second nameserver splits the load with the first server or handles the whole load if the first server is down. You could set up another primary nameserver, but we don't recommend it. Instead, set up a slave nameserver. You can always change a slave nameserver to a primary nameserver if you decide to expend the extra effort it takes to run multiple primary nameservers.

How does a server know if it's the primary or a slave for a zone? The named.conf file tells the nameserver whether it is the primary or a slave on a per-zone basis. The NS records don't tell us which server is the primary 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 servers.)

What's the difference between a primary nameserver and a slave nameserver? The crucial difference is where the server gets its data. A primary nameserver reads its data from zone datafiles. A slave nameserver loads its data over the network from another nameserver. This process is called a zone transfer.

A slave nameserver is not limited to loading zones from a primary nameserver; it can also load from another slave server.

The big advantage of slave nameservers is that you maintain only one set of zone datafiles for a zone, the ones on the primary nameserver. You don't have to worry about synchronizing the files among nameservers; 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 mechanisms to speed up the distribution of zone data, which we'll describe later.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now that you have your nameservers running, you might want to support more zones. What needs to be done? Nothing special, really. All you need to do is add more zone statements to your configuration file. You can even make your primary a slave server for some zones and make your slave server primary for some zones. (You may have already noticed that your slave server is primary 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 nameserver a primary nameserver or a slave nameserver is a little silly. Nameservers can be—and usually are—authoritative for more than one zone. A nameserver can be a primary for one zone and a slave for another. Most nameservers, however, are either primary for most of the zones they load or slave for most of the zones they load. So if we call a particular nameserver a primary or a slave, we mean that it's the primary or a slave for most of the zones it loads.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this chapter, we showed you how to create nameserver zone datafiles by translating /etc/hosts to equivalent nameserver data, and how to set up a primary and a slave nameserver. 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 nameservers. You may also need to start up more nameservers. These topics are covered in the next few chapters.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"And here Alice began to get rather sleepy, and went on saying to herself, in a dreamy sort of way, "Do cats eat bats? Do cats eat bats?" and sometimes "Do bats eat cats?" for, you see, as she couldn't answer either question, it didn't much matter which way she put it."

—

I'll bet you're drowsy too, after that looong chapter. Thankfully, this next chapter discusses a topic that will probably be very interesting to you system administrators and postmasters: how DNS affects electronic mail. And even if it isn't interesting to you, at least it's shorter than the last chapter.

One of the advantages of the Domain Name System over host tables is its support of advanced mail routing. When mailers had only the HOSTS.TXT file (and its derivative, /etc/hosts) to work with, the best they could do was to attempt delivery to a host's IP address. If that failed, they could either defer delivery of the message and try again later or bounce the message back to the sender.

DNS offers a mechanism for specifying backup hosts for mail delivery. The mechanism also allows hosts to assume mail-handling responsibilities for other hosts. This lets diskless hosts that don't run mailers, for example, have mail addressed to them processed by their servers.

DNS, unlike host tables, allows arbitrary names to represent electronic mail destinations. You can—and most organizations on the Internet do—use the domain name of your main forward-mapping zone as an email destination. Or you can add domain names to your zone that are purely email destinations and don't represent any particular host. A single logical email destination may also represent several mail servers. With host tables, mail destinations were hosts, period.

Together, these features give administrators much more flexibility in configuring electronic mail on their networks.

DNS uses a single type of resource record to implement enhanced mail routing: the MX record. Originally, the MX record's function was split between two records—the MD (mail destination) and MF (mail forwarder) records. MD specified the final destination to which a message addressed to a given domain name should be delivered. MF specified a host that would forward mail on to the eventual destination, should that destination be unreachable.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

DNS uses a single type of resource record to implement enhanced mail routing: the MX record. Originally, the MX record's function was split between two records—the MD (mail destination) and MF (mail forwarder) records. MD specified the final destination to which a message addressed to a given domain name should be delivered. MF specified a host that would forward mail on to the eventual destination, should that destination be unreachable.

Early experience with DNS on the ARPAnet showed that separating the functions didn't work very well. A mailer needed both the MD and MF records attached to a domain name (if both existed) to decide where to send mail; one or the other alone wouldn't do. But an explicit lookup of one type or another (either MD or MF) would cause a nameserver to cache just that record type. So mailers either had to do two queries, one for MD and one for MF records, or they could no longer accept cached answers. This meant that the overhead of running mail was higher than that of running other services, which was eventually deemed unacceptable.

The two records were integrated into a single record type, MX, to solve this problem. Now a mailer just needed all the MX records for a particular domain name destination to make a mail-routing decision. Using cached MX records was fine, as long as the TTLs matched.

MX records specify a mail exchanger for a domain name: a host that will either process or forward mail for the domain name (through a firewall, for example). Processing the mail means either delivering it to the individual to whom it's addressed or gatewaying it to another mail transport, such as X.400. Forwarding means sending it to its final destination or to another mail exchanger closer to the destination via SMTP, the Internet's Simple Mail Transfer Protocol. Sometimes forwarding the mail involves queuing it for some amount of time, too.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

At movie.edu, we have a single mail hub, postmanrings2x.movie.edu. postmanrings2x runs both an SMTP server and an IMAP server with accounts for all movie.edu mail users.

To direct mail servers on the Internet to send mail addressed to users at movie.edu to our mail hub, we add this MX record to db.movie.edu:


movie.edu.  IN  MX  10 postmanrings2x.movie.edu.

Our ISP runs a backup SMTP server as a service for customers; it will queue mail for us if our mail server or our connection to the Internet fails. To tell Internet mailers to try it if postmanrings2x isn't available, we add another MX record to the movie.edu zone datafile:


movie.edu.  IN  MX  20 smtp.isp.net.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The idea of a mail exchanger is probably new to many of you, so let's go over it in a little more detail. A simple analogy should help here: imagine that a mail exchanger is an airport, and instead of setting up MX records to instruct mailers where to send messages, you're advising your in-laws as to which airport to fly into when they come to visit you.

Say you live in Los Gatos, California. The closest airport for your in-laws to fly into is San Jose, the second closest is San Francisco, and the third Oakland. (We'll ignore other factors such as price of the ticket, Bay Area traffic, etc.) Don't see the parallel? Then picture it like this:


los-gatos.ca.us.    IN    MX    1 san-jose.ca.us.

los-gatos.ca.us.    IN    MX    2 san-francisco.ca.us.

los-gatos.ca.us.    IN    MX    3 oakland.ca.us.

The MX list is just an ordered list of destinations that tells mailers (your in-laws) where to send messages (fly) if they want to reach a given email destination (your house). The preference value tells them how desirable it is to use that destination; think of it as a logical "distance" from the eventual destination (in any units you choose), or simply as a "top 10"-style ranking of the proximity of those mail exchangers to the final destination.

With this list, you're saying, "Try to fly into San Jose, and if you can't get there, try San Francisco and Oakland, in that order." It also says that if you reach San Francisco, you should take a commuter flight to San Jose. If you wind up in Oakland, you should try to get a commuter to San Jose or at least to San Francisco.

What makes a good mail exchanger, then? The same qualities that make a good airport:

Size: You wouldn't want to fly into tiny Reid-Hillview Airport to get to Los Gatos, because the airport's not equipped to handle large planes or many people. (You'd probably be better off landing a big jet on Interstate 280 than at Reid-Hillview.) Likewise, you don't want to use an emaciated, underpowered host as a mail exchanger; it won't be able to handle the load.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

That's the basic idea behind MX records and mail exchangers, but there are a few more wrinkles you should know about. To avoid routing loops, mailers need to use a slightly more complicated algorithm than what we've described when they determine where to send mail.

Imagine what would happen if mailers didn't check for routing loops. Let's say you send mail from your workstation to nuts@oreilly.com, raving (or raging) about the quality of this book. Unfortunately, ora.oreilly.com is down at the moment. No problem! Recall oreilly.com's MX records:


oreilly.com.    IN    MX    0  ora.oreilly.com.

oreilly.com.    IN    MX    10 ruby.oreilly.com.

oreilly.com.    IN    MX    10 opal.oreilly.com.

Your mailer falls back and sends your message to ruby.oreilly.com, which is up. ruby.oreilly.com's mailer then tries to forward the mail on to ora.reilly.com but can't because ora.oreilly.com is down. Now what? Unless ruby.oreilly.com checks the sanity of what she is doing, she'll try to forward the message to opal.oreilly.com or maybe even to herself. That's certainly not going to help get the mail delivered. If ruby.oreilly.com sends the message to herself, we have a mail-routing loop. If ruby.oreilly.com sends the message to opal.oreilly.com, opal.oreilly.com will either send it back to ruby.oreilly.com or send it to herself, and we again have a mail-routing loop.

To prevent this from happening, mailers discard certain MX records before they decide where to send a message. A mailer sorts the list of MX records by preference value and looks in the list for the canonical domain name of the host on which it's running. If the local host appears as a mail exchanger, the mailer discards that MX record and all MX records in which the preference value is equal or higher (that is, equally or less-preferred mail exchangers). That prevents the mailer from sending messages to itself or to mailers "farther" from the eventual destination.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In addition to using MX records stored in DNS to determine where to send mail, some modern mail servers can now use other data in DNS to authenticate a message's sender. In particular, several recently proposed email authentication mechanisms use resource records to store critical information. While a complete description of any of these proposals is beyond the scope of this book, we'd like to introduce you to the most widely deployed of them, with a particular emphasis on how it uses DNS.

We'll cover SPF, the Sender Policy Framework, both because it's the most widely deployed of these authentication mechanisms and because it's fairly simple to describe. SPF allows a company's postmaster—maybe with the cooperation of his friendly DNS administrator—to specify which mail servers are allowed to send email addressed from the organization's domain names. It's a little like the opposite function of the MX record: an MX record tells a mailer to send mail addressed to a particular domain name to particular mail servers, while SPF information tells a mailer which mail servers can send mail addressed from a particular domain name.

Here's a simple example: Say O'Reilly Media's postmaster knows that all legitimate oreilly.com email is sent from one of two SMTP servers, smtp1.oreilly.com and smtp2.oreilly.com. He can advertise this fact in DNS by adding a TXT record to the domain name oreilly.com (or by asking whomever administers the oreilly.com zone to do it for him). Here's one possible TXT record that accomplishes this:


oreilly.com.  IN  TXT  "v=spf1 +a:smtp1.oreilly.com +a:smtp2.oreilly.com -all"

The tag v=spf1 at the beginning of the record-specific data identifies this TXT record as an SPF record. This is needed because TXT records can be used for many purposes, including human-readable comments, and you wouldn't want Internet mail servers trying to interpret your comments as SPF instructions. If SPF takes off, it will eventually receive its own, dedicated record type, SPF, and the tag will become unnecessary.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"They were indeed a queer-looking party that assembled on the bank—the birds with draggled feathers, the animals with their fur clinging close to them, and all dripping wet, cross, and uncomfortable."

—

Now that you or someone else in your organization has set up nameservers for your zones, you'll want to configure the hosts on your network to use them. That involves configuring those hosts' resolvers, which you can do by telling the resolvers which nameservers to query and which domain names to search. This chapter covers these topics and describes configuring the resolver in many common versions of Unix and in Microsoft's Windows 2000, 2003, and XP (which are basically the same).

We introduced resolvers way back in Chapter 2, but we didn't say much more about them. The resolver, you'll remember, is the client half of the Domain Name System. It's responsible for translating a program's request for host information into a query to a nameserver and for translating the response into an answer for the program.

We haven't done any resolver configuration yet, because the occasion for it hasn't arisen. When we set up our nameservers in Chapter 4, the resolver's default behavior worked just fine for our purposes. But if we'd needed the resolver to do more than or behave differently from the default, we would have had to configure the resolver.

There's one thing we should mention up front: what we'll be describing in the next few sections is the behavior of the vanilla BIND 8.4.6 resolver in the absence of other naming services. Not all resolvers behave quite this way; some vendors still ship resolvers based on earlier versions of the BIND code, and some have implemented special resolver functionality that lets you modify the resolver algorithm. Whenever we think it's important, we'll point out differences between the behavior of the 8.4.6 BIND resolver and that of earlier resolvers, particularly the 4.8.3 and 4.9 resolvers, which many vendors were shipping when we last updated this book. We'll cover various vendors' extensions later in this chapter.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We introduced resolvers way back in Chapter 2, but we didn't say much more about them. The resolver, you'll remember, is the client half of the Domain Name System. It's responsible for translating a program's request for host information into a query to a nameserver and for translating the response into an answer for the program.

We haven't done any resolver configuration yet, because the occasion for it hasn't arisen. When we set up our nameservers in Chapter 4, the resolver's default behavior worked just fine for our purposes. But if we'd needed the resolver to do more than or behave differently from the default, we would have had to configure the resolver.

There's one thing we should mention up front: what we'll be describing in the next few sections is the behavior of the vanilla BIND 8.4.6 resolver in the absence of other naming services. Not all resolvers behave quite this way; some vendors still ship resolvers based on earlier versions of the BIND code, and some have implemented special resolver functionality that lets you modify the resolver algorithm. Whenever we think it's important, we'll point out differences between the behavior of the 8.4.6 BIND resolver and that of earlier resolvers, particularly the 4.8.3 and 4.9 resolvers, which many vendors were shipping when we last updated this book. We'll cover various vendors' extensions later in this chapter.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

So what exactly does the resolver allow you to configure? Most resolvers let you configure at least three aspects of the resolver's behavior: the local domain name, the search list, and the nameserver(s) that the resolver queries. Many Unix vendors also allow you to configure other resolver behavior through nonstandard extensions to DNS. Sometimes these extensions are necessary to cope with other software, such as Sun's Network Information Service (NIS); sometimes they're simply value added by the vendor.

Almost all resolver configuration is done in the file /etc/resolv.conf (this might be /usr/etc/resolv.conf or something similar on your host—check the resolver manual page, usually in section 4 or 5, to make sure). There are five main configuration directives you can use in resolv.conf: the domain directive, the search directive, the nameserver directive, the sortlist directive, and the options directive. These directives control the behavior of the resolver. There are other, vendor-specific directives available on some versions of Unix; we'll discuss them at the end of this chapter.

The local domain name is the domain name in which the resolver resides. In most situations, it's the domain name of the zone in which you'd find the host running the resolver. For example, the resolver on the host toystory.movie.edu would probably use movie.edu as its local domain name.

The resolver uses the local domain name to interpret domain names that aren't fully qualified. For example, when you add an entry such as:


relay bernie

to your .rhosts file, the name relay is assumed to be in your local domain. This makes a lot more sense than allowing access to a user called bernie on every host on the Internet whose domain name starts with relay. Other authorization files such as hosts.equiv and hosts.lpd work the same way.

Normally, the local domain name is determined from the host's hostname; the local domain name is everything after the first "." in the name. If the name doesn't contain a ".", the local domain is assumed to be the root domain. So the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

So much for theory—let's now go over what resolv.conf files look like on real hosts. Resolver configuration needs vary depending on whether a host runs a local nameserver, so we'll cover both cases: hosts with local nameservers and hosts with remote nameservers.

We, as the administrators of movie.edu, have just been asked to configure a professor's new standalone workstation, which doesn't run a nameserver. Deciding which domain the workstation belongs in is easy: there's only movie.edu to choose from. However, she is working with researchers at Pixar on new shading algorithms, so perhaps it'd be wise to put pixar.com in her workstation's search list. The search directive:


search movie.edu pixar.com

makes movie.edu her workstation's local domain name and searches pixar.com for names not found in movie.edu.

The new workstation is on the 192.249.249/24 network, so the closest nameservers are wormhole.movie.edu (192.249.249.1) and toystory.movie.edu (192.249.249.3). As a rule, you should configure hosts to use the closest nameserver available first. (The closest possible nameserver is a nameserver on the local host; the next closest is a nameserver on the same subnet or network.) In this case, both nameservers are equally close, but we know that wormhole.movie.edu is bigger (it's a faster host, with more capacity). So the first nameserver directive in resolv.conf should be:


nameserver 192.249.249.1

Since this particular professor is known to get awfully vocal when she has problems with her computer, we'll also add toystory.movie.edu (192.249.249.3) as a backup nameserver. That way, if wormhole.movie.edu is down for any reason, the professor's workstation can still get name service (assuming toystory.movie.edu and the rest of the network are up).

The resolv.conf file ends up looking like this:


search movie.edu pixar.com

nameserver 192.249.249.1

nameserver 192.249.249.3

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now that you've configured your host to use DNS, what's going to change? Will your users be forced to type long domain names? Will they have to change their mail addresses and mailing lists?

Thanks to the search list, much of this will continue working as before. There are some exceptions, though, and some notable differences in the way that some programs behave when they use DNS. We'll try to cover all the common ones.

As you've seen earlier in this chapter, programs such as telnet, ftp, rlogin, and rsh apply the search list to domain name arguments that aren't dot-terminated. That means that if you're in movie.edu (i.e., your local domain name is movie.edu, and your search list includes movie.edu), you can type either:


% telnet misery

or:


% telnet misery.movie.edu

or even:


% telnet misery.movie.edu.

and get to the same place. The same holds true for the other services, too. There's one other behavioral difference you may benefit from: because a nameserver may return more than one IP address when you look up an address, modern versions of Telnet, FTP, and web browsers try to connect to the first address returned, and if the connection is refused or times out, for example, they try the next, and so on:


% ftp tootsie

ftp: connect to address 192.249.249.244: Connection timed out

Trying 192.253.253.244...

Connected to tootsie.movie.edu.

220 tootsie.movie.edu FTP server (Version 16.2 Fri Apr 26

    18:20:43 GMT 1991) ready.

Name (tootsie: guest):

And remember that with the resolv.conf sortlist directive, you can even control the order in which your applications try those IP addresses.

One oddball service is NFS. The mount command can handle domain names just fine, and you can put domain names into /etc/fstab (your vendor may call it /etc/checklist), too. But watch out for /etc/exports and /etc/netgroup. /etc/exports controls which filesystems you allow various clients to NFS-mount. You can also assign a name to a group of hosts in

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In addition to configuring the resolver for DNS queries, you may be able to configure which service is used to obtain name and address information. The most common file used by vendors is nsswitch.conf, which we will cover here. Some vendors use irs.conf or netsvc.conf. Check your system's manual pages for details on these files.

/etc/nsswitch.conf is used to configure the order in which a number of different sources are checked. You select the database you want to configure by specifying a keyword. For naming services, the database name is hosts. The possible sources for the hosts database are dns, nis, nisplus, and files (which refers to /etc/hosts in this case). Configuring the order in which the sources are consulted is a simple matter of listing them after the database name in that order. For example:


hosts:  dns files

has the resolver try DNS (i.e., query a nameserver) first, then check /etc/hosts. By default, resolution moves from one source to the next (e.g., falls back to /etc/hosts from DNS) if the first source isn't available or the name being looked up isn't found. You can modify this behavior by specifying a condition and an action in square brackets between the sources. The possible conditions are:

UNAVAIL: The source hasn't been configured (in DNS's case, there is no resolv.conf file, and there is no nameserver running on the local host).
NOTFOUND: The source can't find the name in question (for DNS, the name looked up or the type of data looked up doesn't exist).
TRYAGAIN

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We'll cover the resolver in Windows XP because most modern Windows resolvers—Windows 2000, Windows Server 2003—look similar and act similarly. This resolver can be a little tough to find; its configuration is well hidden. To get to it, click on Start, then Control Panel, then Network and Internet Connections, then Network Connections. This brings up the window shown in Figure 6-1.

Figure 6-1: Windows XP Network Connections

Right-click on Local Area Connection and choose Properties. This brings up a window like the one shown in Figure 6-2.

Figure 6-2: Windows XP Local Area Connection Properties

Double-click on Internet Protocol (TCP/IP). This posts the basic resolver configuration window shown in Figure 6-3.

Figure 6-3: Basic Windows XP resolver configuration

If you check the Obtain DNS server address automatically radio button, the resolver queries the nameservers that the local DHCP server tells it to use. If you check the Use the following DNS server addresses radio button, the resolver queries the nameservers you specify in the Preferred DNS server and Alternate DNS server fields.

To get at more advanced resolver configuration, click on (what else?) the Advanced . . . button. Click on the DNS tab, and you'll see the window in Figure 6-4.

Figure 6-4: Advanced Windows XP resolver configuration

If you've specified the addresses of nameservers to query in the basic resolver configuration window, you'll see them again at the top of this window, under

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"Well, in our country," said Alice, still panting a little, "you'd generally get to somewhere else—if you ran very fast for a long time as we've been doing."

—

"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"

This chapter discusses a number of related topics pertaining to nameserver maintenance. We'll talk about controlling nameservers, modifying zone datafiles, and keeping the root hints file up to date. We'll list common syslog error messages and explain the statistics BIND keeps.

This chapter doesn't cover troubleshooting problems. Maintenance involves keeping your data current and watching over your nameservers as they operate. Troubleshooting involves putting out fires—those little DNS emergencies that flare up periodically. Firefighting is covered in Chapter 14.

Traditionally, administrators have controlled the BIND nameserver, named, with Unix signals. The nameserver interprets the receipt of certain signals as instructions to take particular actions, such as reloading all the primary zones that have changed. However, there are a limited number of signals available, and signals offer no means of passing along additional information such as the domain name of a particular zone to reload.

In BIND 8.2, the ISC introduced a method of controlling the nameserver by sending messages to it on a special control channel. The control channel can be either a Unix domain socket or a TCP port that the nameserver listens on for messages. Because the control channel isn't limited to a finite number of discrete signals, it's more flexible and powerful. The ISC says that the control channel is the way of the future and that administrators should use it, rather than signals, for all nameserver management.

You send messages to a nameserver via the control channel using a program called ndc (in BIND 8) or rndc (in BIND 9). Prior to BIND 8.2,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Traditionally, administrators have controlled the BIND nameserver, named, with Unix signals. The nameserver interprets the receipt of certain signals as instructions to take particular actions, such as reloading all the primary zones that have changed. However, there are a limited number of signals available, and signals offer no means of passing along additional information such as the domain name of a particular zone to reload.

In BIND 8.2, the ISC introduced a method of controlling the nameserver by sending messages to it on a special control channel. The control channel can be either a Unix domain socket or a TCP port that the nameserver listens on for messages. Because the control channel isn't limited to a finite number of discrete signals, it's more flexible and powerful. The ISC says that the control channel is the way of the future and that administrators should use it, rather than signals, for all nameserver management.

You send messages to a nameserver via the control channel using a program called ndc (in BIND 8) or rndc (in BIND 9). Prior to BIND 8.2, ndc was simply a shell script that allowed you to substitute convenient arguments (such as reload) for signals (such as HUP). We'll talk about that version of ndc later in this chapter.

Executed without arguments, ndc will try to communicate with a nameserver running on the local host by sending messages through a Unix domain socket. The socket is usually called /var/run/ndc, though some operating systems use a different pathname. The socket is normally owned by root and is readable and writable only by the owner. BIND 8.2 and later nameservers create the Unix domain socket when they start up. You can specify an alternate pathname or permissions for the socket using the controls statement. For example, to change the socket's path to /etc/ndc and group ownership to named, and to make the socket readable and writable by both owner and group, you can use:


controls {

    unix "/etc/ndc" perm 0660 owner 0 group 53;  // group 53 is "named"

};

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Something is always changing on your network—new workstations arrive, you finally retire or sell the relic, or you move a host to a different network. Each change means that zone datafiles must be modified. Should you make the changes manually? Or should you wimp out and use a tool to help you?

First, we'll discuss how to make the changes manually. Then, we'll talk about a tool to help out: h2n. Actually, we recommend that you use a tool to create the zone datafiles; we were kidding about that wimp stuff, okay? Or at least use a tool to increment the serial number for you. The syntax of zone datafiles lends itself to making mistakes. It doesn't help that the address and pointer records are in different files, which must agree with each other. However, even when you use a tool, it is critical to know what goes on when the files are updated, so we'll start with the manual method.

After creating your zone datafiles initially, it should be fairly apparent what you need to change when you add a new host. We'll go through the steps here in case you weren't the one to set up those files or if you'd just like a checklist to follow. Make these changes to your primary nameserver's zone datafiles. If you make the changes to your slave nameserver's backup zone datafiles, the slave's data will change, but the next zone transfer will overwrite it.

Update the serial number in db.DOMAIN. The serial number is likely to be at the top of the file, so it's easy to do first and reduces the chance that you'll forget.
Add any A (address), CNAME (alias), and MX (mail exchanger) records for the host to the db.DOMAIN file. We added the following resource records to the db.movie.edu file when a new host (cujo) was added to our network:
```
cujo  IN  A  192.253.253.5  ; cujo's internet address

      IN MX  10 cujo        ; if possible, mail directly to cujo

      IN MX  20 toystory    ; otherwise, deliver to our mail hub
```

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Back when you first set up your zones, organizing your files was simple: you put them all in a single directory. There was one configuration file and a handful of zone datafiles. Over time, though, your responsibilities grew. More networks were added and hence more in-addr.arpa zones. Maybe you delegated a few subdomains. You started backing up zones for other sites. After a while, an ls of your nameserver directory no longer fit on a single screen. It's time to reorganize. BIND has a few features that will help with this reorganization.

BIND nameservers support a configuration file statement, called include, which allows you to insert the contents of a file into the current configuration file. This lets you take a very large configuration file and break it into smaller pieces.

Zone datafiles (for all BIND versions) support two control statements: $ORIGIN and $INCLUDE. The $ORIGIN statement changes a zone datafile's origin, and $INCLUDE inserts a new file into the current zone datafile. These control statements are not resource records; they facilitate the maintenance of DNS data. In particular, they make it easier for you to divide your zone into subdomains by allowing you to store the data for each subdomain in a separate file.

One way to organize your zone datafiles is to store them in separate directories. If your nameserver is a primary for several sites' zones (both forward- and reverse-mapping), you can store each site's zone datafiles in its own directory. Another arrangement might be to store all the primary zones' datafiles in one directory and all the backup zone datafiles in another. Let's look at what the configuration file might look like if you chose to split up your primary and slave zones:


options { directory "/var/named"; };

//

// These files are not specific to any zone

//

zone "." {

        type hint;

        file "db.cache";

};

zone "0.0.127.in-addr.arpa" {

        type master;

        file "db.127.0.0";

};

//

// These are our primary zone files

//

zone "movie.edu" {

        type master;

        file "primary/db.movie.edu";

};

zone "249.249.192.in-addr.arpa" {

        type master;

        file "primary/db.192.249.249";

};

zone "253.253.192.in-addr.arpa" {

        type master;

        file "primary/db.192.253.253";

};

//

// These are our slave zone files

//

zone "ora.com" {

        type slave;

        file "slave/bak.ora.com";

        masters { 198.112.208.25; };

};

zone "208.112.192.in-addr.arpa" {

        type slave;

        file "slave/bak.198.112.208";

        masters { 198.112.208.25; };

};

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

BIND allows you to change the name and location of the following system files: named.pid, named-xfer, named_dump.db, and named.stats. Most of you will not need to use this feature; don't feel obligated to change the names or locations of these files just because you can.

If you do change the location of the files written by the nameserver (named.pid, named_dump.db, or named.stats), for security reasons you should choose a directory that is not world-writable. While we don't know of any break-ins caused by writing these files, you should follow this guideline just to be safe.

named.pid's full path is usually /var/run/named.pid or /etc/named.pid. One reason you might change the default location of this file is if you find yourself running more than one nameserver on a single host. Yikes! Why would someone do that? Well, Chapter 10 gives an example of running two nameservers on one host (and explains the rationale behind it). You can specify a different named.pid file in the configuration file for each server:


options { pid-file "server1.pid"; };

named-xfer's path is usually /usr/sbin/named-xfer or /etc/named-xfer. You'll remember that named-xfer is used by a slave nameserver for inbound zone transfers. One reason you might change the default location is to build and test a new version of BIND in a local directory; your test version of named can be configured to use the local version of named-xfer:


options { named-xfer "/home/rudy/named/named-xfer"; };

Since BIND 9 doesn't use named-xfer, of course, there's not much call for this substatement with BIND 9.

The nameserver writes named_dump.db into its current directory when you tell it to dump its database. Here's an example of how to change the location of the dump file:


options { dump-file "/home/rudy/named/named_dump.db"; };

The nameserver writes named.stats into its current directory when you tell it to dump statistics. Here's an example of how to change its location:


options { statistics-file "/home/rudy/named/named.stats"; };

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

BIND supports extensive logging, which consists of writing information to a debug file and sending information to syslog. Extensive logging has its costs, though; there's a lot to learn before you can effectively configure this subsystem. If you don't have time to experiment with logging, use the defaults and come back to this topic later. Most of you won't need to change the default logging behavior.

There are two main concepts in logging: channels and categories. A channel specifies where logged data goes: to syslog, to a file, to named's standard error output, or to the bit bucket. A category specifies what data is logged. In the BIND source code, most messages the nameserver logs are categorized according to the function of the code they relate to. For example, a message produced by the part of BIND that handles dynamic updates is probably in the update category. We'll give you a list of the categories shortly.

Each category of data can be sent to a single channel or to multiple channels. In Figure 7-1, queries are logged to a file while zone transfer data is both logged to a file and to syslog.

Figure 7-1: Logging categories to channels

Channels allow you to filter by message severity. Here's the list of severities, from most severe to least:


critical

error

warning

notice

info

debug [level]

dynamic

The top five severities (critical, error, warning, notice, and info) are the familiar severity levels used by syslog. The other two (debug and dynamic) are unique to BIND.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

A significant part of maintenance is being aware that something is wrong before it becomes a real problem. If you catch a problem early, chances are it'll be that much easier to fix. As the old adage says, an ounce of prevention is worth a pound of cure.

This isn't quite troubleshooting—we'll devote an entire chapter to troubleshooting later—think of it more as "pre-troubleshooting." Troubleshooting (the pound of cure) is what you have to do after your problem has developed complications and you need to identify the problem by its symptoms.

The next two sections deal with preventative maintenance: looking periodically at the syslog file and at the BIND nameserver statistics to see whether any problems are developing. Consider this a nameserver's medical checkup.

There are a large number of syslog messages that named can emit. In practice, you'll see only a few of them. We'll cover the most common syslog messages here, excluding reports of syntax errors in zone datafiles.

Every time you start named, it sends out a message at priority LOG_NOTICE. For a BIND 8 nameserver, it looks like this:


Jan 10 20:48:32 toystory named[3221]: starting.  named 8.2.3 Tue May 16 09:39:40

MDT 2000 cricket@huskymo.boulder.acmebw.com:/usr/local/src/bind-8.2.3/src/bin/

named

For BIND 9, it's significantly abridged:


Jul 27 16:18:41 toystory named[7045]: starting BIND 9.3.2

This message logs the fact that named started at this time and tells you the version of BIND you're running as well as who built it and where (for BIND 8). Of course, this is nothing to be concerned about. It is a good place to look if you're not sure what version of BIND your operating system supports.

Every time you send the nameserver a reload command, a BIND 8 nameserver sends out this message at priority LOG_NOTICE:


Jan 10 20:50:16 toystory named[3221]: reloading nameserver

Here's the BIND 9 nameservers log:


Jul 27 16:27:45 toystory named[7047]: loading configuration from

                '/etc/named.conf'

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"What size do you want to be?" it asked.

"Oh, I'm not particular as to size," Alice hastily replied; "only one doesn't like changing so often, you know . . . "

"Are you content now?" said the Caterpillar.

"Well, I should like to be a little larger, sir, if you wouldn't mind . . . "

—

We set up two nameservers in Chapter 4. Two servers are as few as you'll ever want to run and, depending on the size of your network, you may need to run many more. It is not uncommon to run four or more nameservers, with one of them off-site. How many nameservers are enough? You'll have to decide that based on your network. Here are some guidelines to help out:

Run at least one nameserver on each network or subnet you have. This removes routers as a point of failure. Make the most of any multihomed hosts you may have because they are (by definition) attached to more than one network.
If you have a file server and some diskless nodes, run a nameserver on the file server to serve this group of machines.
Run nameservers near, but not necessarily on, large multiuser computers. The users and their processes probably generate a lot of queries, and, as an administrator, you will work harder to keep a multiuser host up. But balance their needs against the risk of running a nameserver—a security-critical server—on a system to which lots of people have access.
Run at least one nameserver off-site. This makes your data available when your network isn't. You might argue that it's useless to look up an address when you can't reach the host. Then again, the off-site nameserver may be available if your network is reachable, but your other nameservers are down. If you have a close relationship with an organization on the Internet—say another university, your ISP, or a business partner—they may be willing to run a slave for you.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We set up two nameservers in Chapter 4. Two servers are as few as you'll ever want to run and, depending on the size of your network, you may need to run many more. It is not uncommon to run four or more nameservers, with one of them off-site. How many nameservers are enough? You'll have to decide that based on your network. Here are some guidelines to help out:

Run at least one nameserver on each network or subnet you have. This removes routers as a point of failure. Make the most of any multihomed hosts you may have because they are (by definition) attached to more than one network.
If you have a file server and some diskless nodes, run a nameserver on the file server to serve this group of machines.
Run nameservers near, but not necessarily on, large multiuser computers. The users and their processes probably generate a lot of queries, and, as an administrator, you will work harder to keep a multiuser host up. But balance their needs against the risk of running a nameserver—a security-critical server—on a system to which lots of people have access.
Run at least one nameserver off-site. This makes your data available when your network isn't. You might argue that it's useless to look up an address when you can't reach the host. Then again, the off-site nameserver may be available if your network is reachable, but your other nameservers are down. If you have a close relationship with an organization on the Internet—say another university, your ISP, or a business partner—they may be willing to run a slave for you.

Figure 8-1 presents a sample topology to show you how this might work.

Figure 8-1: Sample network topology

Notice that if you follow our guidelines, there are still a number of places you can choose to run a nameserver. Host

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When you need to create new nameservers for your zones, the simplest recourse is to add slaves. You already know how—we went over it in Chapter 4—and once you've set up one slave, cloning it is a piece of cake. However, you can run into trouble by adding slaves indiscriminately.

If you run a large number of slave servers for a zone, the primary nameserver can take quite a beating serving all of the slaves' zone transfers. There are a number of remedies for this problem, as described in the sections that follow:

Make more primary master nameservers.
Direct some of the slave nameservers to load from other slave nameservers.
Create caching-only nameservers.
Create "partial-slave" nameservers.

Creating more primaries means extra work for you because you have to keep /etc/named.conf and the zone datafiles synchronized manually. Whether this is preferable to your other alternatives is your call. You can use tools such as rdist or rsync to simplify the process of distributing the files. A distfile to synchronize files between primaries might be as simple as the following:


dup-primary:



# copy named.conf file to dup'd primary



/etc/named.conf  -> wormhole

    install ;



# copy contents of /var/named (zone data files, etc.) to dup'd primary



/var/named -> wormhole

    install ;

or for multiple primaries:


dup-primary:



primaries =  ( wormhole carrie )

/etc/named.conf  -> {$primaries}

    install ;



/var/named -> {$primaries}

    install ;

You can even have rdist trigger your nameserver's reload using the special option by adding lines such as:


special /var/named/* "rndc reload" ;

special /etc/named.conf "rndc reload" ;

These tell rdist to execute the quoted command if any of the files change.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When you get around to setting up more and more nameservers, a question may strike you—do I need to register all of my primary and slave nameservers with my parent zone? The answer is no. Only those servers you want to make available to nameservers outside your zone need to be registered with your parent. For example, if you run nine nameservers for your zone, you may choose to tell the parent zone about only four of them. Within your network, you use all nine servers. Five of those nine servers, however, are queried only by resolvers on hosts that are configured to query them (in resolv.conf, for example). Their parent zone's nameservers don't delegate to them, so they'll never be queried by remote nameservers. Only the four servers registered with your parent zone are queried by other nameservers, including caching-only and partial-slave nameservers on your network. This setup is shown in Figure 8-2.

Figure 8-2: Registering only some of your nameservers

Besides being able to pick and choose which of your nameservers are hammered by outside queries, there's a technical motivation for registering only some of your zone's nameservers: there is a limit to how many servers will fit in a UDP-based response message. In practice, around 10 nameserver records should fit. Depending on the data (how many servers' names are in the same domain), you can get more or fewer. There's not much point in registering more than 10 nameservers, anyway; if none of those 10 servers can be reached, it's unlikely the destination host can be reached.

If you've set up a new authoritative nameserver, and you decide it should be registered, make a list of the parents of the zones for which it's authoritative. You'll need to contact the administrators for each parent zone. For example, let's say we want to register the nameserver we just set up on zardoz

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

An experienced zone administrator needs to know how to set the time to live on his zone's data to his best advantage. The TTL on a resource record, remember, is the length of time for which any nameserver can cache that record. So if the TTL for a particular resource record is 3,600 seconds and a server outside your network caches that record, it will have to remove the entry from its cache after an hour. If it needs the same data after the hour is up, it'll have to query one of your nameservers again.

When we introduced TTLs, we emphasized that your choice of a TTL would dictate how current you would keep copies of your data, at the cost of increased load on your nameservers. A low TTL would mean that nameservers outside your network would have to get data from your nameservers often and that the data would therefore be kept current. On the other hand, your nameservers would be peppered by the nameservers' queries.

You don't have to choose a TTL once and for all, though. You can—and experienced administrators do—change TTLs periodically to suit your needs.

Suppose we know that one of our hosts is about to be moved to another network. This host houses the movie.edu film library, a large collection of files our site makes available to hosts on the Internet. During normal operation, outside nameservers cache the address of our host according to the default TTL set in the $TTL control statement, or for pre-BIND 8.2 nameservers, in the SOA record. (We set the default TTL for movie.edu to three hours in our sample zone datafiles.) A nameserver caching the old address record just before the change could have the wrong address for as long as three hours. A loss of connectivity for three hours is unacceptable, though. What can we do to minimize the loss of connectivity? We can lower the TTL so that outside servers cache the address record for a shorter period. By reducing the TTL, we force the outside servers to update their data more frequently, which means that any changes we make when we actually move the system will be propagated to the outside world quickly. How short can we make the TTL? Unfortunately, we can't safely use a TTL of 0, which should mean "don't cache this record at all." Some older BIND version 4 nameservers can't cope with a TTL of 0. Small TTLs, like 30 seconds, are okay, though. The easiest change is to lower the TTL in the $TTL control statement in the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

It's a fact of life on a network that things go wrong. Hardware fails, software has bugs, and people occasionally make mistakes. Sometimes this results in minor inconveniences, like having a few users lose connections. Sometimes the results are catastrophic and involve the loss of important data and gainful employment.

Because the Domain Name System relies so heavily on the network, it is vulnerable to network outages. Thankfully, the design of DNS takes into account the imperfection of networks: it allows for multiple, redundant nameservers; retransmission of queries; retrying zone transfers; and so on.

DNS doesn't protect itself from every conceivable calamity, though. There are types of network failures —some of them quite common—that DNS doesn't or can't protect against. But with a small investment of time and money, you can minimize the threat of these problems.

Power outages, for example, are relatively common in many parts of the world. In some parts of the United States, thunderstorms or tornadoes may cause a site to lose power, or to have only intermittent power, for an extended period. Elsewhere, typhoons, volcanoes, or construction work may interrupt your electrical service. And you never know when those of you in California might lose power in a rolling blackout from a lack of electrical capacity.

If all your hosts are down, of course, you don't need name service. Quite often, however, sites have problems when power is restored. Following our recommendations, they run their nameservers on file servers and big, multiuser machines. And when the power comes up, those machines are naturally the last to boot because all those disks need to be checked and fixed first! Which means that all the on-site hosts that are quick to boot do so without the benefit of name service.

This can cause all sorts of wonderful problems, depending on how your hosts' startup files are written. Unix hosts often execute some variant of:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When disaster strikes, it really helps to know what to do. Knowing to duck under a sturdy table or desk during an earthquake can save you from being pinned under a toppling monitor. Knowing how to turn off your gas can save your house from conflagration.

Likewise, knowing what to do in a network disaster (or even just a minor mishap) can help you keep your network running. Living out in California, as we do, we have some first-hand experience with disaster, and some suggestions.

If you lose network connectivity for a long time, your nameservers may begin to have problems. If they lose connectivity to the root nameservers for an extended period, they'll stop resolving queries outside their authoritative zone data. If the slaves can't reach their master, sooner or later they'll expire the zone.

In case your name service really goes haywire because of the connectivity loss, it's a good idea to keep a site-wide or workgroup /etc/hosts around. In times of dire need, you can move resolv.conf to resolv.bak, kill the local nameserver (if there is one), and just use /etc/hosts. It's not flashy, but it'll get you by.

As for slaves, you can reconfigure a slave that can't reach its master to temporarily run as a primary. Just edit named.conf and change the type substatement in the zone statement from slave to master, then delete the masters substatement. If more than one slave for the same zone is cut off, you can configure one as a primary temporarily and reconfigure the others to load from the temporary primary.

If an extended outage cuts you off from the Internet—say for a week or more—you may need to restore connectivity to root nameservers artificially to get things working again. Every nameserver needs to talk to a root nameserver occasionally. It's a bit like therapy: the nameserver needs to contact a root periodically to regain its perspective on the world.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"The way Dinah washed her children's faces was this: first she held the poor thing down by its ear with one paw, and then with the other paw she rubbed its face all over, the wrong way, beginning at the nose: and just now, as I said, she was hard at work on the white kitten, which was lying quite still and trying to purr—no doubt feeling that it was all meant for its good."

—

Once your domain reaches a certain size, or you decide you need to distribute the management of parts of your domain to various entities within your organization, you'll want to divide the domain into subdomains. These subdomains will be the children of your current domain in the namespace; your domain will be the parent. If you delegate responsibility for your subdomains to another organization, each becomes its own zone, separate from its parent zone. We like to call the management of your subdomains—your children—parenting.

Good parenting starts with carving up your domain sensibly, choosing appropriate names for your subdomains, and delegating the subdomains to create new zones. A responsible parent also works hard at maintaining the relationship between his zone and its children; he ensures that delegation from parent to child is current and correct.

Good parenting is vital to the success of your network, especially as name service becomes critical to navigating between sites. Incorrect delegation to a child zone's nameservers can render a site effectively unreachable, while the loss of connectivity to the parent zone's nameservers can leave a site unable to reach any hosts outside the local zone.

In this chapter, we present our views on when to create subdomains, and we go over how to create and delegate them in some detail. We also discuss management of the parent/child relationship and, finally, how to manage the process of carving up a large domain into smaller subdomains with minimal disruption and inconvenience.

Far be it from us to tell you when you should become a parent, but we will be so bold as to offer you some guidelines. You may find some compelling reason to implement subdomains that isn't on our list, but here are some common reasons:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Far be it from us to tell you when you should become a parent, but we will be so bold as to offer you some guidelines. You may find some compelling reason to implement subdomains that isn't on our list, but here are some common reasons:

A need to delegate or distribute management of your domain to a number of organizations
The large size of your domain: dividing it would make it easier to manage and reduce the load on your authoritative nameservers
A need to distinguish hosts' organizational affiliations by including them in particular subdomains

Once you've decided to have children, the next question to ask yourself is, naturally, how many children to have.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Of course, you won't simply say, "I want to create four subdomains." Deciding how many subdomains to implement is really choosing the organizational affiliations of those subdomains. For example, if your company has four branch offices, you might decide to create four subdomains, each of which corresponds to a branch office.

Should you create subdomains for each site, for each division, or even for each department? You have a lot of latitude in your choice because of DNS's scalability. You can create a few large subdomains or many small subdomains. There are trade-offs whichever you choose, though.

Delegating to a few large subdomains isn't much work for the parent, because there's not much delegation to keep track of. However, you wind up with larger subdomains, which require more memory to load and faster nameservers, and administration isn't as distributed. If you implement site-level subdomains, for example, you may force autonomous or unrelated groups at a site to share a single zone and a single point of administration.

Delegating to many smaller subdomains can be a headache for the parent's administrator. Keeping delegation data current involves keeping track of which hosts run nameservers and which zones they're authoritative for. The data changes each time a subdomain adds a new nameserver or the address of a nameserver for the subdomain changes. If the subdomains are all administered by different people, that means more administrators to train, more relationships for the parent's administrator to maintain, and more overhead for the organization overall. On the other hand, the subdomains are smaller and easier to manage, and the administration is more widely distributed, allowing closer management of zone data.

Given the advantages and disadvantages of either alternative, it may seem difficult to make a choice. Actually, there's probably a natural division in your organization. Some companies manage computers and networks at the site level; others have decentralized, relatively autonomous workgroups that manage everything themselves. Here are a few basic rules to help you find the right way to carve up your namespace:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Once you've decided how many subdomains you'd like to create and what they correspond to, you must choose names for them. Rather than unilaterally deciding on your subdomains' names, it's considered polite to involve your future subdomain administrators and their constituencies in the decision. In fact, you can leave the decision entirely to them if you like.

This can lead to problems, though. It's preferable to use a relatively consistent naming scheme across your subdomains. This practice makes it easier for users in one subdomain, or outside your domain entirely, to guess or remember your subdomain names and to figure out in which domain a particular host or user lives.

Leaving the decision to the locals can result in naming chaos. Some will want to use geographical names; others will insist on organizational names. Some will want to abbreviate; others will want to use full names.

Therefore, it's often best to establish a naming convention before choosing subdomain names. Here are some suggestions from our experience:

In a dynamic company, the names of organizations can change frequently. Naming subdomains organizationally in a climate like this can be disastrous. One month the Relatively Advanced Technology group seems stable enough, the next month they've been merged into the Questionable Computer Systems organization, and the following quarter they're all sold to a German conglomerate. Meanwhile, you're stuck with well-known hosts in a subdomain whose name no longer has any meaning.
Geographical names are more stable than organizational names but sometimes aren't as well known. You may know that your famous Software Evangelism Business Unit is in Poughkeepsie or Waukegan, but people outside your company may have no idea where it is (and might have trouble spelling either name).
Don't sacrifice readability for convenience. Two-letter subdomain names may be easy to type, but impossible to recognize. Why abbreviate "Italy" to "it" and have it confused with your Information Technology organization when for a paltry three more letters you can use the full name and eliminate any ambiguity?

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Once you've decided on names, creating the child domains is easy. But first, you must decide how much autonomy you're going to give your subdomains. Odd that you have to decide that before you actually create them . . . .

Thus far, we've assumed that if you create a subdomain, you'll want to delegate it to another organization, thereby making it a separate zone from the parent. Is this always true, though? Not necessarily.

Think carefully about how the computers and networks within a subdomain are managed when choosing whether to delegate it. It doesn't make sense to delegate a subdomain to an entity that doesn't manage its own hosts or networks. For example, in a large corporation, the Personnel Department probably doesn't run its own computers: the MIS (Management Information Systems) or IT (Information Technology—same animal as MIS) Department manages them. So while you may want to create a subdomain for personnel, delegating management for that subdomain to it is probably wasted effort.

You can create a subdomain without delegating it, however. How? By creating resource records that refer to the subdomain within the parent's zone. For example, movie.edu has a host that stores its complete database of employee and student records, called brazil. To put brazil in the personnel.movie.edu domain, we can add records to db.movie.edu.

Partial contents of file db.movie.edu:


brazil.personnel      IN  A      192.253.253.10

                      IN  MX     10 brazil.personnel.movie.edu.

                      IN  MX     100 postmanrings2x.movie.edu.

employeedb.personnel  IN  CNAME  brazil.personnel.movie.edu.

db.personnel          IN  CNAME  brazil.personnel.movie.edu.

Now users can log into db.personnel.movie.edu to get to the employee database. We can make this setup especially convenient for Personnel Department employees by adding personnel.movie.edu to their PCs' or workstations' search lists; they'd need to type only

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Forward-mapping domains aren't the only domains you can divide into subdomains and delegate. If your in-addr.arpa namespace is large enough, you may need to divide it, too. Typically, you divide the domain that corresponds to your network number into subdomains that correspond to your subnets. How that works depends on the type of network you have and on your network's subnet mask.

Since Movie U. has just three /24 (Class C-sized) networks, one per segment, there's no particular need to subnet those networks. However, our sister university, Altered State, has a Class B-sized network, 172.20/16. Its network is subnetted between the third and fourth octet of the IP address; that is, its subnet mask is 255.255.255.0. It's already created a number of subdomains of its domain: altered.edu, including fx.altered.edu (okay, we copied them); makeup.altered.edu; and foley.altered.edu. Since each department also runs its own subnet (its Special Effects department runs subnet 172.20.2/24, Makeup runs 172.20.15/24, and Foley runs 172.20.25/24), it'd like to divvy up its in-addr.arpa namespace appropriately, too.

Delegating in-addr.arpa subdomains is no different from delegating subdomains of forward-mapping domains. Within its db.172.20 zone datafile, it needs to add NS records like these:


2     86400    IN    NS    gump.fx.altered.edu.

2     86400    IN    NS    toystory.fx.altered.edu.

15    86400    IN    NS    prettywoman.makeup.altered.edu.

15    86400    IN    NS    priscilla.makeup.altered.edu.

25    86400    IN    NS    blowup.foley.altered.edu.

25    86400    IN    NS    muppetmovie.foley.altered.edu.

These records delegate the subdomain that corresponds to each subnet to the correct nameserver in each subdomain.

A few important notes: the Altered States administrators can use only the third octet of the subnet in the owner name field because the default origin in this file is 20.172.in-addr.arpa. They need to use the fully qualified domain names of the nameservers in the right side of the NS records, though, to avoid having the origin appended. And they

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now that the delegation to the fx.movie.edu nameservers is in place, we—responsible parents that we are—should check that delegation using host. What? We haven't given you host yet? A version of host for many Unix variants is available from http://www.weird.com/~woods/projects/host.html.

To build host, first extract it:


% zcat host.tar.Z | tar -xvf -

Then build it on your system:


% make

host makes it easy to check delegation. With host, you can look up the NS records for your zone on your parent zone's nameservers. If those look good, you can use host to query each nameserver listed for the zone's SOA record. The query is nonrecursive, so the nameserver queried doesn't query other nameservers to find the SOA record. If the nameserver replies, host checks the reply to see whether the aa—authoritative answer—bit in the reply message is set. If it is, the nameserver checks to make sure that the message contains an answer. If both these criteria are met, the nameserver is flagged as authoritative for the zone. Otherwise, the nameserver is not authoritative, and host reports an error.

Why all the fuss over bad delegation? Incorrect delegation slows name resolution and causes the propagation of old and erroneous nameserver information. Remote nameservers will waste time following your bad NS records, only to receive responses from your nameservers indicating that they aren't, in fact, authoritative for the zone. The remote nameservers will be forced to query a nameserver listed in another NS record, which means resolving names will take longer. Worse, those remote nameservers will cache those bogus NS records and return them in responses to other nameservers, compounding the problem.

If our little lecture has convinced you of the importance of maintaining correct delegation, you'll be eager to learn how to use host to ensure that you don't join the ranks of the miscreants.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We won't lie to you: the fx.movie.edu example we showed you was unrealistic for several reasons. The main one is the magical appearance of the special-effects lab's hosts. In the real world, the lab would have started out with a few hosts, probably in the movie.edu zone. After a generous endowment, an NSF grant, or a corporate gift, the lab might expand a little and a few more computers might be purchased. Sooner or later, the lab would have enough hosts to warrant the creation of a new subdomain. By that point, however, many of the original hosts would be well known by their names in movie.edu.

We briefly touched on using CNAME records in the parent zone (in our plan9.movie.edu example) to help people adjust to a host's change of domain. But what happens when you move a whole network or subnet into a new subdomain?

The strategy we recommend uses CNAME records in much the same way but on a larger scale. Using a tool such as h2n, you can create CNAMEs for hosts en masse. This allows users to continue using the old domain names for any of the hosts that have moved. When they telnet or ftp (or whatever) to those hosts, however, the command reports that they're connected to a host in fx.movie.edu:


% telnet plan9

Trying...

Connected to plan9.fx.movie.edu.

Escape character is '^]'.



HP-UX plan9.fx.movie.edu A.09.05 C 9000/735 (ttyu1)



login:

Some users, of course, don't notice subtle changes like this, so you should also do some public relations work and notify folks of the change.

On fx.movie.edu hosts running old versions of sendmail, we may also need to configure sendmail to accept mail addressed to the new domain names. Modern versions of sendmail canonicalize the hostnames in message headers using a nameserver before sending the messages. This turns a movie.edu alias into a canonical name in fx.movie.edu. If, however, the sendmail on the receiving end is older and hardcodes the local host's domain name, we have to change the name to the new domain name by hand. This usually requires a simple change to class

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

That's a lot of parental advice to digest in one sitting, so let's recap the highlights of what we've talked about. The lifecycle of a typical parent goes something like this:

You have a single zone, with all your hosts in that zone.
You break your zone into a number of subdomains, some of them in the same zone as the parent, if necessary. You provide CNAME records in the parent zone for well-known hosts that have moved into subdomains.
After a grace period, you delete any remaining CNAME records.
You handle subdomain delegation updates, either manually or by using stub zones, and periodically check delegation.

Okay, now that you know all there is to parenting, let's go on to talk about more advanced nameserver features. You may need some of these tools to keep those kids in line.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"What's the use of their having names," the Gnat said, "if they won't answer to them?"

The latest BIND nameservers, versions 8.4.7 and 9.3.2, have lots of new features. Some of the most prominent introductions are support for dynamic updates, asynchronous zone change notification (called "NOTIFY" for short), and incremental zone transfer. Of the rest, the most important are related to security: they let you tell your nameserver whom to answer queries from, whom to serve zone transfers to, and whom to permit dynamic updates from. Many of the security features aren't necessary inside a corporate network, but the other mechanisms will help out administrators of any nameservers.

In this chapter, we'll cover these features and suggest how they might come in handy in your DNS infrastructure. (We do save some of the hardcore firewall material 'til the next chapter, though.)

Before we introduce the new features, however, we'd better cover address match lists. BIND 8 and 9 use address match lists for nearly every security feature and for some features that aren't security-related at all.

An address match list is a list (what else?) of terms that specifies one or more IP addresses. The elements in the list can be individual IP addresses, IP prefixes, or a named address match list (more on those shortly). An IP prefix has the format:


network in dotted-octet format/bits in netmask

For example, the network 15.0.0.0 with the network mask 255.0.0.0 (eight contiguous ones) is written 15/8. Traditionally, this would have been thought of as the "class A" network 15. The network consisting of IP addresses 192.168.1.192 through 192.168.1.255, on the other hand, would be written 192.168.1.192/26 (network 192.168.1.192 with the netmask 255.255.255.192, which has 26 contiguous ones). Here's an address match list comprising those two networks:


15/8; 192.168.1.192/26;

A named address match list is just that: an address match list with a name. To be used within another address match list, a named address match list must have been previously defined in

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before we introduce the new features, however, we'd better cover address match lists. BIND 8 and 9 use address match lists for nearly every security feature and for some features that aren't security-related at all.

An address match list is a list (what else?) of terms that specifies one or more IP addresses. The elements in the list can be individual IP addresses, IP prefixes, or a named address match list (more on those shortly). An IP prefix has the format:


network in dotted-octet format/bits in netmask

For example, the network 15.0.0.0 with the network mask 255.0.0.0 (eight contiguous ones) is written 15/8. Traditionally, this would have been thought of as the "class A" network 15. The network consisting of IP addresses 192.168.1.192 through 192.168.1.255, on the other hand, would be written 192.168.1.192/26 (network 192.168.1.192 with the netmask 255.255.255.192, which has 26 contiguous ones). Here's an address match list comprising those two networks:


15/8; 192.168.1.192/26;

A named address match list is just that: an address match list with a name. To be used within another address match list, a named address match list must have been previously defined in named.conf with an acl statement. The acl statement has a simple syntax:


acl name { address_match_list; };

This just makes the name equivalent to that address match list from now on. Although the name of the statement, acl, suggests "access control list," you can use the named address match list anywhere an address match list is accepted, including some places that don't have anything to do with access control.

Whenever you use one or more of the same terms in a few access control lists, it's a good idea to use an acl statement to associate them with a name. You can then refer to the name in the address match list. For example, let's call 15/8 what it is: "HP-NET." And we'll call 192.168.1.192/26 "internal":

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The world of the Internet—and of TCP/IP networking in general—has become a much more dynamic place. Most large corporations use DHCP to control IP address assignment. Nearly all ISPs assign addresses to dial-up and cable modem customers using DHCP. To keep up, DNS needed to support the dynamic addition and deletion of records. RFC 2136 introduced this mechanism, called DNS Dynamic Update.

BIND 8 and 9 support the dynamic update facility described in RFC 2136. This permits authorized updaters to add and delete resource records from a zone for which a nameserver is authoritative. An updater can find the authoritative nameservers for a zone by retrieving the zone's NS records. If the nameserver receiving an authorized update message is not the primary master for the zone, it forwards the update "upstream" to its master server, a process referred to as update forwarding. If this next server, in turn, is a slave for the zone, it also forwards the update upstream. Only the primary nameserver for a zone, after all, has a writable copy of the zone data; all the slaves get their copies of the zone data from the primary, either directly or indirectly (through other slaves). Once the primary has processed the dynamic update and modified the zone, the slaves can get a new copy of it via zone transfers.

Dynamic update permits more than the simple addition and deletion of records. Updaters can add or delete individual resource records, delete RRsets (a set of resource records with the same domain name, class, and type, such as all the addresses of www.movie.edu), or even delete all records associated with a given domain name. An update can also stipulate that certain records exist or not exist in the zone as a prerequisite to the update's taking effect. For example, an update can add the address record:


armageddon.fx.movie.edu.  300  IN  A  192.253.253.15

only if the domain name

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Traditionally, BIND slaves have used a polling scheme to determine when they need a zone transfer. The polling interval is called the refresh interval. Other parameters in the zone's SOA record govern other aspects of the polling mechanism.

But with this polling scheme, it can take up to the refresh interval before a slave detects and transfers new zone data from its master nameserver. That kind of latency can wreak havoc in a dynamically updated environment. Wouldn't it be nice if the primary nameserver could tell its slave servers when the information in the zone changed? After all, the primary nameserver knows the data has changed; someone reloaded the data or it received and processed a dynamic update. The primary could send notification right after processing the reload or update instead of waiting for the refresh interval to pass.

RFC 1996 proposed a mechanism that would allow primary nameservers to notify their slaves of changes to a zone's data. BIND 8 and 9 implement this scheme, which is called DNS NOTIFY.

DNS NOTIFY works like this: when a primary nameserver notices that the serial number of a zone has changed, it sends a special announcement to all the slave nameservers for that zone. The primary nameserver determines which servers are the slaves for the zone by looking at the list of NS records in the zone and taking out the record that points to the nameserver listed in the MNAME field of the zone's SOA record as well as the domain name of the local host.

When does the nameserver notice a change? Restarting a primary nameserver causes it to notify all its slaves as to the current serial number of all of its zones because the primary has no way of knowing whether its zone datafiles were edited before it started. Reloading one or more zones with new serial numbers causes a nameserver to notify the slaves of those zones. And a dynamic update that causes a zone's serial number to increment also causes notification.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

With dynamic update and NOTIFY, our zones are updated according to the changing state of the network, and those changes quickly propagate to all the authoritative nameservers for those zones. The picture's complete, right?

Not quite. Imagine you run a large zone that's dynamically updated with frightening frequency. That's easy to envision: you might have a big zone to begin with, including thousands of clients, when all of a sudden management decides to implement Active Directory and DHCP. Now each of your clients updates its own address record in the zone, and the Domain Controllers update the records that tell clients which services they run. (There's much more to come on Active Directory in Chapter 17.)

Each time your primary nameserver receives an update that increments the zone's serial number, it sends a NOTIFY announcement to its slaves. And each time they receive NOTIFY announcements, the slaves check the serial number of the zone on their master server and, possibly, transfer the zone. If that zone is large, the transfer will take some time; another update could arrive in the interim. Your slaves could be transferring zones in perpetuity! At the very least, your nameservers will spend a lot of time transferring the whole zone when the change to the zone is probably very small (e.g., the addition of a client's address record).

Incremental zone transfer, or IXFR for short, solves this problem by allowing slave nameservers to tell their master servers which version of a zone they currently hold and to request just the changes to the zone between that version and the current one. This can dramatically reduce the size and duration of a zone transfer.

An incremental zone transfer request has a query type of IXFR instead of AXFR (the type of query that initiates a full zone transfer), and it contains the slave's current SOA record from the zone in the authority section of the message. When the master nameserver receives an incremental zone transfer request, it looks for the record of the changes to the zone between the slave's version of the zone and the version the master holds. If that record is missing, the master sends a full zone transfer. Otherwise, it sends just the differences between the versions of the zone.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Certain network connections discourage sending large volumes of traffic off-site, perhaps because it's a slow link with high delay; a remote office's satellite connection to the company's network is an example. In these situations, you'll want to limit the off-site DNS traffic to the bare minimum. BIND provides a mechanism to do this: forwarders.

Forwarders are also useful if you need to shunt name resolution to a particular nameserver. For example, if only one of the hosts on your network has Internet connectivity, and you run a nameserver on that host, you can configure your other nameservers to use it as a forwarder so that they can look up Internet domain names. (More on this use of forwarders when we discuss firewalls in Chapter 11.)

If you designate one or more servers at your site as forwarders, your nameservers will send all their off-site queries to the forwarders first. The idea is that the forwarders handle all the off-site queries generated at the site, building up a rich cache of information. For any given query in a remote zone, there is a high probability that the forwarder can answer the query from its cache, avoiding the need for the other servers to send queries off-site. You don't do anything to a nameserver to make it a forwarder; you modify all the other servers at your site to direct their queries through the forwarders.

A primary or slave nameserver's mode of operation changes slightly when it is configured to use a forwarder. If a resolver requests records that are already in the nameserver's authoritative data or cached data, the nameserver answers with that information; this part of its operation hasn't changed. However, if the records aren't in its database, the nameserver sends the query to a forwarder and waits a short period for an answer before resuming normal operation and starting the iterative name resolution process. This mode of operation is called

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

BIND 9 introduced views, another mechanism that's very useful in firewalled environments. Views allow you to present one nameserver configuration to one community of hosts and a different configuration to another community. This is particularly handy if you're running a nameserver on a host that receives queries from both your internal hosts and hosts on the Internet (we'll cover this in the next chapter).

If you don't configure any views, BIND 9 automatically creates a single, implicit view that it shows to all hosts that query it. To explicitly create a view, you use the view statement, which takes the name of the view as an argument:


view "internal" {

};

Although the name of the view can be just about anything, using a descriptive name is always a good idea. And while quoting the name of the view isn't necessary, it's helpful to do so to avoid conflict with words BIND reserves for its own use ("internal," for example). The view statement must come after any options statement, though not necessarily right after it.

You can select which hosts "see" a particular view using the match-clients view substatement, which takes an address match list as an argument. If you don't specify a community of hosts with match-clients, the view applies to all hosts.

Let's say we're setting up a special view of the fx.movie.edu zone on our nameservers that we want only the Special Effects department to see. We could create a view visible only to hosts on our subnet:


view "internal" {

    match-clients { 192.253.254/24; };

};

If you want to make that a little more readable, you can use an acl statement:


acl "fx-subnet" { 192.253.254/24; };



view "internal" {

    match-clients { "fx-subnet"; };

};

Just be sure you define the ACL

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Nameservers released since BIND 4.9 have formalized some load distribution functionality that has existed in patches to BIND for some time. Bryan Beecher wrote patches to BIND 4.8.3 to implement what he called "shuffle address records." These were address records of a special type that the nameserver rotated between responses. For example, if the domain name foo.bar.baz had three "shuffled" IP addresses, 192.168.1.1, 192.168.1.2, and 192.168.1.3, an appropriately patched nameserver would give them out first in the order:


192.168.1.1 192.168.1.2 192.168.1.3

then in the order:


192.168.1.2 192.168.1.3 192.168.1.1

and then in the order:


192.168.1.3 192.168.1.1 192.168.1.2

before starting all over with the first order and repeating the rotation ad infinitum.

This functionality is enormously useful if you have a number of equivalent network resources, such as mirrored FTP servers, web servers, or terminal servers, and you'd like to spread the load among them. You establish one domain name that refers to the group of resources and configure clients to access that domain name, and the nameserver distributes requests among the IP addresses you list.

BIND 8 and 9 do away with the shuffle address record as a separate record type, subject to special handling. Instead, a modern nameserver rotates addresses for any domain name that has more than one A record. (In fact, the nameserver will rotate any type of record as long as a given domain name has more than one of them.) So the records:


foo.bar.baz.    60    IN    A    192.168.1.1

foo.bar.baz.    60    IN    A    192.168.1.2

foo.bar.baz.    60    IN    A    192.168.1.3

accomplish on a BIND 8 or 9 nameserver just what the shuffle address records did on a patched 4.8.3 server. The BIND documentation calls this process round-robin.

It's a good idea to reduce the records' time to live, too, as we did in this example. This ensures that if the addresses are cached on an intermediate nameserver that doesn't support round-robin, they'll time out of the cache quickly. If the intermediate nameserver looks up the name again, your authoritative nameserver can round-robin the addresses again.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Sometimes, neither round-robin nor any other configurable order is what you want. When you are contacting a host that has multiple network interfaces and hence multiple IP addresses, choosing a particular interface based on your host's address may give you better performance. No rrset-order substatement can do that for you.

If the multihomed host is local and shares a network or subnet with your host, one of the multihomed host's addresses is "closer." If the multihomed host is remote, you may see better performance using one interface instead of another, but often it doesn't matter much which address is used. In days long past, net 10 (the former ARPAnet "backbone") was always closer than any other remote address. The Internet has improved drastically since those days, so you won't often see a marked performance improvement when using one network over another for remote multihomed hosts, but we'll cover that case anyway.

Before we get into address sorting by a nameserver, you should first look at whether address sorting by the resolver better suits your needs. (See the section "The sortlist Directive" in Chapter 6.) Since your resolver and nameserver may be on different networks, it often makes more sense for the resolver to sort addresses optimally for its host. Address sorting at the nameserver works fairly well, but it can be hard to optimize for every resolver it services.

In an uncommon turn of events, the nameserver's address-sorting feature was removed in early versions of BIND 8, primarily because of the developers' insistence that it had no place in the nameserver. The feature was restored—and in fact enhanced—in BIND 8.2. BIND 9.1.0 was the first BIND 9 release to support address sorting.

The key to address sorting is an options substatement called sortlist. The sortlist substatement takes an address match list as an argument. Unlike address match lists used as access control lists, though, sortlist's has a very specialized interpretation. Each entry in the address match list is itself an address match list with either one or two elements.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

BIND 8's topology feature is somewhat similar to sortlist, but it applies only to the process of choosing nameservers. (BIND 9 doesn't support topology as of 9.3.2.) Earlier in the book, we described how BIND chooses between a number of nameservers that are authoritative for the same zone by selecting the nameserver with the lowest round-trip time. But we lied—a little. BIND 8 actually places remote nameservers in 64-millisecond bands when comparing RTT. The first band is actually only 32 milliseconds wide (there! we did it again), from 0 to 32 milliseconds. The next extends from 33 to 96 milliseconds, and so on. The bands are designed so that nameservers on different continents are always in different bands.

The idea is to favor nameservers in lower bands but to treat servers in the same band as equivalent. If a nameserver compares two remote servers' RTTs, and one is in a lower band, the nameserver chooses to query the nameserver in the lower band. But if the remote servers are in the same band, the nameserver checks to see whether one of the remote servers is topologically closer.

So topology lets you introduce an element of fudge into the process of choosing a nameserver to query. It lets you favor nameservers on certain networks over others. Topology takes as an argument an address match list, where the entries are networks, listed in the order in which the local nameserver should prefer them (highest to lowest). Therefore:


topology {

    15/8;

    172.88/16;

};

tells the local nameserver to prefer nameservers on the network 15/8 over other nameservers, and nameservers on the network 172.88/16 over nameservers on networks other than 15/8. So if the nameserver has a choice between a nameserver on network 15/8, a nameserver on 172.88/16, and a nameserver on 192.168.1/24, assuming all three have RTT values in the same band, it will choose to query the nameserver on 15/8.

You can also negate entries in the topology address match list to penalize nameservers on certain networks. The earlier in the address match list the negated entry matches, the greater the penalty. You might use this to keep your nameserver from querying remote nameservers on a network that's particularly flaky, for example.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

By default, BIND resolvers send recursive queries, and, by default, BIND nameservers do the work required to answer them. (If you don't remember how recursion works, see Chapter 2.) In the process of finding the answers to recursive queries, the nameserver builds up a cache of nonauthoritative information from other zones.

In some situations, it's undesirable for nameservers to do the extra work required to answer a recursive query or to build up a cache of data. The root nameservers are an example of one of these situations. The root nameservers are so busy that they can't expend the extra effort necessary to find the answers to recursive queries. Instead, they send a response based only on the authoritative data they have. The response may contain the answer, but it more likely contains a referral to other nameservers. And since the root servers do not support recursive queries, they don't build up a cache of nonauthoritative data, which is good because their caches would be huge.

You can induce a BIND nameserver to run in nonrecursive mode with the following configuration (config) file statement:


options {

    recursion no;

};

Now the server will respond to recursive queries as if they were nonrecursive.

In conjunction with recursion no, there is one more configuration option necessary if you want to prevent your nameserver from building a cache:


options {

    fetch-glue no;

};

This stops the server from fetching missing glue when constructing the additional data section of a response. BIND 9 nameservers don't fetch glue, so the fetch-glue substatement is obsolete in BIND 9.

If you choose to make one of your servers nonrecursive, don't list that nameserver in any host's resolv.conf file. While you can make your nameserver nonrecursive, there is no corresponding option to make your resolver work with a nonrecursive nameserver. If your nameserver needs to continue to serve one or more resolvers, you can use the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In your term as nameserver administrator, you might find some remote nameserver that responds with bad information—old, incorrect, badly formatted, or even deliberately deceptive. You can attempt to find an administrator to fix the problem. Or you can save yourself some grief and configure your nameserver not to ask questions of this server, which is possible with BIND 8, and BIND 9.1.0 and later. Here is the configuration file statement:


server 10.0.0.2 {

    bogus yes;

};

Of course, you fill in the correct IP address.

If you tell your nameserver to stop talking to a server that is the only server for a zone, don't expect to be able to look up names in that zone. Hopefully, there are other servers for that zone that can provide good information.

An even more potent way of shutting out a remote nameserver is to put it on your blackhole list. Your nameserver won't query nameservers on the list, and it won't respond to their queries. blackhole is an options substatement that takes an address match list as an argument:


options {



    /* Don't waste your time trying to respond to queries from RFC 1918

       private addresses */



    blackhole {

        10/8;

        172.16/12;

        192.168/16;

    };

};

This prevents your nameserver from trying to respond to any queries it might receive from RFC 1918 private addresses. There are no routes on the Internet to these addresses, so trying to reply to them is a waste of CPU cycles and bandwidth.

The blackhole substatement is supported on BIND 8 versions after 8.2 and on BIND 9 after 9.1.0.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

While for many nameservers BIND's default configuration values work just fine, yours may be one of those that need some further tuning. In this section, we discuss all the various dials and switches available to you to tune your nameserver.

Zone transfers can place a heavy load on a nameserver. Consequently, BIND has mechanisms for limiting the zone transfer load that your slave nameservers place on their master servers.

Section 10.12.1.1: Limiting transfers requested per nameserver

On a slave nameserver, you can limit the number of zones the server requests from a single master nameserver. This will make the administrator of your master nameserver happy because his host won't be pounded for zone transfers if all the zones change—important if hundreds of zones are involved.

The config file statement is:


options {

    transfers-per-ns 

 2;

};

In BIND 9, you can also set the limit on a server-by-server basis instead of globally. To do this, use the transfers substatement inside a server statement, where the server is the nameserver you'd like to specify the limit for:


server 192.168.1.2 {

    transfers 2;

};

This overrides any global limit set in the options statement. The default limit is two active zone transfers per master nameserver. That limit may seem small, but it works. Here's what happens: suppose your nameserver needs to load four zones from a master nameserver. Your nameserver starts transferring the first two zones and waits to transfer the third and fourth zones. After one of the first two zone transfers completes, the nameserver begins transferring the third zone. After another transfer completes, the nameserver starts transferring the fourth zone. The net result is the same as before when there were limits—all the zones are transferred—but the work is spread out.

When may you need to increase this limit? You might notice that it is taking too long to synch up with the master nameserver, and you know that the reason is the serializing of transfers—not just that the network between the hosts is slow. This probably matters only if you're maintaining hundreds or thousands of zones. You also need to make sure that the master nameserver and the networks in between can handle the additional workload of more simultaneous zone transfers.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now, to wrap things up, we'll cover some configuration substatements related to your nameserver's compatibility with resolvers and other nameservers.

The rfc2308-type1 substatement controls the format of the negative answers your nameserver sends. By default, BIND 8 and 9 nameservers include only the SOA record in a negative response from a zone. Another legitimate format for that response includes the zone's NS records, too, but some older nameservers misinterpret such a response as a referral. If for some odd reason (odd because we can't think of one) you want to send those NS records as well, use:


options {

    rfc2308-type1 yes;

};

rfc2308-type1 is first supported in BIND 8.2; BIND 9 doesn't support it.

Older nameservers can also cause problems when you send them cached negative responses. Before the days of negative caching, all negative responses were, naturally, authoritative. But some nameserver implementers added a check to their servers: they'd accept only authoritative negative responses. Then, with the advent of negative caching, negative responses could be nonauthoritative. Oops!

The auth-nxdomain options substatement lets your nameserver falsely claim that a negative answer from its cache is actually authoritative, just so one of these older nameservers will believe it. By default, BIND 8 nameservers have auth-nxdomain on (set to yes); BIND 9 nameservers turn it off by default.

When some adventurous souls ported BIND 8.2.2 to Windows NT, they found they needed the nameserver to treat a carriage return and a newline at the end of a line (Windows' end-of-line sequence) the same way it treated just a newline (Unix's end-of-line). For that behavior, use:


options {

    treat-cr-as-space yes;

};

BIND 9 ignores this option because it always treats a carriage return and a newline the same way as a newline by itself.

Finally, if you run a BIND nameserver that's configured as a slave to Microsoft DNS Servers with Active Directory-integrated zones, you may see an error message in

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before we cover the next two topics, which include how domain names map to IPv6 addresses and vice versa, we'd better describe the representation and structure of IPv6 addresses. As you probably know, IPv6 addresses are 128 bits long. The preferred representation of an IPv6 address is eight groups of as many as four hexadecimal digits, separated by colons; for example:


2001:db80:0123:4567:89ab:cdef:0123:4567

The first group of hex digits (2001, in this example) represents the most significant (or highest-order) 16 bits of the address.

Groups of digits that begin with one or more zeros don't need to be padded to four places, so you can also write the previous address as:


2001:db80:123:4567:89ab:cdef:123:4567

Each group must contain at least one digit, though, unless you're using the :: notation. The :: notation allows you to compress sequential groups of zeros. This comes in handy when you're specifying just an IPv6 prefix. For example:


2001:db80:dead:beef::

specifies the first 64 bits of an IPv6 address as 2001:db80:dead:beef and the remaining 64 as zeros.

You can also use :: at the beginning of an IPv6 address to specify a suffix. For example, the IPv6 loopback address is commonly written as:

::1

or 127 zeros followed by a single one. You can even use :: in the middle of an address as a shorthand for contiguous groups of zeros:


2001:db80:dead:beef::1

You can use the :: shorthand only once in an address, since more than one could be ambiguous.

IPv6 prefixes are specified in a format similar to IPv4's CIDR notation. As many bits of the prefix as are significant are expressed in the standard IPv6 notation, followed by a slash and a decimal count of exactly how many significant bits there are. So the following three prefix specifications are equivalent (though obviously not equivalently terse):

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Since IPv4 is relatively simple compared to IPv6, let's cover the nameserver's IPv4 configuration together with IPv6. BIND 8.4.0 and later and all BIND 9 nameservers can use both IPv4 and IPv6 as a transport; that is, they can send and receive queries and responses over IPv4 and IPv6. Both nameservers also support similar substatements to configure which network interfaces and ports they listen on and send queries from.

You can specify which network interface your BIND 8 or BIND 9 nameserver listens on for queries using the listen-on substatement. In its simplest form, listen-on takes an address match list as an argument:


options {

    listen-on { 192.249.249/24; };

};

The nameserver listens on any of the local host's network interfaces whose addresses match the address match list. To specify an alternate port (one other than 53) to listen on, use the port modifier:


options {

    listen-on port 5353 { 192.249.249/24; };

};

In BIND 9, you can even specify a different port for each network interface:


options {

    listen-on { 192.249.249.1 port 5353; 192.253.253.1 port 1053; };

};

Note that there's no way to configure most resolvers to query a nameserver on an alternate port, so this nameserver might not be as useful as you'd think. Still, it can serve zone transfers because you can specify an alternate port in a masters substatement:


zone "movie.edu" {

    type slave;

    masters port 5353 { 192.249.249.1; };

    file "bak.movie.edu";

};

Or, if your BIND 9 nameserver has multiple master nameservers, each listening on a different port, you can use something like:


zone "movie.edu" {

    type slave;

    masters { 192.249.249.1 port 5353; 192.253.253.1 port 1053; };

    file "bak.movie.edu";

};

BIND 9 even allows you to send your NOTIFY messages to alternate ports. To tell your master nameserver to notify all its slave nameservers on the same oddball port, use:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"I hope you've got your hair well fastened on?" he continued, as they set off.

"Only in the usual way," Alice said, smiling.

"That's hardly enough," he said, anxiously. "You see the wind is so very strong here. It's as strong as soup."

"Have you invented a plan for keeping the hair from being blown off?" Alice enquired.

"Not yet," said the Knight. "But I've got a plan for keeping it from falling off."

—

Why should you care about DNS security? Why go to the trouble of securing a service that mostly maps names to addresses? Let us tell you a story.

In July 1997, during two periods of several days, users around the Internet who typed www.internic.net into their web browsers thinking they were going to the InterNIC's web site instead ended up at a web site belonging to the AlterNIC. (The AlterNIC runs an alternate set of root nameservers that delegate to additional top-level domains with names like med and porn.) How'd it happen? Eugene Kashpureff, then affiliated with the AlterNIC, had run a program to "poison" the caches of major nameservers around the world, making them believe that www.internic.net's address was actually the address of the AlterNIC web server.

Kashpureff hadn't made any attempt to disguise what he had done; the web site that users reached was plainly the AlterNIC's, not the InterNIC's. But imagine someone poisoning your nameserver's cache to direct www.amazon.com or www.wellsfargo.com to his own web server, conveniently located well outside local law enforcement jurisdiction. Further, imagine your users typing in their credit card numbers and expiration dates. Now you get the idea.

Protecting your users against these kinds of attacks requires DNS security. DNS security comes in several flavors. You can secure transactions—the queries, responses, and other messages your nameserver sends and receives. You can secure your nameserver, refusing queries, zone transfer requests, and dynamic updates from unauthorized addresses, for example. You can even secure zone data by digitally signing it.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

BIND 8.2 introduced a new mechanism for securing DNS messages called transaction signatures, or TSIG for short. TSIG uses shared secrets and a one-way hash function to authenticate DNS messages, particularly responses and updates.

TSIG, now codified in RFC 2845, is relatively simple to configure, light-weight for resolvers and nameservers to use, and flexible enough to secure DNS messages (including zone transfers) and dynamic updates. (Contrast this with the DNS Security Extensions, which we'll discuss at the end of this chapter.)

With TSIG configured, a nameserver or updater adds a TSIG record to the additional data section of a DNS message. The TSIG record "signs" the DNS message, proving that the message's sender had a cryptographic key shared with the receiver and that the message wasn't modified after it left the sender.

TSIG provides authentication and data integrity through the use of a special type of mathematical formula called a one-way hash function. A one-way hash function, also known as a cryptographic checksum or message digest, computes a fixed-size hash value based on arbitrarily large input. The magic of a one-way hash function is that each bit of the hash value depends on each and every bit of the input. Change a single bit of the input, and the hash value changes dramatically and unpredictably—so unpredictably that it's "computationally infeasible" to reverse the function and find an input that produces a given hash value.

TSIG uses a one-way hash function called MD5. In particular, it uses a variant of MD5 called HMAC-MD5. HMAC-MD5 works in a keyed mode in which the 128-bit hash value depends not only on the input, but also on a key.

We won't cover the TSIG record's syntax in detail because you don't need to know it: TSIG is a "meta-record" that never appears in zone data and is never cached by a resolver or nameserver. A signer adds the TSIG record to a DNS message, and the recipient removes and verifies the record before doing anything further, such as caching the data in the message.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

BIND 8 and 9 support a wide variety of security mechanisms. These features are particularly important if your nameserver is running on the Internet, but they're also useful on purely internal nameservers.

We'll start by discussing measures you should take on all nameservers for which security is important. Then we'll describe a model in which your nameservers are split into two communities, one for serving only resolvers and one for answering other nameservers' queries.

One of the most important ways you can enhance the security of your nameserver is to run a recent version of BIND. All versions of BIND 8 before 8.4.7 and all versions of BIND 9 older than 9.3.2 are susceptible to at least a few known attacks. Check the ISC's list of vulnerabilities in various BIND versions at http://www.isc.org/sw/bind/bind-security.php for updates.

But don't stop there: new attacks are being thought up all the time, so you'll have to do your best to keep abreast of BIND's vulnerabilities and the latest "safe" version of BIND. One good way to do that is to read the comp.protocols.dns.bind newsgroup or its mailing list equivalent, bind-users, regularly. If you'd prefer less noise, there's always the bind-announce mailing list, which carries only announcements of patches and new releases of BIND.

There's another aspect of BIND's version relevant to security: if a hacker can easily find out which version of BIND you're running, he may be able to tailor his attacks to that version of BIND. And, wouldn't you know it, since about BIND 4.9, BIND nameservers have replied to a certain query with their version. If you look up TXT records in the CHAOSNET class attached to the domain name version.bind, BIND graciously returns something like this:


% dig txt chaos version.bind.



; <<>> DiG 9.3.2 <<>> txt chaos version.bind.

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14286

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0



;; QUESTION SECTION:

;version.bind.                  CH      TXT



;; ANSWER SECTION:

version.bind.           0       CH      TXT     "9.3.2"



;; AUTHORITY SECTION:

version.bind.           0       CH      NS      version.bind.



;; Query time: 17 msec

;; SERVER: 192.168.0.1#53(192.168.0.1)

;; WHEN: Sat Jan  7 16:14:39 2006

;; MSG SIZE  rcvd: 62

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Domain Name System wasn't designed to work with Internet firewalls. It's a testimony to the flexibility of DNS and of its BIND implementation that you can configure DNS to work with, or even through, an Internet firewall.

That said, configuring BIND to work in a firewalled environment, although not difficult, takes a good, complete understanding of DNS and a few of BIND's more obscure features. Describing it also requires a large portion of this chapter, so here's a roadmap.

We'll start by describing the two major families of Internet firewall software: packet filters and proxies. The capabilities of each family have a bearing on how you'll need to configure BIND to work through the firewall. Next, we'll detail the two most common DNS architectures used with firewalls, forwarders and internal roots, and describe the advantages and disadvantages of each. We'll then introduce a solution using a new feature, forward zones, which combines the best of internal roots and forwarders. Finally, we'll discuss split namespaces and the configuration of the bastion host, the host at the core of your firewall system.

Before you start configuring BIND to work with your firewall, it's important to understand what your firewall is capable of. Your firewall's capabilities will influence your choice of DNS architecture and determine how you implement it. If you don't know the answers to the questions in this section, track down someone in your organization who does know and ask. Better yet, work with your firewall's administrator when designing your DNS architecture to ensure it will coexist with the firewall.

Note that this is far from a complete explanation of Internet firewalls. These few paragraphs describe only the two most common types of Internet firewalls and only in enough detail to show how the differences in their capabilities affect nameservers. For a comprehensive treatment of Internet firewalls, see Building Internet Firewalls

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

TSIG, which we described earlier in this chapter, is well suited to securing the communications between two nameservers or between an updater and a nameserver. However, it won't protect you if one of your nameservers is compromised: if someone breaks into the host that runs one of your nameservers, he may also gain access to its TSIG keys. Moreover, because TSIG uses shared secrets, it isn't practical to configure TSIG among many nameservers. You couldn't use TSIG to secure your nameservers' communications with arbitrary nameservers on the Internet because you can't distribute and manage that many keys.

The most common way to deal with key management problems like these is to use public-key cryptography. The DNS Security Extensions (DNSSEC), described in RFCs 4033, 4034, and 4035, use public-key cryptography to enable zone administrators to digitally sign their zone data, thereby proving its authenticity.

We'll describe the DNS Security Extensions in their current form as described by RFCs 4033 through 4035. These RFCs reflect substantial changes in DNSSEC since its original version, described in RFC 2065 (and in the previous edition of this book). However, the IETF's DNSEXT working group is still working on DNSSEC and may change aspects of it before it becomes a standard.

Also know that though BIND 8 provided preliminary support of DNSSEC as early as BIND 8.2, DNSSEC wasn't really usable before BIND 9, and it isn't implemented as described in this section (and in the latest RFCs) until 9.3.0. Consequently, we'll use BIND 9.3.2 in our examples. If you want to use DNSSEC, you really shouldn't use anything older.

Public-key cryptography solves the key distribution problem by using asymmetric cryptographic algorithms. In an asymmetric cryptographic algorithm, one key is used to decrypt data that another has encrypted. These two keys—a key pair—are generated at the same time using a mathematical formula. That's the only easy way to find two keys that have this special asymmetry (one decrypts what the other encrypts): it's very difficult to determine one key given the other. (In the most popular asymmetric cryptographic algorithm, RSA, that determination involves factoring very large numbers, a notoriously hard problem.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"Don't stand chattering to yourself like that," Humpty Dumpty said, looking at her for the first time, "but tell me your name and your business."

"My name is Alice, but—"

"It's a stupid name enough!" Humpty Dumpty interrupted impatiently. "What does it mean?"

"Must a name mean something?" Alice asked doubtfully.

"Of course it must," Humpty Dumpty said with a short laugh . . .

—

To be proficient at troubleshooting nameserver problems, you'll need a troubleshooting tool to send DNS queries, one that gives you complete control. We'll cover nslookup in this chapter because it's distributed with BIND and with many vendors' operating systems. That doesn't mean it's the best DNS troubleshooting tool available, though. nslookup has its faults—so many, in fact, that it's now deprecated (geekish for "officially out of favor") in the BIND 9 distribution. We'll cover it anyway because it's pervasive. We'll also cover dig, which provides similar functionality and doesn't suffer from nslookup's deficiencies.

Note that this chapter isn't comprehensive; there are aspects of nslookup and dig (mostly obscure and seldom used) that we won't cover. You can always consult the manual pages for those.

Much of the time, you'll use nslookup to send queries in the same way the resolver sends them. Sometimes, though, you'll use nslookup to query other nameservers as a nameserver would instead. The way you use it will depend on the problem you're trying to debug. You might wonder, "How accurately does nslookup emulate a resolver or a nameserver? Does nslookup actually use the BIND resolver library routines?" No, nslookup uses its own routines for querying nameservers, but those routines are based on the resolver routines. Consequently, nslookup's behavior is very similar to the resolver's behavior, but it does differ slightly. We'll point out some of those differences. As for emulating nameserver behavior, nslookup allows us to query another server with the same query message that a nameserver would use, but the retransmission scheme is quite different. Like a nameserver, though,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Much of the time, you'll use nslookup to send queries in the same way the resolver sends them. Sometimes, though, you'll use nslookup to query other nameservers as a nameserver would instead. The way you use it will depend on the problem you're trying to debug. You might wonder, "How accurately does nslookup emulate a resolver or a nameserver? Does nslookup actually use the BIND resolver library routines?" No, nslookup uses its own routines for querying nameservers, but those routines are based on the resolver routines. Consequently, nslookup's behavior is very similar to the resolver's behavior, but it does differ slightly. We'll point out some of those differences. As for emulating nameserver behavior, nslookup allows us to query another server with the same query message that a nameserver would use, but the retransmission scheme is quite different. Like a nameserver, though, nslookup can transfer a copy of the zone data. So nslookup doesn't emulate either the resolver or the nameserver exactly, but it does emulate them well enough to make a decent troubleshooting tool. Let's delve into those differences we alluded to.

nslookup talks to only one nameserver at a time. This is the biggest difference between nslookup's behavior and the resolver's behavior. The resolver uses each nameserver directive in resolv.conf. If there are two nameserver directives in resolv.conf, the resolver tries the first nameserver, then the second, then the first, then the second, until it receives a response or gives up. The resolver does this for every query. On the other hand, nslookup tries the first nameserver in resolv.conf and keeps retrying until it finally gives up on the first nameserver and tries the second. Once it gets a response, it locks onto that server and doesn't try the next. However, you want your troubleshooting tool to talk to only one nameserver so you can reduce the number of variables when analyzing a problem. If nslookup used more than one nameserver, you wouldn't have as much control over your troubleshooting session. So talking to only one server is the right thing for a troubleshooting tool to do.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Let's start our tutorial on nslookup by looking at how to start it and how to exit from it. You can run nslookup either interactively or noninteractively. If you only want to look up one record for one domain name, use the noninteractive form. If you plan on doing something more extensive, such as changing nameservers or options, use an interactive session.

To start an interactive session, just type nslookup:


% nslookup

Default Server:  toystory.movie.edu

Address:  0.0.0.0#53



> ^D

If you need help, type ? or help. When you want to exit, type ^D (Ctrl-D) or exit. If you try to exit from nslookup by interrupting it with ^C (or whatever your interrupt character is), you won't get very far. nslookup catches the interrupt, stops whatever it is doing (like a zone transfer), and gives you the > prompt.

For a noninteractive lookup, include the name you are looking up on the command line:


% nslookup carrie

Server:  toystory.movie.edu

Address:  0.0.0.0#53



Name:    carrie.movie.edu

Address: 192.253.253.4

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

nslookup has its own set of dials and knobs, called options. All of the option settings can be changed. We'll discuss here what each of the options means, and we'll use the rest of the chapter to show you how to use them.


% nslookup

Default Server:  bladerunner.fx.movie.edu

Address:  0.0.0.0#53



> set all

Default Server:  bladerunner.fx.movie.edu

Address:  0.0.0.0



Set options:

  nodebug         defname         search          recurse

  nod2            novc            noignoretc      port=53

  querytype=A     class=IN        timeout=5       retry=4

  root=a.root-servers.net.

  domain=fx.movie.edu

  srchlist=fx.movie.edu



> ^D

For BIND 9.3.2, a few of the options have been removed or changed:


  novc                  nodebug         nod2

  search                recurse

  timeout = 0           retry = 3       port = 53

  querytype = A         class = IN

  srchlist = fx.movie.edu

Before we get into the options, we need to cover the introductory lines. The default nameserver is bladerunner.fx.movie.edu. This means that nslookup will query bladerunner unless we specify another nameserver. The address 0.0.0.0 means "this host." When nslookup is using address 0.0.0.0 or 127.0.0.1 as its nameserver, it is using the server running on the local system—in this case, bladerunner.

The options come in two flavors: Boolean and value. The options that do not have an equals sign after them are Boolean options. They have the interesting property of being either "on" or "off." The value options can take on different, well, values. How can we tell which Boolean options are on and which are off? The option is off when a "no" precedes the option's name. nodebug means that debugging is off. As you might guess, the search option is on.

How you change Boolean or value options depends on whether you are using nslookup interactively. In an interactive session, you change an option with the set

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

nslookup implements the same search list as the resolver. When you're debugging, though, the search list can get in your way. You may need to turn off the search list completely (set nosearch) or add a trailing dot to the fully qualified domain name you are looking up. We prefer the latter, as you'll see in our examples.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There are little chores you'll come to use nslookup for almost every day: finding the IP address or MX records for a given domain name, or querying a particular nameserver for data. We'll cover these first, before moving on to the more occasional stuff.

By default, nslookup looks up the address for a domain name, or the domain name for an address. You can look up any record type by changing the querytype, as we show in this example:


% nslookup

Default Server:  toystory.movie.edu

Address:  0.0.0.0#53



> misery                 Look up address

Server:  toystory.movie.edu

Address:  0.0.0.0#53



Name:    misery.movie.edu

Address:  192.253.253.2



> 192.253.253.2          Look up domain name

Server:  toystory.movie.edu

Address:  0.0.0.0#53



Name:    misery.movie.edu

Address:  192.253.253.2



> set q=mx               Look up MX records

> wormhole

Server:  toystory.movie.edu

Address:  0.0.0.0#53



wormhole.movie.edu      preference = 10, mail exchanger = wormhole.movie.edu

wormhole.movie.edu      internet address = 192.249.249.1

wormhole.movie.edu      internet address = 192.253.253.1



> set q=any              Look up records of any type

> monsters-inc

Server:  toystory.movie.edu

Address:  0.0.0.0#53



monsters-inc.movie.edu       internet address = 192.249.249.4

monsters-inc.movie.edu       preference = 10, mail exchanger = monsters-inc.movie.edu

monsters-inc.movie.edu       internet address = 192.249.249.4

These are only a few of the valid DNS record types, of course. For a more complete list, see Appendix A.

If you've used nslookup before, you might have noticed something peculiar: the first time you look up a remote domain name, the answer is authoritative, but the second time you look up the same name, it is nonauthoritative. Here's an example:


% nslookup

Default Server:  toystory.movie.edu

Address:  0.0.0.0#53



> slate.mines.colorado.edu.

Server:  toystory.movie.edu

Address:  0.0.0.0#53



Name:     slate.mines.colorado.edu

Address:  138.67.1.3



>

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Let's move on to some tricks you'll probably use less often but are still handy to have in your repertoire. Most of these will be helpful when you are trying to troubleshoot a DNS or BIND problem; they'll enable you to grub around in the messages the resolver sees and mimic a BIND nameserver querying another nameserver or transferring zone data.

If you need to, you can direct nslookup to show you the queries it sends out and the responses it receives. Turning on debug shows the responses. Turning on d2 shows the queries as well. When you want to turn off debugging completely, you have to use set nodebug because set nod2 turns off only level 2 debugging. After the following trace, we'll explain some parts of the output. If you want, pull out your copy of RFC 1035, turn to page 25, and read along with our explanation.


% nslookup

Default Server:  toystory.movie.edu

Address:  0.0.0.0#53



> set debug

> wormhole

Server:  toystory.movie.edu

Address:  0.0.0.0#53



------------

Got answer:

    HEADER:

        opcode = QUERY, id = 6813, rcode = NOERROR

        header flags:  response, auth. answer, want recursion,

        recursion avail.  questions = 1,  answers = 2,

        authority records = 2,  additional = 3



    QUESTIONS:

        wormhole.movie.edu, type = A, class = IN

    ANSWERS:

    ->  wormhole.movie.edu

        internet address = 192.253.253.1

        ttl = 86400 (1D)

    ->  wormhole.movie.edu

        internet address = 192.249.249.1

        ttl = 86400 (1D)

    AUTHORITY RECORDS:

    ->  movie.edu

        nameserver = toystory.movie.edu

        ttl = 86400 (1D)

    ->  movie.edu

        nameserver = wormhole.movie.edu

        ttl = 86400 (1D)

    ADDITIONAL RECORDS:

    ->  toystory.movie.edu

        internet address = 192.249.249.3

        ttl = 86400 (1D)

    ->  wormhole.movie.edu

        internet address = 192.253.253.1

        ttl = 86400 (1D)

    ->  wormhole.movie.edu

        internet address = 192.249.249.1

        ttl = 86400 (1D)



------------

Name:    wormhole.movie.edu

Addresses:  192.253.253.1, 192.249.249.1



>

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The last thing you want is to have problems with your troubleshooting tool. Unfortunately, some types of failures render nslookup nearly useless. Other types of nslookup failures are (at best) confusing, because they don't give you any clear information to work with. While there may be a few problems with nslookup itself, most of the problems you encounter will be caused by nameserver configuration and operation. We'll cover these problems here.

This isn't really a problem per se, but it can be awfully confusing. If you use nslookup to look up a type of record for a domain name, and the domain name exists but records of the type you're looking for don't, you'll get an error like this:


% nslookup

Default Server:  toystory.movie.edu

Address:  0.0.0.0#53



> movie.edu.

Server:  toystory.movie.edu

Address:  0.0.0.0#53



*** No address (A) records available for movie.edu.

So what types of records do exist? Just type set type=any to find out:


> set type=any

> movie.edu.

Server:  toystory.movie.edu

Address:  0.0.0.0#53



movie.edu

      origin = toystory.movie.edu

      mail addr = al.shrek.movie.edu

      serial = 42

      refresh = 10800 (3H)

      retry   = 3600 (1H)

      expire  = 604800 (7D)

      minimum ttl = 86400 (1D)

movie.edu    nameserver = toystory.movie.edu

movie.edu    nameserver = wormhole.movie.edu

movie.edu    nameserver = zardoz.movie.edu

movie.edu    preference = 10, mail exchanger = postmanrings2x.movie.edu

postmanrings2x.movie.edu        internet address = 192.249.249.66

What could have gone wrong if your nameserver can't look up its own name?


% nslookup

Default Server:  toystory.movie.edu

Address:  0.0.0.0#53



> toystory

Server:  toystory.movie.edu

Address:  0.0.0.0#53



*** toystory.movie.edu can't find toystory: No response from server

The "no response from server" error message means exactly that: the resolver didn't get back a response. nslookup

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

System administrators have a thankless job. There are certain questions, usually quite simple ones, that users ask over and over again. And sometimes, when in a creative mood, sysadmins come up with clever ways to help their users. When the rest of us discover their ingenuity, we can only sit back, smile admiringly, and wish we had thought of it ourselves. Here is one such case, where a system administrator found a way to communicate the solution to the sometimes vexing puzzle of how to end an nslookup session:


% nslookup

Default Server:  envy.ugcs.caltech.edu

Address:  131.215.134.135



> quit

Server:  envy.ugcs.caltech.edu

Addresses:  131.215.134.135, 131.215.128.135



Name:    ugcs.caltech.edu

Addresses:  131.215.128.135, 131.215.134.135

Aliases:  quit.ugcs.caltech.edu

          use.exit.to.leave.nslookup.-.-.-.ugcs.caltech.edu



> exit

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

That's one way to deal with what's arguably a shortcoming in nslookup. Another is just to chuck nslookup and use dig, the Domain Information Groper (a reverse-engineered acronym if we've ever heard one).

We said earlier that dig isn't as pervasive as nslookup, so we'd better begin by telling you where to get it. You can pick up source for dig from the src/bin/dig directory (BIND 8), or the bin/dig directory (BIND 9) of the BIND distribution. If you build the whole distribution, you'll build a nice, new copy of dig, too.

With dig, you specify all aspects of the query you'd like to send on the command line; there's no interactive mode. You specify the domain name you want to look up as an argument, and the type of query you want to send (e.g., a for address records, mx for MX records) as another argument; the default is to look up address records. You specify the nameserver you'd like to query after an "@." You can use either a domain name or an IP address to designate a nameserver. The default is to query the nameservers in resolv.conf.

dig is smart about arguments, too. You can specify the arguments in any order you like, and dig will figure out that mx is probably the type of records, not the domain name, you want to look up.

One major difference between nslookup and dig is that dig doesn't apply the search list, so always use fully qualified domain names as arguments to dig. The following:


% dig plan9.fx.movie.edu

looks up address records for plan9.fx.movie.edu using the first nameserver in resolv.conf, while:


% dig acmebw.com mx

looks up MX records for acmebw.com on the same nameserver, and:


% dig @wormhole.movie.edu. movie.edu. soa

queries wormhole.movie.edu for the SOA record of movie.edu.

dig shows you the complete DNS response message in all its glory, with the various sections (header, question, answer, authority, and additional) clearly called out, and with resource records in those sections printed in master file format. This can come in handy if you need to use some of your troubleshooting tool's output in a zone datafile or in your root hints file. For example, the output produced by:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"O Tiger-lily!" said Alice, addressing herself to one that was waving gracefully about in the wind, "I wish you could talk!"

"We can talk," said the Tiger-lily, "when there's anybody worth talking to."

—

One of the tools in your troubleshooting toolbox is the nameserver's debugging output. As long as your nameserver has been compiled with DEBUG defined, you can get query-by-query reports of its internal operation. The messages you get are often quite cryptic; they were meant for someone who has the source code to follow. We'll explain some of the debugging output in this chapter. Our goal is to cover just enough for you to follow what the nameserver is doing; we aren't trying to supply an exhaustive compilation of debugging messages.

As you read through the explanations here, think back to material covered in earlier chapters. Seeing this information again, in another context, should help you understand more fully how a nameserver works.

The amount of information the nameserver provides depends on the debugging level. The lower the debugging level, the less information you get. Higher debugging levels give you more information, but they also fill up your disk faster. After you've read a lot of debugging output, you'll develop a feel for how much information you'll need to solve any particular problem. Of course, if you can easily recreate the problem, you can start at level 1 and increase the debugging level until you have enough information. For the most basic problem—why a name can't be looked up—level 1 will often suffice, so you should start there.

Here's a list of the information that each debugging level produces for BIND 8 and BIND 9 nameservers. The debugging information is cumulative; for example, level 2 includes all of level 1's debugging information. The data is divided into the following basic areas: starting up, updating the database, processing queries, and maintaining zones. We won't cover updating the nameserver's internal database; problems almost always occur elsewhere. However,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The amount of information the nameserver provides depends on the debugging level. The lower the debugging level, the less information you get. Higher debugging levels give you more information, but they also fill up your disk faster. After you've read a lot of debugging output, you'll develop a feel for how much information you'll need to solve any particular problem. Of course, if you can easily recreate the problem, you can start at level 1 and increase the debugging level until you have enough information. For the most basic problem—why a name can't be looked up—level 1 will often suffice, so you should start there.

Here's a list of the information that each debugging level produces for BIND 8 and BIND 9 nameservers. The debugging information is cumulative; for example, level 2 includes all of level 1's debugging information. The data is divided into the following basic areas: starting up, updating the database, processing queries, and maintaining zones. We won't cover updating the nameserver's internal database; problems almost always occur elsewhere. However, what the nameserver adds or deletes from its internal database can be a problem, as you'll see in Chapter 14.

BIND 8 and 9 have a whopping 99 debug levels, but most of the debugging messages are logged at just a few of those levels. We'll look at those now.

Section 13.1.1.1: BIND 8 debugging levels

Level 1: The information at this level is necessarily brief. Nameservers can process lots of queries, which can create lots of debugging output. Since the output is condensed, you can collect data over long periods. Use this debugging level for basic startup information and for watching query transactions. You'll see some errors logged at this level, including syntax errors and DNS packet-formatting errors. This level also shows referrals.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Nameserver debugging can be started either from the command line or with control messages. If you need to see the startup information to diagnose your current problem, you'll have to use the command-line option. If you want to start debugging on a nameserver that is already running, or if you want to turn off debugging, you'll have to use controls. The nameserver writes its debugging output to named.run in the nameserver's working directory.

When troubleshooting, you sometimes need to see the sortlist, know which interface a file descriptor is bound to, or find out where in the initialization stage the nameserver was when it exited (if the syslog error message wasn't clear enough). To see this kind of debugging information, you'll have to start debugging with a command-line option; by the time you send a control message, it will be too late. The command-line option for debugging is —d level.

If you don't need to see the nameserver's initialization, start your nameserver without the debugging command-line option. You can later turn debugging on and off using rndc (or, with BIND 8, ndc) to send the appropriate control message to the nameserver process. Here, we set debugging to level 3, then turn off debugging:


# rndc trace 3

# rndc notrace

And, as you might expect, if you turn on debugging from the command line, you can still use rndc to change the nameserver's debug level.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We'll cover five examples of debugging output. The first example shows the nameserver starting up. The next two examples show successful name lookups. The fourth example shows a slave nameserver keeping its zone up to date. And in the last example, we switch from showing you nameserver behavior to showing you resolver behavior: the resolver search algorithm. After each trace (except the last one), we killed the nameserver and started it again so that each trace started with a fresh, nearly empty cache.

You might wonder why we've chosen to show normal nameserver behavior for all our examples; after all, this chapter is about debugging. We're showing you normal behavior because you have to know what normal operation is before you can track down abnormal operation. Another reason is to help you understand the concepts (retransmissions, roundtrip times, etc.) we described in earlier chapters.

We'll start the debugging examples by watching the nameserver initialize. This first nameserver is a BIND 8 nameserver. We used -d 1 on the command line, and this is the named.run output that resulted:


1 Debug level 1

2 Version = named 8.2.3-T7B Mon Aug 21 19:21:21 MDT 2000

3 cricket@abugslife.movie.edu:/usr/local/src/bind-8.2.3-T7B/src/bin/named

4 conffile = ./named.conf

5 starting.  named 8.2.3-T7B Mon Aug 21 19:21:21 MDT 2000

6 cricket@abugslife.movie.edu:/usr/local/src/bind-8.2.3-T7B/src/bin/named

7 ns_init(./named.conf)

8 Adding 64 template zones

9 update_zone_info('0.0.127.in-addr.arpa', 1)

10 source = db.127.0.0

11 purge_zone(0.0.127.in-addr.arpa,1)

12 reloading zone

13 db_load(db.127.0.0, 0.0.127.in-addr.arpa, 1, Nil, Normal)

14 purge_zone(0.0.127.in-addr.arpa,1)

15 master zone "0.0.127.in-addr.arpa" (IN) loaded (serial 2000091500)

16 zone[1] type 1: '0.0.127.in-addr.arpa' z_time 0, z_refresh 0

17 update_zone_info('.', 3)

18 source = db.cache

19 reloading hint zone

20 db_load(db.cache, , 2, Nil, Normal)

21 purge_zone(,1)

22 hint zone "" (IN) loaded (serial 0)

23 zone[2] type 3: '.' z_time 0, z_refresh 0

24 update_pid_file(  )

25 getnetconf(generation 969052965)

26 getnetconf: considering lo [127.0.0.1]

27 ifp->addr [127.0.0.1].53 d_dfd 20

28 evSelectFD(ctx 0x80d8148, fd 20, mask 0x1, func 0x805e710, uap 0x40114344)

29 evSelectFD(ctx 0x80d8148, fd 21, mask 0x1, func 0x8089540, uap 0x4011b0e8)

30 listening on [127.0.0.1].53 (lo)

31 getnetconf: considering eth0 [192.249.249.3]

32 ifp->addr [192.249.249.3].53 d_dfd 22

33 evSelectFD(ctx 0x80d8148, fd 22, mask 0x1, func 0x805e710, uap 0x401143b0)

34 evSelectFD(ctx 0x80d8148, fd 23, mask 0x1, func 0x8089540, uap 0x4011b104)

35 listening on [206.168.194.122].53 (eth0)

36 fwd ds 5 addr [0.0.0.0].1085

37 Forwarding source address is [0.0.0.0].1085

38 evSelectFD(ctx 0x80d8148, fd 5, mask 0x1, func 0x805e710, uap 0)

39 evSetTimer(ctx 0x80d8148, func 0x807cbe8, uap 0x40116158, due

969052990.812648000, inter 0.000000000)

40 exit ns_init(  )

41 update_pid_file(  )

42 Ready to answer queries.

43 prime_cache: priming = 0, root = 0

44 evSetTimer(ctx 0x80d8148, func 0x805bc30, uap 0, due

969052969.000000000, inter 0.000000000)

45 sysquery: send -> [192.33.4.12].53 dfd=5 nsid=32211 id=0 retry=969052969

46 datagram from [192.33.4.12].53, fd 5, len 436

47 13 root servers

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this trace, we'll show you what the BIND search algorithm and negative caching look like from the perspective of a BIND 8 nameserver. We could look up galt.cs.purdue.edu like the last trace, but it wouldn't show the search algorithm. Instead, we will look up foo.bar, a name that doesn't exist. In fact, we'll look it up twice:


1 datagram from cujo.horror.movie.edu 1109, fd 6, len 25

2 req: nlookup(foo.bar) id 19220 type=1 class=1

3 req: found 'foo.bar' as '' (cname=0)

4 forw: forw -> D.ROOT-SERVERS.NET 53 ds=7 nsid=2532 id=19220 0ms retry 4sec

5

6 datagram from D.ROOT-SERVERS.NET 53, fd 5, len 25

7 ncache: dname foo.bar, type 1, class 1

8 send_msg -> cujo.horror.movie.edu 1109 (UDP 6) id=19220

9

10 datagram from cujo.horror.movie.edu 1110, fd 6, len 42

11 req: nlookup(foo.bar.horror.movie.edu) id 19221 type=1 class=1

12 req: found 'foo.bar.horror.movie.edu' as 'horror.movie.edu' (cname=0)

13 forw: forw -> carrie.horror.movie.edu 53 ds=7 nsid=2533 id=19221 0ms

                                                          retry 4sec

14 datagram from carrie.horror.movie.edu 53, fd 5, len 42

15 ncache: dname foo.bar.horror.movie.edu, type 1, class 1

16 send_msg -> cujo.horror.movie.edu 1110 (UDP 6) id=19221

Look up foo.bar again:


17 datagram from cujo.horror.movie.edu 1111, fd 6, len 25

18 req: nlookup(foo.bar) id 15541 type=1 class=1

19 req: found 'foo.bar' as 'foo.bar' (cname=0)

20 ns_req: answer -> cujo.horror.movie.edu 1111 fd=6 id=15541 size=25 Local

21

22 datagram from cujo.horror.movie.edu 1112, fd 6, len 42

23 req: nlookup(foo.bar.horror.movie.edu) id 15542 type=1 class=1

24 req: found 'foo.bar.horror.movie.edu' as 'foo.bar.horror.movie.edu' (cname=0)

25 ns_req: answer -> cujo.horror.movie.edu 1112 fd=6 id=15542 size=42 Local

Let's look at the resolver search algorithm. The first name looked up (line 2) is exactly the name we typed in. Since the name had at least one dot, it is looked up without modification. When that name lookup failed, horror.movie.edu was appended to the name and looked up.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Here's what a BIND 9.3.1 nameserver's debugging output looks like when looking up foo.bar twice:


04-Jul-2005 15:45:42.944 client cujo.horror.movie.edu#1044: query: foo.bar A +

04-Jul-2005 15:45:42.945 createfetch: foo.bar. A

04-Jul-2005 15:45:42.945 createfetch: . NS

04-Jul-2005 15:45:43.425 client cujo.horror.movie.edu#1044: query:

                                                  foo.bar.horror.movie.edu A +

04-Jul-2005 15:45:43.425 createfetch: foo.bar.horror.movie.edu. A

This assumes, of course, that you added the following lines to /etc/named.conf to see the queries:


logging {

    category queries {

        default_debug;

    };

};

This output is more subtle and succinct than BIND 8's, but you can get the information you need from it. The first line, at 15:45:42.944, shows the initial query for foo.bar's address arriving from the client cujo.horror.movie.edu (remember, we ran this through our magic IP-to-name filter, which we'll introduce next). The next two lines show the nameserver dispatching two tasks (createfetch) to look up foo.bar: the first is the actual task to look up foo.bar's address, while the second is a subsidiary task to look up NS records for the root zone, necessary to complete the foo.bar lookup. Once the nameserver has current NS records for the root, it queries a root nameserver for foo.bar's address and gets a response indicating that no top-level domain called bar exists. Unfortunately, you don't see that.

The line at 15:45:43.425 shows cujo.horror.movie.edu applying the search list, looking up foo.bar.horror.movie.edu. This causes the nameserver to dispatch a task (createfetch) to look up that domain name.

When we look up foo.bar again, we see:


04-Jul-2005 15:45:46.557 client cujo.horror.movie.edu#1044: query: foo.bar A +

04-Jul-2005 15:45:46.558 client cujo.horror.movie.edu#1044: query:

                                                  foo.bar.horror.movie.edu A +

Notice the absence of createfetch entries? That's because our nameserver has the negative answers cached.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Let's wrap up loose ends. We told you about our tool to convert IP addresses to names so that your debugging output is easier to read. Here is such a tool written in Perl:


#!/usr/bin/perl -n



use "Socket";



if (/\b)(\d+\.\d+\.\d+\.\d+)\b/) {

$addr = pack('C4', split(/\./, $1));

($name, $rest) = gethostbyaddr($addr, &AF_INET);

if($name) {s/$1/$name/};

}



print;

It's best not to pipe named.run output into this script with debugging on because the script will generate its own queries to the nameserver.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"Of course not," said the Mock Turtle. "Why, if a fish came to me, and told me he was going on a journey, I should say, `With what porpoise?'"

"Don't you mean `purpose'?" said Alice.

"I mean what I say," the Mock Turtle replied, in an offended tone. And the Gryphon added, "Come, let's hear some of your adventures."

—

In the last two chapters, we've demonstrated how to use nslookup and dig, and how to read the nameserver's debugging information. In this chapter, we'll show you how to use these tools—plus traditional Unix networking tools like trusty ol' ping—to troubleshoot real-life problems with DNS and BIND.

Troubleshooting, by its nature, is a tough subject to teach. You start with any of a world of symptoms and try to work your way back to the cause. We can't cover the whole gamut of problems you may encounter on the Internet, but we will certainly do our best to show how to diagnose the most common of them. And along the way, we hope to teach you troubleshooting techniques that will be valuable in tracking down more obscure problems that we don't document.

Before we launch into a discussion of how to troubleshoot a DNS or BIND problem, we should make sure you know how to tell whether a problem is caused by DNS as opposed to NIS. On hosts running NIS, figuring out whether the culprit is DNS or NIS can be difficult. The stock BSD nslookup, for example, doesn't pay any attention to NIS. You can run nslookup on a Sun and query the nameserver 'til the cows come home while all the other services are using NIS.

How do you know where to put the blame? Some vendors have modified nslookup to use NIS for name service if NIS is configured. The HP-UX nslookup, for example, will report that it's querying an NIS server when it starts up:


% nslookup

Default NIS Server:  toystory.movie.edu

Address:  192.249.249.3



>

A surefire way to decide whether an answer came from NIS is to use ypcat to list the hosts database. For example, to find out whether

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before we launch into a discussion of how to troubleshoot a DNS or BIND problem, we should make sure you know how to tell whether a problem is caused by DNS as opposed to NIS. On hosts running NIS, figuring out whether the culprit is DNS or NIS can be difficult. The stock BSD nslookup, for example, doesn't pay any attention to NIS. You can run nslookup on a Sun and query the nameserver 'til the cows come home while all the other services are using NIS.

How do you know where to put the blame? Some vendors have modified nslookup to use NIS for name service if NIS is configured. The HP-UX nslookup, for example, will report that it's querying an NIS server when it starts up:


% nslookup

Default NIS Server:  toystory.movie.edu

Address:  192.249.249.3



>

A surefire way to decide whether an answer came from NIS is to use ypcat to list the hosts database. For example, to find out whether andrew.cmu.edu is in your NIS hosts map, you could execute:


% ypcat hosts | grep andrew.cmu.edu

If you find the answer in NIS (and you know NIS is being consulted first), you've found the cause of the problem.

Finally, in the versions of Unix that use the nsswitch.conf file, you can determine the order in which the different name services are used by referring to the entry for the hosts database in the file. An entry like this, for example, indicates that NIS is being checked first:


hosts:    nis dns files

while this entry has the name resolver querying DNS first:


hosts:    dns nis files

For more detailed information on the syntax and semantics of the nsswitch.conf file, see Chapter 6.

These hints should help you identify the guilty party or at least exonerate one suspect. If you narrow down the suspects and DNS is still implicated, you'll just have to read this chapter.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We went over nslookup, dig, and the nameserver's debugging output in the last two chapters. Before we go on, let's introduce some new tools that can be useful in troubleshooting: named-xfer, nameserver database dumps, and query logging.

named-xfer is the program that BIND 8 nameservers start to perform zone transfers. (BIND 9 nameservers, you'll remember, are multithreaded, so they don't need a separate program to do inbound zone transfers; they just start a new thread.) named-xfer checks whether the slave's copy of the zone data is up to date and transfers a new zone if necessary.

In Chapter 13, we showed you the debugging output a BIND 8 slave nameserver logged as it checked its zone. When the slave server transferred the zone, it started a child process (named-xfer) to pull the data to the local filesystem. We didn't tell you, however, that you can also start named-xfer manually instead of waiting for named to start it, and that you can tell it to produce debugging output independent of named.

This can be useful if you're tracking down a problem with zone transfers but don't want to wait for named to schedule one. To test a zone transfer manually, you need to specify a number of command-line options:


% /usr/sbin/named-xfer

Usage error: no domain

Usage: named-xfer

        -z zone_to_transfer

        -f db_file

        [-i ixfr_file]

        [-s serial_no]

        [-d debug_level]

        [-l debug_log_file]

        [-t trace_file]

        [-p port]

        [-S] [-Z]

        [-C class]

        [-x axfr-src]

        [-X axfr-src-v6]

        [-T tsig_info_file]

        servers [-ixfr|-axfr]...

This is the output from a BIND 8.4.7 version of named-xfer. Earlier versions of named-xfer won't have all these options.

When named starts named-xfer, it specifies the -z option (the zone named wants to check), the -f option (the name of the zone datafile that corresponds to the zone, from

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now that we've given you a nice set of tools, let's talk about how you can use them to diagnose real problems. There are some problems that are easy to recognize and correct. We should cover these as a matter of course; they're some of the most common problems because they're caused by some of the most common mistakes. Here are the contestants, in no particular order. We call 'em our "Unlucky Thirteen."

The main symptom of this problem is that slave nameservers don't pick up any changes you made to the zone's datafile on the primary. The slaves think the zone data hasn't changed because the serial number is still the same.

How do you check whether you remembered to increment the serial number? Unfortunately, that's not so easy. If you don't remember what the old serial number was, and your serial number gives you no indication of when it was updated, there's no direct way to tell whether it's changed. When you reload the primary, it loads the updated zone file regardless of whether you've changed the serial number. It checks the file's timestamp, sees that it's been modified since it last loaded the data, and reads the file. About the best you can do is to use nslookup to compare the data returned by the primary and by a slave. If they return different data, you probably forgot to increment the serial number. If you can remember a recent change you made, you can look for that data. If you can't remember a recent change, you can try transferring the zone from a primary and from a slave, sorting the results, and using diff to compare them.

The good news is that, although determining whether the zone was transferred is tricky, making sure the zone is transferred is simple. Just increment the serial number on the primary's copy of the zone datafile and reload the zone on the primary. The slaves should pick up the new data within their refresh interval, or sooner if they use NOTIFY. If you run BIND 9.3 slaves, you can use the new rndc retransfer command to force an immediate zone transfer. To force BIND 8 slaves to transfer the new data, you can delete the backup file and restart

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

With the release of BIND 8, and now BIND 9, many Unix operating systems are updating their resolvers and nameservers. Some features of the most recent versions of BIND, however, may seem like errors to you after you upgrade to a new version. We'll try to give you an idea of some changes you may notice in your nameserver and name service after making the jump.

The changes to the resolver's default search list described in Chapter 6 may seem like a problem to your users. Recall that with a local domain name set to fx.movie.edu, your default search list will no longer include movie.edu. Therefore, users accustomed to using commands such as ssh db.personnel and having the partial domain name expanded to db.personnel.movie.edu will have their commands fail. To solve this problem, you can use the search directive to define an explicit search list that includes your local domain name's parent. Or just tell your users to expect the new behavior.

Before Version 4.9, a BIND nameserver would gladly load data in any zone from any zone datafile that the nameserver read as a primary. If you configured the nameserver as the primary for movie.edu and told it that the movie.edu data was in db.movie.edu, you could stick data about hp.com in db.movie.edu, and your nameserver would load the hp.com resource records into the cache. Some books even suggested putting the data for all your in-addr.arpa zones in one file. Ugh.

All BIND 4.9 and later nameservers ignore any "out of zone" resource records in a zone datafile. So if you cram PTR records for all your in-addr.arpa zones into one file and load it with a single zone statement, the nameserver ignores all the records not in the named zone. And that, of course, means loads of missing PTR records and failed gethostbyaddr() calls.

BIND does log that it's ignoring the records in syslog. The messages look like this in BIND 9:


Sep 26 13:48:19 toystory named[21960]: dns_master_load: db.movie.edu:16:

ignoring out-of-zone data

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

With the move to BIND 9 and the introduction of Microsoft DNS Server, more interoperability problems are cropping up between nameservers. There are also a handful of problems unique to one version or another of BIND or the underlying operating system. Many of these are easy to spot and correct, and we would be remiss if we didn't cover them.

When a Microsoft DNS Server is configured to consult a WINS server for names it can't find in a given zone, it inserts a special record into the zone datafile. The record looks like this:


@   IN   WINS   &IP address of WINS server

Unfortunately, WINS is not a standard record type in the IN class. Consequently, if there are BIND slaves that transfer this zone, they'll choke on the WINS record and refuse to load the zone:


May 23 15:58:43 toystory named-xfer[386]: "fx.movie.edu IN 65281" -

unknown type (65281)

The workaround for this is to configure the Microsoft DNS Server to filter out the proprietary record before transferring the zone. You do this by selecting the zone on the left side of the DNS Manager screen, right-clicking on it, and selecting Properties. Click on the WINS Lookup tab in the resulting Zone Properties window, shown in Figure 14-1.

Figure 14-1: Zone Properties window

Checking Settings only affect local server filters out the WINS record for that zone. However, if there are any Microsoft DNS Server slaves, they won't see the record either, even though they can use it.

You'll see this error only on BIND 8.1 servers:


May 8 03:44:38 toystory named[11680]: no NS RR for SOA MNAME "movie.edu" in

     zone "movie.edu"

The 8.1 server was a real stickler about the first field in the SOA record. Remember that one? In Chapter 4, we said that it was, by convention, the domain name of the primary nameserver for the zone. BIND 8.1 assumes it is and checks for a corresponding NS record pointing the zone's domain name to the server in that field. If there's no such NS record, BIND emits that error message. It will also prevent NOTIFY messages from working correctly. The solution is either to change your MNAME field to the domain name of a nameserver listed in an NS record or to upgrade to a newer version of BIND 8. Upgrading is the better option because BIND 8.1 is so old. The check was removed in BIND 8.1.1.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As we said in Chapter 11, transaction signatures require time synchronization and key synchronization (the same key on either end of the transaction, plus the same key name) to work. Here are a couple of errors that may arise if you lose time synchronization or use different keys or key names:

Here's an error you'd see on a BIND 8 nameserver if you had configured TSIG but had too much clock skew between your primary nameserver and a slave:


Sep 27 10:47:49 wormhole named[22139]: Err/TO getting serial# for "movie.edu"

Sep 27 10:47:49 wormhole named-xfer[22584]: SOA TSIG verification from server

[192.249.249.3], zone movie.edu: message had BADTIME set (18)

Here, your nameserver tries to check the serial number of the movie.edu zone on toystory.movie.edu (192.249.249.3). The response from toystory.movie.edu doesn't verify because wormhole.movie.edu's clock shows a time difference of more than 10 minutes from the time the response was signed. The Err/TO message is just a byproduct of the failure of the TSIG-signed response to verify.
If you use a different key name on either end of the transaction, even if the data the key name refers to is the same, you'll see an error like this one from your BIND 8 nameserver:
```
Sep 27 12:02:44 wormhole named-xfer[22651]: SOA TSIG verification from server

[209.8.5.250], zone movie.edu: BADKEY(-17)
```
This time, the TSIG-signed response doesn't check out because the verifier can't find a key with the name specified in the TSIG record. You'd see the same error if the key name matched but pointed to different data.

As always, BIND 9 is considerably more closed-mouthed about TSIG failure, reporting only:


Sep 27 13:35:42.804 client 192.249.249.1#1115: query: movie.edu SOA

Sep 27 13:35:42.804 client 192.249.249.1#1115: error

at debug level 3 for both previous scenarios.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Some problems, unfortunately, aren't as easy to identify as the ones we listed. You'll experience some misbehavior but won't be able to attribute it directly to its cause, often because any of a number of problems can cause the symptoms you see. For cases like this, we'll suggest some of the common causes of these symptoms and ways to isolate them.

The first thing to do when a program such as ssh or ftp can't look up a local domain name is to use nslookup or dig to try to look up the same name. When we say "the same name," we mean literally the same name: don't add labels and a trailing dot if the user didn't type them. Don't query a different nameserver than the user did.

As often as not, the user mistyped the name or doesn't understand how the search list works and just needs direction. Occasionally, you'll turn up real host configuration errors:

Syntax errors in resolv.conf (problem 11 in the earlier section "Potential Problem List")
An unset local domain name (problem 12)

You can check for either of these using nslookup's set all command.

If nslookup points to a problem with the nameserver rather than with the host configuration, check for the problems associated with the type of nameserver. If the nameserver is the primary for the zone, but it isn't responding with data you think it should:

Check that the zone datafile contains the data in question and that the nameserver has loaded it (problem 2). A database dump can tell you for sure whether the data was loaded.
Check the configuration file and the pertinent zone datafile for syntax errors (problem 5). Check the nameserver's syslog output for indications of those errors.
Ensure that the records have trailing dots, if they require them (problem 6).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"I know what you're thinking about," said Tweedledum; "but it isn't so, nohow."

"Contrariwise," continued Tweedledee, "if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic."

—

I bet you think resolver programming is hard. Contrariwise! It isn't very hard, really. The format of DNS messages is quite straightforward; you don't have to deal with ASN.1 at all, as you do with SNMP. And you have nifty library routines to make parsing DNS messages easy. We've included portions of RFC 1035 in Appendix A. However, you might find it handy to have a copy of RFC 1035 to look at as we go through this chapter; at least have a copy of it nearby when you write your own DNS programs.

Before you go off and write a C program to do your DNS chore, you should write the program as a shell script using nslookup or dig. There are good reasons to start with a shell script:

You can write the shell script much faster than you can write a C program.
If you're not comfortable with DNS, you can work out the details of your program's logic with a quick shell script prototype. When you finally write the C program, you can focus on the additional control you have with C rather than spending your time reworking the basic functionality.
You might find out that the shell script version does your task well enough so that you don't have to write the C program after all. And not only is it quicker to write shell scripts, but they're easier to maintain if you stick with them for the long run.

If you prefer Perl over plain old shell programming, you can use Perl instead. At the end of this chapter, we'll show you how to use the Perl Net::DNS module written by Michael Fuhr.

Before you write a program, you need a problem to solve. Let's suppose you want your network management system to watch over your primary master and slave nameservers. You want it to notify you of several problems: a nameserver that isn't running (it might have died), a nameserver that is not authoritative for a zone it is supposed to be authoritative for (the config file or zone datafile might have been messed up), or a nameserver that has fallen behind in updating its zone data (the primary master's serial number might have been decreased accidentally).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before you go off and write a C program to do your DNS chore, you should write the program as a shell script using nslookup or dig. There are good reasons to start with a shell script:

You can write the shell script much faster than you can write a C program.
If you're not comfortable with DNS, you can work out the details of your program's logic with a quick shell script prototype. When you finally write the C program, you can focus on the additional control you have with C rather than spending your time reworking the basic functionality.
You might find out that the shell script version does your task well enough so that you don't have to write the C program after all. And not only is it quicker to write shell scripts, but they're easier to maintain if you stick with them for the long run.

If you prefer Perl over plain old shell programming, you can use Perl instead. At the end of this chapter, we'll show you how to use the Perl Net::DNS module written by Michael Fuhr.

Before you write a program, you need a problem to solve. Let's suppose you want your network management system to watch over your primary master and slave nameservers. You want it to notify you of several problems: a nameserver that isn't running (it might have died), a nameserver that is not authoritative for a zone it is supposed to be authoritative for (the config file or zone datafile might have been messed up), or a nameserver that has fallen behind in updating its zone data (the primary master's serial number might have been decreased accidentally).

Each problem is easily detectable. If a nameserver is not running on a host, the host sends back an ICMP port unreachable message. You can find this out with either a query tool or the resolver routines. Checking whether a nameserver is authoritative for a zone is easy: ask it for the zone's SOA record. If the answer is nonauthoritative or the nameserver does not have the SOA record, there's a problem. You'll have to ask for the SOA record in a

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before writing any code, though, you need to be familiar with the DNS message format and the resolver library routines. In the shell script we just wrote, nslookup parsed the DNS message. In a C program, though, you have to do the parsing. Let's start this section on programming by looking at the DNS message format.

You've seen the DNS message format before, in Chapter 12. It looks like this:

Header section
Question section
Answer section
Authority section
Additional section

The format of the header section is described in RFC 1035 on pages 26–28, and in Appendix A of this book. It looks like this:


query identification number (2 octets)

query response (1 bit)

opcode (4 bits)

authoritative answer (1 bit)

truncation (1 bit)

recursion desired (1 bit)

recursion available (1 bit)

reserved (3 bits)

response code (4 bits)

question count (2 octets)

answer record count (2 octets)

name server record count (2 octets)

additional record count (2 octets)

You'll also find opcode, response code, type, and class values defined in arpa/nameser.h, as well as routines to extract this information from a message. We'll discuss these routines, part of the nameserver library, shortly.

The question section is described on pages 28–29 of RFC 1035. It looks like this:


domain name (variable length)

query type (2 octets)

query class (2 octets)

The answer, authority, and additional sections are described on pages 29–30 of RFC 1035. These sections comprise some number of resource records that look like this:


domain name (variable length)

type (2 octets)

class (2 octets)

TTL (4 octets)

resource data length (2 octets)

resource data (variable length)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

If using the shell to parse nslookup's output seems too awkward and writing a C program seems too complicated, consider writing your program in Perl using the Net::DNS module written by Michael Fuhr. You'll find the package at http://www.perl.com/CPAN-local/modules/by-module/Net/Net-DNS-0.12.tar.gz.

Net::DNS treats resolvers, DNS messages, sections of DNS messages, and individual resource records as objects and provides methods for setting or querying each object's attributes. We'll examine each object type first, then give a Perl version of our check_soa program.

Before making any queries, you must first create a resolver object:


$res = new Net::DNS::Resolver;

Resolver objects are initialized from your resolv.conf file, but you can change the default settings by making calls to the object's methods. Many of the methods described in the Net::DNS::Resolver manual page correspond to fields and options in the _res structure described earlier in this chapter. For example, if you want to set the number of times the resolver tries each query before timing out, you can call the $res->retry method:


$res->retry(2);

To make a query, call one of the following methods:


$res->search

$res->query

$res->send

These methods behave like the res_search, res_query, and res_send library functions described in the C programming section, though they take fewer arguments. You must provide a domain name, and you can optionally provide a record type and class (the default behavior is to query for A records in the IN class). These methods return Net::DNS::Packet objects, which we'll describe next. Here are a few examples:


$packet = $res->search("terminator");

$packet = $res->query("movie.edu", "MX");

$packet = $res->send("version.bind", "TXT", "CH");

Resolver queries return Net::DNS::Packet objects, whose methods you can use to access the header, question, answer, authority, and additional sections of a DNS message:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"Now if you'll only attend, Kitty, and not talk so much, I'll tell you all my ideas about Looking-glass House."

—

You've now seen bits and pieces of the Movie U. DNS infrastructure: our first primary and slave nameservers in Chapter 4, more slaves in Chapter 8, a delegated subdomain and its associated authoritative nameservers in Chapter 9. In Chapter 11, we introduced external nameservers and forwarders, split namespaces, views, and more. It may be difficult to get a sense of how all these components work together because we introduced them over so many pages. In this chapter, we'll put all of these components together into an overall design for a DNS infrastructure—what we call DNS architecture.

DNS architecture focuses on high-level aspects of your nameservers' configuration rather than the contents of your zones. Which nameserver is primary and which is slave for which zones? How are Internet domain names resolved? Who forwards to whom? Which nameserver-based ACLs and firewall rules protect which nameservers?

It's critical that you document your DNS architecture, just as you would your network topology. That documentation can help you identify single points of failure, performance bottlenecks, and security exposures. When name resolution goes awry, it'll be much easier to track down the problem with a thorough understanding of your DNS architecture rather than trying to piece it together from named.conf files and dig output.

However, digesting a complete DNS architecture all at once can be tough. Let's begin by looking at a small piece of it: external, authoritative nameservers.

External, authoritative nameservers play a particularly important role in name resolution: they make your external zone data available to nameservers on the Internet. When people on the Internet send us email or visit our web site, they rely on data served by these nameservers.

In Chapter 11, we described the nameservers that "advertised" our external zones. One,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

External, authoritative nameservers play a particularly important role in name resolution: they make your external zone data available to nameservers on the Internet. When people on the Internet send us email or visit our web site, they rely on data served by these nameservers.

In Chapter 11, we described the nameservers that "advertised" our external zones. One, ns.movie.edu, the primary for our external zones, sat outside our firewall on our perimeter network. Our ISP's nameserver, ns1.isp.net, acted as a slave for our external zones.

These nameservers, because they're directly exposed to the Internet, require special attention. We should disable recursion on ns.movie.edu, because it has no business handling recursive queries. This helps protect it against brute-force denial-of-service attacks, because its capacity to handle nonrecursive queries is many times its capacity to serve recursive queries. We should also limit zone transfers to just our ISP's nameserver, preferably using TSIG. This helps protect the nameserver against denial-of-service attacks in which the attacker simply tries to start numerous concurrent zone transfers. And we can implement ACLs on our router or external firewall to limit the network traffic that our external nameservers are exposed to: minimally, we need to allow inbound UDP and TCP to port 53 and outbound UDP and TCP from our nameserver's port 53.

We might later decide to enhance our external DNS infrastructure by setting up a new primary nameserver for our external zones, this one inside the firewall. In fact, using views, we can configure the internal movie.edu primary as the primary for the external movie.edu, too. This might be more convenient for us as administrators because it allows us to make changes to either the internal or external namespace from the same host. Here's how the primary's named.conf file might look:


options {

    directory "/var/named";

};



acl "internal" {

    127/8; 192.249.249/24; 192.253.253/24; 192.253.254/24; 192.254.20/24;

};



view "internal" {

    match-clients { "internal"; };

    recursion yes;



    zone "movie.edu" {

        type master;

        file "db.movie.edu.internal";

        forwarders {};

     };



    zone "249.249.192.in-addr.arpa" {

        type master;

        file "db.192.249.249";

    };



zone "253.253.192.in-addr.arpa" {

        type master;

        file "db.192.253.253";

    };



    zone "254.253.192.in-addr.arpa" {

        type master;

        file "db.192.253.254";

    };



    zone "20.254.192.in-addr.arpa" {

        type master;

        file "db.192.254.20";

    };



    zone "." {

        type hint;

        file "db.cache";

    };

};



key "ns.movie.edu" {

    algorithm hmac-md5;

    secret "JprUYzd+p2TO/B7k9k9Gdg==";

};



view "external" {

    match-clients { key "ns.movie.edu"; };

    recursion no;



    zone "movie.edu" {

        type master;

        file "db.movie.edu.external";

    };



    zone "4.1.200.in-addr.arpa" {

        type master;

        file "db.200.1.4";

    };

};

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

That's only half of our external DNS infrastructure. We also need to let internal resolvers and nameservers resolve Internet domain names. We can satisfy that requirement by allowing our internal nameservers to query arbitrary nameservers on the Internet, assuming our firewall is capable of that. That can be dangerous, though, for reasons we discussed back in Chapter 11. Consequently, most organizations run forwarders, which basically act as DNS proxy servers. (We introduced them back in Chapter 10.) We'll set up two forwarders, for redundancy, near our connection to the Internet. The forwarders can send queries through our firewall to nameservers on the Internet and receive responses; nameservers on the Internet, however, won't be allowed to query our forwarders. We can enforce this using an allow-query ACL in our forwarders' named.conf files and state-based UDP filtering on our firewall. As with the ACLs protecting the hidden primary, this gives us defense in depth.

Be sure to run the latest version of BIND, at least 9.3.0, on your internal nameservers to ensure that they choose intelligently between the two forwarders, as described in Chapter 10. Older BIND nameservers (e.g., before 9.3.0) with simpler forwarder selection algorithms can have problems if their first forwarder fails. Since they blindly try the first forwarder each time they forward a query, each forwarded query will take longer to process—sometimes several seconds longer. This can quickly add up on a nameserver processing hundreds of queries per second, even to the point of causing the nameserver to refuse new recursive queries. (Remember the default limit of 1,000 concurrent recursive queries?)

As recommended back in Chapter 11, we'll configure our internal nameservers to forward only queries for domain names outside our internal namespace. Any domain names ending in movie.edu should be resolved internally, via iterative queries. On authoritative movie.edu nameservers, this requires adding an empty forwarders substatement within the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We've already discussed one aspect of our internal DNS architecture: the forwarding configuration. While that's important, there's more to cover. For movie.edu, we have a primary nameserver running on toystory.movie.edu and slaves on wormhole.movie.edu and zardoz.movie.edu. For fx.movie.edu, bladerunner.fx.movie.edu is the primary and outland.fx.movie.edu is a slave.

If we can scare up a little extra hardware, we might set up hidden primaries for movie.edu and fx.movie.edu, too. In our external authoritative DNS infrastructure, a hidden primary configuration is necessary to prevent nameservers on the Internet from trying to query our primary, which is inside the firewall and not reachable from the Internet. Internally, a hidden primary configuration offers different advantages.

Inside the firewall, using a hidden primary helps to insulate our resolvers and nameservers from occasional configuration and data-entry snafus, maintenance-induced outages, and the like. If we accidentally mess up while editing a zone datafile on the movie.edu primary and our nameserver starts spewing SERVFAIL responses to movie.edu queries, this won't degrade our name service. Our slaves, which answer all queries from resolvers and other internal nameservers, won't be affected. They'll keep responding with the last good version of the zone they transferred, and won't transfer a new copy of the zone until the primary is back up and responding authoritatively. We'll have until movie.edu's expiration time—weeks—to fix the problem. If we can't fix the problem before the zone's expiration time, we should probably consider a change of career.

As time goes on, we'll probably need to expand our internal DNS infrastructure. Let's say we need to provide name service to a new building on campus. Using the guidelines in Chapter 8, we should determine whether the resolvers in the building generate enough queries to warrant setting up a local nameserver. If not—assuming the connection from the building to the rest of the campus network is reliable—we can just configure the building's resolvers to query our existing internal nameservers.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

While not strictly architectural, it's a good idea to spend some time documenting DNS operations. For example, you can institute a change control process, which can include saving older versions of named.conf and zone datafiles, perhaps by checking each modified file in using the Revision Control System, RCS. In fact, before saving a new version of a zone datafile, and certainly before putting the zone into production, you should check its syntax using the named-checkzone command, introduced in Chapter 4. Likewise, check the syntax of new named.conf files using named-checkconf. You can use a script to automate the process of managing zone datafiles, which will:

Edit the file
Use named-checkzone to check the zone datafile
If named-checkzone exits with errors, reedit the file
Otherwise, use ci -l to check the file in to RCS

To make it easier to monitor your nameservers, you can aggregate their syslog output on a single host. If you haven't reconfigured named's logging, that's a simple matter of adding a line like:


daemon.*        @loghost

to the syslog.conf files on the hosts running your nameservers. If that catches syslog messages from network servers you don't want sent, you can easily reconfigure your nameservers to use a unique facility name with a logging statement like this:


logging {

    channel default_syslog {

        syslog local0;

    };

};

Now adding the line:


local0.*        @loghost

to syslog.conf sends only named's syslog messages to your log host (assuming you're not using the local0 facility for anything else).

To ensure that you're notified of important messages your nameservers log, set up a logfile monitor. swatch is a popular (and free!) program that scans logfiles for regular expressions you specify and takes action—sends email, pages you—based on rules you establish.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As the administrators of many zones and several BIND nameservers, we believe it's critical to keep up with the latest developments. You can do so by subscribing to the BIND Users mailing list or, at minimum, BIND Announce, which we talked about in Chapter 3. Using these resources, you can stay up to date on BIND vulnerabilities, and the availability of patches and new versions of BIND.

Of course, we think a good way to keep up with DNS and BIND is to keep buying the latest edition of this book, too. See you next time!

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

"The time has come," the Walrus said, "To talk of many things: Of shoes—and ships—and sealing-wax—Of cabbages—and kings—And why the sea is boiling hot—And whether pigs have wings."

—

It's time we tied up loose ends. We've already covered the mainstream of DNS and BIND, but there's a handful of interesting niches we haven't explored. Some of these may actually be useful to you, such as instructions on how to accommodate Active Directory with BIND; others may just be interesting. We can't in good conscience send you out into the world without completing your education!

We talked about CNAME resource records in Chapter 4. We didn't tell you everything about CNAME records, though; we saved that for this chapter. When you set up your first nameservers, you probably wouldn't have cared about the subtle nuances of the magical CNAME record. Some of this trivia is interesting, some is arcane. We'll let you decide which is which.

If you've ever renamed your zone because of a company reorganization or acquisition, you may have considered creating a single CNAME record that pointed from the zone's old domain name to its new domain name. For instance, if the fx.movie.edu zone were renamed magic.movie.edu, we'd be tempted to create a single CNAME record to map all the old domain names to the new names:


fx.movie.edu.  IN  CNAME  magic.movie.edu.

With this in place, you'd expect a lookup of empire.fx.movie.edu to result in a lookup of empire.magic.movie.edu. Unfortunately, this doesn't work: you can't have a CNAME record attached to an interior node like fx.movie.edu if it owns other records. Remember that fx.movie.edu has an SOA record and NS records, so attaching a CNAME record to it violates the rule that a domain name be either an alias or a canonical name, not both.

If you're running BIND 9, though, you can use the brand-spanking-new DNAME record (introduced in Chapter 10) to create an alias from your zone's old domain name to its new one:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We talked about CNAME resource records in Chapter 4. We didn't tell you everything about CNAME records, though; we saved that for this chapter. When you set up your first nameservers, you probably wouldn't have cared about the subtle nuances of the magical CNAME record. Some of this trivia is interesting, some is arcane. We'll let you decide which is which.

If you've ever renamed your zone because of a company reorganization or acquisition, you may have considered creating a single CNAME record that pointed from the zone's old domain name to its new domain name. For instance, if the fx.movie.edu zone were renamed magic.movie.edu, we'd be tempted to create a single CNAME record to map all the old domain names to the new names:


fx.movie.edu.  IN  CNAME  magic.movie.edu.

With this in place, you'd expect a lookup of empire.fx.movie.edu to result in a lookup of empire.magic.movie.edu. Unfortunately, this doesn't work: you can't have a CNAME record attached to an interior node like fx.movie.edu if it owns other records. Remember that fx.movie.edu has an SOA record and NS records, so attaching a CNAME record to it violates the rule that a domain name be either an alias or a canonical name, not both.

If you're running BIND 9, though, you can use the brand-spanking-new DNAME record (introduced in Chapter 10) to create an alias from your zone's old domain name to its new one:


fx.movie.edu.  IN  DNAME  magic.movie.edu.

The DNAME record can coexist with other record types at fx.movie.edu—like the SOA record and NS records that are undoubtedly there—but you can't have any other domain names that end in fx.movie.edu. It'll "synthesize" CNAME records from domain names in fx.movie.edu to like domain names in magic.movie.edu when the names in fx.movie.edu are looked up.

If you don't have BIND 9, you'll have to create aliases the old-fashioned way—a CNAME record for each individual domain name within the zone:


empire.fx.movie.edu.       IN  CNAME  empire.magic.movie.edu.

bladerunner.fx.movie.edu.  IN  CNAME  bladerunner.magic.movie.edu.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Something else we haven't covered in detail yet is DNS wildcards. There are times when you want a single resource record to cover any possible name, rather than creating zillions of resource records that are all the same except for the domain name to which they apply. DNS reserves a special character, the asterisk (*), to use in zone datafiles as a wildcard name. It matches any number of labels in a name as long as there isn't an exact match with a name already in the nameserver's database.

Most often, you'd use wildcards to forward mail to non-Internet-connected networks. Suppose our site wasn't connected to the Internet, but we had a host that relayed mail between the Internet and our network. We can add a wildcard MX record to the movie.edu zone for Internet consumption that points all our mail to the relay. Here is an example:


*.movie.edu.  IN  MX  10 movie-relay.nea.gov.

Since the wildcard matches one or more labels, this resource record applies to names such as toystory.movie.edu, empire.fx.movie.edu, or casablanca.bogart.classics.movie.edu. The danger with wildcards is that they clash with search lists. This wildcard also matches cujo.movie.edu.movie.edu, making wildcards dangerous to use in our internal zone data. Remember that some versions of sendmail apply the search list when looking up MX records:


% nslookup

Default Server:  wormhole

Address:  0.0.0.0



> set type=mx                                   Look up MX records

> cujo.movie.edu                                for cujo

Server:  wormhole

Address:  0.0.0.0



cujo.movie.edu.movie.edu                        This isn't a real host's name!

        preference = 10, mail exchanger = movie-relay.nea.gov

What are other limitations of wildcards? Wildcards do not match domain names for which there is already data. Suppose we did use wildcards within our zone data, as in these partial contents of db.movie.edu:


*     IN  MX  10 mail-hub.movie.edu.

et    IN  MX  10 et.movie.edu.

jaws  IN  A   192.253.253.113

fx    IN  NS  bladerunner.fx.movie.edu.

fx    IN  NS  outland.fx.movie.edu.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

While we are on the topic of MX records, let's talk about how they can result in mail taking a longer path than necessary. The MX records are a list of data returned when the domain name of a mail destination is looked up. The list isn't ordered according to which exchanger is closest to the sender. Here is an example of this problem. Your non-Internet-connected network has two hosts that can relay Internet mail to your network. One host is in the United States, and one host is in France. Your network is in Greece. Most of your mail comes from the United States, so you have someone maintain your zone and install two wildcard MX records—the highest preference to the U.S. relay and a lower preference to the relay in France. Since the United States relay is at a higher preference, all mail will go through that relay (as long as it is reachable). If someone in France sends you a letter, it will travel across the Atlantic to the United States and back because there is nothing in the MX list to indicate that the French relay is closer to that sender.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Another recent development in networking (recent only relative to DNS's age) that presents a challenge to DNS is the dial-up Internet connection. When the Internet was young, and DNS was born, there was no such thing as a dial-up connection. With the enormous explosion in the Internet's popularity and the propagation of Internet service providers who offer dial-up Internet connectivity to the masses, a whole new breed of problems with name service has been introduced.

The basic goal when setting up DNS to work with dial-up is to enable every host in your network to resolve the domain names of every host it needs to access. (Of course, when your connection to the Internet is down, your hosts probably don't need to resolve Internet domain names.) If you're using dial-on-demand, there's the additional goal of minimizing unnecessary dialouts: if you're looking up the domain name of a host on your local network, that shouldn't require your router to bring up a connection to the Internet.

We'll separate dial-up connections into two categories: manual dial-up, by which we mean a connection to the Internet that must be brought up by a user, and dial-on-demand, which implies the use of a device—often a router, but sometimes just a host running Linux or another server operating system—to connect to the Internet automatically whenever hosts generate traffic bound for the Internet. We'll also describe two scenarios for each category of dial-up: one in which you have just one host dialing up a connection to the Internet, and one in which you have a small network of hosts dialing up a connection. Before we talk about these scenarios, though, let's discuss what causes dialouts and how to avoid them.

Many users, particularly in Europe, where ISDN is popular, connect to the Internet via dial-on-demand connections. Nearly all of these users want to minimize, if not completely prevent, unnecessary connections to the Internet. Connection setup is often more expensive than successive minutes, and always takes time.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The original DNS specifications didn't provide the ability to look up a network name based on a network number—a feature that was provided by the original HOSTS.TXT file. Since then, RFC 1101 has defined a system for storing network names; this system also works for subnets and subnet masks, so it goes significantly beyond HOSTS.TXT. Moreover, it doesn't require any modification to the nameserver software at all; it's based entirely on the clever use of PTR and A records.

Remember that to map an IP address to a name in DNS, you reverse the IP address, append in-addr.arpa, and look up PTR records. This same technique maps a network number to a network name—for example, to map network 15/8 to "HP Internet." To look up the network number, include the network bits and pad them with trailing zeros to make four bytes, and look up PTR data just as you did with a host's IP address. For example, to find the network name for the old ARPAnet, network 10/8, look up PTR data for 0.0.0.10.in-addr.arpa. You get back an answer like ARPAnet.ARPA.

If the ARPAnet is subnetted, you'll also find an address record at 0.0.0.10.in-addr.arpa. The address would be the subnet mask, 255.255.0.0, for instance. If you were interested in the subnet name instead of the network name, you apply the mask to the IP address and look up the subnet number.

This technique allows you to map the network number to a name. To provide a complete solution, there must be a way to map a network name to its network number. This, again, is accomplished with PTR records. The network name has PTR data that points to the network number (reversed with in-addr.arpa appended).

Let's see what the data might look like in HP's zone datafiles (the HP Internet has network number 15/8) and step through mapping a network number to a network name.

Partial contents of the file db.hp.com:


;

; Map HP's network name to 15.0.0.0.

;

hp-net.hp.com.            IN  PTR 0.0.0.15.in-addr.arpa.

Partial contents of the file

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There are a number of resource records that we haven't covered yet in this book. Some of these are experimental, but some are on the standards track and are coming into more prevalent use. We'll describe them here to give you a little head start in getting used to them.

AFSDB has a syntax like that of the MX record, and semantics a bit like that of the NS record. An AFSDB record gives either the location of an AFS cell database server or of a DCE cell's authenticated nameserver. The type of server the record points to and the name of the host running the server are contained in the record-specific data portion of the record.

So what's an AFS cell database server? Or AFS, for that matter? AFS originally stood for the Andrew File System, designed by the good folks at Carnegie-Mellon University as part of the Andrew Project. (It's now an IBM product.) AFS is a network filesystem, like NFS, but one that handles the latency of wide area networks much better than NFS does and provides local caching of files to enhance performance. An AFS cell database server runs the process responsible for tracking the location of filesets (groups of files) on various AFS fileservers within a cell (a logical group of hosts). So being able to find the AFS cell database server is the key to finding any file in the cell.

And what's an authenticated nameserver? It holds location information about all sorts of services available within a DCE cell. A DCE cell? That's a logical group of hosts that share services offered by The Open Group's Distributed Computing Environment (DCE).

And now, back to our story. To access another cell's AFS or DCE services across a network, you must first find out where that cell's cell database servers or authenticated nameservers are—hence the new record type. The domain name the record is attached to gives the name of the cell the server knows about. Cells often share names with DNS domains, so this usually doesn't look at all odd.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

ENUM, which stands for Telephone Number Mapping, is a new application of DNS; its overall function is to use DNS to map E.164 numbers to URIs. These URIs might identify a particular VoIP user, an email address, a fax machine, or many other possibilities.

You're probably already familiar with E.164 numbers, though perhaps not by that name. The E.164 recommendation from the International Telecommunication Union, or ITU, specifies the format of world telephone numbers. These formats begin with a country code (such as "1," which actually identifies not a particular country but the North American Dialing Plan, which includes the United States, Canada, and parts of Mexico and the Caribbean), then usually an area code or a city code. The format of the rest of the number is defined locally.

Phone numbers may be written with various forms of punctuation separating the country code and other fields. In the United States, for example, we often write the area code in parentheses, as in (408) 555-1234. Other common formats use dashes, periods, parentheses, or some combination of these. A plus sign ("+") is frequently used before a country code to help identify it.

Mapping an E.164 number to a URI makes it possible, for example, for a caller to reach a VoIP user even though he doesn't know and can't dial the URI that identifies the VoIP user. As long as the caller knows an E.164 number that maps to the correct URI, his phone (or, more likely, some software or device acting on behalf of his phone) can determine the destination URI and make the call. ENUM also allows users of different VoIP networks to communicate without resorting to using the public switched telephone network. And ENUM promises to become a kind of unified directory of methods for communicating with people. Under a single E.164 number, you can list URIs that allow people to contact you via phone, email, fax, and instant messaging, for example.

ENUM uses DNS to map E.164 numbers to URIs, and DNS uses domain names to index data, so we need to write the phone number in a canonical format and translate it into a domain name before looking it up. This requires the following steps:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One shortcoming in the original design of DNS that has become painfully obvious over the years is the character set supported in domain names. While DNS purists may tell you that labels in domain names can contain any binary value, US-ASCII characters are really the only values that are useful and supported by all DNS implementations. As the Internet has expanded internationally, this has meant that companies in countries in which European languages aren't widely spoken have been forced to use ASCII characters for their domain names. Even Europeans have had to transcribe their non-ASCII characters into ASCII; most Germans, for example, reflexively write ä and ö as ae and oe, respectively.

RFC 3490 introduced a method for encoding international characters in the labels of domain names. Because simply inserting non-ASCII characters into domain names doesn't work, most DNS software interprets multibyte characters as a sequence of ASCII characters, for example; these international characters are encoded into ASCII. The resulting ASCII-compatible encoding, or ACE, is basically unintelligible to ordinary humans in the same way that base-64 encodings are. To help distinguish an ACE-encoded label in a domain name from a normal but particularly cryptic ASCII label, ACE encodings include a specific prefix, "xn--," which is now forbidden to appear in a normal, ASCII label. Domain names with one or more labels encoded in ACE are referred to as internationalized domain names, or IDNs.

Rather than trying to accommodate the multitude of language- and script-specific character sets that computers support, RFC 3490 encodes only a single character set, called Unicode, into ASCII. But what a character set it is! Unicode contains tens of thousands of characters from the world's scripts. In almost all cases, it's possible to transform a string typed in a script-specific character set (say ISO Latin-1) into a Unicode equivalent.

The burden of encoding Unicode into ACE is placed on applications, not on resolvers or nameservers. If a web browser allows a user to type

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In our first edition—oh, for those simpler days!—we mentioned the close alignment between NetBIOS names and domain names, but noted that, alas, there was no way for DNS to function as a NetBIOS nameserver. Basically, a nameserver would need to support dynamic updates to function as a NetBIOS nameserver.

Of course, BIND 8 and 9 do support dynamic updates. Unfortunately, neither NetBIOS clients nor WINS servers send dynamic updates to nameservers. WINS servers accept only the peculiar, proprietary dynamic updates sent by NetBIOS clients. In other words, a WINS server doesn't speak DNS.

However, Microsoft provides a nameserver, the Microsoft DNS Server, which in turn can talk to WINS servers. The Microsoft DNS Server has a nice graphical administration tool, as you would expect from Microsoft, and provides a handy hook into WINS: you can configure the server to query a WINS server for address data if it doesn't find the data in a DNS zone.

This is done by adding a new WINS record to the zone. The WINS record, like the SOA record, is attached to the zone's domain name. It acts as a flag to tell the Microsoft DNS Server to query a WINS server if it doesn't find an address for the name it's looking up. The record:


@        0       IN     WINS            192.249.249.39 192.253.253.39

tells the Microsoft DNS Server to query the WINS servers running at 192.249.249.39 and 192.253.253.39 (in that order) for the name. The zero TTL is a precaution against the record being looked up and cached.

There's also a companion WINS-R record that allows a Microsoft DNS Server to reverse-map IP addresses using a NetBIOS NBSTAT request. If an in-addr.arpa zone contains a WINS-R record such as:


@        0      IN      WINS-R          movie.edu

and the IP address sought doesn't appear in the zone, the nameserver attempts to send a NetBIOS NBSTAT request to the IP address being reverse-mapped. This amounts to calling a phone number and asking the person on the other end, "What's your name?" The nameserver then appends a dot and the domain name in the record-specific data, in this case ".movie.edu," to the result.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Modern Windows operating systems —by which we mean Windows 2000, Windows XP, and Windows Server 2003—can use standard dynamic updates to register hosts in DNS. For a modern Windows client, registration means adding a name-to-address mapping and an address-to-name mapping for that client—information Windows clients formerly registered with WINS servers. For a Windows server, registration involves adding records to a zone to tell clients which services it's running and where (on which host and port). For example, an Active Directory Domain Controller uses dynamic update to add SRV records that tell Windows clients which services it's running.

So what gets added when a client registers? Let's reboot a Windows client in the Special Effects Lab and see.

Our client is called mummy.fx.movie.edu. It has the fixed IP address 192.253.254.13 (it doesn't get its address from our DHCP server). At boot time, the dynamic update routines on the client go through the following steps:

Look up the SOA record for mummy.fx.movie.edu on the local nameserver. Though there isn't an SOA record for that domain name, the authority section of the response includes the SOA record of the zone that contains mummy.fx.movie.edu, which is fx.movie.edu.
Look up the address of the nameserver in the MNAME field of the SOA record, bladerunner.fx.movie.edu.
Send a dynamic update to bladerunner.fx.movie.edu with two prerequisites: that mummy.fx.movie.edu isn't an alias (i.e., doesn't own a CNAME record) and that it doesn't already have an address record pointing to 192.253.254.13. The dynamic update contains no update section; it's just a probe to see what's out there.
If mummy.fx.movie.edu already points to the correct address, stop. Otherwise, send another dynamic update to bladerunner.fx.movie.edu

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This appendix outlines the format of DNS messages and enumerates all the resource record types. The resource records are shown in their textual format, as you would specify them in a zone datafile, and in their binary format, as they appear in DNS messages. You'll find a few resource records here that weren't covered earlier because they are experimental or obsolete.

We've included the portions of RFC 1035, written by Paul Mockapetris, that deal with the textual format of master files (what we called zone data files in the book) or with the DNS message format (for those of you who need to parse DNS packets).

Section A.1: Master File Format

Section A.2: DNS Messages

Section A.3: Resource Record Data

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

(From RFC 1035, pages 33–35)

The format of these files is a sequence of entries. Entries are predominantly line-oriented, though parentheses can be used to continue a list of items across a line boundary, and text literals can contain CRLF within the text. Any combination of tabs and spaces acts as a delimiter between the separate items that make up an entry. The end of any line in the master file can end with a comment. The comment starts with a semicolon (;).

The following entries are defined:


blank[comment]



$ORIGIN domain-name [comment]



$INCLUDE file-name [domain-name] [comment]



domain-namerr [comment]



blankrr [comment]

Blank lines, with or without comments, are allowed anywhere in the file.

Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is followed by a domain name and resets the current origin for relative domain names to the stated name. $INCLUDE inserts the named file into the current file and may optionally specify a domain name that sets the relative domain name origin for the included file. $INCLUDE may also have a comment. Note that an $INCLUDE entry never changes the relative origin of the parent file, regardless of changes to the relative origin made within the included file.

The last two forms represent RRs. If an entry for an RR begins with a blank, the RR is assumed to be owned by the last stated owner. If an RR entry begins with a domain-name, the owner name is reset.

rr contents take one of the following forms:


[TTL] [class] type RDATA

[class] [TTL] type RDATA

The RR begins with optional TTL and class fields, followed by a type and RDATA field appropriate to the type and class. Class and type use the standard mnemonics; TTL is a decimal integer. Omitted class and TTL values default to the last explicitly stated values. Since type and class mnemonics are disjoint, the parse is unique.

domain-names make up a large share of the data in the master file. The labels in the domain name are expressed as character strings and separated by dots. Quoting conventions allow arbitrary characters to be stored in domain names. Domain names that end in a dot are called absolute, and are taken as complete. Domain names that do not end in a dot are called relative; the actual domain name is the concatenation of the relative part with an origin specified in an $ORIGIN, $INCLUDE, or argument to the master file-loading routine. A relative name is an error when no origin is available.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In order to write programs that parse DNS messages, you need to understand the message format. DNS queries and responses are most often contained within UDP datagrams. Each message is fully contained within a UDP datagram. If the query and response are sent over TCP, they are prefixed with a two-byte value indicating the length of the query or response, excluding the two-byte length. The following sections detail the format and content of the DNS message.

(From RFC 1035, page 25)

All communications inside the domain protocol are carried in a single format called a message. The top-level format of the message is divided into five sections (some may be empty in certain cases), shown here:


+---------------------+

|        Header       |

+---------------------+

|       Question      | the question for the name server

+---------------------+

|        Answer       | RRs answering the question

+---------------------+

|      Authority      | RRs pointing toward an authority

+---------------------+

|      Additional     | RRs holding additional information

+---------------------+

The header section is always present. The header includes fields that specify which remaining sections are present and specifies whether the message is a query or a response, a standard query or some other opcode, etc.

The names of the sections after the header are derived from their use in standard queries. The question section contains fields that describe a question to a nameserver. These fields are a query type (QTYPE), a query class (QCLASS), and a query domain name (QNAME). The last three sections have the same format: a possibly empty list of concatenated resource records (RRs). The answer section contains RRs that answer the question, the authority section contains RRs that point toward an authoritative nameserver, and the additional records section contains RRs that relate to the query but are not strictly answers for the question.

(From RFC 1035, pages 26–28)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In addition to two- and four-octet integer values, resource record data can contain domain names or character strings.

Section A.3.1.1: Character string

(From RFC 1035, page 13)

A character string is a single length octet followed by that number of characters. A character string is treated as binary information, and can be up to 256 characters in length (including the length octet).

Section A.3.1.2: Domain name

(From RFC 1035, page 10)

Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one-octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of 0. The high order two bits of every length octet must be 0, and the remaining 6 bits of the length field limit the label to 63 octets or less.

Section A.3.1.3: Message compression

(From RFC 1035, page 30)

In order to reduce the size of messages, the domain system uses a compression scheme that eliminates the repetition of domain names in a message. In this scheme, an entire domain name or a list of labels at the end of a domain name is replaced with a pointer to a prior occurrence of the same name.

The pointer takes the form of a two-octet sequence:


+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| 1  1|                OFFSET                   |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The first two bits are ones. This allows a pointer to be distinguished from a label, since the label must begin with 2 zero bits because labels are restricted to 63 octets or less. (The 10 and 01 combinations are reserved for future use.) The OFFSET field specifies an offset from the start of the message (i.e., the first octet of the ID field in the domain header). A zero offset specifies the first byte of the ID field, etc.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Table B-1 shows you which versions of BIND support various features.

Table B-1: BIND compatibility matrix
Feature	BIND version
	8.2.3	8.4.7	9.1.0	9.3.2
Multiprocessor support			✗	✗
Dynamic update	✗	✗	✗	✗
TSIG-signed dynamic update	✗	✗	✗	✗
TSIG-based update policy			✗	✗
NOTIFY	✗	✗	✗	✗
Incremental zone transfer	✗	✗	✗	✗
Incremental zone transfers with manual zone editing				✗
Forwarding	✗	✗	✗

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The versions of BIND shipped with most versions of Linux are fairly recent. Still, BIND 8.4.7 is the most current BIND release (at the time of this writing), and the ISC recommends that you upgrade to BIND 9. For those of you who can't wait until your version of Linux updates to the latest version of BIND 8 or 9, this appendix will show you how to do it yourself.

Section C.1: Instructions for BIND 8

Section C.2: Instructions for BIND 9

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Compiling and installing the latest version of BIND 8 is easy. (Because the path to BIND 8 includes following the link bind-8, you will always get the latest version.) The following sections provide detailed instructions.

First, you must get the source code. There's a copy on ftp.isc.org, available for anonymous FTP:


% cd /tmp

% ftp ftp.isc.org.

Connected to isrv4.pa.vix.com.

220 ProFTPD 1.2.0 Server (ISC FTP Server) [ftp.isc.org]

Name (ftp.isc.org.:user): ftp

331 Anonymous login ok, send your complete e-mail address as password.

Password:

230 Anonymous access granted, restrictions apply.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp>

Now you need to find the right file:


ftp > cd /isc/bind/src/cur/bind-8

250 CWD command successful.

ftp > binary

200 Type set to I.

ftp > get bind-src.tar.gz

local: bind-src.tar.gz remote: bind-src.tar.gz

200 PORT command successful.

150 Opening BINARY mode data connection for bind-src.tar.gz (1600504 bytes).

226 Transfer complete.

1600504 bytes received in 23 seconds (56 Kbytes/s)

ftp > quit

221 Goodbye.

Now you have the compressed tar file that contains the BIND source. Just use the tar command to uncompress and untar it:


% tar -zxvf bind-src.tar.gz

(This assumes you have a version of tar that can handle compressed gzip'ed files; if you don't, you can get a new copy of tar via anonymous FTP from ftp.gnu.org in /gnu/tar/tar-1.15.tar.) This creates a src directory with several subdirectories, including bin, include, lib, and port. Here are the contents of these subdirectories:

bin: Source code for all BIND binaries, including named.
include: Copies of include files referenced by the BIND code. You should use these to build your nameserver instead of using those shipped with your system because they have been updated.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Here's how to compile and install BIND 9 on your Linux host. (At the time of this writing, 9.3.2 is the latest version.)

As with BIND 8, you must get the source code first. And again, this requires FTP'ing to ftp.isc.org:


% cd /tmp

% ftp ftp.isc.org.

Connected to isrv4.pa.vix.com.

220 ProFTPD 1.2.1 Server (ISC FTP Server) [ftp.isc.org]

Name (ftp.isc.org.:user): ftp

331 Anonymous login ok, send your complete email address as your password.

Password:

230 Anonymous access granted, restrictions apply.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp>

Change to the right directory and get the file you need:


ftp> cd /isc/bind9

250 CWD command successful.

At this point, you should check to see what is the latest version available by doing a dir command. At the time of this writing, 9.3.2 is the latest version.


ftp> cd 9.3.2

250 CWD command successful.

ftp> get bind-9.3.2.tar.gz

local: bind-9.3.2.tar.gz remote: bind-9.3.2.tar.gz

200 PORT command successful.

150 Opening BINARY mode data connection for bind-9.3.2.tar.gz (4673603 bytes).

226 Transfer complete.

4673603 bytes received in 92.4 secs (35 Kbytes/sec)

ftp> quit

221 Goodbye.

Use the tar command to uncompress and untar the compressed tar file:


% tar zxvf bind-9.3.2.tar.gz

Unlike the BIND 8 distribution, this creates a bind-9.3.2 subdirectory in your working directory for all the BIND source code. (BIND 8 distributions always unpacked everything into the working directory.) The bind-9.3.2 subdirectory will have subdirectories called:

bin: Source code for all BIND binaries, including named
contrib: Contributed tools

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This table lists all the two-letter country codes and all the top-level domains that aren't countries. Not all the countries are registered in the Internet's namespace at the time of this writing, but there aren't many missing.

Domain	Country or organization
AC	Ascension Island
AD	Andorra
AE	United Arab Emirates
AERO	Aeronautical Industry
AF	Afghanistan
AG	Antigua and Barbuda
AI	Anguilla
AL	Albania
AM	Armenia
AN	Netherlands Antilles
AO	Angola
AQ	Antarctica
AR	Argentina
ARPA	ARPA Internet
AS	American Samoa
AT	Austria
AU	Australia
AW

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Section E.1: BIND Nameserver Boot File Directives and Configuration File Statements

Section E.2: BIND 8 Configuration File Statements

Section E.3: BIND 9 Configuration File Statements

Section E.4: BIND Resolver Statements

Section E.5: BIND 9 Options Statement

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Here's a handy list of all the boot file directives and configuration file statements for the BIND nameserver, as well as configuration directives for the BIND resolver. Some of the directives and statements exist only in later versions, so your nameserver may not support them yet. Most of this information is based on the named.conf manual page, so you can check your manual page if your version of BIND is a newer than 8.4.7or 9.3.2.

The options statement has become quite extensive. At the end of this appendix, we have included the description of each configuration option from the BIND 9 Administrator Reference Manual, in case you don't have easy access to the manual page. For BIND 8, this information is on the named.conf manual page.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Section E.2.1.1: acl

Function

Creates a named IP address matching list, for access control and other uses.

Syntax


acl name {

   address_match_list;

};

Covered in Chapters 10 and 11.

Section E.2.1.2: controls (8.2+)

Function

Configures a channel used by ndc to control the nameserver.

Syntax


controls {

   [ inet ( ip_addr | * ) port ip_port allow address_match_list; ]

   [ unix path_name perm number owner number group number; ]

};

Covered in Chapter 7.

Section E.2.1.3: include

Function

Inserts the specified file at the point the include statement is encountered.

Syntax


include path_name;

Covered in Chapter 7.

Section E.2.1.4: key (8.2+)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

C style: /* */
C++ style: // to end of line
Unix style: # to end of line

Section E.3.1.1: acl

Function

Creates a named IP address matching list, for access control and other uses.

Syntax


acl string { address_match_element; ... };

Covered in Chapters 10 and 11.

Section E.3.1.2: controls

Function

Configures a channel used by rndc to control the nameserver.

Syntax


controls {

  inet ( ipv4_address | ipv6_address | * )

       [ port ( integer | * ) ]

       allow { address_match_element; ... }

       [ keys { string; ... } ];

  unix unsupported; // not implemented

};

Covered in Chapter 7.

Section E.3.1.3: include

Function: Inserts the specified file at the point where the include statement is encountered.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The following statements are for the resolver configuration file, /etc/resolv.conf.

Section E.4.1.1: ; and #

Function

Adds a comment to the resolver configuration file.

Syntax


; free-format-comment

or:

# free-format-comment

Example


# Added parent domain to search list for compatibility with 4.8.3

Covered in Chapter 6.

Section E.4.1.2: domain

Function

Defines your resolver's local domain name.

Syntax


domain domain-name

Example


domain corp.hp.com

Covered in Chapter 6.

Section E.4.1.3: nameserver

Function: Tells your resolver to query a particular nameserver.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Remember that statement that had way too many choices for you to consider?


options {

  avoid-v4-udp-ports { port; ... };

  avoid-v6-udp-ports { port; ... };

  blackhole { address_match_element; ... };

   ...

}

This section explains each choice.

This text came from the BIND 9 Administrator Reference Manual (created by Nominum). If you are running BIND 8, look for similar information in the named.conf manual page.

The options statement sets up global options to be used by BIND. This statement may appear only once in a configuration file. If there is no options statement, an options block with each option set to its default is used.

directory: The working directory of the server. Any nonabsolute pathnames in the configuration file will be taken as relative to this directory. The default location for most server output files (e.g., named.run) is this directory. If a directory is not specified, the working directory defaults to ., the directory from which the server was started. The directory specified should be an absolute path.
key-directory: When performing dynamic update of secure zones, the directory where the public- and private-key files should be found, if different than the current working directory. The directory specified must be an absolute path.
named-xfer: This option is obsolete. It was used in BIND 8 to specify the pathname to the named-xfer program. In BIND 9, no separate named-xfer program is needed; its functionality is built into the nameserver.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.