Hi Brad, Thanks for reply. A few comments.
> Infact, happyeyeballs itself doesn't always do parallel connection attempts, > its an implementation-defined delay before also attempting the next address > in the list. In case of Happy Eyeballs, a delay between IPv4 and IPv6 connections is constant and typically relatively short – 200-300ms. But non-functional IPv6 name servers in the server list may create dynamic delays in connection establishment which can be very large. By default, c-ares uses 5s timeout per name server, so it may take 5s and more (if several IPv6 name servers are in the list) to get to the connection Happy Eyeballs thus taking much more than expected 200-300ms. > 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). Yes, of course, it is possible that c-ares client can implement some kind of name server sorting/filtering logic outside of c-ares and just pass a list of “good” name servers to c-ares, but in this case it has to be more involved into the name resolution business than it would be desired. A cross-platform client will have to implement a multi-platform logic to get a list of name servers like c-ares, thus potentially duplicating the code doing the same thing, and then also implement a mechanism of checking and filtering out bad servers to create a list of good servers to feed it to c-ares or some c-ares client application. In my opinion, this is too much complexity to ask from a resolver client, which only desires to get host name resolutions from the resolver relying on the resolver to do it using the best and the fastest way. Using parallel DNS requests for IPv4 and IPv6 stacks in c-ares will help to avoid complicated workarounds in all clients trying to resolve dual-stack issues, and option to use parallel requests for all servers in the list will help to address a general problem of bad name servers going before good ones. I think these issues are quite common, so I thought that it would be a good c-ares extension to provide an option to deal more easily with bad name servers for its clients using parallel approach. Thanks, Dmitry Karpov From: Brad House <b...@brad-house.com> Sent: Tuesday, January 18, 2022 2:56 PM To: c-ares discussions <c-ares@lists.haxx.se> Cc: Dmitry Karpov <dkar...@roku.com> Subject: Re: Feature request for parallel queries for name servers from different protocol families (IPv4 vs IPv6) 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: 1. Split the flat name server list for both stacks into two lists for each stack. 2. Execute parallel DNS queries for each stack list, iterating each stack list sequentially as it is currently done for the whole dual-stack list. 3. Return the result whichever comes first. This feature request can be also considered in a broader scope: 1. Run parallel queries for each name server in the dual-stack list regardless of whether it is IPv4 or IPv6 address. 2. 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
