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