Slashdot Mirror
How CDNs and Alternative DNS Services Combine For Higher Latency
The_PHP_Jedi writes "Alternative DNS services, such as OpenDNS and Google Public DNS, are used to bypass the sluggishness often associated with local ISP DNS servers. However, as more websites, particularly smaller ones, use content distribution networks via embedded ads, widgets, and other assets, the effectiveness of non-ISP DNS servers may be undermined. Why? Because CDNs rely on the location of a user's DNS server to determine the closest server with the hosted content. Sajal Kayan published a series of test results which demonstrates the difference, and also provided the Python script used so you can test which is the most effective DNS service for your own Internet connection."
Why drag us lovely CDN's in to this.
Maybe I'm missing something here, but shouldn't be the application's responsibility to provide a geographically correct host name to the client, not the responsibility of DNS? It seems like poor application design to rely on DNS for this. Your app should determine the host based on the IP of the client, not give the client an arbitrary host name and then rely on DNS to provide your geologically correct server.
Automatically routes your DNS request to a Google server close to you. So there's no problem here.
It isn't just ads. For example, Microsoft, Apple, Symantec, and Red Hat use CDNs for distributing software updates (that's just a few companies I know of off the top of my head). Basically, CDNs keep the Internet working, saving server load at the source and bandwidth across the Internet and at the providers.
While some shoddy CDN companies may reroute you at the DNS level, many are actually smarter about it. Smart systems will redirect you to a 'closer' system via a different URL for media files, or utilize anycast BGP routing so that you always take the shortest path to one of their nodes.
As for 'who serves stuff on CDNs that I want to see anyway' -- everyone. From porn sites to Google to Youtube, they're all one type or another of CDN.
Just because you disagree doesn't make it offtopic or flamebait.
Seven or so years ago, before I retired from one of the large cable companies, CDNs were hosting the relatively static parts for a surprisingly large number of broadly popular sites. I had an opportunity to see the list when we were approached by the then-largest CDN, who wanted to place servers in many of our head-end locations for the obvious performance benefit. I was the one who pointed out that all of our internal DNS requests were routed to one of two data centers, one on the East Coast and one on the West, creating exactly the situation described in the OP: the CDN would have no idea where the original request came from, so would be unable to direct the end user to the appropriate server.
I was one of the few engineers who argued for less centralization in our network. I wanted broader distribution for reliability purposes: at that time, the massive centralized mail servers had a tendency to fail at the drop of a hat. But it would also have given us the ability to work with companies like the CDNs in order to provide better service.
This is exactly the problem. Most people have probably not heard about a little company called Akamai, but chances are if you're downloading content from a large site, you're using Akamai's content delivery network. Go view a trailer on Apple's site for instance and you'll see the host is actually served off edgesuite.net (which is Akamai). They use a distributed system of caching mirror servers to serve up content to a server closest to you geographically.
The one reason I use an open DNS server instead of my cable provider's (Cox Cable) servers is because they have an Akamai server for Cox and it was horribly overloaded. I was getting 512 Kbps anytime I was trying to download something from Apple. I switched my DNS to a combination of Level3's and Cisco's open DNS servers and I started hitting another Akamai server outside Cox and started getting 15 Mbps. It was night and day going from barely being able to watch a standard definition movie trailer on Apple's site while it buffered buffered, played, buffered, play buffered, etc. to being able to watch a 1080p HDTV stream with the buffer way ahead of my realtime viewing.
As opposed to using the client IP address?
Palm trees and 8
The whole point of a CDN (the middle initial) is distribution, theoretically to a broad area.
For example, without a CDN, you have 3 servers, all located in San Francisco. The guy who lives in Florida (or Russia, or South America) who requests content from your server will receive it much more slowly than the guy who lives in Vegas.
With a CDN, there will be servers all over the nation (and preferably around the world, if you serve internationally) which will be physically closer to the requestor that can serve with a lower latency. The servers within the CDN farm utilize reverse DNS lookup to balance and serve traffic from the correct place.
Grammar Lesson: you're is a contraction of "you are"; your means you possess something; yore means days gone by.
I'm the founder of OpenDNS (and long-time slashdot reader).
This article is not very accurate for a number of reasons. First, both my service (OpenDNS) and Google's are co-located in similar POPs to all of the major CDNs which causes this problem to be largely avoided. The author of the blog post used a tiny sample size and tested mainly from EC2 instances, neither of which helps his cause.
1) EC2 instances are BY DESIGN not co-located in the same place as major peering infrastructure because that real estate costs more. They are one or two hops away. People use EC2 for compute power, not for routing performance. So he needs to use something like Keynote or Gomez to test from home connections. If he had, he'd see it doesn't impact anything, and often improves performance, especially in the US. We don't have POPs in Asia yet, though they are coming this year, and when we do, we'll improve things for him.
2) Akamai is the only CDN where this will ever be perceptible because their deployments are so dense. They have 3000+ pops which means they will also be able to target more precisely. But this is being worked on RIGHT NOW in the IETF -- http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01
Anyways, this is really not the issue the author makes it out to be, and for the edge cases, they are being worked on.
Thanks,
David
# Hack the planet, it's important.
...so those in the know can select the nameserver(s) closest to them without having to depend upon a 3rd party to determine (sometimes erroneously) what servers are closest.