DNS monitoring

When DNS breaks,everything breaks.

DNS monitors run a real lookup against the resolver you choose and alert when the record stops resolving. Expired zones, botched migrations and dying resolvers surface as a named alert instead of a vague outage.

www.example.comA record
Host
www.example.com
DNS server
1.1.1.1
Record type
A
Resolved in 23 ms · checked every 60 s
6 record types

The records your stack depends on.

A and AAAA keep your hosts findable, CNAME holds your aliases together, MX routes your mail, TXT carries SPF and domain verification, NS proves your delegation still points home.

Each monitor queries one record type on a schedule. The monitor stays up while the lookup returns at least one matching record, and goes down the moment it fails or comes back empty.

  • A, AAAA, CNAME, MX, TXT and NS records
  • Up means at least one matching record answered
  • Failed and empty lookups alert immediately
Record type6 types
AAAAACNAMEMXTXTNS
Up while at least one MX record answers
Your resolver

Ask the resolver your users ask.

Every DNS monitor queries a DNS server you pick. Point one at a public resolver to see the internet's view of your zone, and another at the internal resolver your office and servers depend on.

When the two disagree, you have found the problem before anyone filed a ticket. The zone is fine, the office resolver is not, and the alert says which.

  • Resolver chosen per monitor
  • Public and internal resolvers side by side
One monitor per resolverapp.example.com
1.1.1.1 · Cloudflareresolves
8.8.8.8 · Googleresolves
10.0.0.53 · internalSERVFAIL
The zone is fine, the office resolver is not
First to know

The outage that hides behind other outages.

DNS failures rarely announce themselves. They arrive as a site that won't load, mail that silently queues and an API that times out, which sends the team debugging the wrong layer.

A dedicated DNS monitor with its own history turns the first question of an incident into a dashboard glance. Resolution time is charted per check, the same as response time on any other monitor.

  • Resolution time charted per check
  • Uptime and incident history per record
app.example.comDNS · A
Resolving / 7 days
100%
0 incidents
Resolution time
23 ms
avg this week
Resolver
1.1.1.1
per-monitor choice
Last 40 checks
Who runs this

For anyone who has said "it's always DNS".

Teams with many domains

Product domains, client domains, redirects and legacy zones. A monitor per critical record means a renamed nameserver or an expired zone gets caught in minutes.

Anyone who depends on MX

Mail keeps flowing only while MX records resolve. When they vanish, senders queue silently for days before bouncing, so an immediate alert is the difference between a blip and lost mail.

Platform teams mid-migration

Cutovers live and die on DNS. Watch the old record, the new record and both resolvers while the TTLs drain, and know the moment the world sees what you expect it to.

Scope

What it covers, and what it doesn't.

Covered

  • Lookups for A, AAAA, CNAME, MX, TXT and NS records
  • The resolver of your choice, set per monitor
  • Alerts when a lookup fails or returns no matching record
  • Resolution time recorded per check
  • Internal resolvers, since checks run from your instance
  • Alerts on 12 notification channels

Out of scope

  • Record content matching: the check confirms the record resolves, it does not compare the returned values against an expected answer
  • DNSSEC validation and zone-transfer auditing
  • Domain registration expiry: that is tracked on uptime monitors, alongside SSL expiry
Under the hood

For the technically curious.

A real resolver query

Each check performs an actual DNS lookup against the server you configured, not a lookup through a cached HTTP API. What the monitor sees is what a client using that resolver sees.

Typed queries

The check queries exactly the record type you picked. An A record that resolves while the MX is gone will not mask the mail problem, because those are two different monitors.

Internal DNS included

Split-horizon zones and office resolvers are only visible from inside the network. Your Checkmate instance is inside the network, so they get the same monitoring as public DNS.

Timing on every check

Resolution time is recorded per check and charted over time. A resolver that grows slow under load shows a trend long before it starts refusing queries outright.

FAQ

Frequently askedquestions.

DNS monitoring runs scheduled lookups for a specific record and alerts you when the record stops resolving. Checkmate queries the resolver you choose and records the result plus the resolution time of every check.

A, AAAA, CNAME, MX, TXT and NS records. Each monitor watches one hostname and record type pair, so a zone's critical records are typically covered by a handful of monitors.

Yes, per monitor. Point one monitor at a public resolver like 1.1.1.1 and another at your internal resolver, and you can tell a broken zone apart from a broken resolver at a glance.

It catches records that stop resolving, which covers many hijack and takeover scenarios. It does not compare returned values, so pair it with an HTTP monitor on the same host: if the record starts pointing somewhere wrong, the HTTP check fails on content or certificate.

Yes. Checks run from your self-hosted instance, so internal resolvers and split-horizon views that no hosted monitor can reach are fully monitorable.

Checkmate is one. It is open source under AGPL-3.0 and self-hosted, so you can monitor as many records and resolvers as you like for free.

Get started

Every feature,no paywall.

Checkmate is open source under AGPL-3.0. Self-host it and this feature ships free, on your servers, with your data.