Everything works. Servers respond. Containers are green. But users write: "Your site won't load". You check from your laptop — same problem. Ping the IP — it responds. What's happening? DNS stopped resolving your domain. Someone accidentally deleted the A record, or DNS provider is down, or TTL cache returns stale IP after migration.
DNS is the internet's phone book. If your number isn't in it, people can't find you even if you're home and the phone works. Unlike server errors, DNS problems are insidious: regular HTTP monitoring catches them but can't explain why. You see "Connection timeout" when really it's DNS. Below are specific scenarios, record types, and approaches for monitoring DNS as a critical observability layer.
Why DNS breaks more often than you'd think
DNS seems simple: domain → IP address. In practice it's a distributed system with caching, TTL, multiple server levels, and complex dependencies. Here are real scenarios that break DNS:
Expired domain. Forgot to renew — registrar puts parking page or deletes DNS records entirely. Auto-renewal failed because card expired. Most frustrating cause: domain costs $12/year but downtime costs thousands.
Accidental record deletion. New DevOps engineer cleaning unused records accidentally deleted production A record. Or Terraform state got out of sync and deleted records on apply. Takes hours to discover without monitoring.
Failed DNS provider migration. Moved NS records to Cloudflare but didn't migrate all DNS records. Main domain works, but api.example.com doesn't because CNAME stayed on old provider.
DNS provider outage. Even major providers go down. Dyn DNS attack 2016, Cloudflare incidents — when your DNS provider is down, all your domains are unreachable regardless of server state.
TTL too high during migration. You changed server IP but TTL was 86400 (24 hours). Half your users still go to old IP where nothing exists. You think migration succeeded.
Which DNS records to monitor
A and AAAA records
Core records linking domain to IP address. A for IPv4, AAAA for IPv6. Monitor that they resolve to correct IP. If IP changed without your knowledge, it's either DNS hijacking or configuration mistake. DNS monitoring checks resolved IP every cycle.
MX records
Determine where mail for your domain is delivered. Broken MX records mean mail doesn't arrive. Sender may not get bounce — email just disappears. If you use Google Workspace, Microsoft 365, or your own mail server, MX monitoring is mandatory. Free MX Lookup shows current state.
CNAME records
Aliases pointing one domain to another. Typical use: www.example.com → CNAME → example.com, or cdn.example.com → CNAME → d123.cloudfront.net. If CDN changed endpoint but you didn't update CNAME, static assets stop loading.
TXT records (SPF, DKIM, DMARC)
Critical for email deliverability. SPF specifies which servers can send from your domain. DKIM signs messages. DMARC sets policy on mismatch. If TXT records are deleted or changed, your emails start going to spam. You find out days later when customers say "I'm not getting your emails".
NS records
Specify which nameservers handle your domain. If NS records change without your involvement, it's serious security incident (possible domain hijacking). NS record monitoring is your canary for detecting unauthorized changes.
DNS resolution time: hidden performance factor
Every time user visits your site, browser first resolves DNS. Usually 20-50ms. But if DNS server is overloaded or far away, resolution time can grow to 200-500ms. This adds to every initial request and directly impacts TTFB.
Factors affecting DNS resolution time:
Geographic location of DNS servers. If your NS servers are only in US but users are in Europe, every resolution makes transatlantic round-trip. Use Anycast DNS (Cloudflare, Route53) for minimum latency.
TTL settings. Low TTL (60s) means frequent DNS queries. High TTL (3600s) caches response but slows failover. Balance: 300-600s for production, 60s before planned migration.
Number of records in zone. Huge DNS zones with thousands of records can slow response. If you have many subdomains, consider zone delegation.
DNS monitoring + HTTP monitoring: complementary combo
DNS monitoring doesn't replace HTTP monitoring — they complement each other. HTTP check says "site not responding". DNS check says "because domain isn't resolving". Together they give full picture and reduce MTTR (Mean Time to Resolution).
Typical incident workflow:
Scenario A: HTTP ❌, DNS ✅ — Domain resolves but server doesn't respond. Problem on server side: crashed process, full disk, firewall. Check application logs.
Scenario B: HTTP ❌, DNS ❌ — Domain won't resolve. Problem in DNS: deleted record, DNS provider down, expired domain. Check DNS configuration.
Scenario C: HTTP ✅, DNS ⚠️ (wrong IP) — Domain resolves to wrong IP, but that server also responds (old server). Data is stale but user sees "working" site. Without DNS monitoring you won't catch this.
Scenario D: HTTP ⚠️ (slow), DNS ⚠️ (slow) — High DNS resolution time contributes to total latency. DNS response time monitoring shows: degradation comes from DNS level, not server.
Setting up DNS monitoring
Setting up DNS monitoring in AtomPing takes 3 minutes per domain:
Step 1. Create DNS check, specify domain and record type (A, MX, CNAME, TXT). For main domain, start with A record.
Step 2. Specify expected value: specific IP for A record, hostname for MX. Monitoring will alert if resolved value changes.
Step 3. Set interval (1-5 minutes) and check regions. Multi-region DNS checks show if record resolves differently across the world.
Step 4. Connect alerts: Slack, Telegram, email. DNS incidents are critical — set immediate notification, no delays.
DNS monitoring for email: don't lose messages
Email infrastructure completely depends on DNS. If MX records point wrong way, incoming mail disappears. If SPF/DKIM/DMARC TXT records are wrong, outgoing mail goes to spam. Problem: email failures manifest slowly. You don't get error immediately, you find out days later when customer says "I sent you three emails".
Minimal DNS checks for email:
MX record — verify values match your email provider. For Google Workspace: aspmx.l.google.com etc. Use MX Lookup for current check.
SPF (TXT record) — v=spf1 include:_spf.google.com ~all. If someone deletes or changes it, your emails go to spam.
DKIM (TXT record) — long TXT record with public key. If it disappears, email signature verification stops working.
DNS security: monitoring as hijacking defense
DNS hijacking is attack where attacker changes DNS records to redirect traffic to their server. Allows data interception, phishing pages, or credential theft. Registrar attack or NS record changes are among most dangerous vectors.
DNS monitoring is your first defense line. If A record suddenly changes to IP you don't own, monitoring sends alert in minutes. Without it you might learn about hijacking hours or days later when users start complaining.
Additional measures: enable DNSSEC at registrar level (protection from response spoofing), use registrar lock (unauthorized transfer protection), and monitor NS records — nameserver change without your involvement is red flag.
DNS monitoring checklist
1. A/AAAA record of main domain — check every 1-3 minutes, expected IP pinned.
2. A record of API domain (if separate) — same as main.
3. MX records — verify email routing is correct.
4. SPF TXT record — protection from spam folder.
5. NS records — canary for hijacking detection.
6. Auto-renewal enabled for domain — don't let it expire.
7. TTL set to 300-600s — sensible balance of caching and flexibility.
8. Registrar lock enabled — protection from unauthorized transfer.
DNS is invisible but critical infrastructure component. Works silently and breaks silently. Only way to guarantee domains resolve correctly is to actively monitor DNS continuously. Three minutes of setup now and you permanently eliminate an entire class of incidents that regular HTTP monitoring can't diagnose.
FAQ
What is DNS monitoring?
DNS monitoring continuously checks that your domain names resolve correctly to the right IP addresses. It verifies DNS record accuracy (A, AAAA, CNAME, MX, TXT), measures resolution time, and alerts you when records change unexpectedly or resolution fails. Without DNS monitoring, a misconfigured record can make your entire site unreachable even while servers are running perfectly.
Why does DNS monitoring matter if my site is already monitored?
HTTP monitoring checks your server — DNS monitoring checks the path to your server. If DNS breaks, HTTP checks fail too, but the root cause is invisible. DNS monitoring tells you immediately: 'The domain isn't resolving' vs 'The server is down.' This distinction saves 30-60 minutes of debugging during incidents.
How often should I check DNS records?
Every 1-5 minutes for critical domains. DNS changes propagate gradually, so frequent checks catch propagation issues early. For secondary domains or internal services, every 5-10 minutes is sufficient. AtomPing checks DNS as part of every monitoring cycle.
What DNS records should I monitor?
At minimum: A records (IPv4 address), AAAA records (IPv6), MX records (email delivery), and CNAME records (aliases). Also monitor TXT records if you rely on SPF/DKIM/DMARC for email authentication, and NS records to verify your nameservers haven't changed.
Can DNS issues cause email delivery problems?
Yes, absolutely. MX records direct email to your mail servers. If MX records are wrong, deleted, or pointing to a dead server, incoming email silently disappears or bounces. SPF/DKIM TXT records affect deliverability — if they're misconfigured, your outgoing emails land in spam. DNS monitoring catches these before you lose important messages.
What is DNS propagation and why does it cause outages?
When you change a DNS record, the update doesn't happen instantly worldwide. Each DNS resolver caches records based on the TTL (Time to Live) value. Propagation is the time it takes for all resolvers globally to pick up the new record. During propagation, some users see the old IP, others the new one. If you cut over too fast, users hitting the old IP get errors.