DNS resolver: multi-qtypes in glibc and HTTPS RR support

[Florian Weimer]

* Petr Menšík via Libc-help:

> But adding just additional parallel query might not be as effective as
> desired. Because all of those queries would be sent on the same name,
> it might be possible to use proposed draft [1]. Problem with using it
> is common application does not keep any state between subsequent
> resolutions. (With exceptions of /etc/resolv.conf parsed
> context?). Therefore it is unable to keep autodetected state, without
> which it cannot be used.

Is this really a DNS API issue at its core?

I think what our users expect is that if there is an endpoint associated
with a name that can be connected to within a few dozen milliseconds, we
use that endpoint.  Even if there are other endpoints that are much
further away or time out.  (I think this is sometimes referred to as
“happy eyeballs”.)  Just looking at DNS won't get us there.
Applications need to initiate TCP (or QUIC?) handshakes to multiple
addresses in parallel, and need to be able to obtain reachability
information from some form of persistant cache.

I expect that without that, merely making more choices available to
applications will not make much of a difference, or even lead to worse
performance because there are additional bad options to choose from.

A potential way forward would be to discuss this with the libcurl
developers and ask them if they need anything from glibc.  I'm assuming
that libcurl, not applications, would determine which endpoints to
connect to.

Thanks,
Florian