Chapter 9 - Managing MS DNS Servers

The Domain Name System (DNS) is a set of protocols and services for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. DNS enables you to use hierarchical "friendly" names to easily locate computers and other resources on a network. Microsoft DNS server is a new service in the family of TCP/IP networking services provided by Windows NT Server version 4.0. It enables you to provide and manage DNS services for your private TCP/IP networks and for users who connect to the public Internet. Microsoft DNS server is based on a client/server architecture that enables Microsoft DNS servers to maintain DNS name data and process DNS client name queries.

This chapter is for network administrators and support personnel who need to understand and administer DNS services. It includes the following topics:

Introduction to the Domain Name System

Microsoft DNS server

DNS server database

Primary and secondary DNS servers

Microsoft DNS clients

Planning for Microsoft DNS server implementation

Using Microsoft DNS server to connect to the Internet

Planning for Microsoft DNS and Microsoft WINS integration

Using DNS Manager

Adding DNS servers 

Creating zones

Adding and Modifying DNS resource records 

The zone transfer

Troubleshooting DNS server

Using the DNS diagnostic utility—Nslookup 

Refreshing DNS server statistics

Resolving slow DNS zone transfer 

Resolving zone wizard errors 

Porting data files from other DNS servers 

Introduction to Domain Name System

The Domain Name System (DNS) is used extensively on the Internet and in many private enterprises today. Computers running TCP/IP and connected to the Internet can have one or more IP addresses associated with each network adapter card in the computer. DNS is designed so that people do not have to remember IP addresses, but can instead use "friendly" names to locate and connect to remote computers and other network devices on TCP/IP networks. DNS is used on private TCP/IP-based intranets as well as the Internet.

Before the implementation of DNS, the use of names to locate resources on TCP/IP networks was supported by using a name resolution method based on files known as HOSTS files. Each HOSTS file contained a list of host (computer or other TCP/IP network device) names and their associated IP addresses. As the number of computers and users on the Internet grew, the HOSTS file method of name resolution became an unmanageable solution.

DNS is designed to replace the HOSTS file with a distributed database that implements a conceptual naming system. This naming system allows for growth on the Internet and the creation of host names that are unique throughout the Internet and private TCP/IP-based intranets.

The conceptual naming system on which DNS is based is a hierarchical and logical tree structure called the domain name space. The root (the top-most level) of the domain name space is managed by the Internet Network Information Center (InterNIC) (http://www.internic.net). InterNIC is responsible for delegating administrative responsibility for portions of the domain name space to organizations and enterprises that connect to the Internet.

These organizations and enterprises then employ DNS servers to manage the name-to-IP-address mappings for computers and network devices contained within their authoritative domain. The DNS servers that are used at the upper levels of the DNS hierarchy and at private domain nodes lower down in the DNS hierarchy are referred to as the authoritative name servers.

To understand how the conceptual domain name space is used to create unique names for computers on TCP/IP networks, you need to understand the top-down structure of DNS. The top level of the domain name space is managed by InterNIC and is divided into three main areas:

Organizational domains—these are named by using a 3- character code that indicates the primary function or activity of the enterprises contained within the domain. Most organizations and enterprises located in the United States are contained within one of these organizational domains, as shown in Table 9.1. 

Geographical domains—these are named by using the 2-character country codes established by ISO 3166. These codes are used primarily for international organization and enterprise domains.

Reverse domain—this is a special domain, named in-addr.arpa, that is used for IP-address-to-name mappings (referred to as reverse name lookup.) 

The most commonly used top-level DNS name components for organizations and institutions in the United States are described in the following table and in Figure 9.1.

Top-level name componentDescriptionExample domain name

.com

InterNIC assigns portions of the domain name space under this level to commercial organizations, such as the Microsoft Corporation.

microsoft.com

.edu

InterNIC assigns portions of this domain name space to educational organizations, such as the Massachusetts Institute of Technology.

mit.edu

.gov

InterNIC assigns portions of this domain name space to governmental organizations, such as the White House in Washington, D.C.

whitehouse.gov

.int

InterNIC assigns portions of this domain name space to international organizations, such as the North Atlantic Treaty Organization.

nato.int

.mil

InterNIC assigns portions of the domain name space to military operations, such as the Defense Date Network.

ddn.mil

.net

InterNIC assigns portions of the domain name space to networking organizations, such as the the National Science Foundation.

nsf.net

.org

InterNIC assigns portions of the domain name space to noncommercial organizations, such as the Center for Networked Information Discovery and Recovery.

cnidr.org

As mentioned earlier, InterNIC manages the assignment of domain names to organizations, private enterprises, and institutions. The organizations and enterprises to which InterNIC assigns a portion of the domain name space are then responsible for naming the computers and network devices within their assigned domain and its subdivisions.

The following figure illustrates the DNS naming conventions described in Table 9.1 by using a fictional domain named TerraFlora that contains a host (computer) named 'mfgserver'.

 

Figure 9.1 Domain Name System

A DNS-based name for the server in the TerraFlora domain is constructed as mfgserver.terraflora.com, which is the concatenation of the host name (mfgserver) with the domain name (terraflora) and the upper-level name (com) separated by the dot "." character at each point of concatenation. This name is referred to as the Fully Qualified Domain Name (FQDN). 

Note In general, domain names and host names have restrictions in their naming which only allow the use of characters a-z, A-Z, 0-9, and the dash or minus sign (-). The use of characters such the slash (/), period (.), and underscore (_) is not allowed by specification. However, Microsoft DNS server does allow the use of underscore (_) in a name. This is done to support BIND versions earlier than BIND version 4.94.

The preceding figure presents a simple view of a domain. In actuality, domains can contain both hosts (computers) and other domains (referred to as zones, sub-zones, or domains). Each organization assigned authority for a portion of the domain name space is responsible for administering, subdividing, and naming the zones, sub-zones, domains, and computers within the domain for which they are "authoritative" by InterNIC assignment.

Subdividing is an important concept in DNS. Creating subdivisions of the domain name space and private TCP/IP network domains supports new growth on the Internet and the ability to continually expand name and administrative groupings.

For example, the Terraflora domain could contain groups such as retail, manufacturing, and so on. A DNS administrator of the Terraflora domain could subdivide the domain to create host names that reflect these groupings. For example, Terraflora's Internet server could be named www.terraflora.com and their retail departmental server could be named ntserver.retail.terraflora.com, and so on.

Microsoft DNS Server

Microsoft DNS server running under Windows NT Server version 4.0 is an RFC-compliant DNS name server that you use to manage and administer DNS services on your TCP/IP network. Microsoft DNS server supports RFCs 1033, 1034, 1035, 1101, 1123, 1183, and 1536, and is also compatible with the Berkeley Internet Name Domain (BIND) implementation of DNS.

Note BIND is a popular implementation of DNS originally developed at Berkeley for the 4.3 BSD UNIX operating system.

Because Microsoft DNS server is an RFC-compliant DNS server, it creates and uses standard DNS database files and record types. These are referred to as resource record types. Microsoft DNS server is interoperable with other DNS servers and can be managed by using the standard DNS diagnostic utility, nslookup. (Nslookup is included with the TCP/IP utilities provided with Windows NT Server version 4.0.)

Microsoft DNS server also has features above and beyond those specified in the RFCs, such as tight integration with Microsoft Windows Internet Name Service (WINS) and ease-of-administration through the use of the graphical user interface, DNS Manager.

Integration of DNS and WINS services is an important feature that allows interoperability between non-Microsoft and Microsoft Windows-based TCP/IP network clients. DNS and WINS integration provides a method to reliably resolve name queries for Windows-based computers that use dynamic (DHCP-based) IP addressing and NetBIOS computer names.

The other important new feature of the Microsoft DNS server implementation is DNS Manager, a graphical user interface that you use to manage local and remote Microsoft DNS servers and database files.

Microsoft DNS server allows you to use a computer running under Windows NT Server version 4.0 to administer an entire domain or subdivisions of the domain referred to as zones, sub-zones and domains. These subdivisions are dependent on your enterprise requirements for name and administrative groupings of computers, integration of Windows NT-based domains into the DNS domain model, or your role as an Internet Service Provider (ISP) to other enterprises.

Note In existing TCP/IP networks that are administratively organized by using Windows NT-based domain concepts, it is recommended that you use, or realign, your Windows NT-based domains with the DNS domain and subdivisions you have or may create. For additional information, see the topic "Planning for Microsoft DNS and Microsoft WINS Integration" later in this chapter.

The main administrative grouping by which a computer running Microsoft DNS server manages DNS services is the zone. A zone is an administrative portion (in small enterprises it can be the entire portion) of a DNS domain, referred to as the zone's root domain. (This root domain is generally the domain for which your organization is authoritative.) You can install Microsoft DNS servers in the root domain, zone, and zone subdivisions of a TCP/IP network— wherever you need a DNS server to manage your DNS data and DNS name query traffic.

The following figure illustrates an example deployment of Microsoft DNS servers based on the domain and zone concepts.

 

Figure 9.2 DNS Zones 

A single Microsoft DNS server can be configured to manage one or multiple zones. You can also use multiple DNS servers to administer a zone and its subdivisions, as shown in the preceding figure. Dividing a domain into multiple zones can be done to distribute administrative tasks to different groups and to provide efficient data distribution by using the data replication method referred to as a zone transfer.

Microsoft DNS Server Database

The Microsoft DNS server database is a set of files that contain the host name –to-IP-address mappings and other DNS information data for the computers on your TCP/IP network. These data records are referred to as resource records and are contained in the zone, cache, reverse-lookup, and arpa-127 files in the \%systemroot%\Winnt\System32\Dns directory.

The following table describes the different types of resource records that may be used to provide DNS-based data about computers on a TCP/IP network.

Record typeDescription

A

An address record that maps a host name to an IP address in a DNS zone. Its counterpart, the PTR resource record, is used to map an IP address to a host name in a DNS reverse zone (those in the in-addr.arpa. DNS domain).

AFSDB

Gives the location of either an Andrew File System (AFS) cell database server, or a DCE (Distributed Computing Environment) cell's authenticated name server. The AFS system uses DNS to map a DNS domain name to the name of an AFS cell database server. The Open Software Foundation's DCE Naming service uses DNS for a similar function.

CNAME

The canonical name resource record creates an alias (synonymous name) for the specified host name. You can use CNAME records to hide the implementation details of your network from the clients that connect to it. For example, ftp.terraflora.com is an alias (CNAME) for the real name of the computer that runs the FTP server. This alias also allows the FTP server to be moved to a different computer; only the CNAME record needs to change.

HINFO

The host information resource record identifies a host's hardware type and operating system. The CPU Type and Operating System identifiers should come from the computer names and system names listed in RFC 1700.

ISDN

The Integrated Services Digital Network (ISDN) resource record is a variation of the A (address) resource record. Rather than mapping a host name to an IP address, the ISDN record maps the name to an ISDN address. An ISDN address is a phone number that consists of a country code, an area code or country code, a local phone number, and, optionally, a subaddress. The ISDN resource record is designed to be used in conjunction with the RT (route through) resource record.

MB

The mailbox resource record is an experimental record that specifies a DNS host with the specified mailbox. Other related experimental records are the MG (mail group) resource record, the MR (mailbox rename) resource record, and the MINFO (mailbox information) resource record.

MG

The mail group resource record is an experimental record that specifies a mailbox that is a member of the mail group (mailing list) specified by the DNS domain name. Other related experimental records are the MB (mailbox) resource record, the MR (mailbox rename) resource record, and the MINFO (mailbox information) resource record.

MINFO

The mailbox information resource record is an experimental record that specifies a mailbox that is responsible for the specified mailing list or mailbox. Other related experimental records are the MB (mailbox) resource record, the MG (mail group) resource record, and the MR (mailbox rename) resource record.

MR

The mailbox rename resource record is an experimental record that specifies a mailbox that is the proper rename of the other specified mailbox. Other related experimental records are the MB (mailbox) resource record, the MG (mail group) resource record, and the MINFO (mailbox information) resource record.

MX

The mail exchange resource record specifies a mail exchange server for a DNS domain name. A mail exchange server is a host that will either process or forward mail for the DNS domain name. Processing the mail means either delivering it to the addressee or passing it to a different type of mail transport. Forwarding the mail means sending it to its final destination server, sending it using Simple Message Transfer Protocol (SMTP) to another mail exchange server that is closer to the final destination, or queuing it for a specified amount of time.

NS

The name server resource record identifies the DNS server(s) for the DNS domain. NS resource records appear in all DNS zones and reverse zones (those in the in-addr.arpa DNS domain).

PTR

The pointer resource record maps an IP address to a host name in a DNS reverse zone (those in the in-addr.arpa DNS domain). Its counterpart, the A (address) resource record, is used to map a host name to an IP address in a DNS zone.

RP

The responsible person resource record indicates who is responsible for the specified DNS domain or host. You can specify multiple RP records for a given DNS domain or host. The record has two parts: an electronic mail address (in the same DNS format as the one in the SOA resource record), and a DNS domain name that points to additional information about the contact.

RT

The route through resource record specifies an intermediate host that routes packets to a destination host. The RT record is used in conjunction with the ISDN and X25 resource records. It is syntactically and semantically similar to the MX record type and is used in much the same way.

SOA

The start of authority resource record indicates that this DNS server is the authoritative source of information for the data within this DNS domain. It is the first record in each of the DNS database files. The SOA resource record is created automatically by DNS Manager when you create a new DNS zone.

TXT

The text resource record associates general textual information with an item in the DNS database. A typical use is for identifying a host's location (for example, Location: Building 26S, Room 2499). The text string must be less than 256 characters, but multiple TXT resource records are allowed.

WINS

A record that contains the IP address of the WINS server configured on the DNS Server for WINS name resolution. This record is automatically created when WINS lookup is enabled on the DNS server, and is not a record that can be manually created by using Add Record in DNS Manager.

WINS_R

This record instructs Microsoft DNS server to use a NetBIOS node adapter status (nbtstat) command to resolve a DNS client reverse-lookup query. The reverse-lookup query requests the name of a computer identified only by an IP address. This record is automatically created when WINS reverse lookup is enabled on the DNS server, and is not a record that can be manually created by using Add Record in DNS Manager.

WKS

The well-known service resource record describes the services provided by a particular protocol on a particular interface. The protocol is usually UDP or TCP, but can be any of the entries listed in the PROTOCOLS file (\%systemroot%\system32\drivers\etc\protocol). The services are the services below port number 256 from the SERVICES file (\%systemroot%\system32\drivers\etc\services).

X.25

The X.25 resource record is a variation of the A (address) resource record. Rather than mapping a host name to an IP address, the X.25 record maps the name to an X.121 address. X.121 is the International Standards Organization (ISO) standard that specifies the format of addresses used in X.25 networks. The X.25 resource record is designed to be used in conjunction with the RT (route through) resource record.

The following sections describe the DNS files that contain DNS resource records and that you create and use as the Microsoft DNS server database files.

Zone Files

A zone file contains resource records (described in the preceding table) for computers within the zone for which the DNS server is authoritative. A Microsoft DNS server zone file can contain multiple resource records of different types, depending on the information you enter about the computers in the zone.

A zone file is automatically created when you create a zone by using DNS Manager. The DNS Manager zone wizard prompts you for the needed information and then automatically creates a file named zonename.dns in the \%systemroot%\System32\Dns directory. You then use DNS Manager to add resource records to the zonename.dns file.

Note If you want to create a new zone file or reuse an existing zone file by using a text editor, rather than by using DNS Manager, see the sample zone files in the \%systemroot%\System32\Dns\Sample directory.

Cache File

The cache file contains name –to-IP-address mappings for the Internet root DNS servers and is used by the Microsoft DNS server to resolve name queries for computers that are located outside the enterprise network on the Internet.

When you install Microsoft DNS server, a cache file with current Internet root DNS mappings is automatically installed in the \%systemroot%\System32\Dns directory.

If you plan to use the Internet, you can use this cache file or you can obtain a copy from ftp://rs.internic.net/domain/named.cache.

If you do not connect to resources on the Internet, you should delete this file and create a new cache file that contains the host name – to-IP-address mappings for the DNS servers that are authoritative for the root of your private TCP/IP network. Replace the existing cache file in the \%systemroot%\System32\Dns directory with the new cache file.

Reverse Lookup Files

This file contains IP-address-to-host-name mappings (PTR records) that are used when a program or user has only the IP address of a remote computer but needs the host name associated to that IP address. This reverse lookup file is important for programs that implement security based on the connecting host name, and is also used for TCP/IP network troubleshooting.

There is no direct correlation between the conceptual model used to create IP addresses and the hierarchical structure of domain names. To provide a conceptual structure to manage IP-address-to-host-name mappings by using DNS servers, a special domain named in-addr.arpa was created. Nodes in the in-addr.arpa domain are named by using the numbers that comprise the dotted-octet representation of IP addresses, and IP-address-to-host-name mappings are mapped to these node numbers.

This is a somewhat complex mapping because IP addresses get more specific from left to right and domain names get less specific from left to right. The order of IP address octets must be reversed when building the in-addr.arpa top-down hierarchy (or tree). However, by using this method, administration of lower levels of the in-addr.arpa domain can be managed by using DNS servers and zones based on the class A, B, or C subnet addresses assigned to an enterprise.

You use the zone wizard in DNS Manager to create the reverse-lookup zone and files. DNS Manager automatically creates a reverse-lookup zone when the zone name that you enter is some form of nnn.nnn.nnn.in-addr.arpa.

After the reverse-lookup zone is created, you can add PTR records for the IP addresses contained within that zone. (The PTR record is analogous to the A record in the other zone files.) Reverse-lookup files also contain SOA and name server (NS) records as do other zone files.

Note In a PTR record, the IP address is actually written in reverse order and the text "in-addr.arpa." is appended to the end of the IP address to create the pointer. For example, the pointer for a computer with the static IP address 172.16.48.1 would be entered as "1.48.16.172.in-addr.arpa".

Boot Files

Although a boot file is not needed for Microsoft DNS server, it is described here for completeness. This file is not required by RFC and is actually a feature of DNS servers running under a BIND implementation of DNS. You would only use a boot file on a Microsoft DNS server if you want to port an existing BIND boot file to the Microsoft DNS server. For more information about using a BIND boot file, see the topic "Porting Data Files from Other DNS Servers" in the section "Troubleshooting DNS Server" later in this chapter.

Primary and Secondary Servers

The Microsoft DNS server can be either a primary or secondary DNS server to another Microsoft DNS server or to a DNS server running under another operating system (such as UNIX or other vendor's Windows NT implementation).

A primary name server is a DNS server that gets the data for its zones from the local DNS database files. When a change is made to the zone data, such as delegating a portion of the zone to another DNS server or adding hosts in the zone, these changes must be made on the primary DNS server so that the new information is entered in the local zone file.

A secondary name server gets its zone data file from the primary DNS server that is authoritative for that zone. The primary DNS server sends a copy of the zone file to the secondary DNS server in a process referred to as a zone transfer.

The minimum number of DNS servers you need in order to serve each zone is two — a primary and a secondary. Both a primary and a secondary server are required to provide database redundancy and a degree of fault tolerance. Generally, plan to install the primary and secondary servers on different subnets to provide continual support for DNS name queries if one subnet should go down. (Note that Microsoft DNS server automatically makes a zone backup by creating a local DNS backup directory the first time a zone is created on the computer running Microsoft DNS server.)

When a DNS server receives a DNS name query, it attempts to locate the requested information by retrieving data from its local zone files. If this fails because the server is not authoritative for the domain requested and thus does not have the data for the requested domain, the server can communicate with other DNS servers to resolve the request.

Caching-only Servers

Although all DNS servers cache queries that they have resolved, caching-only servers are DNS servers that only perform queries, cache the answers, and return the results. In other words, they are not authoritative for any domains and only store data that they have cached while resolving queries.

When trying to determine when to use such a server, keep in mind that when the server is initially started it has no cached information and must build up this information over time as it services requests. The benefit of using a caching-only server is that it does not generate zone transfer network traffic.

Microsoft DNS Clients

A DNS client (sometimes called a resolver) uses a DNS server to resolve name queries and to locate resources on TCP/IP networks.

Note Computers running under Windows NT Workstation or Windows NT Server version 4.0 automatically use DNS name resolution when a name query contains a name that is greater than 15 characters in length. If the name is less than or equal to 15 characters, either NetBIOS or DNS name resolution may be attempted. See Chapter 6, "TCP/IP Implementation Details," for additional details about DNS and NetBIOS name resolution.

There are three types of name queries that a DNS client can make. These types of name queries are recursive, iterative, and reverse (also called inverse).

A recursive name query is one in which the DNS client requires that the DNS server either respond to the client with the requested name –to-IP-address mapping or an error message stating that the data or domain name does not exist. The DNS server can not just refer the DNS client to a different DNS server.

Recursive name queries are generally made by a DNS client to a DNS server or by a DNS server that is configured to pass unresolved name queries to another DNS server. (Keep in mind that a DNS server can be a client to another DNS server.)

An iterative name query is one in which the queried DNS server returns the best answer it can give based on its cache or zone data. What this means is that if the queried DNS server does not have an exact match for the queried name, the best possible information it can return is a pointer to an authoritative DNS server in a higher level of the domain name space. This process will continue up through the DNS hierarchy to the next authoritative DNS server until the query reaches a DNS server that can provide a referral down the hierarchy to a lower-level DNS server in a different branch of the domain name space, until a DNS server is located that has data that is an exact match for the queried name, or an error or timeout condition is met.

This process is sometimes referred to as "walking the tree" and this type of query is typically initiated by a DNS server that attempts to resolve a recursive name query for a DNS client.

A reverse name query is one in which the DNS client provides the IP address and requests the name that matches that IP address. For example, to find a host name for the IP address 172.16.48.1, the DNS client would query the DNS server for a PTR record for 1.48.16.172.in-addr.arpa. If this IP address is outside the local domain, the DNS server would need to connect to the in-addr.arpa root server and sequentially resolve the in-addr.arpa domain nodes until it locates the DNS server that is authoritative for that IP address.

Planning for Microsoft DNS Server Implementation

You will want to install a Microsoft DNS server if the following conditions exist on your network:

You have established your own domain on the Internet and need a DNS name server. 

Your enterprise needs to implement DNS names on a TCP/IP-based intranet. 

You need a DNS name server that provides a GUI-based administration tool. 

You need to migrate existing non-Microsoft DNS name services to the Windows NT-based DNS server.

The number and location of computers running Microsoft DNS server that are needed to effectively manage DNS name data and name query traffic within your enterprise is a function of the size (number of hosts and their locations) of your network, the links between network subnets, and your network's security requirements.

When planning for the installation of Microsoft DNS server in your enterprise, there are several choices you can make. One option is to create one DNS zone that contains your entire enterprise domain.

The minimum number of DNS servers needed to serve each zone is two—a primary and a secondary—to provide database redundancy. As with any fault tolerant system, the computers should be as independent as possible, for example, by placing the primary and secondary servers on different subnets.

There are some disadvantages to using a single zone. One of the disadvantages is that the primary DNS server may have a problem responding to polling from secondary DNS servers. There are several ways to resolve this problem, such as increasing the secondary refresh interval, configuring some of the secondaries to obtain zone data from other secondaries, and configuring DNS servers in remote locations (or on the far side of a slow network link) as caching-only servers. (Caching-only servers allow you to avoid the overhead of zone transfers to remote locations or over slow network links.)

Large networks which span multiple sites should not use a single zone but instead use multiple zones to manage their DNS services. This implementation would consist of one root domain with (1) a primary DNS server and one or more secondary DNS servers and (2) one or more zones (and sub-zones as needed), each with a primary DNS server and one or more secondary DNS servers.

A network architect usually breaks up a corporate DNS domain into multiple subdivisions to distribute the administration of parts of the domain to various entities within the enterprise.

Whenever possible, plan to align your Windows NT domains with the organizational structure of your DNS domain, zones, and subdomains.

Using Microsoft DNS Server to Connect to the Internet

Many enterprises today are connecting their private, internal networks to the Internet to provide access to external resources on the Internet. Although this is an important capability, it is one that must be well planned to avoid possible security risks by exposing the internal network to users outside the enterprise.

One common way to provide protection is to use a computer that is referred to as a firewall. A firewall is a computer or network device that allows only certain authorized operations or programs to be run between internal networks and the Internet.

A firewall configuration can be very simple or extremely complex depending on the particular requirements of the enterprise. This chapter is not designed to provide an exhaustive description of firewalls but will briefly discuss how the Microsoft DNS server can be used on a network that uses the services of a firewall to provide security for the network.

The following figure illustrates a typical network architecture that includes a multihomed computer running as an Internet firewall.

Figure 9.3 A Typical Network with a Firewall 

As is illustrated in the Figure, the firewall protects the internal network from computers on the Internet that may attempt to access the internal network, while allowing computers on the internal network to access Internet resources. The example network design also includes computers that are configured as WWW and FTP servers that are external to the firewall.

The external servers allow computers from outside the internal network to access resources provided as public services, but these external servers must be closely monitored and secured because they are connected directly to the Internet network and do not use the firewall for access control. A router that is configured to control the type of packets allowed to pass through the router (referred to as packet filtering) can provide some additional access control.

The DNS services for the external and internal networks should be entirely isolated from one another to prevent computers outside the internal network from obtaining the names and IP addresses for resources located on the internal side of the firewall. This will help ensure that the only externally available information are the names and IP addresses of the external servers that are configured to provide external public services. These services include electronic mail, WWW, and FTP servers.

When internal network computers require access to computers outside the internal network, DNS name resolution typically requires interaction with DNS servers located on the public Internet. For this reason, you may want to allow only certain DNS servers to communicate outside the internal enterprise network. A DNS server that can communicate outside of the private network to resolve a DNS name query is referred to as forwarder.

After one or more DNS servers are designated as a forwarder, all other DNS servers on the internal network should be configured to use the forwarder for name resolution outside the internal network. The following figure illustrates this concept.

 

Figure 9.4 Using a DNS Forwarder and a Firewall 

When a DNS server which is configured to use forwarders receives a DNS request that it is unable to resolve (through its own zone files), it passes the request to one of the designated forwarders. The forwarder then carries out whatever communication is necessary to resolve the request and returns the results to the requesting server, which, in turn, returns the results to the DNS client. If the forwarder is unable to resolve the query, the DNS server attempts to resolve the query on its own as normal.

To configure a Microsoft DNS server to use a forwarder 

1.

In DNS Manager, right-click the appropriate server icon, and then click Properties

2.

In the Server Properties dialog box, click the Forwarders tab and enter the IP address of the forwarder.

Planning for Microsoft DNS and Microsoft WINS Integration

You can configure Microsoft DNS servers to use a Microsoft WINS server for host name resolution (remember that the host name portion of a fully qualified domain name (FQDN) is analogous to a NetBIOS computer name.) Microsoft DNS server includes support for inter-operation with the NetBIOS naming system of traditional Microsoft networking by delegating part of the name resolution process to computers running Microsoft WINS server. DNS names and NetBIOS computer names can be integrated as complementary naming schemes by using Microsoft WINS servers and Microsoft DNS servers.

A Microsoft DNS server can be configured to resolve the upper layers of a FQDN and, if necessary, to pass the final part of name resolution, the host name portion of the FQDN, to a Microsoft WINS server. The Microsoft WINS server can then use the host name (if it is the same as the NetBIOS computer name) to find the correct name-to-IP-address mapping. Once the WINS server finds the correct mapping, it then returns this information to the DNS server. The DNS server then sends the information to the DNS client; the interaction between the WINS server and the DNS server is transparent to the DNS client to whom it appears as though the DNS server handled the entire name resolution process.

Using Microsoft WINS and Microsoft DNS on a TCP/IP network allows network clients to use either a NetBIOS name or a DNS name to find, communicate with, and connect to network resources. When both Microsoft WINS and Microsoft DNS are enabled on a computer, the order of name resolution is as follows:

1.

A name query that contains a name greater than 16 characters is first sent to the DNS server for name resolution. 

2.

If the name is less than or equal to 16 characters, the name query is sent to the WINS server. If the WINS server cannot resolve the name, the name query is forwarded to the DNS server. 

By integrating Microsoft WINS and Microsoft DNS, you can use the dynamic names services of Microsoft WINS and reduce the number of static resource records you would normally have to maintain in a DNS database file. Note that this support is available only for Windows NT-based and Windows-based computers that are configured to use DHCP and Microsoft WINS servers.

You can install Microsoft WINS server and Microsoft DNS server on the same computer or on different computers running under Windows NT Server version 4.0.

When configuring TCP/IP on a computer running Microsoft WINS server under Windows NT Server, consider the following recommendations:

When determining the physical location of Microsoft WINS and DNS servers, use the physical characteristics of your LAN or WAN infrastructure and not the logical groupings defined in the Windows NT (or DNS) domain concepts. 

Manually assign an IP address, subnet mask, default gateway, and other TCP/IP parameters on the computer. Do not configure the computer as a DHCP client. Enter the Microsoft WINS server's static IP address into the DHCP server database as a reserved IP address (using DHCP Manager) to prevent assigning the IP address to another computer. 

To configure TCP/IP on a computer running Microsoft WINS server under Windows NT server 

1.

Click Start, point to Settings, and then click Control Panel

2.

Double-click Network

3.

On the Protocols tab, select TCP/IP Protocol, and click Properties

4.

Click the WINS Address tab. 

5.

Select the Enable DNS for Windows Resolution checkbox. 

6.

Click the DNS tab.

7.

In the DNS Service Search Order list, type the IP address of the DNS server that is geographically (physically) closest to the WINS server. 

You can enter multiple DNS servers in this list. 

When configuring TCP/IP on a computer running Microsoft DNS Server under Windows NT Server, consider the following recommendations:

Manually assign an IP address, subnet mask, default gateway, and other TCP/IP parameters on the Microsoft DNS server. Enter the DNS server's static IP address into the DHCP server database as a reserved IP address (using DHCP Manager) to prevent assigning the IP address to another computer. 

Use DNS Manager to configure the Microsoft DNS server to pass unresolved name queries to WINS servers, referred as WINS Lookup. See online Help in DNS Manager for detailed DNS server configuration tasks. (Microsoft DNS server can also be configured to perform Reverse WINS Lookup, which refers to obtaining an NetBIOS name by IP address query.) 

After you have configured TCP/IP on the Microsoft DNS server, create a zone for each group of computers where name resolution can be performed by using a WINS server.

Capacity Planning and Performance

Microsoft DNS server keeps track of a number of server usage statistics and displays these statistics in the right pane of the DNS Manager window. These statistics are cumulative; in other words they are started when the DNS server is started and are not cleared until the DNS server is stopped.

These statistics are useful for comparing relative name query traffic and load on each DNS server to determine how many name queries each DNS server is servicing. If one DNS server is busier than other DNS servers, you can direct some of the name query traffic away from the overloaded server to another server that is not as heavily loaded. For example if you have a primary and two secondaries, you can balance the load on the primary by configuring some of the DNS clients to point to one DNS secondary and other clients to point to the other DNS secondary. This reconfiguration can be done by using the DHCP server to change the DNS server which DHCP clients are configured to use, or by manually reconfiguring TCP/IP on non-DHCP enabled clients.

For capacity planning purposes, it is important to periodically compare the level of growth in usage of the DNS server versus the memory, disk, network, and CPU capabilities of the computer running the DNS server. If you feel that a DNS server is not responding as fast as it should, look first at the following performance monitor counters on that server. If any of the thresholds described in the following table are being met, there may be room to improve performance on the DNS server.

ObjectCounterThresholdNotes

processor

%processor time

> 80%

 

memory

available bytes

< 1 MB

 

physical disk

%disk time

> 67%

only available if you start the counters from the command line with diskperf -y, and reboot

network segment

% network usage

> 40%

only available if Network Monitor Agent is installed

If memory is an issue, then check the 'process' object, 'DNS' instance, 'Private Bytes' counter. If this counter is high, then the DNS service is causing the memory available bytes counter to be low. If this is the case, add more memory or possibly investigate which records are currently active in the DNS cache and find out the TTL associated with each.

If processor is an issue , check the 'process' object, 'DNS' instance, '%processor time' counter. If this is > 80 %, consider running the DNS server on a more powerful server. If this is not high, and processor '%processor time' is still high, look at all the other processes and determine which process is requiring large amounts of CPU time.

On a DNS server, physical disk '%disk time' should not be a problem, unless the system has started paging for lack of memory. If this is the case, treat this as a memory issue.

If network use is a problem, find out if it is the DNS server that is causing all of the traffic or another server on the same segment. To do this, use the Network Monitor utility to examine the traffic that is received and sent by the server.

DNS Server Memory Usage

Microsoft DNS server cache memory is different than processing of resource records. Virtual (pageable) memory is allocated for cached data as needed (remember, as a DNS server performs name resolution for a name query, it caches a copy of the data which is retained for the time period specified by the TTL). If the DNS server requires more than the normal amount of cache memory, this memory is taken from the local computer page file and is usually slower than cache memory.

Using DNS Manager

DNS Manager is the graphical user interface that is automatically installed and added to Administrative (Tools) on the Program menu when you install Microsoft DNS server on a computer running under Windows NT Server 4.0. You can use DNS Manager to administer local and remote Microsoft DNS servers and database files.

Note Keep in mind that you cannot administer non-Microsoft DNS servers by using DNS Manager.

DNS Manager provides menus and options that enable you to add and configure DNS servers, and a zone wizard that enables you to create the zones and sub-zones managed by each DNS server. Once you have added DNS servers and their zones, you can then administer the local and remote DNS servers and add, view, and edit DNS resource records that comprise the database files for each zone and DNS server.

To start DNS Manager 

Click Start, point to Programs, point to Administrative Tools, and click DNS Manager

The following sections provide introductory information about the basic tasks you perform to start using Microsoft DNS server. For a complete task list and detailed task instructions, see DNS Manager Help.

Tip When you make a change to DNS server and zone data by using DNS Manager, click DNS on the menu bar, then click Update Server Data Files to immediately write the changed information to the DNS database files.

Adding DNS Servers

Use DNS Manager to add the local and remote Microsoft DNS servers to be managed by using the local computer running Microsoft DNS server.

To add a Microsoft DNS server 

1.

In DNS Manager, click the Server List icon. 

2.

Click New Server, and enter either the DNS server host name or the IP address in the Add DNS Server dialog box. 

3.

Click OK.

DNS Manager will automatically display a server icon for the new server and automatically create the following zones:

Cache— contains the records needed to connect to the Internet root DNS name servers. 

0.in-addr.arpa— used to prevent passing reverse-lookup queries for the IP address 0.0.0.0 to the root DNS server . 

127.in-addr.arpa —used to prevent passing reverse-lookup queries for the loopback address name queries to the root DNS server. 

255.in-addr.arpa— used to prevent passing broadcast name queries to the root DNS server. 

After you have added a server, you can then configure the server and create the zone or zones to be managed by the server.

To configure the server 

1.

Right-click the server icon, and click Properties

2.

In the Server Properties dialog box, add the IP address (or IP addresses for a multihomed computer) and forwarder information as needed. 

Creating Zones

After you have added and configured a server by using DNS Manager, you create the zone or zones managed by that server. Remember that you will need to create a zone for each group of WINS-enabled computers where you want to use both DNS and NetBIOS name resolution. Before creating a zone, make sure that you have correctly configured TCP/IP on the DNS server and that you have entered the DNS server host name and domain name on the DNS tab on the Microsoft TCP/IP Properties page.

To add a Primary zone 

1.

Right-click the appropriate server icon, and click New Zone to start the zone wizard.

2.

Click Primary, and then click Next

The zone wizard will prompt you for additional information and then automatically create the zone, zone file, and the SOA, NS, and server A data records.

Tip To create a reverse-lookup zone, use this same procedure and use a zone name that complies with the reverse-lookup name format (nnn.nnn.nnn.in-addr.arpa). For example, the reverse-lookup zone that could contain PTR records for IP addresses 172.16.16.1 through 172.16.224.254 would be named .16.172.in-addr.arpa. Whenever possible, create reverse-lookup zones before adding host data so that you can use the automatic Create PTR Record option in the Add Host dialog box.

After you have created the primary zone, you can create secondary zones by using the same procedure.

To add a Secondary zone 

1.

Right-click the secondary server icon, and click New Zone to start the zone wizard.

2.

Click Secondary, and enter the requested information.

3.

Click Next

The zone wizard will prompt you for additional information and then automatically create the zone, zone file, and the SOA, NS, and server A data records. 

After a zone is created, you can further subdivide that zone as described in the following procedure.

To create a subdomain (a domain contained within a zone) 

1.

Right-click the appropriate zone folder. 

2.

Click New Domain

3.

Type the domain name in Domain Name, and then click OK

After you have successfully added a zone, you can configure and modify the zone properties. To do this, select and right-click the zone icon to display the Zone Properties dialog box. You can use the Zone Properties dialog box to perform the following actions:

Change the zone from a primary to secondary, or vice versa, by using the General tab. 

Modify the default server TTL values and the values used to determine refresh and zone transfer rates by using the SOA Record tab. 

Identify the secondary DNS servers that should be notified of changes in the zone by using the Notify tab. 

Configure the zone server to use WINS for host name resolution by using the WINS Lookup tab (on a reverse-lookup zone, this tab is labeled WINS Reverse Lookup.) 

The following figure illustrates the Zone Properties dialog box for a normal zone.

Figure 9.5 Zone Properties dialog box

The only difference in the Zone Properties dialog box for a reverse-lookup zone is the text on the WINS Lookup tab, as illustrated in the following figure.

Figure 9.6 Zone Properties dialog box for Reverse-Lookup Zone 

Adding and Modifying DNS Resource Records

DNS Manager makes it easy to add data to both local and remote Microsoft DNS servers because you can create and edit all DNS resource records by using DNS Manager. After you create a zone, you can select and right-click the zone to display a menu of actions that you can perform on the zone. The following figure illustrates this menu.

 

Figure 9.7 Zone menu 

The two menu choices that you use to add information about the computers in the zone are New Host and New Record.

You will want to use the New Host option to add the A and PTR records for the computers in the zone that are not DHCP- or WINS-enabled. The following figure illustrates the Add New Host dialog box.

 

Figure 9.8 New Host dialog box 

Additionally you will want to use New Resource Record to add other DNS information about a computer, such as alias (Cname), mail server, and so on. (Refer back to Table 9.2 for descriptions of the different types of resource records you can create.)

The following figure illustrates the New Resource Record dialog box.

Figure 9.9 New Resource Record dialog box 

Note You can use existing resource records in the DNS database files from other DNS servers. For more information about this topic, see "Porting Data Files from Other DNS Servers" in the section "Troubleshooting DNS Server" later in this chapter.

The Zone Transfer

How often zone transfers should occur is a function of how often names and IP address mappings change within your domain. Note that unnecessary zone transfer could cause unnecessary network and server loads.

A zone transfer is nothing more than a file copy procedure. The entire contents of the database are copied from the primary (or master) to the secondary each time the secondary is 'notified' by the primary (or master) that there has been a change in the zone data.

You configure primary and secondary zones with the information needed to initiate and request zone transfers by using the SOA Record and Notify tabs of the Zone Properties dialog box. You can change the default zone transfer timers by using the SOA Record tab. You can change the following values that affect zone transfer:

Serial Number 

Refresh Interval 

Retry Interval 

Expire Time 

Minimum Default TTL 

The following figure illustrates the SOA Record tab.

Figure 9.10 SOA Record tab

On the primary zone, use the Notify tab of the Zone Properties dialog box to identify the secondary or secondaries to notify for the zone transfer. The following figure illustrates the Notify tab.

Figure 9.11 Notify Tab 

Troubleshooting DNS Server

The following sections provide information about problems you might encounter when using Microsoft DNS server and the tools or procedures that you can use.

Using Nslookup

Nslookup is a TCP/IP utility that you can use at the command prompt. Use the nslookup command to get information about hosts in a domain or to set configuration parameters on a Microsoft DNS server.

For more information on how to use the nslookup command, see the topic "TCP/IP Procedures Help" in Control Panel Help.

Clearing DNS Server Statistics

DNS Manager displays statistics about the traffic received on the computer running Microsoft DNS server. These statistics are automatically started and displayed in the right pane of DNS Manager after you add a server and create at least one zone on that server. By default, these statistics are cumulative and are not normally cleared until the computer running Microsoft DNS server is stopped.

You can use the dnsstat.exe utility provided in the Windows NT Server version 4.0 Resource Kit to clear the statistics without stopping the Microsoft DNS server.

This command-line utility provides a dump of statistics about traffic received on a computer running Microsoft DNS server. You can also use dnsstat to clear these statistics without stopping the DNS server. By default, these statistics are cumulative and are not normally cleared until the computer running Microsoft DNS server is stopped.

dnsstat syntax

dnsstat {servername | IP address} [{-c | /c | -clear | /clear}]

Where servername returns all DNS server statistics on the server named servername. IP address returns all DNS server statistics on the server with the IP address indicated. The options -c or /c or -clear or /clear clear clearable DNS statistics on the server indicated.

To clear the Microsoft DNS server statistics by using the dnsstat command

1.

Click Start, and then click Run

2.

In Open, type dnsstat <servername> -c or dnsstat <servername> /c, and then click OK

This will reset the value the DNS statistics to zero. Open DNS Manager to verify that the statistics have been cleared and restarted.

For detailed information about using this utility, see Resource Kit Tools Help.

Resolving Slow DNS Zone Transfer to non-Microsoft DNS Servers

Slow DNS zone transfers may occur when your secondary DNS server is a non-Microsoft DNS server. By default, the Microsoft DNS server performs zone transfers to non-Microsoft DNS secondaries by sending one resource record per message. This behavior enables Microsoft DNS server to work with DNS servers running under an implementation of BIND earlier than BIND version 4.9.4. (Only BIND version 4.9.4 and later use a faster, high compression method that allows multiple resource records to be sent per message.)

If you are running a secondary non-Microsoft DNS server under BIND version 4.9.4 or higher, you can increase the speed of the zone transfer by creating a new parameter BindSecondaries of type DWORD with Value=0 in the following Registry key:

\HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \DNS \Parameters 

To add the BindSecondaries parameter 

1.

Click Start, and then click Run

2.

In Open, type regedit, and then click OK.

3.

Open the following key folder: 

\HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \DNS \Parameters 

4.

On the Edit menu, click New, and then click Key

5.

Type BindSecondaries, and then press ENTER. 

6.

On the Edit menu, click New, and then click DWORD Value

7.

Type 0 or 1 in the value box, and press ENTER.

Note Use value = 0 if you have no BIND secondaries or if all BIND secondaries are running under BIND version 4.9.4 or later. Use value = 1 if you have BIND secondaries running under a BIND implementation earlier than BIND version 4.9.4.

8.

Stop and restart the Microsoft DNS server by using Services in Control Panel.

Note Zone transfers between computers running Microsoft DNS server are automatically performed using the faster, high compression transfer method and are not affected by the BindSecondaries parameter.

Zone Wizard Did Not Correctly Autocreate SOA, NS, or A Record

The DNS zone wizard retrieves information from your user logon information and the TCP/IP configuration on the DNS server in order to create a zone. For example, the DNS zone wizard uses your logon name in the Responsible Party Mailbox Name field of the SOA Record dialog box.

If you are creating a zone that has the same name as your domain and you do not enter the domain name on the DNS page in the Microsoft TCP/IP Properties dialog box, the DNS zone wizard cannot create the A record. To add the domain name, use the Network applet in Control Panel to display and configure TCP/IP properties. Type the domain name on the DNS page of the Microsoft TCP/IP properties dialog box and then stop and restart the Microsoft DNS server by using the Services applet in Control Panel.

Note If you are creating a zone whose name is not the same as your domain name, you must manually add the SOA, A, and NS records in order to create the records with the new domain name and not the domain name configured on the local DNS server.

Porting Data Files from Other DNS Servers

You can use the boot, zone, cache, and other files from non-Microsoft RFC-compliant DNS servers. To do this, you must install these files in the \%systemroot\System32\DNS directory, and then stop and restart the DNS server.

Before installing files from other DNS servers on a Microsoft DNS server, you must edit the file name and directory location text in the ported files and make additional changes as described in this section.

The boot file will be used to load the data files you want to port into a Microsoft DNS server. A boot file is actually a file that controls the startup behavior of DNS servers running under a BIND implementation of DNS. It is a BIND-specific feature and not a requirement of the DNS RFCs. Microsoft DNS server's ability to use a boot file on initial startup is provided to support migration of data from BIND-based DNS servers to Microsoft DNS servers.

Although Microsoft DNS server will support a boot file, you must install the edited boot file before using DNS Manager. Starting DNS Manager configures the Microsoft DNS server to use the Windows NT Server Registry instead of the boot file.

If you need port data files after starting DNS Manager, you must change the value of the EnableRegistryBoot parameter from 1 to 0. The EnableRegistryBoot parameter is located in the following key:

\HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \DNS \Parameters 

To change the value of the EnableRegistryBoot parameter 

1.

Click Start, and then click Run

2.

In Open, type regedit, and then press ENTER. 

3.

Open the following key folder: 

\HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \DNS \Parameters 

4.

Select the EnableRegistryBoot parameter in the right pane of the Registry Editor, and then select Edit

5.

Click Modify, and type 0

6.

Click OK, and return to the menu bar and click Edit

7.

Select New, and then click DWORD Value

8.

Type 0 in the value box, and press ENTER. 

9.

Stop and restart the Microsoft DNS server by using Services in Control Panel

The following table describes the format of boot file commands. You can use any text editor to edit or create a boot file. Commands must start at the beginning of a line and no spaces may precede the commands. This table shows the order in which the Microsoft DNS server supported boot commands must appear in the file, and gives the syntax for each command.

CommandDescriptionSyntax

Directory

Specifies a directory where other files referred to in the boot file can be found.

directory <directory>

Cache

Specifies a file used to help the DNS service contact DNS servers for the root domain. This command and the file it refers to must be present.

cache <filename>

Primary

Specifies a domain for which this DNS server is authoritative, and a database file which contains the resource records for that domain in the zone file. Multiple primary command records can be entered in the boot file.

primary <domain> <filename>

Secondary

Specifies a domain for which this DNS server is authoritative, and a list of master server IP addresses from which to attempt downloading the zone information.

secondary <domain> <hostlist> <local filename>



© 2016 Microsoft Corporation. All rights reserved. Contact Us |Terms of Use |Trademarks |Privacy & Cookies