Developer

Troubleshooting DNS in Windows NT 4.0

In this Daily Drill Down, Richard Charrington examines some aspects of DNS that will prove helpful when you're troubleshooting.


In the Daily Drill Down “Setting up DNS in Windows NT 4.0,” I showed you how to set up DNS on your NT Server and talked a little about how resource records are used in DNS and IIS (Internet Information Server). I also discussed creating aliases, using DNS to create virtual servers, and using DNS to distribute traffic between Web servers. In this Daily Drill Down, I’ll cover some aspects of DNS that will assist you in troubleshooting.

Troubleshooting
Establishing a DNS name server and creating a database of resource records is not a trivial task. Errors are common; many of these errors are described in RFC 1912, “Common DNS Operational and Configuration Errors.” As you know, DNS is used in TCP/IP networks. You can use the TCP/IP utilities provided with Microsoft Windows NT Server version 4.0 to troubleshoot problems you might encounter when using Microsoft DNS Server. You’ll find the following TCP/IP utilities very useful:
  • NSLookup: A diagnostic tool for DNS servers.
  • IPConfig: A utility used to display information about the TCP/IP configuration of local and remote computers.
  • Ping: A utility used to test the network connectivity of local and remote hosts.

If you encounter problems with DNS servers, see the topic “TCP/IP Procedures Help” in Control Panel Help and the Microsoft white paper “Windows NT Server Networking Guide.” In this Daily Drill Down, I’ll provide additional information you can use to troubleshoot Microsoft DNS Server.

RFC 1912 highly recommends verifying all data entered into DNS name server zone files. One common error with DNS name server data is incorrect formatting of DNS resource records. Using DNS Manager to automatically create and maintain resource records prevents potential resource record formatting errors.

Incorrect usage of resource records and entry of invalid data, however, are not precluded by using DNS Manager. Common data errors include inconsistent IP addresses in A and PTR records, alias names in PTR records, and invalid characters within host names. Common usage errors include invalid CNAME records, missing MX records, and incomplete or invalid zone delegation, also referred to as lame zone delegation.

I can’t address all possible data or usage errors in this Daily Drill Down, but the following information will help you examine your Microsoft DNS Server data files to identify data errors or incorrect usage of resource records for your own specific implementation of Microsoft DNS Server.

Examining DNS files and resource records
The database files below are important in troubleshooting Microsoft DNS Server. You’ll find these files in the \Systemroot\System32\DNS\ directory.
  • Cache.dns: This file is essentially the same on all DNS name servers connected to the Internet and must be present. It contains the names and addresses for the top-level name servers.
  • Zonename.dns: This file contains the name-to-IP address mappings for a specific zone. A zone file is created for each zone managed by the local Microsoft DNS Server.
  • NetworkID.in-addr.arpa.dns: This file contains the IP-address-to-name mappings for a reverse-lookup zone. The NetworkID portion of a reverse-lookup zone name is the network and subnet numbers that InterNIC or your ISP has allocated to your enterprise.

Cache.dns
When you install Microsoft DNS Server, the cache file is automatically installed. The data in this file contains name-to-IP-address mappings for the InterNIC root domain name servers. Microsoft DNS Server uses this information when name resolution queries must be resolved by getting information from name servers outside your LAN by contacting name servers on the Internet. You should not change this file unless the name-to-IP-address mappings of the Internet root servers change.

If the computer on which you install Microsoft DNS Server does not connect to the Internet, you should delete all the entries in this file and replace them with NS and A records for your intranet root name servers.

Zonename.dns
The zone file is automatically created when you configure a zone on a computer running Microsoft DNS Server. The zone file has the same name as the zone. Resource records are added to this file when you configure zone properties and add new records by using DNS Manager. If your computer running Microsoft DNS Server is configured with multiple zones, you’ll have multiple zone files in the DNS directory on that computer.

NetworkID.in-addr.arpa.dns
A reverse-lookup zone file is automatically created when you create a reverse-lookup zone.

Format of resource records
As I stated previously, when you use DNS Manager to create your zone files, the data for each resource record is automatically formatted. In general, you needn’t worry about the format of resource records. However, if you manually examine the DNS data files, you must understand the record format.

The standard format of a resource record as specified by RFCs 1034 and 1035 is shown below:
<name> [<ttl>] [<class>] <type> <data>

The fields in a resource record are as follows:
  • Name: This field contains the host name.
  • TTL: The time-to-live (TTL) value is an optional entry. It’s a 32-bit integer that represents, in seconds, the length of time the record is valid, after which it should be discarded.
  • Class: The class identifies the protocol and is generally IN, for Internet. Microsoft DNS Server uses only the IN class.
  • Type: The type specifies a resource record type. The most commonly used types are SOA, NS, A, CNAME, MX, and PTR.
  • Data: The data field is variable and is different for each record type. This field contains the information defined by the record type. The data in this field is specific to a particular host.

Most resource records are represented as single-line text entries. If you have resource records that span more than one line of text, you can enclose the record within parentheses.

Under Microsoft DNS Server, each resource record is entered into the zone file with preceding and following blank lines to improve readability. All blank and comment lines begin with a semicolon (;) and end with a carriage return. The semicolon instructs Microsoft DNS Server to ignore the line.

Consider the following example, which is taken from the sample DNS zone file Place.dns, located in the \Root\System32\DNS\Samples directory:
; START OF AUTHORITY
;
@ IN SOA  nameserver.place.dom. postmaster.place.dom. (
        1   ; serial number
        36000  ; refresh [1h]
        600   ; retry  [10m]
        86400  ; expire [1d]
        3600 )  ; min TTL [1h]
;
; NAME SERVERS
;
;
place.dom
@    IN NS  nameserver.place.dom.
@    IN NS  nameserver2.place.dom.
nameserver  IN A  192.5.29.7
nameserver2  IN A  192.5.29.8
;
; WINS LOOKUP
;
; The WINS LOOKUP is specific to the Microsoft DNS Server
;  implementation of DNS resource records and may be attached ONLY
;  to the zone root. Presence of a WINS record at the zone root
;  instructs the name server to use WINS to lookup any requests for A
;  (address) records for names which are DIRECT children of zone root,
;  and which do NOT have A records in the zone file.
;
@ IN WINS LOCAL 192.5.29.2 192.5.29.3
;
; E-MAIL SERVERS
;
@    IN MX  10  mailserver1
@   IN MX  15  mailserver2
mailserver1  IN A  192.5.29.17
       192.5.29.19
;
; CNAME RECORDS
;
; The following records are sometimes called "aliases" but are
; technically referred to as "Canonical Names (CNAME)" entries.
; These records allow you to use more than one name to point to
; a single host.
;
; For example, the entries below mean that:
;
; ftp.place.dom. is really host.place.dom.
; www.place.dom. is really other-host.place.dom.
;
; By using CNAME records, you avoid typing duplicate information
; in your database files.
;
ftp    IN CNAME host
www    IN CNAME other-host


Note that some line entries contain the @ character in the name field (that is, the first field). When the @ character exists in a name field, Microsoft DNS Server assumes that the name value is the same as the name of the zone. When the name field is blank, Microsoft DNS Server assumes that the name value is the same as that for the preceding record.

The optional TTL field follows the name field. If this field is blank, Microsoft DNS Server assumes that the TTL value is the same as the TTL value that was specified in the SOA record by using DNS Manager to configure zone properties. The default TTL value is 60 minutes. You can change this default value by using DNS Manager to edit the SOA value.

To change the default TTL value, start DNS Manager and right-click the folder for the zone whose default TTL value you want to change. Next, select Properties and click the SOA Record tab. Increase or decrease the value in the Minimum Default TTL box. Next, increase by 1 the value in the Serial Number text box. The serial number is the number used to identify the version of the file. To save the changes, click OK twice.

Name errors
Name errors are common in the operation of DNS name servers. Name errors can occur because of the differences between what is acceptable in NetBIOS computer names and what is acceptable in DNS host names. NetBIOS computer names support a different character set than DNS host names, and by installation default, Windows NT Server and Windows NT Workstation are configured with a host name by using the NetBIOS computer name. In other words, the installation default for Windows NT Server and Windows NT Workstation is to configure the NetBIOS computer name as the DNS host name.

If the NetBIOS computer name contains invalid host name characters, Microsoft Windows NT Server and Windows NT Workstation attempt to correct the name by changing the invalid character in the host name to the hyphen (-) character. However, this change generates name resolution errors. For example, if your Web server NetBIOS computer name is Server#1, all attempts by remote TCP/IP network users to connect to the Web server by using the URL http://Server#1 will fail. They do so because the invalid # character is changed in the DNS host name, changing Server#1 to Server-1.

If computers in the zone managed by your Microsoft DNS Server use NetBIOS names containing characters not supported in DNS host names, you must manually configure a valid host name on those computers.

To change a host name to a valid string of characters, right-click Network Neighborhood, select Properties, and click the Protocols tab. In the Network Protocols list, click TCP/IP Protocol, and then click Properties. Next, click the DNS tab. In the Host Name text box, type the corrected host name. To finish, click OK, and then click OK again.

Valid DNS host names can include only ASCII letters, digits, and the hyphen (-). They may not be all numbers, but they may have a leading digit (for example, 3com.com). They must end and begin with a letter or digit. For more information about rules for creating valid host names, see RFC 1912, RFC 1035, and RFC 1123.

Locating multihomed computers
A multihomed computer is a single computer associated with multiple IP addresses. When a DNS name server is queried for a single host name-to-IP-address mapping for a multihomed computer, it responds with a list of the host name-to-IP-address mappings for that computer.

Because of the round-robin feature of Microsoft DNS Server, described in “Setting up DNS in Windows NT 4.0,” the order of the listed mappings for a multihomed computer changes with each new name query. The round-robin feature enables DNS to respond with the list of mappings in a different order each time it receives a name query for the multihomed computer. This feature is used to balance the load of connections made to each IP address. If one or more of the listed mappings is incorrect—for example, if there is an incorrect or nonexistent IP address—errors can occur.

TCP/IP utility programs, NetBT programs, and Microsoft Internet Explorer all process the list of mappings for a multihomed computer differently. Some TCP/IP utility programs, such as FTP and Telnet, send a separate name resolution request to the DNS server each time an attempt is made to resolve a name to an IP address. These utilities use the first IP address in the list returned for each new request by the DNS server. If that first IP address is incorrect, the program fails to connect to the multihomed computer, even though it may have previously connected by using a previous name resolution query.

Programs that use NetBT to connect to remote computers process the list provided by the DNS server in a different manner. The first time a DNS client program using NetBT sends a name query to a DNS server, it saves only the first mapping in the list in a local cache on the DNS client computer. If the first mapping is incorrect, the program fails to connect to the multihomed computer.

The list is saved for a period of time defined as the CacheTimeout, which has a default value of 10 minutes. Any subsequent name resolution queries made within the CacheTimeout period are resolved by using the mapping saved in the local cache. Name queries made after the CacheTimeout period is expired require a new request for host name-to-IP-address mapping. If the subsequent mapping is correct, the client program connects to the multihomed computer. If the subsequent mapping is incorrect, the client program fails to connect.

Microsoft Internet Explorer processes the list received from the DNS server differently than either the TCP/IP utilities or NetBT. Microsoft Internet Explorer tries to connect to the multihomed computer by using each name-to-IP-address mapping until it succeeds or until it has attempted all IP addresses in the list.

The responsibility of performing in this manner lies with the application. It is the responsibility of the resolver to return the addresses from DNS, not to define the manner in which the application uses the addresses.

To prevent failure to connect to a multihomed computer, use DNS Manager to select the zone in which the multihomed computer exists and create A and PTR records for each IP address associated with the multihomed computer. Do not create A and PTR resource records for IP addresses that are nonexistent on the multihomed computer. Use DNS Manager or a text editor to examine the data in the A and PTR records for the computer. Delete any A or PTR records that contain invalid IP address mappings.

Errors when starting Exchange Server
You might receive the following error message when starting the Internet Mail Connector service on the computer configured with Microsoft Exchange Server:
Stop "Could not start the Microsoft Exchange Internet Mail Connector service on ..."
Error 2140: An internal Windows NT error occurred.
If so, the following event will be logged in the event viewer:
EventID 4058
Category: Initialization/Termination


This error occurs when the TCP/IP protocol properties for DNS name resolution are not properly configured—for example, when there’s a blank entry for the DNS domain name. To configure a DNS domain name, right-click Network Neighborhood, select Properties, and click the Protocols tab. Next, in the Network Protocols list, select TCP/IP Protocol, and then click Properties. To display the DNS information configured on the computer, click the DNS tab. In the Domain text box, type the DNS domain name (that is, the name of the enterprise in which the Microsoft Exchange Server exists). To finish, click OK, and then click OK again to close the Network Properties window.

Conclusion
DNS is one of the most important services that you deploy on your server if you’re connecting to the Internet or using TCP/IP. Unfortunately, it can also be troublesome to implement. In this Daily Drill Down, I’ve shown you some of the things you can look for to troubleshoot your Windows NT 4.0 DNS.

Richard Charrington’s computer career began when he started working with PCs—back when they were known as microcomputers. Starting as a programmer, he worked his way up to the lofty heights of a Windows NT Systems Administrator, and he has done just about everything in between. Richard has been working with Windows since before it had a proper GUI and with Windows NT since it was LANManager. Now a contractor, he has slipped into script writing for Windows NT and has built some very useful auto-admin utilities.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox