Fix “DNS Server Isn’t Responding” and Other DNS Errors Fast

Fix “DNS Server Isn’t Responding” and Other DNS Errors Fast

When a browser says “DNS server isn’t responding,” it isn’t claiming your internet is down; it’s reporting that the address book for the internet didn’t reply or couldn’t complete the lookup in time.

Most cases trace back to an unhealthy resolver, a stale cache, a firewall blocking port 53, or an upstream outage at your provider. The upside: you can isolate which one it is quickly with a few focused checks instead of guessing.

Below we’ll walk through fast fixes and deeper diagnostics for Windows, macOS, and Linux—plus what to gather when the problem is on your ISP or a domain’s nameservers. Keep a terminal or Command Prompt handy.

How DNS Works in 60 Seconds

DNS translates a domain into an IP address so your device knows where to connect. Your device queries a recursive resolver (often on your router, from your ISP, or a public service). That resolver follows referrals from the root to a TLD to the domain’s authoritative nameservers, caches the answer, and returns it. Queries are typically UDP on port 53 with TCP fallback when responses don’t fit or are truncated; modern stacks may also use encrypted transports like DoH (HTTPS) or DoT (TLS).

Common Failure Modes in Plain Terms

Timeout means no answer—common with blocked UDP 53, packet loss, or an offline resolver. SERVFAIL means the resolver tried but failed (think upstream errors or DNSSEC validation problems). NXDOMAIN means the name truly doesn’t exist. REFUSED means the server declines to answer (policy, ACL, rate limit). Those codes steer your next step.

Quick Fixes You Should Try First

Work through these in order and stop when things recover:

If quick fixes don’t help, the steps below pinpoint where the chain breaks.

Step-by-Step Diagnostics

Use this sequence to compare connectivity, the local stack, the resolver, and the domain’s authorities so you can see precisely where resolution fails before changing settings.

Confirm the Symptom

Compare IP connectivity versus DNS resolution. If ping 1.1.1.1 works but ping example.com fails, it’s DNS. Run nslookup example.com or dig example.com and note the response code (NOERROR, NXDOMAIN, SERVFAIL) and the “Server:” it queried.

Test the Resolver Directly

Query a known-good resolver explicitly. With nslookup, enter nslookup, then server 8.8.8.8, then example.com. With dig, try dig @1.1.1.1 example.com. If a public resolver answers but your default doesn’t, your router/ISP resolver is unhealthy or blocked. If UDP is blocked or truncated, dig +tcp example.com may succeed; that points to a firewall dropping UDP 53 or large EDNS0 responses.

Clear Caches and Check the Hosts File

Flush the OS cache (commands above) and clear browser caches. Inspect the hosts file for overrides like 0.0.0.0 or outdated IPs: Windows C:\Windows\System32\drivers\etc\hosts; macOS/Linux /etc/hosts. Remove stale entries and retest.

Inspect Firewalls and Security Suites

Personal firewalls, endpoint protection, and router “DNS filtering” features can intercept or block lookups. Ensure outbound UDP and TCP 53 are allowed. If you rely on encrypted DNS (DoH/DoT) at the OS or browser level, make sure those endpoints aren’t blocked by upstream filtering.

Validate Router and ISP DNS

Routers often proxy DNS and forward to ISP resolvers. A firmware hiccup or ISP outage can cause timeouts. Bypass the router’s DNS by setting public resolvers directly on the client; if that works, leave the client configured that way or change the router’s WAN DNS to the same public pair. If nothing answers, contact your ISP with the resolver IPs that fail, the time window, and sample query outputs.

Is It One Site or All Sites?

A single failing domain is diagnostic gold. NXDOMAIN across multiple resolvers means the name is gone or a typo. SERVFAIL on multiple resolvers often suggests broken DNSSEC, lame delegation, or oversized responses getting dropped by middleboxes—try dig +dnssec to see if validation is involved. If only your ISP resolver fails while public resolvers work, it’s an upstream cache or policy issue—switch resolvers and notify the provider.

Check Authoritative Nameservers

If a domain you manage won’t resolve, query an authority directly: dig @ns1.your-dns-host.tld yourdomain.tld A. Look for mismatched NS/glue, missing A/AAAA for nameservers, or disallowed CNAMEs at the zone apex. If DNSSEC is enabled, verify DS and DNSKEY alignment; a wrong DS record guarantees validation failure and client-side SERVFAIL.

Account for Encrypted DNS

Browsers can use secure DNS independent of OS resolver settings when the feature is enabled. In Chrome and Firefox, temporarily disable “Use secure DNS”/DoH and retry; if resolution then works, your DoH/DoT endpoint was unreachable or blocked. Consider setting a system-wide encrypted resolver so app behavior aligns across the device.

Fixes by Platform

The exact clicks and commands differ by operating system, but the goals are the same: refresh the stack, point to healthy resolvers, and remove stale or conflicting state before retesting.

Windows

Open an elevated Command Prompt or PowerShell and run ipconfig /flushdns, then netsh winsock reset and reboot. In Network Connections → Adapter → IPv4/IPv6, set DNS to known-good resolvers. Confirm that DHCP isn’t feeding a dead resolver via ipconfig /all.

macOS

System Settings → Network → your interface → Details → DNS lets you add resolver IPs; apply and test. Run scutil --dns to inspect active resolvers and sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder to clear caches.

Linux

With systemd-resolved, run resolvectl status to see per-link DNS and sudo resolvectl flush-caches to clear. If you manage /etc/resolv.conf directly, ensure it points to reachable resolvers and that only one manager writes it. With NetworkManager, add DNS IPs in your connection profile and reconnect.

When It’s Not You: ISP or Upstream Outage

If multiple devices fail to resolve and public resolvers work, it’s your ISP DNS. Leave clients on public resolvers and open a ticket including resolver IPs, error codes, and timestamps. If both public and ISP resolvers fail for a specific domain, contact the domain’s DNS host; provide the domain, record type, response code, and a traceroute to the nameserver if reachable.

Prevent Recurrence

Set two diverse resolvers (different networks/vendors) on every device. Where feasible, use encrypted DNS. Keep router firmware updated. Avoid hardcoding DNS on guest networks that captive portals expect to intercept. For managed domains, enable health checks and change logs, keep TTLs sensible (300–3600s), and if you use anycast services, ensure nameserver IP diversity and monitoring.

Troubleshooting Checklist You Can Paste into a Ticket

Include: 1) your OS and router model/firmware, 2) resolver IP(s) and whether the issue reproduces with 1.1.1.1/8.8.8.8/9.9.9.9, 3) exact errors and timestamps, 4) sample nslookup or dig outputs (include +tcp and +dnssec runs), 5) VPN/proxy status, 6) whether another network works. This shortens time to resolution dramatically.

Fix DNS Errors Fast (FAQ)

Your device asked a resolver for an answer, but the resolver didn’t reply in time or couldn’t complete the lookup, so the browser can’t map the domain to an IP and the connection never starts.

Reach a known IP (for example, 1.1.1.1) and then a domain; if the IP works but the name fails, it’s DNS; to see your current public address for comparison, check What Is My IP in a working browser.

Use well-known anycast services like 1.1.1.1/1.0.0.1, 8.8.8.8/8.8.4.4, or 9.9.9.9/149.112.112.112; set both addresses, test, and keep them if stability improves.

Yes; flushing only removes stale entries so the next query fetches fresh data; do it after moving networks, changing VPNs, or when one site works on a phone but not on your laptop.

On Windows or macOS, open Terminal/Command Prompt and run nslookup example.com; on Linux, use dig example.com; if you need a second vantage point, try a simple external DNS Lookup.

That often points to domain-specific issues like NXDOMAIN from a removal or typo, SERVFAIL from bad DNSSEC, or a nameserver outage; compare results across multiple resolvers and check TTLs before assuming it’s your device.

No; DNS works over IPv4 alone, but if your device prefers IPv6 and the v6 path is misconfigured, lookups can stall; verify reachability with an IPv6 Test and either fix the v6 path or disable it temporarily while you troubleshoot.

Provide failing resolver IPs, timestamps, two or three dig/nslookup outputs showing codes like SERVFAIL or timeouts, and note whether public resolvers succeed; ask for escalation to their DNS operations.