- 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, 2 insertions, 1 deletions

diff --git a/ares/RELEASE-NOTES b/ares/RELEASE-NOTES
index 752c4db41..eb9110dcf 100644
--- a/ares/RELEASE-NOTES
+++ b/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!