DNS monitoring

DNS is the layer everyone forgets until it breaks — and when it breaks, it breaks strangely. The site is "up" from your desk but gone for half your customers. Email starts bouncing because an MX record vanished during a provider migration. A CNAME quietly points at a decommissioned load balancer. None of these throw a 500; conventional uptime checks often keep passing while real users are routed into the void.

DNS monitoring watches the records themselves. You declare what each record should say; FourSight resolves it continuously from four regions and alerts the moment the answer stops matching. It's change detection for the most change-sensitive infrastructure you have.

The failure modes fall into three families — accidental drift, failed changes, and hostile changes — and record-level monitoring catches all three the same way: the resolved answer stops matching the expected one.

You pick a record type — A, AAAA, CNAME, MX, NS, or TXT — and declare the expected values. On every check cycle, FourSight's probes in four regions (United States, Canada, Europe, and APAC) resolve the record and compare the live answer to your expectation. Choose exact matching when the record set should be complete and closed (NS records, a single-target CNAME), or contains matching when you only care that a specific value is present (one address in a round-robin pool, your SPF include inside a longer TXT record).

When answers stop matching, the incident includes the actual resolved values from each region — so at a glance you can tell a global change (every region sees the wrong value: someone edited the zone) from a regional anomaly (one resolver path serving stale or poisoned data). Because an incident requires quorum agreement across regions, a single flaky resolver doesn't page you at 3 AM.

Supported record types and what to watch

Record type	What it controls	Typical monitoring use
A / AAAA	Hostname to IPv4/IPv6 address	Web and API origins pointing at the right servers
CNAME	Hostname aliases	CDN, SaaS, and load-balancer targets staying correct
MX	Mail routing	Email keeps flowing after provider or zone changes
NS	Zone delegation	Hijack and rogue-delegation detection — highest-severity record
TXT	SPF/DKIM/verification strings	Email deliverability and domain-verification records intact

Record monitoring is one of the fastest practical tripwires for DNS hijacking. Most real-world hijacks work by changing what your records say — an attacker with registrar access swaps your NS delegation, or edits A records to point at credential-harvesting infrastructure while your site "keeps working" behind their proxy. Users see a valid-looking site; your own uptime checks may even pass.

A monitor that expects your NS records to equal your legitimate nameservers, and your A records to equal your real addresses, converts that attack into an alert within a check cycle or two of propagation. It's not a substitute for registrar security — enable MFA and registry locks — but it's the detection layer that tells you when prevention has failed, which is exactly the moment every minute counts.

Tip: Minimum hijack tripwire: one NS monitor with exact matching, plus an A record monitor on your apex domain and primary app hostname. Three monitors, and registrar-level compromise can no longer be silent.

Because DNS is a distributed cache, not a single source of truth. Propagation delays, per-resolver TTL behavior, geo-routing, and regional anycast issues mean two users in different countries can legitimately receive different answers for the same name — and a single-vantage monitor can't tell you which answer the rest of the world is seeing.

FourSight resolves from four regions in parallel on every cycle. During a planned change, that shows you propagation actually completing across continents rather than just at your provider's status page. During an incident, it localizes the blast radius immediately: all regions wrong means the zone changed; one region wrong means a resolver-path problem. And because alerting requires multi-region quorum, transient single-resolver blips don't wake anyone.

An HTTP check tells you the endpoint answered; it can't tell you who answered. If a hijacked record points users at an attacker's proxy, or a stale CNAME serves a deprecated-but-alive server, HTTP checks can pass while the actual failure — wrong destination — goes undetected. Conversely, DNS can be perfectly correct while the origin is down. They're different layers, and production coverage needs both.

In FourSight they're two monitor types on one platform: HTTP checks for reachability and correctness of content (add keyword checks for that), DNS checks for the integrity of the resolution layer underneath — plus SSL, domain expiry, ping, port, and heartbeat checks rounding out the stack, all included in the Growth plan at $40/mo flat.

Included in Growth — $40/mo flat

Declare what your DNS should say — get paged when it doesn't

DNS monitoring is included in the Growth plan with all eight check types, 4-region resolution on every cycle, and quorum-based alerting that ignores single-resolver noise.

• A, AAAA, CNAME, MX, NS, and TXT record monitoring
• Exact or contains matching per monitor
• Per-region resolved values attached to every incident
• Hijack tripwire: NS and A monitors take minutes to set up

FAQ