When DNS fails, a healthy website becomes unreachable. The server is running, the application is fine, but the visitor's browser cannot find out where to connect. The browser reports something like "server not found", and that is all it says.

This guide helps you find out what kind of failure it is and where it happens. For a plain explanation of the terms, see DNS resolution.

Read the symptom first

A DNS answer carries a status. Four outcomes cover most cases.

What you see Meaning Usual causes
NXDOMAIN The name does not exist A typo, a deleted record or zone, a missing delegation, an expired domain
Empty answer, status NOERROR The name exists, but has no record of the type you asked for No AAAA record on a site that is IPv4-only. This is often normal
SERVFAIL The server could not complete the lookup The zone's name servers do not answer or answer wrongly, a broken delegation, a failed DNSSEC check
Timeout, no answer Nothing replied in time A blocked network, an overloaded or down resolver, a firewall

RFC 1035 defines the codes for "server failure" and "name error" (the name does not exist). RFC 8499 explains the common names SERVFAIL and NXDOMAIN. The empty answer is sometimes called NODATA. It is not a status of its own, only a successful answer with nothing in it.

Test with dig

dig is the standard tool on Linux and macOS. It prints the status in the header line.

dig example.com A
dig example.com AAAA

Look for the line status: in the output. To keep only the addresses:

dig +short example.com A

Windows has nslookup:

nslookup example.com

Ask a different resolver

By default you ask the resolver your network gave you. To ask another one, name it after @:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

If your usual resolver fails and the others answer, the problem is the resolver or the path to it, not your domain. If every resolver fails, the problem is in your zone or your delegation.

Ask the authoritative servers

Find which servers are responsible for the domain, then ask them directly:

dig example.com NS +short
dig @ns1.your-dns-provider.example example.com A

An authoritative server knows the zone from its own data. If it returns the right address while public resolvers do not, the answer is probably cached somewhere, or the delegation at the registrar points elsewhere. If the authoritative server does not answer at all, your DNS provider has a problem.

Walk the chain

dig +trace starts at the root and follows each delegation:

dig +trace example.com

It shows which step stops answering. A trace that ends with the registry giving no name servers for your domain suggests a delegation problem, often a registration that has lapsed.

Narrow it down

Work from the outside in.

  1. Do other networks see it? Try a phone on mobile data and a public resolver. If only your network fails, look at local resolvers, a VPN, or a filter.
  2. Did the domain expire? An expired registration is a common reason for sudden NXDOMAIN. Check the date as described in How to Check When a Domain Expires.
  3. Did the delegation change? If name servers at the registrar were changed, compare the NS records at the registry with the servers where the zone actually lives.
  4. Did a record change? A deleted or mistyped A, AAAA, or CNAME record gives an empty answer or a wrong one.
  5. Is the local machine at fault? Check the hosts file, flush the local cache, and test from another device.

Why a fix does not show up everywhere at once

Resolvers cache answers. Positive answers are kept for the record's time to live (TTL). Negative answers are cached too: RFC 2308 describes caching of "name does not exist" and "no data" answers, using the time given by the zone's SOA record. A resolver that heard NXDOMAIN a moment before you created the record may keep saying so until that time runs out.

A SERVFAIL may be cached as well, though RFC 2308 asks that such caching not exceed five minutes.

So after a fix, test against the authoritative servers first. They show the truth. Public resolvers catch up as their caches expire.

A and AAAA: a partial outage that hides well

An A record holds an IPv4 address (RFC 1035). An AAAA record holds an IPv6 address (RFC 3596). A site may have both, or only A.

A missing AAAA record is normal. A wrong one is not: a visitor whose connection prefers IPv6 can be sent to an address where nothing answers, while visitors on IPv4 see a working site. If reports of "the site is down" come from only some users, compare dig example.com A with dig example.com AAAA.

What UptimeWire checks

Once an hour, for every website, UptimeWire resolves the website's host name with the standard system resolver and looks at the answer:

  • The check passes when the name resolves to at least one public address.
  • It fails when the domain does not exist (NXDOMAIN) or when the name resolves only to private addresses.
  • It shows unknown when the name server did not answer. Unreachable DNS says nothing sure about the domain, so no warning is sent.

When the check turns from passing to failing, UptimeWire sends one warning by email and by Telegram, with the reason. A DNS warning is not an incident and does not go to webhook or chat channels.

The ordinary website check also fails when the name cannot be resolved, with the reason "the domain name could not be resolved". After repeated failures that check can open an incident.

UptimeWire does not detect changes to DNS records, does not follow propagation, does not query other record types such as MX or TXT, and does not validate DNSSEC. It tells you that the name stopped resolving, not why.

Checklist

  • Note the exact status: NXDOMAIN, empty answer, SERVFAIL, or timeout.
  • Query two public resolvers and the authoritative servers.
  • Check the registration date and the name servers at the registrar.
  • Compare A and AAAA answers.
  • Remember caching before you decide a fix did not work.
  • Keep a record of what changed and when.