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

Comments

Leave Canada Alone

[ironicsky]

Why drag us lovely CDN's in to this.

Re:Leave Canada Alone

[PNutts]

Why wouldn't I use OpenDNS? They may be working for profit but it is free to individuals. Also, I disagree that they are the "exact same ads" when they consist of a few text links and I trust them more than Comcast. But more importantly, assuming you were correct that they are the same ads, the other benefits far outweigh this nit. The ability to whitelist/blacklist domains and block them by category is more than worth the price of admission, which again is free. Then throw in useage reports... To ignore all that because of the "exact same ads" is shortsighted. The company I work for started using this and the incidents of crapware have gone way down. I've set it up on all my family's computers and recommend it to others.

Re:Leave Canada Alone

[Anonymous Coward]

For one, because they're deliberately abusing the Open moniker. They also do not provide an ad-free DNS service, unlike for example Google's DNS server. Furthermore, they redirect www.google.com through OpenDNS servers. Last but not least, to change the configuration (e.g. the Google redirection or the NXDOMAIN highjacking), you have to get an account and always log in. For DNS. Are you kidding me?

Re:Leave Canada Alone

[Sillygates]

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.

Re:Leave Canada Alone

[Sir_Lewk]

I don't give a shit if you use OpenDNS or not. If you like their censorship features then that is great, use what works for you.

What I do give a shit about is people recommending OpenDNS as a good alternative for ISP DNS servers in discussions about NXDOMAIN fuckery. They are about the absolute last alternative DNS provider you should choose if NXDOMAIN is important to you. Just about any of the dozens of other free DNS servers doesn't require you to do retarded shit like use DynamDNS just to get standards compliant DNS results, recommending OpenDNS is irresponsible at best.

Seriously, just because they have "Open" in their name, doesn't mean they are good.

Re:Leave Canada Alone

[BitZtream]

Its slow, it requires you to opt out of its crappy web redirects, it redirects google on occasion to the wrong servers.

I've got a list about 8 miles long that explains while using OpenDNS is an absolutely retarded idea unless you have absolutely no other choice, which of course you do.

Re:Leave Canada Alone

[Sir_Lewk]

OR just use a REAL DNS server and don't worry about that shit. Why is this such a hard concept?

Re:Leave Canada Alone

[Sir_Lewk]

Wow, so suddenly now purely informative and relevant posts get modded flamebait because of a little profanity? Newsflash mods: profanity does not warrant down-modding, slashdot has no policies against profanity, and never has.

Re:Leave Canada Alone

[h0dg3s]

Level 3 has 4.2.2.1 to 4.2.2.6

Re:Leave Canada Alone

[lonecrow]

But I use OpenDNS to keep the kids away from Chat Routlette, Goatse.cx and other emotionally scarring sites. If Google DNS offered that I would switch.

Re:Leave Canada Alone

[Anonymous Coward]

No, you can't. Chatroulette for example can be accessed through its IP address alone, which any number of DNS lookup web tools will give you. Unless your kids are idiots, if they want it, your DNS games won't stop them.

Parent is NSFW

[Anonymous Coward]

"Pair" in question is a pair of nipples, apparently.

Poor application design

[Mondo1287]

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.

Re:Poor application design

[jcinnamond]

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.

Re:Poor application design

[Zerth]

Like you couldn't redirect on GET instead of serving up the app?

Re:Poor application design

[Trepidity]

There's various tricks you can do to decide later, if you have significant content other than the raw HTML page itself, though they do require some server processing. The initial HTML request will be based on DNS, but once the user's hit your servers, you have their IP, so you can rewrite the URLs of embedded content / AJAX requests / whatever, so that they hit a geographically nearby server.

Re:Poor application design

[mother_reincarnated]

Sure you can! If you don't mind effing up the URL bar and possibly generating certificate warnings.

It's not a clean nor transparent way to do it.

Re:Poor application design

[jcinnamond]

Redirect on GET is doing it too late. By that time you've already sent a load of traffic to one location, potentially one that takes a long time to get to.

It's not much of an issue for a low volume website with users in the same country but it does matter when you get high volume sites with users around the world.

Re:Poor application design

[BitZtream]

So once you've connected to the server, its then going to have to redirect you somewhere else since its only once you connect that it gets your IP so it can figure out if you need to be directed.

DNS is the step before that, so you can do it one stage earlier.

Or your app has to have some list of ip ranges so it knows where its at and then where to connect to, which means you have to keep the client list up to date since ips move across the nation wildly. The IP I had 2 months ago is no being used in Texas, thats about 1500 miles aware from where I am.

So the client is going to be constantly trying to update its list of address ranges so then it can figure out which server to connect to, so you've added a metric fuckton of traffic and complexity to the client ... when you can simply handle it at the DNS level.

DNS is pretty much the first and easest to manage portion of the network chain, as long as everyone plays by the rules. Problem is, ISPs haven't been playing by the rules for years.

Re:Poor application design

[rekoil]

Or you can use DNS for a first guess to the closest site, then use a redirect at the server (which, unlike DNS, sees the real client IP) to correct egregiously bad geo-DNS decisions. This way, a redirect is only done if it's likely that the overhead of the redirect itself will be offset by the faster page load from the "correct" site.

Is this a problem?

[pjt33]

How many of the resources hosted by CDNs are things which we're already stopping with various ad blocking techniques, and how many are content we actually care about?

Re:Is this a problem?

[Burdell]

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.

Re:Is this a problem?

[betterunixthanunix]

Sounds like a system of mirrors to me. Now, the more relevant question: why is it using DNS to try to determine my location?

Re:Is this a problem?

[michael_cain]

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.

Re:Is this a problem?

[maxume]

To transparently reduce latency and hops.

Re:Is this a problem?

[Professor_UNIX]

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.

Re:Is this a problem?

[betterunixthanunix]

As opposed to using the client IP address?

Re:Is this a problem?

[b4k3d b34nz]

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.

Re:Is this a problem?

[pjt33]

Ok, saving network capacity I can buy as a benefit. I'm not sure that latency - the focus of TFS - is a real issue when downloading software updates, though.

Re:Is this a problem?

[maxume]

That wouldn't be transparent to the application server.

Re:Is this a problem?

[Anonymous Coward]

The servers within the CDN farm utilize reverse DNS lookup to balance and serve traffic from the correct place.

No, they don't. The way this works is that there is a separate domain name for the content which is to be served by the CDN. The response DNS resource record is dynamically chosen to point to the CDN server closest (in routing terms, not geographically) to the source of the request. The reverse lookup (i.e. the canonical name of the IP address) does not play a part in this, only the routing paths to the resolver's IP address.

The request usually comes from a recursive resolver which doesn't run on the user's computer. Most often it is located in one of the end-user ISP networks though. If the user chooses to use a resolver which is located across the world from him, then the CDN will also point his browser to download from a CDN server close to the resolver, not close to the user.

Since it's not a good idea to use a resolver which is on the other side of the planet, because DNS requests are frequent and invariably must finish before anything useful can be done, meaning high latency DNS sucks, this problem is not as big as it looks. For example, you can use Google DNS (8.8.8.8 and 8.8.4.4) and the resolver will not be far away from you, because those are IP anycast addresses. There are many resolvers across the world which all respond to these same addresses and BGP (the Border Gateway Protocol) routes your packets to the closest one.

Re:Is this a problem?

[hedwards]

It's a problem of implementation. Few sites disclose that they're wanting to do it, and I had no idea until I installed noscript and started to have to enable a huge number of sites to view what should be relatively simple ones. On top of which each one can have vulnerabilities. I'm not suggesting that you were wrong, there are definite reasons why centralization is asking for trouble. But by the same token, I don't think the companies engaging in that process are as transparent, honest and responsible about it as they need to be.

Re:Is this a problem?

[Dahamma]

It's not as much a matter of "using DNS" to determine your location, it's using the IP of the DNS server asking for the CDN's IP to determine your location - with the possibly faulty assumption that your DNS server is near you geographically.

The problem is the CDN's DNS only sees your DNS IP, not your computer's IP.

There are actually a couple solutions to this, though. The most efficient one is Google's proposed extension to DNS that basically forwards the IP of the host originally making the request.

Another solution is for the application server to notice that your IP is not the best for the CDN, and do an HTTP 302 redirect to the correct one. That adds a bit more latency for the orignal request, so is best for larger files (like streaming video, etc). Plus, it only works for HTTP.

Re:Is this a problem?

[UnderCoverPenguin]

Supposedly my ISP of 2 years ago consolidated its servers into 2 data centers about 3 years go. About 2.5 years ago, their DNS servers in 1 center went off line and the servers in the other center were overloaded, so they went down, too. Fortunately, my local head end still had a machine they could use for DNS and did so (allowing only local subscribers, of course). The nest major DNS outage they had, the local head end no longer that resource, and their routers were forcing all DNS requests to their servers, so we suffered the outage along the rest of their subscribers. I was lucky in that I was able to get the IP address of my (then current) client's VPN server, so I was still able to work (but no Slashdot that day).

Re:Is this a problem?

[BitZtream]

Basically, CDNs keep the Internet working

You are also one of the guys who claims its going to collapse under its own weight next year too I'm sure.

If you think the limited amount of bandwidth is the issue than you really don't know anything about what the backbones are capable of.

Just because your local ISP is too cheap to upgrade its circuits to fill its own needs doesn't mean the internet is 'out of bandwidth'

Re:Is this a problem?

[BitZtream]

content from your server will receive it much more slowly than the guy who lives in Vegas.

Not likely. Theres more latency sure, and australia has shitty connections to the rest of the world, but outside that, there really isn't a bandwidth limitation on the backbone, just latency issues, which TCP handles just fine.

Re:Is this a problem?

[zippthorne]

So, um..

Why can't the CDN's use the same system?

Re:Is this a problem?

[b4k3d b34nz]

Respectfully, I disagree, since we see exactly the opposite of what you're saying using our CDN setup. Packet loss over long distances causes a slow retransmittal if it has to go across the world. More switching = slower transmittal as well, so if you can reduce the number of stops along the way, you're going to see both lower latency and less retransmission.

Also, I never said bandwidth, I just said it would get there more slowly, and that's due to the number of computers sitting between me and the theoretical server in San Francisco.

You say TCP handles latency just fine, but in reality TCP requires no packet loss and low latency to avoid burst/wait, so since I'm more likely to hit a high latency connection crossing the world, it's also more likely that I'll get greater levels of packet loss, and therefore the packet window will be smaller than a low latency 100% packet transfer.

Re:Is this a problem?

[bell.colin]

Microsoft? WTF, You mean the update service that takes 15-30 damn minutes to determine that i don't have the 800KB WGA .dll file version up to date before i can install any other updates. I don't think that has anything to with CDNs at all, their update site is just damn sloppy. (BTW that's on a 21M Tier1 T3 so bandwidth is not the problem)

Apple - Don't use it so i wouldn't know
Symantec - Other than the crappy AV software it "was" updating, LU updates download just fine (and fast)
RedHat - RPM repos work fine.
Microsoft - don't make me laugh to hard at MS Update being the slowest damn thing ever.

Re:Is this a problem?

[Burdell]

Nope, I don't think the Internet is going to "collapse". I've run servers and networks for ISPs for over 14 years, so I think I understand just a little about how things work. We have had Akamai servers on our network for about 10 years, and they save us a good chunk of bandwidth (as much as 15% some days) and give our users a better experience (faster and smoother downloads).

Re:Is this a problem?

[xous]

So your competent enough to be able to connect to a VPN and remember an IP address but you couldn't just change your resolvers to a known set of public resolvers?

Re:Is this a problem?

[UnderCoverPenguin]

As I said in my post, the ISP's routers were redirecting DNS requests to the IPS's own DNS servers. I don't know if that one still does this, but my current ISP currently does not.

Re:Is this a problem?

[rekoil]

That's *exactly* what a CDN is, although generally they're implemented as caching proxies as opposed to true mirrors (i.e. content is pulled into a site the first time it's accessed, then served from the site from that point on). Just about every large web property uses CDNs run by Akamai, Limelight, Internap, Level3, and others, and most the largest sites (Google, Yahoo, et al) operate their own in-house.

DNS is used because *most* of the time, the location of your DNS resolver is a good hint of the client's actual location. There are many cases where this isn't true, which there are other solutions for - one is to redirect the client to a better-located site if the server that gets the request determines that the DNS geolocation was profoundly wrong, another is a proposal from Neustar and Google to embed client IP information in forwarded DNS queries, and have geo-aware resolvers use that information instead of the requesting resolver's IP if available.

Disclaimer: I've worked for two of the companies I've named above. Not telling which ones. :)

Re:Is this a problem?

[rekoil]

RTSP (IETF media streaming protocol) and RTMP (Adobe's proprietary version) support redirects as well.

Re:Is this a problem?

[thegarbz]

If you get this far you're already too late. The point here was to reduce latency as well as bandwidth. Using the clients IP address when they connect to determine the best server to send them some updates may work just fine, however the process of single DNS request -> ideal server is still better than:

1. DNS request -> IP addres of a server
2. Connect to server
3. Reverse IP lookup of client
4. Redirect client
5. Finally connect to ideal server

Re:Is this a problem?

[Uncle Dazza]

I had exactly the same problem with Time Warner Cable in SoCal. My apple tv would take 12 hours to download a film. Changed my DNS servers to level3, which resulted in a Akamai server outside TWC (but still in LA), and viola! Instant HD streaming.

It's actually a bit poor that the CDN doesn't detect this and redirect some connections to alternate servers. I always wondered if it was Akamai that couldn't handle the load or a limit within TWC..

Re:Is this a problem?

[Dahamma]

True - and really, ANY protocol can support redirecting as long as it's part of the protocol, by definition ;)

Just curious, though, does anyone actually *use* RTSP any more? I think most of the big players (Apple, Microsoft/Silverlight, Netflix, Vudu, CinemaNow, etc) have all switched to some form of HTTP adaptive streaming. And others are swiching away from Flash (Netflix, Youtube) where possible, partly because it doesn't support seamless adaptive bitrate changes with RTMP...

Re:Is this a problem?

[allo]

but only for ads the *latency* is important. The latency of a windows update is not so important, the data rate is more imporant there.

Re:Is this a problem?

[badkarmadayaccount]

I don't think you actually have to forward IPs. Just publish a anycast list of IPs with geo-data that DNS can resolve to as it sees fit. Transparent, client and server side, and anonymous. Though Google's idea seems reasonable.

Re:Is this a problem?

[Dahamma]

I'm not sure that is the best solution for long-running TCP connections like streaming a movie over a couple hours, though...

Re:Is this a problem?

[badkarmadayaccount]

Wha? Wait, I think you got me wrong. The CDN DNS server broadcasts a list of IPs that somecdn.tld resolves to, along with location data for the IPs, the DNS server receives that list and caches it. When a client looks up somecdn.tld, the DNS server checks the client IP for geo data against a DB, and sends the IP of the physically nearest CDN server. Sorta like anycast, only it is statically resolved per look-up on the DNS level.

Re:Is this a problem?

[compro01]

A company I used to work for used Akamai to deliver their software updates.

Google Public DNS

[The MAZZTer]

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

Re:Google Public DNS

[Anonymous Coward]

Right. However, the problem arises with non google owned services. Like akamai CDNs.

Re:Google Public DNS

[arkhan_jg]

But if you look at TFA, that doesn't actually work in practise - looking at, for example, the swedish EC2 host pinging -
internap:
using local DNS gives a ping of 36.3, opendns is 40 and googledns is 189!
akamai:
local dns resolved IP pings at 13.2, opendms at 51.7 and googledns at 36.

In both cases, using local DNS gives a substantially faster responding server with both CDN networks tested, presumably one that is physically closer to the testing machine. Using google DNS and open DNS both result in getting less optimal servers for the actual content; so any saving in DNS resolution itself is lost due to the CDN giving you the actual website content from a sub-optimal location; especially if you're pulling down lots of different bits of content.

It's an interesting enough result that I'm going to reinvestigate using my ISP DNS for my dnsmasq local cache server (or at least one hosted in my own country), and compare total page rendering time for the sites I visit often, rather than just DNS resolution times, given how many large sites use akamai and the like these days.

Re:Google Public DNS

[KahabutDieDrake]

Have some perspective. The biggest difference in your numbers is about the time it takes you to blink twice. Why don't you think about that for a few seconds, which is several orders of magnitude longer than it takes to find and start receiving data from your non-optimal CDN.

Re:Google Public DNS

[fluffy99]

Yeah the latency is a minor issue, particularly for video content where actual bandwidth and jitter matters. Adding up the latency for lots of gets on a single web page might be noticeable. In the bigger scheme of things, having your traffic travel a longer path ends up costing someone more money. Traffic taking longer paths increases the bandwidth use on cross-country fibers, may involved farming out to other backbones for delivery, etc. It's the same notion (or at least used to be) of local calls being cheaper than long distance.

Re:Google Public DNS

[hairyfeet]

Not to mention this whole thing is working under the assumption that your local DNS is actually..oh what is the word?...oh yeah...good. I'm on Cox Cable and during "popular" times the Internet slows to a crawl using their DNS, whereas OpenDNS continues to work reliably, day in and day out.

If I have to wait an extra eye blink for content (I use Noscript and ABP so a lot of that stuff I'll never see anyway) it is nothing compared to the wait I'd have by using Cox Cable DNS, and for what? So I can have some ads I don't want served to me a little faster? No thanks, I'll stick with OpenDNS.

Do you even know what a CDN is?

[Anonymous Coward]

Yeah, go ahead and block them. Try it. Do you know what happens? Most of the web sites you use just won't fucking work. This is especially true with so many web sites these days serving up their images, JavaScript scripts and stylesheets via a CDN.

Re:Do you even know what a CDN is?

[betterunixthanunix]

Sounds like the pages will load even faster? I already block Javascript, Flash, and other trendy web technologies, and to be honest, if a webpage looks less "pretty" because I also blocked images and stylesheets, I can deal with it. If the images are really that important, then I can just load them as needed.

Re:Do you even know what a CDN is?

[betterunixthanunix]

1. The Web is not the be-all and end-all of the Internet
2. Browsing without autoloading images is not nearly as bad as you make it out to be
3. Most of what I go on the web for is news (where the text is usually more important) and journal articles (which are distributed as PDFs)

As a case in point, Slashdot is perfectly fine without images or Javascript (as long as you request Javascript-free pages, which are readily delivered).

We've discussed this before

[Anonymous Coward]

Previous Discussion

DNS is not and should not be a good indicator of client location. The proper solution for routing to a closer server is IP anycast.

Re:We've discussed this before

[mother_reincarnated]

Yeah, as long as your entire transaction consists of a single packet being sent to the server. It's not reliable after that.

Re:We've discussed this before

[Ash-Fox]

Yeah, as long as your entire transaction consists of a single packet being sent to the server. It's not reliable after that.

Non-sense. DALnet has been using it now for years and the TCP connections to their anycast IRC servers appear to be perfectly reliable.

Re:We've discussed this before

[mother_reincarnated]

LMAO!!!

no big deal, really

[youn]

most people don't actually care about DNS... they use the dhcp provided dns server from their ISP and don't even know how to fiddle with it... heck a lot don't even know what DNS is and will say, "DNS yourself, stop cursing :)"

let's assume for a minute that ads are less relevant... not really a big deal... because those are more likely tech savvy people (or friends of tech savvy people) who are more likely to install extensions such as adblock and get rid of ads alltogether.

plus there is the obvious for advertisers... if it is not really reliable, well don't use it, find other ways to geolocate your guy :)

Re:no big deal, really

[bjourne]

CDN:s (Content Delivery Networks for those who don't know. I can't believe these things have to be spelled out on /. Quality really has gone downhill) are not only used for advertising. They are used to serve all kinds of resource-intensive content. Such as porn. And streaming video. Let's say you're an Aussie with your website hosted on the Australian mainland. Then you'll pay premium for international bandwidth because Australia has crappy connections to the rest of the world. So you want international visitors to get their images and other static content you don't change regularily from a CDN to reduce your bandwidth costs.

What?

[Seth Kriticos]

I don't really know what benefits CDN could give me.

Anyway, I solved the sluggish ISP DNS problem with simply installing bind9 and be done with it. Setting up a DNS server on a modern system is really child's play, no need for the openDNS stuff.

(install bind9; remove DNS IP. Done - around 1 minute)

Re:What?

[Shakrai]

Anyway, I solved the sluggish ISP DNS problem with simply installing bind9 and be done with it

Having my own DNS server is one of the reasons why I haven't abandoned my full fledged Linux box for a DD-WRT flashed router or similar solution. Running BIND locally gives me a local DNS cache, remains compatible with CDNs (since the requests come from my own IP) and avoids any DNS tracking on the part of my ISP. Since I have a fixed IP address I've also made my server available to friends who share my ISP -- no reason they should have to use it's crappy DNS servers when mine is a hop or two away, is there?

Re:What?

[value_added]

I solved the sluggish ISP DNS problem with simply installing bind9

So instead of one problem, you now have two? ;-)

Most of the complaints I read on Slashdot invariably seem to be related to a loss of control. Seems to me that if you object to how others do things, taking charge and doing it yourself when possible is the only logical solution. For the tecnically inclined, that typically amounts to a few extra bucks per month along with, as you pointed out, some minimal work.

Re:What?

[John Hasler]

> ...that typically amounts to a few extra bucks per month...

For what?

Re:What?

[UnderCoverPenguin]

avoids any DNS tracking on the part of my ISP

Assuming your ISP doesn't sniff your DNS requests. Having DNSSEC on the root servers only serves to detect DNS high-jacking. As I understand it, the actual DNS requests and responses are still open to monitoring.

Re:What?

[Shakrai]

That would be a violation of my state's wiretapping laws.

Re:What?

[Ash-Fox]

That would be a violation of my state's wiretapping laws.

Most wiretapping laws that I am aware of do not protect you from 'eaves dropping' from private companies when you're using their services.

Re:What?

[Shakrai]

Then I don't think you understand the laws very well. Verizon can't eavesdrop on your telephone calls for the hell of it. If they are working on the lines and a tech splices into your line it's one thing -- but they can't eavesdrop on you just because you are using their services.

Here's the NYS law:

A person is guilty of eavesdropping when he unlawfully engages in wiretapping, mechanical overhearing of a conversation, or intercepting or accessing of an electronic communication.
Eavesdropping is a class E felony.

There's a limited exemption in the law for a telephone company to monitor your calls in the "regular course of business", i.e: for troubleshooting or billing purposes. Somehow I doubt that a ISP monitoring all of your DNS packets to build a profile of you would qualify under this exemption.

Re:What?

[Ash-Fox]

Then I don't think you understand the laws very well.

I'm pretty sure that's only the case when it comes to common carrier scenarios. Since ISPs aren't considered common carriers, I am sceptical this applies to such instances as I have been told by actual lawyers due to related work.

Slashdot uses Akamai

[sajalkayan]

Slashdot.org is serving static assets from the hostname a.fsdn.com which is served via Akamai CDN. I count 19 requests to http://a.fsdn.com/* on a single pageload of the homepage. These static files are currently served by a server within my ISPs network rather than some server on the other side of the globe... Alamai uses DNS routing.

Re:Slashdot uses Akamai

[Ash-Fox]

But every time I notice slashdot taking a long time to load it is always one of the a.fsdn.com links that it is "stuck" or sluggish on (as you see them in the status bar). I wonder why that is?

Duh, they're getting slashdotted!

Most CDNs don't do this..

[poptix_work]

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.

Re:Most CDNs don't do this..

[mother_reincarnated]

Ok so by "shoddy CDN companies" you mean every CDN anyone here has ever heard of? And the vast majority of enterprises that have hot/hot (public) datacenters?

Using anycast for serving content is a guarantee of fail. Great for DNS, less than ideal for HTTP. How serious a failure depends on important reliable and consistent end user experience is. Using geolocation based on the actual source address for content within the pages is a very intelligent thing to do in addition to doing it at the LDNS level initially.

On the innertubes anycast is good for things for which UDP is appropriate (even if they use other transports), and it can be acceptable for HA between a hot and a warm datacenter, but it's just not robust enough for a "CDN".

Re:Most CDNs don't do this..

[Thundersnatch]

CacheFly and MaxCDN, amongst others, disagree. They've built their businesses on anycast *TCP*. The idea being that routes to well-managed colocation facilities are very stable. My tests indicate both are very fast in the USA, but I suppose Gomez or some similar service would have to tell us if the percentage of dropped connections is any higher than a DNS-based CDN.

Re:Most CDNs don't do this..

[Thundersnatch]

"Anycast TCP" means advertising a connection-oriented TCP service via anycast routing. I did not make up the term, Google for "anycast TCP".

And as far as Gomez is concerned, I am not a customer nor an advocate, but they are probably the best-known distributed monitoring service out there. My point was that you need lots of long-term measurements from many vantage points to see if using anycast with TCP services is really as trouble-free as CacheFly et. all contend.

Questionable testing method

[Florian Weimer]

Two things make those numbers fairly irrelevant: CDNs are optimized for delivering content to end users, not datacenters (where most machines are non-Windows anyway, so you don't even need AV updates). And what matters in the end aren't ping times, but actual request latency.

Re:Block?

[jon3k]

Why is "services" in quotes?

Uptime

[h4rr4r]

Considering TWC can't keep their DNS servers up reliably using them is not even an option.

Re:Uptime

[Shakrai]

That's another reason not to use them. When I experimented with DD-WRT to save electricity (my other router is a full fledged Linux box that uses ~50 watts) I had it set to use TWC's DNS servers. Had forgotten how often they went down until I found myself using them again.

Pathetic. How hard is it to keep BIND running?

Re:Uptime

[UnderCoverPenguin]

Bean counters refusing to approve more and/or better machines to host DNS.

Re:Uptime

[bill_mcgonigle]

Pathetic. How hard is it to keep BIND running?

Maybe they were on Fedora. Multiple yum updates broke production BIND's in recent months.

All the more reason to block.

[Jane Q. Public]

Use NoScript and / or RequestPolicy, which let you allow the CDNs you want, block those you don't. And have the additional side benefit of blocking tracking cookies and other such nastiness from companies you don't like (DoubleClick, Google Analytics, etc.)

This is not accurate

[davidu]

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

Re:This is not accurate

[funfail]

Hi David. Isn't it possible for you to just cooperate with Akamai and resolve according to the client location based on IP address?

Re:This is not accurate

[cynyr]

to flame you, Why cooperate with online advertisers, i really wish that i could block ads, pre-render instead of post in chrome, would make webpages nice and snappy, and save me some bandwidth.

Re:This is not accurate

[davidu]

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

Re:This is not accurate

[Anonymous Coward]

awesome! thank you for your reply. BUT wouldn't giving client ip away in the dns request reduce privacy?

Re:This is not accurate

[davidu]

That's the argument opponents make. I don't buy it for a variety of reasons. Hard to write it on my iPhone but will blog about it soon.

Re:This is not accurate

[arkhan_jg]

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.

Re:This is not accurate

[mother_reincarnated]

Because the organization that runs the authoritative DNS isn't going to see your source IP in a fraction of a second when you make the connection to their (in this case) web server?

Re:This is not accurate

[GIL_Dude]

pre-render blocking does indeed save you some bandwidth and can make pages render more quickly. That's my main reason that I use FF. However, some folks may WANT to do post-render. The reason (a bit on the shady side though) is that downloading the ad and just not seeing it will:

1) Give the site you are visiting revenue
2) Cost the advertiser in bandwidth even though you don't have to see the ad.

Some folks have gone to Chrome preferentially so that they can block post render and allow their favorite sites to get revenue without having the bother of the ads blemishing the page.

Re:This is not accurate

[bananaendian]

by davidu (18) writes: on Saturday May 29, @11:32AM (#32389146)

I'm the founder of OpenDNS (and long-time slashdot reader).

Oh yeah, how long-time? I've been reading /. for 928499 seconds where as you've apparently just clicked here 18 seconds ago. What a newbie! They should have somekind of filter for first time posters...

  ) = hides under hat

Re:This is not accurate

[BitZtream]

Since you're here ...

So you want to explain why you hijack google traffic?

Why does www.google.com CNAME to google.navigation.opendns.com ... which is in your address space and apparently just passes through to the real google servers?

Re:This is not accurate

[UnderCoverPenguin]

Most disagree since the ultimate authority will see the clients IP eventually,

I think the concern could be about unnecessary disclosure to 4th parties. (The 1st responder DNS being the 3rd party and the "ultimate authority" being the 2nd party)

Re:This is not accurate

[BitZtream]

If anyone would like to see this for themselves on any servers they use, check out namebench

http://code.google.com/p/namebench/

Tests to figure out which DNS servers you should use from a speed perspective mostly, but does all sorts of neat checks for DNS hijacking like OpenDNS does.

Its bad enough to do NXDOMAIN hijacking, but flat out stealing google traffic and running it threw their own servers is just bullshit.

Re:This is not accurate

[Anonymous Coward]

While I question the utility of hiding one's IP from a DNS server (or anything on the web, really), it's entirely possible that your IP won't ever be displayed to the resolved server.

In cases of SMTP resolution, it's not meaningful for the DNS server to know the client IP. Also, I frequently DNS sites to see where they are, get IP block info, and possibly block access to them. I don't access their services as I do this, and thre's no reason for them to know I'm looking into them. An antivirus firm, when looking up the IP blocks of hostnames, could have an NXDOMAIN returned if the DNS server matches one of their IP's, thus throwing off the investigative trail.

The obvious resolution to this would be to set a privacy flag on the query. If I tell the resolver on my machine I want to be private (maybe for load testing issues such as was done in a comment below), the receiving DNS server should both 1. not forward my IP to the upstream DNS server and 2. forward the privacy flag to the upstream server so that the downstream server IP is not forwarded to the next upstream server. Problem resolved.... right? it would then be a matter of updating nslookup, host, etc to use the privacy flag.. but the protocol itself wouldn't be preventing the privacy.

Actually, reading the given link,
"Users who wish their full IP address to be hidden can include an edns-client-subnet option specifying the wildcard address 0.0.0.0/0 (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS). As described in previous sections, this option will be forwarded across all the Recursive Resolvers supporting edns-client-subnet, which MUST NOT modify it to include the network address of the client."

So... what's the problem here? ;-)

Re:This is not accurate

[davidu]

You have summarized the privacy concern well. That's exactly the issue. The fear that is held is that implementations won't respect someone who includes 0.0.0.0/0 and instead will replace it with the actual client's source_addr when forwarding a request along. Think hotel, cafe, wifi hotspot vendors, etc... Those folks tend to implement for ease, not privacy. And sometimes they opt against privacy.

The critics of the proposal think that there is no assurance of privacy, and they feel that's a reason to not move forward. In my world, there are much better ways to violate real privacy than to see a client IP address in a DNS request, but maybe I'm less sensitive about it. I think it's certainly worthy of discussion and attempting to find a solution.

Re:This is not accurate

[davidu]

Well the critics argue that the Internet != The WWW. Which is true. If you are sending email, the destination SMTP server, and it's corresponding authoritative DNS server would never normally see the client's original IP. The fact that TONS of benefits exist from routing and performance to anti-spam measures would benefit from this, we're creating a vector of privacy leakage that possibly didn't previously exist in all scenarios.

None of this considers the fact that very few DNS operators would actually even implement this standard. Just big 3rd party resolvers like us and Google and big CDNs and eye-ball sites.

Re:This is not accurate

[UnderCoverPenguin]

Actually, I was thinking in terms of some intermediate DNS provider between the 1st responder (which sees the client's DNS request directly) and the final destination, which may or may not also be the authoritative DNS provider. That is, either the first responder forwards the request to another non-authoritative provider rather than directly to the authoritative provider. or the authoritative DNS provider is a 4th party providing DNS on behalf of the final destination. Either could result in disclosing the client's IP address unnecessarily to a 4th party.

(Or maybe I should say 5th party, since the client's, destination's and any intermediate ISPs are 4th parties who will see the client's IP address anyway.)

Re:This is not accurate

[UnderCoverPenguin]

None of this considers the fact that very few DNS operators would actually even implement this standard.

I take it that you and the other big DNS providers use custom DNS software? Still, I wonder how many others use BIND (though I suppose they might be part of the "old guard", so would not implement the feature).

Re:This is not accurate

[sajalkayan]

I'm the author of the blogpost and am inclined to reply. David, I don't mean any disrespect to OpenDNS. It is an awesome service and I too myself use it when nothing else works. I don't have anything against OpenDNS. If you for some strange reason want to discredit data from EC2 instances, please see the data from Thai and the Swedish ISP. Both are personal internet connections of people residing in the respective countries from their homes. Now that you have really discredited me, I have to work harder to get data from someone's home connection is US and UK (apparently you dont recognize data from other locations). Thanks, Sajal

Re:This is not accurate

[mother_reincarnated]

Actually this isn't even true- when you initially submit it to the first MTA that connection always was from 'you.' That server would be (in the worst case) the first one that used DNS to the receiving domain. It would also be a host trying to directly connect to the MX.

I can't think of a single protocol this isn't true for, so how would anyone except whomever you choosen as your LDNS provider and parties authoritative for your destination ever be seeing this information?

I know, I'm preaching to the choir, sorry!

Re:This is not accurate

[davidu]

What you're suggesting is really just another way of saying a "Man in the middle" attack. IE, someone in transit can copy, inspect or re-route your packets and do bad stuff. That always exists when using insecure channels, and is a different concern. DNS will never eliminate that concern actually. Even with DNSSEC. End to end dynamic ad-hoc encryption would, but that's a pipe dream. :-)

Re:This is not accurate

[davidu]

I always encourage testing and was actually happy to see you posted your scripts. You can email me at david at opendns dot com if you want to discuss further. I just don't think your testing methodology backs up your rather bold claims.

Re:This is not accurate

[gad_zuki!]

>. Unfortunately the old guard of DNS (Vixie, et al) are not supporting it because they fear it raises insurmountable privacy concerns.

Old guard? You'll find end users are also very much concerned with privacy. Rewriting the DNS spec solely for CDNs is ridiculous. Want location services in web broswer? Add it to http. Let the browser makers figure out the implemention.

Not to mention, there's nothing open about your service. Its simply free. There's nothing open source about it and you openly violate the DNS spec with your typo domain crap. Sorry, the internet doesnt need "open" dns to ruin dns. You've done enough already. Thankfully, google offers free dns at 8.8.8.8.

Re:This is not accurate

[Ash-Fox]

So you want to explain why you hijack google traffic?

So, why exactly couldn't you find this information in their knowledge base again?

Failure to provide a non-"computer illiterate" reason will require you to hand in your geek card.

Re:This is not accurate

[scherrey]

David, how can you say "this is not accurate" when the article simply says that OpenDNS (which I use and am a big advocate of) *may* not return good results, demonstrates circumstances where this is clearly the case and publishes code where people can reproduce the results themselves? I only wish more articles would do such things and be as accurate.

        It's generally true that these are "edge" conditions but the internet is one giant collection of edges once you get outside the USA and a few major countries. I reside in Bangkok presently, travel around SE Asia a good bit and have found circumstances where using OpenDNS make it impossible to get facebook or google mail working. The local DNS servers are often quite unreliable so a service like OpenDNS is a godsend when it works but, having an awareness of the potential problems as noted in the article has saved me hours of headaches when things get pathological on me.

        I'm glad to hear you're getting POPs in Asia - where the majority of internet users reside and is one heckuva huge "edge". I think it also shows to need for improvements to the protocols which can take a lot of time. I continue to use OpenDNS but now as a backup rather than a primary in locations where latency is increased as a result. Believe me I'm grateful to have it.

        I think you owe the author an apology though. He's trying to be fair and accurate as to the potential issues with services like OpenDNS, help people be aware that they are not a panacea, and explan why. I think that's a good thing that should be commended.

    -- Ben Scherrey

Re:This is not accurate

[davidu]

He titled his blog post "In a CDN'd world, OpenDNS is the enemy!" not "Using third-party DNS resolvers can in some cases cause suboptimal server targeting."

I thought my response and followups were fairly even-keeled all things considered but appreciate the feedback. I have no ill will to the author and welcome his further tests.

OpenNIC published server locations...

[pongo000]

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

Re:OpenNIC published server locations...

[BitZtream]

Selecting the close name servers doesn't mean those DNS servers are returning the closest servers for the names you're looking up.

Short of some sort of hijacking or really shitty service you should be using your ISPs name servers. Even on slashdot, its highly unlikely that you really do no more than the admins upstream.

Yes, 15 or 20 slashdot readers do, but the rest of you are just armchair admins who really don't know what your doing regardless of how many forums you've read.

Re:and?

[BrokenHalo]

Great. But what the fuck is a CDN

Wikipedia is your friend, you lazy sod.

It's a race...

[pongo000]

...to see who has the balls to announce to the /. world that they don't know what CDN stands for!

I win!

Re:It's a race...

[0racle]

Canadians slow everything down.

Re:REWARD IS OFFERED

[Anonymous Coward]

i hope she does

already fixed

[uolamer]

"However, as more websites, particularly smaller ones, use content distribution networks via embedded ads, widgets, and other assets..."

Like many people reading this site I block most the crap mention here at a level where the DNS is never resolved.

Latency

[Peach Rings]

You want lower latency, not higher latency. Thanks soulskill.

Re:Latency

[grahammm]

For serving bulk (ie large) or streaming content, which is what CDNs are used for, then latency does not really matter. As long as the TCP window is large enough and there are not too many dropped packets (resulting in re-transmission) then a high latency link can delivery a high throughput. For streaming you also want low jitter (ie a reasonably constant RTT), but this is not related to latency. It is only for interactive connections, such as VOIP, ssh, and gaming, for which CDN are not used, that you need low latency.

Re:Latency

[socsoc]

Thus the point being that the two combined are not as beneficial as one would hope. You misread the headline.

Re:You're a man after my own heart! apk

[LordLimecat]

Neither infected PDFs nor Java rely on javascript. An ad in a DIV will infect you just fine.

going wrong

[DaveGod]

I'm using Open DNS and since yesterday Google keeps offering to translate everything into Dutch (I'm in UK)

Re:Block?

[hedwards]

Because he's using in non-literally. The CDNs don't provide a service to the people that have to put up with them in most cases. It personally pisses me off to have to loosen up so thoroughly on noscript for a website to be even able to figure out if I want to see the content. Worse is that few sites if any actually disclose what sites they allow to connect in that fashion meaning that you don't necessarily know whether a particular site is meant to be loading content. It's just an easy way of them losing your information then not being responsible for the consequences.

Re:Block?

[jon3k]

"The CDNs don't provide a service to the people that have to put up with them in most cases."

I'm going to go out on a limb and say that in "most cases" CDNs do in fact provide a service of providing faster access to content. There are problems, like the one this story points out, but they definitely do provide a useful service.

"...used to bypass the sluggishness..."?

[oDDmON oUT]

I use Google DNS to bypass the interstitial ad results page my ISP pops up with any "incompletely typed" (i.e. I didn't type .com/.net/etc.) or mistyped URL.

Since I rarely if ever click on widgets, ads or other assets, I doubt that any lag time in response would make a material difference to me (nor, I suspect, would it to many others).

Geographically nearby is BS outside America

[DNS-and-BIND]

I love how "geographically aware" applications will happily direct me to Japan or Taiwan when the link from America is far faster. Why the hell should something route me to Japan when I start from Thailand? Or route to Taiwan from China? WTF? I suppose in some people's tiny minds, this makes sense, but in reality the USA link is usually much faster.

Poor applicationn or limits of DNS design?

[Midnight Thunder]

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.

Well depending on the protocol, you could just be redirected to the closest by other means. For example, an http server could redirect to another server by name.

We recently ran into issues of trying to rely on the DNS server for establishing geographic location, when we realised that the DNS server making the address look up could be five servers upstream of the actual client and each of them with their own caching rules.

The real issue, is that DNS lookups aren't expecting to look for a geographic record. If DNS entries could be registered with geographic locations, then the choice could be left up to the client computer on which is the best to choose and then fall back down the of alternative entries when one doesn't respond. The same could be done by the DNS server if the client were to declare its geographic locations to the server, but the former approach reduces privacy issues.

Re:Poor applicationn or limits of DNS design?

[UnderCoverPenguin]

The issue here is actually network hops. Regardless of geographic distance, the fewer hops from router to router from the client to content server is generally better. IF a CDN can put their servers near your ISP's upstream feed point - or, even better, in your ISP's network, then you theoretically get better download performance if you use the ISP's DNS. A 3rd party DNS relay may refer you to CDN server that is more hops away from your client.

I'm a big fan of CDNs...

[Chris Snook]

...but my current ISP redirects all NXDOMAIN results to their ad page, and the only "opt-out" is a browser cookie that turns that page into an error page. At least Verizon offered an alternative DNS server with that misfeature disabled. I can't wait until my one-year contract is up.

Re:I'm a big fan of CDNs...

[xous]

Umm.. How about not using your ISP's DNS servers?

edns-client-subnet

[Anonymous Coward]

http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01

Problem solved.

Re:Blame Canada Alone

[newdsfornerds]

The plural of CDN is CDNs. Forget what your browser's spell checker says; it's wrong. Also, you have asked a question. Why is there no question mark?

Just Askin'

[hduff]

Shouldn't the script begin with
#!/usr/bin/python

and I needed to install dnspython as a dependency.

Re:Block?

[rekoil]

Sure, if you don't mind not being able to access:

- Media from iTunes
- Windows software updates
- Netflix video on demand
- *any* digital media purchased from amazon.com (even DRM-free mp3s)
- Images from flickr
- boston.com's The Big Picture
- Any image I embed in a fark.com comment.

DNS Extension

[Fnord666]

A DNS Extension has been proposed that would allow the authoritative DNS server to see the originating IP address for the query in addition to the intermediate DNS server. This was previously discussed here on slashdot as well.

Re:DNS Extension

[MadMaverick9]

Well - I sincerely hope that this so-called "extension" never happens.

And - why do we need an extension for DNS ?

The website already has the ip address of the requester (cgi var REMOTE_ADDR) and one can then use a service like "http://ipxml.info/myip/?ip=174.151.33.250" to get the location of this ip address.

So can someone please explain to me - why do we need to extend DNS, when with existing protocols and services, we can get someone's location already.

Re:DNS Extension

[lintux]

(Disclaimer: I'm one of the authors of this I-D.)

Because by the time you went through all the steps you're describing here, you lost so much time already that the CDN may as well just serve you their content from the other side of the planet. CDNs are meant to *improve* latency. If two or more HTTP requests are needed to reach the goal, you really just completely miss it.

Also, HTTP caching wouldn't work very well if content gets served from "random" hostnames (because how else would you get the web browser to connect to the right CDN node?).

Remember that this is an EDNS0 option, to be implemented only by parties that need it. It's not intended to become a standard DNS feature.

Re:Block?

[h0dg3s]

You've effectively crippled your browser and you're mad that websites don't load correctly?

Re:Block?

[EsbenMoseHansen]

Actually, I would be fine without any items on that list :)

Though I run my own DNS server. Not sure if that clashes with the CDNs, but I think not.

And

[mahadiga]

I use the following options in /etc/resolv.conf

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 208.67.222.222
option rotate
option timeout:1