IT Toolbox
Procedure

Solve a DNS problem on Windows

Diagnose Windows DNS resolution by separating IP configuration, DNS servers, suffixes, cache, the exact record being queried, and the network path, using Resolve-DnsName, nslookup, and targeted tracing when needed.

Networking

Objective

Diagnose Windows DNS resolution by separating IP configuration, DNS servers, suffixes, cache, the exact record being queried, and the network path, using Resolve-DnsName, nslookup, and targeted tracing when needed.

Prerequisites

  • Known addressing, VLAN, routing and firewall context for the affected flow.
  • A representative test client and the exact protocol or port involved.
  • Administrative access appropriate to the system being changed or diagnosed.
  • A clearly identified scope: affected users, systems, addresses, services and the time of the observed problem.
  • A maintenance or test window when the procedure can affect production traffic or availability.
  • A copy of the current configuration or other recovery material before any irreversible action.

Step-by-step procedure

1

Establish the baseline and scope

Before changing anything, reproduce the issue or document the requested change on a representative system. Record the affected users or services, exact time, current configuration, recent changes and a known-good comparison point. This baseline is the reference used to decide whether each later step improves the situation.

Expected result
  • The scope and current state are documented well enough to reproduce or verify the procedure.
2

IP configuration

Examine this diagnostic area: IP configuration. Use the narrowest reproducible test, compare the observed state with the documented or expected state, record timestamps and exact errors, and correlate the result with adjacent dependencies. Do not change several settings at once: the purpose of this step is to establish whether this area is healthy, misconfigured, unavailable, or simply not involved in the failure.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
3

DNS servers

Examine this diagnostic area: DNS servers. Use the narrowest reproducible test, compare the observed state with the documented or expected state, record timestamps and exact errors, and correlate the result with adjacent dependencies. Do not change several settings at once: the purpose of this step is to establish whether this area is healthy, misconfigured, unavailable, or simply not involved in the failure.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
4

Suffixes

Examine this diagnostic area: suffixes. Use the narrowest reproducible test, compare the observed state with the documented or expected state, record timestamps and exact errors, and correlate the result with adjacent dependencies. Do not change several settings at once: the purpose of this step is to establish whether this area is healthy, misconfigured, unavailable, or simply not involved in the failure.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
5

Cache

Examine this diagnostic area: cache. Use the narrowest reproducible test, compare the observed state with the documented or expected state, record timestamps and exact errors, and correlate the result with adjacent dependencies. Do not change several settings at once: the purpose of this step is to establish whether this area is healthy, misconfigured, unavailable, or simply not involved in the failure.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
6

The exact record being queried

Examine this diagnostic area: the exact record being queried. Use the narrowest reproducible test, compare the observed state with the documented or expected state, record timestamps and exact errors, and correlate the result with adjacent dependencies. Do not change several settings at once: the purpose of this step is to establish whether this area is healthy, misconfigured, unavailable, or simply not involved in the failure.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
7

The network path

Examine this diagnostic area: the network path. Use the narrowest reproducible test, compare the observed state with the documented or expected state, record timestamps and exact errors, and correlate the result with adjacent dependencies. Do not change several settings at once: the purpose of this step is to establish whether this area is healthy, misconfigured, unavailable, or simply not involved in the failure.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
8

Resolve-DnsName

Examine this diagnostic area: Resolve-DnsName. Use the narrowest reproducible test, compare the observed state with the documented or expected state, record timestamps and exact errors, and correlate the result with adjacent dependencies. Do not change several settings at once: the purpose of this step is to establish whether this area is healthy, misconfigured, unavailable, or simply not involved in the failure.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
9

Nslookup

Examine this diagnostic area: nslookup. Use the narrowest reproducible test, compare the observed state with the documented or expected state, record timestamps and exact errors, and correlate the result with adjacent dependencies. Do not change several settings at once: the purpose of this step is to establish whether this area is healthy, misconfigured, unavailable, or simply not involved in the failure.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
10

Validate the complete service

Repeat the original user, system or application workflow from the real source and verify the complete result, not only one command or one local check. Confirm that logs and monitoring show the expected behavior and that no temporary debug, bypass, test account, rule or maintenance setting remains enabled.

Expected result
  • The end-to-end service works or the remaining failure is isolated to a clearly identified component.

Technical commands from the original procedure

These technical blocks are preserved byte-for-byte from the historical procedure and kept in their original order. Review names, addresses, paths and parameters before use.

Technical block 1
ipconfig /all
Technical block 2
Get-DnsClientServerAddress -AddressFamily IPv4
Technical block 3
Get-DnsClient | Select InterfaceAlias,ConnectionSpecificSuffix,RegisterThisConnectionsAddress
Technical block 4
Resolve-DnsName '<FQDN>.' -DnsOnly
Technical block 5
nslookup <FQDN>.
Technical block 6
Resolve-DnsName '<FQDN>.' -Type A
Technical block 7
Resolve-DnsName '<FQDN>.' -Server <DNS-IP-1> -DnsOnly
Technical block 8
Resolve-DnsName '<FQDN>.' -Server <DNS-IP-2> -DnsOnly
Technical block 9
nslookup <FQDN>. <DNS-IP-1>
Technical block 10
Resolve-DnsName '<SHORTNAME>'
Technical block 11
Resolve-DnsName '<FQDN>.'
Technical block 12
Get-DnsClientNrptPolicy -ErrorAction SilentlyContinue
Technical block 13
ipconfig /displaydns
Technical block 14
ipconfig /flushdns
Technical block 15
Clear-DnsClientCache
Technical block 16
Resolve-DnsName '<FQDN>.' -DnsOnly
Technical block 17
ping <DNS-IP>
Technical block 18
Test-NetConnection <DNS-IP> -Port 53
Technical block 19
route print
Technical block 20
(Measure-Command {Resolve-DnsName -Name '<FQDN>' -Server <DNS-IP> -DnsOnly}).TotalMilliseconds
Technical block 21
Get-Content C:WindowsSystem32driversetchosts
Technical block 22
Resolve-DnsName '<FQDN>.'
Technical block 23
netsh trace start capture=yes tracefile=C:Tempdns-client.etl
Technical block 24
ipconfig /flushdns
Technical block 25
nslookup <FQDN>.
Technical block 26
netsh trace stop

Validation

The procedure is validated when:

  • The original symptom or change request has been tested end to end.
  • The effective configuration matches the intended design and no unexplained error remains in the relevant logs.
  • Temporary troubleshooting controls have been removed and monitoring remains normal.
  • The result, evidence and any follow-up action are documented.

Rollback

  • Restore the configuration, policy, binding, route, credential assignment or service state recorded in the baseline when the change does not meet its success criteria.
  • Remove temporary rules, test objects and diagnostic settings that were introduced only for the procedure.
  • After rollback, repeat the minimum health checks to confirm that the previous service level has been restored.

Troubleshooting / common errors

  • A successful ping does not prove that the application protocol is allowed or listening.
  • When packet and policy evidence disagree, capture the same test flow at more than one point in the path.
  • If the result changes between tests, compare source, destination, identity, time and policy context before changing additional settings.
  • If a command succeeds but the application still fails, continue at the next protocol or application layer instead of widening access.
  • If the expected evidence is missing, verify that logging, auditing and the test path actually cover the failing component.
  • If the change does not improve the measured symptom, restore the previous state and reassess the working hypothesis.

Official and vendor references preserved from the original procedure

♡ 0