Akamai doesn't use the usual round-robin. They do OTHER magic.
The OTHER magic Akamai uses can be replicated by using BIND 9's view functions on specific IP blocks for query sources. The problem is, you need to write a backend program that figures out the closest layer3 hops or AS hops and even combine it with latency if necessary, in which it will then update your named.conf's view function section. (Unless you have named.conf split over using include directives for 'views') For your secondary nearby DNS servers running BIND9, you should not slave the zones under view functions b/c view will only return the zone file that your secondary DNS server's IP matches for the query source. You'd need to use rsync or cvsup, then do a reload/restart on named.. Schedule it using crond or whatever.. What I have been told is that Akamai's nearby DNS' selection algorithm is partially based on number of AS hops from BGP path table. These are simply my thoughts+solutions that will give you the simple way to setup nearby DNS tricks/MAGICS, using sorted open source stuff that's all around the 'net.
The problem is that the backend doesn't know the source of the original query, they only know the IP address of the DNS server that's doing the recursion.
My thoughts here again, do not solve this problem. This is beyond the technical limit of the way DNS infrastructure works on internet.. :-( Perhaps someone could setup like a distributed load balancer that can tunnel the traffic from one place to the other, depending on source of the actual tcp/80 traffic to the web server... But then the SYN packet still has to go thru the load balancer and travel over the tunnel, not being so effective in terms of content delivery. -hc
-- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech