4 ms·

The problem is that Apple's CDN is being extremely naive about DNS — 8.8.8.8 is not "Google's DNS server" at a particular geolocation, but many servers distribu

by blasdel 16y ago

The problem is that Apple's CDN is being extremely naive about DNS — 8.8.8.8 is not "Google's DNS server" at a particular geolocation, but many servers distributed around the world, with different routes advertised to different destinations depending on the client network (anycast). Even without anycast the DNS server's geolocation is going to be way off for a lot of ISP defaults. Why look at a cached second-party side channel instead of the real routed packets from the client anyway? Anycast is the right mechanism for distributing this stuff — Apple's keying off of DNS is a bad idea, implemented poorly.

foobarbazetc 16y ago
Apple's CDN is Akamai, which is definitely not "naive". Google DNS is broken as a concept, and shouldn't have been released until they were anycasted in either all Google CDN POPs (where ever www.google.com is proxied from) or had talked the major CDNs (AKAM, LLNW, L3, etc) into supporting their proposed DNS extension (http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01 http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-...). As it stands, using Google DNS is optimizing exactly the wrong thing -- it may be "faster" than your local ISP (which I've actually never seen), but you're trading a couple of ms on an easily scaled distributed system (which every single ISP in the world provides) for a huge hit on network performance because you get a non-optimal CDN pop. I'd even go as far as saying that Google DNS is ruining the network experience for anyone outside the US (and from Gruber's article, apparently in the US too) -- the very problem people pay CDNs to solve in the first place.
- willscott 16y ago
  Couldn't the CDN redirect to a closer node if DNS doesn't bring the user to an optimal pop? I'm pretty sure we're talking about an HTTP protocol so a 302 redirect ought to work, and it seems like that would give the CDN way more control than trying to distribute traffic using a cached and not reliably localized DNS mechanism. Edit: foobarbazetc has a good point, but it still feels like the CDN has reasonable ways to work around and do a better job of selecting the correct pop than DNS. Adding a layer of subdomains which force locality (us-ny.host.com) would keep urls readable & virtual hosts intact.
  - foobarbazetc 16y ago
    Unfortunately not, because your redirect would have to use an IP address instead of the hostname, so your browser address bar would look like: http://1.2.3.4/ http://1.2.3.4/ Which would send the wrong 'Host' header to the server, and won't serve the right site and/or content through the CDN. :)
    - trotsky 16y ago
      apple tv
- jws 16y ago
  For my midwestern U-verse vendor supplied DNS server, it is trading annoying timeouts from unanswered queries for a reliable DNS response. But the article makes a good point, and since I have a bind running on my firewall anyway, I'll just take the forwarders out.
- trotsky 16y ago
  Are you sure Apple is using akamai for video? They have a substantial contract with Limelight and have long been rumored to be bringing traffic in house that had been previously served by CDN. With a long term connection that can withstand a little extra in setup time and a custom built client (both things fit apple tv) it's unnecessary to rely on geo dns anyway.
evgen 16y ago
This is how most global load balancing works, and even Google uses systems like this for deciding the closest data center to serve content from (which is why they have submitted an internet draft that would add a few octets from the source ip to forwarded dns requests as a solution to this problem.) If you are using a chatty protocol then you can take an early guess as to the closest server based on the dns lookup and then redirect/refine the path once you are actually talking to the endpoint, but in some cases you would take more time re-establishing the connection than you would servicing it from the "wrong" data center so you just grit your teeth and try to either be smarter next time or add the dns server to the "we have no idea where the endpoint is" list. In theory anycast delivery is the right solution, but there is a wide gulf between theory and practicality here. There is a reason that no one uses anycast for anything other than dns at the moment...

by blasdel 16y ago

foobarbazetc 16y ago

Apple's CDN is Akamai, which is definitely not "naive". Google DNS is broken as a concept, and shouldn't have been released until they were anycasted in either all Google CDN POPs (where ever www.google.com is proxied from) or had talked the major CDNs (AKAM, LLNW, L3, etc) into supporting their proposed DNS extension (http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01 http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-...). As it stands, using Google DNS is optimizing exactly the wrong thing -- it may be "faster" than your local ISP (which I've actually never seen), but you're trading a couple of ms on an easily scaled distributed system (which every single ISP in the world provides) for a huge hit on network performance because you get a non-optimal CDN pop. I'd even go as far as saying that Google DNS is ruining the network experience for anyone outside the US (and from Gruber's article, apparently in the US too) -- the very problem people pay CDNs to solve in the first place.

willscott 16y ago
Couldn't the CDN redirect to a closer node if DNS doesn't bring the user to an optimal pop? I'm pretty sure we're talking about an HTTP protocol so a 302 redirect ought to work, and it seems like that would give the CDN way more control than trying to distribute traffic using a cached and not reliably localized DNS mechanism. Edit: foobarbazetc has a good point, but it still feels like the CDN has reasonable ways to work around and do a better job of selecting the correct pop than DNS. Adding a layer of subdomains which force locality (us-ny.host.com) would keep urls readable & virtual hosts intact.
- foobarbazetc 16y ago
  Unfortunately not, because your redirect would have to use an IP address instead of the hostname, so your browser address bar would look like: http://1.2.3.4/ http://1.2.3.4/ Which would send the wrong 'Host' header to the server, and won't serve the right site and/or content through the CDN. :)
  - trotsky 16y ago
    apple tv
jws 16y ago
For my midwestern U-verse vendor supplied DNS server, it is trading annoying timeouts from unanswered queries for a reliable DNS response. But the article makes a good point, and since I have a bind running on my firewall anyway, I'll just take the forwarders out.
trotsky 16y ago
Are you sure Apple is using akamai for video? They have a substantial contract with Limelight and have long been rumored to be bringing traffic in house that had been previously served by CDN. With a long term connection that can withstand a little extra in setup time and a custom built client (both things fit apple tv) it's unnecessary to rely on geo dns anyway.

evgen 16y ago

This is how most global load balancing works, and even Google uses systems like this for deciding the closest data center to serve content from (which is why they have submitted an internet draft that would add a few octets from the source ip to forwarded dns requests as a solution to this problem.) If you are using a chatty protocol then you can take an early guess as to the closest server based on the dns lookup and then redirect/refine the path once you are actually talking to the endpoint, but in some cases you would take more time re-establishing the connection than you would servicing it from the "wrong" data center so you just grit your teeth and try to either be smarter next time or add the dns server to the "we have no idea where the endpoint is" list. In theory anycast delivery is the right solution, but there is a wide gulf between theory and practicality here. There is a reason that no one uses anycast for anything other than dns at the moment...