in man resolv.conf:
causes round robin selection of nameservers from among those listed. This
has the effect of spreading the query load among all listed servers, rather
than having all clients try the first listed server first every time.
You can enable it with ARES_OPT_ROTATE
The symptom:
* Users (usually, but not always) on 2-Wire routers and the Comcast service
and a wired connection to their router would find that the second and
subsequent DNS lookups from fresh processes using c-ares to resolve the same
address would cause the process to never see a reply (it keeps polling for
around 1m15s before giving up).
The repro:
* On such a machine (and yeah, it took us a lot of QA to find the systems
that reproduce such a specific problem!), do 'ahost www.secondlife.com',
then do it again. The first process's lookup will work, subsequent lookups
will time-out and fail.
The cause:
* init_id_key() was calling randomize_key() *before* it initialized
key->state, meaning that the randomness generated by randomize_key() is
immediately overwritten with deterministic values. (/dev/urandom was also
being read incorrectly in the c-ares version we were using, but this was
fixed in a later version.)
* This makes the stream of generated query-IDs from any new c-ares process
be an identical and predictable sequence of IDs.
* This makes the 2-Wire's default built-in DNS server detect these queries
as probable-duplicates and (erroneously) not respond at all.
not posix or anything and thus c-ares failed to build on hurd (and possibly
elsewhere). The define was also somewhat artificially used in the windows
port. Now, I instead rewrote the use of gethostbyname to enlarge the host
name buffer in case of need and totally avoid the use of the MAXHOSTNAMELEN
define. I thus also removed the defien from the namser.h file where it was
once added for the windows build.
I also fixed init_by_defaults() function to not leak memory in case if
error.
outstanding queries, and processing a DNS response packet was O(n) in the
number of outstanding queries. To speed things up in Google, we added a few circular,
doubly-linked lists of queries that are hash-bucketed based on
the attributes we care about, so most important operations are now O(1).
It might be that the number of buckets are higher than most people would need,
but on a quick calculation it should only be 100kB or so even on a 64-bit
system, so I've let it stay as-is.
something with the ares_save_options() where it would try to do a malloc(0)
when no options of that type needed to be saved. On most platforms, this was
fine because malloc(0) doesn't actually return NULL, but on AIX it does, so
ares_save_options would return ARES_ENOMEM.
Daniel Stenberg