It’s 2017, and DNS has taken over as the de-facto standard for name resolution. It’s been this way for many years, and we like it! It’s organized, hierarchical, and makes sense!
However, DNS is not always what computers will use.
What is DNS?
Domain Name System (DNS) is the foundation of Microsoft’s Active Directory. It appears as wizardry to some, magic to others, and a database for most. When Active Directory is on the fritz, remember the DNS haiku:
It’s not DNS;
It is never DNS;
It was DNS
To troubleshoot when you’re on an Active Directory domain is simple - use nslookup <computername> to see what the name server returns. It will show which name server is resolving the address, and the address it received back. For example, when looking up www.google.ca:
nslookup www.google.ca
Server: ns.lukebarone.lan
Address: 192.168.0.1
Non-authoritative answer:
Name: www.google.ca
Addresses: 2607:f8b0:400e:c04::5e
173.194.203.94
My name server knew how to find Google’s Canadian address, as I used it many times, and it saved the response. If it ever does not know the answer, it looks through the root name server (for the . domain). After getting an answer, it would look for the ca. domain. Next, it would look for the google.ca. domain, then finally the www.google.ca. domain. Very basic rundown, you can find more information on Wikipedia.
Issue found, now what?
To fix DNS issues, you first need to know where your computer is looking for an answer. On Windows, you can run ipconfig /all to view the DNS servers. For Linux, you can usually check under /etc/resolv.conf for the nameserver parameter. If you have control over these servers, then you can work on getting DNS fixed. If you don’t, and you’re simply at a client workstation, you can attempt to run (from the computer that won’t resolve correctly) ipconfig /flushdns && ipconfig /registerdns. This may or may not work, but it seems to work when DNS is properly configured with DHCP.
If you have access to the DNS server’s configuration, you need to check your zones. For Windows, use the DNS Management MMC snap-in (%WINDIR%\System32\dns.msc). For Linux, you’ll likely have bind/named, or dnsmasq. You’ll need to check your server for each, and see which one is running (ps can help).
Once you are in the zone that seems to have incorrect information, check the TTL or expiry on the A/CNAME records for the system in question. If the expiry is in a long time, you’ll need to manually update it and increment your serial number. If the TTL or expiry is very low, you can wait it out, and let the system get the current address from the client. Active Directory seems to keep a close eye on the name-to-IP mapping, for security, so I wouldn’t worry too much about LAN traffic getting lost along the way.
That didn’t work? Must be NetBIOS…
If you are not running an Active Directory domain, you may be running a Samba server hosting an NT4-style domain (as deprecated as Microsoft may claim). Many organizations and people still run Samba in this mode, which does NOT rely on DNS. Instead, it’s relying on NetBIOS for name resolution. When this happens, you see weird behaviour if systems get new IP addresses.
NetBIOS uses WINS servers for resolving names, then looks for responses from a BROADCAST request to the network. Both methods work for various networks, and are usually used together.
One example in particular was when I was using Admin Arsenal’s PDQ Inventory (which I love). I was looking for information on computers that have been handed in, and noticed they were duplicated under new names! TEACHER-01 would appear as the same computer as TEACHER-45, complete with Serial Number and IP Address! When I attempting to PING, both computer names reported back the same IP Address, which is what got it confused!
I looked for help, and even flushed my DNS. It never seemed to work. The reason is because the system was using NetBIOS Name Resolution to do the name-to-IP translation. Luckily, I understood this, and narrowed my search terms.
So how did you fix it?
On the server (running Debian), I checked if it could see the correct IP Address. I tried to ping both computer names, and the responses were the same. Since my Windows workstations would look to this Samba server as the WINS server, I knew the issue was on this side - and I was right.
I used nmblookup <hostname> to see what Samba found. Usually it returned the correct address… as well as a few extra IP addresses. This was an issue since we used DHCP, and spanned across a few subnets depending on location. Obviously, the next step is to figure out where it’s getting this information from, and correct it.
I learned that Samba stored the data in a file called wins.dat. On my system, it was in /var/lib/samba, but it may be somewhere else. To find it, execute find / -xdev -type f -name "wins.dat". This command searches the entire root (/) for a file called “wins.dat”, and spits out all the files it finds with that name.
After checking the file, I saw multiple entries for the computers I looked for. The file is laid out very simply, but I still recommend NOT editing it to add entries yourself. It was being used by the nmbd service, so that needed to be shutdown first. I created a short script to deal with the issue for me:
#!/bin/bash
/etc/init.d/nmbd stop
mv /var/lib/samba/wins.dat{,.old}
/etc/init.d/nmbd start
For those unfamiliar with some of BASH’s awesomeness, the command expands automatically to mv /var/lib/samba/wins.dat /var/lib/samba/wins.dat.old, thanks to the curly braces.
Once nmbd starts again, I can lookup the computer name, and it will send the broadcast request out to find the correct IP address! Hooray!
But Windows didn’t see it right…
That’s right - Windows kept its own cache as well. This one was a little more tricky to deal with at first.
After ensuring the server had it correct, I had to (as an Administrator) run nbtstat -RR. nbtstat is how Windows handles name resolution with NetBIOS names, just as nslookup is how it handles name resolution with DNS. The above command re-registers the computer in the WINS server, and dumps any cached entries saved. Once I did this, my pings went to the correct computer, and PDQ Inventory picked up the correct computer.
If you want to see the cache, or look for a specific entry, you can also run nbtstat -c (for cache), or nbtstat -r (for resolved). For more information, refer to the following entry:
Displays protocol statistics and current TCP/IP connections using NBT (NetBIOS over TCP/IP).
NBTSTAT [ [-a RemoteName] [-A IP address] [-c] [-n]``[-r] [-R] [-RR] [-s] [-S] [interval] ]
-a (adapter status) Lists the remote machine's name table given its name
-A (Adapter status) Lists the remote machine's name table given its``IP address.
-c (cache) Lists NBT's cache of remote [machine] names and their IP addresses
-n (names) Lists local NetBIOS names.
-r (resolved) Lists names resolved by broadcast and via WINS
-R (Reload) Purges and reloads the remote cache name table
-S (Sessions) Lists sessions table with the destination IP addresses
-s (sessions) Lists sessions table converting destination IP``addresses to computer NETBIOS names.
-RR (ReleaseRefresh) Sends Name Release packets to WINS and then, starts Refresh
RemoteName Remote host machine name.
IP address Dotted decimal representation of the IP address.
interval Redisplays selected statistics, pausing interval seconds``between each display. Press Ctrl+C to stop redisplaying statistics.
Additional Troubleshooting
This is all that resolved (pun intended) the issues for me. There are a few other locations you can check for as well.
On both Linux/BSD and Windows systems is a HOSTS file. On Linux/BSD, it is in /etc/hosts - on Windows, it’s in %WINDIR%\System32\drivers\etc. This file format is the same on both architectures - IPA.ddr.e.ss hostname.domain.tld. The hosts file always takes precedence when using applications trying to connect by DNS name. On Windows, there is also an LMHOSTS file that can be put in the same location, with the same format (minus the domain.tld section), to take precedence over NetBIOS names. Check these files for errors if you are still having issues. Note that you need Administrator Rights (Windows) or root access (Linux/BSD) to make changes to these files.
Next up, are you even looking for the correct name? If you have access to the target computer, execute the command “hostname”. The computer will tell you it’s DNS hostname, and you can assume the NetBIOS name is the first part (before the first period).