> Since libcurl's DNS cache is downstream of some full-function resolver cache, 
> using 60 seconds as default is probably not harmful. On the other hand, using 
> the exact cache seems somehow more correct.

Exactly! Honoring exact TTLs will be a very good feature.
I heard complaints from some backend services who manipulated DNS records for 
load balancing and used 20s TTL that libcurl didn't honor it and it created 
performance issues.
So, it will be definitely a good addition to the library.

> I've thought a little about what should be the TTL that libcurl's cache uses 
> when it contains data drawn from multiple RRsets (even if just A and AAAA).
> I think the safe think to do is to use the minimum value across all retrieved 
> RRsets, so that each set of related data in cache has a consistent lifetime.

Sounds reasonable, I think.

Thanks,
Dmitry Karpov

-----Original Message-----
From: curl-library <curl-library-boun...@lists.haxx.se> On Behalf Of Niall 
O'Reilly via curl-library
Sent: Wednesday, December 7, 2022 12:59 PM
To: Daniel Stenberg <dan...@haxx.se>
Cc: Niall O'Reilly <niall.oreilly+li...@ucd.ie>; libcurl development 
<curl-library@lists.haxx.se>
Subject: [EXTERNAL] Re: HTTPS records

On 6 Dec 2022, at 7:33, Daniel Stenberg wrote:

> I think we could just extend the current logic and add the scheme to 
> the mix. It's not like many users are going to first use one scheme 
> and then switch to another to the same host name and port number 
> (within the DNS cache timeout period) and get upset if we don't cache 
> the address for that.

If I get time before someone else does, that looks like a place for me to start.

> Another thing that we might want to ponder is TTL for DNS cache 
> entries, as currently we have a 60 second default but when we talk to 
> the DNS "properly" we actually get the exact TTL for entries and could 
> then potentially have a different TTL for some of the data for a 
> cached entry.

Since libcurl's DNS cache is downstream of some full-function resolver cache, 
using 60 seconds as default is probably not harmful. On the other hand, using 
the exact cache seems somehow more correct.

I've thought a little about what should be the TTL that libcurl's cache uses 
when it contains data drawn from multiple RRsets (even if just A and AAAA).
I think the safe think to do is to use the minimum value across all retrieved 
RRsets, so that each set of related data in cache has a consistent lifetime.

€0,02
Niall
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Reply via email to