Third-Party DNS Caches Considered A Blog Post

Thomas Ptacek | July 13th, 2006 | Filed Under: Bitching About Protocols

Rescorla on OpenDNS, which claims to improve performance by centralizing a DNS cache (“OpenDNS caches are really big”). And you thought third-party secondary DNS service was silly! As Rescorla rightly points out, your ISP does this for you already, and it works just fine.

You can test this for yourself using nsping, which is simultaneously the most useful and poorly-coded program I’ve written (in fairness: 1997). Random recursive GOOGLE.COM queries via Speakeasy:

nsping -z google.com 1.2.3.4
- [  22 ]    38 bytes from 1.2.3.4:  148.442 ms [  159.158 san-avg ]

Same queries via OpenDNS:

nsping -z google.com 208.67.222.222
+ [  22 ]    55 bytes from 208.67.222.222:   361.796 ms [  233.872 san-avg ]

74ms longer via OpenDNS. How much of that is network latency? You could turn off recursion, but OpenDNS doesn’t support it, so instead query for OpenDNS’s own names:

nsping -z opendns.com 208.67.222.222
+ [  22 ]    55 bytes from 208.67.222.222:  261.771 ms [  192.468 san-avg ]

41ms. Weak evidence that it takes OpenDNS 33ms longer to look up random names at Google on my DSL connection? Note also that all the OpenDNS queries “succeed”, because OpenDNS sends you to a landing page for typos.

Neat arithmatic trick: you can use nsping to guess the latency between any two recursive DNS servers.

OpenDNS claims to help “secure” DNS, by blocking “known phishing sites”. Whatever, dude, it also creates a single-point-of-failure target for DNS spoofing.

PS: OpenDNS, your graphic designer rocks. Refer him/her to us? Love, Thomas.

Viewing 8 Comments

    • ^
    • v
    Thomas,

    Lies, damn lies and statistics. ;-) I could prove the exact opposite with my own statistics.

    There are lots of variables involved including latency to our machines and latency of your machines to the internet, size of your caches, churn rate, etc.

    That said, let's see where you are and why we are slower. Can you provide a traceroute to 208.67.222.222?

    And yes, our designer does rock. We feed him lots of burritos to keep him happy.
    • ^
    • v
    Thanks for responding. This should be fun, because both of us know what latency means, what cache size means, and what churn rate is.

    I just tested and I see a 12ms average difference between random SPEAKEASY.NET names and random GOOGLE.COM names from my ISP's cache, and a 40ms average difference between random OPENDNS.COM names and random GOOGLE.COM names from 208.67.222.222.

    That is, _RANDOM_.SPEAKEASY.NET takes N milliseconds, and _RANDOM_.GOOGLE.COM takes N+12 ms locally. Meanwhile, _RANDOM_.OPENDNS.COM takes N and _RANDOM_.GOOGLE.COM takes N+40 from your server.

    A test run is 50 samples.

    Can Speakeasy look up a Google name almost 4 times faster than OpenDNS?
    • ^
    • v
    PS: Let's agree on a methodology and test from a number of ISPs.
    • ^
    • v
    Thomas,

    Happy to do so. I'm probably not going to be able to find time to sit down and do this until the weekend or maybe late tonight (PST).

    I also want to check out nsping, never heard of it before. We've used netperf from Rick Jones and queryperf for some testing along with a host of other tools. Are we going to check from our location to host's ns caches or find a way to be on their networks?

    There's no question that some ISPs run better resolvers than others. There definitely does seem to be a surprising number of crappy ISPs out there though. Personally, I'm a big speakeasy fan, and wouldn't be surprised if they're one to get things pretty right. Let's find out. Want to take the details to email and post them here once we figure it out or just keep going back and forth here?

    Email's a bit more real-time for me.

    -david
    • ^
    • v
    I'm happy to talk offline.

    I want to be clear, I think that there is value you can provide from the vantage point of "third-party aftermarket DNS cache". I just don't believe that you've found it.

    In a sense, Eric Rescorla's point is better than mine: he (smartly) concedes that your cache can be faster, and then disputes that it will make a difference to my mom.

    I'm being a bit of a twit and claiming that you're not even faster, which is just kind of mean and not as productive as Eric's comment.

    Things that sound fun to me:

    - A discussion on how to test the performance of DNS caches.

    - A discussion of the architecture of DNS caches.

    What software are you using?

    You can catch me in email at <blog>. I'll keep responding here too.</blog>
    • ^
    • v
    That's "blog AT matasano DOT com". Sorry.
    • ^
    • v
    Great post Thomas. nsping looks awesome. I have zero c skills, otherwise I'd try to port it to my linux box. :) Time to download FreeBSD maybe. heh.
    • ^
    • v
    i normally use pch or ultradns for 3rd party, since they both employ anycast. more and more dns servers are shutting off recursion because of http://www.derkeiler.com/Mailing-Lists/Full-Dis...
    and similar tools/attacks. not to mention dns pollution (i could say something here about dislike for a certain tcp/ip blackops "expert", but i think i'll leave it alone for now).

    http://www.bleedingsnort.com/blackhole-dns/ can be added to any third-party nameserver, so i wonder what improvements opendns have for their anti-phishing component. the mistyped domain names component is really weird and a bad idea to me. i'd like to see statistics on that first.

    speaking of which - if internet measurement were beautiful women, both nsping and ntpq would be "perfect 10's" even if they are badly coded. pathchar would be a 9. sexchart-pathchar would be mixing metaphors, and is thus, disqualified.

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus