Two Minute Drill: Troubleshooting Name Resolution

Welcome back AskPerf readers!  For our readers in the United States, I hope you enjoyed your three day weekend for the Labor Day holiday, but it’s time to get back to work.  I know today’s title looks like it should be posted on one of our Networking blogs, but we see a few issues with name resolution over on the Performance team – especially when the problem relates to applications not functioning as expected.  So let’s dive right in …

When troubleshooting name resolution problems as they relate to application functionality, it is important to determine how the application connects – does it use NetBIOS name resolution or does it use sockets (host name resolution)?  NetBIOS application issues – especially with applications such as Windows Explorer, My Network Places and use of the various net commands (such as net use) are the ones that we see quite often on the Performance team.  When the Performance team supported Internet Explorer (which uses sockets / host name resolution), we obviously dealt with our fair share of customer incidents dealing with connectivity.

The most common symptom of a NetBIOS name resolution problem is the Error 53 message.  This message is returned when name resolution fails for a particular computer name or when there is a problem establishing a NetBIOS session – such as trying to connect to \\<servername>.  However, the error message itself does not tell you whether the problem is a name resolution one, or a session establishment problem.  To narrow down the problem you can try a couple of different tests:

• net view \\hostname: if this works, then you probably do not have a name resolution issue.  You can also ping the hostname to confirm this.  However, remember that if you encounter a problem connecting to a share name, for example, that the problem could also be due to an incorrect entry in DNS / WINS.  In that type of scenario, simple connectivity tests may work such as net view and ping, but net use will still return an Error 53, because the server does not have the resource name you are trying to use.
• net view \\ipaddress: This actually removes the name resolution piece from the equation.  By connecting directly to the IP address, we bypass both DNS and WINS.  If this test fails, then the problem is in establishing the NetBIOS session itself

When troubleshooting sockets (host name resolution) connections issues, we can still use the ping command – however, you should always specify the Fully Qualified Domain Name (FQDN) for the target machine to ensure that you are hitting the right system.  You can also use nslookup hostname to determine not only if you are hitting the correct machine, but also to determine if the DNS entry on whichever server you are using for your lookup server is correct.

Remember that we often assume that entries in the DNS and WINS server databases are correct – it never hurts to double check them!  That holds especially true if you are using static LMHosts or HOSTS files – it’s one of those things that we tend to overlook (and forget!) when dealing with name resolution.  This is especially true in legacy environments that have been upgraded.  The remnants of the old HOSTS / LMHOSTS file can create some issues.

With that, I’ll bring this post to a close.  Until next time …

- CC Hameed