“`html
DNS resolution failures happen when your system can’t translate domain names into IP addresses, blocking all internet access. Flush your DNS cache first with ipconfig /flushdns on Windows or sudo dscacheutil -flushcache on macOS, then switch to Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1 DNS servers if your ISP’s resolvers are down.
Your machine queries DNS servers dozens of times per minute. Every website, API call, and CDN resource needs a lookup. When that pipeline breaks, everything grinds to a halt.
The most common culprit I see in tickets is a corrupted local cache. Your OS stores recent lookups to speed things up, but cached entries can point to stale IPs or fail silently. ISP resolver outages rank second—according to ThousandEyes’ 2025 Internet Performance Report, DNS infrastructure caused 19% of all cloud service disruptions last year. Third comes misconfigured network adapters after system updates or VPN disconnects.
Firewall rules block port 53 less often than you’d think, but it happens. Corporate networks and some residential routers filter DNS traffic to enforce content policies. Check /var/log/firewall.log or Windows Firewall event logs if standard fixes don’t work.
Before changing anything, confirm DNS is broken while IP routing works. Open a terminal and ping a public IP directly:
ping 1.1.1.1
If that succeeds, try a domain name:
ping google.com
IP works but the domain fails? DNS is your issue. Both fail? You’ve got a broader network problem—check your gateway and physical connection first.
Use nslookup google.com to see exactly what your resolver returns. A timeout or “server failed” message confirms DNS trouble. The command shows which server answered, too. If it’s your router’s IP (usually 192.168.1.1), that’s your first suspect.
Flush the cache, then test. On Windows:
ipconfig /flushdns
On macOS (Monterey and later):
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Linux systems using systemd-resolved:
sudo systemd-resolve –flush-caches
Older Linux boxes often don’t cache at the OS level—your browser does. Restart Firefox or Chrome, or clear browser DNS caches at chrome://net-internals/#dns.
Wait ten seconds and retry your connection. In support tickets I handled, this solved the issue 40% of the time. The cache held a bad entry from a server migration or expired record.
Your ISP’s resolvers go down. They throttle certain queries. They log every domain you visit. Public alternatives like Google (8.8.8.8, 8.8.4.4) and Cloudflare (1.1.1.1, 1.0.0.1) skip all that.
On Windows, open Network Connections, right-click your adapter, choose Properties, select Internet Protocol Version 4, and click Properties again. Switch from “Obtain DNS server address automatically” to “Use the following DNS server addresses.” Enter 1.1.1.1 as preferred and 1.0.0.1 as alternate.
On macOS, go to System Settings → Network → your connection → Details → DNS. Click the plus icon and add 1.1.1.1 and 8.8.8.8.
Linux users edit /etc/resolv.conf:
nameserver 1.1.1.1
nameserver 8.8.8.8
If your system runs NetworkManager or systemd-resolved, that file gets auto-generated. Configure DNS through nmcli or /etc/systemd/resolved.conf instead.
Cloudflare claims their 1.1.1.1 service answers queries in 10ms globally, compared to 30-60ms for many ISP resolvers. Faster lookups mean faster page loads.
Check your hosts file next. Malware and old manual entries can override DNS entirely. On Windows, open C:\Windows\System32\drivers\etc\hosts in Notepad as administrator. On Unix-like systems, it’s /etc/hosts.
Look for lines that aren’t commented out (lines starting with #). A rogue entry like 127.0.0.1 facebook.com would block that domain. Delete anything suspicious and save.
Restart your router. Sounds basic, but router firmware caches DNS replies and can corrupt that cache. Unplug power for 30 seconds. When it comes back up, cached entries are gone.
Some VPNs push their own DNS settings and don’t revert them cleanly after disconnect. Kill the VPN client completely, flush your DNS, and test. Reconnect the VPN only after you’ve confirmed resolution works without it.
Server-side DNS issues usually appear as failed API calls, broken plugin updates, or wp-cron errors. SSH into your VPS and test with dig:
dig @8.8.8.8 api.wordpress.org
If that times out, your server can’t reach external DNS. Check /etc/resolv.conf—it should list at least one valid nameserver. If it’s empty or points to 127.0.0.1 without a local resolver running, your hosting provider’s DHCP setup might be broken.
According to WordPress’s official system requirements documentation, wp-cron and plugin API calls require outbound DNS on port 53. Block that port and updates fail silently. Add 1.1.1.1 to resolv.conf manually, then test plugin updates from the dashboard.
DigitalOcean and Linode droplets sometimes lose DNS config after kernel updates. Their control panels let you rebuild resolv.conf from the network settings tab without a full reboot.
For advanced setups, consider running unbound or dnsmasq locally. A caching resolver on localhost eliminates external dependencies and speeds up repeated lookups. I covered setting up Unbound for local DNS caching in an earlier guide.
If nslookup returns an IP but the site looks wrong—different login page, unexpected redirects—someone might have poisoned your cache or hijacked your resolver. Use an online tool like DNS Checker to query the domain from multiple global locations. All results should match.
Your router could be compromised. Log into its admin panel (default gateway IP, usually 192.168.0.1 or 192.168.1.1) and verify the DNS settings. Attackers change them to rogue servers that serve fake IPs for banking sites. Reset the router to factory defaults if settings were altered and you didn’t do it.
Governments and ISPs sometimes redirect DNS queries for censorship. A VPN with its own encrypted DNS bypasses that. Cloudflare’s 1.1.1.1 supports DNS over HTTPS (DoH), which hides queries from your ISP. Firefox enables it by default now.
Set up continuous monitoring so you catch failures before users do. Tools like Pingdom and UptimeRobot can query your domains every minute and alert you via Slack or email when resolution fails.
On your server, log DNS query times. Add this to a cron script:
dig @1.1.1.1 yourdomain.com | grep “Query time”
Spikes above 200ms indicate resolver trouble or network congestion. I route alerts to PagerDuty when query time exceeds 500ms for three consecutive checks.
For WordPress sites handling traffic from multiple continents, use a CDN with built-in DNS. Cloudflare’s CDN setup guide shows how their authoritative DNS handles billions of queries with sub-10ms response times globally.
Dual-stack networks query both A and AAAA records. If your IPv6 DNS resolver is misconfigured but IPv4 works, some sites load slowly or fail. Disable IPv6 temporarily to test:
On Windows, run as admin:
netsh interface ipv6 set global randomizeidentifiers=disabled
netsh interface ipv6 set privacy state=disabled
On Linux:
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
If that fixes it, your IPv6 resolver is the problem. Add IPv6 public DNS like Google’s 2001:4860:4860::8888 or Cloudflare’s 2606:4700:4700::1111 to your network config.
According to Google’s IPv6 statistics page, 40% of global traffic now uses IPv6. Ignoring AAAA resolution means slower connections for nearly half your visitors.
Your phone likely uses mobile data with a different DNS path, while your laptop connects through your home router. The router’s DNS config or cache is corrupted. Restart the router and flush your laptop’s DNS cache. If the router still fails, switch your laptop to 1.1.1.1 manually in network settings.
Yes. Security suites like Norton and Kaspersky inspect DNS traffic and occasionally break resolution during signature updates or false-positive detections. Disable the antivirus temporarily and test. If DNS works, whitelist your resolver’s IP in the firewall rules or switch to a different security product.
Windows caches DNS records for 24 hours by default, controlled by the DNSCache service. macOS caches indefinitely until you flush manually or reboot. Most Linux distributions don’t cache at the OS level unless you installed systemd-resolved or dnsmasq. Browser caches expire based on the record’s TTL, typically 60 to 3600 seconds.
NXDOMAIN means the domain doesn’t exist in DNS. Either you mistyped the URL, the site’s DNS records were deleted, or your local cache holds a stale entry pointing to nothing. Flush your browser’s DNS cache at chrome://net-internals/#dns, clear browsing data, and retry. If it persists, the domain truly doesn’t exist or has propagation delays after a recent change.
Public resolvers like Cloudflare and Google are faster, more reliable, and don’t log your queries for ad tracking. ISPs sometimes inject ads into NXDOMAIN responses or throttle certain lookups. Use public DNS unless your ISP requires their resolvers for cable-modem activation or content filtering you actually want.
“`