Many DNS "load balancing" solutions will return the address of the web
server closest to the _query source_. This means these systems work best
when your recursive DNS servers are topologically closest to your users.
Correct me if I am wrong.. But..
I don't think multiple 'A' record load balancing will return the IP
address of the web server that is closest to the _query_source_. If this
is true, then Akamai has reinvented the wheel with their near-by DNS
setup on *.g.akamai.net entries.
The NS entry 'name server' record that is closest to the _query_source_
may answer the DNS query.. I.e... such as f.root-servers.net serving many
pacific traffic as well as western US in majority.
Akamai doesn't use the usual round-robin. They do OTHER magic.
Some solutions use a special magic DNS backend that will launch a PING or
other RTT detector from the multiple service locations, and then return the
location with the lowest RTT. Of course, this means you're measuring the RTT
from the servers to the user's DNS server - if they're using a DNS server
that's a long way away network-wise, this can produce odd results.
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.
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.
