On Jul 13, 2010, at 9:13 PM, Craig Spiers wrote:
I think it's pretty common for service providers
to be using DNS
trickery to get to the closer, faster, less cost caches..
This trickery could be called far worse names. I'll explain more below.
[mailto:email@example.com] On Behalf Of Lincoln Reid
Sent: Wednesday, 14 July 2010 1:08 p.m.
My question is, is there a method I can use to
influence which Akamai
cabinet serves up content to our networks and downstream networks?
You can ask us. But we have restrictions on what we can do.
If you e-mail NetSupport-tix(a)akamai.com, that will open a ticket with our Network Support
group. They will do what they can, but as I said, we do not have complete freedom on
where to serve what to whom.
If you e-mail them, please include the results of:
[Note the .com & .net are not interchangeable.]
We have free peering with most networks within New
We have paid peering circuits ( at something like $150 / mbps ) with two
larger NZ telco's.
And finally we have multiple paid transit services with other
international providers ( at something like $250 / mbps ).
Damned telcos! :)
The situation we have currently is that the default
Akamai instance we
get given when we make a request is over one of the most expensive
circuits for us and it is outside the country.
Akamai choses where to serve people based on latency, packet loss, and throughput. If the
latency over your transit provider is slightly lower than the latency over a
'free' path, we will still pick the transit provider - many times. We can
influence that decision if you ask us, assuming that 1) we are allowed to serve you over
the free path, and 2) the free path has acceptable performance characteristics.
Both of the larger NZ telco's have their own
Akamai cabinets, that with
( some slightly distasteful ) dns hackery we can use, and appear to work
well with lower latency and at a lower cost. Also one of the NZ ISP's
that we have free peering with ( Callplus ) have their own Akamai
instance that we can access at zero cost and has the best latency.
Ideally, we would like to use that one when ever possible.
I had a bunch of feedback from my original query from network folk that
were whacking in forwarders to other peoples DNS servers to use their
local caches to pick better ( either $ or ms ) circuits for them. I'm
sure that there will be side effects from this at times, but the trade
off is worth it for them.
Most Akamai nodes are limited to serve only the network in which they reside and its
customers. Think of it as peering on steroids. We give them servers, they give us
rackspace, and we agree to only serve their end users. This means we cannot simply map
you to the "closest" node if the network hosting that node does not want us to
You can get around this using "DNS trickery". But I caution you against this.
Let me explain more in-depth how the Akamai system works to explain why.
First, some terminology. Akamai's secret sauce is our Mapping System. When I say
"map you to", that means tell you which web server will serve you content. This
is done through DNS. You type "www.akamai.com" into your browser, your computer
goes to your recursive name server (aka RNS or sometimes caching NS). The RNS asks us for
an IP address for that hostname.
Notice at this point we have not seen the end user IP address. Moreover, even if we had,
the RNS will cache the response and had it to the next end user without asking us again.
As a result, we use the RNS IP address as a proxy for the end user IP address.
We look up the RNS IP address in our system and respond with an IP address of a web server
that is both 'close' and allowed to serve that IP address. The rest of the
transaction is standard, every day HTTP GET & the like. No redirects, no anycast, no
transparent proxying, nothing. If you used a sniffer on the line, you could not tell the
difference between an Akamai web server and the Apache server you probably installed
yourself last month.
Now, back to the on-net caches. The network with the on-net node gives us an ACL (usually
through a BGP session to one of our Quagga boxes) of which users are allowed to use that
node. Any request from an IP address outside that ACL will not be directed to the on-net
Unfortunately, one of the limitations of Akamai is that we do our mapping through DNS, as
I described above. This means if you use a recursive name server inside a network, your
request will get mapped to the on-net cache because you look to us like you came from
inside the network.
So when you configure your RNS to forward to another provider's RNS without their
permission, you are really circumventing the agreement we have with that provider. It is
the same as sending a packet to Provider 1 which is destined for Provider 2. Even if
Provider 1 & Provider 2 peer, it is still really bad Netiquette at best, and many
would call it far worse. (Including me.)
End result, if you want to be mapped somewhere other than where you are mapped today,
please e-mail us and ask. Please do not use other networks' resources by sending DNS
requests through a box you do not own or pay for.
If we can move you somewhere better and save you money, we will - as long as it does not
destroy performance. (Which I doubt any of you want anyway.) But we must abide by the
agreement we make with networks when we place caches inside those networks.
And, of course, if you know a network which has an Akamai node, you can always ask them to
add your AS / prefixes to the ACL. We have no problem serving you from any node that
gives us permission to serve you.
Finally, Akamai ships free kit to any network with enough traffic. Unfortunately, the
levels are significant, I believe it is 75 or 100 Mbps of Akamai traffic. (Hey, those
servers ain't cheap!) But the requirement may be lower in .nz because of the higher
cost down there. It wouldn't be 5 or 10 Mbps, but you can always ask and we'll
let you know.
Hopefully this answered many people's questions. If anything was unclear, please let