DNS on Windows Server 2003

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The White Rabbit put on his spectacles. "Where shall I begin, please your Majesty?" he asked. "Begin at the beginning," the King said, very gravely, "and go on till you come to the end: then stop."

—

It's important to know a little ARPAnet history to understand the Domain Name System (DNS). 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 U.S. 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the late 1960s, the U.S. Department of Defense's Advanced Research Projects Agency, ARPA (later DARPA), began funding the ARPAnet , an experimental wide area computer network that connected important research organizations in the U.S. 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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 is really just a TCP/IP-based "little i" 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 ftped to SRI-NIC and grabbed the current

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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 name servers constitute the server half of DNS's client/server mechanism. Name servers 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 name server.

The structure of the DNS database, shown in Figure 1-1, is similar to the structure of the Windows 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 Temp. 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 Windows filesystem, the root is written as a backslash (\ ).

Figure 1-1: The DNS database versus a Windows 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" or "folder" in the Windows 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The first implementation of the Domain Name System was called JEEVES, written by Paul Mockapetris himself. A later implementation was BIND, an acronym for Berkeley Internet Name Domain, written by Kevin Dunlap for BSD 4.3 Unix. BIND is now maintained by the Internet Software Consortium.

Although the Microsoft DNS Server can read BIND's configuration and datafiles, it is not BIND. Microsoft wrote its server from scratch, according to the DNS specifications. The first version of the Microsoft DNS Server was a beta version that ran on Windows NT 3.51. Microsoft made it available for some time from one of its FTP servers. The first product version of the DNS Server was shipped with Microsoft Windows NT Server 4.0 (but not with NT Workstation 4.0). The DNS server shipped with Windows 2000 Server and Windows Server 2003 comes from the same code base as the Windows NT DNS server—it's really just a later version.

There are other name servers that run on Windows. For example, the Internet Software Consortium distributes free ports of BIND, including 9.2.2 (the latest released version as of this writing), which run on Windows NT, Windows 2000, and Windows Server 2003 (see ftp://ftp.isc.org/isc/bind/contrib/).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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 name servers outweighs the benefits. On the other hand, there are circumstances in which you have no other choice but to set up and manage name servers. Here are some guidelines to help you make that decision.

. . . 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 got only 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 they'll host your zone for you, too. Even if you aren't already a customer, there are companies who will help out, for a price.

If you have a little more than a handful of hosts, or a lot more, you'll probably want your own zone. And if you want direct control over your zone and your name servers, you'll want to manage it yourself. Read on!

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

If your internet is basically homogeneous and your hosts don't need DNS (say they don't run TCP/IP at all), you may be able to do without it. But if you've got a variety of hosts, especially if some of those run some variety of Unix, you'll want DNS. It'll simplify the distribution of host information and rid you of any kludgy host-table distribution schemes you may have cooked up.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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

—

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

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

In this chapter, we'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 Windows filesystem. The tree has a single root at the top. In the Windows filesystem, this is called the root directory and is represented by a backslash (\ ). DNS simply calls it "the root." Like a filesystem, DNS's tree can branch any number of ways at each intersection point, or node. The depth of the tree is limited to 127 levels (a limit you're not likely to reach).

Figure 2-1: The structure of the DNS namespace

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

DNS's distributed database is indexed by domain names. Each domain name is essentially just a path in a large inverted tree, called the domain namespace. The tree's hierarchical structure, shown in Figure 2-1, is similar to the structure of the Windows filesystem. The tree has a single root at the top. In the Windows filesystem, this is called the root directory and is represented by a backslash (\ ). 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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, as 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 (nsf.gov).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Remember that one of the main goals of the design of the Domain Name System was to decentralize administration? This is achieved through delegation. Delegating domains 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 of those subdomains can be delegated to other organizations. This means that an organization becomes responsible for maintaining all the data in that subdomain. It can freely change the data and even divide 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 (see Figure 2-7).

Figure 2-7: stanford.edu is delegated to Stanford University

Not all organizations delegate away their whole domain, just as not all managers delegate all their work. A domain may have several delegated subdomains and also contain hosts that don't belong in the subdomains. For example, the Acme Corporation (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 U.S. would fit better under acme.com than under either subdomain.

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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

The difference between a zone and a domain is important, but subtle. All top-level domains and many domains at the second level and lower, such as berkeley.edu and hp.com, are broken into smaller, more manageable units by delegation. These units are called zones. The edu domain, shown in Figure 2-8, is divided into many zones, including the berkeley.edu zone, the purdue.edu zone, and the nwu.edu zone. At the top of the domain, there's also an edu zone. It's natural that the folks who run edu would break up the edu domain: otherwise, they'd have to manage the berkeley.edu subdomain themselves. It makes much more sense to delegate berkeley.edu to Berkeley. What's left for the folks who run edu? The edu zone, which 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 of these subdomains is delegated to a set of name servers, some of which are also authoritative for berkeley.edu. However, the zones are still separate and may have totally different groups of authoritative name servers.

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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

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

In Windows Server 2003, the resolver is a set of library routines, linked into programs such as telnet and ftp, and a system service called the DNS Client, which is responsible for caching records that applications have requested. The resolver relies almost entirely upon the name servers 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 name server. 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, such as follow referrals to locate the name servers authoritative for a particular zone.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Name servers 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 name server needs only the domain names and addresses of the root name servers to find its way to any point in the tree. A name server can issue a query to a root name server for any domain name in the domain namespace, and the root name server will start the name server on its way.

The root name servers know where the authoritative name servers for each of the top-level zones are. (In fact, some of the root name servers are authoritative for some of the generic top-level zones.) Given a query about any domain name, the root name servers can at least provide the names and addresses of the name servers that are authoritative for the top-level zone the domain name ends in. In turn, the top-level name servers can provide the list of authoritative name servers for the second-level zone that the domain name ends in. Each name server queried either gives the querier information about how to get "closer" to the answer it's seeking or provides the answer itself.

The root name servers are clearly important to resolution. Because they're so important, DNS provides mechanisms—such as caching, which we'll discuss a little later—to help offload the root name servers. But in the absence of other information, resolution has to start at the root name servers. This makes the root name servers crucial to the operation of DNS; if all the Internet root name servers were unreachable for an extended period, all resolution on the Internet would fail. To protect against this, the Internet has 13 root name servers (as of this writing) spread across different parts of the network. One is on PSINet, a commercial Internet backbone; one is on the NASA Science Internet; two are in Europe; and one is in Japan.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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

A name server processing a recursive query may have to send out quite a few queries to find an answer. However, it discovers a lot of information about the domain namespace as it does so. Each time it's referred to another list of name servers, it learns that those name servers are authoritative for some zone, and it learns the addresses of those servers. 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 Microsoft DNS Server even implements negative caching: if a name server responds to a query with an answer that says the domain name or data type in the query doesn't exist, the local name server will also temporarily cache that information.

Name servers cache all this data to help speed up successive queries. The next time a resolver queries the name server for data about a domain name the name server knows something about, the process is shortened quite a bit. The name server may have cached the answer, positive or negative, in which case it simply returns the answer to the resolver. Even if it doesn't have the answer cached, it may have learned the identities of the name servers that are authoritative for the zone the domain name is in and be able to query them directly.

For example, say our name server has already looked up the address of eecs.berkeley.edu. In the process, it cached the names and addresses of the eecs.berkeley.edu and berkeley.edu name servers (plus eecs.berkeley.edu's IP address). Now if a resolver were to query our name server for the address of baobab.cs.berkeley.edu, our name server could skip querying the root name servers. Recognizing that

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

"What do you call yourself?" the Fawn said at last. Such a soft sweet voice it had!

"I wish I knew!" thought poor Alice. She answered, rather sadly, "Nothing, just now."

"Think again," it said: "that won't do."

Alice thought, but nothing came of it. "Please, would you tell me what you call yourself?" she said timidly. "I think that might help a little."

"I'll tell you, if you come a little further on," the Fawn said. "I can't remember here."

—

Now that you understand the theory behind the Domain Name System, we can attend to more practical matters. Before you set up your zones, you may need to get name server software. While a name server is included as a standard part of Windows Server 2003, you may want to look at alternatives. Once you've got the software to run your name server, you need to decide on a domain name for your main zone—which 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 how to decide on name server software and where to get it.

If you plan to set up your own zones and run name servers for them, you'll need name server software first. Even if you're planning on having someone else run the name servers for your zones, it's helpful to have the software around. For example, you can use a local name server to test your zone datafiles before giving them to your remote name server administrator.

Microsoft ships a name server on the Windows Server 2003 CD-ROM, but you have to install it separately from the OS. This server, which we call the Microsoft DNS Server, is the server we cover in this book. It's notable because it sports a nice graphical front-end for configuring the server. This isn't the only name server available for Windows Server 2003, however. There are several others. Many are ports of BIND, which has traditionally been a Unix-based name server. If you're more comfortable configuring BIND than learning to configure a new name server (even with a GUI), you might consider running the latest version of BIND (9.2.2 as of this writing) on Windows Server 2003.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you plan to set up your own zones and run name servers for them, you'll need name server software first. Even if you're planning on having someone else run the name servers for your zones, it's helpful to have the software around. For example, you can use a local name server to test your zone datafiles before giving them to your remote name server administrator.

Microsoft ships a name server on the Windows Server 2003 CD-ROM, but you have to install it separately from the OS. This server, which we call the Microsoft DNS Server, is the server we cover in this book. It's notable because it sports a nice graphical front-end for configuring the server. This isn't the only name server available for Windows Server 2003, however. There are several others. Many are ports of BIND, which has traditionally been a Unix-based name server. If you're more comfortable configuring BIND than learning to configure a new name server (even with a GUI), you might consider running the latest version of BIND (9.2.2 as of this writing) on Windows Server 2003.

BIND 9.2.2 compiles on Windows Server 2003 without any modification of the source code. However, since many people lack the software necessary to compile it, the Internet Software Consortium distributes a compiled version from its web site at http://www.isc.org/products/BIND/bind9.html.

If you decide to run BIND on Windows Server 2003, we suggest you pick up a copy of DNS and BIND. That book concentrates on the BIND implementation; this book emphasizes the Microsoft DNS Server.

If you've read to this section, we'll assume you've decided to use the Microsoft DNS Server. Before proceeding, you'll need to install the name server and its configuration front-end from the Windows Server 2003 CD-ROM. For detailed instructions on this process, see Chapter 4.

Now that you've installed your name server, it's important to keep abreast of DNS and name server developments. Three Usenet newsgroups are helpful for this:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Choosing a domain name is more involved than it may sound because it entails both choosing a name and finding out who runs the parent zone. In other words, you need to find out where you fit in the Internet domain 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 name servers (as in our previous ftp.microsoft.com 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 the registry, providing registration and value-added services. It submits to the registry the zone data and other data (including contact information) for each of its customers in a single top-level domain.

Registration is the process by which a customer tells a registrar which name servers to delegate a subdomain to and provides the registrar with contact and billing information. The registrar makes these changes through the registry.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

"It seems very pretty," she said when she had finished it, "but it's rather hard to understand!" (You see she didn't like to confess, even to herself, that she couldn't make it out at all.) "Somehow it seems to fill my head with ideas—only I don't exactly know what they are!"

—

If you have been diligently reading each chapter of this book, you're probably anxious to get a name server running. This chapter is for you. Let's set up a couple of name servers. Some 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 who cuts corners, be aware that we may use concepts from earlier chapters and expect you to understand them.

Several factors influence how you should set up your name servers. The biggest factor is what sort of access you have to the Internet: complete access (for example, you can ftp to ftp.uu.net), limited access (limited by a security firewall), or no access at all. This chapter assumes you have complete access. We'll discuss the other cases in Chapter 16.

In this chapter, we'll set up two name servers for a fictitious domain as an example for you to follow in setting up your own domain. We'll cover the topics in this chapter in enough detail for you to get your first two name servers running. Subsequent chapters will fill in the holes and go into greater depth. If you already have your name servers running, skim through this chapter to familiarize yourself with the terms we use or just to verify that you didn't miss something when you set up your servers.

Our fictitious zone serves a college. Movie University studies all aspects of the film industry and researches novel ways to distribute films. One of our most promising projects is research into using IP as a 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 for another network or two. The Ethernets have network addresses 192.249.249/24 and 192.253.253/24. A portion of our host table contains the following entries:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Our fictitious zone serves a college. Movie University studies all aspects of the film industry and researches novel ways to distribute films. One of our most promising projects is research into using IP as a 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 for another network or two. The Ethernets have network addresses 192.249.249/24 and 192.253.253/24. A portion of our host table contains the following entries:

127.0.0.1      localhost 

# These are our killer machines. 

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

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

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

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

192.249.249.1  wormhole.movie.edu wormhole wh wh249 
192.253.253.1  wormhole.movie.edu wormhole wh wh253

The network is pictured in Figure 4-1.

Figure 4-1: The Movie University network

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Our plan for the Movie U. network is to run name servers on two hosts: terminator and wormhole. But a fresh installation of Windows Server 2003 doesn't include the DNS server by default, so we need to install it on these hosts.

Start by selecting Start → Manage Your Server. This brings up the administrator's one-stop-shopping application, Manage Your Server, as shown in Figure 4-2.

Figure 4-2: Manage Your Server

Choose Add or remove a role. The next window is titled Preliminary Steps and we don't show it, but it just admonishes you to have the computer connected to the network and any peripherals and to have your installation media handy. After clicking Next on this screen, you might (or might not) see the Configuration Options screen, which gives you the option to install several common services all at once or pick and choose a custom configuration. We don't show this screen either, but choose Custom configuration and click Next.

Now you're presented with the Server Role window, shown in Figure 4-3. Select DNS server as shown in the figure and click Next.

Figure 4-3: The Server Role window

The resulting window, Summary of Selections, describes the actions about to be taken. Click Next to install the DNS server and do some preliminary configuration. After the installation from the media completes, the Configure Your Server Wizard starts the Configure a DNS Server Wizard, which is shown in Figure 4-4.

Figure 4-4: Configure a DNS Server Wizard

If you want to, at this point you can review the checklists, but since we're walking you through this process, select Next and you'll see the Select Configuration Action

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To manage a Microsoft DNS Server and maintain your DNS data, you'll use a tool called the DNS console, a snap-in for the Microsoft Management Console (MMC). MMC is a general-purpose program that hosts administrative tools. Introduced in Windows 2000, MMC replaced the "one-off" administrative tools found in Windows NT 4.0, such as DNS Manager, WINS Manager, DHCP Manager, and the like. The DNS console has a graphical user interface and is capable of managing multiple name servers. The DNS console is located on the Administrative Tools menu, provided you've already installed the DNS Server. The DNS console communicates with the Microsoft DNS Server using a proprietary management protocol built on Microsoft's RPC (remote procedure call) mechanism. That means the DNS console is able to manage only Microsoft DNS Servers and not other name servers, such as BIND.

The main DNS console window looks like Figure 4-6 (or will look like it, after we've set everything up in the course of this chapter).

Figure 4-6: The DNS console main window

The left pane is called the console tree. It shows name servers, zones, and domains. The right pane shows either informational messages or resource records.

This particular DNS console knows about only one name server, terminator. That name server is authoritative for three zones: movie.edu, 249.249.192.in-addr.arpa, and 253.253.192.in-addr.arpa. The DNS console segregates forward-lookup zones (which hold primarily address records) and reverse-lookup zones (which hold primarily pointer records). If any of these zones had subdomains, they would show up as subfolders under the appropriate zone. For example, comedies.movie.edu would be represented as a folder called comedies under movie.edu.

Let's take a look at the menus at the top of the window. The File, Window, and Help menus control the MMC application itself and, to be honest, they're not that interesting. The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Let's configure the first of Movie U.'s name servers. We'll use the DNS console for most of this process, so start it up if you haven't already done so. You don't have to run the DNS console on the machine running the name server, but for now it's easier if you do. You'll also need to have Administrator privileges to use the DNS console; otherwise, you'll only be able to start the application, not manage any name servers with it.

The first step is configuring the DNS console to manage the primary master name server for your zone. The primary master for a zone—also called just the primary—stores information about the zone on its disk. You make all changes to your zone on the primary master.

Select Action → Connect To DNS Server and specify where the name server you want to manage—the primary master—is running. As you can see in Figure 4-9, you can choose either the local machine or specify a name server running somewhere else. If the name server isn't local, enter its name or IP address. Leave the box checked, which causes the DNS console to immediately contact the server to obtain its status and a list of any zones it might already be authoritative for.

Figure 4-9: Specifying the location of a name server to manage

The DNS console adds an icon in the left pane for that name server, as in Figure 4-10.

Figure 4-10: The DNS console with a new server

It's important to understand what we just did here. We told the DNS console about a name server for it to manage and it added that name server to its configuration. The DNS console did not start the name server on the target machine. If the name server isn't already installed and running, the DNS console can't manage it and will complain with the message, "The server is unavailable. Would you like to add it anyway?"

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Your primary name server is already up and running; you've been talking to it via the DNS console. You've created a zone and populated it with information. You directed the server to write out zone datafiles with the Action → Update Server Data Files command. In the interest of completeness, next we'll show you how to stop and restart the server and then check the Event Log for any messages or errors.

You can start and stop the DNS server in several ways. First, you can control it just like any other Windows Server 2003 service: with the Services MMC snap-in. Select Start → Administrative Tools → Services. You'll see a window like Figure 4-27.

Figure 4-27: Windows Server 2003 services control window

Your system should look like this: the server should be running (that is, it should be started). Select the server as we've done by clicking anywhere on the DNS Server line. Select Action → Stop. After the server stops, select Action → Start. In a few seconds, the server should be running again. You can also use the handy links in the upper left of the right pane to stop and start the service.

While you've got this window open, check to make sure that the DNS server is being started automatically when the system is booted. You want to see Automatic in the Startup Type column (and not Manual or Disabled). To change the startup behavior, double-click on the service and choose the appropriate behavior in the Startup Type field of the resulting window.

You can also start and stop the DNS server from within the DNS console. With the server selected in the left pane, select Action →

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to set up another name server for robustness. You can (and probably will) set up more than two name servers. Two servers are the minimum. If you have only one name server and it goes down, no one can look up names in your zone. A second name server splits the load with the first server or handles the whole load if the first server is down. You could set up another primary master name server, but we don't recommend it. Set up a secondary name server instead.

How does a server know if it is a primary master or a secondary for a zone? The DNS server configuration information in the Registry tells the server it is a primary master or a secondary on a per zone basis. The NS records don't tell us which server is the primary master for a zone and which servers are secondaries for a zone—they only say who the servers are. (Globally, DNS doesn't care; as far as the actual name resolution goes, secondary servers are as good as primary master servers.)

What is different between a primary master name server and a secondary name server? The crucial difference is where the server gets its data. A primary master name server reads its data from files. A secondary name server loads its data over the network from another name server. This process is called a zone transfer.

A secondary name server is not limited to loading zones from a primary master name server; a secondary can load from another secondary. The big advantage of secondary name servers is that you maintain only one set of zone datafiles: the ones on the primary master name server. You don't have to worry about synchronizing the files among name servers; the secondaries do that for you.

A secondary name server doesn't need to retrieve all of its datafiles over the network; the cache.dns file is the same as on a primary master, so you'll need a local copy on the secondary. Fortunately, the DNS server installation process includes this file.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·

Table of Contents