Why Your Uptime Monitor Stays Green During an Authoritative DNS Outage

A site owner checks their dashboard during a wave of customer complaints and sees every monitoring check glowing green. The HTTP monitor reports a brisk 200 OK every sixty seconds, the application servers are idling with normal CPU usage, yet users on social media or in support tickets say the domain does not exist. This disconnect usually points to an outage at the authoritative Domain Name System (DNS) level, where the systems hosting your zone file stop responding while the rest of the internet runs on borrowed time. To see why this happens, imagine a small neighborhood bakery that posts its daily menu on a board outside. Every morning, a courier walks by, writes down the menu on a notepad, and hands copies to customers who ask for it down the street. If the bakery catches fire at noon, the courier does not immediately notice. As long as the notes in the courier's pocket remain valid, customers who ask the courier will think the bakery is operating normally. Only someone trying to visit the bakery directly, or a courier whose notes just expired, discovers the problem. In internet infrastructure, your uptime monitor behaves just like that courier, while your authoritative nameservers are the bakery.

The path between recursive resolvers and authoritative nameservers

When a browser or an automated monitoring probe requests example.com, it rarely talks to the nameservers that hold your domain's master records. Instead, the operating system forwards the request to a recursive resolver—often operated by an Internet Service Provider (ISP), a cloud vendor, or a public service like Cloudflare or Google. The recursive resolver is responsible for tracking down the answer. It asks the root servers, then the Top-Level Domain (TLD) servers (such as .com), and finally reaches your authoritative nameservers. The authoritative nameserver holds the actual zone configuration and returns the IP address along with a Time to Live (TTL) value. The TTL is an instruction measured in seconds that tells the recursive resolver: "You do not need to ask me again for this record until this duration expires." If your authoritative nameservers suffer a catastrophic failure—whether due to network partition, distributed denial-of-service, or provider routing errors—the records do not instantly vanish from the internet. Every recursive resolver that recently looked up your domain still holds the IP address in its local cache. As long as the TTL has not counted down to zero, the recursive resolver answers queries instantly without touching your authoritative nameservers. Most standard uptime monitoring services deploy worker nodes that run an HTTP check every one to five minutes. Because these monitoring probes query the same domain repeatedly from the same regional vantage points, their local recursive resolvers almost always have an unexpired record in memory. The monitor requests the page, the resolver hands back the cached IP, the probe connects to your healthy web server, and the dashboard marks the test as passing. Meanwhile, a visitor using an ISP resolver that did not have the domain cached, or whose cache expired two minutes after the outage began, receives a SERVFAIL or a resolution timeout. From the visitor's perspective, your site is completely offline. From your monitor's perspective, nothing has changed.

Why long TTLs protect users but blind your alerts

A common piece of advice in DNS administration is to use relatively long TTLs, such as 3600 seconds (one hour) or 86400 seconds (one day), for stable production records. Long TTLs are genuine lifesavers during infrastructure incidents. If an authoritative DNS provider goes down for two hours, an application with a 24-hour TTL might see almost all of its existing traffic proceed uninterrupted because existing resolvers continue to serve the cached record. However, that same resilience creates a massive blind spot for basic synthetic monitors. If your monitoring tool relies on the standard system resolver of its host server, it benefits from the exact same cache shield that protects regular users. You end up in a situation where the underlying service is effectively inaccessible to new visitors or systems with cold caches, but your alerting platform will not page you until the cache expires hours later. Furthermore, even after an authoritative provider recovers, resolution does not return uniformly. Different recursive resolvers around the world evict records at different times, and some resolvers cache negative responses (when a lookup fails) for a period defined by your zone's Start of Authority (SOA) record. This leads to a rolling, inconsistent recovery where some regions work while others remain broken.

Common pitfalls in DNS monitoring

The most frequent mistake is assuming that an HTTP or HTTPS check tests the entire delivery pipeline. An HTTP check tests that the web application, the TLS handshake, and the underlying server respond with the expected status code. It does not test whether the authority behind that domain is actually functional. A second mistake is setting an artificially tiny TTL—such as thirty seconds—across all records simply to make HTTP monitors detect nameserver drops faster. While this removes the cache shield and makes monitors fail sooner during an authoritative drop, it also removes the entire safety net of DNS. Every single user query requires an active authoritative lookup. If your nameservers experience a brief two-second hiccup or rate-limiting event, your users will feel it instantly. A third misconception is relying on a single DNS provider because they advertise redundant nameservers. A provider might list four nameservers across different IP ranges, but if all four rely on the same control plane, the same Autonomous System (ASN), or the same underlying routing architecture, a shared failure can take all of them offline simultaneously.

Setting up direct authoritative checks

To detect an authoritative DNS failure before your users start filing complaints, your synthetic monitoring must bypass recursive caching entirely and query your designated nameservers directly. You can observe the difference from the command line using dig. When you query normally, you ask your local recursive resolver. To query the authority directly, you point the query at the specific nameserver assigned to your domain and disable recursion by setting the +norecurse flag:

BASH

# Query the authoritative nameserver directly without relying on resolver caching
dig @ns1.exampledns-provider.com example.com A +norecurse +time=2 +tries=1

In this command, @ns1.exampledns-provider.com tells dig to bypass your local network's resolver and send the UDP query straight to the authoritative server. The +norecurse flag explicitly tells the remote server: "Only answer if you are authoritative for this zone; do not ask anyone else on my behalf." If the authoritative server is healthy, it returns the record with the aa (Authoritative Answer) flag in the header. If the nameserver is unreachable, experiencing internal engine failures, or dropping packets, the command times out immediately. Modern monitoring stacks allow you to create explicit DNS checks alongside your standard HTTP probes. Instead of configuring a single check that requests https://example.com, configure a separate synthetic probe for every nameserver listed in your domain's delegation. The probe should execute a direct UDP/TCP query against the nameserver IP address, request an address record from your domain, and verify that it receives a response containing the authoritative flag within an acceptable timeout. When you separate the health of your authoritative nameservers from the health of your web application, your monitoring matches reality. Your HTTP checks will confirm that your web workers and databases are processing requests, while your direct nameserver checks will alert you the moment the foundation of your domain resolution begins to crack.