- 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, 28 insertions, 0 deletions

diff --git a/ares/CHANGES b/ares/CHANGES
index d23897216..dff8e8d67 100644
--- a/ares/CHANGES
+++ b/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