How to Get Alerted When a DNS Record Stops Resolving
DNS records don't usually break because someone changes them on purpose and gets it wrong. More often, they break because someone else touched something nearby: a zone file got re-imported during a registrar migration and a record that wasn't in the new zone silently vanished, a domain's renewal lapsed a day later than everyone assumed it would, or a "cleanup" of unused-looking DNS entries turned out to include one that wasn't actually unused. The record was resolving yesterday, and today it isn't, and depending on what depended on it, that can mean anything from a broken subdomain to email routing failing silently in the background.
The fix here is narrower than it might sound: a DNS monitor that simply confirms a record still resolves, on a schedule, and alerts you the moment it doesn't. Here's how to set that up with Downdar.
What You Will Need
A Downdar account and API key, and the hostname whose DNS record you want watched.
Creating a DNS Monitor
The /api/v1/monitors/create endpoint accepts a POST request specifying the monitor type and host:
Creating it from your Downdar dashboard works the same way, pick DNS as the check type and enter the hostname. Downdar checks whether the record resolves on its regular interval and opens an incident the moment it doesn't.
If you have several hostnames that matter independently, your main domain, an API subdomain, an MX record's mail server, each one needs its own monitor. A record failing on one subdomain doesn't tell you anything about the others.
What This Monitor Actually Checks (and Doesn't)
It's worth being precise about this, because it's easy to assume more coverage than you're actually getting. This monitor confirms a DNS record exists and resolves, nothing more. It does not track what value the record resolves to, and it won't alert you if a record's value changes but the record still resolves successfully, an A record pointed at a different IP, a CNAME retargeted somewhere else, an MX record swapped to a different mail provider. All of those would pass this check without triggering anything, since the record is still there and still resolving.
What this catches is the record disappearing entirely, or a lookup starting to fail, NXDOMAIN, no answer, or the zone becoming unreachable. That's a real and common failure mode on its own. If you specifically need to know when a record's value changes, not just whether it's present, that's a different kind of monitoring than a resolution check provides, and worth keeping in mind if your actual concern is unauthorized or unexpected changes to a record's target rather than the record vanishing.
Configuring Alerts
New monitors alert through your account's default channel unless you specify otherwise. To route this monitor to a specific channel, pass alert_channel_keys when creating it:
A DNS record failing usually means something is fully unreachable rather than degraded, so treat this alert with the same urgency as an uptime monitor going down, not something to review at the end of the day.
Checking Monitor Status Programmatically
The /api/v1/monitors/status endpoint returns a monitor's current state if you want to surface it in your own tooling.
A Note on DNS Caching and Propagation
If you've just fixed a broken record, don't be surprised if it takes a little while for every resolver everywhere to catch up, DNS caching means different resolvers can hold onto an old answer for as long as the record's TTL allows, even after the authoritative answer is correct again. That's a normal, expected delay, not a sign that the fix didn't work. If a monitor still shows a failure immediately after a fix, give it a bit of time before assuming something's still wrong.
Get Started
Set up a monitor for any hostname where "this stopped resolving" would be a genuine problem, not just your main domain, but the subdomains and mail records that tend to get forgotten during infrastructure changes.