Home > Articles > Operating Systems, Server > Microsoft Servers

The Domain Name System

In this sample chapter, author Drew Heywood turns new DNS administrators into DNS masters by exploring the essentials of the Domain Name System. Learn how DNS domains work, and how servers cooperate to implement a large-scale DNS name service. Catch a glimpse of general DNS configuration issues, and discuss how DNS integrates with Active Directory. Finally, learn how to implement DNS in an environment that contains non–Windows 2000 DNS servers.
This chapter is excerpted from Drew Heywood's Windows 2000 Network Services.
In This Chapter
  • 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.


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.


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:   loopback  blythe   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.


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.


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.


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.


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




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:


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.


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.


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.


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






Maps a domain name to an IP address


Canonical Name

Maps an alias to a host domain name


Mail Exchanger

Identifies a mail server for a domain


Name Server

Identifies a name server for a domain



Matches an IP address to a host domain name (the reverse of an A RR)


Start of Authority

Identifies the domain administrative contact and configures several operational parameters


Service Location

Provides the location of a service

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

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020