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]>, "Phil Flack"
<[email protected]>, "Stuart Cheshire" <[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 [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
