If there’s one component of Windows 2000 that needs to be solid from the get-go, it’s DNS. DNS is the backbone of Windows 2000 Active Directory, the repository of the information your network’s hardware and software need to communicate. If DNS fails, so does your network. In this Daily Drill Down, I’ll show you what’s involved in troubleshooting a faulty DNS server.

Start with the basics
If you’re having DNS problems, you don’t want to get out your Windows CD-ROM and start reinstalling software. There are many things you can do to diagnose and solve DNS problems before taking drastic steps. The best way to fix problems is to start with the basics.

If a user reported the DNS trouble, the first thing you should do is try DNS out yourself. Even though you can do that simply by opening a browser window, you can also ping the user’s workstation using the workstation’s DNS name rather than an IP address. If you get a response, you know DNS is working because Ping uses DNS for name resolution. If ping doesn’t return a response, you first need to check all the obvious weak links before you start fiddling with the DNS installation. These include the network card, cables, and any router that the user may be sending packets through.

At the user’s workstation, you should run IPCONFIG /ALL from a command line to see whether the TCP/IP stack on the local machine is responding correctly. If you’re running DHCP, try running IPCONFIG /RELEASE followed by IPCONFIG /RENEW. Running these two commands back to back will renew the IP address lease and refresh the workstation’s DHCP options.

If you run IPCONFIG /FLUSHDNS, you can flush the local host’s resolver cache. After that, run IPCONFIG /REGISTERDNS to check the event log and zone file for errors and updates, respectively. If you’re lucky, this could be all you need to do to isolate and fix the problem.

If you need more help diagnosing DNS, you can use an NSLOOKUP query. NSLOOKUP is a command-line utility that allows you to query DNS server zone files.

NSLOOKUP

For more information about NSLOOKUP, see the Daily Drill Down “Resolving mail server problems with NSLOOKUP and Telnet.”

Just as with any other service, the Event Viewer is a gold mine of information when resolving DNS errors. Some of the common DNS errors you may find in Event Viewer include:

  • 132 (Warning) DNS_EVENT_NBSTAT_ADAPTER_FAILED
  • 404 (Error) DNS_EVENT_CANNOT_BIND_TCP_SOCKET
  • 409 (Warning) DNS_EVENT_UPDATE_LISTEN_ADDRESSES
  • 500 (Error) DNS_EVENT_INVALID_REGISTRY_ZONE
  • 1003 (Error) DNS_EVENT_CACHE_FILE_NOT_FOUND
DNS Errors

For a complete list of DNS Errors found in Event Viewer, visit Microsoft’s TechNet Knowledge Base.

DNS logs
You can configure DNS to write logs, and I recommend that you do so. DNS logs can be an invaluable source of information on what went wrong, when, and sometimes even why. To set up logging, start the DNS MMC by clicking Start | Programs | Administrative Tools | DNS. Right-click your DNS server, choose Properties, and then go to the Logging tab. You can then select the types of DNS actions you’d like to log.

By default, Windows 2000 locates the DNS log in the %systemroot%\system32\dns\dns.log file. If you want to change the path to the DNS log, you can do so in the registry. Open the server’s registry and change the value of the HKLM\System\CurrentControlSet\Services\DNS\Parameters\LogFilePath key.

The DNS log file is limited by default to 4 MB. Like the log file location, you can change the size of the DNS log file by making changes in the registry. To do so, you need to add a REG_DWORD entry called  LogFileMaxSize to the HKLM\System\CurrentControlSet\Services\DNS\Parameters key.

Be careful in the registry

Remember to use caution any time you edit the registry. It’s wise to perform a full backup before you change anything in the registry.

Check your cache
DNS stores its name resolution information in files called zone files. There are four types of zone file in Windows 2000: Primary, Secondary, Reverse, and Active Directory Integrated (ADI). DNS includes another important file called CACHE.DNS. CACHE.DNS is not really a zone file, but it holds the same kind of information as a zone file.

One of the most common problems encountered when working with DNS servers is corruption of the CACHE.DNS file. If your users can resolve everything on the local private network but can’t connect to any Web sites on the Internet, this may point to a problem in the CACHE.DNS file.

To remedy this situation, first ensure that the DNS Server service is stopped. Then just pop in your Windows 2000 Server CD, find the CACHE.DNS file on the CD, and copy it into the %systemroot%\system32\dns directory on your server, overwriting the other file. Then restart the DNS Server service and check to see if name resolution is working again.

Breaking down the problem
After you’ve eliminated all other potential causes of name resolution failure, you’re left with the DNS server itself. A Windows 2000 DNS server is most likely to fail on startup, so the most important thing at this stage is to understand what files and processes are involved in starting or booting a DNS server. The files involved, in order of use, are:

  • BOOT: The BOOT file does two things: It tells the DNS server if it’s a root server, and also if it’s a primary and/or secondary DNS server for any DNS naming zones.
  • CACHE.DNS: This file lists so-called root hints relevant to your DNS installation’s top-level servers. By default, the file contains the names and IP addresses of all 13 Internet root servers. This is because DNS is most often used for Internet name resolution; but if your network is disconnected from the Internet, your DNS servers act as root servers.
  • Zone files: There is one zone file for each zone hosted on a particular DNS server. The zone file contains all machine names and IP addresses relevant to the domain whose information is stored in the zone file.

You can initiate the startup process for a DNS server from three sources: the BOOT file itself, Active Directory, or the registry. By default, a Windows 2000 DNS server stores all startup information in Active Directory or the registry, or a combination of both. Normally this is fine, but you may want to consider changing the way DNS starts by having it start from the ASCII BOOT file in the %systemroot%\system32\dns directory. Starting DNS from the BOOT file simplifies troubleshooting and repair because you can manually edit the BOOT file using any text editor, should you need to.

To change the way your DNS server starts, open the DNS MMC, right-click your server’s icon, and select Properties. When the Properties window appears, click the Advanced tab. Finally, select Boot From File From The Load Zone Data drop-down list box.

You can accomplish the same thing from the registry by finding the HKLM\System\CurrentControlSet\Services\DNS\Parameters key. Check to see if it contains a BootMethod entry. If BootMethod doesn’t exist, you can create it as a REG_DWORD, setting its value to 1. Values 2 and 3 cause DNS to start from the registry and Active Directory, respectively.

The BOOT file
When checking the BOOT file, you should see various entries such as the primary record, the secondary record (if applicable in your DNS installation), and a cache record.

You should see something like this:
1 primary tweedldee.com tweedldee.com.dns
2 secondary tweedldum.com 100.100.100.103 tweedldum.com.dns
3 cache . cache.dns

Please note that the numbers on the left are line numbers I put in for my example—you won’t see them in the BOOT file. Line 1 indicates that this DNS server is primary and authoritative for tweedldee.com and that the zone file for this domain is called tweedldee.com.dns. Line 2 indicates that this server is also a secondary server for tweedldum.com. The IP address you see is the one pointing to the primary name server of tweedldum.com. The tweedldum.com.dns entry is the name of the secondary zone file for tweedldum.com.

In Line 3, you’ll see the entry for the cache file. The dot refers to the root servers, whether they’re local or the 13 on the Internet. They have no name because they are the top-level name resolvers. Finally, cache.dns refers to the name of the file itself.

So if your dead DNS server has intact cache and zone files, and it received boot information from Active Directory or the registry, how do you fix it and get DNS going again? First, install DNS on a new server and set it to boot from the BOOT file instead of from Active Directory and/or the registry. Then stop the DNS service and restore the cache and zone files to %systemroot%\system32\dns.

But you say you don’t have a BOOT file so you can’t start DNS anyway? Maybe not, but using the information and layout above, you can write your own BOOT file in no time. You know what needs to be in your BOOT file because you know the names of all the zone files. If you need IP addresses for secondary records, you can open the relevant secondary zone file(s) and find them. Once this is done, you can start the DNS server again, and you should have your network up and running in no time.

Apart from its simplicity, this method gets Active Directory working again because the zone files contain all the necessary data, such as SRV records, needed to locate domain controllers for Active Directory replication and other Active Directory activities. To be sure it all works, run NSLOOKUP and run some queries.

Best practices
Here are some suggestions to help you design and configure your DNS deployment to prevent trouble:

  • Make sure you have redundancy in your DNS server infrastructure. This means using more than one server to host each DNS zone.
  • Make sure that the e-mail address for the zone administrator is correctly entered into the zone information because DNS will use this address to send alerts for a variety of DNS illnesses. E-mail addresses in DNS are entered with a period (.), not an ampersand (@). E.g., admin@mydomain.com must be entered as admin.mydomain.com.
  • Use ADI zones, but set the BootMethod to use the BOOT file rather than Active Directory or the registry.
  • Use secure DDNS.
  • If you have a large network, consider installing one or more dedicated caching-only DNS servers to offload the other servers.
  • If you’re using DHCP with the above option, make sure you provide each client with two DNS server addresses in case one of the DNS servers breaks. This way, clients can resolve names and they can also continue to update their A and PTR records via DDNS.

Of course, if none of these approaches fits, you’ll most likely either need to restore DNS services from a backup, build a new domain from scratch (ouch), or find a new job, preferably on some distant beach.