The Cannot Connect to DNS Server error means your device sent a lookup to its assigned DNS resolver and received no response. In most cases, flushing the DNS cache and switching to a public resolver — 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) — fixes it in under two minutes. If that does not work, the fault is usually a stale DHCP lease, a misconfigured router, or a firewall blocking UDP port 53.
What the Error Actually Means
The message surfaces most visibly in the Windows Network Diagnostics tool, but the underlying failure — an unanswered DNS query — shows up on every operating system as "This site can't be reached," "ERR_NAME_NOT_RESOLVED," or "Server not found." DNS translates domain names into IP addresses. When the resolver your device is pointed at is unreachable, every hostname lookup fails even if your internet connection is otherwise healthy.
Quick test before going further: open a browser and navigate to a bare IP address such as https://1.1.1.1. If that page loads, your internet is up and only DNS is broken. If it does not load, the fault is at the network level and fixing DNS alone will not be enough.
Root Causes, Ranked by Frequency
- Stale or incorrect DNS server address — after a router reboot or ISP maintenance, DHCP can assign a DNS IP that is no longer valid.
- ISP DNS server outage — the ISP's resolver goes down and every device on their network fails simultaneously.
- Manually set incorrect DNS — a previous fix attempt hard-coded an IP that no longer routes.
- Firewall or security software blocking port 53 — antivirus suites and third-party firewalls sometimes block outbound UDP and TCP port 53.
- Network adapter in a bad state — a driver crash or aggressive power-management setting can prevent the adapter from completing DHCP negotiations.
- Router DNS relay broken — the router acts as a DNS forwarder; if that service crashes, every device behind it fails even though the WAN link is up.
- IPv6 DNS misconfiguration — on dual-stack networks, a missing or wrong IPv6 DNS address causes failures on systems that prefer IPv6 queries.
- Malware DNS hijack — some malware rewrites the DNS server address to route traffic through a rogue resolver.
Step 1: Flush the Cache and Renew the IP Lease (Windows)
Open an elevated Command Prompt or Windows Terminal as Administrator — press Win + X and select the admin Terminal or Command Prompt option. Run these commands in order:
Restart your computer after the netsh commands. The Winsock and IP stack resets do not take effect until after a reboot. After restarting, open a browser and test. If browsing works, the cause was a corrupt Winsock catalog or an expired DHCP lease.
Step 2: Switch to a Public DNS Server
This is the fastest permanent fix when your ISP's DNS is down or misconfigured. On Windows 11: Settings → Network & Internet → Wi-Fi or Ethernet → Hardware properties → DNS server assignment → Edit → set type to Manual. Enter 1.1.1.1 as preferred and 1.0.0.1 as alternate (Cloudflare), or 8.8.8.8 and 8.8.4.4 (Google). For IPv6, use 2606:4700:4700::1111 and 2606:4700:4700::1001 (Cloudflare) or 2001:4860:4860::8888 and 2001:4860:4860::8844 (Google). Click Save — no restart needed.
On Windows 10: Control Panel → Network and Sharing Center → Change adapter settings → right-click the active adapter → Properties → Internet Protocol Version 4 (TCP/IPv4) → Properties → Use the following DNS server addresses. Enter the same IPs above and click OK. Repeat in the IPv6 entry for IPv6 DNS addresses.
Step 3: Reset the Network Adapter (Windows)
If switching DNS did not help, the adapter itself may be stuck. Start with the lightest option: Settings → Network & Internet → Advanced network settings → right-click your adapter → Disable, wait five seconds, then Enable.
If that does not clear it, run a full network reset. On Windows 11: Settings → Network & Internet → Advanced network settings → Network reset → Reset now. On Windows 10: Settings → Network & Internet → Status → Network reset. This removes all adapter configurations and reinstalls network drivers to defaults — you will need to re-enter Wi-Fi passwords afterward.
Also check power management: in Device Manager (Win + X → Device Manager), expand Network adapters, right-click your adapter → Properties → Power Management tab → uncheck Allow the computer to turn off this device to save power. Laptops on battery can lose DNS connectivity if the adapter is aggressively suspended between requests.
Step 4: Check Your Router's DNS Settings
If every device on the network is failing simultaneously, the router's DNS relay is the likely culprit. Log in to your router admin panel at one of these addresses depending on brand:
- Most home routers: 192.168.1.1 or 192.168.0.1
- TP-Link: tplinkwifi.net or 192.168.0.1
- Netgear: routerlogin.net or 192.168.1.1
- ASUS: asusrouter.com or 192.168.1.1
- Xiaomi: miwifi.com
- Linksys: linksyssmartwifi.com
- Netgear Orbi: orbilogin.com
Locate the DNS settings — the path varies by firmware generation; look for WAN Setup, Internet Settings, or Advanced → DNS. Override the primary field with 1.1.1.1 and the secondary with 1.0.0.1. Save and restart the router; wait 60 seconds before reconnecting devices.
OpenWrt: DNS is handled by dnsmasq. Go to Network → DHCP and DNS → DNS forwardings and add 1.1.1.1 and 8.8.8.8. DD-WRT: Setup → Basic Setup → Network Address Server Settings (DHCP) → set Static DNS 1 to 1.1.1.1, Static DNS 2 to 8.8.8.8. Save and apply settings.
Mac Fixes
Flush the DNS cache first. Open Terminal and run:
To change DNS: on macOS 13 Ventura and later, go to System Settings → Network → select your connection → Details → DNS tab → click + and add 1.1.1.1 and 1.0.0.1. On macOS 12 Monterey and earlier, use System Preferences → Network → Advanced → DNS. Remove any stale entries after adding the new ones.
While on the TCP/IP tab, click Renew DHCP Lease. If problems persist, delete the network preference files: in Finder navigate to /Library/Preferences/SystemConfiguration/ and move NetworkInterfaces.plist and preferences.plist to the Desktop as a backup, then restart. macOS regenerates these files with clean defaults on next boot.
Linux Fixes
DNS management varies by distribution. On Ubuntu 20.04+, Debian 11+, and Fedora using systemd-resolved, flush the cache and inspect the current resolver:
To configure a permanent DNS server, edit /etc/systemd/resolved.conf and add or update these lines:
Then restart the resolver service:
On NetworkManager systems (most desktop distros), change DNS per connection from the terminal:
Replace Your Connection Name with the exact name returned by nmcli con show.
iOS and Android
iOS: Settings → Wi-Fi → tap the (i) icon next to your network → Configure DNS → Manual → Add Server: enter 1.1.1.1, then 1.0.0.1, and delete the existing auto-assigned entry. To flush without changing DNS: toggle Airplane Mode on for 10 seconds, then off. Full reset (last resort — erases all saved Wi-Fi passwords): Settings → General → Transfer or Reset iPhone → Reset → Reset Network Settings.
Android 9 and later: Settings → Network & Internet → Private DNS → Private DNS provider hostname → enter one.one.one.one (Cloudflare's DNS-over-TLS hostname) or dns.google. This applies system-wide over TLS regardless of which network you join. On older Android or custom ROMs, long-press the network in Wi-Fi settings → Modify network → Advanced options → IP settings: Static → DNS 1: 1.1.1.1, DNS 2: 1.0.0.1. Leave all other fields unchanged to avoid breaking the gateway.
CLI Verification: Confirm the Fix Worked
After any fix, run a manual lookup before calling the job done.
Windows — nslookup:
The first command tests your currently configured DNS server. The second queries Cloudflare directly. If the second succeeds but the first fails, your configured server is still the problem.
Mac and Linux — dig:
You should see one or more A record IP addresses in the answer section. "Connection timed out; no servers could be reached" means DNS is still broken. SERVFAIL returned by a working resolver often indicates a DNSSEC validation failure — see the 2026 section below.
Linux (systemd-resolved):
The output names the answering server and shows whether DNSSEC validation was applied. This is the most informative single diagnostic command on modern Linux systems.
Firewall and Security Software Checks
DNS uses UDP port 53 for most queries and TCP port 53 for responses exceeding 512 bytes. A firewall silently blocking outbound port 53 kills all DNS. To test: temporarily disable your third-party firewall's web-shield or DNS-protection module (not the entire product), retry a lookup, then re-enable immediately. If that clears the error, reconfigure the product's DNS interception settings rather than leaving it off.
To check the Windows built-in firewall state from an admin terminal:
If you are on a corporate or school network managed by group policy, DNS may be forcibly routed through a managed resolver. In that scenario, changing the DNS server address in network settings will have no effect on the resolver actually used — work through your IT department instead.
Ruling Out Malware
A DNS hijack rewrites your configured resolver to one that returns false results. Signs: certificate warnings on familiar sites, search redirects to unknown domains, or DNS consistently returning unexpected IP addresses. Check which server is actually configured:
Look at the DNS Servers line. It should show your router's LAN IP (typically 192.168.1.1 or 192.168.0.1), your ISP's resolver, or a recognized public resolver such as 1.1.1.1, 8.8.8.8, 9.9.9.9, or 208.67.222.222. Any unfamiliar IP is suspicious. On Mac and Linux:
If a rogue IP appears, run a full scan with Windows Defender Offline or Malwarebytes, reset the DNS server addresses as described in Step 2, and change your router admin password as a precaution.
How to Prevent Recurrence
- Set a public DNS server on your router rather than relying on the ISP default. ISP resolvers go down; major public resolvers maintain far higher uptime.
- Configure both IPv4 and IPv6 DNS addresses on every device. Setting only IPv4 while the system prefers IPv6 leaves you exposed whenever IPv6 is used for the lookup.
- Keep router firmware updated. DNS relay bugs and relay service crashes are regularly fixed in manufacturer firmware releases.
- On Android 9+ and iOS 14+, enable encrypted DNS — Private DNS on Android, and a DNS-over-HTTPS configuration profile on iOS. This prevents DHCP-based DNS hijacking on public Wi-Fi networks.
- On Windows 11 22H2 and later, enable DNS-over-HTTPS natively: Settings → Network & Internet → your connection → DNS server assignment → Edit → set DNS-over-HTTPS to On (automatic template) when using 1.1.1.1 or 8.8.8.8.
Common Misdiagnoses
"My internet is down" — before assuming a full outage, run ping 8.8.8.8 from the command line. If replies come back, the connection is up and only DNS is broken. The fix path is completely different from a downed link.
"The website is down" — when DNS fails, all sites fail equally. You cannot distinguish a site-specific outage from a DNS failure until DNS is restored and you can actually reach the site.
"The VPN broke it" — VPN clients override the OS DNS server. Disconnect the VPN and test. If resolution works without it, the VPN's assigned resolver is the fault; configure a reliable DNS server inside the VPN client's settings rather than abandoning the VPN.
"Disabling IPv6 fixes it" — this is a heavy-handed workaround that introduces new connectivity problems. The correct fix is to add proper IPv6 DNS addresses alongside IPv4, not to disable the protocol entirely.
"My router must be broken" — before factory-resetting the router, connect a device directly to the modem if your router and modem are separate units. If DNS works on a direct modem connection, the router is the fault point. If it still fails, the issue is upstream from the router and a reset will accomplish nothing.
2026 Notes: IPv6, Encrypted DNS, and DNSSEC
IPv6 DNS is now pushed by default on most ISP-supplied routers. A missing or misconfigured IPv6 DNS address in the Router Advertisement causes lookup failures on systems that prefer AAAA queries — even when IPv4 DNS is perfectly healthy. On Windows, verify both are present with:
On Linux, check per interface:
DNS-over-HTTPS (DoH) is now built into Windows 11, macOS 13+, and all major browsers. A browser may resolve names independently of the OS resolver — meaning Chrome or Firefox can reach sites that ping and nslookup cannot, making the failure appear inconsistent. Check browser-specific DNS settings: in Chrome, chrome://settings/security → Use secure DNS; in Firefox, about:preferences#general → Network Settings → DNS over HTTPS. Disabling the browser's own DoH setting forces it back through the OS resolver, which helps isolate where the failure lives.
DNSSEC: if dig google.com @8.8.8.8 returns SERVFAIL while running the same query with the +cd flag (checking disabled) returns a valid answer, DNSSEC validation is rejecting the response. This is uncommon on major domains but can occur during zone signing key rollovers. The foundational DNS specification — RFC 1035 — defines the core protocol without security extensions; DNSSEC was layered on later and remains optional, so switching to a non-validating resolver temporarily is a valid diagnostic step while you determine whether the zone itself has a signing problem.