The concept of shifting that behavior to the client versus having the DNS infrastructure handle it could have a wide array of undesirable consequences. Given the prevalence of the use of global server load balancing (GSLB) technology, which often relies on low TTLs to be able to control traffic flow, this kind of behavior could possibly break all kinds of application infrastructures both internally and externally.
Thanks, Ross On Fri, Jun 5, 2026 at 7:48 AM Libor Peltan <libor.peltan= [email protected]> wrote: > Hi, > > thank you for bringing this topic, especially considering it is already > deployed for years. > > I'm not a fan of using any DNS records past their TTL. Authoritatives > often (and in various ways) rely on the fact that the RRs are not used > after their TTLs expire. > > Regarding Serve Stale, the argument is that it makes less damage to use > expired RRs, than fail. I'm not really comfortable even with that. > > Rather than Optimistic DNS, I would like to see wider adoption of > pre-fetching in resolvers. This means that if a frequently queried, > soon-to-expire record is re-queried at authoritatives, so that it never > expires in the cache. And yes, it heavily depends on the setting of > "frequently queried" and "soon-to-expire". The biggest disadvantage of the > pre-fetching is that it does not work when forwarding to another resolver, > which doesn't pre-fetch as well. > > I guess the pre-fetching feature is mostly implemented in common > resolvers, but not always enabled by default. Maybe we should advocate for > enabling it by default and used practically everywhere. > > Anyway, if Optimistic DNS would still be the way to go, I'd recommend to > strongly limit the amount of time past the TTL expiration, in which the RR > can be optimisticly returned. If it expired just four seconds ago, it is > probably OK. If more than hour, than please don't. I especially dislike the > draft's paragraph 7.4. > > > Libor > On 03. 06. 26 22:54, Gautam Akiwate wrote: > > Greetings, > > We have submitted a new draft that describes Optimistic DNS a client-side > stub resolver > mechanism that immediately returns expired cached records to applications > while issuing > a fresh network query in parallel to refresh the record eliminating the > latency spikes on > TTL expiry. > > As a note mDNSResponder (default stub resolver on all Apple platforms) has > shipped this since > macOS 10.14 / iOS 12 (September 2018) so the document captures already > deployed behavior. > The main impetus for writing this draft was discussions in the HAPPY WG > around these ideas. > > We look forward to feedback on this document. > > Thanks > Gautam > > > Begin forwarded message: > > *From: *[email protected] > *Subject: **New Version Notification for > draft-gakiwate-dnsop-optimistic-dns-00.txt* > *Date: *June 3, 2026 at 1:15:21 PM PDT > *To: *"Gautam Akiwate" <[email protected]> <[email protected]>, "Phil > Flack" <[email protected]> <[email protected]>, "Stuart Cheshire" > <[email protected]> <[email protected]> > > A new version of Internet-Draft draft-gakiwate-dnsop-optimistic-dns-00.txt > has > been successfully submitted by Gautam Akiwate and posted to the > IETF repository. > > Name: draft-gakiwate-dnsop-optimistic-dns > Revision: 00 > Title: Optimistic DNS > Date: 2026-06-03 > Group: Individual Submission > Pages: 30 > URL: > https://www.ietf.org/archive/id/draft-gakiwate-dnsop-optimistic-dns-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gakiwate-dnsop-optimistic-dns/ > HTML: > https://www.ietf.org/archive/id/draft-gakiwate-dnsop-optimistic-dns-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-gakiwate-dnsop-optimistic-dns > > > Abstract: > > DNS lookups introduce user-visible delay, particularly when cached > records have expired and must be refreshed from the network. This > document describes Optimistic DNS, a client-side stub resolver > mechanism that immediately returns expired cached DNS records to > applications while simultaneously refreshing them with a network > query. The application receives an answer in microseconds rather > than milliseconds, and if the data has changed receives an updated > answer shortly thereafter. Optimistic DNS is complementary to RFC > 8767, which addresses serving stale data at recursive resolvers. > This document focuses exclusively on client-side stub resolver > behavior, including explicit signaling from the application to inform > the stub resolver that the application is able to handle old and > possibly incorrect information. > > > > The IETF Secretariat > > > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
