DNS Server Not Responding: Complete Troubleshooting Guide

A "DNS server not responding" error means your operating system sent a resolution query to a DNS resolver and received no answer within the timeout window — so the browser never obtained the IP address needed to open a TCP connection. The result is a broken page load even when your physical network link is fully operational. The root cause can sit anywhere in the resolution chain: your local stub resolver, the recursive resolver at your ISP, an upstream authoritative server, or a misconfigured network device between you and any of them.

This guide walks through every layer of that chain — from a 30-second router reboot to low-level driver replacement — with exact commands for Windows, macOS, and Linux, plus a comparison of public resolvers and a decision matrix to help you isolate the fault quickly.

What Actually Happens During DNS Resolution

Before fixing the error, understanding the resolution path prevents wasted effort. When you type example.com into a browser:

1. The OS checks its local DNS cache (and the hosts file).
2. If no cached record exists, the stub resolver forwards the query to the recursive resolver configured on the network interface (usually your router or an ISP-assigned server).
3. The recursive resolver walks the DNS hierarchy — root servers, TLD nameservers, authoritative nameservers — and returns the final A or AAAA record.
4. The OS caches the result for the duration of the record's TTL and passes the IP to the browser.

A "not responding" error typically fires at step 2 or 3. The stub resolver sent a UDP packet to port 53 and got silence. That silence has a surprisingly large number of causes.

Root Causes of the DNS Server Not Responding Error

DNS Resolver-Side Failures

• The configured recursive resolver is temporarily overloaded or offline.
• Your ISP's DNS infrastructure is under a DDoS attack or undergoing maintenance.
• The resolver's IP address has changed but your device still holds the old value.

Local Network and Hardware Problems

• Router firmware bugs that corrupt DNS relay (common in consumer-grade devices after long uptimes).
• A DHCP lease that pushed a stale or invalid DNS server address.
• A faulty Ethernet cable or a degraded Wi-Fi signal causing packet loss specifically on UDP port 53.

Host-Level Misconfigurations

• A corrupted or poisoned local DNS cache containing stale negative responses.
• A manually entered DNS address that is wrong or no longer reachable.
• A hosts file entry that conflicts with the expected DNS response.

Security Software Interference

• Firewalls or endpoint security tools that block outbound UDP/TCP port 53 or intercept DNS queries for inspection and then drop them.
• VPN clients that redirect DNS traffic through a tunnel endpoint that is currently unreachable.
• Parental control software that acts as a local DNS proxy and crashes silently.

Driver and OS-Level Issues

• An outdated or corrupted NIC driver that mishandles UDP datagrams.
• The Windows DNS Client service (Dnscache) in a hung state.
• A macOS mDNSResponder process that has consumed excessive memory and stopped responding.

Step-by-Step Fixes: Ordered by Effort and Likelihood

Work through these in order. Each step takes less than five minutes and eliminates a specific layer of the problem.

Step 1: Verify the Scope of the Problem First

Before touching any settings, run a quick diagnostic to confirm DNS is actually the failure point and not general connectivity:

# Windows — ping a known IP directly (bypasses DNS entirely)
ping 8.8.8.8

# Windows — attempt a DNS lookup explicitly
nslookup example.com

# macOS / Linux
ping -c 4 8.8.8.8
dig example.com

If ping 8.8.8.8 succeeds but nslookup example.com fails, DNS resolution is definitively the problem. If ping 8.8.8.8 also fails, the issue is deeper — likely routing or physical connectivity — and DNS is a symptom, not the cause.

Step 2: Restart Your Router and Modem

A power cycle clears the router's internal DNS relay cache, resets DHCP leases, and re-establishes the WAN connection with fresh DNS server assignments from your ISP.

1. Unplug the power cable from both the modem and the router.
2. Wait a full 30 seconds (capacitors need time to discharge).
3. Power the modem on first; wait for it to fully synchronize (solid WAN light).
4. Power the router on second; wait for it to complete its boot sequence.
5. Reconnect your device and re-run the nslookup test from Step 1.

Edge case: If your router has been running for weeks without a reboot, its DNS relay (dnsmasq or similar) may have a full cache or a memory leak. Some ISP-provided routers have known bugs where the DNS relay stops forwarding queries after a certain uptime threshold. A reboot is the fastest fix.

Step 3: Flush the Local DNS Cache

Stale or corrupted cache entries cause the OS to return bad results or generate lookup failures before a query even leaves the machine.

Windows:

ipconfig /flushdns

You should see: Successfully flushed the DNS Resolver Cache.

macOS (version-specific — use the correct command for your OS):

# macOS Ventura, Monterey, Big Sur, Catalina
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Mojave and earlier
sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches
# Verify the cache was cleared
sudo systemd-resolve --statistics | grep "Current Cache Size"

Linux (nscd):

sudo service nscd restart

Step 4: Change to a Reliable Public DNS Resolver

If your ISP's DNS resolver is the problem, switching to a well-maintained public resolver is the fastest workaround. The table below compares the most widely used options:

Cloudflare 1.1.1.1 consistently measures the lowest global average query latency in independent benchmarks. Quad9 is the better choice if you want passive malware-domain blocking without managing a separate DNS filter.

Changing DNS on Windows 10/11:

1. Open Settings > Network & Internet > Change adapter options.
2. Right-click your active adapter and select Properties.
3. Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
4. Select Use the following DNS server addresses.
5. Enter your chosen primary and secondary resolver IPs.
6. Click OK, then run ipconfig /flushdns to clear stale cache entries.

For IPv6 networks, repeat the process for Internet Protocol Version 6 (TCP/IPv6) using the resolver's IPv6 addresses (e.g., Cloudflare: 2606:4700:4700::1111 and 2606:4700:4700::1001).

Changing DNS on macOS:

1. Open System Settings > Network.
2. Select your active connection and click Details.
3. Go to the DNS tab.
4. Remove existing entries with the – button, then add your chosen resolver IPs with +.
5. Click OK and Apply.

Changing DNS on Linux (NetworkManager):

# Edit the connection (replace "Wired connection 1" with your connection name)
nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"

Step 5: Restart the DNS Client Service (Windows)

The Windows DNS Client service (Dnscache) caches resolved names and manages the stub resolver. If it enters a hung state, all DNS queries fail silently.

net stop dnscache
net start dnscache

Alternatively, via the Services console: press Win + R, type services.msc, locate DNS Client, right-click, and select Restart. Note that on some Windows 11 builds the restart option is greyed out in the GUI — use the command-line method instead.

Step 6: Disable Firewall or Security Software Temporarily

Third-party firewalls and endpoint protection suites sometimes intercept DNS traffic for inspection and, due to a rule conflict or engine bug, drop the packets entirely.

Windows Defender Firewall (temporary test only):

netsh advfirewall set allprofiles state off

Re-enable immediately after testing:

netsh advfirewall set allprofiles state on

macOS:

Navigate to System Settings > Privacy & Security > Firewall and toggle it off for testing purposes.

If disabling the firewall resolves the issue, do not leave it disabled. Instead, open the firewall's rule editor and look for rules blocking outbound traffic on UDP port 53 and TCP port 53. Add explicit allow rules for your chosen DNS resolver IPs.

VPN clients deserve special attention here. Many VPN applications install a local DNS proxy on 127.0.0.1:53 and redirect all queries through the tunnel. If the VPN server is unreachable, every DNS query fails. Disconnect the VPN, test DNS, then reconnect and check the VPN client's DNS leak settings.

Step 7: Try a Different Browser

Certain browser extensions — particularly ad blockers, privacy tools, and security plugins — intercept DNS-over-HTTPS (DoH) queries or modify the system resolver behavior. If DNS works in one browser but not another, the issue is extension-level, not OS-level.

Test in a private/incognito window first (extensions are usually disabled). If that resolves it, disable extensions one by one to identify the culprit. If the problem persists across all browsers, the fault is at the OS or network layer.

Step 8: Update or Roll Back Network Drivers

A corrupted NIC driver can cause erratic UDP packet handling, which manifests as intermittent DNS failures even when TCP connections work.

Windows — update via Device Manager:

1. Press Win + X and select Device Manager.
2. Expand Network adapters.
3. Right-click your adapter and select Update driver > Search automatically for drivers.
4. Restart after installation.

Windows — roll back a recently updated driver:

If the DNS error started immediately after a Windows Update, the new driver may be the regression. In Device Manager, right-click the adapter, select Properties > Driver > Roll Back Driver.

macOS: NIC drivers are bundled with macOS. Apply all pending system updates via System Settings > General > Software Update.

Linux:

# Check current driver module
lspci -k | grep -A 3 "Network controller"

# Update kernel (which includes driver updates) on Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic

Step 9: Check Physical Network Connections

If you are on a wired connection, a degraded Ethernet cable causes intermittent packet loss that disproportionately affects UDP-based protocols like DNS (which has no built-in retransmission at the application layer).

• Reseat both ends of the Ethernet cable.
• Swap the cable with a known-good one.
• Test a different port on the router or switch.
• Check the NIC's link indicator LEDs — a solid green or amber light confirms physical link; a blinking or absent light indicates a layer-1 problem.

Step 10: Run the Windows Network Troubleshooter

Windows includes an automated diagnostic that can detect and fix common DNS misconfigurations, including resetting the DNS client and clearing the cache.

Navigate to Settings > System > Troubleshoot > Other troubleshooters > Internet Connections and run the wizard. It will attempt automatic repairs and report what it found. While it does not catch every scenario, it is a useful sanity check that takes under a minute.

Step 11: Check and Edit the Hosts File

A corrupted or maliciously modified hosts file can override DNS for specific domains, causing resolution failures that look identical to a DNS server error.

Windows — open with elevated privileges:

notepad C:WindowsSystem32driversetchosts

macOS / Linux:

sudo nano /etc/hosts

Look for entries that redirect common domains to 0.0.0.0 or 127.0.0.1. Security software, ad blockers, and malware all modify this file. Remove any suspicious entries, save, and flush the DNS cache.

Step 12: Reset TCP/IP and Winsock Stack (Windows)

If multiple network components are misconfigured, a full stack reset is faster than hunting individual settings:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew

Restart the machine after running all five commands. This resets the TCP/IP registry parameters and the Winsock catalog to their default state without affecting your network adapter drivers.

Step 13: Reset Your Router to Factory Defaults

Use this as a last resort before calling your ISP. A factory reset wipes all custom configuration — Wi-Fi SSIDs, passwords, port forwarding rules, and any custom DNS settings — and restores the router to its out-of-box state.

Most routers have a recessed reset button. Hold it with a pin for 10–15 seconds until the status LEDs cycle. After the router reboots, reconfigure your network from scratch. If DNS works immediately after the reset, a misconfigured router setting was the cause.

Step 14: Contact Your ISP

If every step above fails and the issue affects all devices on your network, the problem is almost certainly upstream of your router — either at the ISP's recursive resolver infrastructure or on the WAN link itself. Contact your ISP's technical support with the following information ready:

• Results of nslookup example.com using both your ISP's DNS and a public resolver like 8.8.8.8.
• Whether the issue is intermittent or constant.
• Whether switching to a mobile hotspot (bypassing your ISP entirely) resolves the problem.

That last test is the definitive ISP isolation check.

DNS Configuration for Server Administrators

If you manage a VPS Hosting environment or a Dedicated Server, DNS errors take on additional dimensions. A misconfigured resolver on a server affects every application running on it — web servers, mail delivery, package managers, and monitoring agents all depend on reliable name resolution.

Verify the resolver configuration on Linux servers:

cat /etc/resolv.conf

A healthy file should contain at least two nameserver lines pointing to reliable resolvers:

nameserver 1.1.1.1
nameserver 8.8.8.8

On systems using systemd-resolved, /etc/resolv.conf is a symlink. Editing it directly has no effect. Use resolvectl instead:

resolvectl status
resolvectl dns eth0 1.1.1.1 8.8.8.8

Test resolution latency from a server:

dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

If query times exceed 200ms consistently, the resolver is geographically distant or under load. Switch to a resolver with a point-of-presence closer to your server's data center.

For servers running cPanel VPS environments, DNS configuration is also managed through WHM's Basic cPanel & WHM Setup page. Ensure the resolvers listed there match what is in /etc/resolv.conf to avoid split-brain resolution issues.

DNS and Domain Registration: The Upstream Connection

A "DNS server not responding" error on your own domain — rather than someone else's — often traces back to nameserver configuration at the registrar level. If you recently registered a domain or changed nameservers through Domain Registration, propagation takes up to 48 hours. During that window, some resolvers around the world still hold the old NS records.

Use a propagation checker or query multiple geographically distributed resolvers directly:

# Query authoritative nameservers directly, bypassing cache
dig +trace example.com

# Check what specific resolvers currently return
dig @1.1.1.1 example.com NS
dig @8.8.8.8 example.com NS
dig @208.67.222.222 example.com NS

Discrepancies between resolver responses during propagation are normal. If responses are still inconsistent after 48 hours, the NS records at the registrar are likely misconfigured.

Securing DNS: DNSSEC and DNS-over-HTTPS

Standard DNS queries travel in plaintext over UDP port 53, making them vulnerable to DNS spoofing and cache poisoning attacks. Two complementary technologies address this:

DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that a response is authentic and has not been tampered with. It protects the integrity of the data but does not encrypt the query itself.

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt the entire DNS query, preventing eavesdropping and on-path manipulation. Modern browsers support DoH natively. To enable it system-wide on Windows 11, navigate to Settings > Network & Internet > [your adapter] > DNS server assignment > Edit and set the encryption to Encrypted only (DNS over HTTPS).

For servers, configure systemd-resolved to use DoT:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
DNSSEC=yes

sudo systemctl restart systemd-resolved

If you are running Email Hosting or managing your own mail server, correct DNS configuration — specifically SPF, DKIM, and DMARC records — is critical for deliverability. DNS failures on a mail server do not just break outbound browsing; they cause deferred or bounced email and failed TLS certificate validation.

SSL Certificates and DNS Dependency

TLS certificate issuance and renewal depend entirely on DNS. Certificate Authorities performing domain validation (DV) via the DNS-01 ACME challenge must resolve your domain's _acme-challenge TXT record. If DNS is broken at the time of renewal, automated tools like Certbot will fail silently, and your SSL Certificates will expire — taking HTTPS down with them.

Set up monitoring for both DNS resolution and certificate expiry. A simple cron-based check:

# Check days until certificate expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates

Decision Matrix: Isolating the DNS Failure Layer

Use this matrix to identify the fault layer before spending time on fixes that will not apply to your situation.

Technical Key-Takeaway Checklist

• Run ping 8.8.8.8 first. If it fails, DNS is not your primary problem — fix routing or physical connectivity first.
• Always flush the local DNS cache after changing resolver settings; stale entries will mask whether the fix worked.
• Switch to Cloudflare 1.1.1.1 or Quad9 9.9.9.9 as your first resolver change — both are faster and more reliable than most ISP resolvers.
• On Windows, if the Services GUI greys out the DNS Client restart option, use net stop dnscache && net start dnscache from an elevated command prompt.
• On Linux servers, never edit /etc/resolv.conf directly on systemd-resolved systems — changes are overwritten on network restart. Use resolvectl or nmcli.
• VPN clients are a frequent silent culprit. Always test with the VPN disconnected before escalating.
• For your own domains, dig +trace bypasses all caches and shows exactly what the authoritative servers are returning — use it before assuming a resolver problem.
• Enable DNSSEC validation and DNS-over-TLS/HTTPS on production servers to eliminate an entire class of spoofing-based DNS failures.
• On servers, monitor both DNS resolution health and SSL certificate expiry together — a DNS failure will silently cause certificate renewal to fail days later.

Frequently Asked Questions

Why does DNS fail even though I have a working internet connection?

DNS resolution uses UDP packets to port 53, which is separate from the TCP connections your browser uses to load pages. A firewall rule, a crashed DNS relay on your router, or a down resolver can block port 53 specifically while leaving all other traffic unaffected. Run ping 8.8.8.8 to confirm IP connectivity, then nslookup example.com to confirm DNS is the isolated failure.

Is it safe to permanently use Google or Cloudflare DNS instead of my ISP's resolver?

Yes, for most users and use cases. Both Google Public DNS and Cloudflare 1.1.1.1 support DNSSEC validation and offer higher uptime SLAs than typical ISP resolvers. The trade-off is that your DNS queries are processed by a third-party infrastructure provider rather than your ISP. Cloudflare publishes a strict no-query-logging policy; Google retains anonymized logs for up to 48 hours.

What is the difference between flushing the DNS cache and changing the DNS server?

Flushing the cache deletes locally stored resolution results, forcing the OS to send fresh queries to the configured resolver. Changing the DNS server redirects where those queries are sent. If your cache holds a poisoned or stale entry, flushing fixes it without changing your resolver. If your resolver itself is down or slow, changing the server address fixes it without touching the cache. In practice, doing both together after a DNS failure is the cleanest approach.

Why does nslookup succeed but the browser still shows a DNS error?

Browsers increasingly use their own DNS-over-HTTPS implementation, which bypasses the OS resolver entirely. If the browser's configured DoH endpoint is unreachable, it may fail even when the system resolver works fine. Check the browser's privacy or security settings for a "Secure DNS" or "DNS over HTTPS" option and either disable it or point it to a reachable DoH provider.

How do I diagnose DNS issues on a Linux VPS without a GUI?

Use dig, nslookup, and resolvectl from the command line. Run dig @1.1.1.1 example.com to test a specific resolver directly, bypassing local configuration entirely. Run resolvectl status to see which resolver the system is currently using and whether DNSSEC is active. Check /etc/resolv.conf to confirm the configured nameservers, and verify the file is not a broken symlink with ls -la /etc/resolv.conf.