DNS Troubleshooting

You want to understand how to troubleshoot host name resolution issues, and how it affects PDQ software.

Common DNS Resolution Errors

Common errors you might encounter include DNS resolution failures for the target machine, such as:

• 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

Troubleshooting process

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 running the following commands:

----

----

If 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 - Devices share IP address

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 device with multiple IP addresses

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.