DNS Monitoring: Why DNS Takes Sites Down and Which Records to Watch

Why does a DNS failure look like a total outage?

Every visit to your site starts with a lookup. The visitor's device asks a recursive resolver (their ISP's, or a public one such as 1.1.1.1 or 8.8.8.8), which asks the root servers, then the servers for your top-level domain, then your own authoritative name servers. Only when that chain returns an address does the browser connect to you.

If any step fails or returns the wrong answer, the request never reaches your infrastructure. Your server logs show nothing unusual, your internal health checks pass, and your error rate may even fall, because fewer requests are arriving. The only way to see a DNS failure is to do a lookup from outside, the way your users do.

Caching makes DNS problems confusing in both directions. Resolvers keep answers for as long as the record's TTL allows. During a break, people with a cached correct answer keep working, so reports come in patchily. After a fix, people with a cached wrong answer stay broken until their cache expires.

What breaks DNS?

• The domain expiredWhen a registration lapses, the registrar stops the domain resolving to your servers, often pointing it at a parking or renewal page. Website, API and email all fail together. The domain expiry monitoring guide covers how that happens and how to prevent it.
• A record was edited by mistakeA typo in an IP address, a record deleted because it looked unused, a change made in the wrong zone, or an infrastructure-as-code run that removed records it did not know about. These are the most common DNS outages, and they are entirely self-inflicted.
• Propagation and TTLsAfter a change, resolvers keep serving the old answer until its TTL runs out, so a record with a 24-hour TTL can take a day to change everywhere. Negative answers are cached too: if a name returned "does not exist" before you created it, resolvers can keep saying so for the negative-caching time set in your zone's SOA record.
• Name server changesMoving DNS providers means changing the NS records at your registrar. If the new zone is incomplete when you switch, records go missing. If one of the listed name servers does not answer for the zone (a lame delegation), lookups become slow or fail intermittently depending on which server a resolver tries.
• DNSSECWith DNSSEC, the zone's signatures expire and must be renewed, and the DS record at the registry must match the zone's signing key. If signatures lapse, or you move providers without updating or removing the DS record, validating resolvers return SERVFAIL. Large public resolvers such as Google Public DNS and Cloudflare 1.1.1.1 validate, so the site breaks for many users while still working on networks that do not.
• Dangling CNAMEsA CNAME still points at a cloud resource, SaaS app or storage bucket that was deleted. The hostname breaks, and if someone else can claim the target name, they can serve content on your subdomain.
• Provider outages and attacksYour authoritative DNS provider can fail like any other service, and a compromised registrar or DNS account lets an attacker repoint your records or name servers.
• Email recordsA deleted MX record or a broken SPF or DMARC TXT record stops or degrades email delivery while the website stays up, so nobody notices until replies stop arriving or messages start landing in spam.

Which DNS records should you monitor?

• A and AAAAThe IPv4 and IPv6 addresses for your apex domain, www and API hostnames. A wrong AAAA record breaks only IPv6 users, which makes it hard to spot without a check.
• CNAMEHostnames that point at a CDN or hosting platform. A changed target means traffic bypasses the CDN or goes nowhere.
• NSThe name servers for your domain. An NS change you did not make is one of the strongest signs of a compromised registrar or DNS account.
• MXYour mail servers, with their priorities.
• TXTSPF on the domain itself, DMARC at _dmarc.example.com, DKIM at selector._domainkey.example.com, and verification tokens that some services re-check periodically.
• Resolution timeHow long a lookup takes. A sudden rise can mean one of your name servers has stopped answering and resolvers are retrying the others.

Alert on change, or alert on mismatch?

There are two ways to grade a DNS answer, and each suits different records.

• Alert when the records changeThe monitor remembers the first answer it sees and fails when a value is added or removed. Good when you do not know the values in advance or a provider manages them. You accept intended changes so the new answer becomes the baseline.
• Alert when they do not match an expected listYou write down the values the records must have. Good for records you control exactly: NS, MX, SPF and the IPs of your own servers.

Within expected values, exact matching also fails when an unexpected extra record appears, which is what you want for NS and MX: an extra mail server you did not add is worth an alert. Some providers return a changing set of addresses, which makes exact matching noisy. CDNs often return different IPs by location and over time, so monitor the CNAME that points at the CDN rather than the addresses behind it.

Which resolver should a DNS check ask?

A check can ask a public recursive resolver or your authoritative name server directly, and the two answer different questions. A recursive resolver shows what users see, including caching and DNSSEC validation. Your authoritative server shows what you have published, with no caching, so a change shows up immediately. Use the authoritative server to confirm an edit took effect, and public resolvers to confirm users can resolve you.

For a one-off check after a change, the free DNS checker looks a record up on Cloudflare, Google and Quad9 at once and shows whether they agree, with TTLs, which is a quick way to see how far a change has propagated.

How to change DNS safely

• Lower the TTL of a record you plan to change at least one full old-TTL period beforehand, so caches pick up the new value quickly. Raise it again once the change is stable.
• Export or version-control the zone before editing it, so you can restore a deleted record exactly.
• When moving DNS providers, build and verify the complete zone at the new provider before changing name servers at the registrar.
• With DNSSEC, follow your providers' key-change procedure, and never remove the old keys before the DS record at the registry has been updated and its TTL has passed.
• Turn on two-factor authentication and registrar lock for your registrar and DNS accounts.
• Check the result from outside after every change, from more than one resolver.

How DNS monitoring works in SutramX

SutramX has a DNS records monitor type. Each monitor looks up one record type for one domain from each of the monitor's check locations.

• Record typesA, AAAA, CNAME, MX, TXT and NS. Names with underscores such as _dmarc and _domainkey work. Only public domain names can be checked; internal names such as .local or .internal are rejected.
• Two modesThe records change: each location keeps its own baseline, so geo-DNS answers do not cause false alerts, and you accept a change manually with Accept current records or automatically once it has lasted between 5 and 10,080 minutes. Or they don't match what I expect: up to 50 expected values, matched exactly or with other values allowed.
• Fair comparisonsHost names are compared lower-cased without the trailing dot, IPv6 addresses in compressed form, split TXT strings joined into one value, and records as a set, so order, duplicates and TTLs never cause a failure.
• Lookup failuresNXDOMAIN, SERVFAIL (often a DNSSEC or name server problem), a refused query and a timeout each fail the check as DNS resolution failed, with a message that says which.
• ResolverBy default each location uses its own resolver. You can set a public IP instead, such as your authoritative name server's, to get the same answer everywhere.
• HistoryThe monitor's response time is how long the lookup took, and the DNS records card shows each location's current answer, what was added or removed, and up to the 200 most recent changes.

Next steps

• DNS checker across public resolvers
• DNS record monitor setup
• Network and DNS monitoring in SutramX