I'm the founder of OpenDNS. This article is not accurate. We are blocked by Sprint Wireless, not Verizon Wireless. You can't change your DNS easily when using the Verizon Wireless 3G network's provided hardware, but if you are using your device in tethering mode or a USB-connected fashion, you certainly can use whatever DNS service you want.
How did this happen? We have, in the past, been blocked by Verizon Wireless, either deliberately or due to technical issues, but it is not the case today. I've been a VW customer for a few years, and it's a great service. And today, Verizon FIOS service requires the user to have CPE that doesn't allow the user to change their DNS (same with ATT U-Verse). Sprint Wireless blocks us today, and always has.
In my phone interview, done too hastily or speaking too quickly, I misspoke when speaking about Verizon FIOS and Sprint Wireless as examples of how our customers aren't able to use our service and mixed up the companies. That or the reporter misheard. Either way, this is a good reminder of why it's always better to do email-based interviews. The reporter in this case is a very good one whom I've worked with in the past, so I'm confident the error was mine. In fact, most of the post (it's a Q&A) doesn't really capture the entirety of our discussion, which is unfortunate. My actual sentiments are far less anti-ISP and pro-Google than I think they came out. (repeat, I really dislike phone interviews)
It's unfortunate that I wasn't able to correct the story earlier, though we did work to get the original Washington Post blog updated right after it posted (and it was corrected). Other sites didn't quite seem to pick up the update. I've been trying to update other blogs where I can because it's not fair for VW to be painted in this light. It should have been Sprint Wireless. Some folks on my staff have also worked with Verizon Wireless to make sure that they are not blocking us, and I thank them for their efforts.
And today, Verizon FIOS service requires the user to have CPE that doesn't allow the user to change their DNS
I'm hesitant to publicly disagree with the founder of OpenDNS, but I have a different experience. FiOS doesn't require the use of their provided CPE for Internet access. The ONTs installed have both Ethernet and MoCA ports, and I use a non-Verizon device connected to the ONT's Ethernet. Using a non-MoCA CPE will break Verizon's television boxes, but the fix for this is to simply plug Verizon's supplied CPE into both an Ethernet port on the replacement and the shared coax segment.
I think this is right and what we've heard from users is right. It's actually the same complaint from Uverse customers -- swapping out the ISP-provided CPE breaks their TV service.
It seems you've got a work-around. We'd love to update our knowledge base with this. I can't find contact info on your user page, can you email me david at opendns dot com as I have a few more questions.
DNS redirection (and the monetization thereof) is kind of a moot point in the mid/long term in light of DNSSEC.
Consider the example of comcast, an ISP that uses opt-out DNS redirection advertising, but has been forced to give up the practice for its DNSSEC resolvers:
* We believe that the web error redirection function of Comcast Domain Helper is technically incompatible with DNSSEC.
* Comcast has always known this and plans to turn off such redirection when DNSSEC is fully implemented.
* The production network DNSSEC servers do not have Comcast Domain Helper's DNS redirect functionality enabled.
I don't think this matters as much as you think it does for two reasons.
First, the relationship your computer has with the DNS is as a "stub resolver", meaning that you rely on real DNS resolver hosted somewhere else to do the walk from the roots to the leaf names. DNSSEC doesn't protect (or, more appropriately, disrupt) stub resolution (a different protocol, TSIG, does this instead). If Comcast operates the real resolver and all you do is aim your computer at it, you have little opportunity to "disagree" with the results they feed you.
Secondly, regardless of how much noise people may be making about DNSSEC's impending deployment (and it's been impending about as long as IPv6), the prospects for widespread DNSSEC adoption aren't great. It solves very few problems, is a bear to administer, and creates operational problems. Most of the Internet is (thankfully) oblivious to its attempted deployment.
You really think resolvers are going to be willing to forge the AD (authenticated data) bit when the data isn't authenticated? Even when it's so easy for a client or downstream caching only server to be set to validating and thus discover the forgery? Once you've determined that your server is willing to forge AD surely you'd have no reason to trust any other response it gives.
DNSSEC deployment seems to be going rather well to me, compared to a year ago the root servers are signing, several major TLD's are signed, and common registrars support signed zones in those TLDs. Individual zone signing really isn't that difficult, and besides, almost everyone uses third party DNS hosting. Once a few major DNS hosters start signing zones by default you'll see adoption skyrocketing, don't you think?
No. tptacek is entirely correct. DNSSEC won't help here.
DNSSEC is not exposed to applications the way SSL is and so you will never see widespread adoption.
Take Chrome for example. Chrome is in the best position to make use of DNSSEC since it does it's own resolving, and even they don't see the value in it. They may do it in the background, but they won't make it user visible any time soon. Reasons from Chrome devs are very well articulated here: http://code.google.com/p/chromium/issues/detail?id=50874
That said, I do believe that stub resolvers will go away, with every client running a full-blown recursor, but that still won't make DNSSEC solve the problems that need solving.
It would seem relevant to note that your company openDNS has publicly promoted and rolled out DNSCurve, a non-IETF track set of extensions to DNS intended to compete with DNSSEC.
DNSCurve makes no attempt to authenticate the source of the DNS data and instead relies on only securing the connection between the the client and server (or server and server). In this way, DNSCurve does not prevent a service provider like openDNS from replacing NXDOMAIN returns with their own sponsored pages.
DNSSEC instead aims to "protect DNS content from third party modification" which would include third parties like openDNS. Performing this modification is the basis of DNS redirection. OpenDNS's strong complaints about DNSSEC and adoption of an obscure replacement (DNSCurve - About 6,620 results; DNSSEC - About 6,730,000 results) would seem to confirm my original suggestion much better than I can do myself.
Paul Vixie on the matter:
The problem statement for DNSSEC was: "how can we protect DNS content from third party modification?" The first parties in this case are the the zone administrator who produces the primary zone content and the ultimate end user or application who consumes that content. Third parties include Dan Kaminsky or anyone else who might bombard a client with spoofed replies attempting to guess transaction ID's and port numbers; secondary name server operators or hackers who break into those systems; recursive name server operators who may want to rewrite www.google.com to their own search page or to rewrite negative responses to point to their own advertising servers; firewall and IDS operators who might want to rewrite all answers containing profanity or pornography or other illicit content to point at a walled garden. From DNSSEC's point of view, only the zone administrator should be able to produce content within the namespace of a zone. There are no exceptions.
I think it's worth pointing out here that DNScurve isn't some crazy OpenDNS standard; it's a research proposal from Daniel J. Bernstein, author of djbdns, the only nameserver that survived the 2000's without a terrible security flaw.
I don't know or care why OpenDNS pushed for DNScurve adoption (I don't use or approve of OpenDNS; I think its performance benefits are apocryphal and that its NXDOMAIN interception breaks the Internet in more pernicious ways than any Verizon filter). But I do object to the subtext that DNScurve --- or critiques of the vast, unruly briar patch of DNSSEC standards --- must have ulterior motives.
And as someone who cares about (but does not always live up to) the debate standards of Hacker News, I object to the way you responded to a factual correction by kicking up dust about motives. It was wrong for you to imply that DNSSEC was going to be a serious technical hurdle to NXDOMAIN interception.
I strongly disagree with the notion that only the zone owner should be able to generate records for it. Nothing else on the Internet behaves like that.
He may disagree with the NXDOMAIN wildcard that we do (which we will probably phase out in the long run anyways) but there is no question that allowing end-users to control their responses as they see fit makes tremendous sense.
Do you think you should have to receive all email sent to your mail server? Of course not.
Why should DNS be any different? Your network, your rules.
I'm confused as to why you claim DNSSEC removes user choice.
Clearly any client that wishes to can simply fail to set DO and ED and will receive a traditional, non-validated response.
If the client identifies that they wish authenticated data, they still have plenty of opportunities to act once they receive the authentic zone response. You mention mail host blacklisting, but typical DNS based blacklists have always been based on secondary lookups ie - 1.2.3.4.dnsbl.example.com - and not by forging the originator domain records.
I'm returning signed content from my server to an end user, whether I am a root server, tld, or single domain server. There is no more reason you should have the authority to alter that data than there would be if I was returning an HTTPS response.
It's only in the case where the client explicitly asks you to provide authenticated original zone data but you wish to return to them unauthenticated and modified zone data that you run into problems with DNSSEC.
Actually, you are not returning signed content from your server to an end user. End users are stub resolvers, which are not DNSSEC aware.
I believe that should change, as I mentioned previously, but even the DNSSEC proponents pretend to assume the edge is DNSSEC-aware. It most certainly was and is not from their design and implementation stand-point. A position I find ridiculous.
But back to your point -- Of course, we could support DNSSEC and validate responses and then modify them as we see fit. Which is exactly why DNSSEC does not prevent our service from working. We already have some of the largest companies in the world forwarding DNS to us, when we enable DNSSEC validation for them, nothing will change. FWIW, none of them have us wildcard NXDOMAIN responses either, which is not surprising. They do have us block content, however. Some of these are Fortune 50 companies, btw.
By being one of the first commercial ISPs with a user facing DNSSEC deployment. The issue of DNS redirection being incompatible with DNSSEC is a technical one, here comcast is just an early report of the fact that they will cease all DNS redirection once DNSSEC resolvers are the default solution. Verizon and openDNS both will be in the same boat once client resolvers demand signed zones.
It's no different than hearing about the results of a new RFC from google even if you use bing for search.
I don't think that DNSSEC is going to be a sufficient hurdle:
"When you first set up your Acme Internet Services account, you will need to set up your domain name servers correctly. This is a two step process which requires setting up your computer to use our DNS servers, and adding our security key as authorised on your computer".
Most Internet users believe everything that their ISPs tell them about what is necessary to use their service, especially when it doesn't work until they do it, so getting users to add a new authorised root DNSSEC key is not going to be an impossible hurdle.
That's certainly possible, but I'd be surprised if it came to pass. Anyone who stopped by your house and used your wifi would need to take on your ISP keys, your DVD player would need to be able to accept them, etc. At this point the ad revenue wouldn't seem to make up for the bad user experience.
It would be similar to an ISP requiring you to trust their root CA so they could MITM your SSL sessions. Sure, some enterprises do this through their management systems, but a big ISP that required this would likely get hit by a large amount of negative reactions.
Whoa, will DNSSEC prevent all DNS-level hijacking? OpenDNS has a DNS-level blacklist option (totally opt-in) which redirects to their own servers. Will that still be possible with DNSSEC?
As this amounts to A record forgery, yes DNSSEC clients will prevent this. There is really no technical difference between this practice and the poisoning that DNSSEC is defined to defeat.
Of course there are plenty of other ways to blacklist or redirect IPs - using routes, RBL subscriptions in software firewalls or through browsers like the google safe browsing subscriptions. DNSSEC won't be the place to do it, though.
OpenDNS has a whole bunch of other opt-out (per IP) features that depend on DNS-level hijacking.
By default they point NXDOMAIN to their own landing page, blacklist 'known phishing sites', and proxy some Google requests through their own servers to defeat clever browser address bars.
If an "important" ISP starts blocking outbound port 53, then people will just do their DNS lookups over HTTPS or whatever. This is irrelevant today because nobody is censoring DNS yet. Combine documented DNS censorship with documented blocking-of-port-53, and the problem will be fixed in hours.
(Funny story; my work laptop has some software installed that only allows ssh connections to be made when connected to the VPN. But when connected to the VPN, there are no routes to the Internet, so I can't check my email while traveling with my work laptop. Change my sshd to bind port 443 in addition to 22, though, and ... the restriction is gone.
Censoring the Internet is hard, even when you control the network or client machine!)
True, but each restriction just makes it that much harder to get around. For the majority of people, the first block will stop them, but once you get into cat-and-mouse land, you'll lose a bunch more.
Most IPSs think that DNS is an afterthought, to be stuffed in an old box and forgotten. Typical scenario: wait for a request, deny that request, then cache and honor the request the second time round.
Is that why sometimes I open a webpage and it gets stuck loading with the status bar displaying "Looking up example.com..."? If I reload the page it then loads immediately. I've been thinking that it has something to do with the cache, but why on earth would they deny the first request?
I'd like to put in a good word for openDNS. I've used them for several years and have always found David Ulevitch and the company to be friendly, helpful, and reliable.
Seconded. It's faster than my own ISP's DNS. (Damn you, Speakeasy! shakes fist) If you want to test for yourself, ping 208.67.222.222 (one of OpenDNS' anycast DNS IPs). If it's faster than your ISP's, you should try switching.
I would not like to see ISPs block alternative DNS services.
I use OpenDNS to block distracting sites, and alias
http://block.opendns.com to localhost, which is then
redirected to my to-do list. A web server on my machine
redirects the default page at localhost to my to-do
list on http://rememberthemilk.com.
In addition, my /etc/hosts file includes the hosts file
from http://www.mvps.org/winhelp2002/, which aliases
ad and tracker site domains to localhost.
Ad blockers suppress ads, but do not provide positive reinforcement. Site blocking software systems filter unwanted content, but do not substitute desired content in its place. It's not enough to slap the user's hand.
The domain name filtering service OpenDNS displays a block
page at http://block.opendns.com if a site meets the criteria for filtering. This is negative reinforcement. OpenDNS might provide positive reinforcement if users could to substitute something else, for example, an online to-do list such as http://rememberthemilk.com, for the block page.
How did this happen? We have, in the past, been blocked by Verizon Wireless, either deliberately or due to technical issues, but it is not the case today. I've been a VW customer for a few years, and it's a great service. And today, Verizon FIOS service requires the user to have CPE that doesn't allow the user to change their DNS (same with ATT U-Verse). Sprint Wireless blocks us today, and always has.
In my phone interview, done too hastily or speaking too quickly, I misspoke when speaking about Verizon FIOS and Sprint Wireless as examples of how our customers aren't able to use our service and mixed up the companies. That or the reporter misheard. Either way, this is a good reminder of why it's always better to do email-based interviews. The reporter in this case is a very good one whom I've worked with in the past, so I'm confident the error was mine. In fact, most of the post (it's a Q&A) doesn't really capture the entirety of our discussion, which is unfortunate. My actual sentiments are far less anti-ISP and pro-Google than I think they came out. (repeat, I really dislike phone interviews)
It's unfortunate that I wasn't able to correct the story earlier, though we did work to get the original Washington Post blog updated right after it posted (and it was corrected). Other sites didn't quite seem to pick up the update. I've been trying to update other blogs where I can because it's not fair for VW to be painted in this light. It should have been Sprint Wireless. Some folks on my staff have also worked with Verizon Wireless to make sure that they are not blocking us, and I thank them for their efforts.