I guess it always depends on the design of whatever is using c-ares. In
my own use cases, I have a single ares_channel running on an event loop
and enqueue my lookups to there ... so it keeps state. Nothing with
thread local storage or anything, just dispatching to that event loop
for any DNS queries that need to be performed. The single ares_channel
can handle multiple simultaneous DNS queries.
Also, since there is a proposed feedback loop, if a DNS server is no
longer reachable, it will re-sort the list for any future requests, so
it would only impact a single request (ok, well, whatever number of
requests came in before the timeout or error occurred).
Again, there's a reason happy eyeballs doesn't just hammer all endpoints
returned from getaddrinfo() simultaneously, I'd think the same reasoning
would go for DNS servers ... be kind ... start a second query after a
short delay if we haven't received a response yet (e.g. 200ms). It
doesn't make sense to hammer more than 1 DNS server if they're all
responsive, you just doubled the network load for DNS for no reason.
On 1/19/22 5:25 PM, Dmitry Karpov via c-ares wrote:
> 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.
OK, I got it know. :)
Pre-sorting name servers based on reachability from previous queries
or/and protocol family may help in some cases, but the sequential
approach, even with sorting, still will have some issues that the
parallel approach allows to solve more efficiently.
For example, the first query when nothing is sorted, may cause
critical connection timeouts aborting some applications, and storing
name server “reachability metrics” which name servers will be sorted
on will require either thread local storage (thus requiring each
thread to go through the same “name server discovery” procedure as the
other app threads using c-ares) or some global access to the metrics
data with proper read/write accesses, needed by multi-threaded apps.
Also, if run-time conditions change from the previous query then the
sorted list may be not sorted correctly for the current conditions,
and thus not the best server or even bad server may be tried first,
thus increasing name resolution time.
The parallel approach, on the other hand, will provide the fastest
name resolution regardless the previous queries, so it doesn’t need to
store any name server metrics and do pre-processing of the name server
list from OS.
But I agree that implementing parallel approach may be not very easy
and any improvements in this area will be a very welcomed extension,
anyway.
So, if you think that updated sequential approach with smart sorting
is much easier to implement than the parallel one, then hopefully we
can get it in next c-ares updates.
Thanks,
Dmitry Karpov
*From:* Brad House <b...@brad-house.com>
*Sent:* Wednesday, January 19, 2022 12:10 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)
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
--
c-ares mailing list
c-ares@lists.haxx.se
https://lists.haxx.se/listinfo/c-ares
