[DNSOP] Re: Fwd: New Version Notification for draft-gakiwa te-dnsop-optimistic-dns-00.txt

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]