Yuncedria
Get in touch
← All articles

· 6 min read

How to Check DNS When a Website Won't Load

When a site fails to load, DNS is one of the first things to rule in or out. Here is which records to query, which resolvers to compare, and how to tell a real DNS fault from a local one.

First, confirm it is a DNS problem

Browsers usually say when name resolution failed. In Chrome and Edge, errors such as ERR_NAME_NOT_RESOLVED or DNS_PROBE_FINISHED_NXDOMAIN point to DNS. Errors such as ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_REFUSED or a certificate warning mean the name did resolve and the problem lies further along: the server, the network or TLS.

From the command line, curl shows which address it connects to:

curl -v -o /dev/null https://example.com/

If curl reports Could not resolve host, resolution failed on your system. If it prints a line such as Trying 203.0.113.10:443 and then stalls or errors, DNS did its job and you should look at the server or the network instead.

Query the records that matter

Use dig or nslookup to query each record type a browser depends on:

dig example.com A +short
dig example.com AAAA +short
dig www.example.com CNAME +short
dig example.com NS +short
nslookup -type=AAAA example.com
  • A / AAAA return the IPv4 and IPv6 addresses. Check that they point to your current host or CDN. A stale AAAA record left over from a migration is a classic cause of “works for me, fails for some visitors”, because IPv6-capable clients usually prefer it.
  • CNAME makes one name an alias of another. It cannot coexist with other records at the same name, so it is not allowed at the zone apex (example.com itself); many DNS providers offer ALIAS, ANAME or CNAME flattening instead.
  • NS lists the authoritative name servers. If they are not the servers where you edit the zone, your changes will never be seen.

Without +short, dig also shows the response status, the header flags and the TTLs you need next.

Compare public resolvers with the authoritative servers

Each resolver caches independently, so answers can legitimately differ for a while. Ask a couple of public resolvers, then the source of truth (replace ns1.example.net with a name returned by dig NS):

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @ns1.example.net example.com A +norecurse
dig example.com A +trace

An authoritative server shows what the zone contains right now; look for the aa (authoritative answer) flag in the header. dig +trace starts at the root servers and follows each delegation down to your zone, bypassing recursive caches and exposing delegation problems such as a TLD that still points to old name servers.

If the authoritative servers return the new value but a public resolver returns the old one, nothing is broken: that resolver is still serving a cached copy. If the authoritative servers return the wrong value, fix the zone.

Read the error: NXDOMAIN, SERVFAIL or a timeout

  • NXDOMAIN: the name does not exist. Check for typos, a missing record (often www), an expired domain, or a zone that is not delegated where you think it is.
  • NOERROR with an empty answer (often called NODATA): the name exists but has no record of the requested type, for example an AAAA query for an IPv4-only host.
  • SERVFAIL: the resolver could not obtain a usable answer. Common causes are authoritative servers that are down or not configured for the zone (a lame delegation) and DNSSEC validation failures. If the query succeeds only with +cd (checking disabled), review your DS and DNSKEY records.
  • REFUSED: the server declined to answer, typically an authoritative server asked about a zone it does not host.
  • Timeout (connection timed out; no servers could be reached): no reply at all. The server is unreachable or a firewall is blocking DNS on port 53; try another resolver to tell which.

TTL, caching and “propagation”

Every DNS record has a TTL (time to live) in seconds, set by whoever manages the zone. A resolver that fetches the record may cache it for up to that long. When you query a recursive resolver, the TTL shown by dig is the time left in its cache.

DNS changes therefore do not travel outward. The authoritative servers serve the new value as soon as the zone is updated, and each resolver answers from its cached copy until that copy expires. What people call propagation is caches expiring. In practice:

  • Lower the TTL (for example to 300 seconds) at least one full old TTL before a planned change, then raise it again afterwards.
  • Negative answers are cached too. If a name was looked up before you created it, the NXDOMAIN can stay cached for a period derived from the zone’s SOA record.
  • Changing name servers at the registrar updates the NS records in the parent (TLD) zone, whose TTL, often a day or more, you do not control.
  • Your operating system and browser keep their own caches as well.

Rule out local causes

dig and nslookup query DNS servers directly. Browsers use the operating system resolver instead, which also reads the hosts file and local caches. If dig looks right but the browser still fails, check:

  • Hosts file: /etc/hosts on macOS and Linux, C:\Windows\System32\drivers\etc\hosts on Windows. A forgotten test entry overrides DNS completely. getent hosts example.com (Linux) or dscacheutil -q host -a name example.com (macOS) show what the system resolver returns.
  • VPN and corporate networks: a VPN can push its own DNS servers or split DNS rules. Compare scutil --dns (macOS), resolvectl status (Linux) or ipconfig /all (Windows) with the VPN on and off.
  • Browser DNS over HTTPS: Chrome, Edge and Firefox can use their own encrypted resolver, so the browser may disagree with the system. Check the secure DNS setting; in Chromium-based browsers, clear the host cache at chrome://net-internals/#dns.
  • Local caches: flush them with sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder (macOS), ipconfig /flushdns (Windows) or resolvectl flush-caches (systemd-resolved).

Quick checklist

  1. Read the browser error: name resolution, or a connection or TLS error after DNS succeeded?
  2. Query A, AAAA and CNAME for both the apex and www.
  3. Confirm the NS records point to the provider where you edit the zone.
  4. Compare 1.1.1.1, 8.8.8.8 and an authoritative server queried with +norecurse.
  5. Note the status: NXDOMAIN, NODATA, SERVFAIL, REFUSED or timeout.
  6. Check remaining TTLs before concluding that a change “hasn’t propagated”.
  7. Rule out the hosts file, VPN, browser DNS over HTTPS and local caches.

Check it with WebTraceCheck

For a view from outside your own network, WebTraceCheck can run a DNS or website check without an account. Its website audit inspects DNS, HTTP responses, redirects and technical SEO, and shows each observation with its source and the limits of the measurement. To reproduce the problem in a real browser away from your hosts file, VPN and local caches, sign in with GitHub and open a temporary cloud browser with the browser engine, region and device mode you choose.