Diagnose Windows DNS Client Name-Resolution Failures

Before you begin

Applicable to supported Windows Server/client environments where the named role or feature is installed. Run read-only checks first from an elevated PowerShell or Command Prompt as appropriate. Replace example hostnames, domain names, addresses, ports and paths with values from the affected environment. Record the exact error, timestamp, OS build and scope of impact.

Production safety: obtain change approval and a verified backup before modifying AD DS, DNS, DHCP, firewall, IIS, storage or Hyper-V configuration. Ensure console/out-of-band access before network or remote-access changes.

Symptoms and likely root cause

Clients reach a server by IP but not by hostname; short names and FQDNs may behave differently.

Client DNS list, suffix search, NRPT/VPN policy, cached answers or an incorrect A/AAAA record.

Diagnostic commands

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientGlobalSetting
nslookup app01.corp.example.com
nslookup app01.corp.example.com 10.20.0.10
Resolve-DnsName app01.corp.example.com -Server 10.20.0.10 -DnsOnly

Run the commands in order and save the complete output. The commands above are intended to establish the failing layer before a configuration change is attempted.

How to interpret the results

The responding DNS server must be the intended internal resolver and the answer must contain the expected A/AAAA address. Test the FQDN with a trailing dot to avoid suffix appending: nslookup app01.corp.example.com. If FQDN works but short name fails, inspect the connection-specific suffix and suffix search list.

Practical correction

Correct the active adapter/VPN DNS server list or suffix configuration. If only one record is wrong, correct that record in the authoritative zone after checking replication and TTL. Flush the cache only after capturing the old answer: ipconfig /flushdns.

Make one change at a time. Re-run the failed diagnostic after each change so the cause-and-effect relationship is clear.

Fallback and recovery

If the result worsens, restore the previous adapter DNS/suffix values and original DNS record/TTL. Do not add public DNS directly to a domain-joined client as a workaround.

Verification checklist

Success: repeated queries from the affected subnet return the intended IP, and the application opens by FQDN and expected short name. nslookup queries DNS directly; compare it with Resolve-DnsName and the actual application.

• Repeat the original failing operation from the affected client/user or service.
• Test from a second approved endpoint or subnet where relevant.
• Review the relevant event log/IIS log after the fix.
• Record the change, actual result and any remaining limitation.

Frequently asked question

Does FQDN work but short name fail? Check suffix search. Does ping prove DNS is healthy? No; it can use cached resolution.

Official technical reference

Microsoft Learn — troubleshoot dns client

Use the official documentation for exact version support, prerequisites and any procedure that differs between Windows Server releases.

Technician field note

This runbook describes a controlled diagnostic path; it is not a universal guarantee that every environment has the same cause. If evidence does not match the expected result, stop and investigate rather than applying unrelated fixes. Do not mark the incident resolved until the original symptom is verified as cleared.