ares_addr6ttl in order to prevent name space pollution, along with
necessary changes to code base and man pages.This change does not break
ABI, there is no need to recompile existing applications. But existing
applications using these structs with the old name will need source code
adjustments when recompiled using c-ares 1.6.1.
that is now used by the ares_parse_*_reply() functions instead of the
ares_expand_name() simply to easier return ARES_EBADRESP for the cases where
the name expansion fails as in responses that really isn't expected.
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.