The Domain Name System

• DNS Architecture

• Deploying DNS Servers

• Managing DNS in a Small Domain

• Configuring Reverse Lookup Zones to Support Classless IP Addresses

• Importing and Exporting BIND Databases

• Integrating DNS Zones with Active Directory

• Using NSLOOKUP

• Now, You're the DNS Master

Even if you have never administered a Domain Name System (DNS) server, you are familiar with the way DNS enables you to use names to identify hosts on the Internet. DNS is simply a hierarchical database that can be used to store a variety of different kinds of information, such as hostnames and the names of mail servers. A new DNS record type introduced by Microsoft, the Service record, stores information about the locations of services. With the Service record type, Windows 2000 can use DNS for naming and service location, enabling a pure Windows 2000 network configured with Active Directory to operate independently of NetBIOS names.

If you have managed earlier Microsoft network operating systems, you know all too well the drawbacks of NetBIOS names. They are particularly problematic on TCP/IP networks because NetBIOS devices request information about services by sending broadcast messages, and broadcast messages aren't permitted to cross TCP/IP routers. To enable NetBIOS naming to work over TCP/IP, Microsoft devised the NetBIOS Name System, more familiar by the name of WINS, the Windows Internet Name System. WINS is used with Windows NT to support NetBIOS naming over routers. WINS works (usually), but, despite being documented as an Internet standard (RFC 1001/1002), the NetBIOS Name System remains a technology that is principally supported by Microsoft. DNS, on the other hand, is a universally accepted technology. The use of DNS as the name and service database is one of the most significant new features of Windows 2000.

Given the way Active Directory gets involved with almost every aspect of Windows 2000, it should come as no surprise that Microsoft has added some Active Directory twists to the Windows 2000 DNS service. Active Directory uses Dynamic DNS (DDNS) to store hostname records in DNS and also to update Service records in the DNS database. In turn, Microsoft has enabled the Windows 2000 DNS service to use Active Directory as its database store. Active Directory remains an optional feature of Windows 2000. You can configure Windows 2000 Servers and clients to support NetBIOS naming. But even if you don't activate Active Directory, you will probably find yourself configuring a DNS service to enable your clients to use DNS domain names to identify TCP/IP hosts.

That raises concern in many data centers because they already have a DNS service in operation, probably a UNIX system running the Berkeley Internet Name Domain (BIND) DNS implementation, which provides nearly all the DNS services on the Internet. Although I have not tested it, Microsoft states that BIND versions 8.1.2 and later have the features required to support Active Directory. If you are integrating Active Directory into a network with an existing DNS service, you will need to determine whether you will migrate to the Windows 2000 DNS service, run Active Directory with a foreign DNS service, or run both the foreign DNS service and Windows 2000 DNS. The advantages, disadvantages, and practices for each approach will be discussed later in the chapter.

---

Note

It's worth quoting Microsoft's statement about Windows 2000 DNS compatibility:

"Windows 2000 DNS is RFC-compliant and interoperates with other DNS implementations. It has been tested to work with Windows NT 4.0, BIND 8.2, BIND 8.1.2, and BIND 4.9.7. However, Windows 2000 supports some features that other implementations of DNS do not support."

I mention one of those feature distinctions later in the chapter. Windows 2000 DNS servers permit names to include Unicode characters that are not allowed by the RFCs. You must, of course, avoid these features in environments that have mixed types of DNS servers.

I haven't encountered any tests that independently investigate DNS service interoperability issues, so you should mix DNS services with caution. Certainly, if you deploy Active Directory, all your DNS servers must support the required features. If you base your DNS services on BIND 8.1.2 or later, I suggest that you make your own tests before you deploy Active Directory on a large scale.

---

But first, for new DNS administrators, I need to go over some DNS essentials. You need to know how DNS domains work, and how servers cooperate to implement a large-scale DNS name service. After looking at general DNS configuration issues, we'll see how DNS integrates with Active Directory. Finally, we'll see how to implement DNS in an environment that contains non–Windows 2000 DNS servers.

---

Note

Before DNS, hostname resolution was performed using static HOSTS files that were stored on the local host. A HOSTS file is simply a text file in which each line maps a single IP address to one or more hostnames. A HOSTS file contains entries like the following:

127.0.0.1   loopback
10.1.1.122  blythe
10.1.0.50   drew drew.pseudo-corp.com

A single entry can define one or more aliases, which are separated by spaces.

On UNIX hosts, the HOSTS file is stored in a special directory named /etc. On Windows NT and 2000, the standard directory for HOSTS and other TCP/IP configuration files is %systemroot%\system32\drivers\etc.

HOSTS files work, but aren't of much value on a changing network. Because Active Directory dynamically modifies the name database, HOSTS files have little or no value on Windows 2000 networks. The same can be said for LMHOSTS files, static database files that provided a method of matching NetBIOS names to IP addresses before the introduction of the NetBIOS Name System.

---

DNS Architecture

DNS maintains a database that is often called a namespace, because its primary use is to store records about hostnames. The database is structured as a hierarchy of containers called domains. Each domain can store two sorts of information:

• The names of additional domains that fall at the next lower layer in the hierarchy, along with the information required to access information in those domains

• Various types of data, such as hostnames, that are stored in resource records

The Domain Hierarchy

Because domains can contain other domains, we can construct a hierarchy of domains. A domain that contains a subdomain is called a parent domain, and the subdomain is called a child domain. Figure 3.1 illustrates a small part of the domain name hierarchy that is found on the Internet. Like every hierarchy, the entire database originates from a single domain, typically placed at the top when the hierarchy is drawn. This "top" domain is the only domain that doesn't have a name. It is known as the root domain.

---

Note

It is worth stating up front that DNS domains and Windows domains are not the same thing. Both function as containers, but DNS domains are simply containers for data in a database. Windows domains establish administrative and security boundaries for Windows services and objects.

DNS and Windows domain concepts get a bit confused with Windows 2000 because an Active Directory Windows domain is always represented by a domain in a DNS database where the naming and service data for an Active Directory domain are stored. Thus there will always be a hierarchy of DNS domains that corresponds to the hierarchy of Active Directory domains.

---

I won't go into great detail about the organization of the Internet name space except to introduce a bit of terminology. The Internet root domain contains quite a few first-level domains such as the familiar COM, NET, EDU, ORG, and GOV domains, shown in Figure 3.1. Additionally, there is a first-level domain for each country, such as US for the United States or IT for Italy. It is up to each country to determine how its national domain will be structured.

Figure 3.1 A portion of the Internet namespace.

---

Note

You can learn more about the generic and country-code top-level domains at http://www.iana.org/domain-names.html and in RFC 1591.

---

---

Note

The COM domain particularly is getting so crowded that it is becoming difficult to reserve a new domain name that isn't either obscure or awkward to type. To capitalize on this shortage, many small countries have begun to sell space in their national domains. My favorite is the small country of Tuvalu, which owns the first-level domain name TV. Practically everyone in the TV business wants a place in that domain, so the registrars for the TV domain have been able to charge above-market rates to register domains. As other first-level domain names begin to catch on, it won't be a "Dot.COM" world for much longer.

---

Below the first-level domains are second-, third-, and fourth-level domains that are often referred to as subdomains. The RFCs do not specify a limit to the number of levels of subdomains that can be defined, but all DNS server implementations set some sort of limit. You don't want names to grow too long, however, and five or six levels seems to be a practical limit, at least for information that is accessed by users. In practice, you will seldom see domains that are deeper than the fourth level.

---

Note

If you don't want to be tied in to the Internet domain namespace, you can configure your DNS servers so that you have a private root domain. As we'll see in the next chapter, a private root domain might actually be the preferred way to set things up if you are running Active Directory.

---

Domain Names

A host's complete domain name is constructed by concatenating its hostname to the name of every domain between it and the root, separating the names with periods. This produces names in the familiar domain name form such as

http://www.pseudo-corp.com

or

ftp.ietf.org

In the first example, the name identifies a host named www that is in the pseudo-corp subdomain of the com top-level domain. Expressed in this way, the complete name of a domain is called a fully qualified domain name, usually referred to as an FQDN.

I deliberately placed the above names on separate lines so that punctuation wouldn't get in the way. Remember that there is a root domain at the top of the DNS name hierarchy. Where is the root domain in the previously mentioned names? The answer is that the root domain is implicit. Technically, because the root domain name is indicated with a period, it should be specified by adding a period to the end of the name like this:

http://www.pseudo-corp.com.

But that is almost never done in practice, and the root domain is usually implicit. You will see the trailing period in some DNS files, however, where it is used to indicate clearly that the name is a FQDN that starts at the root domain.

---

Note

The RFCs limit the length of an FQDN to 255 characters, although you will seldom if ever want to define domain names this long. Although the RFCs don't limit the number of domain levels that can be defined, the FQDN length limitation ensures that any mad desire to keep adding levels to the domain hierarchy must eventually be curbed.

Domain name requirements are standardized in RFCs 952 and 1123. Domain names can contain only characters a–z, 0–9, and the hyphen character (-). Names can be up to 63 characters in length. Periods can appear only as separators between domain names that appear in a relative or fully qualified domain name.

The Windows 2000 DNS service optionally permits DNS names to contain other ASCII characters as well, such as Unicode characters. Be aware that these extended domain names are not supported by all DNS servers. See the section "Advanced Properties" later in this chapter for the procedure used to specify the characters that the DNS service will accept in domain names.

---

Making DNS Queries

A single DNS server could not possibly handle naming for the entire Internet. Two problems would arise if we tried to centralize naming: Demand would quickly outstrip any possible amount of processing power, and a huge, centralized bureaucracy would be required to keep current with changes. The designers of DNS realized that these problems could only be prevented if the database was distributed. Consequently, the Internet uses a great many computers, each running DNS-compliant name servers, each administered independently, and each responsible for but a small part of the entire Internet namespace.

A given name server can store the database for one domain or for many related or unrelated domains. Your ISP, for example, almost certainly hosts the domains of many of its clients, which share the same set of DNS servers. A DNS server that stores the records for a domain is said to be authoritative for that domain.

---

Note

A DNS name server manages the data for one or more zones, where a zone stores the DNS database for one or more domains. Thus it is common to refer to a DNS database as a zone database.

---

The most important function of a DNS server is to look up the IP address that matches a particular host's domain name. The process of looking up the IP address that corresponds to a domain name is called resolving a name query. Because no single DNS server has a copy of the entire Internet namespace, resolution of most name queries typically requires the involvement of two or more DNS servers.

Figure 3.2 illustrates the process of a typical query. In this case, the user on host lauren.pseudo-corp.com wants to connect to http://www.microsoft.com. Her name query would be answered something like this:

1. Her computer first sends queries to the name server that is listed in its TCP/IP configuration. This name server must provide one of the following responses:

   • Return the IP address of the host that is specified in the query, or

   • Return a message stating that no records can be found for the hostname specified

2. The local name server cannot resolve names in the Microsoft.com domain, so it must search for a name server that is authoritative for the target domain. When starting from scratch, a DNS server usually starts at the top of the domain hierarchy by querying a name server that is authoritative for the root domain.

3. The Internet root domain servers are authoritative for the root and com domains, but they are not authoritative for the microsoft.com domain. The root domain server responds with a referral to the IP address of a name server that is authoritative for microsoft.com.

4. The local name server queries the name server it learned about from the root domain servers.

5. This name server is authoritative for microsoft.com and can resolve http://www.microsoft.com to its IP address. This IP address is returned to the local name server.

6. The local name server returns the results of the query to the user's computer, completing the query.

There are several opportunities to shorten this process because name servers retain copies of searches they have recently conducted in a local cache. Suppose that the local name server has recently resolved http://www.microsoft.com for another user. It can resolve the query locally without the need to search outside name servers. On busy name servers, the local name cache results in significant improvements in resource usage. Caching is such a powerful technique for reducing WAN traffic that many organizations deploy cache-only name servers, also known as forwarders, a technique that is described later in the chapter.

Iterative and Recursive Queries

There are two types of DNS queries: iterative and recursive, both of which figure into the search process depicted in Figure 3.2. You will need to have some familiarity with these types of queries when you configure the DNS server.

Figure 3.2 Resolving a name query for a remote domain.

Client software must be able to initiate a DNS query because it must know the IP address of a target host in order to instruct the Host-to-Host layer on the destination of a message. But it would be wasteful to build all the intelligence required to conduct a DNS search into each application. Typically, the developer of an application wants to generate a query that says to a DNS server, "Here's the name. It's your responsibility to succeed or fail in a name search. Let me know when you're done."

That type of query is called a recursive query. A DNS server that receives a recursive query must do one of two things:

• Resolve the name, consulting other DNS servers if necessary, or

• Report that the name cannot be resolved

In other words, a DNS server that receives a recursive query can't respond, "I don't know the answer, but you might try looking over there."

In theory, if your local name server can't resolve one of your recursive queries, it could send a recursive query to a root name server, requiring it to resolve the query or report failure. The root name server could then send a recursive query to a DNS server in microsoft.com. The DNS server in microsoft.com would send the result to the root name server, which would send the result to your local name server, which would finally send the result to you. Clearly, your local name server would get a break because it has to do a lot less work. But the root name servers would bear considerably more responsibility because they would have to keep track of every outstanding query and where it came from so that they could pass the response back to the correct name server. Chaining recursive queries to recursive queries saves work for the local name server but increases the burden on remote name servers that become involved in the query.

It is more common, therefore, for name servers to send iterative queries to other name servers. A DNS server can respond to an iterative query in several ways:

• It can provide the desired result.

• It can provide the IP address of another name server that is closer to the domain containing the requested information.

• It can report that, although it is authoritative for the target domain, it cannot find the requested information.

After a DNS server has provided any of these responses, it is done with an iterative query. Iterative queries make responding easier for the root name servers, but they require the local name server to be more intelligent about conducting its search. It must keep track of each unresolved query as it queries domains that successively enable it to locate and query name servers for the target domain.

Root Name Servers

Because most name searches start at the root of the namespace, it should come as no surprise that the Internet root name servers are very, very busy. Currently, 13 root name servers in various locations support the Internet root domain. The names and IP addresses of the root name servers are entered into the DNS server's configuration by an administrator (or, in the case of the Windows 2000 Server, by the software that installs and configures the DNS service). Microsoft calls these pointers to the root name servers root name server hints.

---

Note

Delegation is the capability whereby the manager of a parent domain can permit a child domain to be managed by a different organization or hosted by another DNS server.

---

OK, we've found name servers that support the root of the DNS naming tree. How do we search down to find a name server for microsoft.com? When a subdomain is configured, the parent domain is configured with hints that enable it to point to name servers in its child domains. Now it so happens that the Internet root name servers also service the com subdomain, so they can get us that far. Within the com subdomain are hints that point to name servers for the microsoft.com subdomain.

If your organization has a domain on the Internet, there must be at least one name server that is authoritative for the domain. (Although you must declare at least two name servers when you register a domain.) If you have two or more name servers, each will have a copy of the zone database so that queries can be resolved when one of the name servers is down. When you register a domain, the authority that completes your registration ensures that the parent domain for your domain is configured with the records that identify the name servers for your subdomain. After that, it is your responsibility to maintain the database within your subdomain.

In summary, name resolution on the Internet depends on the following characteristics of DNS:

• The root domain is managed centrally by Internet authorities.

• Some Internet top-level domains (com, org, and net) are hosted on the root domain name servers. Management of other top-level domains has been delegated to the entity responsible for the domain.

• Authority for second- and lower-level domains is delegated to the organization that registers the domain. That organization must ensure that suitable name servers are configured to support the domain.

• DNS servers are capable of accepting referrals to other DNS servers, enabling them to search for name servers that are authoritative for a target domain. Consequently, the search process is transparent to the user and to the user's software.

Many organizations, particularly small ones, let their ISPs host and manage their domains, eliminating the need to maintain two local name servers and to learn how to manage a DNS service. Most ISPs provide name services using BIND running over UNIX. Although BIND version 8.1.2 has the features required to support Active Directory, I would question whether it is a good idea to outsource DNS support when DNS is so crucial to Active Directory. If the WAN link fails, Active Directory would be unable to contact its requisite name servers and could not function. Fortunately, the Windows 2000 DNS service isn't all that difficult to manage, so it's not that big a deal to keep the service in house.

Resource Records

The primary purpose of DNS is to provide a database that matches hostnames to IP addresses, but DNS supplies other information as well. For example, DNS can be used to determine the addresses of mail servers that support a domain. The information in the DNS database is stored in the form of resource records (RRs). Each RR has a name and an abbreviation. Only a few types of RRs are essential to our purposes in this book. These are summarized in Table 3.1. We will discuss how these RRs are configured later in the chapter.

Table 3.1  Common Resource Records and Their Functions

We will look at these resource records more closely later in the chapter when we discuss how to manage zones and resource records.