Troubleshooting Tips for DNS in Windows Server 2003
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.
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.
See more about ipconfig
in PowerShell 3
Guy Recommends: A Free Trial of the Network Performance Monitor
(NPM)
SolarWinds'
Network Performance Monitor
will help you discover what's happening on your network. This
utility will also guide you through troubleshooting; the dashboard will
indicate whether the root cause is a broken link, faulty equipment or
resource overload.
Perhaps the NPM's best feature is the way it suggests solutions to network
problems. Its second best feature is the ability to monitor the health of individual VMware
virtual machines. If you are interested in troubleshooting, and creating network maps, then I recommend that you
give this Network Performance Monitor a try.
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.
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
Calculating IP Address ranges is a black art, which many network managers
solve by creating custom Excel spreadsheets. IPAT cracks this problem of
allocating IP addresses in networks in two ways:
For Mr Organized there is a nifty subnet calculator, you enter the network
address and the subnet mask, then IPAT works out the usable addresses and their
ranges. For Mr Lazy IPAT discovers and then displays the IP addresses of existing
computers.
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.
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!
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.
If you like this page then please share it with your friends
Guy Recommends:
SolarWinds' NPM - Network Performance Monitor
SolarWinds' performance monitor is designed for detecting network outages,
making it easy to see what's working, and what needs your attention.
This utility guides you through creating network maps; it also helps
identifying whether the
root cause is faulty equipment, or resource overload. Give NPM a try.
Beware of making the problem worse by altering settings that are correct.
Change one factor at a time, and write down what you configured.
