Getting Started With Microsoft DNS Server

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By John Jacobs

At A Glance:

Tech Level: Intermediate.

Audience: Novice and experienced administrators.

Section

What's There

DNS Overview

Novices should read this for a description of key concepts and explanation of important terms; more experienced admins can skip it.

Windows NT Deployment Steps

Outlines and explains in table form the major steps in a typical Windows NT DNS deployment. A good high-level view of the process.

Specialized Deployment Examples

Describes three deployments that require modified steps: intranet with controlled access to the Internet, adding to an existing DNS system, and Internet Service Provider (two examples).

More Information

Pointers to other references, especially to more in-depth documents on the Web and the TechNet CD, and advice for finding additional articles.

ABSTRACT: The Domain Name System (DNS) is an important Internet standard for finding a computer's IP address, given its host name. The Windows NT Server 4.0 DNS service implements the DNS standards, and provides a useful management utility. This article supplements the product's documentation, summarizing DNS concepts for novice administrators, and detailing the management utility's use for experienced administrators.

Introduction

Referencing a computer on a network has always involved a trade-off between efficiency and usability. For example, TCP/IP software identifies computers using numbers, but people want to give computers names, which are easier to remember than strings of numbers. The Domain Name System (DNS) is the de facto standard solution on TCP/IP networks, and Microsoft has developed DNS software for Windows NT Server 4.0. The DNS service makes Windows NT Server attractive to companies of all sizes, but deploying it can require some training: many administrators have experience with DNS, or Windows NT, but not both.

This article is designed to help administrators learn about DNS in general and Microsoft's implementation in particular. The first section helps DNS novices by explaining what DNS is and how it works, the second shows how to deploy DNS in a typical environment, and the third presents specialized deployment examples. The article concludes with a More Information section with pointers to other references on the Web and on the TechNet CD.

DNS Overview

The Problem DNS Solves

Each computer on a TCP/IP network has a unique IP address written as four numbers separated by periods, such as 10.0.0.1. Software uses these IP addresses to direct information from one computer to another. IP addresses are hard to memorize and use, and most people would rather use computer names to identify and locate network machines.

The General Solution

The generalized solution has two parts:

  • A database—A way to match names to IP addresses; it may include querying and maintenance tools

    A naming convention—The convention used for identifying nearly all Internet resources, and most intranet resources, defines these parameters for "domain names:"

    • Legal characters include the hyphen, period, digits "0" though "9," and letters "A" through "Z" and "a" through "z."

    • Periods can separate a domain name into parts. In standard usage, parts of names correspond to logical categories and subcategories. When read right-to-left, the parts of a name describe the categorization from most general to most specific. For example, reading the parts of the domain name dev.microsoft.com:

      com—This name is in the set of domains controlled by commercial organizations, as opposed to domains controlled by educational organizations (edu), military organizations (mil), and so on

      microsoft—Owned by Microsoft

      dev—Owned by the development group at Microsoft

    • No part of a domain name can exceed 63 characters, and the entire name must not exceed 255 characters.

Two specific solutions, called HOSTS and DNS, have been developed within this general framework. DNS and HOSTS are not mutually exclusive, and they do not rely on each other, so client-side software may be designed to use DNS, or HOSTS, or DNS first and then HOSTS, or HOSTS first and then DNS. This allows the administrator to use the solution that best meets the organization's needs.

A Simple Implementation: HOSTS

Each client computer has a copy of a flat-file database stored in a text file called HOSTS; the lines of this file match IP addresses to domain names. For example, this line:

127.0.0.1   localhost

associates the name "localhost" with the IP address 127.0.0.1. Client software, such as the TCP/IP protocol, can be designed to look up a domain name in the HOSTS file to find the corresponding IP address.

There is no automatic administration of the clients' HOSTS files: administrators often update a master HOSTS file and rely on each end-user to copy it periodically to the client computer, at which point the administrator has little control of the file's contents. This solution is rarely the best choice if the network includes more than a few computers, especially if the network is connected to the Internet, because of the administrative overhead, lack of security, and reliance on end-users to keep the database files up-to-date.

A Sophisticated Implementation: DNS

DNS is a system of "name server" computers that store information about network resources, such as name-to-IP mappings, in database files. Name servers are organized in a hierarchy based on the parts of domain names. For example, name servers operated by the Internet Network Information Center (InterNIC) are responsible for the "top-level" domains (com, edu, mil, and so on), which means their databases store IP addresses for domain names such as "microsoft.com" and "mit.edu." These databases are said to be "authoritative" for the top-level domains, which means that they are the most reliable source of information about those domains. Other name servers hold databases that are authoritative for lower-level domains ("subdomains"). For example, a name server at Microsoft has authority over the microsoft.com domain, so its databases store information about resources, such as the Web server www.microsoft.com, and third-level domains, such as dev.microsoft.com.

DNS client-side software is called a resolver, because it resolves domain names to IP addresses. The client's TCP/IP protocol software is often the resolver. It typically resolves a domain name by sending a query to its designated name server. If that name server is authoritative for the domain of the requested name, the name server responds to the client with the IP address (or a list of them), or it responds that the name does not exist. If the client's name server is not authoritative for the requested domain, then that name server contacts other name servers on the client's behalf. It starts with the servers in charge of the "root" domain; on the Internet, these are the InterNIC's servers, which are authoritative for domains such as com, edu, mil, and so on. If the root server is authoritative for the requested name's domain, it responds with one or more IP addresses, or with a "not found" message; otherwise, it responds with the IP address of a second-level name server that might be authoritative.

For example, suppose a client's resolver wants the IP address of www.microsoft.com. The client's resolver asks its name server, which then asks an InterNIC name server, which is authoritative for the com domain. The InterNIC server responds, in effect, "I'm not the authority for names within the microsoft.com domain, but here's the IP address of the name server that is authoritative for that domain…" The client's name server then contacts the name server for microsoft.com, which is authoritative, and which responds with a valid IP address. The client's name server stores this IP address for a short time, so other clients that ask for the same information get it quickly.

DNS is a more flexible, more scalable solution than HOSTS, and it is the de facto standard of the Internet, and by extension, of intranets as well.

Beyond Theory: DNS Implementation Ideas and Terms

The description to this point has focused on the ideas on which DNS is based; the topics below move beyond theory to implementation details that administrators need to understand.

The most important aspect of the DNS is that it is a distributed database system; in other words, the database is broken up between multiple name servers. To illustrate why the database is distributed, consider the alternative: one name server with one database containing records for all of the uncounted millions of computers on the Internet. Many database programs can store this many records in one table, but doing so would cause enormous problems in five other areas. Here is a table showing the area affected, the problem caused by a single database, and its corresponding solution:

Problems and solutions related to database distribution

Area

Single-Database Problem

Distributed-Database Solution

Administration

Every organization in the world would need to need to send the InterNIC a database update request every time a computer were added to or removed from the Internet, and every time a domain name-IP address matching changed.

If an organization needs control of its resources, assign it a part of the name space, and let it maintain a name server whose database holds all the records for that part of the name space. Related term: zone.

Fault tolerance

If the server failed, computers across the planet would be unable to find each other.

Distribute copies of the database to multiple servers. Related terms: primary zone, secondary zone.

Query Efficiency

Achieving high efficiency for multiple types of queries in one table increases the complexity of the database software.

Create one table for each of several common types of queries, and store the tables on the same server. Related terms: forward lookup zone, reverse lookup zone.

Bandwidth

Every second, the server's network would need to carry millions of lookup requests to the server, and carry as many responses back to the clients.

Place a name server on the same network as the clients, and give that name server the database for the clients' most frequently requested domain names.

Processing

Every second, the server would need to perform millions of lookups.

Balance the processing among multiple computers.

This example involves the entire Internet, but the problems and solutions also apply on smaller scales: administrators often distribute records of an organization's intranet resources among several database files, and distribute those files among several servers.

Key concepts and terms related to database distribution

Domain and sub-domain—These terms refer to the organization of the name space, just as "directory" and "subdirectory" (or "folder" and "sub-folder") refer to the organization of a hard disk. For example, a two-part domain name, such as microsoft.com, is analogous to a second-level subdirectory, such as C:\winnt\system32.

Resource or host—An entity on the network (usually a computer); it resides in a domain just as a file resides in a directory. For example, Microsoft's Web server is a resource identified by the name www.microsoft.com.

Name space—The set of all domain names, and resource names, that have been registered. Together, the distributed parts of the DNS database document the entire name space.

Authority—Each of the distributed parts of the DNS database documents a subset of the name space (some set of domain names and resource names). Each database file is the authority for the part of the name space that it documents. For example, the files on the InterNIC servers are the authorities for domains such as com, edu, mil, and so on: their databases document all registered names of the form something.com, something.edu, something.mil, and so on.

Zone—This term has two related meanings:

  • A DNS database file: "The com zone is stored on the hard disks of the InterNIC name servers."

  • The portion of the name space documented in a zone file: "The InterNIC name servers can resolve any name that is part of the com zone."

A company's sub-domains can be divided into zones in various ways, as illustrated in these hypothetical examples:

  • One zone—A single microsoft.com zone is the authority for every resource in the microsoft.com domain, and every resource in every sub-domain (dev.microsoft.com, sales.microsoft.com, and so on).

  • One zone per sub-domain—The microsoft.com zone is the authority for only the microsoft.com domain. Authority for each sub-domain, such as dev.microsoft.com and sales.microsoft.com, are delegated to zone files managed by the respective divisions.

  • Combination—One zone is the authority for microsoft.com and sales.microsoft.com, but authority for dev.microsoft.com is delegated to a zone maintained by the Development division.

Files for different zones are often located on different servers, usually to cut network traffic. However, this is not a requirement. For example, an administrator could divide an organization's name space into zones matching five divisions, and each of those divisions could sub-divide its namespace into subzones matching four departments, for a total of 26 zones (1 "root" zone, plus 5 division-level zones, plus 20 department-level zones). Each zone file might reside on its own name server, or all 26 might be stored on one name server, or various subsets of the zones could be stored on some other number of name servers.

Primary and Secondary Zones—A single zone file is not fault tolerant. Also, if clients at a branch office access the name server over a slow link, the queries and responses consume valuable bandwidth, and if your organization is billed by the volume of traffic over that link, a single zone file is expensive. The solution is to distribute copies of a zone file among several name servers. One file is designated the primary zone, and the others are secondary zones. Administrators make changes to the primary zone, and the changes replicate to the secondary zones; this replication is called a zone transfer.

A name server is not necessarily "primary" or "secondary": it might hold the primary zone for one portion of the organization's name space, and a secondary zone for another portion.

Forward and Reverse Zones—A client can use DNS is find the IP address associated with a given domain name. This is called a "forward lookup" and the zone file optimized for this operation is called a "forward lookup zone," or simply "forward zone." Users rarely need to look up a name associated with a given IP address, but many programs do this to enforce security or perform diagnostics. This is called a "reverse lookup," and a name server usually optimizes this type of search by keeping a "reverse lookup zone" or "reverse zone" that corresponds to each forward zone. Other types of zones exist, but these are the most important ones for name resolution.

Resource records—Each database contains multiple records, often of different types. For example, a forward zone contains one "A" resource record for every resource documented in the zone; each of these maps one domain name to one IP address. In a reverse zone, each of many "PTR" resource records maps an IP address to a domain name. All zones have an "SOA" record that identifies the name server on which the primary copy of the zone is kept. Only a few of the many resource record types are mentioned in this article; see More Information, below, for articles that describe all of the resource record types.

Vendor-specific terms

Administration tools—Most DNS implementations, including the Windows NT Server 4.0 implementation, provide a command-line utility, called nslookup, for viewing the contents of zone files. However, in most implementations, administrators change the records in each zone file using a text editor. Windows NT Server supplies a graphical utility, called DNS Manager, that eases database administration by presenting information in two, side-by-side panes, much like Windows NT Explorer. However, whereas most Explorer operations are performed by selecting menus or toolbar buttons, most DNS Manager operations are performed by clicking the mouse's right button to display a context-sensitive menu of options. The DNS technical support team at Microsoft reports that forgetting to right-click the mouse is a major source of DNS usability problems.

Berkeley Internet Name Domain (BIND)—A popular implementation of DNS, written for BSD UNIX.

Windows NT DNS Deployment Steps

This section outlines the steps to deploy Windows NT DNS at an organization that previously has not needed DNS servers, but needs them now to direct people to the Internet Web site and FTP site the organization is deploying. Many small companies outsource site hosting to an ISP, in which case this example explains what the ISP does to deploy a Windows NT DNS server.

DNS Deployment Steps

General Deployment Step

Detailed Instructions

1. Select a domain name, research it to ensure it is not already associated with another organization, and identify the IP address of the intended name servers.

See the InterNIC's Web site, https://rs.internic.net/rs-internic.html, for research assistance. You can find a Windows NT Server's IP address with the "ipconfig" command-line utility, or by running the Network application in Control Panel, selecting TCP/IP Protocol from the Protocols tab, and selecting Properties.

2. Install the DNS Service on a name server.

Run the Network application from the Control Panel, select Services, select Add, select Microsoft DNS Server, select OK, and reboot the server when prompted.

3. Create a primary, forward zone.

In the Server List, right-click the server icon for which you are creating a zone. Select New Zone, then Primary, and then Next. Type the Zone Name, and select the Zone File text box to accept the default zone file name, or type a different one.

4. Before adding resource records to the forward zone, create a primary, reverse zone.

The steps are the same as creating a primary zone, except for entering the zone name: you must type the network portion of your IP address, followed by "in-addr.arpa". For example, if the name server's IP address is 10.20.30.1, and the network portion of that IP address is the first three octets (10.20.30), the name of the zone file must be "30.20.10.in-addr.arpa".

5. Add records to the zone.

In the Server List, right-click the name server's entry, and select New Record. Select the type of record and enter the appropriate information, then select OK.
To each forward zone you must add, at minimum: one NS record and one A record for each other name server; one MS and one A record for each mail server (if any); and one A record for each resource server (Web server, FTP server, and so on). DNS Manager automatically creates the zone's required SOA record for you, and gives its fields the default values.
The data entry dialog for the A record also has a Create Associated PTR Record checkbox. Select this to automatically add the corresponding PTR record to the reverse zone.

6. Install the DNS Service on at least one other server and configure it as the secondary name server.

Install the DNS service on the intended secondary name server. On that server, start the DNS Manager utility, and from the Server List, select the intended secondary server, and right-click its entry. Select New Zone, then Secondary. Enter the zone name and the IP address of the primary DNS server.

7. Once the organization's primary and secondary zones are in place, register the domain name and name servers with the InterNIC.

See the InterNIC's Web site, https://rs.internic.net/rs-internic.html, for more information. Expect to provide the information you gathered in Step 1.

8. Install and configure the DNS Service on a sub-zone server if appropriate to minimize network traffic, or to allow a department to have control over its sub-domain.

Repeat Step 6 on each sub-zone server.

Specialized Deployment Examples

The preceding example addresses many organizations' needs. The following examples explain how to modify deployment steps for other, common scenarios.

Deployment for an Intranet With Controlled Access to the Internet

Organizations link their networks to the Internet in various ways that differ in the degree of security they need, and how they achieve that security. These security issues impact DNS configuration and deployment, and presenting the options is beyond the scope of this introductory article. You can find additional information in articles referenced below, in the More Information section.

Adding to an Existing DNS System

Many networks already have DNS systems supported by other servers, such as UNIX, and want to introduce Windows NT Server-based name servers, initially to maintain secondary zones. To do this, the administrator simply performs Step 6 from the main example above.

Internet Service Provider

In each of the previous examples, an organization uses DNS to support to its individual servers. An ISP is an example of an organization that may use DNS to support multiple organizations, multiple sites on each server, and multiple servers for each site. The examples below address these needs.

One name server for multiple companies

An ISP's computers often host Web and FTP sites for other companies, using domain names for those companies. For example, a client company might register the domain name company1.com, and the ISP's Web server computer might host a Web site called https://www.company1.com, as well as similar sites for other companies.

At first this might seem to be a special case not covered by the main example. Actually, this is much like a organization that divides its name space into zones that match each of several departments, and maintains those zone files on one name server. Instead of maintaining zones for sales.company1.com, marketing.company1.com, and support.company1.com, the ISP's name server maintains one zone for itself (isp.com) and one for each of the client companies (company1.com, company2.com, and so on).

For each new client company, the administrator performs all steps from the main example, except 2, 6, and 7.

Multiple computers for one resource

ISPs usually place the same content onto multiple servers in order to achieve fault tolerance and load balancing. Each server has at least one network adapter and at least one unique IP address. This would appear to be a problem for the name server: when asked to resolve a name, which of the servers' IP addresses should the name server return? The solution lies in the protocol for communicating with a name server: it states that if multiple IP addresses are associated with one name, then the name server should return a complete list of IP addresses. However, the specification does not state how the list should be ordered, and in practice, client-side resolver software almost always uses the first entry in the list. The solution is to change the order of the list after resolving each request. This "round robin" capability balances the load among the available servers, and provides fault tolerance.

Suppose the ISP starts by hosting all Web sites on one server. The administrator initially added this Web server, and its IP address, in an A record in Step 5 of the main example. Suppose the ISP contracts to host Web sites for three client companies. The administrator adds a new zone for each company by following all steps except 2, 6, and 7 from the main example. Each time the administrator performs Step 5, a new A record is added to the zone. The DNS Manager will show at least four zones (one for each of the four domains: isp.com, company1.com, company2.com, and company3.com).

Now the ISP decides to mirror the company2 Web site onto a second Web server computer, because this site receives a great deal of traffic. The administrator uses DNS Manager to add a new A record to the forward zone for the company2.com domain (Step 5 of the main example). One such record in that zone already associates the name www.company2.com with the IP address of the main Web server; the new A record associates the same name with the IP address of the mirror Web server.

Conclusion

At first, matching names to IP addresses may seem like a simple problem that deserves a simple solution. However, the problems are not simple, and the designers of DNS focused on making a solution possible more than on making it easy to learn and deploy. This article presents the basics of DNS and of Microsoft's Windows NT implementation, but it cannot cover all of the details, so the section below provides pointers to other articles that can help you learn the rest.

More Information

On TechNet

Search TechNet for "DNS" to find over 100 articles, such as:

  • Windows NT Server Domain Name Server

  • MS Windows NT 4.0 Upgrade Training, Lesson 6: Domain Name Server (DNS)

  • MS Windows NT Server 4.0 Resource Kit: Name Resolution Using WINS and DNS

Elsewhere

Microsoft's Web site, https://www.microsoft.com, has several important articles, including:

Windows NT Server Domain Name System (DNS) Server

https://www.microsoft.com/ntserver/dnstb.htm

DNS and Microsoft Windows NT 4.0

https://www.microsoft.com/msdn/sdk/techinfo/dnswp.doc

DNS Integration

https://www.microsoft.com/windows/common/contentntsice.htm

WINS/DNS Integration

https://www.microsoft.com/windows/common/contentntsiac05.htm

DNS Troubleshooter

https://www.microsoft.com/ntserversupport/content/nt4troubleshoot/dns/

Querying for "DNS" on any major Internet search site will find hundreds or thousands of documents, so narrow your query with other terms, such as "setup" or "administration." Reference lists on the World Wide Web include:

DNS Resources Directory

https://www.dns.net/dnsrd

DNS Background Materials: Suggested Reading

https://rs.internic.net/help/domain/dns.html.

Microsoft TechNet
January 1997
Volume 5, Issue 1