Stale Answer Client Option SACO Serving Expired Records

The Domain Name System is expected to be fast, accurate, and always available, but the inherent structure of its operation creates moments of potential failure. DNS resolvers rely heavily on caching to reduce latency and improve performance. Cached responses come with a time-to-live (TTL) value, after which the data is considered stale and must be refreshed from the authoritative source. However, when that authoritative server is temporarily unreachable—due to network issues, denial-of-service attacks, misconfiguration, or outages—resolvers face a dilemma: either fail the query with a SERVFAIL response or serve stale data that may be technically outdated but functionally useful. This tradeoff is addressed by the Stale Answer Client Option (SACO), a relatively new mechanism that standardizes how resolvers can serve expired DNS records to requesting clients in a controlled and transparent way.

Stale answer serving is not entirely new. For years, DNS implementations like Unbound and BIND have included features that allow them to serve stale data under certain conditions, particularly when refreshing the record from the authoritative server results in a timeout or failure. The practice was formally described in RFC 8767, which defines the rules for serving stale data from cache to maintain availability. However, this approach operated at the discretion of the resolver and without explicit signaling to clients. Clients had no way to request stale data or to know whether the answer they received was current or expired. This lack of visibility limited the flexibility and trustworthiness of stale answer serving, particularly in enterprise and application contexts where understanding the freshness of data is crucial.

The Stale Answer Client Option, described in the Internet draft draft-ietf-dnsop-saco-02, proposes a solution by extending the EDNS(0) mechanism with a new option code that allows clients to explicitly indicate their willingness to receive stale answers. SACO empowers clients to influence resolver behavior, providing an opt-in mechanism rather than leaving stale answer serving entirely up to the resolver’s policies. By embedding the SACO flag into a query, a client effectively tells the resolver, “I prefer fresh data, but if you cannot get it, I’m okay with something stale.” This level of control is especially valuable in applications that require high availability, such as content delivery platforms, security tools, or real-time systems, where a slightly outdated record is preferable to complete failure.

Under SACO, the resolver receiving the query inspects the EDNS(0) options and, if the authoritative query fails and the client has indicated support for stale responses, it may serve a stale cached answer. To distinguish these responses, the resolver adds a new EDNS option to the response, signaling that the data is stale and providing metadata about its age. This allows clients to make informed decisions about how to handle the response—perhaps using it with reduced trust or attempting a secondary resolution path. This structured signaling enhances resilience without introducing silent data inconsistencies, a key concern in systems where integrity and freshness are closely monitored.

One of the critical benefits of SACO is that it formalizes a behavior that was previously implementation-specific and opaque. Different resolvers handled stale data differently, and clients had no way to know whether stale serving was even enabled. SACO brings consistency to the ecosystem, enabling applications, libraries, and operating systems to adopt standardized behaviors and adapt their logic accordingly. For example, a mobile app that performs DNS lookups for backend APIs could use SACO to ensure that transient DNS outages do not block user actions, while still displaying a warning or logging an event when stale data is used.

From an operational standpoint, SACO reduces the pressure on authoritative DNS servers during outage events. When a server becomes unreachable, resolvers that support SACO can continue to serve stale data to clients that accept it, smoothing over the failure and reducing the cascade of retries that might otherwise contribute to further congestion or denial-of-service conditions. This not only improves client experience but also enhances the overall stability of the DNS ecosystem during stress periods. For large-scale operators and cloud platforms, SACO represents a pragmatic tool for resilience without sacrificing transparency.

Implementing SACO involves updates on both the client and resolver sides. Clients must be updated to include the SACO option in their EDNS(0) records and to handle the new response metadata, while resolvers must be able to inspect, honor, and respond appropriately to the option. The uptake of SACO is expected to begin with programmable clients, such as embedded systems, browsers, and enterprise agents, before becoming more widespread in consumer-facing operating systems and applications.

As with any protocol extension, SACO raises questions around security and consistency. Serving stale data inherently carries a risk that outdated or incorrect information could propagate. SACO mitigates this by making the client’s consent explicit and by tagging stale responses clearly, but it does not eliminate the underlying risk. DNSSEC validation still applies to stale data, meaning that a resolver can verify the signature of an expired record, but the signature’s validity window must still be within acceptable bounds. This constraint ensures that DNSSEC remains a guardrail against tampered data, even when freshness is relaxed for availability.

In conclusion, the Stale Answer Client Option represents a thoughtful and necessary evolution of DNS behavior in an increasingly availability-sensitive internet. By empowering clients to choose stale data when fresh data is unavailable, SACO enhances the resilience of applications while preserving the transparency and integrity of DNS interactions. It aligns with broader trends in internet architecture toward graceful degradation, adaptive behavior, and informed decision-making. As DNS continues to evolve in response to modern demands, SACO offers a balanced approach to one of its most persistent challenges: how to keep systems responsive and trustworthy in the face of inevitable disruption.

The Domain Name System is expected to be fast, accurate, and always available, but the inherent structure of its operation creates moments of potential failure. DNS resolvers rely heavily on caching to reduce latency and improve performance. Cached responses come with a time-to-live (TTL) value, after which the data is considered stale and must be…