Troubleshooting Tips for DNS in Windows Server 2003


During my career as a biologist when we went on field trips, I had a student who always claimed that he had found a rare bird.  Inevitably it turned out to be the common or garden variety.  My point is this, when it comes to troubleshooting DNS, begin with the basics, investigate the most obvious solution, check the common trouble spots.

Beware of making the problem worse by altering settings that are correct.  Change one factor at a time, and write down what you configured.

1) Start Troubleshooting with Ping

Can you ping the target machine?
a) By IP address.  Ping 10.1.0.100
b) By Hostname.  Ping BigServer
c) By fully qualified domain name. Ping BigServer.guybay.com

Examine the replies for clues, for example is the reply BigServer or BigServer.domain.com.

Depending on the results from Ping, check the Default Gateway and Subnet Mask.

2) Do not neglect IPCONFIG

Collect information about default gateways and DNS servers with IPCONFIG's switches, particularly the /all.

What you are particularly interested in is the DNS Server's IP address.  Should that field be empty or incorrect then adjust the IP address at the Network Icon, TCP/IP properties.

Remember that Ipconfig has 3 DNS specific switches.  On more than one occasion /flushdns has saved me tearing my hair out.  What happens is that you may have solved the problem, but the a dirty cache prevents confirmation.  Ipconfig /registerdns can save a reboot, while /displaydns may give you extra information on what name resolution the client has achieved.

3) Time to look at the DNS server snap-in




At the DNS console, Click on View (Menu) and make sure that Advanced is ticked.  This is rather like 'Show All files'.

Precisely what to look for in the Snap-in, depends on the problem.  If you are checking basic connectivity, then check you have a Host (A) record for the machine you are trying to contact.  However, I would follow up PING with a check of the Monitor Tab on the DNS Server icon.



 
For basic Active Directory / DNS configuration check that the _msdcs records were created by DCPROMO.  If not try restarting the Netlogon service.

If you have a more difficult problem, for example zone replication, then click on the Server Icon, Properties.  (In the diagram Alan is the name of the server.)

One trap is to investigate the DNS server icon when you should be looking at the Forward Lookup Zone, domain name.  (Also vica versa, you look at the domain properties instead of the DNS server icon.)

About half the solution to DNS problems require a restart of the DNS service, fortunately Microsoft supply a Restart option on the 'All Tasks' menu.

If the problem involves internet connectivity, then check the root hints, see here for more information.

4) NSLookup

My conclusion for troubleshooting with NSLookup is avoid it.  Instead, where ever possible, use the above DNS snap-in.  At first I was in awe of NSLookup, then I mastered it, then I realized that it did not give me any more information than the DNS snap-in.
So, the killer use of NSLookup is if you do not have the DNS snap-in, for example you are troubleshooting from an XP machine. 

The trap with NSLookup is that you forget to configure the PTR records, without the corresponding Reverse Lookup Zone, NSLookup will fail. 

Instead of NSLookup I would use DNSLint see more here


5) Hosts files


Reverting to hosts files may seem like taking a step backwards into the dark ages, but many is the time that this trust old technology has solved a problem.

The beauty of the hosts file is its simplicity and the fact that the client operating system reads the hosts file BEFORE it queries DNS.  Be sure that you are editing the hosts file in the
%systemroot%\system32\drivers\etc.  (Not in the \i386 or dllcache folder)

Once you have opened the hosts file with notepad, experiment with hostnames and IP addresses for the server that you wish to connect.  Once you have added the host entry try once more to contact with Ping.

Example of Hosts file entries

10.10.0.1 BigServer
or
10.10.0.1 BigServer.guybay.com

6) Event Viewer

In truth the Event Viewer should be the first place to look for clues, not the last! Mastering the Event Viewer is an art in itself.  The point to remember is that DNS has its own Log.  By all means check the system log or even the application log, but do investigate the DNS log.

What you are looking for depends on the problem area.  But here are a few categories to check: Domain Name Problems,  Resource Record, Database Load and there really is a DNS Sanity Check!

  • See here for Advanced DNS Troubleshooting Techniques

Summary of Troubleshooting DNS

When Troubleshooting DNS server, always begin with the basics.  Start with Ping, Ipconfig and the DNS snap-in.  Also, remember the Event Viewer.  One of my favourite troubleshooting utilities is Monitor Server on the DNS Server snap-in.


Windows Server 2003 - NetDiag Tutorial


NetDiag provides a master class in testing Network Availability.  When you run NetDiag from the command line it carries out a battery of tests, which test your servers' ability to operate successfully.  As usual, my goal in this NetDiag tutorial is to show you how to get testing your Lan or Wan network.

Even if there is no problem with your Active Directory, it is still worth running NetDiag to learn about a healthy operating system, for example, NetDiag checks the NIC bindings.  Get a free copy of Netdiag at the end of this page.

Examples of NetDiag

  1. Installing Exchange and you wish to check that you can connect to other servers.
  2. Checking VPN network tunnels on the WAN.
  3. DNS problems.  Computers cannot 'see' their domain controller on the LAN.
  4. A quick check on hotfixes.
  5. Check the Network Card Bindings from the command prompt.
  6. You are having problems with IPSEC.
  7. Winsock corruption, wrong version incompatibilities.
  8. NetDiag checks that Domain Controllers are all able to 'speak' LDAP.

Installing NetDiag

NetDiag magically appears after you install the Support Tools from the Windows Server 2003 CD.  Once NetDiag.exe (and Support Tools) is the path then you can run it from any command prompt.

NetDiag switches

/v  If you need the full report on your network availability, then append this verbose switch to the command.  Unlike the /v of other utilities, NetDiag /v really does produce chapter and verse on your network cards and their binding.

/Debug  This debug switch was disappointing in that it did not produce any more details than those supplied by the /v.  Perhaps I would have received extra information if my Windows Server 2003 really had a network connectivity problem.

/q  When you just need to know if there are any errors, this is the switch for troubleshooting.  The /q is the antithesis of the /v and /debug.

/test:  Unlike DCDiag, NetDiag's test switched worked perfectly.  What is more the command:

netdiag /test produced the following list of possible tests:

  • NetSh PowerShell