In a CDN'd world, OpenDNS is the enemy

http://www.sajalkayan.com/in-a-cdnd-world-opendns-is-the-enemy.html

by johnx123-up • 14 years ago

70 64 14 years ago

Piskvorrr3• 14 years ago

"Fairly simple to set up BIND" - well yes, for someone with access to the local gateway and the ability to install a caching DNS resolver, this is a good option.

Unfortunately, most crappy DNS servers are with residential ISPs - and most residential users don't run anything near an usable distro on their gateways. For a user who's just competent enough to change the DNS settings, the "slow CDN access" versus "spotty DNS" tradeoff will be heavily weighted towards the first option.

piffey• 14 years ago

How many home users will even notice the few second difference and think there's anything they can do about it though?

Piskvorrr3• 14 years ago

Good point. The ones likely to notice would be the ones capable of setting up a local caching DNS server (that is to say, the HN crowd).

icebraining• 14 years ago

Why not just install the DNS resolver on the client machine? Sure, you'd miss out on the shared cache, but I doubt it'd make much of a difference.

sanxiyn2• 14 years ago

This is what I do. Caching DNS resolver needs no configuration whatsoever. It is literally "apt-get install pdns-recursor" and edit /etc/resolv.conf to point to 127.0.0.1.

vld• 14 years ago

This article is from 2010, back when the edns-client-subnet [1] draft wasn't even published. I believe most CDN's are now whitelisted with Google's and OpenDNS's edns list, so you'll much better results. also see edns-client-subnet demo [2]

[1] http://tools.ietf.org/html/draft-vandergaast-edns-client-sub... [2] http://news.ycombinator.com/item?id=4174512

josephcooney• 14 years ago

I don't know how many do, but Apple digital media purchases don't. OpenDNS causes movie download times to blow out to weeks for me on itunes.

elithrar• 14 years ago

Apple use Akamai, who are the exception here; which explains your problem.

SoftwareMaven2• 14 years ago

Really? I've never had that problem for movies. There are times apps seem to take a long time to update, though. I'll have to experiment.

sirn• 14 years ago

This issue will be (is?) solved with the "Client IP information in DNS requests " DNS extension[1]. A year ago, David Ulevitch (OpenDNS's owner) mentions in HN post that he already got it working for all Google properties and few other CDNs (except Akamai).[2]

[1] http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-...

[2] http://news.ycombinator.com/item?id=2941948

omh• 14 years ago

Is there a technical reason why Akamai don't support this yet?

It seems that it would be in their interests to improve this. Both for a better experience for users and lower latencies from their point of view.

Or is it just that they're big, and it's a complex change?

acdha• 14 years ago

My guess is that they're not receiving strong demand from their major customers - since they have so many massive users and a long-term code-base it makes sense that they'd be rather conservative.

bashzor• 14 years ago

Funny, I was wondering about this exact thing yesterday. Trying Google though (hadn't thought about other DNS providers), the traceroute went to somewhere within Europe or maybe even Amsterdam. Being from the Netherlands, that'd be very close, there just is no way 13ms is a ping from America.

So I guess 8.8.8.8 is multihomed or however they call it. Still, the geoIP databases claim it to be in Mountain View where Google is, so I wasn't not sure exactly how this affected 'split horizon' (on which, as far as I know, the DNS decides which IP(s) to return for the requested hostname).

gorset• 14 years ago

According to the compute engine talks from this year's google IO, they have their own private network covering most of the world and uses anycast for external Internet Addresses. This basically means that a connection from you will be routed to the nearest google data center, and from there to the final server using google's private network.

Google DNS uses both anycast and multihoming, so you will both be routed to the nearest google data center and then to the closest DNS server inside google's private network.

jemfinch2• 14 years ago

To be precise, HonestDNS uses Anycast routing to situate the same IP at multiple places around the globe, letting BGP and least cost path routing send users to their best location. The DNS protocol works particularly well for this.

gdamjan• 14 years ago

CDNs could solve this by using BGP anycast routing.

astrodust3• 14 years ago

Does this work with TCP? The only implementations I've seen are for UDP which is stateless and unaffected by route flap.

amalcon3• 14 years ago

In theory yes, but BGP anycast routing is really bad in performance terms. BGP doesn't care about performance, only politics and cost, so you can get all sorts of weirdness.

jemfinch2• 14 years ago

CDNs are typically used for transferring large objects, for whom the anycast routing instability is a real concern. If a client's anycast endpoint changes in the middle of a connect, the client will receive an immediate RST from the new server.

le2• 14 years ago

Major CDNs do use anycast routing, in conjunction with DNS/geolocation based routing in locations where anycast's results would be unpredictable (usually in locations where there are many POPs.)

mcbridematt• 14 years ago

This has long been an issue; particularly for Australian users where using a foreign DNS server will cause CDN requests to travel across the Pacific Ocean. This is one example (from 2010): http://apcmag.com/why-using-google-dns-opendns-is-a-bad-idea...

From my location Google DNS terminates within the country - so no issue there. Not sure about OpenDNS, however.

gte910h2• 14 years ago

I find putting the primary DNS on my router to by my ISPs, and the second to be a 8.8.4.4, etc, type one to be a nice compromise.

amalcon3• 14 years ago

This is actually a pretty good idea if you've noticed some sort of systemic problem with your ISP's DNS. If the secondary is likely to be down at the same times as the primary, it's a good way to avoid that dependency.

mrcharles3• 14 years ago

This article misses one of the main reasons for people to use OpenDNS/Google DNS, which is to prevent ISP hijacking of domain names or redirection of unresolved domains.

I personally use it because I am extremely uncomfortable with my ISP catching mistyped URLs and redirecting me to a page filled with ads, searches, and other bogus things.

sandstrom• 14 years ago

This is also the revenue model of OpenDNS (although I agree that they are less aggressive than some ISPs).

mrcharles3• 14 years ago

Ah, my bad. I actually use Google DNS because they don't hijack anything, which was my prime reason. I'd assumed Open DNS was similar.

That being said, I can still get behind at least choosing to let someone hijack those pages, rather than sticking with a company that does it automatically.

nyellin• 14 years ago

What country do you live in?

I have never seen an Israeli ISP do that. (Although, there were reports a few years ago that Bezeq intercepted .torrent files to add their own trackers to the file.)

polyfractal• 14 years ago

I live in the US and have had Comcast do this to me before. I routinely use GoogleDNS because of that.

Also because Comcast DNS sucks horribly and times out with upsetting regularity.

pault• 14 years ago

AFAIK all of the major ISPs in the U.S. do this.

mrcharles3• 14 years ago

Rogers and Bell in Canada both give you their own pages when you type a URL that doesn't exist.

amalcon3• 14 years ago

Verizon allows you to opt out of this, which incidentally I have done. These instructions are for FiOS, but I am proof that they work for DSL as well. (I still gripe that they don't tell people about this...)

http://domnit.org/verizon/

astrodust3• 14 years ago

Those ISPs will soon jack all your DNS traffic.

A lot of them already hijack port 80 and inject random junk in there which is why HTTPs is the way forward.

MiguelHudnandez• 14 years ago

> "A lot of them already hijack port 80 and inject random junk in there..."

That's a pretty bold claim. Other than free wifi at hotels, I've never seen an ISP use transparent proxying to intercept pages and serve ads.

Do you have any examples?

danielweber• 14 years ago

In dealing with clients, I have found that DNS routinely sucks from nearly all ISPs. It seems the most important thing they put the least amount of resources into.

nl2• 14 years ago

OpenDNS does redirection of unresolved domains itself. I don't see that as any better or worse than your ISP doing it.

(Google - of course - does the technically correct thing)

djbender• 14 years ago

The main reason I use an alternative DNS is because my ISP's DNS service goes down constantly.

nl2• 14 years ago

It's worth noting that ISP-run DNS services aren't entirely free of these issues either.

In Australia, both Vodaphone and (to a lesser extent) Optus resolve all DNS queries from a server farm in a single location. It is unfortunate, because mobile clients are the perfect use-case for highly localized CDNs.

darkhorn• 14 years ago

The biggest Turkish ISP blockes all porn sites. Thus the users need to use GoogleDNS.

igrigorik• 14 years ago

Instead of relying on a few pings, run the test for yourself: http://code.google.com/p/namebench/

The Google DNS team built the tool above, and it allows you to test your current setup against a number of DNS vendors + allows you to share the data, etc.

lftl• 14 years ago

If I understand correctly, these are addressing two different issues. Namebench seems to be interested in finding out which DNS server will return a look up request the fastest. The OP though is saying that because global DNS providers don't currently pass along information about my local IP address, I'll get a suboptimal response that points to an IP address that may not be the fastest for me.

Or does namebench actually test the IP addresses you get in response to test their response time?

gte910h2• 14 years ago

You should actually be using a free, fast DNS near you, with at least one not on your ISP. Here is a program to help find them:

http://www.grc.com/dns/benchmark.htm

michaelcampbell• 14 years ago

Network neophyte here. Am I wrong in that CDN's ultimate goal is geolocation of the requestor, and they're using DNS to do that? And if the user uses a DNS that isn't "near" him, this scheme fails?

If that's correct, is there no better way to do user geolocation than the nameserver they choose to use? That seems weird to me.

In a CDN'd world, OpenDNS is the enemy

Related Stories