> ## Documentation Index > Fetch the complete documentation index at: https://docs.derekdinh.com/llms.txt > Use this file to discover all available pages before exploring further. # Resolving DNS Failures and Name Resolution Errors Quickly > Learn to identify DNS failure symptoms, flush your DNS cache, switch to a reliable DNS server, and verify resolution using nslookup across all platforms. The Domain Name System (DNS) is the internet's phonebook — it translates human-readable domain names like `company.com` into the IP addresses that computers actually use to communicate. When DNS fails, websites and services become unreachable even though your underlying internet connection may be perfectly healthy. This guide walks you through diagnosing DNS problems and applying the correct fix for Windows, macOS, and Linux. Before making any changes, confirm that you are dealing with a DNS problem rather than a general connectivity issue. DNS failures have a distinctive signature. **Classic symptoms of DNS failure:** * Websites fail to load with errors such as `DNS_PROBE_FINISHED_NXDOMAIN`, `ERR_NAME_NOT_RESOLVED`, or `Server not found`. * You can load websites by typing their **IP address** directly, but not by their domain name. * Messaging apps or email clients that rely on domain names stop working, while locally resolved services remain accessible. * The issue affects multiple different websites and services simultaneously. **The definitive DNS test — ping IP vs. ping hostname:** ```bash theme={null} # Test 1: Ping a public IP address directly (no DNS required) ping 8.8.8.8 # Test 2: Ping the same server by hostname (DNS required) ping google.com ``` If **Test 1 succeeds** but **Test 2 fails**, you have a DNS resolution problem. Your internet connection is working correctly, but your device cannot translate domain names to IP addresses. If both tests fail, you likely have a broader connectivity issue rather than a pure DNS problem. Refer to the [No Internet Connection](/networking/no-internet-connection) guide first to restore basic connectivity before addressing DNS. Your operating system caches DNS responses locally to speed up repeat lookups. If an entry becomes stale or corrupted — for example, after a server changes its IP address — your device may continue routing traffic to the old, incorrect address. Flushing the cache forces a fresh lookup for every domain. **Windows (Command Prompt or PowerShell — run as Administrator):** ```powershell theme={null} ipconfig /flushdns ``` Successful output: ```text theme={null} Windows IP Configuration Successfully flushed the DNS Resolver Cache. ``` **macOS Ventura / Sonoma (13+):** ```bash theme={null} sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ``` macOS does not print a confirmation message on success. If the command completes without an error, the cache has been cleared. **macOS Monterey (12) and earlier:** ```bash theme={null} sudo killall -HUP mDNSResponder ``` **Linux — systemd-resolved (Ubuntu 18.04+, Fedora, Arch):** ```bash theme={null} sudo systemd-resolve --flush-caches # Verify the cache was cleared (CacheSize should now show 0) sudo systemd-resolve --statistics | grep -A 3 "Cache" ``` **Linux — nscd (older distributions):** ```bash theme={null} sudo systemctl restart nscd ``` **Linux — dnsmasq:** ```bash theme={null} sudo systemctl restart dnsmasq ``` After flushing, open a browser and try loading a website. If it loads successfully, a stale cache entry was the cause and no further steps are needed. You can also flush the DNS cache built into Chrome and Edge without restarting the browser. Navigate to `chrome://net-internals/#dns` (Chrome) or `edge://net-internals/#dns` (Edge) and click **Clear host cache**. If flushing the cache does not resolve the issue, your configured DNS server may be down, slow, or returning incorrect responses. Switching to a well-known public DNS resolver is a reliable fix. **Recommended public DNS servers:** | Provider | Primary | Secondary | | ----------------------------- | --------- | ----------------- | | Cloudflare | `1.1.1.1` | `1.0.0.1` | | Google Public DNS | `8.8.8.8` | `8.8.4.4` | | Quad9 (with malware blocking) | `9.9.9.9` | `149.112.112.112` | *** **Windows:** 1. Press **Win + R**, type `ncpa.cpl`, and press **Enter**. 2. Right-click your active network adapter and choose **Properties**. 3. Select **Internet Protocol Version 4 (TCP/IPv4)** and click **Properties**. 4. Choose **Use the following DNS server addresses** and enter your preferred values. 5. Click **OK**, then close the windows. You can also change DNS via PowerShell (run as Administrator): ```powershell theme={null} # Replace 'Ethernet' with your actual adapter name (check with Get-NetAdapter) Set-DnsClientServerAddress -InterfaceAlias "Ethernet" ` -ServerAddresses ("1.1.1.1", "1.0.0.1") # Verify the change Get-DnsClientServerAddress -InterfaceAlias "Ethernet" ``` *** **macOS:** 1. Open **System Settings → Network**. 2. Select your active interface (Wi-Fi or Ethernet) and click **Details**. 3. Switch to the **DNS** tab. 4. Click **+** to add `1.1.1.1` and `1.0.0.1`, then click **OK**. *** **Linux (systemd-resolved):** Edit the resolved configuration file: ```bash theme={null} sudo nano /etc/systemd/resolved.conf ``` Find the `[Resolve]` section and update the `DNS` line: ```ini theme={null} [Resolve] DNS=1.1.1.1 1.0.0.1 FallbackDNS=8.8.8.8 8.8.4.4 ``` Save the file and restart the service: ```bash theme={null} sudo systemctl restart systemd-resolved ``` On corporate or managed networks, your IT department may require you to use company-specific internal DNS servers to resolve internal hostnames (e.g., `intranet.company.local`). Switching to a public DNS server on these networks may prevent access to internal resources. Check with your IT team before changing DNS on a work device. `nslookup` is a cross-platform command-line tool that lets you query a DNS server directly and see exactly what it returns. It is available on Windows, macOS, and Linux without any installation. **Basic hostname lookup:** ```bash theme={null} nslookup google.com ``` Healthy output looks like this: ```text theme={null} Server: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: Name: google.com Address: 142.250.80.46 ``` **Test a specific DNS server (useful for comparing your ISP's DNS vs. a public one):** ```bash theme={null} # Query Cloudflare DNS directly nslookup google.com 1.1.1.1 # Query Google Public DNS directly nslookup google.com 8.8.8.8 ``` **Test an internal corporate hostname:** ```bash theme={null} # Replace with your company's internal DNS server IP nslookup intranet.company.local 10.0.0.1 ``` **Reverse DNS lookup (IP address → hostname):** ```bash theme={null} nslookup 8.8.8.8 ``` | Error | Likely Cause | Action | | -------------------------------- | --------------------------------------- | --------------------------------------------------------- | | `NXDOMAIN` (Non-Existent Domain) | The domain does not exist in DNS | Check for typos; confirm the domain is registered | | `SERVFAIL` | The DNS server encountered an error | Switch to a different DNS server | | `REFUSED` | The DNS server rejected the query | Try a public DNS server; check firewall rules on port 53 | | `Timed out` | The DNS server is unreachable | Check network connectivity; switch DNS servers | | `Can't find server` | Your device cannot reach any DNS server | Verify your DNS server addresses are correctly configured | `dig` is a more powerful alternative to `nslookup` on macOS and Linux. Run `dig google.com` for a detailed response including query time, which is useful for benchmarking DNS server performance. Firewalls and VPN clients can block or redirect DNS traffic, causing resolution failures even when your DNS settings look correct. **Verify that port 53 (DNS) is not blocked:** ```bash theme={null} # macOS / Linux nc -zv 1.1.1.1 53 # Windows (PowerShell) Test-NetConnection -ComputerName 1.1.1.1 -Port 53 ``` A successful result looks like: ```text theme={null} TcpTestSucceeded : True ``` If port 53 is blocked, work with your IT team to determine whether the firewall policy is intentional (e.g., forcing all DNS through a company resolver) or a misconfiguration. **If you are on a VPN:** * Disconnect from the VPN and test DNS resolution again. * If DNS works without the VPN but fails with it connected, the VPN is intercepting DNS queries. This is common with split-tunneling configurations that route DNS traffic incorrectly. * Contact your VPN administrator or refer to the [VPN Connectivity](/networking/vpn-connectivity) guide. Some corporate environments use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) for encrypted DNS traffic. If your organization mandates this, standard port 53 tests will appear to fail even when DNS is working correctly through the encrypted channel. If you have flushed the cache, switched DNS servers, and verified that port 53 is open, but DNS resolution still fails, escalate with the information below. * **Output of `nslookup google.com`** using both your current DNS server and a public one (e.g., `nslookup google.com 8.8.8.8`) * **Output of `ipconfig /all`** (Windows) or `cat /etc/resolv.conf` (Linux) showing your currently configured DNS servers * **Results of your ping tests** — does `ping 8.8.8.8` succeed while `ping google.com` fails? * **Browser error messages** — exact error codes such as `DNS_PROBE_FINISHED_BAD_CONFIG` or `ERR_NAME_NOT_RESOLVED` * **Whether the issue affects all domains or only specific ones** — a subset of failing domains may indicate a split-horizon DNS issue or a corrupted hosts file * **Contents of your hosts file** (check for unexpected entries): ```powershell theme={null} # Windows type C:\Windows\System32\drivers\etc\hosts ``` ```bash theme={null} # macOS / Linux cat /etc/hosts ``` Do not add entries to the hosts file to work around DNS failures unless explicitly instructed by IT support. Incorrect hosts file entries can cause persistent routing problems that are difficult to diagnose later.