How DNS breaks a working site
- The domain registration expired. The registrar's auto-renewal failed on an old payment card, and the domain stops resolving, or points somewhere else.
- The delegation is wrong. After a move to a new DNS provider, the registrar still lists the old name servers, or only some of the new ones.
- A record was changed or deleted. An edit meant for one subdomain hit another, or a cleanup removed a record something still needed.
- DNSSEC broke. Keys were rotated or the provider changed without updating the record at the registrar. Validating resolvers then refuse to answer at all.
- The DNS provider has an outage. Your records are fine, but nobody can ask for them.
Each of these looks, from a browser, like your site being down. An HTTP check catches the effect; a DNS check tells you the cause, and catches it for names that have no website, like a mail domain.
Which records to watch
| Record | What it does | Watch it for |
|---|---|---|
| A, AAAA | The IPv4 and IPv6 addresses of a name. | Your website and API hostnames. |
| CNAME | An alias to another name. | Subdomains that point at a hosting platform or CDN. |
| MX | The servers that receive a domain's email. | Any domain that receives mail. |
| TXT | Free text: SPF, DKIM and DMARC for email, domain verification for other services. | Mail domains, and domains other services verify. |
| NS | The name servers that answer for the domain. | Every domain you own: it is where delegation breaks. |
What a resolver's answer tells you
- An answer with records (response code NOERROR): the name resolves.
- NOERROR with no records: the name exists but has no record of that type. A deleted A record looks like this.
- NXDOMAIN: the name doesn't exist, or the domain itself is gone.
- SERVFAIL: the resolver couldn't get a usable answer: the name servers didn't answer, or DNSSEC validation failed.
- No answer in time: the resolver, or the network to it, is the problem.
Ask a public resolver, or the name servers?
A public resolver, like the ones your visitors' devices use, shows what the world sees, caching included. It catches delegation and DNSSEC problems, because it follows the whole chain from the root down. It can also keep serving a cached answer for a while after something changed.
Asking your name servers directly shows a change the moment it is made, but it skips the chain: a broken delegation or DNSSEC setup can look perfect from there. For uptime, the public view is the one that matters to your visitors.
Present, or correct?
A check that a record exists catches deletions, expired domains, broken delegation and outages. It doesn't catch a record that exists with the wrong value, say an A record pointing at an old server. Pair the DNS check with an HTTP check on the same name: if the address is wrong, the website check fails, and the two together tell you where to look.
Caching and TTLs
Every record has a time to live (TTL): how long resolvers may keep it before asking again. A fix you make in DNS reaches everyone only once the old answer's TTL has run out. Before a planned change, such as a server move, lower the TTL a day ahead, and raise it again once the move is done.
The registration date
The cheapest DNS outage to prevent is an expired domain. Turn on auto-renewal at the registrar, keep the payment method current, and make sure the registrar's emails reach an address someone reads.
How BBoxProbe handles it
- A DNS monitor asks for one record type of a name: A, AAAA, CNAME, MX, TXT, and NS.
- Each check asks 8.8.8.8, Google's public resolver, from each of the monitor's cities. The monitor is up when the answer comes back without an error and holds at least one record of that type.
- It doesn't compare the record's value with an expected one; add an HTTP monitor on the same name for that.
- Like every monitor, it counts as down only when enough of its cities fail, and the alert says what each city got: no valid answer, or no answer in time.
- It doesn't watch the domain's registration date.
How it works has every option of the three kinds of monitor.