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

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?

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.

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

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.

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

Apple has a long running relationship with Akamai, but they also use Limelight and Level 3 for content delivery as well.

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.

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.

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)

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

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.

At least you have the option of throwing a few bucks at OpenDNS and they'll stop filtering, or even add custom redirects/shortcuts for you.

You don't have to pay them to stop filtering - just make an account and disable the setting (my information is a few month old, I've since changed to Google DNS - it is faster for me).

Good to know, thanks.

So you have to pay to get what installing unbound (Win, OSX, Linux) on your machine will give you for free?

Not sure what you mean by unbound, but your Windows box does not have a DNS server installed by default. Most people depend on the DNS server that their ISP runs. If the ISP is doing unwanted redirects or filtering, or is just unreliable, you can point your DNS to OpenDNS which is fast and reliable. You can either use it for free and it will show you ads when you typo, or you can pay them some money for their service. (edit: expanded)

Unbound is a recursive & caching DNS server. You can use it to query DNS "directly", avoiding your ISP's DNS server.

At some point in time I'd have said this would increase your DNS latency, but given the poor level of service that many ISP servers provide, I don't think that's true anymore. Though I have no data to back this up, I suspect many home users visit a fairly small set of websites and so DNS caching would work very well.

Oh I see now. OK so yes, you can either admin your own DNS server, or get an ad-supported version, or pay someone a small amount of money to do it for you. I think that about covers the options :)

You get more than just "no ads". It also provides domain filtering, which is a nice feature with kids and a million internet connected devices.

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.

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

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.

Note that you can opt out of Comcast's DNS hijacking, although the fact that it's on by default is still pretty bad.

There is, as far as I know, no switch to make their DNS more reliable, though.

I have Cablevision and they technically allow you to opt out. But even after opting out, I still get that damned useless ad-infested search page sometimes, seemingly at random. I'm not sure if it's because of their incompetence of malicious intent.

Comcast has disabled all DNS hijacking, and has since they implemented their DNSSEC validating servers.

Yeah, I think you are right. The "Domain Helper" options no longer appear in my accounts page:

http://dns-opt-out.comcast.net/help-index.php

If you're using Comcast Business, I've yet to find a way to do this. Comcast Support (email, phone, live chat) also have no idea. If anyone knows how to do it, please let me know.

That's crazy. You'd think the business version would have more customization available, not less.

I take it you've logged into your comcast.net account and the box to disable it isn't there for you?

That is my experience with comcast dns too. Although, I have had some issues with google dns too on a rare occasion where I had to change back to something else (comcast or opendns) for a short while until google dns worked again. They never hijacked anything, but it just stopped working for a brief period.

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

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

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/

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.

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

My provider at home, Rogers Cable (Toronto), will inject things in the pages you see when you're approaching your bandwidth cap. It's extremely irritating and somewhat worrying.

Basically they mangle the HTML and slap in their own banner which means they must be doing some kind of stream inspection and processing to manage this. I do not have a proxy configured, and requests don't indicate that this is being done.

I would be VERY interested to see a packet capture of the same page when you're under and near your cap.

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

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.

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.

And on Windows? Or a Ubuntu user who only knows how to use the GUI? Or OS X?

I don't know about windows but it's pretty easy to install a single program and either edit a text file or go into network settings with a gui.

What I wrote is actually possible to do on Ubuntu without ever opening a terminal.

Not to mention that the NetworkManager version shipping with 12.04 does this by default.

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

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

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.

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.

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.

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.

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?

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

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

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

CDNs could solve this by using BGP anycast routing.

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.

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

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

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.

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.

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.

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

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.

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.