What are you talking about? You might not have like the ads, but we never lied about anything. Our service was super clear about how it worked. And for those who didn't like the redirection, it has always been possible to create an account and disable that part of the service.
We have been building a data privacy and data usage policy document that we plan to release soon.
One of the many, many reasons to turn off ads is that we had to share some potentially personally identifiable information with ad partners (indirectly when making ad requests, they would just see it in the ad request), so by turning off ads, our privacy / data policy will be a lot more clear and will not need to have weird "certain third parties for certain services" kind of language to address the advertising business.
We're waiting to turn off ads, we'll get the document cleaned up, and we'll publish it.
We wouldn't make such a case for turning off ads if this was our business model going forward. You could visit our site and see how we make money. We sell security services. We never could have done it without first being a consumer service, but we're not selling your data. Come on.
Nope. Never. We've never sold our data. We've never even used it for marketing purposes internally.
We've only ever made money from one of three things: Ads, selling individuals an ad-free version, and enterprise security services.
Today, most all of our revenue, and all of our growth, comes from selling enterprise security. If you work in IT, it's worth checking out to improve your security posture. There's a lot more to it than you might guess.
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.
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.
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.:-)
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.
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.
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.:-(
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.
I run OpenDNS and we have about 12,000,000 end users. A large number of those are comcast users. We would know if this was true, and we haven't had a single report about it.
I also know a few/really smart/ people in the Comcast engineering department who run their DNS infrastructure. These guys wouldn't do something like block port 53.
Based on the above, there is no truth to this rumor from what I can tell and from those I've talked to. I think an update on this story is warranted.
The comcast engineering team pride themselves on running a great network and robust infrastructure and I think they do a pretty good job (though of course I'm biased and think OpenDNS does a better job on the DNS side of the house):-)
I'm the founder of OpenDNS. I've decided to reply even though these comments are heinously wrong, and probably just me feeding the trolls...
We have never sold user data, ever. We also have no CDN bills, we don't even use a CDN. We've built a global BGP-speaking network with hundreds of peers around the world. I know, because I built it. We peer at LoNAP, LINX, PAIX, SeattleIX and on a few of the Equinix peering fabrics around the US.
The idea that we would build our business based on monitoring user data is preposterous. I wouldn't stand for it, nor would our employees. I'm confident that all our engineers are just as vocal or more vocal about doing the right thing than you are. We make it very clear how we make money, and it's all over our website. Go to http://guide.opendns.com and do a search. The sponsored results are ads where we get paid, the organic results are regular search results. That's how we make money. We might offer an enterprise for-pay service down the road as some of our customers begin to demand tighter integration with their network but for now, we're happy with our business. And I'm happy to report that we're profitable and stable, even in this economy.
And as to the OpenDNS proxy. It's true, we do redirect certain Google requests through a proxy so that we can make our OpenDNS shortcuts and some other features work more reliably. Two important things here: First, we peer with Google at every datacenter, so we aren't adding to your latency or anything else. Second, we don't log and store any data and we certainly don't care about it. We prefer to be able to confidently say we aren't keeping data on it. Of course, you are welcome to disable it by going into your settings and disabling the OpenDNS proxy. That's it. Do that and we don't ever see the request. Pretty easy. End of story.
We're working on providing a FULL API to EveryDNS. Slowly, but surely. I've got new folks on board taking over the site to make it finally be the awesome beast it should be. And it'll still be free.
I'm also trying to figure out a way to tie this into Pingdom's API since a lot of people already use that for monitoring.:-)
Slashdot Mirror
I'd like you to at least give us a chance. I am still running the ship here.
I was here before it was Slashdot...
What are you talking about? You might not have like the ads, but we never lied about anything. Our service was super clear about how it worked. And for those who didn't like the redirection, it has always been possible to create an account and disable that part of the service.
We have been building a data privacy and data usage policy document that we plan to release soon.
One of the many, many reasons to turn off ads is that we had to share some potentially personally identifiable information with ad partners (indirectly when making ad requests, they would just see it in the ad request), so by turning off ads, our privacy / data policy will be a lot more clear and will not need to have weird "certain third parties for certain services" kind of language to address the advertising business.
We're waiting to turn off ads, we'll get the document cleaned up, and we'll publish it.
-David
Nope. Never.
We wouldn't make such a case for turning off ads if this was our business model going forward. You could visit our site and see how we make money. We sell security services. We never could have done it without first being a consumer service, but we're not selling your data. Come on.
-David
Nope. Never. We've never sold our data. We've never even used it for marketing purposes internally.
We've only ever made money from one of three things: Ads, selling individuals an ad-free version, and enterprise security services.
Today, most all of our revenue, and all of our growth, comes from selling enterprise security. If you work in IT, it's worth checking out to improve your security posture. There's a lot more to it than you might guess.
-David
As long as my UID still exists and shows up... I'm all good with the changes. :-)
Yeah, it's pretty low.
I guess this is an appropriate post for me to comment in. Nice work Slashdot, still going strong.
Happy to answer questions about this work.
Really the only thing you can be reasonably certain about with a UID pissing contest is that you'll pretty much inevitably lose. :-)
If it were a competition that mattered, I feel like I could compete. :-)
You guys provided the platform which educated, informed and helped shape my views on technology and the Internet.
:-)
Thanks for all the fish.
-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.
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.
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. :-)
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.
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.
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.
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. :-(
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
This would have been a good one for me to get a "first post" on... do people even do that here any more? :-)
-David
I run OpenDNS and we have about 12,000,000 end users. A large number of those are comcast users. We would know if this was true, and we haven't had a single report about it.
I also know a few /really smart/ people in the Comcast engineering department who run their DNS infrastructure. These guys wouldn't do something like block port 53.
Based on the above, there is no truth to this rumor from what I can tell and from those I've talked to. I think an update on this story is warranted.
The comcast engineering team pride themselves on running a great network and robust infrastructure and I think they do a pretty good job (though of course I'm biased and think OpenDNS does a better job on the DNS side of the house) :-)
-David
I'm the founder of OpenDNS. I've decided to reply even though these comments are heinously wrong, and probably just me feeding the trolls...
We have never sold user data, ever. We also have no CDN bills, we don't even use a CDN. We've built a global BGP-speaking network with hundreds of peers around the world. I know, because I built it. We peer at LoNAP, LINX, PAIX, SeattleIX and on a few of the Equinix peering fabrics around the US.
The idea that we would build our business based on monitoring user data is preposterous. I wouldn't stand for it, nor would our employees. I'm confident that all our engineers are just as vocal or more vocal about doing the right thing than you are. We make it very clear how we make money, and it's all over our website. Go to http://guide.opendns.com and do a search. The sponsored results are ads where we get paid, the organic results are regular search results. That's how we make money. We might offer an enterprise for-pay service down the road as some of our customers begin to demand tighter integration with their network but for now, we're happy with our business. And I'm happy to report that we're profitable and stable, even in this economy.
And as to the OpenDNS proxy. It's true, we do redirect certain Google requests through a proxy so that we can make our OpenDNS shortcuts and some other features work more reliably. Two important things here: First, we peer with Google at every datacenter, so we aren't adding to your latency or anything else. Second, we don't log and store any data and we certainly don't care about it. We prefer to be able to confidently say we aren't keeping data on it. Of course, you are welcome to disable it by going into your settings and disabling the OpenDNS proxy. That's it. Do that and we don't ever see the request. Pretty easy. End of story.
David Ulevitch
Founder, OpenDNS
Well that obviously makes a lot of sense. :-)
Thanks for letting me know.
-davidu
I wrote:
-davidu