Slashdot Mirror

← Back to Stories (view on slashdot.org)

How CDNs and Alternative DNS Services Combine For Higher Latency

Posted by Soulskill on from the taking-the-bad-with-the-good dept.

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."

9 of 187 comments (clear)

  1. Re:Poor application design by jcinnamond · · Score: 3, Informative

    I think you're missing the point. Geographically aware DNS is used to send you to your nearest deployment of an application. Deciding after you've arrived is too late.

  2. Google Public DNS by The+MAZZTer · · Score: 3, Informative

    Automatically routes your DNS request to a Google server close to you. So there's no problem here.

  3. Re:Is this a problem? by Burdell · · Score: 4, Informative

    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.

  4. Re:Is this a problem? by b4k3d+b34nz · · Score: 4, Informative

    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.
  5. This is not accurate by davidu · · Score: 5, Informative

    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.
    1. Re:This is not accurate by davidu · · Score: 4, Informative

      yep! This is the exact goal of the IETF draft I linked. Unfortunately the old guard of DNS (Vixie, et al) are not supporting it because they fear it raises insurmountable privacy concerns. Most disagree since the ultimate authority will see the clients IP eventually, but that's the current hold up. Not sure if it can be resolved to everyone's satisfaction. :-(

      --

      # Hack the planet, it's important.
    2. Re:This is not accurate by arkhan_jg · · Score: 5, Informative

      You know, I'd thought I'd actually try it out for myself with a rough and ready test. I have an ISP that gives me multiple real IP addresses, so I stuck my PC on the DMZ with a real IP, and tested each of the DNS servers as the sole DNS server in windows, without using either my local dnsmasq local cache or the one on my router. Obviously, I flushed windows own DNS cache between each ping test. The results are below, make of them what you will.

      I also tested all DNS providers with both primary and secondary servers; since the 2ndary servers always gave me the same IP address as the primary, they're not included. Ping times are a simple 0DP average of two sets of 10 pings (and there were no odd spikes, with my connection otherwise idle)

      First though, the response times of the DNS servers themselves, average uncached - tested using GRC's DNSBench.
      aaisp is my own ISP, BT is a large ISP in my country, 4.2.2.3 is one which I'm using at the moment, having previously tested it as fastest.

      google (8.8.8.8): 156ms
      opendns (208.67.222.222): 176 ms
      aaisp (217.169.20.20): 115 ms
      BT (194.72.9.34): 71ms
      level 3 (4.2.2.3): 95ms

      Then, testing which CDN server each DNS server sends me to, and the ping times of those servers - I used the same CDN DNS names as the article;

      First, cdn.thaindia.com (internap):

      google resolves as 64.7.222.130, ping 167ms
      opendns resolves as 77.242.194.130, ping 15ms (!)
      aaisp resolves as 64.20.60.99, ping 82 ms
      BT resolves as 64.20.60.106, ping 81ms
      level 3 resolves as 64.20.60.106, ping 81ms

      Then profile.ak.fbcdn.net (akamai):

      google resolves it as 92,122,217,75, ping 22ms
      opendns resolves as 195.59.150.152, ping 15ms
      aaisp resolves as 92.122,208.106, ping 13ms
      BT resolves as 88.221.94.242, ping 14ms
      level 3 resolves as 195.59.150.144, ping 15 ms

      However you slice it, google's public DNS is a bad choice for me. Longer to resolve addresses, and it sends me to non-optimal CDN servers. OpenDNS is a mixed bag; slower resolution than the rest, but sends me to easily the most optimal cdn.thaindia.com server (shame about the redirected NXDOMAIN problem). Yet BT are the fastest DNS resolver of all, and still return decent results. Go figure; I thought they'd be overloaded and well, crap.

      I'm definitely going to have to further testing for my own personal use, using whole page rendering on my favourite sites to see what is actually the best option for me personally, as DNS resolver speed clearly isn't the whole story in this CDN world.

      --
      Remember kids, it's all fun and games until someone commits wholesale galactic genocide.
  6. OpenNIC published server locations... by pongo000 · · Score: 3, Informative

    ...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.

  7. Re:Leave Canada Alone by Sillygates · · Score: 3, Informative

    This still violates the DNS specification, and there is no way to effectively turn it off. Why is this a problem? Please see: http://en.wikipedia.org/wiki/DNS_hijacking#Use_by_ISPs .

    For this reason I use Internet2, Level 3's (4.2.2.2 - 4.2.2.4), and now google's dns servers.

    --
    I fear the Y2038 bug