You type your domain into a browser, hit Enter, and get nothing — a blank page, a "server not found" error, or a timeout. Meanwhile, someone else reports the site loads fine for them. That disconnect is maddening, and the root cause could be anywhere from a misconfigured DNS record to a corrupted local cache to an expired domain registration. This guide cuts through the noise and walks you through every likely culprit in order of likelihood, so you can stop guessing and start fixing.
Step 1: Confirm Whether the Problem Is Local or Global
The first thing you need to determine is whether the resolution failure is happening only on your machine or network, or whether it is truly a global DNS outage affecting everyone. This single check saves enormous amounts of wasted effort.
- Pull out your phone, turn off Wi-Fi, and try loading the domain over mobile data. If it loads, your local network or computer is the problem, not the DNS records themselves.
- Ask a colleague in a different city or country to try the domain. If they see it fine, you are almost certainly looking at a local issue.
- Use a web-based tool to query the domain from multiple global vantage points simultaneously.
Step 2: Flush Your Local DNS Cache
Operating systems cache DNS responses to speed up repeat lookups. When a DNS record changes — or when a bad record gets cached — your machine stubbornly holds onto the old data even after the authoritative servers have been updated. Flushing the cache forces a fresh query.
Windows 10 and 11
Open Command Prompt as Administrator, run those commands in order, then try the domain again.
macOS (Ventura, Sonoma, and Monterey)
Enter your password when prompted. There is no success message — the flush happens silently.
Linux (systemd-resolved)
After flushing, open a new browser tab and test the domain again. If it now resolves, a stale cache was your problem and you are done.
Step 3: Query DNS Directly to Bypass Your Resolver
If flushing the cache did not help, the next move is to bypass your default DNS resolver and query an authoritative server directly. This isolates whether the fault is in your ISP resolver, your router, or the DNS records themselves.
Run these from Command Prompt (Windows) or Terminal (Mac/Linux). Replace yourdomain.com with your actual domain. If the domain resolves correctly when you point at 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) but fails with your default resolver, then your ISP's DNS servers are the problem — not your records.
You can also use dig on Mac and Linux for more detail:
The +trace flag follows the resolution path from the root DNS servers all the way down to your authoritative nameservers. If the trace stops midway, you have found where the chain breaks.
Step 4: Check Your DNS Records in a Lookup Tool
Even if the domain resolves to something, it might be pointing at the wrong IP address, a deleted server, or a misconfigured CNAME chain. Verify what is actually published in DNS right now.
Use the DNS Lookup tool to check your A, AAAA, CNAME, and NS records instantly. Look for these common problems:
- A record points to an old IP: A common post-migration problem. The record still shows the previous hosting provider's IP even though the server there was decommissioned.
- Missing A or AAAA record: The root domain has no address record at all, though a www CNAME may exist. Visitors going to the bare domain get nothing.
- CNAME pointing to a dead hostname: A CNAME chain that terminates at a hostname that no longer has an A record causes a NXDOMAIN or empty response.
- Nameservers not matching your registrar: If your registrar shows NS records pointing to Cloudflare, but a live query returns the old host's nameservers, the update has not propagated yet or was not saved.
Step 5: Verify Your Domain Registration Is Active
An expired domain stops resolving immediately. Registrars pull the delegation the moment a domain lapses, and it happens faster than most people expect — sometimes within hours of the expiry date, not days.
Run a WHOIS lookup on your domain:
Look at the Expiry Date and Status fields. A status of clientHold or pendingDelete means the domain has been suspended. If it shows redemptionPeriod, the domain has expired and moved into a grace period — you can still recover it, usually at a premium fee, by logging into your registrar and renewing immediately.
Also verify the domain's Registrar Lock status is set to clientTransferProhibited. If it was accidentally unlocked during a transfer attempt, some registrars temporarily suppress DNS while the domain is in a pending-transfer state.
Step 6: Inspect Your Nameserver Configuration
The nameservers (NS records) are the bridge between your domain registrar and your DNS hosting provider. If they are wrong, nothing else matters — no record you publish will ever be seen.
At your registrar, look for a section called DNS Management, Nameservers, or Name Servers. Common locations:
- GoDaddy: My Products > DNS > Nameservers
- Namecheap: Domain List > Manage > Nameservers
- Google Domains / Squarespace Domains: DNS > Name Servers
- Cloudflare Registrar: DNS > Nameservers (always ns1.cloudflare.com / ns2.cloudflare.com for Cloudflare-hosted zones)
Cross-reference what your registrar shows against what a live query returns:
The NS records in the answer section must exactly match what your registrar has on file. Any mismatch means the NS update either was not saved or has not propagated yet. NS changes can take up to 48 hours, though most complete within 4 to 6 hours.
Step 7: Rule Out a Router or Local DNS Issue
Home routers and small-office routers often act as a DNS forwarder or even a caching resolver. A hung or misconfigured router can cause resolution failures for every device on the network while external tests show the domain is perfectly fine.
Restart your router first. Hold the power button or unplug it for 30 seconds. This alone clears most router-level DNS caches.
If the problem persists, log into your router admin panel and manually set the upstream DNS servers to a known-good public resolver:
- Netgear (routerlogin.net or 192.168.1.1): Advanced > Setup > Internet Setup > Domain Name Server (DNS) Address — set primary to 1.1.1.1, secondary to 8.8.8.8
- TP-Link (tplinkwifi.net or 192.168.0.1): Advanced > Network > Internet > DNS Server — enter 1.1.1.1 and 8.8.8.8
- ASUS (asusrouter.com or 192.168.1.1): WAN > Internet Connection > WAN DNS Setting — disable "Connect to DNS Server Automatically" and enter 1.1.1.1 / 8.8.8.8
- Linksys (192.168.1.1): Connectivity > Internet Settings > IPv4 > DNS — manually enter 1.1.1.1 and 8.8.8.8
- D-Link (192.168.0.1): Setup > Internet > Manual > Primary DNS Server — enter 1.1.1.1
Save the settings and reconnect your devices. If the domain resolves now, your ISP was serving bad DNS data and your router was inheriting that problem.
Step 8: Change DNS Servers on Your Device
If you cannot change the router, or you only need a fix for one machine, configure DNS directly on the network adapter.
Windows
Settings > Network and Internet > Change Adapter Options > right-click your active connection > Properties > Internet Protocol Version 4 (TCP/IPv4) > Properties > Use the following DNS server addresses. Enter 1.1.1.1 and 8.8.8.8.
macOS
System Settings > Network > select your Wi-Fi or Ethernet connection > Details > DNS > click the plus button and add 1.1.1.1 and 8.8.8.8.
Linux
Step 9: Check for Propagation Lag
If you recently changed DNS records or moved to a new host and the domain worked before but stopped after your changes, propagation lag is the most likely culprit. TTL (Time to Live) values control how long resolvers cache records. If your old records had a TTL of 86400 (24 hours), resolvers around the world will keep serving the stale IP for up to 24 hours after your update.
There is no shortcut to force other resolvers to flush their cache for your domain. Your options are:
- Wait for the TTL to expire — check the old TTL value to know how long this will take.
- Use a VPN to connect through a different network and test whether that resolver has picked up the new record.
- Switch your own device DNS to 1.1.1.1, which typically picks up changes faster than ISP resolvers.
- For future changes, lower your TTL to 300 seconds (5 minutes) at least 24 hours before you make changes, then raise it back after confirming the new records work.
Step 10: Verify the Server Itself Is Responding
DNS resolving correctly does not mean the website is reachable. Once you confirm the domain points to the right IP, test whether the server at that IP is actually up:
If ping resolves the IP correctly but times out, the server or its firewall is blocking ICMP. Try the curl command instead — a 200 or 301 response means the web server is alive. A connection refused error means the web server process (Apache, Nginx, etc.) is down on that machine. A timeout means either the server is offline or a firewall is blocking port 80/443.
Contact your hosting provider if the server itself is unreachable — this is beyond a DNS problem at that point.
How to Prevent Domain Resolution Failures
Most outages caused by DNS failures are preventable. Put these practices in place now:
- Enable auto-renewal on your domain registration. A lapsed domain is the most disruptive and completely avoidable cause of DNS failure.
- Lower TTLs before planned changes. Set records to 300 seconds (5 minutes) at least 24 hours before any migration, then restore them afterward.
- Monitor your domain with an uptime service. Tools like UptimeRobot or Better Uptime alert you within minutes if your domain stops resolving globally.
- Keep your registrar and DNS hosting login credentials documented and accessible to more than one person on your team. Many outages drag on for hours simply because no one can find the login.
- Use secondary DNS. Enterprise-grade hosting platforms and DNS providers like Cloudflare offer anycast DNS with 100% uptime SLAs. Moving off a shared registrar DNS to a dedicated DNS provider dramatically improves reliability.
- Document your DNS records. Keep a spreadsheet or configuration file of every DNS record: type, name, value, TTL, and purpose. When something breaks, you need to know immediately what the correct state looks like.
Quick Reference: Common Errors and What They Mean
- NXDOMAIN: The domain does not exist in DNS. Either it expired, was deleted, or was never created. Check your registrar and zone file immediately.
- SERVFAIL: The authoritative nameserver returned an error. Often caused by a broken zone file, DNSSEC misconfiguration, or nameserver outage at your DNS hosting provider.
- REFUSED: The resolver declined the query. Common when querying a nameserver that is not authoritative for the domain and has recursion disabled.
- Connection timed out: DNS resolved but the web server is not answering. A hosting or firewall issue, not a DNS issue.
- ERR_NAME_NOT_RESOLVED (Chrome): The browser could not get an A or AAAA record. Either NXDOMAIN or a local resolver failure — flush cache and retest.
Domain resolution failures almost always have a concrete, fixable cause. Work through each step methodically — starting local, then moving outward to the network, then to the DNS records, then to the registrar — and you will isolate the problem every time. The majority of issues resolve at step 2 or 3 (cache flush or nameserver misconfiguration). The rest fall into the handful of categories covered above. Once you have identified the break, the fix is usually straightforward.