1) Start Troubleshooting with Ping
Can you ping the target machine?
a) By IP address. Ping 192.168.1.3
b) By Hostname. Ping myserver
c) By fully qualified domain name. Ping myserver.company.com
Examine the replies for clues, for example is the reply myserver or myserver.company.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
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.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.
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
192.168.1.3 myserver
or
192.168.1.3 myserver.mycompany.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! 
No comments:
Post a Comment