DNS Troubleshooting

Purpose

You want to understand how to troubleshoot host name resolution issues, and how it affects PDQ software. You receive one of the errors listed below, or a similar error indicating that DNS resolution for the target machine has failed.

• Target Computer Name Mismatch
• NTLM: Target computer name mismatch
• Kerberos: The target account name is incorrect
• The network name cannot be found
• The network path was not found

Resolution

Note: This is not to show if DNS host name resolution is working, but if DNS host name resolution is pointing to the wrong IP Addresses.

Troubleshooting methods and why it's important to have a one-to-one relationship between a DNS record, IP Address, and a computer are covered in the following sections:

1. DNS Troubleshooting from the PDQ Server
2. DNS Troubleshooting from the DNS Server
3. Recommended Fixes
4. Misconfigured DNS Scenarios
5. Helpful Resources

To troubleshoot host name resolution, you must first determine the following.

• What IP Addresses a computer's DNS records contain.
• Which of these IP Addresses are actively in use.
• What other computer DNS records contain the same IP Addresses.

Once you have determined the troubled DNS records, you can research the following.

• Where are the computers getting their IP Addresses from?
  • Different DHCP servers with different lease times?
• Why are the invalid DNS records for the computers not being deleted?
  • Is DNS scavenging enabled?
  • Is DNS scavenging in sync with DHCP lease times?
• How are the computers registering their IP Addresses in DNS?
  • By themselves?
  • By a DHCP server?

DNS Troubleshooting from the PDQ Server

To troubleshoot DNS, ensure that the target computer is the correct computer. This can be accomplished by performing the following:

1. On the PDQ console machine, open an administrative/elevated command prompt and run ONE of the following,

ipconfig /flushdns

Or

sc stop dnscache && sc start dnscache

2. From the same or new administrative/elevated command prompt run, 

nslookup TARGET

Using the IP address returned from the results of the nslookup command above run,

nbtstat -A <IP_Address>

For example:

IMPORTANT: Microsoft released an update in 2016 that prevents NetBIOS resolution traversing different networks and subnets. If the PDQ console is on a different network/subnet than the target machine, nbtstat -A results will typically result in, "Host not found." In these cases, login to a machine on the same network/subnet as the target and perform the nbtstat -A test.

3. Attempt to ping the target machine from the PDQ console. Like performing an nslookup, this will show the IP of the target machine as returned from the DNS server.  

4. From the PDQ console machine, go to Start > Run > \\TARGET\ADMIN$. If you are unable to access the ADMIN$ of the target machine AND you receive the Target Name Mismatch error in PDQ, DNS is likely the culprit. When attempting to access the ADMIN$, you might see an error like this:

Or this:

5. Where the results of the above are inconclusive, you may need to log into the target machine physically or retrieve the IP information from the user (e.g. have them run ipconfig from a command prompt). Check the actual IP information against either an nslookup query or the DNS record on the DNS server.

DNS Troubleshooting from the DNS Server

If you don't have Reverse Lookup Zones, you can use the DNS PowerShell cmdlets on the DNS Server, and with a little bit of magic, you can see which computer DNS records have the same IP Address.

Get-DnsServerZone | %{Get-DnsServerResourceRecord -ZoneName $_.ZoneName} | ?{$_.HostName -eq "Computer Name"}

Get-DnsServerZone | %{Get-DnsServerResourceRecord -ZoneName $_.ZoneName} | ?{($_.RecordData).IPV4Address -eq "IP Address"}

Recommended Fixes

If you are using Microsoft DNS, try configuring automatic scavenging of stale records. If this has already been implemented and scavenging is taking place at an interval appropriate for your environment, it may help to create a scheduled task to periodically flush the local DNS cache of the PDQ server (ipconfig /flushdns) since name resolution will occur there first.

Scenario 1

The same IP Address is being used by multiple computers DNS records, and why a ping to the computer name is not a valid way to troubleshoot stale DNS, a ping provides no verification if the computer is the correct one.

Even if you had a Reverse Lookup Zone, it wouldn't matter since it's just going to point back to the DNS A records and this can't be used to verify which computer is truly on the IP Address.

This causes issues with SMB and Kerberos\NTLM authentication as PDQ software goes to connect to three different computers by their FDQN and it ends up connecting to the same computer.

Scenario 2

A single computer's DNS records contain multiple IP Addresses, which are active and being used by other computers.

A ping to the computer name can also be dependent on the ARP and DNS, once a cached entry times out or gets removed, next time you go to ping the computer name if a different IP Address gets returned at random by the DNS record, and that ping responds, now you will have both that DNS > IP Address and that IP Address > ARP, cached. Any subsequent pings to the computer name will go to the same destination, even if it's the incorrect one, this is due to Microsoft TCP/IP host name resolution order, SMB connections follow this order. This causes PDQ software to connect to the correct computer at random, if it gets the correct IP Address on the first try, it will succeed, but if it doesn't it will fail.

See Also

Article - A Healthy DNS Is Important for PDQ Deploy and Inventory

Blog - How to Set Up DNS

Blog - DNS is A Four Letter Word

Blog - Healthy DNS Will Keep PDQ Inventory and PDQ Deploy Hummin’ Along