- Fix by Tofu Linden:

  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.

1 files changed, 1 insertions, 1 deletions

diff --git a/ares/ares_init.c b/ares/ares_init.c
index e33c3973a..20a23a340 100644
--- a/ares/ares_init.c
+++ b/ares/ares_init.c
@@ -1464,11 +1464,11 @@ static int init_id_key(rc4_key* key,int key_data_len)
   if (!key_data_ptr)
     return ARES_ENOMEM;
 
-  randomize_key(key->state,key_data_len);
   state = &key->state[0];
   for(counter = 0; counter < 256; counter++)
     /* unnecessary AND but it keeps some compilers happier */
     state[counter] = (unsigned char)(counter & 0xff);
+  randomize_key(key->state,key_data_len);
   key->x = 0;
   key->y = 0;
   index1 = 0;