Why do I need DNS monitoring if I already have HTTP monitoring?

An HTTP check tells you resolution failed, but not why — and it misses the DNS problems that don't fully break resolution: hijacked records pointing users at an attacker's server (which may answer HTTP checks fine), stale answers in some geographies during propagation, vanished MX or SPF records that break email without touching your site. DNS checks assert the answers themselves are correct, not merely that something responded.

How do I detect DNS hijacking?

Monitor your critical records continuously and alert on unexpected changes: an A record pointing at a new address nobody deployed, a nameserver change nobody requested, new TXT records. Combine detection with prevention — registry lock, MFA on the registrar account, and scoped DNS API tokens — since hijacks typically enter through account compromise rather than protocol attacks.

What TTL should my DNS records have?

300 seconds for records you may need to change quickly (app endpoints, anything behind failover), 3600 for stable infrastructure records. Before any planned migration, lower the TTL at least one full old-TTL period in advance so caches worldwide learn the short value, make the change, verify from multiple regions, then restore the longer TTL.

Is DNSSEC worth enabling?

It's real protection with real operational risk: expired signatures or a mismatched DS record make your domain unreachable specifically for users on validating resolvers, and the partial failure pattern is confusing to diagnose. Enable it if you'll also commit to monitoring signature expiry and treating key rollovers as production changes — DNSSEC without that discipline has caused more outages than it has prevented attacks for many teams.

Do I need a secondary DNS provider?

If an hour of total unreachability is an existential number for your business, yes — provider-level DNS outages recur every few years at even the largest providers, and secondary DNS at an independent provider keeps you resolvable through them. If you adopt it, automate zone synchronization and monitor both providers for consistency; a drifted secondary can be worse than none.

DNS Monitoring: Catching Silent Failures

DNS: The Silent Point of Failure

DNS is the layer everything else stands on: before a browser can load your page, verify your SSL certificate, or deliver a webhook, it has to resolve your hostname to an address. When DNS fails, everything above it fails — but unlike an application crash, DNS failures are frequently partial, intermittent, and invisible from where you sit. Resolution is distributed across resolvers you don't operate, each caching your records for its own remaining TTL, which means a bad record change doesn't break the internet all at once; it breaks user by user, resolver by resolver, as caches expire. The team's own machines often resolve fine (their office resolver still has the old record cached) while customers three time zones away get nothing. That staggered, someone-else's-cache failure pattern is exactly why DNS problems routinely run for hours before anyone correlates the scattered reports — and why DNS deserves dedicated monitoring rather than being implicitly covered by HTTP checks.

Common DNS Failure Modes

DNS fails in a handful of recurring patterns, each with a distinct signature. Knowing them turns a vague 'some users can't reach us' report into a short diagnostic checklist.

Propagation Delays and Botched Changes

After a record change, resolvers keep serving the old value until their cached copy's TTL expires — so a change made with a 24-hour TTL still in effect takes up to a day to fully land, and during the window different users see different answers. The standard operational mistake is changing a record without first lowering its TTL: plan migrations by dropping the TTL to 300 seconds at least one full old-TTL period in advance, making the change, verifying from multiple regions, then raising the TTL back. Multi-region monitoring shows you the propagation wave directly — which geographies have the new record, which are still serving stale answers.

Record Hijacking and Unauthorized Changes

DNS hijacking — via a compromised registrar account, a stolen DNS-provider API key, or social engineering against the registrar — redirects your traffic to servers an attacker controls, often while your infrastructure stays perfectly healthy. Continuous monitoring that compares resolved values against expected values catches this class fast: an A record that suddenly points somewhere new, an unexpected nameserver delegation change, a TXT record you didn't add. Registrar-level protections (registry lock, MFA on the registrar account, scoped API tokens) reduce the odds; monitoring bounds how long a successful hijack goes unnoticed.

Expired Domains and Broken Delegation

The most catastrophic DNS failure is upstream of your records entirely: the domain registration lapses, or a nameserver migration leaves the delegation at the registry pointing at servers that no longer answer authoritatively. Both produce total resolution failure with a recovery time measured in hours to days (registrar redemption processes are slow by design). Domain-expiry monitoring is its own check type for exactly this reason — the failure gives no application-level warning at all.

TTL Misconfiguration

TTLs encode a trade-off you should choose deliberately rather than inherit from provider defaults. Very low TTLs (under 60s) give you fast failover but raise resolution latency for users and query load on your provider, and they make you dependent on your DNS provider's uptime minute to minute. Very high TTLs (24h+) pin mistakes and slow every migration. Reasonable defaults: 300s for records you might need to move quickly (app endpoints behind failover), 3600s for stable infrastructure, longer only for records that genuinely never change. Audit effective TTLs occasionally — they drift as teams copy old zone files.

Monitoring a Commercial SaaS?

FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card.

Start Monitoring Free

Setting Up DNS Monitoring

A DNS monitor queries your records on an interval and alerts when the answers change unexpectedly or stop coming back — catching hijacks, botched changes, propagation stalls, and provider outages as distinct events. Coverage matters more than sophistication: teams reliably monitor the apex A record and forget the records whose failure is quieter but just as expensive. MX records that vanish stop your email silently. A missing SPF or altered DKIM TXT record doesn't stop mail sending — it sends your invoices and password resets to spam folders, which takes days to notice and weeks to fully recover deliverability from. CNAMEs pointing at third-party services (status page vendors, docs hosts, tracking domains) break when the vendor changes endpoints, and nothing on your side logs anything.

DNS records to monitor:

A/AAAA records  → Your primary domain and API subdomains
CNAME records   → CDN and third-party service integrations
NS records      → Delegation — changes here are always significant
MX records      → Email delivery (failure is silent until someone asks)
TXT records     → SPF, DKIM, domain verification (deliverability)

DNS Provider Redundancy

Your DNS provider is a single point of failure sitting under your entire estate, and provider-level outages are a recurring feature of internet history rather than a hypothetical. When one hits, your servers are healthy, your certificates are valid, and none of it matters because nobody can resolve your name. Secondary DNS — a second provider serving the same zone, listed in your delegation alongside the primary — means resolvers simply use the surviving provider when one fails. It's cheap insurance with real operational cost (keeping zones synchronized, ideally automated via zone transfer or infrastructure-as-code), which is why it's most justified for businesses where an hour of total unreachability is an existential number. Monitoring belongs on both providers independently: consistency checks between them catch synchronization drift long before an outage makes the drift matter.

💡 The July 2021 Akamai Edge DNS incident disrupted resolution for thousands of major sites for roughly an hour — airlines, banks, and gaming platforms included. The sites with secondary DNS at another provider stayed resolvable throughout. An hour of global unreachability is the scale of event provider redundancy exists for.

DNSSEC: Powerful, and Sharp-Edged

DNSSEC cryptographically signs your DNS records so validating resolvers can detect tampering — real protection against a class of spoofing attacks. Its operational sharp edge is that validation failures are treated as attacks by design: if your signatures (RRSIGs) expire because a re-signing job died, or your registrar's DS record falls out of step with your zone's keys during a key rollover or provider migration, validating resolvers — which now include major public resolvers and many ISPs — return SERVFAIL and your domain becomes unreachable for that entire population. The failure is also maddeningly partial: users on validating resolvers get nothing while users on non-validating resolvers see a perfectly healthy site, producing contradictory reports mid-incident. If you run DNSSEC, monitor signature validity and expiry explicitly, treat key rollovers as production changes with rollback plans, and never migrate DNS providers without a DNSSEC-specific runbook — removing the DS record before the move and re-establishing it after is the standard sequence.