DNS monitoring and drift detection

Each run queries A, AAAA, MX, NS, TXT, CNAME, CAA and SOA records and records exactly what came back. Host records are looked up on the monitored hostname; MX, TXT and the mail policy records are looked up on the registrable domain, because that is where they live.

Default interval

1 hour

Minimum interval

15 minutes

Record types

A AAAA MX NS TXT CNAME CAA SOA

Also verifies

SPF · DMARC · DKIM

Comparison is order-insensitive. Round-robin A records come back in a different order on every query, and a naive array compare would report drift several times an hour, forever. Values are normalised, sorted and de-duplicated; MX records sort by priority then exchange; TXT chunks are joined before anything is compared.

This is the rule the whole check is built around, and it is worth stating plainly.

If you declare that your A record should be 203.0.113.10 and it is not, that is a contract you wrote being broken. The check fails, an incident opens and you are notified.

If a record you never declared changes, the check reports it and goes degraded — visible on the dashboard, recorded as an event, in the alert list — but it opens no incident and pages nobody. Somebody on your team may well have made that change on purpose ten minutes ago.

Turn on strict mode and every record must match exactly. That is the right setting for a domain that should never move, and the wrong one for a site behind a CDN that rotates addresses.

The check keeps a baseline: the last complete observation, stored against that specific scheduled check. When a run differs, you get one event describing exactly what changed — which record type, the old values, the new ones — and the baseline advances.

The next run compares against the new reality and passes. There is nothing to acknowledge and nothing to clear.

The alternative was diffing against “the last good run”, and it does not work: after an intentional change the old run stays the reference, the check fails on every run after that, and the incident never closes. There is no action a user can take to make it stop short of deleting the check.

Two related safeguards. A run whose lookups failed does not overwrite the baseline, so a resolver outage cannot redefine normal. And an ad-hoc “run this now” never touches the baseline at all — only the scheduled check owns it.

Mail authentication lives in DNS and fails silently — the first sign is usually a customer saying they never got the email. Pulse parses these rather than pattern-matching them:

• SPF — found in your TXT records, with its policy qualifier read out.
• DMARC — looked up at _dmarc on the domain, with its policy reported.
• DKIM — checked at the selectors you name, and this one catches a genuinely nasty case: a published key with an empty p= value is a revoked key. A check that only asks “is there a record?” passes happily while none of your mail can be signed.

By default the check uses a pinned resolver rather than whatever the host machine happens to be configured with, and records which one answered in the result. A local resolver cache can hide a real change for the length of its TTL, and “no drift” from a stale cache is indistinguishable from “no drift” from the truth. You can name your own resolvers, which is how you confirm your authoritative nameservers and a public resolver actually agree.

A resolver timeout or a SERVFAIL is reported as degraded, never as a failure. That is our problem, not yours, and paging you for it would train you to ignore the check.