- 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.

ares/CHANGES

@@ -1,5 +1,33 @@
   Changelog for the c-ares project
 
+* Aug 4 2008 (Daniel Stenberg)
+- 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.
+
+
 * Aug 4 2008 (Yang Tse)
 - Autoconf 2.62 has changed the behaviour of the AC_AIX macro which we use.
   Prior versions of autoconf defined _ALL_SOURCE if _AIX was defined. 2.62

ares/RELEASE-NOTES

@@ -8,10 +8,11 @@ This is what's new and changed in the c-ares 1.5.3 release:
  o configure process no longer needs nor checks size of curl_off_t
  o library will now be built with _REENTRANT symbol defined if needed
  o Improved configure detection of number of arguments for getservbyport_r
+ o Improved query-ID randomness
 
 Thanks go to these friendly people for their efforts and contributions:
 
- Brad House, Yang Tse, Phil Blundell
+ Brad House, Yang Tse, Phil Blundell, Tofu Linden
  and obviously Daniel Stenberg
 
 Have fun!

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;