The migration plan said "lower TTL to 300, wait, switch records, monitor." The team did that. Google DNS showed the new IP within minutes. Cloudflare showed it too. Then support tickets started from one region: half the users still hit the old origin, email delivery was inconsistent, and certificate issuance failed because a stale CAA record at the parent zone still allowed only the previous CA.
This is the DNS monitoring gap. A single dig from your laptop is not a production signal. DNS is distributed, cached, resolver-specific, region-specific, and layered through parent zones, authoritative nameservers, recursive resolvers, DNSSEC validators, and CDN-specific features like CNAME flattening. The record can be "right" in your DNS provider dashboard and wrong for users.
This guide goes beyond foundational DNS uptime checks. It covers propagation monitoring across resolvers, TTL strategy, CAA records, DNSSEC validation, MX/SPF/DKIM/DMARC records, nameserver delegation drift, SOA serials, zone-transfer risk, and how to alert on DNS changes before they become outages.
For the basics, start with DNS Monitoring: The Overlooked Foundation of Website Reliability. This is the deep dive for teams that treat DNS as production infrastructure.
DNS Propagation Is Not One Thing
When you change an A record, there are several views of truth:
- DNS provider dashboard
- Authoritative nameserver answer
- Parent-zone delegation
- Recursive resolver cache (Google, Cloudflare, Quad9, ISP resolvers)
- Regional resolver behavior
- End-user device cache
Propagation monitoring means comparing answers from many recursive resolvers and regions until they converge.
Recommended resolver set:
- Google:
8.8.8.8,8.8.4.4 - Cloudflare:
1.1.1.1,1.0.0.1 - Quad9:
9.9.9.9 - OpenDNS:
208.67.222.222 - Regional ISP resolvers for your key markets
- Your own authoritative nameservers directly
Track answer value, TTL remaining, resolver, region, and timestamp.
TTL Strategy and Migration Windows
TTL is how long resolvers may cache an answer. Lowering TTL right before a migration does not help if the old higher TTL is already cached.
Safe migration pattern:
- Lower TTL from 3600/86400 to 300 at least one old-TTL period before the migration.
- Verify major resolvers now return the lower TTL.
- Change the record.
- Monitor convergence across resolvers.
- Keep old origin alive until max observed resolver TTL has elapsed.
- Raise TTL after stability.
Monitor both answer value and TTL. If one resolver still returns the old value with 20,000 seconds of TTL, the migration is not done for users behind that resolver.
See Website Migration Monitoring for broader migration checks.
CAA Records: Who May Issue Certificates
CAA (Certificate Authority Authorization) records tell certificate authorities which CAs may issue certificates for your domain.
Example:
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issuewild ";"
example.com. 300 IN CAA 0 iodef "mailto:security@example.com"
Why it matters:
- Prevents unauthorized or accidental certificate issuance by other CAs
- Required for clean certificate automation in locked-down environments
- Misconfig can block renewal at the worst time
Monitor:
- CAA record exists where expected
- Allowed CA list matches your certificate provider
issuewildpolicy matches wildcard certificate needs- CAA answers are consistent across resolvers
- CAA changes trigger alerts
CAA is the bridge between DNS and TLS Configuration Monitoring. A CAA error can break certificate renewal even when the TLS endpoint is currently healthy.
DNSSEC Monitoring
DNSSEC adds cryptographic validation to DNS responses. It is powerful, but misconfiguration can make a valid domain disappear for validating resolvers.
Monitor the chain:
- DS record at parent zone
- DNSKEY records in child zone
- KSK and ZSK validity
- RRSIG expiration
- NSEC/NSEC3 behavior
- Validation result from validating resolvers
Common DNSSEC outages:
- DS record remains at parent after DNSSEC disabled in child
- KSK rollover not completed
- RRSIG expires because signing automation failed
- Registrar publishes wrong DS digest
- Split-horizon DNS returns unsigned internal answers externally
Alert on any validation failure from a validating resolver. A non-validating resolver may still answer while a validating resolver returns SERVFAIL, which is exactly why multi-resolver checks matter.
Nameserver Delegation and NS Drift
There are two NS views:
- Parent-zone delegation (
.comsays which NS serveexample.com) - Child-zone NS records (your zone says which NS serve itself)
They should match. If they do not, some resolvers can behave unpredictably.
Alert when:
- Parent NS set changes unexpectedly
- Child NS set differs from parent NS set
- Unknown nameserver appears
- Expected nameserver disappears
- Any authoritative nameserver returns different answers from the others
This overlaps with Domain Expiry & WHOIS Monitoring, because registrar-level delegation changes can happen without DNS-provider changes.
MX, SPF, DKIM, and DMARC Records
DNS is also the foundation of email deliverability.
Monitor:
- MX records exist and point to expected hosts
- MX priority order is expected
- SPF TXT record exists and is not too long or too permissive
- DKIM selector records exist for active mail providers
- DMARC record exists and has expected policy (
p=none,quarantine, orreject) - Records are consistent across resolvers
Email-specific monitoring is covered in Email Deliverability Monitoring: DMARC, SPF, and Bounces. The DNS layer here catches record drift before bounces show up.
SOA Serial and Zone Freshness
The SOA record includes a serial number that should change when the zone changes.
Monitor:
- SOA serial increments after expected DNS changes
- Primary nameserver in SOA is expected
- Refresh/retry/expire values are sane
- Different authoritative nameservers agree on SOA serial
If one authoritative nameserver has an old SOA serial, it may be serving stale records. That creates region-specific or resolver-specific failures.
Zone Transfer (AXFR) Exposure
AXFR is full zone transfer. Public AXFR exposure can leak internal hostnames, staging systems, service names, and security-sensitive structure.
Monitor:
dig AXFR example.com @ns1.example-dns.com
Expected result: refused or failed unless the requesting IP is authorized.
Alert if AXFR succeeds from an external probe.
Apex CNAME Flattening and ALIAS Records
Many DNS providers support CNAME-like behavior at the apex via ALIAS/ANAME/CNAME flattening.
Failure modes:
- Flattening provider caches stale target IPs
- Target hostname returns different records by region
- Apex and
wwwresolve to different infrastructure - CDN target changes but flattened answer lags
Monitor the final resolved A/AAAA answers, not just the configured target name.
Split-Horizon DNS
Split-horizon DNS returns different answers internally and externally. It is useful for private services, but dangerous when production endpoints accidentally depend on internal-only answers.
Monitor from:
- Public external probes
- Internal corporate resolver (if possible)
- Cloud VPC resolver
- Regional external probes
Alert when public answers for production hostnames differ from expected, or when public resolvers leak private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) for public services.
What to Alert On
Critical (page)
- Production A/AAAA/CNAME answer differs from expected after migration window
- DNSSEC validation returns
SERVFAIL - Parent NS set changes unexpectedly
- CAA no longer authorizes your certificate authority
- MX records disappear
- Public production hostname resolves to private IP
- AXFR succeeds from external probe
High (notification)
- Resolver disagreement persists > 30 minutes after expected propagation
- SOA serial differs across authoritative nameservers
- TTL remains high during planned migration
- SPF/DKIM/DMARC records missing or changed
- Unknown nameserver appears in delegation
Informational
- TTL changed
- CAA changed but still authorizes expected CA
- MX priority changed
- New TXT record appeared
See Alert Fatigue: Notifications That Get Acted On for keeping DNS alerts useful.
DNS Deep-Dive Monitoring Checklist
- A/AAAA/CNAME records monitored from multiple public resolvers
- Authoritative nameservers queried directly
- TTL tracked before and during migrations
- CAA records monitored and matched to expected CA
- DNSSEC chain validation monitored from validating resolvers
- Parent NS set monitored
- Child-zone NS set compared with parent
- SOA serial compared across authoritative nameservers
- MX records monitored for existence and priority
- SPF/DKIM/DMARC TXT records monitored
- AXFR exposure tested externally
- Split-horizon differences documented
- Apex flattening final A/AAAA answers monitored
- Multi-region probes enabled
- DNS changes tied to migration runbooks
How Webalert Helps With DNS Propagation, CAA, and DNSSEC
Webalert can monitor DNS from the outside, the same way users and bots experience it:
- Multi-resolver DNS checks - Compare answers from Google, Cloudflare, Quad9, OpenDNS, and regional resolvers.
- Record-content assertions - Assert A/AAAA/CNAME/MX/TXT/CAA records match expected values.
- DNSSEC validation - Alert when validating resolvers return failure.
- Propagation tracking - Show which resolvers have converged after a DNS change.
- Nameserver monitoring - Detect parent-zone NS drift.
- Email DNS checks - Monitor MX, SPF, DKIM, and DMARC records.
- Multi-region probes - Catch geo-specific DNS behavior and CDN routing differences.
- Multi-channel alerts - Email, SMS, Slack, Discord, Microsoft Teams, webhooks.
Example Webalert configuration:
- Record:
www.example.com - Type:
CNAME - Expected value:
example-cdn.provider.net - Resolvers: Google, Cloudflare, Quad9, regional probes
- Alert if: any resolver returns old value for > 30 minutes
CAA example:
- Record:
example.com - Type:
CAA - Must contain:
issue "letsencrypt.org" - Must not contain unexpected CA
See features and pricing for details.
Summary
- DNS propagation is resolver-specific and region-specific. A single laptop
digis not enough. - TTL must be lowered before the old TTL has already been cached.
- CAA controls which certificate authorities may issue for your domain; monitor it or renewal can fail unexpectedly.
- DNSSEC protects DNS integrity but can turn misconfiguration into
SERVFAILfor validating resolvers. - Monitor parent NS delegation, child NS records, SOA serials, MX/email records, AXFR exposure, and split-horizon behavior.
- Pair DNS monitoring with domain expiry monitoring and TLS configuration monitoring.
DNS is not a static config file. It is a distributed system. Monitor it like one.