Guide
What DNS failure means (and how to check yours)
When the internet's phone book stops answering for your domain, nothing else about your website matters.
Published · Updated
A DNS failure means the lookup that turns your domain name into a server address broke — browsers literally cannot find your website, no matter how healthy the server is. The three failures you will actually meet: NXDOMAIN (the name doesn't exist — usually an expired domain or a typo'd record), SERVFAIL (the nameservers responsible for your domain are broken or misconfigured, often DNSSEC), and no address records (the domain exists but no A or AAAA record points it anywhere). Run your domain through a DNS check to see which one you have — the fix is different for each.
What DNS actually does
Computers reach websites by IP address; humans type names. DNS is the lookup between the two — a chain of servers that answers “where is yourdomain.com?” with something like 203.0.113.7. That lookup happens before the connection, before the SSL certificate, before your application runs a single line. Which is why DNS failure is total failure: there is no error page, no logo, nothing — just the browser's own “can't find this site” screen.
The three failures, by name
NXDOMAIN — the name doesn't exist
The DNS system answered clearly: there is no such domain. The two everyday causes are an expired domain registration (one of the most common ways small-business websites die — the renewal email went to an old inbox) and a wrong name: a typo in a record, or a subdomain like www that was never actually created even though the bare domain works.
SERVFAIL — the nameservers are broken
The domain exists, but the servers responsible for answering questions about it returned an error. Usual suspects: a DNS provider outage, nameservers that were changed at the registrar but never set up at the new provider, or a DNSSEC misconfiguration — DNSSEC signatures that don't validate make resolvers refuse to answer at all, on purpose. If SERVFAIL started right after a provider migration or a DNSSEC change, that change is your cause.
No A/AAAA records — the name points nowhere
The domain resolves fine as a name, but has no address record for browsers to connect to. This happens mid-migration (old records deleted, new ones not yet added), or when a record was removed by accident. Email can keep working while the website is gone, because MX records are separate — a confusing symptom that points squarely at missing A/AAAA records.
The “propagation” myth
When a DNS change misbehaves, someone will tell you to “wait 24–48 hours for propagation.” That is mostly folklore. DNS changes don't sweep across the earth in a wave — resolvers simply cache answers for as long as your record's TTL (time-to-live) told them to. If your TTL was 3600, every resolver that looked you up keeps the old answer for up to an hour, then asks fresh. Nothing is “still propagating” beyond your longest TTL; if a record is wrong after that, it is actually wrong at the source. This is also why a change can look instant for you and stale for a customer — you are simply talking to different caches. Our guide on why a site can be down for some people but not others digs into exactly that.
How to check your DNS
The free PingStuff DNS check looks your domain up from outside your network and reports what it finds in plain English. These are the actual report strings, one per failure above:
- NXDOMAIN → “This domain isn't pointing anywhere.” Check that the domain is registered and its records point to your server.
- SERVFAIL → “The domain's DNS servers returned an error.” Check your DNS provider's status and your nameserver settings.
- No records → “This domain has no address records.” Add an A or AAAA record pointing the domain at your server.
The technical detail — including the address your domain resolved to — sits under the plain explanation, so you can hand it to whoever manages your DNS.
Preventing the next one
- Turn on auto-renew at your registrar and keep the billing card and contact email current. Expired registration is the most preventable outage there is.
- Lower TTLs before a migration, not after. Drop the TTL to 300 a day ahead, make the change, confirm it, then raise the TTL back. That shrinks the stale-cache window from hours to minutes.
- Change one thing at a time. Moving host, DNS provider and enabling DNSSEC in one evening makes a SERVFAIL nearly undebuggable. Sequence the changes and verify each.