DNS monitoring: know when a record changes or stops resolving

What the check queries

A DNS monitor asks public recursive resolvers, Google at 8.8.8.8 and Cloudflare at 1.1.1.1, for the record type you chose and compares the answer with what you told Tenium to expect. It tries twice with a timeout of up to 10 seconds, and the time the lookup took is stored as the response time. The record types are A, AAAA, CNAME, MX, NS and TXT.

Because the questions go through recursive resolvers, you see what the public internet sees, including cached answers. You cannot query one specific authoritative nameserver, and you will not see a propagation map. The upside is that a check passing here means real visitors resolve the name; the downside is that changes show up only after the record's TTL expires.

Expected values: subset, not exact

Put one or more values in the expected field, separated by commas or new lines. Each must appear in the answer; additional records in the answer are fine. Comparison ignores case and trailing dots. So an A monitor expecting 203.0.113.10 passes when the answer is 203.0.113.10 and 203.0.113.11, and fails the moment 203.0.113.10 disappears. The failure message prints what was found, which makes a hijack or a mistaken edit easy to read.

Some formats deserve a note. MX answers are matched on the host name alone or on priority plus host ("10 mx1.clienta.com"). TXT chunks are joined into one string before comparing, so long DKIM keys compare as written; a TXT monitor needs the whole value. If you leave the expected field empty, the check only requires that the record exists, which catches deletion but not substitution. Set the expected value when you want protection against change.

Records worth watching

A short list gives most of the safety:

• A or AAAA of the apex and www: the classic "someone pointed the site elsewhere" detector.
• NS of the domain: set both nameservers as expected; this is also the best available alarm for a nameserver hijack, since the registration data itself is not watched.
• MX: mail that silently stops arriving is worse than a site that is visibly down.
• TXT at _dmarc.clienta.com and for SPF: verifies that policy records survive a DNS provider migration.
• CNAME of a status or shop subdomain pointing to a SaaS: catches dangling records that could be taken over.

Cloudflare, CDNs and flattened records

If a hostname is proxied, its A record shows the provider's addresses, which are shared and can change without notice. Expecting those is brittle. Watch the NS record to see that the zone is still delegated to the provider, and use website monitoring to see that traffic reaches your origin. CNAME flattening, used by some providers at the apex, makes a CNAME answer look like an A record, so choose the record type that the public sees.

Planned changes without noise

When you migrate a site you will change records deliberately, and the monitor will fail in the minutes between your edit and the new value being served everywhere, because different resolvers hold different cached answers. Two habits help. Lower the TTL a day ahead so caches turn over quickly, and put the monitor into a maintenance window during the switch, then update the expected value and end the window. If you forget to update the expected value, the monitor keeps pointing to the old address and will keep reporting an incident, which is the correct behaviour.

Failures are specific: no record found, SERVFAIL (the zone's servers are failing or DNSSEC is broken), a query timeout, or "record is X, expected Y". DNS monitoring starts on the Starter plan, and check intervals follow your plan, from 1 min on Starter to 30 s on Pro. The 2 regions that run checks all use the same two public resolvers.