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: 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: Thu, 8 Dec 2022 20:05:35 +0000
> Sure, just a little complicated.
> A primary reason the default name resolving in libcurl is still done with
> getaddrinfo() and not with a third party library like c-ares is that it is mighty hard to replicate its functionality. And getaddrinfo() does not return TTL.
> If we want to know the TTL for A and AAAA records while remaining 100% compatible with names used all over, we need to use getaddrinfo() *AND* do a separate lookup for the A and AAAA entries and use any
> possible TTL values we get back. Double the number of DNS requests. Not ideal.
It is kind of pity that we are tightly bound to limitations of getaddrinfo() and can't use features from libraries that provide TTL, like c-ares.
Correct me if I'm wrong, but both c-ares and getaddrinfo()-specific calls are placed inside async-ares.c and async-thread.c and
Curl_resolver_getaddrinfo() is the resulting function for each resolver backend.
So, I am wondering if it is possible to extend Curl_addrinfo (which Curl_resolver_getaddrinfo() returns) and add TTL information there, but only c-ares resolver backend will fill it?
This might allow to use TTLs for libcurl/c-ares combination, and for getaddrinfo() resolver backend the behavior will be like it is now.
Thanks,
Dmitry Karpov
Date: Thu, 8 Dec 2022 20:05:35 +0000
> Sure, just a little complicated.
> A primary reason the default name resolving in libcurl is still done with
> getaddrinfo() and not with a third party library like c-ares is that it is mighty hard to replicate its functionality. And getaddrinfo() does not return TTL.
> If we want to know the TTL for A and AAAA records while remaining 100% compatible with names used all over, we need to use getaddrinfo() *AND* do a separate lookup for the A and AAAA entries and use any
> possible TTL values we get back. Double the number of DNS requests. Not ideal.
It is kind of pity that we are tightly bound to limitations of getaddrinfo() and can't use features from libraries that provide TTL, like c-ares.
Correct me if I'm wrong, but both c-ares and getaddrinfo()-specific calls are placed inside async-ares.c and async-thread.c and
Curl_resolver_getaddrinfo() is the resulting function for each resolver backend.
So, I am wondering if it is possible to extend Curl_addrinfo (which Curl_resolver_getaddrinfo() returns) and add TTL information there, but only c-ares resolver backend will fill it?
This might allow to use TTLs for libcurl/c-ares combination, and for getaddrinfo() resolver backend the behavior will be like it is now.
Thanks,
Dmitry Karpov
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-12-08