



Domain Name System Operations                                 G. Akiwate
Internet-Draft                                                  P. Flack
Intended status: Standards Track                             S. Cheshire
Expires: 5 December 2026                                      Apple Inc.
                                                             3 June 2026


                             Optimistic DNS
                 draft-gakiwate-dnsop-optimistic-dns-00

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.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://gakiwate.github.io/draft-gakiwate-dnsop-optimistic-dns/draft-
   gakiwate-dnsop-optimistic-dns.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-
   gakiwate-dnsop-optimistic-dns/.

   Discussion of this document takes place on the Domain Name System
   Operations Working Group mailing list (mailto:dnsop@ietf.org), which
   is archived at https://mailarchive.ietf.org/arch/browse/dnsop/.
   Subscribe at https://www.ietf.org/mailman/listinfo/dnsop/.

   Source for this draft and an issue tracker can be found at
   https://github.com/gakiwate/draft-gakiwate-dnsop-optimistic-dns.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.



Akiwate, et al.          Expires 5 December 2026                [Page 1]

Internet-Draft               Optimistic DNS                    June 2026


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 December 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
   4.  The Preemptive Refresh Problem - Zeno’s Paradox . . . . . . .   9
   5.  Enabling Technologies . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Asynchronous DNS Resolution . . . . . . . . . . . . . . .  10
     5.2.  Happy Eyeballs  . . . . . . . . . . . . . . . . . . . . .  11
     5.3.  Combined Effect . . . . . . . . . . . . . . . . . . . . .  13
   6.  Optimistic DNS Overview . . . . . . . . . . . . . . . . . . .  13
   7.  Implementation Details  . . . . . . . . . . . . . . . . . . .  15
     7.1.  Query Initiation  . . . . . . . . . . . . . . . . . . . .  15
     7.2.  Cache Lookup with Expired Records . . . . . . . . . . . .  15
     7.3.  Parallel Network Query  . . . . . . . . . . . . . . . . .  16
     7.4.  Cache Management  . . . . . . . . . . . . . . . . . . . .  16
     7.5.  CNAME Handling  . . . . . . . . . . . . . . . . . . . . .  17
   8.  Interaction with Other DNS Features . . . . . . . . . . . . .  18
     8.1.  Uncacheable Records . . . . . . . . . . . . . . . . . . .  18
     8.2.  DNSSEC  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.3.  DNS Domain Name Search Lists  . . . . . . . . . . . . . .  18
     8.4.  Encrypted DNS Transports  . . . . . . . . . . . . . . . .  20



Akiwate, et al.          Expires 5 December 2026                [Page 2]

Internet-Draft               Optimistic DNS                    June 2026


     8.5.  Serving Stale Data at Recursive Resolvers . . . . . . . .  20
   9.  Operational Considerations  . . . . . . . . . . . . . . . . .  21
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  22
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     12.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Appendix A.  Deployment History . . . . . . . . . . . . . . . . .  25
     A.1.  Optimistic DNS in mDNSResponder . . . . . . . . . . . . .  25
       A.1.1.  Signaling . . . . . . . . . . . . . . . . . . . . . .  26
       A.1.2.  Record Lifecycle  . . . . . . . . . . . . . . . . . .  27
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   In the early days of the Internet, computers and network connections
   were much slower than they are now.  Delays of a few tens or hundreds
   of milliseconds used to be insignificant compared to the overall time
   taken to load a web page.  Today, increases in computing power and
   network throughput have dramatically reduced previous major causes of
   slowness.  To continue progress on improving user experience, we need
   to identify and reduce the remaining sources of delay, which -- as
   other aspects of computer and network performance improve -- now
   constitute a larger proportion of the overall web page load time.
   Computer processing speed and network throughput continue to
   increase, but the speed of light isn’t changing.

   When a user views a website, the first step is typically a DNS lookup
   to translate the hostname into an IP address.  If the device's DNS
   cache contains a record for that hostname, the answer is returned
   almost instantly and the user perceives no delay.  But if the
   record's TTL has expired by even a single second, the device must
   perform a fresh DNS lookup.  On a wired connection this might take 50
   to 200 milliseconds.  On a cellular connection, particularly at the
   edge of coverage, it can take several seconds.

   The user experiences this as a brief but noticeable pause.  The
   website appears to hang.  The user wonders if something is wrong.
   And in most cases, the expired record still contained the correct IP
   address and the website has not moved to a different server.  The
   user waited for confirmation of something the device already knew.

   Consider a record for www.example.com with a TTL of 60 seconds.  At
   time T=0 the record is fetched and cached.  For the next 60 seconds,
   any application that asks for www.example.com gets an instant answer.
   At time T=61, the record has expired.  The very next lookup must go
   to the network.  From the user's perspective, the transition from



Akiwate, et al.          Expires 5 December 2026                [Page 3]

Internet-Draft               Optimistic DNS                    June 2026


   "instant" to "slow" is a sudden large spike.  The record was valid
   for 60 seconds, giving cached results in microseconds, then invalid
   for the fraction of a second it took to refresh it, resulting in a
   delay of tens or hundreds of milliseconds, then valid again, with the
   delay returning to microseconds.  Yet that intermittent slowness will
   be the experience that the user notices when the rest of their web
   browsing is usually consistently fast.

   This document describes Optimistic DNS, a stub resolver mechanism
   that addresses this problem.  When the stub resolver has expired
   cached records that match a query, it returns those expired records
   to the application immediately while simultaneously issuing a fresh
   network query in the background.  The application first receives the
   expired (but likely still correct) records, and then shortly
   afterwards, the authoritative fresh records, if different.  Using the
   (expired, but probably correct) address from the cache, the
   networking library code that the application is using will start
   connecting.  While connecting, the networking library code MUST
   continue to pay attention to asynchronous notifications of new
   addresses as they are learned, and the networking library code MUST
   react gracefully if, occasionally, some of the candidate addresses
   do, in fact, prove to be stale and incorrect (Section 5).

   The following diagram illustrates the timing difference between
   conventional DNS resolution and Optimistic DNS:

   *Conventional DNS (after cache expiry):*

     Application        Stub Resolver        DNS Server
         |                    |                    |
         |--- Query --------->|                    |
         |                    |--- Query --------->|
         |                    |                    |
         |          (waiting for network)          |
         |                    |                    |
         |                    |<-- Response -------|
         |<-- Fresh Answer ---|                    |
         |                    |                    |
         [====== 150ms+ delay ======]

   *Optimistic DNS (after cache expiry):*










Akiwate, et al.          Expires 5 December 2026                [Page 4]

Internet-Draft               Optimistic DNS                    June 2026


     Application        Stub Resolver        DNS Server
         |                    |                    |
         |--- Query --------->|                    |
         |<- Expired Answer --|--- Query --------->|
         |   (~0ms delay)     |                    |
         |                    |                    |
         |  (app can start    |                    |
         |  connecting now)   |                    |
         |                    |<-- Response -------|
         |<-- Fresh Answer ---|                    |
         |    (if changed)    |                    |

   Optimistic DNS is complementary to Serving Stale Data to Improve DNS
   Resiliency [RFC8767], which allows recursive resolvers to serve stale
   data during upstream failures.  The two mechanisms differ in their
   focus.  As reflected in the document title, the specification for
   serving stale data from recursive resolvers was focused on improving
   resiliency in situations where the authoritative servers are down or
   unreachable.  Optimistic DNS is focused on enhancements to the stub
   resolver on the end-user's device, to reduce delays even in cases
   where the authoritative servers are functioning perfectly well.  Both
   can be deployed simultaneously for layered staleness tolerance.

   This document describes only the client-side behavior.  Optimistic
   DNS does not define any new DNS wire-protocol messages, opcodes, or
   EDNS options.  The signaling between the stub resolver and the
   application is purely a local API matter.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   _Stub Resolver._  A DNS resolver that operates on the end-user
      device.  It maintains a local cache of DNS records and forwards
      queries to configured recursive resolvers when cached answers are
      unavailable or expired.  This is the component that implements
      Optimistic DNS.

   _Expired Record._  A cached DNS record whose TTL has reached zero.
      Under conventional DNS caching rules, such a record would be
      purged from the cache or ignored when answering queries.

   _Optimistic Answer._  An expired cached record that is returned to an




Akiwate, et al.          Expires 5 December 2026                [Page 5]

Internet-Draft               Optimistic DNS                    June 2026


      application in response to a query, before the stub resolver has
      confirmed whether the record's data is still current.

   _Fresh Answer._  A DNS record received from the network in response
      to a query, as opposed to a record served from the local cache.
      Fresh answers reflect the data known by the upstream recursive
      resolver, which may be more recent than the data in the local
      cache.

   _Asynchronous DNS Resolution._  A DNS resolution model where the
      application initiates a query and receives results through
      callbacks or event notifications as they become available, rather
      than blocking until a single atomic set of answers is returned all
      at once (Section 5.1).

   _Happy Eyeballs._  A client-side connection establishment algorithm
      [IETF72] [RFC6555] [RFC8305] [HEv3] that races connection attempts
      across multiple addresses and address families, using whichever
      connection succeeds first (Section 5.2).

3.  Problem Statement

   The DNS TTL mechanism creates an inherent tension between freshness
   and performance.  When a record is cached and its TTL has not
   expired, lookups are essentially free and the answer is returned from
   local memory in microseconds.  The moment the TTL expires, the cost
   jumps to a full network round trip.  This is not a graceful
   degradation.  It is a dramatic spike.

   This problem is compounded by several factors:

   _Short TTLs._  Many content delivery networks and cloud services use
      TTLs of 60 seconds or less to facilitate rapid failover and load
      balancing.  Short TTLs mean more frequent cache expiration events,
      which means users hit the delay spike more often.

   _High-latency networks._  On cellular networks, satellite links, or
      congested Wi-Fi, a DNS round trip can take one to five seconds.
      The penalty for a cache miss is severe.

   _Multiple queries per page load._  A typical web page load involves
      DNS queries for dozens of hostnames (the page itself, stylesheets,
      scripts, images, analytics, ads).  Often these DNS queries cannot
      be issued concurrently because some of the hostnames are not known
      until earlier transactions complete.  For example, the hostnames
      for stylesheets and images are not known until after the base HTML
      document is fetched.  If multiple hostnames have expired address
      records, the cumulative delay can be substantial.



Akiwate, et al.          Expires 5 December 2026                [Page 6]

Internet-Draft               Optimistic DNS                    June 2026


   _First query after sleep._  While a computer or smartphone is
      sleeping, normal wall-clock time continues to elapse, and by the
      time the device awakes, many cached records may have expired.
      Optimistic DNS avoids the delay penalty when a device is used
      after sleep or any other extended period of inactivity.

   The fundamental observation behind Optimistic DNS is that in most
   cases, a DNS record that expired a little while ago usually still
   contains the correct data.  Servers do not typically change IP
   addresses the instant a TTL expires.  The TTL is a freshness hint,
   not a correctness deadline.  It marks when the resolver decides to
   refresh, not when the data becomes incorrect.

   The "stale" state is also relative.  A user querying the same record
   at two different resolvers can see entirely different views of
   staleness.  The diagram below illustrates this: both Recursive A and
   Recursive B cached A1 before the authoritative server replaced it
   with A2 at T=90.  But because each resolver started its TTL clock at
   a different moment, they present a different view to their clients.
   A client querying Recursive A at time T=80 will cause a DNS request
   to the authoritative DNS server to retrieve fresh data.  A client
   querying Recursive B twenty seconds later at time T=100 will receive
   cached data because Recursive B considers it still valid.




























Akiwate, et al.          Expires 5 December 2026                [Page 7]

Internet-Draft               Optimistic DNS                    June 2026


   Time:
    0 --- 15 --- 30 --- 45 --- 60 --- 75 --- 90 -- 105 -- 120

   Authoritative Nameserver:
   -------------------- A1 -------------------|----- A2 -----
                                              ^
                                 Authoritative Answer Changes
                                 At T=90 A1 is replaced by A2

   Recursive A queries at T=15:
           +--------------------------+
           |    Cached A1 (TTL=60)    |
           +--------------------------+
          15 --- 30 --- 45 --- 60 --- 75  |
                                          |
                                          v
                               Client 1 queries at T=80:
                                    A1 TTL expired
                                      New Query

   Recursive B queries at T=45:
                         +--------------------------+
                         |    Cached A1 (TTL=60)    |
                         +--------------------------+
                        45 --- 60 --- 75 --- 90 -- 105
                                                 |
                                                 |
                                                 v
                                      Client 2 queries at T=100:
                                          A1 TTL still valid
                                          Returns cached A1
                                           (now incorrect).

   Client 1 issued a query at time T=80 and suffered a delay waiting for
   “fresh” data, even though, at that time, the data on the
   authoritative nameserver had not yet changed.  In this case, using
   the expired cached data would have been fine, because it was still
   correct.

   Client 2 issued a query twenty seconds later at time T=100, yet
   Recursive B happily sent it cached data that was no longer correct.










Akiwate, et al.          Expires 5 December 2026                [Page 8]

Internet-Draft               Optimistic DNS                    June 2026


   If the data was already considered “expired” at time T=80, it might
   be natural to think that 20 seconds later it should be even more
   expired, yet Client 2 received the opposite behavior.  Statistically,
   averaged over a large set of queries, records that are older relative
   to their published TTL are more likely to be considered expired, but
   for a specific individual query the results are much less
   deterministic.

   Thus, clients should not attach too much importance to the absolute
   value of a record’s age relative to its declared TTL.  The age of a
   record is a valuable hint as to whether it should be assumed to be
   still valid, but it is not a guarantee.  Data being younger than its
   TTL is not a guarantee that it is still correct, and data being older
   than its TTL is not a guarantee that it is wrong.

   The asynchronous connection-racing mechanism known as Happy Eyeballs
   [IETF72] [RFC6555] [RFC8305] [HEv3] is a key technology that makes
   Optimistic DNS useful, because it makes applications more robust in
   occasional situations where they may briefly receive incorrect
   information (Section 5.2).

4.  The Preemptive Refresh Problem - Zeno’s Paradox

   One seemingly attractive approach to avoiding the delay spike might
   be to take inspiration from DHCP [RFC2131] [RFC2132], and renew a
   record before it expires, instead of waiting until after it is
   already expired before requesting an update.  DHCP typically renews
   an address lease when half of the lease lifetime has elapsed, rather
   than waiting for the lease to expire and then briefly losing the
   right to use that IP address while a new request is processed.

   Unfortunately, because of the way DNS operates, the DHCP-inspired
   approach of refreshing records in advance of their expiration does
   not work.

   Suppose a DNS stub resolver makes a request for a name that is not
   currently in the recursive resolver’s cache.  Suppose that when the
   recursive resolver fetches the authoritative record it has a TTL of
   24 hours, which it returns to the stub resolver.

   If the stub resolver were to request the same record 12 hours later,
   the recursive resolver will tell the stub resolver that the record
   has a remaining TTL of 12 hours.

   If the stub resolver were to request the same record 6 hours after
   that, the recursive resolver will tell the stub resolver that the
   record now has a remaining TTL of 6 hours.




Akiwate, et al.          Expires 5 December 2026                [Page 9]

Internet-Draft               Optimistic DNS                    June 2026


   Using this algorithm would result in an ever-accelerating query rate
   as the remaining TTL continues to count down towards zero, without
   the stub resolver learning anything new.

   Eventually, the record finally expires from the recursive resolver’s
   cache, and the stub resolver then suffers a delay spike waiting for
   the recursive resolver to fetch the authoritative record.

   Currently, recursive resolvers will continue to return a cached
   record down to the last second of its lifetime.  Even for a record
   that is the subject of a large volume of queries, recursive resolvers
   will not take the initiative of refreshing that record prior to its
   inevitable and entirely predictable expiration.  Instead, recursive
   resolvers will let the record expire, and then suffer a delay spike
   on the very next query.

   With the current behavior of recursive resolvers, strictly respecting
   a record’s TTL and avoiding predictable delay spikes are incompatible
   goals.  It is impossible to do both.

5.  Enabling Technologies

   When an application receives an expired address and immediately
   begins connecting to it, two things need to happen:

   *  When the fresh answer arrives moments later, the application needs
      a way to receive it -- which means the DNS API has to support
      delivering asynchronous results as they arrive.

   *  If the expired address is found to be wrong, the application needs
      to continue gracefully.

5.1.  Asynchronous DNS Resolution

   Traditional synchronous DNS APIs typically block until the complete
   set of answers is available.  The caller issues a query, waits,
   receives one set of results, and the call is complete.  Optimistic
   DNS cannot function with this model since there is no mechanism to
   deliver an expired answer now and update it with newer answers
   shortly afterwards.

   Asynchronous DNS APIs support receiving multiple answers over time,
   including updated answers that supersede earlier ones.  The
   operational model of asynchronous DNS resolution is that it is a
   performance optimization over rapid polling.  If an application were
   to call an API like getaddrinfo() as fast as it can in a tight loop,
   then the application would always have the latest information
   available from the local stub resolver, but it would be inefficient



Akiwate, et al.          Expires 5 December 2026               [Page 10]

Internet-Draft               Optimistic DNS                    June 2026


   and wasteful of CPU time.  Most consecutive calls to getaddrinfo()
   would return unchanged information.  The guiding principle of an
   asynchronous DNS resolution API is that it gives the application the
   exact same information as repeated calls to the equivalent
   synchronous API, but more efficiently.  If a fresh new query would
   yield different results, then the client’s asynchronous DNS operation
   MUST be given asynchronous notifications to deliver the new set of
   results.  This avoids the temptation for clients to resort to
   polling, in the belief that polling gives them better results than
   trusting the asynchronous notification mechanism.  For efficiency,
   the application is notified via an asynchronous notification only
   when the set of answers changes.  This is similar to the efficiency
   trade-offs present in other APIs, where asynchronous notification is
   more efficient than polling.  For example, an application can
   repeatedly poll to find if the content of a directory has changed,
   but using asynchronous filesystem notifications gives the same effect
   more efficiently.

   This is the resolution model defined by Multicast DNS [RFC6762] and
   is valuable for unicast DNS too.  Asynchronous DNS resolution is
   supported in Apple’s networking APIs [ZC], and in other DNS stub
   resolver implementations like getdns [getdns].

   This model naturally supports the incremental delivery that
   Optimistic DNS requires.  Expired records arrive in the first
   callback, within microseconds.  Fresh records from the network arrive
   in subsequent callbacks, within milliseconds.  The application can
   act on the expired answer immediately by opening a connection.  If
   the address has changed, the application can start a new connection
   to the updated address.  If the address is the same, the connection
   is already established and the fresh answer serves as confirmation.

5.2.  Happy Eyeballs

   Optimistic DNS delivers DNS answers quickly, with the caveat that, on
   rare occasions, some of those answers might be stale and incorrect,
   in which case updated answers will be delivered as soon as they are
   available.  To make this optimistic approach viable, it MUST be
   coupled with networking code that is designed to embrace this
   uncertainty, and account for the fact that all data received from a
   network is necessarily at least a little stale by the time it
   arrives, and may subsequently be found to be incorrect.  Without
   Happy Eyeballs, a wrong expired address would mean a failed
   connection and user frustration.

   Happy Eyeballs [IETF72] [RFC6555] [RFC8305] [HEv3] defines algorithms
   for racing connection attempts across multiple addresses and address
   families.  When a client has several candidate addresses for a



Akiwate, et al.          Expires 5 December 2026               [Page 11]

Internet-Draft               Optimistic DNS                    June 2026


   destination, Happy Eyeballs staggers connection attempts, in order of
   expected likelihood of success, with short delays, and uses whichever
   connection succeeds first.

   The Happy Eyeballs mechanism pairs naturally with Optimistic DNS.
   When using Happy Eyeballs, the networking code takes the set of
   answers immediately available in the local cache and selects the
   address it predicts is most likely to succeed.  If the prediction is
   correct, which is the common case, the connection succeeds and no
   additional traffic is generated.  The connection may succeed before
   the fresh DNS answer from the network even arrives.

   In the rare cases where the first connection attempt does not succeed
   within the expected network round-trip time, the TCP SYN (or
   equivalent connection request packet) is retransmitted, and a second
   connection attempt is immediately initiated to the next address in
   order of preference.  The first connection attempt is not abandoned
   when the second one starts -- its usual schedule of retransmissions
   is still followed -- and the two attempts proceed in parallel.  If
   the second connection attempt does not succeed within the expected
   time, a third attempt is initiated, and so on.

   Running connection attempts in parallel rather than sequentially
   prevents long stalls waiting for a connection to time out and fail
   before the next attempt is started.  Staggering the start times by
   the expected response time means that in the majority of cases only
   the first connection attempt is needed, which avoids generating
   unnecessary network traffic or extra load on servers.

   If new DNS results are received during this procedure, the list of
   candidate addresses is updated accordingly for use in subsequent
   connection requests.

   Using Optimistic DNS in conjunction with Happy Eyeballs means that,
   in the common case, a connection to the correct server is made
   faster, with no additional network traffic.  In the rare case when a
   server address has actually changed, the cost is a small amount of
   wasted network traffic while waiting for the DNS reply.  Once the
   reply arrives, Happy Eyeballs can immediately connect to the correct
   server, with no additional delay beyond what would have been
   experienced had the application just waited for the DNS reply in the
   first place.  The cost of waiting for a fresh answer that simply
   confirms what the cache already had is a guaranteed delay of the full
   network round-trip time on every cache expiry.  For most
   applications, the expected value of the optimistic approach is
   clearly positive.





Akiwate, et al.          Expires 5 December 2026               [Page 12]

Internet-Draft               Optimistic DNS                    June 2026


   After the Happy Eyeballs algorithm has succeeded in establishing a
   connection to an acceptable destination (determined by verifying the
   TLS certificate, or otherwise, as appropriate) the asynchronous DNS
   operation MUST be stopped.  Once an application has established a
   successful connection, it should make its future decisions based on
   the viability of that connection, rather than any subsequent
   information to the contrary received from asynchronous DNS.
   Cancelling the asynchronous DNS operation prematurely, before a
   successful connection has been established, would prevent the
   reception of future updated answers, which would defeat the purpose
   of Optimistic DNS, which is to deliver available answers quickly
   while still ensuring eventual correctness.  Failure to cancel after
   an acceptable connection has been made would be a waste of resources,
   and in the extreme case would constitute a resource leak on the
   client device.

   Applications using Optimistic DNS and Happy Eyeballs SHOULD follow
   appropriate security practices (Section 10) to ensure that they are
   connecting to the intended host or service on the network.

5.3.  Combined Effect

   Asynchronous DNS resolution makes Optimistic DNS _possible_.  It
   provides the delivery mechanism for multiple waves of results.  Happy
   Eyeballs makes Optimistic DNS _safe_.  It ensures that acting on a
   wrong expired address is not fatal to the overall connection attempt.
   Together, the application starts connecting instantly with
   provisional cached addresses, the connection race handles any
   staleness gracefully, and the fresh DNS answer arrives as an update
   confirming or correcting the initial result.

6.  Optimistic DNS Overview

   Building on the asynchronous resolution model and connection racing
   described above, Optimistic DNS introduces a specific modification to
   stub resolver behavior.  When an application that has opted in issues
   a DNS query and the stub resolver's cache contains expired records
   matching that query, the resolver performs two actions in parallel:

   1.  It immediately returns the expired cached records to the
       application.

   2.  It issues a standard DNS query on the network to obtain fresh
       records.







Akiwate, et al.          Expires 5 December 2026               [Page 13]

Internet-Draft               Optimistic DNS                    June 2026


   As fresh answers arrive from the network, the resolver delivers them
   to the application through the asynchronous callback mechanism.
   Table 1 shows both waves for a query where www.example.com has an
   expired A record (203.0.113.34) in the cache, and the fresh answer
   returns the same address:

      +=========+===============================+===================+
      | Time    | Event                         | Notes             |
      +=========+===============================+===================+
      | T+0us   | App queries www.example.com   |                   |
      +---------+-------------------------------+-------------------+
      | T+5us   | Callback: 203.0.113.34        | Expired           |
      +---------+-------------------------------+-------------------+
      | T+120ms | (data unchanged, no callback) | Fresh Answer Same |
      +---------+-------------------------------+-------------------+

               Table 1: Optimistic DNS when data is unchanged

   When a fresh positive answer matches the previous Optimistic Positive
   Answer, no second callback is delivered.  The application that began
   connecting at T+5us saved 120 milliseconds compared to waiting for
   the fresh answer.

   When the data has changed (for example, if the server moved to a new
   address), or a fresh negative answer confirms a previous Optimistic
   Negative Answer, the application is notified.  Sending confirmations
   of Optimistic Negative Answers is necessary because the client may be
   waiting for that negative answer confirmation before proceeding with
   its next steps.

    +=========+=============================+========================+
    | Time    | Event                       | Notes                  |
    +=========+=============================+========================+
    | T+0us   | App queries www.example.com |                        |
    +---------+-----------------------------+------------------------+
    | T+5us   | Callback: 203.0.113.34      | Expired                |
    +---------+-----------------------------+------------------------+
    | T+120ms | Callback: 198.51.100.42     | Fresh Answer Different |
    +---------+-----------------------------+------------------------+

              Table 2: Optimistic DNS when data has changed










Akiwate, et al.          Expires 5 December 2026               [Page 14]

Internet-Draft               Optimistic DNS                    June 2026


   In Table 2 the expired answer contained a stale and incorrect
   address.  An application that connected to 203.0.113.34 may find that
   the connection fails with an ICMP Host Unreachable error, a TCP RST,
   a TLS failure, or other unexpected content.  But the fresh answer
   arrives 120 milliseconds later, and the application can retry with
   the correct address.  The total time to a successful connection is
   still only about 120 milliseconds -- roughly the same as it would
   have been without Optimistic DNS.

   Optimistic DNS never makes things substantially worse for the
   application.  In the common case where the data has not changed, it
   makes things dramatically faster.  In the uncommon case where the
   data has changed and the server is no longer available at the
   previous address, the cost is a small amount of wasted traffic
   attempting to reach the previous address.

   Optimistic DNS is an opt-in mechanism.  Applications that do not
   request it receive conventional stub resolver behavior: expired
   records are ignored, and only fresh network answers are returned.
   This ensures backward compatibility and allows applications to choose
   the tradeoff that suits their needs.  Applications that do not
   support both Happy Eyeballs and appropriate application-layer
   security SHOULD NOT use Optimistic DNS.  These applications are very
   dependent on always getting the right answers from DNS every time,
   and do not recover gracefully when delivered stale data by Optimistic
   DNS.

7.  Implementation Details

7.1.  Query Initiation

   To use Optimistic DNS, an application signals its willingness to
   receive expired answers when it issues a DNS query.  This signaling
   is a local matter between the application and the stub resolver.

   One possible mechanism is for the stub resolver API to provide a flag
   that the application includes with its query.  Setting this flag
   indicates that the application is prepared to handle expired answers
   and will treat them appropriately.

7.2.  Cache Lookup with Expired Records

   When the stub resolver processes a query, it iterates through its
   cache looking for records that match the query's name, type, and
   class.  For each matching record, it determines whether the record
   has expired by comparing the time elapsed since the record was
   received against the record's original TTL.




Akiwate, et al.          Expires 5 December 2026               [Page 15]

Internet-Draft               Optimistic DNS                    June 2026


   If unexpired records are found in the cache, they are returned to the
   application as a normal cache hit and no network query is needed.

   If a matching cache entry (positive or negative) has expired, then
   this Optimistic Answer is delivered to the Optimistic DNS client.

   Optimistic Answers are subject to concurrent verification
   (Section 7.3) and may subsequently result in an asynchronous update
   to the client if newer information is discovered from the network.

   Optimistic Positive Answers indicate the stub resolver’s optimistic
   best guess of the answer.

   Optimistic Negative Answers (resulting from a previous NXDOMAIN or
   NODATA response) indicate the stub resolver’s best guess that the
   requested record probably still doesn’t exist.  Optimistic Negative
   Answers SHOULD NOT be used to generate error messages to the user.
   Such error messages SHOULD only be generated after a network query
   has confirmed that the named record still does not exist.  Optimistic
   Negative Answers can be useful in certain search scenarios (like
   applying DNS domain name search lists) where the nonexistence of a
   certain record is a prerequisite for using some other record, and the
   tentatively presumed nonexistence of a certain record can serve as a
   useful hint that the client should begin work speculatively looking
   up other names that may be required by the search algorithm
   (Section 8.3).

7.3.  Parallel Network Query

   If no unexpired records are found, the stub resolver MUST issue a
   standard DNS query on the network.  This query proceeds through the
   normal resolution path: contacting configured recursive resolvers,
   following CNAME chains, and so on.

   Fresh answers from the network are delivered to the application
   through an asynchronous callback mechanism.  The application’s
   networking code MUST use these fresh answers to update the list of
   answers it received earlier.

7.4.  Cache Management

   Storing expired records forever could consume an unbounded amount of
   memory, and return egregiously old records.

   For this reason, stub resolvers SHOULD NOT store records for more
   than one week after the TTL has expired.





Akiwate, et al.          Expires 5 December 2026               [Page 16]

Internet-Draft               Optimistic DNS                    June 2026


   The time limit of one week is selected so that a user could go home
   from work on a Thursday night, take a four-day long-weekend break,
   return to work the next Tuesday, and still benefit from using expired
   cached records for faster performance.  Storing expired records for
   less time risks eliminating the benefit of Optimistic DNS in many
   cases; storing expired records for more time is currently considered
   to offer little additional benefit, and using excessively old data
   could lead to unexpected undesirable consequences.

7.5.  CNAME Handling

   CNAME records introduce a complication for Optimistic DNS.  When a
   DNS query encounters a CNAME record, the resolver must follow one or
   more records in a CNAME chain to find the ultimate answer.  If a
   CNAME record itself is expired, it may no longer be correct.

   Consider the following example.  An application queries for
   www.example.com, which has a CNAME record pointing to
   cdn.example.net.  Both records are in the cache but expired:

     www.example.com.   CNAME  cdn.example.net.  (expired)
     cdn.example.net.   A      198.51.100.42     (expired)

   If the resolver follows the expired CNAME to cdn.example.net and
   returns the expired A record, the application receives a result.  But
   if the CNAME has changed (www.example.com now points to
   cdn2.example.net instead), the resolver has followed a stale chain
   and returned a record for the wrong name.

   To handle this correctly, when the stub resolver encounters CNAME
   records during optimistic resolution, it takes the following steps:

   1.  If the record is expired, and a background query is not already
       in progress for this record name, then a background query is
       initiated, as for any other expired record.

   2.  The CNAME referral is followed.  (If the target of the CNAME
       referral is another CNAME record, then this process repeats until
       a non-CNAME answer is found.)












Akiwate, et al.          Expires 5 December 2026               [Page 17]

Internet-Draft               Optimistic DNS                    June 2026


   3.  If, at any time while an asynchronous DNS query is active, the
       record data for any of the names in the CNAME chain changes, then
       the query is re-evaluated starting from the original query name,
       as if it were a fresh query.  This maintains the operational
       model of asynchronous DNS resolution, that it is simply a more
       efficient equivalent to repeated polling.  If a fresh new query
       would yield different results, then the client’s asynchronous DNS
       operation receives asynchronous notifications to deliver the new
       set of results, giving it the exact same information that a fresh
       query at that time would yield.

   This rewind-and-restart approach ensures that the application
   continues to receive a complete, consistent answer for its query,
   even as DNS record changes may mean that the CNAME chain for a given
   name changes over time.

8.  Interaction with Other DNS Features

8.1.  Uncacheable Records

   The DNS specifications require that DNS records with a TTL of zero
   MUST NOT be cached [RFC1035].  This document does not change that
   requirement; subsequent queries for these records always result in a
   new network request.

8.2.  DNSSEC

   Optimistic DNS extends the cache lifetime for DNS records, as
   signaled by the TTL values.

   Optimistic DNS does not extend the validity periods of cryptographic
   signatures.

   Optimistic DNS does not interpret the content of any records,
   including cryptographic records like RRSIG, and will deliver DNS
   records after their cache lifetime has expired.  Clients are
   responsible for checking and respecting the validity periods of
   cryptographic signatures.

8.3.  DNS Domain Name Search Lists

   Most DNS stub resolvers support domain name search lists [RFC1034].
   Domain name search lists can be configured manually, or learned
   automatically from the network using DHCP [RFC3397] [RFC3646] or IPv6
   Router Advertisements [RFC8106].






Akiwate, et al.          Expires 5 December 2026               [Page 18]

Internet-Draft               Optimistic DNS                    June 2026


   Applying domain name search lists can be thought of as an iterative
   search algorithm that operates at a layer above the stub resolver’s
   query mechanism.  Each query made in the course of executing the
   domain name search algorithm is a normal query for a fully qualified
   domain name, and is subject to all the usual procedures like
   following CNAME referrals.  Optimistic DNS can be used to speed up
   the process of handling domain name search lists.

   When a client issues a query for a name that is not considered fully
   qualified, the stub resolver applies each of the names from the
   domain name search list, in order, and uses the first name that
   returns a positive answer.  The user expectation is that the order of
   the domain name search list will be respected strictly.  This means
   that results from a later name in the search list cannot be used
   until negative answers have been confirmed for all the earlier
   entries in the search list.  The network queries do not need to be
   performed sequentially, one at a time (intelligently performing
   queries in parallel can result in a faster result for the user), but
   the final determination of which name to use cannot be made until all
   the necessary Optimistic Negative Answers have been confirmed.

   For this reason, Optimistic DNS can use Optimistic Negative Answers
   as a performance hint to tell it that it should start a parallel
   query for the next name in the search list, but the decision to use a
   particular answer needs to wait until all earlier Optimistic Negative
   Answers have been confirmed.

   If a stub resolver were to issue parallel queries for all names in
   the domain name search list, this could result in a lot of
   unnecessary network traffic, particularly for users with many names
   in their search lists.  If a stub resolver were to issue its queries
   sequentially, this could result in poor performance for the user.
   Optimistic DNS provides a good balance between these two extremes.
   Optimistic DNS allows the stub resolver to issue parallel queries for
   all the names it reasonably expects it will need to check, without
   generating wasteful traffic for names near the end of the domain name
   search list that come after a name that is believed to have a
   positive answer.  Optimistic DNS rapidly performs all the queries it
   needs to do to confirm record nonexistence, and then returns the
   first positive answer, whether fresh or expired.  If an expired
   positive answer turns out to be wrong when confirmed with a query on
   the network, then the newly updated answer is delivered
   asynchronously to the client.  If the newly updated answer is
   negative, then the domain name search algorithm resumes, continuing
   with the next untried name in the list, and continues until some
   positive answer, if any, is returned.





Akiwate, et al.          Expires 5 December 2026               [Page 19]

Internet-Draft               Optimistic DNS                    June 2026


8.4.  Encrypted DNS Transports

   Optimistic DNS is transport-agnostic.  It operates entirely within
   the stub resolver's cache layer, which sits above the transport
   layer.  Whether the stub resolver communicates with recursive
   resolvers using classic DNS over UDP/TCP [RFC1035], DNS over TLS
   (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484], or DNS over QUIC
   (DoQ) [RFC9250], the Optimistic DNS mechanism functions identically.

8.5.  Serving Stale Data at Recursive Resolvers

   Serving Stale Data to Improve DNS Resiliency [RFC8767] describes a
   mechanism for recursive resolvers to serve stale cached data when
   they are unable to refresh it from authoritative servers.  Optimistic
   DNS and RFC 8767 address different levels of the DNS resolution
   chain:

   _Optimistic DNS._  Operates at the stub resolver on the end-user's
      device.  Serves expired cached data proactively, while
      simultaneously initiating a network query.  The primary goal is
      delay reduction -- eliminating the TTL expiry spike.

   _RFC 8767._  Operates at the recursive resolver.  Serves stale data
      when upstream authoritative servers are unreachable.  The primary
      goal is resiliency -- maintaining DNS service during outages.

   The two mechanisms are complementary and can be deployed
   simultaneously.  When both are active, the resolution chain has two
   layers of staleness tolerance:

   1.  The stub resolver returns expired records optimistically,
       eliminating client-perceived delay.

   2.  If the recursive resolver's cache has also expired and the
       authoritative server is unreachable, the recursive resolver can
       serve its own stale data rather than returning SERVFAIL.

   Optimistic DNS delivers the data it has immediately, while also
   delivering updated data the moment it becomes available.  It gives
   the application the benefit of timely data, which could occasionally
   be wrong, without depriving the application of also receiving the
   exact data it would have received with a traditional non-optimistic
   DNS query, at the time it would have received it.

   In contrast, RFC 8767 serves stale data without any provision for a
   future asynchronous notification when the desired data becomes
   available.




Akiwate, et al.          Expires 5 December 2026               [Page 20]

Internet-Draft               Optimistic DNS                    June 2026


   Optimistic DNS is not applicable to recursive resolvers because
   Optimistic DNS relies on the ability to deliver its best available
   information immediately, and then asynchronously update that
   information promptly if newer information becomes available.  Stub
   resolvers that provide Asynchronous DNS resolution APIs to client
   applications are able to deliver these essential asynchronous
   updates.  Recursive resolvers do not currently have any good way to
   issue asynchronous updates to correct an earlier answer that is
   subsequently discovered to be wrong.  In principle, stub resolvers
   could use DNS Push Notifications [RFC8765] to receive asynchronous
   updates from a recursive resolver, but in practice this might place
   too much load on recursive resolvers.  The current recommended
   solution for recursive resolvers returning stale data is that the TTL
   is reported as being 30 seconds [RFC8767].  This has the effect of
   instructing stub resolvers to poll the recursive resolver once every
   30 seconds to ascertain if newer data has become available.

9.  Operational Considerations

   A consequence of Optimistic DNS is that clients may continue to use
   an old IP address longer than expected.  There are other reasons that
   stale addresses may persist and cause clients to use an old IP
   address longer than expected, but Optimistic DNS adds a new way that
   this can happen.

   Suppose a server operator has a DNS address record for
   website.example.com with a TTL of 24 hours, and the operator updates
   that address record to point to a new IP address.  Depending on when
   that address record was cached at various recursive resolvers around
   the world, the operator may expect to see a roughly linear decrease
   in new incoming connection requests to the old IP address in the 24
   hours after the address record was updated, ending with no new
   connection requests being received after 24 hours have passed.  In
   reality there are various reasons that some clients may still attempt
   to use a stale address, but in practice there should be very few
   incoming connection requests to the old IP address after 24 hours.
   The server operator has to keep the website available at the old
   address for at least 24 hours, to accommodate clients using the old
   address.

   Optimistic DNS changes this assumption.  Using the same 24-hour TTL,
   the decline in the incoming connection rate will not be quite as
   rapid, and incoming connection requests to the old IP address may
   continue to be received for a week after the TTL has expired
   (Section 7.4).






Akiwate, et al.          Expires 5 December 2026               [Page 21]

Internet-Draft               Optimistic DNS                    June 2026


   However, Optimistic DNS does not mean that the server operator is
   forced to maintain the availability of their website at the old IP
   address for a week after the address change.  Because clients using
   the expired IP address are using Optimistic DNS, they have the
   benefit of asynchronous DNS and Happy Eyeballs, which means that they
   will promptly switch to the new IP address, and the brief failed
   attempt to use the old IP address is inconsequential.

   If a new IP address is established for the server but existing
   connections to the old IP address continue to work, then there is no
   reason for clients to abandon their working connections.  The
   decision about if and when to migrate existing clients to the new IP
   address is in the hands of the server operator.  The server operator
   might choose to allow those connections to remain.  If the server
   operator wishes to have clients reconnect using the new IP address,
   then that could be achieved using an in-band message on the existing
   connection, or by simply shutting down the server at the old IP
   address, so that clients re-establish their connections using the new
   IP address.

   Moreover, Optimistic DNS gives server operators the freedom to use
   shorter DNS TTLs safely.  One of the reasons why server operators may
   choose to use long TTLs is to avoid their users experiencing the
   periodic delay spikes caused by short TTLs.  When Optimistic DNS
   eliminates the concerns about periodic delay spikes, it becomes
   reasonable to use shorter DNS TTLs.  With widespread use of
   Optimistic DNS, server operators are free to use much shorter DNS
   TTLs, like five minutes.  Optimistic DNS clients will suffer no
   periodic delay spikes because of the short DNS TTLs, and when the
   time comes that it is necessary to update the server address for
   website.example.com, the transition to the new server can be
   completed in minutes, rather than hours.

10.  Security Considerations

   Optimistic DNS introduces a tradeoff between speed and freshness.
   Applications that use expired answers must be prepared for those
   answers to be occasionally incorrect.  Applications using Optimistic
   DNS SHOULD employ application-layer security (e.g., using TLS or
   QUIC) when connecting to addresses obtained from expired answers, to
   detect cases where the address has been reassigned.

   Networking always entails a degree of uncertainty -- for example,
   packets may be intercepted in transit and not reach their intended
   destination -- and for correct operation, secure applications have to
   guard against this.  Optimistic DNS adds a new way that packets may
   not reach their intended destination, but does not fundamentally
   alter the importance of application-layer security.



Akiwate, et al.          Expires 5 December 2026               [Page 22]

Internet-Draft               Optimistic DNS                    June 2026


   _IP Address Reuse._  When a DNS record expires, the IP address it
      contained may no longer be associated with the previous host or
      service.  For HTTPS connections, TLS certificate validation will
      detect this mismatch and prevent data from being sent to the wrong
      party.  For unencrypted protocols, there is a risk of connecting
      to an unintended server.

   _Poisoning Amplification._  If an attacker successfully poisons a
      cache entry, Optimistic DNS could extend the lifetime of the
      poisoned record beyond its original TTL.  However, the record will
      be purged after the retention period expires.  Moreover, the
      parallel network query will obtain and deliver the correct answer,
      giving the application an opportunity to detect the discrepancy.

   _Expired Records Retention Period._  The recommended maximum
      retention period of one week (Section 7.4) bounds the maximum time
      an expired record can be served.  Implementations MAY allow this
      period to be configured.  Shorter periods reduce the window of
      exposure to stale data but also reduce the effectiveness of
      Optimistic DNS for infrequently-accessed names.

11.  IANA Considerations

   This document has no IANA actions.

12.  References

12.1.  Normative References

   [HEv3]     Pauly, T., Schinazi, D., Jaju, N., and K. Ishibashi,
              "Happy Eyeballs Version 3: Better Connectivity Using
              Concurrency", Work in Progress, Internet-Draft, draft-
              ietf-happy-happyeyeballs-v3-03, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-happy-
              happyeyeballs-v3-03>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/rfc/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.



Akiwate, et al.          Expires 5 December 2026               [Page 23]

Internet-Draft               Optimistic DNS                    June 2026


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

12.2.  Informative References

   [getdns]   NLnet Labs, Sinodun and No Mountain Software, "Welcome to
              getdns!", n.d., <https://getdnsapi.net/>.

   [IETF72]   Cheshire, S., "Stuart Cheshire on IPv6 Adoption", 2008,
              <https://www.stuartcheshire.org/IETF72/>.  This
              presentation introduced the concept of asynchronous
              concurrent connection racing, later known as Happy
              Eyeballs.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2131>.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2132>.

   [RFC3397]  Aboba, B. and S. Cheshire, "Dynamic Host Configuration
              Protocol (DHCP) Domain Search Option", RFC 3397,
              DOI 10.17487/RFC3397, November 2002,
              <https://www.rfc-editor.org/rfc/rfc3397>.

   [RFC3646]  Droms, R., Ed., "DNS Configuration options for Dynamic
              Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              DOI 10.17487/RFC3646, December 2003,
              <https://www.rfc-editor.org/rfc/rfc3646>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <https://www.rfc-editor.org/rfc/rfc6555>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/rfc/rfc6762>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/rfc/rfc7858>.






Akiwate, et al.          Expires 5 December 2026               [Page 24]

Internet-Draft               Optimistic DNS                    June 2026


   [RFC8106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 8106, DOI 10.17487/RFC8106, March 2017,
              <https://www.rfc-editor.org/rfc/rfc8106>.

   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              DOI 10.17487/RFC8305, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8305>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/rfc/rfc8484>.

   [RFC8765]  Pusateri, T. and S. Cheshire, "DNS Push Notifications",
              RFC 8765, DOI 10.17487/RFC8765, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8765>.

   [RFC8767]  Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
              to Improve DNS Resiliency", RFC 8767,
              DOI 10.17487/RFC8767, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8767>.

   [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
              Dedicated QUIC Connections", RFC 9250,
              DOI 10.17487/RFC9250, May 2022,
              <https://www.rfc-editor.org/rfc/rfc9250>.

   [ZC]       Cheshire, S. and D. H. Steinberg, "Zero Configuration
              Networking: The Definitive Guide", O'Reilly Media,
              ISBN 978-0-596-10100-5, December 2005.

Appendix A.  Deployment History

A.1.  Optimistic DNS in mDNSResponder

   The mDNSResponder project is an open-source system stub resolver, and
   runs on macOS, iOS, tvOS, watchOS, Microsoft Windows, Android, Linux,
   and other platforms.  This section describes its concrete
   implementation of the Optimistic DNS mechanism described in this
   document.

   Optimistic DNS in Apple’s mDNSResponder code was first shipped
   enabled by default in macOS 10.14 (Mojave) and iOS 12 in September
   2018.  It has been active on all Apple platforms since that release,
   serving as the default stub resolver behavior for all applications
   that use Apple’s recommended networking APIs.




Akiwate, et al.          Expires 5 December 2026               [Page 25]

Internet-Draft               Optimistic DNS                    June 2026


   Prior to implementing Optimistic DNS, the mDNSResponder code
   addressed the Zeno’s paradox problem (Section 4) by implementing a
   modest form of DNS TTL stretching.  The mDNSResponder code stretches
   TTLs by 25%, plus two seconds to account for minor clock variations.
   This results in the situation where, when the age of the record as
   viewed by the stub resolver reaches 80% of its stretched TTL, the
   actual TTL of the record as viewed by the recursive resolver has
   expired.

   If a client performs a new DNS query for a record within the time
   window of 80-100% of the stretched TTL, then the mDNSResponder stub
   resolver code will return the available answer to the client
   immediately, while in parallel sending a query to the recursive
   resolver.

   In addition, if an asynchronous query is active on the client at the
   time the record age passes 80% of its stretched TTL, then the
   mDNSResponder stub resolver code will send a DNS query to the
   recursive resolver to fetch fresh data, and will update the client
   with fresh information if new data is received.

   This DNS query to the recursive resolver happens after the recursive
   resolver’s copy of the record has expired, causing the recursive
   resolver to fetch a new fresh copy of the authoritative record, but
   because available answers are delivered to DNS clients immediately,
   DNS clients do not experience a delay spike while waiting for the
   recursive resolver to refresh the record.  Thus, traditional DNS
   queries using the mDNSResponder stub resolver may receive answers
   that are up to 25% beyond their original lifetime.

   The development of Happy Eyeballs in 2008 [IETF72] [RFC6555]
   [RFC8305] [HEv3] made it feasible to increase effective record
   lifetimes beyond a modest extension of just 25%, and this new
   capability is what made Optimistic DNS possible.

A.1.1.  Signaling

   This document describes query initiation as a local signaling matter
   between the application and the stub resolver.  The mDNSResponder
   code implements this through the following API flags:

   _kDNSServiceFlagsAllowExpiredAnswers._  Set by the application when
      issuing a query to request delivery of expired cached records.

   _kDNSServiceFlagsExpiredAnswer._  Set by the resolver on individual
      answer callbacks to indicate that the record being returned is
      expired.  In the case of Optimistic Negative Answers, the flag is
      a useful hint to the client about how much trust it should place



Akiwate, et al.          Expires 5 December 2026               [Page 26]

Internet-Draft               Optimistic DNS                    June 2026


      in this answer.  An expired Optimistic Negative Answer should be
      quickly updated with a fresh confirmation of the negative answer,
      or a new positive answer.  In the case of Optimistic Positive
      Answers, the flag has little significance, since the application
      verifies the validity of positive answers by attempting
      communication with those addresses.  Developers should take care
      in how they interpret this answer property because, as mentioned
      earlier, the notion of record expiry is subjective, and this flag
      is easily misunderstood and misused by developers who think it
      carries more significance than it really does.

   _kDNSServiceFlagsAnsweredFromCache._  Set by the resolver to indicate
      that the record was served from the local cache rather than from a
      network response.  Set regardless of whether the record is
      expired, allowing the application to distinguish cached answers
      (immediate) from network answers (delayed).  Providing an
      equivalent indication in other implementations is not recommended,
      because this flag is easily misunderstood and misused by
      developers who think it carries more significance than it really
      does.  If two clients happen to query for the same domain name at
      almost exactly the same time then one will be told that the answer
      came from the cache and the other will be told that it did not.
      Which client gets told which is effectively a coin toss, and
      usually has little significance.  Revealing whether an answer was
      served from the cache also has privacy implications.  A rogue
      application could issue queries for a large number of popular
      domain names, and from the replies indicating which domain names
      were already in the local cache and which were not, the rogue
      application could infer a list of which services this user has
      recently accessed.

A.1.2.  Record Lifecycle

   The main cache lookup operation requires that expired records remain
   in the cache so that they are available to serve optimistically.
   Conceptually, the stub resolver code saves all records for up to
   seven days.  Practically, the stub resolver code may want to limit
   its memory usage.  The mDNSResponder code approaches this with a
   three-state record lifecycle:

   _Mortal (default)._  The normal cache state for a record retrieved to










Akiwate, et al.          Expires 5 December 2026               [Page 27]

Internet-Draft               Optimistic DNS                    June 2026


      answer a traditional (not Optimistic DNS) query.  If subsequently
      queried by an Optimistic DNS operation, this record gets promoted
      to immortal.  Mortal records may be refreshed in the course of
      normal operation, though because of Zeno’s paradox (Section 4)
      such refreshes are likely to be successful only for records in the
      final 20% of their stretched TTL lifetime.  When the (stretched)
      TTL of a mortal record expires the record is eligible for
      immediate removal.

   _Immortal._  A record marked to survive past its (stretched) TTL
      expiry.  This is the initial cache state for a record retrieved to
      answer an Optimistic DNS query.  In addition, promotion from
      mortal to immortal occurs when a cached record is used to answer a
      query from an application that has opted in to Optimistic DNS.
      (The logic is that if an application has made an Optimistic DNS
      query for this DNS name, that is a hint that there may be more
      such Optimistic DNS queries in the future.  If there has not been
      even one single Optimistic DNS query for this DNS name, then that
      is a sign that whatever applications are resolving this DNS name
      do not yet use Optimistic DNS, so saving these records for a long
      time would be a waste of memory.)  Successful subsequent queries
      for immortal records will refresh their lifetime, as it is with
      mortal records.  When the (stretched) TTL of an immortal record
      expires the record becomes a ghost record.

   _Ghost._  An immortal record whose (stretched) TTL has expired.
      Ghost records linger in the cache, available to serve future
      Optimistic DNS queries.  If an Optimistic DNS query is issued that
      matches a ghost record, then the ghost record data is delivered
      immediately to the application, and the simultaneous DNS query
      over the network, if successful, will refresh the ghost record and
      restore it to immortal state.  If not refreshed for the ghost
      retention period (maximum of one week), ghost records are purged.

   The complete lifecycle:
















Akiwate, et al.          Expires 5 December 2026               [Page 28]

Internet-Draft               Optimistic DNS                    June 2026


          | Traditional      Optimistic DNS |
          | Query                     Query |   ----R----
          | for record           for record |  |         |
    -R-   | not in cache       not in cache |  |   -R-   |
   |   |  |                                 |  |  |   |  |
   |   V  V                                 V  V  V   |  |
   | +--------+  Optimistic DNS Query   +-----------+ |  |
   | | Mortal | ----------------------> | Immortal  | |  |
   | +--------+     during lifetime     +-----------+ |  |
   |   | |                                    |   |   |  |
    ---  |                                    |    ---   |
         | TTL expires            TTL expires |          |
         |                                    |          |
         |                                    |          |
         |                                    v          |
         V                               +---------+     |
      [purged] <-----------------------  |  Ghost  |-----
                      ghost retention    +---------+
                       period expires

   This creates a virtuous cycle: the more frequently a name is queried
   with Optimistic DNS, the more likely the cache will contain a ghost
   record for it the next time the TTL expires.

Acknowledgments

   TODO: Acknowledgments.

Authors' Addresses

   Gautam Akiwate
   Apple Inc.
   One Apple Park Way
   Cupertino, CA 95014
   United States of America
   Email: gakiwate@apple.com


   Phil Flack
   Apple Inc.
   One Apple Park Way
   Cupertino, CA 95014
   United States of America
   Email: pf-ietf@flacko.com







Akiwate, et al.          Expires 5 December 2026               [Page 29]

Internet-Draft               Optimistic DNS                    June 2026


   Stuart Cheshire
   Apple Inc.
   One Apple Park Way
   Cupertino, CA 95014
   United States of America
   Email: cheshire@apple.com













































Akiwate, et al.          Expires 5 December 2026               [Page 30]
