DNS monitoring: what to monitor, and what an uptime tool can see

DNS monitoring means checking, on a schedule, that your domain's DNS gives the right answers, gives them fast, and does not expire. The name covers three different jobs: DNS query monitoring (does a lookup return the right record), DNS server monitoring (are your nameservers up and consistent) and DNS traffic monitoring (how many queries do you receive). An uptime tool does the first well, part of the second, and none of the third.

This guide explains each job, lists what to check, shows the failures that hurt most, and says plainly where an outside check stops being enough.

Why DNS failures hide from HTTP monitors

Every request starts with a lookup. When DNS is wrong, an HTTP monitor sees a symptom: a timeout, a connection error or a certificate mismatch. It does not tell you the cause. Worse, some DNS failures give no HTTP error at all. A wrong A record can point your domain at an old server that still answers with HTTP 200. A deleted MX record does not touch your website, and your email stops arriving. A changed nameserver can send visitors to a page someone else controls.

So DNS needs its own checks, next to your uptime monitoring.

Query, server and traffic monitoring: three different jobs

Traffic data lives with whoever answers your DNS. Amazon Route 53 can send public hosted zone query logs to CloudWatch Logs, and Cloudflare shows DNS analytics in its dashboard and through a GraphQL API, with a retention that depends on the plan. Resolver caching means such logs show only part of what users ask, so read them as a sample, not a count. An outside check cannot see any of this traffic, and a tool that claims to is guessing.

What to check

• Resolution of the records that matter. The A and AAAA records of your domain and of www, the CNAME records of services you use, the MX records for email, and the TXT records for SPF, DKIM, DMARC and domain verification. Check the value, not only that an answer exists.
• Record changes. Keep the expected set of records and alert when it changes. Alerts that name what was added and removed save time.
• Response time. A slow lookup adds delay to every first visit. Track it per resolver or nameserver.
• Every nameserver. Ask each authoritative server directly. One dead server often causes only intermittent failures, which are the hardest to debug.
• Delegation. The NS records at the registry must match the nameservers your provider gave you.
• DNSSEC, if you use it. Signatures expire. When they do, validating resolvers return SERVFAIL, while resolvers that do not validate keep answering. The result is an outage that only some users see.
• Domain expiry. Registrars differ on grace periods, from none to several weeks depending on the registrar and the TLD, and DNS can stop soon after the expiry date. Warn at least 30 days ahead.
• Propagation after a change. Resolvers cache an answer for the record's TTL. Lower the TTL before a migration, then compare answers across resolvers with the DNS propagation checker.

Common DNS failures, and how they look

• The domain expired. The site and email vanish together. A domain expiry monitor catches it weeks before.
• A stale record after a migration. Some visitors reach the old host. The new host looks fine from your laptop.
• Email stops after a provider change. Missing MX, SPF or DKIM records. The website stays up, so nothing alerts you.
• One resolver or one region fails. Users on one network cannot reach you. Compare answers from several resolvers before you blame your server.
• A TTL surprise. You fix a record and the old answer lives on in caches until the TTL runs out. Plan the TTL before you change the record.
• An unexpected NS or A change. It may be a mistake at your provider, or it may be a hijack. Alert on it and ask who changed it.

A checklist for a DNS change

Most DNS outages start with a planned change. This order avoids the usual surprises:

1. Lower the TTL first. Set a short TTL, for example 300 seconds, on the records you will change, then wait for the old TTL to run out before you touch the values.
2. Make the change, then ask your own nameserver. A direct query to your authoritative server skips resolver caches, so you see the new value at once.
3. Check propagation from several resolvers. Different resolvers hold the old answer for different lengths of time.
4. Keep the old host running. Leave it up until the old TTL has passed, so slow caches still reach something that works.
5. Raise the TTL again, and save the new record set. Add a record-change monitor with the final values, so the next unexpected change raises an alert.

How Uptrack covers DNS

Uptrack has four DNS-related monitor types. They are on paid plans; the free plan has HTTP and keyword monitors only.

• DNS: resolve a name and check the answer against the value you expect, with an optional custom DNS server so you can query your own nameserver instead of a public resolver.
• DNS record change: watch the set of A, AAAA, CNAME, MX, TXT, NS or PTR records and alert when it changes, with the added and removed records listed.
• Domain expiry: an RDAP lookup with a WHOIS fallback for TLDs without RDAP. It alerts a set number of days before the domain expires (30 by default).
• DNS blocklist: check your host's IPv4 address against DNSBL zones such as SpamCop and Barracuda. Spamhaus may not answer these lookups.

DNS checks run every 30 seconds on every paid plan, and an alert needs consecutive failed checks, which keeps one lost packet from paging you. They run from Nuremberg, Ashburn and Hyderabad: Germany, the US and India. See the DNS monitoring page for the full list.

Want to look before you monitor? These free tools need no sign-up: DNS lookup, DNS propagation checker, MX lookup, TXT record lookup, WHOIS lookup and the domain expiry checker. Background reading: what DNS propagation is.

When an uptime tool is not enough

• You need traffic numbers. Queries per second, top names and attack spikes come from your DNS provider's analytics or your server logs, not from outside checks.
• You run your own nameservers. Outside checks show the answers. For CPU, memory, query rate and cache hit ratio, export metrics from the DNS software and watch them in a metrics tool.
• You must know why a record changed. Monitoring shows that and when. The provider's audit log shows who.
• You need resolver-level views from many networks. DNS checks here run from three locations. For a wide look, use the propagation checker after a change.

DNS monitoring questions