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

[Petr Menšík]

I think it is generic hostname resolution at its core. I think there 
should be API generic enough to use it for DNS or mDNS, maybe even LLMNR 
protocol is anyone still needed that.

The problem I saw at dnsmasq upstream discussion were attempts to block 
AAAA queries. Because they were no IPv4 only network and the AAAA query 
were not really necessary. I have created bug #30554 [1] for that issue.

But it is created by getaddrinfo() call with AF_UNSPEC set in hints. 
There, it creates two separate queries. The problem I saw on dnsmasq 
side is I do not receive the information, whether user originally asked 
for all address families, or just specific address family. The 
information that AF_UNSPEC were used is lost as soon as nss_dns plugin 
is used and DNS packet leaves. Using multiq would be a way to keep that 
information even inside the DNS packet. Dnsmasq might be able to respond 
only with A address on A+AAAA query. But it does not need to lie to 
direct AAAA query that it has no answer. Because it can get more context 
for a decision. Would make getent ahosts example.com and getent ahostsv6 
example.com possible to be different.

This proposal would help already with A+AAAA query done when AF_UNSPEC 
is used in getaddrinfo(). Adding extra HTTPS query for the record would 
require additional query and waiting for that. Ideally made from single 
call, which would not be specific to (unicast) DNS.

More below.

On 08/11/2024 10:19, Florian Weimer wrote:
> 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.

There is even RFC 8305: Happy Eyeballs v2  [2], which specifies that 
connection should be started as soon as the first response from DNS 
arrives. That is not possible to implement with current getaddrinfo(3) 
call, which blocks until both responses arrive. But use of multiq may 
create just a single response, containing both answers. If that were the 
case, we avoid a need to synchronize and wait for two separate answers. 
Because all answers can arrive from the cache in a single response.

Sure, the application still needs to create separate AF connections. We 
do have BSD socket API to process multiple connections even from a 
single thread. Unfortunately we do not have API for resolving two names 
at the same time, which is a pity. Created bug #32346 for it [3]. But 
connection management should still be done by the application (or its 
library).

> 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

This does not affect only libcurl. It affects also wget, python HTTP 
libraries, Golang HTTP libraries, etc. Majority of internet traffic uses 
HTTP protocol in some form. I think there should be a relatively simple 
API provided to such applications, obtaining additional key=value 
details from HTTPS record. Something like struct addrinfo, but with 
extra key=value array. Providing alpn, ech, ttl, priority or server name 
values in addition to socket address. It could allow also simpler usage 
of SRV records, which have additional weight, priority and server 
name(s) attributes.

Glibc now offers only res_nquery API from libresolv. But that is not 
protocol independent, they are DNS protocol specific. I have seen 
attempts from Apple devices to query HTTPS record even via mDNS 
protocol. I do not think end applications should implement all possible 
protocols at their side. Quite similar to getaddrinfo(3), there should 
be abstraction for it. That is why I am here with these questions.

Best Regards,
Petr

1. https://sourceware.org/bugzilla/show_bug.cgi?id=30544
2. https://datatracker.ietf.org/doc/html/rfc8305.html#section-6
3. https://sourceware.org/bugzilla/show_bug.cgi?id=32346

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB.asc
Type: application/pgp-keys
Size: 9736 bytes
Desc: OpenPGP public key
URL: <https://sourceware.org/pipermail/libc-help/attachments/20241108/fc4d8681/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-help/attachments/20241108/fc4d8681/attachment-0001.sig>