[1,222 words, 6 minute read time]
Most teams think “the website is down” means hosting or code. But a surprising number of outages start somewhere else entirely:
DNS problems masquerade as hosting or “random outages.”
DNS and domain failures create the classic chaos:
- “It works for me.”
- “It works on my phone but not my laptop.”
- “It’s down in Europe but fine in the US.”
- “Our monitor says down, but the server is responding.”
This guide explains DNS monitoring (and domain monitoring) in practical terms: what DNS failures look like, domain expiration risks, the key record types (A/AAAA/CNAME), TTL/propagation, an incident checklist, and copy/paste tables and reminders.
For the full monitoring roadmap, start with the complete guide.
What DNS failures look like (symptoms you’ll see)
DNS failures don’t always look like “DNS.” They show up as confusing symptoms that are easy to misdiagnose.
Common DNS-related symptoms
- Browser shows “DNS_PROBE_FINISHED_NXDOMAIN” or “server IP address could not be found”
- Site times out for some users but not others
- Only one hostname fails (e.g.,
wwwworks but apex doesn’t, or vice versa) - Outage appears regional (works in one location, fails in another)
- API works but website doesn’t (or the reverse)
- Monitoring shows intermittent “down” flapping around DNS change windows
If you only monitor from one location, DNS problems can hide.
That’s why multi-location monitoring is a strong companion: multi-location uptime monitoring.
The two big buckets: domain/registrar vs DNS provider
When something “DNS-ish” breaks, it usually falls into one of these categories:
1) Domain/registrar issues (ownership and renewals)
- domain expired (or is in grace/redemption)
- registrar account compromised
- nameservers changed (maliciously or accidentally)
- contact email invalid (renewal notices never arrive)
- auto-renew failed due to billing
2) DNS provider issues (records and resolution)
- record changed incorrectly (A/AAAA/CNAME)
- record deleted
- DNSSEC misconfiguration (advanced, but common enough to mention)
- propagation/TTL confusion after changes
- provider outage (less common, but possible)
DNS monitoring is about catching both: resolution failures and upcoming renewal risks.
Domain expiration and registrar risks (why this is high-stakes)
A domain is not just a DNS setting. It’s your identity. Domain expiration can look like sudden total downtime—and it can quickly turn into a nightmare.
What can happen when a domain expires
- DNS stops resolving (site “vanishes”)
- email stops working (password resets fail, support inbox dies)
- customers see scary warnings or dead pages
- in worst cases, the domain is purchased by someone else after expiration windows
Registrar risk checklist (high ROI)
- Enable auto-renew
- Use a payment method that won’t fail silently (and keep it updated)
- Set a calendar reminder 30–60 days before expiration
- Ensure WHOIS/contact email is valid and monitored
- Turn on 2FA for registrar accounts
- Restrict who has access (agencies: separate client credentials or vault)
- Consider registry lock for high-value domains (advanced/enterprise)
DNS record basics (A/AAAA/CNAME) at a high level
You don’t need to become a DNS engineer to monitor it well. Here are the records you’ll interact with most:
A record
Maps a hostname (like example.com) to an IPv4 address.
AAAA record
Maps a hostname to an IPv6 address.
CNAME record
Points one hostname to another hostname (common for www → example.com or CDN targets).
Common failure pattern:
A site “works” for some users if the A record is correct but the AAAA record points to a dead IPv6 target (or vice versa). Or www is a CNAME to an old CDN hostname.
Monitoring should include the hostnames users actually type:
example.comwww.example.com- critical subdomains (
api.,app.,status.,cdn.)
Propagation and TTL (practical terms, not theory)
DNS changes aren’t instantly consistent worldwide because resolvers cache answers.
TTL in plain language
TTL (time to live) is “how long other systems are allowed to cache this DNS answer.”
- Lower TTL (e.g., 60–300 seconds): changes spread faster, but can increase query volume
- Higher TTL (e.g., 3600+ seconds): more stable caching, but slower change propagation
Propagation in practice
When you change DNS:
- some resolvers pick it up quickly
- others keep old cached values until TTL expires
- users can see different answers at the same time
That’s why DNS incidents can look “random.”
Practical change strategy
- For planned migrations: lower TTL 24–48 hours beforehand
- Make the change
- After stable: raise TTL back to a reasonable value
What DNS monitoring should actually do
A good DNS monitoring setup watches for:
- resolution success/failure (NXDOMAIN, SERVFAIL, timeout)
- correctness of returned records (A/AAAA/CNAME match expected)
- changes to nameservers
- domain expiration windows (renewal reminders)
- optionally: DNSSEC status changes (advanced)
This complements uptime checks in your overall monitoring plan: complete guide.
Symptom → likely cause table (copy/paste)
Use this to triage quickly when something “feels like DNS.”
| Symptom | Likely cause | First things to check |
|---|---|---|
| “Domain not found” / NXDOMAIN | Record deleted, wrong zone, domain expired | Registrar status, DNS zone exists, record present |
| Works for you, not others | TTL/propagation or regional resolver differences | Recent DNS changes, TTL, multi-location checks |
www works but apex doesn’t (or vice versa) | Missing/incorrect A/CNAME on one hostname | Compare records for both hostnames |
| Intermittent failures | Provider instability, mixed A/AAAA correctness, cached old records | AAAA record, recent changes, provider status |
| Suddenly points to wrong site | Nameserver change, hijack, mis-pointed records | Nameservers at registrar, change history, account security |
| Email breaks too | Domain/DNS-wide issue | MX/TXT records (not covered here deeply), registrar status |
DNS incident checklist (first 15 minutes)
When you suspect DNS during an outage, don’t guess—confirm.
DNS incident checklist
- Confirm resolution failures
- Check
example.comandwww.example.com - Check from a second network/location
- Check if it’s regional
- Compare results from multiple regions (or use your monitoring probes)
- If only one region fails, suspect resolver/propagation/CDN edge
- Check registrar status
- Is the domain expired or in renewal trouble?
- Were nameservers changed?
- Check recent DNS changes
- Did anyone change A/AAAA/CNAME records recently?
- Was a migration planned?
- Are TTLs very high (slower propagation)?
- Validate expected targets
- A/AAAA point to the correct IPs?
- CNAME points to the correct hostname?
- Any stale records left over (especially AAAA)?
- Mitigate
- Roll back the DNS change if it’s clearly wrong
- If nameservers were changed unexpectedly, revert immediately and secure accounts
- Communicate clearly: “DNS issue confirmed; propagation may take X minutes after fix”
If this is part of a broader incident, use the full playbook: incident response.
“Renewal reminders” checklist (prevent the worst DNS outage)
Domain expiry is one of the most preventable outages. Agencies should treat it like client inventory.
Renewal reminders checklist
- Record domain expiration date for every client/domain
- Set reminders for:
- 60 days before expiration (verify billing/contact)
- 30 days before (confirm auto-renew)
- 14 days before (manual check: renewal queued)
- 7 days before (urgent escalation if uncertain)
- Confirm:
- registrar access is current
- client contact email is valid
- 2FA is enabled
- payment method is current
Agency tip: keep domain ownership explicit in your contracts and onboarding (“Client owns domain; agency manages DNS changes under approval”).
How to add DNS monitoring to your overall stack (simple approach)
Start with three checks:
- Monitor DNS resolution for
example.com - Monitor DNS resolution for
www.example.com - Add domain expiration reminders (calendar + tool alerts)
Then level up:
- monitor critical subdomains (
app.,api.,status.) - multi-location checks for global audiences
- change alerts for nameservers/records (if your tooling supports it)
CTA: Add domain expiration reminders + monitor DNS resolution
DNS failures are frustrating because they look like “random outages,” and domain expiration is catastrophic because it looks like instant disappearance.
CTA: Add domain expiration reminders and monitor DNS resolution (for apex + www) today—before your next DNS change or renewal window turns into a surprise outage.