We would certainly take patches to accomplish something like this. I'm
not sure how easy it would be to work the internals of c-ares to
understand parallel nameservers for the same query, it would probably be
a substantial change though.
Also, I'm also not sure how "friendly" it is to actually perform the
requests in parallel at all times.
Infact, happyeyeballs itself doesn't always do parallel connection
attempts, its an implementation-defined delay before also attempting the
next address in the list. It also has you maintain a feedback loop in
order to sort known bad addresses to be least prefered. It would be
much easier to stay closer to happy eyeballs and just sort the dns
server list using prior result success/fail (even upfront sorting using
some algorithm to interleave ipv6/ipv4 in a pattern would help, maybe
with using logic such as from RFC6724 sec 2.1 like we do in
ares_getaddrinfo for returned addresses, but instead of the nameservers
themselves).
Obviously, if you're using something that isn't maintaining state, the
feedback loop won't help, but maybe the pre-sorting suggestion would.
Assuming you're using libcurl, and not a stateless command line curl, I
think it would ultimately accomplish your goal.
-Brad
On 1/18/22 4:23 PM, Dmitry Karpov via c-ares wrote:
Hello,
Using libcurl with c-ares for dual-stack scenarios, I observed that
c-ares doesn’t distinguish between IPv4 and IPv6 nameservers in the
name server list (i.e. listed in resolv.conf on Linux systems) and
iterates through them sequentially.
Such approach creates problems for dual-stack systems, when one stack
is either not fully functional or have not responding/reachable name
servers put on top of the list.
In such scenarios, problems with one stack (i.e. IPv6) may create name
resolution delays and timeouts for the other fully functional stack
(i.e. IPv4) if name servers from the not functioning stack go before
the good stack like:
[IPv6 - BAD]
2001:4860:4860::8888
2001:4860:4860::8844
[IPv4 - GOOD]
8.8.8.8
8.8.4.4
In this scenario, it will take two resolution timeouts for bad IPv6
name servers before good IPv4 name servers are reached, and this
negatively impacts Happy Eyeball implementations in client
applications (i.e. libcurl) which have to wait for too long before
they can start dual-stack connections.
So here is the feature request which should help dual-stack client
applications to work more efficiently when name servers from not
functioning stack are listed before name servers from a good stack:
* Split the flat name server list for both stacks into two lists for
each stack.
* Execute parallel DNS queries for each stack list, iterating each
stack list sequentially as it is currently done for the whole
dual-stack list.
* Return the result whichever comes first.
This feature request can be also considered in a broader scope:
* Run parallel queries for each name server in the dual-stack list
regardless of whether it is IPv4 or IPv6 address.
* Return the result whichever comes first.
Such broader scope will also allow to skip over bad name servers and
get host resolution results much more quickly even for the same stack
(i.e. when name server list for a single stack contains some not
responding name servers at the top).
But in this case, it should be probably controlled by some new c-ares
option, so the current sequential approach may be enforced if needed.
Thanks,
Dmitry Karpov
--
c-ares mailing list
c-ares@lists.haxx.se
https://lists.haxx.se/listinfo/c-ares
