Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
RE: [EXTERNAL] Re: HTTPS records
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 7 Dec 2022 21:46:52 +0000
> 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-bounces_at_lists.haxx.se> On Behalf Of Niall O'Reilly via curl-library
Sent: Wednesday, December 7, 2022 12:59 PM
To: Daniel Stenberg <daniel_at_haxx.se>
Cc: Niall O'Reilly <Niall.oReilly+lists_at_ucd.ie>; libcurl development <curl-library_at_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
Date: Wed, 7 Dec 2022 21:46:52 +0000
> 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-bounces_at_lists.haxx.se> On Behalf Of Niall O'Reilly via curl-library
Sent: Wednesday, December 7, 2022 12:59 PM
To: Daniel Stenberg <daniel_at_haxx.se>
Cc: Niall O'Reilly <Niall.oReilly+lists_at_ucd.ie>; libcurl development <curl-library_at_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.htmlReceived on 2022-12-07