Cached Convictions: How DNS TTLs Distort URL Health Checks Across US Regions

URL monitors are often treated as impartial witnesses. They request a URL, record a status code, and report latency. But before the first HTTP packet leaves the monitor, a resolver has already made a judgment: which IP address belongs to the hostname. That judgment may be cached, steered by geography, or inherited from a CNAME chain. When DNS behavior differs across US regions, the monitor is not lying on purpose. It is answering from the evidence its resolver has.

The Monitor Sees a Resolver, Not the Internet

A check from Ashburn and a check from Los Angeles may not use the same recursive resolver, even when both monitors belong to the same vendor. One may query a public resolver with an anycast presence; another may use an ISP resolver that caches aggressively. A third may pass EDNS Client Subnet, while its neighbor does not. The result is a familiar and frustrating pattern: the same URL looks healthy in one region and stale, slow, or unreachable in another.

This matters because URL health is not a property of a hostname in isolation. It is a property of the path a visitor takes from resolver to edge to origin. A monitor that reports a 200 from Dallas has confirmed one path at one moment. It has not confirmed that a visitor in Seattle will resolve to the same endpoint, receive the same certificate, or reach the same origin pool.

TTL Is a Permission Slip, Not a Stopwatch

DNS TTLs are frequently described as propagation timers. That description is imprecise. A TTL is an upper bound on how long a resolver may cache a record. It does not force every resolver to expire the record at the same instant, and it does not guarantee that a monitor will see a new address immediately after a change.

Resolvers may clamp low TTLs, honor higher ones, or apply their own operational policies. Some networks treat a 60-second TTL as permission to cache for longer during high query volume. Others respect the value closely. Negative answers add another layer: when a hostname does not resolve, resolvers cache the negative response according to the SOA minimum TTL. A newly created subdomain can therefore appear dead in one region long after the authoritative zone has been updated.

CNAME chains compound the problem. Each link in the chain carries its own TTL, and the effective cache lifetime is shaped by the entire path. A short TTL at the final record does not cancel a long TTL at an intermediate CNAME. When a monitor reports an unexpected IP address, the cause may be a stale link several hops away from the record the team thought it changed.

Geo-DNS Turns One URL Into Many

Geo-DNS and latency-based routing are common in US deployments because they can send East Coast visitors to an East Coast endpoint and West Coast visitors to a West Coast endpoint. For URL monitoring, that design creates multiple versions of the same URL. A monitor in one region may test a healthy origin while another region resolves to a degraded or outdated endpoint.

Resolver location further complicates the picture. If a monitor in Chicago queries a public resolver whose egress is in Virginia, the geo-DNS answer may reflect Virginia rather than Chicago. The monitor label says Chicago; the DNS answer says otherwise. Without checking resolver egress and EDNS Client Subnet behavior, teams can draw the wrong conclusion about regional performance.

A Practical Audit for US Monitor Locations

Start by inventorying the authoritative records that matter: A, AAAA, CNAME, and the SOA minimum used for negative caching. Note the published TTL for each record and the expected answer for each region served by geo-DNS.

Next, query from each monitor region through the resolver the monitor actually uses. Repeat the query through at least two public resolvers to expose caching differences. Record the returned addresses, the remaining TTL, and the CNAME chain. Compare those results with a direct authoritative query so you can distinguish an authoritative change from a cached answer.

Then compare DNS answers with HTTP results. If a monitor receives a 200 from an address that another region no longer resolves, the monitor is testing a stale path. If a region resolves correctly but HTTP latency rises, the problem may be at the edge or origin rather than in DNS. Keeping both layers visible prevents misdiagnosis.

Finally, capture a baseline before any planned deploy or failover. A pre-change snapshot is far more useful than a post-incident guess about what the resolver should have returned.

Align TTLs With Deploy and Failover Schedules

TTL policy should follow operational rhythm. Before a planned cutover, lower the relevant TTLs to a short interval, often 60 to 300 seconds, at least 24 to 48 hours in advance. After the new endpoint has proven stable across regions, raise the TTL again. Permanently low TTLs increase query volume and resolver load, so they are a tool for transitions, not a default state.

Failover deserves the same discipline. Health-checked DNS can move traffic quickly only if resolvers are willing to ask for fresh answers. Test the failover from multiple US regions, including at least one location that uses a different resolver type. Confirm that negative caching will not strand new hostnames and that certificate coverage matches every endpoint in the rotation.

What to Put on the Dashboard

A DNS-aware URL dashboard should show more than uptime. Useful fields include the resolved IP address per region, remaining TTL, CNAME chain depth, DNS response time by resolver, and mismatches between expected and observed records. Add negative-answer rates for newly introduced hostnames and correlate DNS changes with HTTP latency and error spikes.

At URLPulse, we treat DNS as the first hop of every URL check. A monitor that ignores resolver behavior is only testing one version of the URL. Audit TTLs, resolver paths, and geo-DNS answers before trusting a green status. The check may be healthy. The visitor's path may not be.