Even though I have selected a roundrobin DNS name for SYNC (rsync.europe.gentoo.org) emerge --sync always tries them in the same order. So if I happen to get a real slow server it does NOT help to restart emerge --sync to get a different one. I don't know what has changed. But this has worked in the past. Now it is broken. Reproducible: Always Steps to Reproduce: 1. emerge --sync 2. look at the server it picked 3. ctrl-c 4. emerge --sync Actual Results: it will pick the same server again and again Expected Results: it should pick a different server every time
the 'randomness' that comes from round robin dns comes from the layers below portage portage itself should not (and does not) care about the info given to it in other words you're gonna have to invesigate your system and see what has changed on it such that the order is given back the same everytime
Also, this is the expected behavior of DNS. When you issue a DNS query against a round robin A record, it returns all results. Your DNS client picks one and caches it based on the associated TTL of the record. It will continue to use that record until a point where the TTL expires.
Kurt, no a DNS client should be aware of round robin and issue a different IP on every request. You can check this with two consecutive pings. These two were performed on people.apache.org: -bash-2.05b$ ping rsync.europe.gentoo.org PING rsync.europe.gentoo.org (193.190.198.20): 56 data bytes -bash-2.05b$ ping rsync.europe.gentoo.org PING rsync.europe.gentoo.org (147.32.127.222): 56 data bytes These two were performed at our site: $ ping rsync.europe.gentoo.org PING rsync.europe.gentoo.org (195.86.128.57): 56 data bytes $ ping rsync.europe.gentoo.org PING rsync.europe.gentoo.org (195.86.128.57): 56 data bytes So it is a local DNS cache problem of our site DNS server.
i guess it depends on your definition of 'dns client' ... ping uses glibc for resolving names and (afaik) so does python
