DNS Monitors

A DNS monitor watches a domain, not a single record. One monitor covers your domain's apex — plus every name a zone file you paste declares — and on each check it queries ten record types at each of those names.

What the monitor expects is the set of records it discovered, held one row per (name, type, value). Nothing is transcribed into an expected-value box, and nothing is compared as one joined blob, so a record appearing beside the ones you already have is reported as an addition rather than hidden inside a string that changed.

DNS records control how users reach your website, where your email is delivered, and how third-party services verify your domain ownership. Monitoring them helps you:

• Detect unauthorized changes — a record edited without authorization can indicate a compromised registrar account or a domain hijacking attempt

• Catch misconfigurations — a typo or a wrong value shows up as a finding instead of as an outage

• Notice delegation changes — nameserver records changing unexpectedly is a signal worth acting on immediately

What We Can and Cannot See

These limits come from DNS itself, and they shape everything below. They are stated first because a monitor is only as useful as your understanding of what it covers.

• We cannot list your DNS records. There is no query that answers "what records exist for this domain": ANY queries are answered NOTIMP, and zone transfer is disabled on every public nameserver worth the name. A zone file you paste is the only channel through which the names in your zone can reach us.

• Without a zone file, a monitor covers one name — your domain itself. A record at staging.example.com or _dmarc.example.com is invisible to us unless that name was in a zone file you pasted.

• The zone file is a snapshot. It is read once, parsed, and never stored. Names added to your zone afterwards are not tracked until you paste again.

• Ten record types, listed below. SOA, SRV, PTR, DNSKEY, HTTPS and the rest are not checked.

• We resolve through one recursive resolver. We do not query each of your authoritative nameservers, so we do not detect disagreement between them and we do not detect regional differences.

• Detection latency is floored by your record's TTL, not by your check interval. A recursive resolver serves a cached answer, so a 15-minute check against a 24-hour TTL does not find out fifteen minutes after a change.

• We do not report DNSSEC validation state.

Additions inside a tracked name are detected, because a DNS query returns the full record set for a name and type rather than a sample of it. A sixth MX record appearing at a name we already track arrives in the same answer as the other five. Only the discovery of new names needs the zone file.

Supported Record Types

Every check queries all ten types at every tracked name.

A Records

A records map a domain name to an IPv4 address. These are the most common DNS records and control where your domain points.

example.com.  A  192.0.2.1

AAAA Records

AAAA records map a domain name to an IPv6 address. Addresses are normalized to one canonical form, so 2001:DB8::1 from a zone file and 2001:db8::1 from a resolver are the same record.

example.com.  AAAA  2001:db8::1

CNAME Records

CNAME (Canonical Name) records create an alias from one domain name to another. These are commonly used for subdomains that point to external services.

blog.example.com.  CNAME  example.netlify.app.

A CNAME at a name suppresses A, AAAA, CAA, TLSA, DS and SVCB tracking at that name. The addresses, issuance policy, keys and service bindings a resolver returns for an aliased name belong to the alias target, not to your zone, and tracking them would alert you every time an unrelated third party rotated an address or changed its certificate authority.

MX Records

MX (Mail Exchange) records specify which mail servers handle email for your domain. Incorrect MX records mean you won't receive email. The preference number is part of the record, so a preference change is a change.

example.com.  MX  10 mail.example.com.

TXT Records

TXT records store text data and are commonly used for domain verification, SPF email authentication, and DKIM keys. A record longer than 255 bytes arrives as several character-strings; they are joined back into the one value you configured.

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

NS Records

NS (Name Server) records specify which DNS servers are authoritative for your domain. Changes to NS records could indicate domain hijacking.

example.com.  NS  ns1.example-dns.com.

CAA Records

CAA (Certification Authority Authorization) records name the certificate authorities allowed to issue certificates for your domain. A CAA record appearing or changing decides who can get a certificate for your name, which makes it a finding worth reading. Each record is stored in its published form — flags, tag and quoted value — whichever form a resolver answers it in.

example.com.  CAA  0 issue "letsencrypt.org"

A Cloudflare-hosted zone lists Cloudflare's own CAA records at the first review. Cloudflare publishes CAA records for the certificate authorities its edge certificates use, and its zone export leaves them out. The review screen shows them beside the ones your export declares, so you choose at import whether each one alerts.

TLSA Records

TLSA records publish DANE certificate associations: which certificate or public key a TLS client should expect at a service, such as _25._tcp.mail.example.com for SMTP. A TLSA record changing without a matching certificate rollover breaks every client that validates it. Each record is stored as usage, selector, matching type and the association data in lowercase hex.

_443._tcp.www.example.com.  TLSA  3 1 1 0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6

DS Records

DS (Delegation Signer) records live in the parent zone and anchor your domain's DNSSEC chain of trust to your signing key. A DS record changing or disappearing at your apex means the delegation's trust anchor moved — a key rollover you started, or one you did not. Each record is stored as key tag, algorithm, digest type and the digest in lowercase hex.

example.com.  DS  60485 5 1 2bb183af5f22588179a53b0a98631fad1a292118

SVCB Records

SVCB (Service Binding) records tell clients where and how to reach a service — its target host, priority, and parameters such as the ALPN protocols and address hints. Each record is stored in its canonical form, with the target name lowercased and without its trailing dot and the parameters in key order.

_8443._foo.api.example.com.  SVCB  16 foo.example.org. mandatory=alpn,ipv4hint alpn="h2,h3-19" ipv4hint=192.0.2.1

Configuration Options

Domain

The domain the monitor covers. Every check queries this name, and it is the origin that relative names in a pasted zone file are resolved against.

Zone File

Optional, and the only way to cover names other than the domain itself. Paste a BIND-format zone file — the export button in your DNS provider's dashboard produces one — and every name it declares is added to the set the monitor sweeps.

The parser reads standard RFC 1035 zone-file syntax: <owner> [<ttl>] [IN] <TYPE> <rdata> records, ; comments, absolute and relative names, @ for the apex, $ORIGIN and $TTL directives, records spread over several lines with parentheses, lines that start with whitespace to reuse the previous record's name, and quoted TXT character-strings, CAA values and SVCB parameters. A TXT value is read as DNS reads it: unquoted words are separate character-strings joined with nothing between them, so write "v=spf1 -all" in quotes to keep its space.

An entry the parser cannot use is never silently dropped. $INCLUDE and $GENERATE directives, classes other than IN, record types outside the ten above, and names outside the monitor's domain are all reported back on the review screen with their line number and a reason. An import that decides what you monitor is the worst possible place for a silent drop.

The pasted text is never stored. It is parsed on submit; the records and the import date are kept, and the text is discarded. Re-importing later means pasting again.

Check Interval

How often the monitor sweeps. Intervals range from 15 minutes to 24 hours, and the default is once a day — DNS changes are human-caused and human-paced, and a record's TTL puts a floor under detection latency that a faster interval cannot get below.

A check costs one ping, however many names and types it swept.

Reviewing Records

Creating a monitor from the dashboard runs discovery immediately and lands you on a review screen: every record found, grouped by name and then by type, each with a checkbox. Submitting saves them.

Records you uncheck are still stored, switched off. That is deliberate:

Without it, a record you declined would be rediscovered as new on the very next check and alert forever.

A monitor created through the API has no review step — there is no reviewer standing at the other end of an API call — so it imports and enables everything discovery found. Turn off what you don't want through the records endpoint.

Declared but not resolving

A record your zone file declares but the resolver does not answer for is shown on the review screen as its own group, saved switched off. It is a real finding at import time — a stale delegation, a change that never published, a typo between the console and the zone.

On a proxied zone this is the normal case, not a broken one. A record behind a reverse proxy does not appear in its own zone export, and the name answers with the proxy's address instead of yours. Neither channel is wrong: your record genuinely is not in public DNS. Nothing is misconfigured, and there is usually nothing to fix.

It does not alert on later checks unless you switch it on. As a standing alert it would be a comparison against a snapshot that only ever gets older — every legitimate change you make after the import would widen a divergence we kept emailing you about.

Record Statuses

Each tracked record carries its own state.

A value edited inside a set holding several records reads as one missing record plus one new one. That is truthful rather than a bug: DNS gives an individual record no identity of its own, so editing one of five MX values is indistinguishable, on the wire, from removing one and adding another. Changed is used only where the diff can attribute the edit without guessing — a name and type holding exactly one watched record, answering with exactly one differing value.

A newly discovered record is imported switched off, on purpose. You have two honest responses to "this appeared and you didn't put it there" — fix your DNS, or accept it — and switching the record on is the second. Importing it switched on would make "accept" the thing that happens by not reading the email.

Monitor Statuses

The monitor rolls its records up into one of three statuses:

A failed query never reads as records vanishing. If a query for one name and type does not answer, no record under it is diffed at all. Otherwise a resolver having a bad minute would tell you your entire zone had disappeared.

Alerting

DNS results reach every alert whose scope covers the monitor: your team-wide alerts, any alert scoped to DNS monitors as a kind, and any alert scoped to that one domain. A domain monitor is noisier than a website check — it reports every record that stops resolving, changes, or newly appears across the whole zone — so a DNS-scoped alert on its own channel is usually worth setting up rather than letting all of it land wherever your outage alerts do. See Alerts.

Notification is edge-triggered on the monitor's status. If a second record is discovered while the monitor is already reporting Changed, that discovery does not produce its own immediate email; it appears in the next repeat, whose body lists everything currently outstanding.

Domain Registration

Every DNS monitor also watches when its domain's registration expires. Once a day the monitor asks the domain's registry over RDAP, the public protocol registries publish registration data through, and shows the expiry date, the registrar and the registry's statuses on the monitor's page. There is nothing to enter, and the lookup costs no pings.

Alerts reach the same alerts as the monitor's DNS results:

• Expiring alerts 30, 14, 7 and 1 days before expiry, and every day within the window from there on; Expired alerts every day.

• A registry status of redemptionPeriod, pendingDelete, clientHold or serverHold alerts every day whatever the date says: each means the domain has stopped resolving, or is about to.

• Lookup failing alerts once when it begins. While the registry is unreachable, the last expiry date we read keeps alerting as it approaches.

Check Now on the monitor's page looks the registration up as well, so a renewal shows straight away. Set the warning window on the monitor's edit page, from 1 to 365 days. The domain must be the registered name, example.co.uk rather than www.example.co.uk: a registry holds no record for a name below it.

Best Practices

Paste the zone file

Without it a monitor covers one name. With it, www, _dmarc, _domainkey, your API subdomain and everything else your zone declares are covered by the same monitor, on the same interval, attached to the same alerts.

Re-import after you restructure

The zone file is a snapshot. After adding a subdomain, or migrating providers, paste the export again so the new names are tracked.

Leave the interval long

DNS changes are rare in normal operation, and your records' TTLs put a floor under how quickly a change can be observed anyway. Daily is the default for good reason. Reserve short intervals for a domain you are actively changing.

Act on new records

A record you did not create is the finding this monitor exists for. Switching it on says "this is mine now"; leaving it off keeps it on the list of things needing your attention. Either is a decision — silence is not.

Watch your NS records

Your NS records determine who controls your DNS. They are swept along with everything else, and a change to them is worth investigating immediately.