* Paul Vixie: >> > some number of vendors have depended on revenue from selling this >> > feature but i'd say that only a small number of sites ever saw any >> > benefit from it. >> >> pool.ntp.org, security.debian.org, rsync.gentoo.org, >> [a-o].ns.spamhaus.org, [a-n].surbl.org. In general the "large RRset" >> approach is used by those who do not buy special DNS appliance to serve >> their zones, I think. > > i'm not sure we're in the same discussion. pool.ntp.org is using short > ttl and silent truncation and round robin. there's no geo-ip stability > that could be hurt by client-side reordering or rerandomizing. The NTP issue is rather specific and affected ntpd when you had server pool.ntp.org server pool.ntp.org server pool.ntp.org in your configuration. And some those mirrors I mentioned are affected by *deterministic* reordering. They don't care if traffic hits the closest instance, they want to spread the load (security.debian.org, for instance, is difficult to serve from a single node from time to time). > and the nameserver examples you gave are all subject to rdns RTT > sorting. If you follow Rule 9, you haven't got that many RTTs to sort by: Rule 10 ensures that there is a single IP address you should use as long as the service on it is reachable. Unless you cheat, deviate from Rule 9, contact additional servers, and gather additional RTTs--but you have to cheat to get that data. > and they have to use drastically low TTL's to prevent mobility from > breaking their assumptions. and they have no way to cope with opendns or > any other global or semi-coherent caching layer. and even when they use > TTL=0 and happen to be talking to an rdns who shares topology with the > stub, they're making an educated guess without knowing what kinds of > wormholes the stub may have access to, whether VPN, private interconnects > that don't show up in global BGP, or whatever. Well, if it's not a good idea, why are most large web sites served this way? I suspect there is currently no better way to distribute initial client requests than to play DNS tricks. -- Florian Weimer <fweimer@xxxxxx> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf