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).
thanks for explaining that.
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.
i don't know any recursive nameservers that follow RFC 3483 for authority
server selection? (your example here was of authority nameservers.)
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?
nobody ever got fired for buying $whatever. so: great marketing trumps
any kind of engineering whether good or bad.
I suspect there is currently no better way to distribute initial
client requests than to play DNS tricks.
since the web protocols support both permanent and temporary redirects,
i've always preferred approaches like IBM's over approaches like akamai's.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf