Feature request for parallel queries for name servers from different protocol families (IPv4 vs IPv6)

Brad House brad at brad-house.com
Wed Jan 19 21:09:53 CET 2022

Commenting below ...

On 1/19/22 2:51 PM, Dmitry Karpov via c-ares wrote:
> > 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 assumed as part of this patch set, this timer would be reduced.

> > 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.

I wasn't suggesting this be outside of c-ares, I was talking about 
implementing this inside of c-ares as a simpler alternative to your 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.haxx.se/pipermail/c-ares/attachments/20220119/8b21c115/attachment.htm>

More information about the c-ares mailing list