On Mon, 5 Dec 2022, Niall O'Reilly wrote:
I think there are two key design decisions to be made for libcurl in order
to go "beyond getaddrinfo()". These are not entirely independent of each
other.
The first of these is whether to develop new functionality in c-ares or
rather to use instead a modern library, developed by DNS specialists, as the
"DNS engine" for libcurl. Ones that come to my mind are [connectbyname][]
and [getdns][]).
I'm open for curl supporting another library than c-ares, but everyone needs
to be aware that c-ares has been supported in curl for almost twenty years by
now and works pretty flawlessly. It will take time and effort to reach that
level of maturity with a new library. Whichever it is.
If we're talking "only" adding support for HTTPS and SVCB records, then it
might make sense to stick to c-ares since maybe using getdns only for those
two extra records might be a bit overkill. Especially for users who are
already using c-ares it might feel awkward to have to link with two different
DNS libraries.
But we also discuss DNSSEC/DANE support from time to time and if we would
start working with a library that has proper native support for that, we could
be getting closer to ever supporting such features.
("connectbyname" sounds like a library that libcurl cannot use, and I'm sorry
to say, their documentation is crap so I couldn't really tell for sure.)
The second is how to extend libcurl's DNS cache so as to represent the
additional DNS data which will be available. IIUC, the current cache maps a
key tuple (hostname, port) to an address-information object (or list of such
objects). SVCB and compatible DNS records, such as HTTPS, are keyed on
(hostname, scheme, port), so it seems that not just the target information
object of the map, but also the key, will need to be extended.
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.
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.
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
