When Windows throws “DNS server not responding” or a Linux box starts timing out on every lookup, the resolver itself is rarely the broken piece. Nine times out of ten the fault sits between your NIC and port 53: a stale cache entry, a VPN hijacking DNS traffic, an adapter still holding a DHCP lease from a network you left an hour ago.
Confirm the fault with ping 8.8.8.8 first: if ICMP replies come back but nslookup times out, you have a name resolution problem and not a connectivity problem, and every fix below narrows down from there. That single test saves you from resetting a router that was never at fault.
The steps here are the same ones we run against production networks at PacketTools, where the network tools log nothing and store nothing. You will finish with a working resolver and a repeatable way to prove it.
What the Error Actually Indicates
The message means your stub resolver sent a query and got nothing back before the timeout expired. It says nothing about whether the DNS server is healthy, only that no answer arrived at your machine within the window.
How DNS Resolution Turns Domain Names Into IP Addresses
Your application hands a hostname to the OS stub resolver, which forwards it to the configured recursive resolver. That resolver walks the domain name system from root to TLD to authoritative nameserver, then returns an A or AAAA record with the IP address.
Every hop in that chain has its own timeout. A slow authoritative server 60 ms away can surface on your desktop as a dead local resolver.
Why a Timeout Does Not Always Mean the Resolver Is Down
Windows gives up on a DNS query fast, and a UDP packet dropped by a firewall produces the exact same silence as a crashed server. Corporate VPN clients intercept port 53 and route it to an internal resolver that your split-tunnel config never reaches.
A DNS outage at the provider is possible. An overloaded resolver under load or a broken DNSSEC chain returns SERVFAIL, which is a different failure with a different fix.
Symptoms That Separate Local, Network-Wide, and Domain-Specific Failures
| Symptom | Likely scope |
|---|---|
| One host fails, others on the same LAN resolve fine | Local cache, adapter, or VPN |
| Every device on the LAN fails | Router forwarder or ISP DNS outage |
| One domain fails everywhere, others resolve | Authoritative zone or delegation |
| IPv4 resolves, IPv6 hostnames fail | Broken AAAA path on dual stack |
Map the symptom to the scope before you touch a single setting. Changing resolver addresses on a laptop does nothing when the zone’s nameservers are unreachable.
Isolate the Fault Before Changing Settings
Spend three minutes proving where the failure lives and you avoid an hour of blind config changes. The goal is to answer two questions: does raw IP connectivity work, and does the configured resolver answer direct queries?
Test Another Browser, Device, and Network Path
Open the same URL in a second web browser. Chrome and Safari both run their own DNS-over-HTTPS stack and browser cache, so a failure in one and success in the other points at the browser rather than the network connection.
Then try a second device on the same Wi-Fi. Two devices failing identically moves the fault upstream to the router or the ISP.
Compare Wi-Fi, Ethernet, VPN, and Mobile Data Results
Tether to mobile data and retest. Resolution working over a hotspot while the LAN fails isolates the problem to your local network connections or ISP DNS.
Disconnect the VPN and test again. VPN clients push their own resolvers and rewrite /etc/resolv.conf or the Windows interface metric, and a stale tunnel leaves you pointed at an unreachable internal server. The same applies to a system proxy holding a dead PAC file.
Use Ping, Nslookup, and Dig to Test the Configured Resolver
Ping the resolver’s IP directly. If ICMP replies but queries do not, port 53 is filtered somewhere between you and it.
ping 8.8.8.8
nslookup packettools.com 192.168.1.1
dig @192.168.1.1 packettools.com +shortSubstitute your actual resolver address. A timeout means unreachable; SERVFAIL means it answered but failed upstream; NXDOMAIN means it answered that the name does not exist. Our ping test gives you an outside-in reference point when you need to compare against a path you do not control.
Check Whether the Failure Is Limited to One Domain
Query a known-good domain and the failing one against the same resolver. One domain failing while everything else resolves is a zone problem, and the fix belongs to whoever runs the nameservers.
Repair DNS Resolution on Windows
Start with the cache and the DHCP lease, since those two account for most Windows 10 and Windows 11 DNS errors that clear without a reboot. Work down to adapter state and security software only when the cheap fixes fail.
Flush the Local Cache and Renew DHCP Configuration
Open Command Prompt as administrator and run these in order:
ipconfig /flushdns
ipconfig /release
ipconfig /renew
ipconfig /registerdns
netsh winsock reset
netsh int ip resetThe last two require a reboot. ipconfig /flushdns clears the DNS cache; the release and renew pair forces a fresh DHCP lease, which matters when the adapter is still holding DNS server addresses from a previous network.
Confirm the result with ipconfig /all and read the DNS Servers line. On domain-joined machines, check whether Group Policy is pushing a resolver that overrides your edit.
Set and Validate IPv4 and IPv6 Resolver Addresses
Press Win+R, run ncpa.cpl, right-click the active adapter, choose Properties, then Internet Protocol Version 4 (TCP/IPv4). Set a preferred DNS server and an alternate DNS server, for example 1.1.1.1 and 8.8.8.8.
Repeat for Internet Protocol Version 6 (TCP/IPv6) or the stack keeps querying an unreachable AAAA path. Some Windows builds resolve the error only after you disable IPv6 on the adapter, though a working IPv6 resolver is the better outcome.
Validate before you close the dialog:
nslookup packettools.com 1.1.1.1
Resolve-DnsName packettools.com -Server 8.8.8.8Inspect Adapters, Drivers, and Conflicting Virtual Interfaces
Open Device Manager and check the network adapter for a warning icon. Roll back or reinstall the network adapter driver when the error appeared right after a Windows Update.
Virtual interfaces cause more grief than physical ones. Hyper-V switches, VMware adapters, and leftover VPN TAP devices sit at a lower interface metric and win the DNS race:
Get-DnsClientServerAddress
Get-NetIPInterface | Sort-Object InterfaceMetricDisable every unused connection under Change adapter settings in Network and Sharing Center.
Use Safe Mode and Security Controls to Identify Local Interference
Boot into Safe Mode with Networking. Resolution working there and failing in a normal boot points at a third-party service, and antivirus software with a web-filtering module is the usual candidate.
Temporarily disable the firewall and the antivirus DNS protection layer, retest, then re-enable immediately. Windows Defender rarely blocks port 53 outright, so treat a Defender-only machine as a lower-probability cause and keep looking at drivers and virtual adapters.
Repair DNS Resolution on Linux and macOS
On Linux, find out what is answering queries before you edit anything, because /etc/resolv.conf is a symlink to a stub on most modern distributions. On Mac, the fix path runs through mDNSResponder and the per-interface resolver order.
Inspect Resolver Configuration and systemd-resolved Status
Run these from a terminal:
resolvectl status
systemctl status systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.confA nameserver 127.0.0.53 line means systemd-resolved is the stub and the real upstreams appear in resolvectl status per link. Editing /etc/resolv.conf directly on that setup gets overwritten on the next network event.
On macOS, scutil --dns prints the resolver list in priority order along with the search domains attached to each interface.
Clear Local Caches and Restart Network Services
sudo resolvectl flush-caches
sudo systemctl restart systemd-resolved
sudo systemctl restart NetworkManagerOlder systems use sudo systemd-resolve --flush-caches or an nscd restart. If dnsmasq is running locally, flushing systemd’s cache changes nothing, so check with systemctl status dnsmasq first.
On macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Toggle Wi-Fi off and on afterward, and run Wireless Diagnostics when the interface keeps dropping.
Check VPN, NetworkManager, and DHCP-Supplied DNS
DHCP-supplied resolvers overwrite static entries on every lease renewal. Pin them per connection:
nmcli con show
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con up "Wired connection 1"Bring the VPN down and rerun resolvectl status. A tunnel that exits uncleanly leaves a routing domain (~.) claiming all queries for a resolver that no longer answers. Reboot the router and modem only after ruling out the host, and verify the router configuration is not still forwarding to a dead upstream.
Use Terminal Diagnostics to Confirm the Active Resolver
dig packettools.com +short
dig @1.1.1.1 packettools.com
resolvectl query packettools.comdig bypasses nsswitch and talks to the resolver in /etc/resolv.conf, while resolvectl query follows the same path glibc applications use. When those two disagree, the problem is in nsswitch or the systemd-resolved link config, not the upstream server. Watch the wire with sudo tcpdump -i any port 53 to see whether queries leave the host at all. For a wider methodology across hosts and zones, our guide to network troubleshooting covers the same ordering applied to routing and latency faults.
Validate Resolvers and Investigate External DNS Problems
Once the host is clean, prove the answer is correct from outside your network. Local tools tell you what your resolver returned; they cannot tell you what the authoritative nameservers are publishing.
When to Test Google DNS, Cloudflare, or Another Public Resolver
Query a public DNS resolver directly and compare. Google DNS runs on 8.8.8.8 and 8.8.4.4, Cloudflare on 1.1.1.1, and Quad9 on 9.9.9.9 with malicious-domain filtering built in.
dig @8.8.8.8 packettools.com
dig @1.1.1.1 packettools.comBoth answering while your configured resolver times out confirms an ISP DNS or router forwarder failure. Setting Cloudflare as primary and Google as secondary, as this DNS troubleshooting walkthrough recommends, covers most single-provider failure scenarios.
Check Records, Delegation, and Propagation From Outside the Network
Pull the delegation and compare it against what the zone serves:
dig NS packettools.com +trace
dig @ns1.example-provider.net packettools.com SOA
dig MX packettools.comMismatched serials between nameservers mean zone transfers are failing quietly. A DNS propagation checker shows what resolvers in different regions currently hold, which is the fastest way to separate a stale TTL from a genuine record error. For a full sweep of DNS, MX record, SPF, DKIM, DMARC, blacklist, and SSL checks in one pass, the SuperTool runs them together.
Identify DNS Hijacking, Secure DNS, and DNS-over-HTTPS Mismatches
Compare the A record your resolver returns against 1.1.1.1. Different IP addresses for the same hostname signal DNS hijacking, a captive portal, or an ISP redirecting NXDOMAIN responses to an ad page.
Secure DNS settings in Chrome and Edge send queries over DNS-over-HTTPS to a resolver you never configured at the OS level, so browser lookups succeed while nslookup fails. Disable DoH in the browser when troubleshooting to keep both paths on the same resolver. Enterprise environments with DNS filtering should verify the policy allows the domain before assuming a fault. Related hardening topics live in our cybersecurity coverage.
Know When the Issue Belongs to the ISP, DNS Provider, or Domain Owner
Escalate to the ISP when public resolvers answer and theirs does not, and confirm from a mobile hotspot first so you arrive with evidence. The DNS provider owns it when the authoritative servers return SERVFAIL or refuse queries. The domain owner owns it when the records are simply wrong or the registrar delegation points at retired nameservers. Microsoft 365 tenants with mail routing failures should validate the required records with an M365 domain check before opening a ticket.
A Repeatable Path From DNS Failure to Verified Recovery
Run the same sequence every time and a DNS resolution failure stops being guesswork. Ping an IP to prove the internet connection, query the configured resolver directly, flush the cache and renew DHCP, then set a known-good resolver on both IPv4 and IPv6.
When the host checks out, move outward: compare answers from 1.1.1.1 and 8.8.8.8, trace the delegation, and check propagation from outside your network before deciding whose problem it is.
Close the loop with a verification query rather than a browser reload. dig packettools.com +short returning an address, plus a second lookup against a public resolver returning the same address, is proof the fix held. Record which step resolved the DNS error so the next incident on that network starts at step three instead of step one, and keep the DNS troubleshooting workflow handy for the ones that do not clear in five minutes.
Leave a Reply