DNS server not responding in Windows 11
First determine scope: test another device on the same network and test whether the PC can reach the router. Then verify configured DNS servers and use nslookup or Resolve-DnsName before resetting the whole network stack. This source-reviewed guide keeps the next step tied to the evidence you can collect safely.
Capture the exact symptom and scope first
First determine scope: test another device on the same network and test whether the PC can reach the router. Then verify configured DNS servers and use nslookup or Resolve-DnsName before resetting the whole network stack.
- Record the exact visible message and timestamp.
- Check whether the symptom affects one target or several.
- Preserve the relevant log, response or configuration state.
- Choose the next step only after identifying the affected layer.
Why this branch first: The exact error, timestamp and scope determine the next branch more safely than broad resets or deletes.
Choose a local-first diagnostic tool
Use a TroubleByte tool to inspect an error, DNS record or local system context before changing settings.
TroubleByte diagnostic path
Check another device and router path.
Inspect configured DNS servers.
Test a known name directly.
Change only the failed layer.
Original TroubleByte diagnostic map. It summarizes the cited troubleshooting order; it is not a vendor screenshot.
Use the symptom to choose the next branch
Does the evidence point to one affected target rather than a wider platform or network failure?
Keep the investigation narrow and correct the affected target or configuration only.
Stop making isolated changes and investigate the shared host, network, storage or platform layer.
Do you have the exact message, timestamp and relevant log or response evidence?
Use that evidence to follow the scoped diagnostic flow and verify one targeted change.
Capture it first; broad resets, deletes and policy changes are premature.
Original TroubleByte decision aid derived from the cited troubleshooting scope. It does not replace vendor documentation.
What this usually means
A DNS timeout can come from an unreachable configured DNS server, a wrong adapter configuration, local VPN or proxy behavior, a router/network outage, or a resolver that cannot answer a particular name. Microsoft’s DNS troubleshooting guidance starts by verifying client configuration and connectivity, then testing the resolver response. A DNS message alone does not prove that changing public DNS will fix the network.
What we verified from the source material
A DNS timeout can come from an unreachable configured DNS server, a wrong adapter configuration, local VPN or proxy behavior, a router/network outage, or a resolver that cannot answer a particular name. Microsoft’s DNS troubleshooting guidance starts by verifying client configuration and connectivity, then testing the resolver response. A DNS message alone does not prove that changing public DNS will fix the network.
Prerequisites and checks
Prepare first
- Record VPN, proxy and custom DNS settings before resetting anything.
- Use a known hostname when testing resolution.
- Do not change DNS on a managed work or school connection without approval.
Checks that prevent the wrong fix
- Test another device on the same network.
- Check the configured DNS server addresses and gateway.
- Use nslookup or Resolve-DnsName to distinguish timeout, negative answer and general connectivity failure.
Applies to
Solutions, in order
Capture the exact symptom and scope first
- Record the exact visible message and timestamp.
- Check whether the symptom affects one target or several.
- Preserve the relevant log, response or configuration state.
- Choose the next step only after identifying the affected layer.
Why this can work: The exact error, timestamp and scope determine the next branch more safely than broad resets or deletes.
Separate resolver failure from a wider network problem
- Test another device and router reachability.
- Inspect configured DNS server addresses.
- Run a targeted name-resolution test.
- Apply the smallest correction supported by the result, then retest.
Why this can work: Apply a narrow correction that follows the observed evidence, then verify the original symptom is gone.
How to know the fix actually worked
- Confirm a lookup succeeds with the intended resolver.
- Confirm normal browsing works after the evidence-based correction.
Do not count a temporary disappearance of the symptom as a confirmed fix if the problem normally returns after a restart, reconnect or several minutes of use.
When not to keep changing things
- If every device on the same network fails, stop changing the Windows PC and investigate the router, ISP or local DNS service first.
Escalation: Escalate with ipconfig /all output with private details removed, resolver test result, affected network and whether other devices fail.
Sources used for this record
Primary · checked Sep 25, 2026Microsoft — Troubleshooting DNS clientsOfficial documentation used to verify the scoped troubleshooting guidance.Corroborating · checked Sep 25, 2026Microsoft — Fix Wi-Fi connection issues in WindowsOfficial documentation used to verify the scoped troubleshooting guidance.Discuss this exact problem
Share what happened on your system, ask a focused follow-up question, or add evidence that may help someone with the same symptom. Community posts are separate from TroubleByte editorial verification.
Start a discussion
Revision history
Show 1 recorded revision
2026-09-25 — Created from current official documentation with scoped decisions, explicit stop conditions and an original TroubleByte diagnostic diagram.