DNS monitoring

Everything else is fine until the name stops resolving

A DNS monitor asks the resolver for your hostname on a schedule and alerts you when nothing comes back. Expired domains, zone migrations gone wrong, a deleted record: the outage nobody sees on the server.

Free for one monitor. No card needed.

shop.tidepool.ioResolves12 ms
  • A
    203.0.113.10203.0.113.11
    2 answers
  • AAAA
    2001:db8::10
    1 answer
  • CNAME
    no record, and none needed
    0 answers
  1. 09:41
    Resolves
    12 ms
  2. 09:40
    Resolves
    11 ms
  3. 09:39
    Resolves
    14 ms
  4. Tue 02:14
    NXDOMAIN: shop.tidepool.io does not existZone migration. #ops knew inside a minute.
    9 ms
30s
Fastest interval
A · AAAA · CNAME
Records checked
2
Tries per check
10s
Resolver timeout

Why DNS deserves its own monitor

When DNS breaks, your servers keep running and every dashboard stays green. Customers, meanwhile, get a browser error that looks like your site was deleted. The usual causes are dull: a domain renewal that bounced, a record removed during a migration, a registrar change that did not copy the zone. All of them are invisible from inside your infrastructure.

A DNS monitor looks from the outside. Every interval it resolves the name, records the answers and the time it took, and treats a name with no A, AAAA or CNAME records as down. Because the check is separate from your HTTPS monitor, you can tell at a glance whether the site is unreachable or simply unnamed.

Every name customers type

The apex, www, the API host, the shop subdomain, and the underscore names your certificate renewal depends on. Each monitor resolves its name against a resolver with a 10 second timeout and two tries, so one dropped packet is not a failure.

  • A, AAAA and CNAME answers all count, so IPv6-only and aliased names work
  • NXDOMAIN, no records, and resolver errors are reported as different failures
  • Resolution time is kept per check, so a slow resolver shows before a dead one
Monitors4 up
  • tidepool.io
    DNS · every 1 min
    12 ms
  • shop.tidepool.io
    DNS · every 1 min
    11 ms
  • api.tidepool.io
    DNS · every 30s
    9 ms
  • _acme-challenge.tidepool.io
    DNS · every 5 min
    14 ms

The 2 am zone migration

Link the monitor to a status page component and give it a rule. When a name stops resolving for as many checks in a row as you set, the component changes, an incident opens, and subscribers hear about it while you are still finding the runbook.

  • Alerts to your team on the channel they actually read
  • Incidents use your template, so the wording is right even when the timing is not
  • Recovery moves the incident to Monitoring; you write the last word
shop.tidepool.ioOutage · 27 min
  1. 02:14:03

    NXDOMAIN: shop.tidepool.io does not exist

  2. 02:15:03

    Still NXDOMAIN. Threshold reached.

  3. 02:15:04

    Component “Storefront” set to Outage; incident published from the template

  4. 02:15:05

    Slack #ops paged; 1 284 subscribers notified

  5. 02:41:20

    A record answers again: 203.0.113.10

  6. 02:41:21

    Incident moved to Monitoring. Cause: a zone migration dropped the record.

Setting one up

01

Enter a hostname

Not an IP address; there is nothing to resolve. Underscore names such as _dmarc are fine.

02

Choose an interval

Every minute is plenty. DNS changes propagate in minutes, not seconds.

03

Link a component

Point the monitor at the component that name serves, and choose what a failure should do.

The other checks

DNS monitoring questions

Find out before the domain does.

One monitor and a status page, free. No card needed.

Add a DNS monitor