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.
(ares_init.c/get_iphlpapi_dns_info() function): when I disable the network
by hand or disconnect the network cable in Windows 2000 or Windows XP, my
application gets 127.0.0.1 as the only name server. The problem comes from
'GetNetworkParams' function, that returns the empty string "" as the only
name server in that case. Moreover, the Windows implementation of
inet_addr() returns INADDR_LOOPBACK instead of INADDR_NONE.
