Maintained by: NLnet Labs

[Unbound-users] [PATCH] Round-robin doesn't work with some Windows clients

W.C.A. Wijngaards
Wed May 15 13:59:00 CEST 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ilya,

On 05/15/2013 01:31 PM, Ilya Bakulin wrote:
> Hi, We have found a problem in Unbound Round-Robin algorithm. One
> of our clients has a DNS record with two IP addresses. When Windows
> clients try to resolve DNS name, they receive these two IPs always
> in the same order. OpenBSD clients have no problem (= the order 
> changes). tcpdump shows that Windows sends incrementing query ID,
> and OpenBSD uses random ID for each query. Unbound uses the
> following construct to generate "random" number to reorder RRs in
> the answer: util/data/msgencode.c: rr_offset =
> RRSET_ROUNDROBIN?id:0;
> 
> The problem here is that "id" is read from wire without converting
> it to Host byte order. So that only high bits of ID change. When
> there are only two RRs in the reply, this code in msgencode.c will
> always generate the same sequence: j = (i + rr_offset) %
> data->count;
> 
> The problem can be easily solved by converting query ID to Host
> byte order:
> 
> /* roundrobin offset. using query id for random number */ 
> -rr_offset = RRSET_ROUNDROBIN?id:0; +rr_offset = RRSET_ROUNDROBIN ?
> ntohs(id) : 0;
> 
> We have tested this with incrementing query IDs and it works fine.

Thank you for this patch, I have committed it to the source code.

Best regards,
   Wouter

> However it may be better to change the way "id" is read from wire
> (reading + converting to Host byte order, and converting back when
> writing back to wire).
> 
> -- Ilya
> 
> 
> 
> _______________________________________________ Unbound-users
> mailing list Unbound-users at unbound.net 
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRk3iEAAoJEJ9vHC1+BF+NXeEP/jA6IZyy9NkeNCHDzo+0L77n
hIV+jxh0EhOeM4AIw9TYv/v+hQGc/AMN1ra3w8JFuBXjLWRw7eIArg5dQnYot6Zv
8JcLFBt/igj48MUk2Shtwg+m279WugbPltVpnnJGyXQaeOJ3sw6FHXAfvZiRsnXE
SehY0ra8voyKhA3NaMkbyv0OOCjJk8ATPZzncPg4XgA8ViJVgPDrYPY9jYDYCUQU
CmJ/X1ErBdzKZ4C6L1iU3c/niaQedM4a9ElWj8G4ECfnC2xVoN7tXHYIjeV0J6lg
UPfV0wTTxL8U+7N43mYm3DopW8XyjHNaM0bA5am63l36/9G93H+FTYJF51Oo2pdT
RQy8i353ptcvPJhkuddPI9dIx2qHeBVSJYGCvs2vDQ8DC1PHNw5G1EoHpBcqLM27
7QayZGbdEo+Iwapn85ppm9aVgWW7fDR33oJ6M2RBuuzEzXfTvler2eHiRb9j6cvz
H0CQADtVe4XYGKyWmvnisumm1LeyIvJe/1Vw49eFtKHvxEtAuacejdlk7B3NhuFT
6CxFP+kDVAGHjQswwOcPpTUjvDJp6pBIPP42TM6wOxgQ/m90JH8OmbzXWy8D+Huc
pw4KJRxhVA2atZcPcNdxzY+J8a2kUOjDVlyanWyQdk6xvGHmJk46t76oNDhgyspk
H4ZxDZ5+0MHUJ9sdvIm8
=kqYh
-----END PGP SIGNATURE-----