DNS monitoring with record-aware expected values

The three ways DNS ruins a week

Hijacks and takeovers. Someone gets into your registrar account and repoints the apex, or a dangling CNAME to a decommissioned bucket gets claimed by a stranger. Your domain resolves and responds; it is simply not your site any more, and nothing in a conventional uptime check goes red.

Expired domains. The renewal card expired, the notice went to an inbox nobody reads, and the registrar pulls the nameservers. Records vanish and the domain lands on a parking page.

Botched migrations. Moving providers leaves gaps: an A record updated but its AAAA still pointing at the old box, an MX record dropped so mail bounces silently for a day, an SPF record lost so your invoices land in spam. Everything works from your laptop, which cached the old answer.

What the DNS probe checks

A DNS monitor resolves a hostname for a record type you choose and judges the result. Six types are supported, and each one knows where its value lives:

The first failure is the blunt one: no record of that type exists. That single check catches an expired domain, a deleted record, and a zone that failed to load, reporting as "No A record for example.com".

The second, optional and much more interesting, is the expected value. Give the monitor a value and at least one returned record must contain it. The match is scoped to the record's value field rather than the whole response, which is why the record type matters: A is matched on its address, CNAME, MX, and NS on their target, TXT on its text content, including a long record split into chunks. Matching the whole answer would happily match a TTL.

Because the match is a substring test, you can be as specific or as loose as needed. Assert the exact IP of your load balancer, or only the domain part of a CNAME target so a CDN edge rename does not page you.

Unlike the other check types, a DNS monitor never opens a socket. It only resolves a name, so a record legitimately pointing at a private address is valid to assert on. Underscores are allowed, so _dmarc.example.com and _acme-challenge.example.com both work.

Setting up a DNS monitor

• Create a monitor and choose the DNS record type.
• Enter the hostname to resolve. Just the name: example.com or _dmarc.example.com.
• Pick the record type. A is the default and the most common starting point.
• Optionally enter an expected value. Leave it blank and the monitor asserts only that the record exists.
• Pick an interval. Five minutes on the free plan is ample for DNS; one-minute checks on Pro are there for a change window.
• Attach notification channels, or leave it unrouted to alert every channel on the team.

DNS monitors earn their keep in sets. A domain you care about deserves an A monitor pinned to your load balancer, an NS monitor pinned to your provider, an MX monitor if you receive mail there, and a TXT monitor on the SPF record. Tag them with the domain and a registrar-level compromise lights up as a cluster.

They run on the free plan: ten monitors permanently, five-minute checks, a public status page, and 30 days of history, with no card. Alerts reach email, ntfy, Telegram, Slack, Discord, and generic webhooks, every one available on free as well as Pro, with exactly-once delivery per transition per channel. Pro is one flat price for the whole team with no per-seat or per-monitor charge: 50 monitors, one-minute checks, a year of history, unlimited status pages and members, and custom domains, after a 14-day trial.

Questions people ask