OpenDNS Releases DNS Encryption Tool 94
wiredmikey writes "It's not news that some of the underlying foundations of the DNS protocol are inherently weak, especially what they call the "last mile" — or the part of the internet connection between the client and the ISP. To address this, OpenDNS has released a preview of DNSCrypt, a tool that enables encrypted DNS traffic, much in the same way SSL enables encrypted HTTP traffic. DNSCrypt will stop DNS replay, observation, and timing attacks, as well as Man-in-the-Middle attacks and resolver impersonation attacks. The tool, available already compiled for OS X, will also run on OpenBSD, NetBSD, Dragonfly BSD, FreeBSD, and Linux. There is no Windows client, which is odd considering a majority of the 30 million OpenDNS users run Microsoft's operating system."
What? No encrypted IPs? (Score:2)
(Wait, doesn't TOR encrypt your DNS requests?)
Re: (Score:2)
Wait, doesn't TOR encrypt your DNS requests?
No.
I mean... reverse domain name lookups exist.
Assuming the admin wasn't too lazy to set it up. :)
Re:What? No encrypted IPs? (Score:4, Informative)
Wait, doesn't TOR encrypt your DNS requests?
No.
Actually your DNS requests can be encrypted and tunneled through TOR (just point your DNS requests at the SOCKS5 server). However they'll be decrypted at the exit node just like plaintext HTTP traffic.
Re: (Score:2)
Assuming the admin wasn't too lazy to set it up. :)
Assuming that the DNS for the IP address range is delegated to the admin first of all.
It's all very well setting up rDNS, but sometimes, the bureaucratic nightmare to get the range pointed at your DNS server is just not worth it.
Not Odd (Score:5, Insightful)
Because the danger isn't poisoning the cache of an end user. The trouble comes when a site's DNS cache is poisoned, affecting hundreds or thousands of users.
Most of these DNS caches are run on a UNIX derivative.
Re:Not Odd - Well actually ... (Score:3, Informative)
The solution is for the 'last mile', ie. the connection between the end user and the ISP. As such, the encryption software will have to run on the user's machine.
Re:Not Odd - Well actually ... (Score:5, Interesting)
They might be thinking that the "user's machine" could be something like a DSL router, which may already be servicing user's DNS requests with dnsmasq or something like that. There are all sorts of opportunities to improve the functionality of these spots, without really needing to impact the software and protocols run by the actual endpoints. It's not so much the "last mile" that is most vulnerable, but rather, the "last mile except for the last 30 feet." In your LAN itself is compromised, then the intruder is already in the house and you are totally screwed no matter what you do. ;-)
Re: (Score:2)
Re: (Score:2)
Umm, yeah. What Sloppy said up there ^^
Re: (Score:2)
That's the problem.
Most Netgear routers that ship, by default, employ a DNS proxy. Any user machine that uses DHCP will be told the DNS server is 192.168.1.1 and use whatever DNS is defined in the WAN configuration.
Deploying a standard-less DNS encryption is only going to happen in one of two places. The user's machine or a DNS proxy being run on a server.
Routers are out of the question, even high end ones, for the time being without a standard. Even then, it will be a long long long time before firmware
Re: (Score:2)
Because the danger isn't poisoning the cache of an end user. The trouble comes when a site's DNS cache is poisoned, affecting hundreds or thousands of users.
Most of these DNS caches are run on a UNIX derivative.
The problem with Windows clients is that they all believe they should be allowed to update DNS.
Re: (Score:3, Insightful)
Re:Not odd that theres no Windows client (Score:4, Insightful)
Windows users don't give a shit about security, thats why they're running Windows.
YAY GAMES DURR
Linux users don't give a shit about getting work done, that's why they're running Linux.
YAY SPENDING FIFTY HOURS TWEAKING MY WINDOWING ENVIRONMENT DURR
Oh, what, that's flamebait, but apparently your comment is "Interesting"? Grow the fuck up. Windows is a hell of a lot more secure than it used to be, Linux and BSD have had their share of vulns as well, and the big threat stopped being the OS a long time ago, it's now shit like Adobe Reader. Oh, wait, this is Slashdot... I should be expecting a BSOD joke, followed by a Clippy joke, followed by a Microsoft Bob joke, because those are all about as topical...
Re: (Score:1)
Wait.
Are you saying that you do not think that Clippy and Bob are funny?
Re: (Score:2)
Re: (Score:2)
Linux users don't give a shit about a desktop, that's why they're running Linux
YAY HEADLESS SERVERS DURR
You know..... I have to laugh.
Linux users apparently done't give a shit about a nice desktop and user friendliness. I say that..... because... it is neither good looking, highly functional, or user friendly.
I just plain *enjoy* a Windows 7 desktop experience more than any Linux GUI. Just the truth. I even enjoy Mac OS X more than Windows as far as visual aesthetics are concerned.
The funny part is the headless servers. I run a *ton* of headless CentOS servers. I can honestly say that for what needs to b
Re: (Score:1, Insightful)
For me the important point isn't to hide addresses that are being looked up, but to determine the credibility and integrity of the response I receive. Encryption is about more than just hiding data.
Regarding the name, I'm not sure what you're complaining about. Where is it written that any entity that prefixes their name with "Open" needs to be an open source project. They are free to use.. If you want to pick on a misleading name, try NetZero...
Re: (Score:1)
Re: (Score:1)
Indeed... I switched to GoogleDNS from OpenDNS a while after it came out. I figure Google already knows everything about me they're likely to find out from DNS data.
Re: (Score:2)
Hiding the domain name may help protecting against censorship. There are places where DNS requests are censored. Even if the packets are integrity protected, it doesn't stop an ISP from just dropping every lookup or response for domain names they want to censor.
Re: (Score:1)
Re: (Score:2)
Not all uses of the word "Open" need to abide by your one definition of the word.
Re: (Score:1)
Not all uses of the word "Open" need to abide by your one definition of the word.
Yes they do. Just like how "pirate", "steal", and "take" each have exactly one definition that can never ever ever never ever ever ever be changed ever, and that definition is whatever is most convenient for my illegal movie downloading rationalization.
(now, watch as someone deliberately misinterprets that as "downloading illegal movies" just to distract from my point)
Re: (Score:2)
OpenDNS is called OpenDNS because they provide and open recursor service.
Maybe I'm dense (Score:1)
but isn't SSL protocall independent? wouldn't it make more sense just to do DNS with SSL?
SSL is heavy (Score:1)
Re:SSL is heavy (Score:4, Informative)
This is correct, SSL induces significant overhead both bandwidth and CPU-wise. While most CPUs can handle an SSL website connection that is because the SSL handshake is done every so often (at the beginning of each resource download). However implementing it in a "fast acting" protocol like DNS is guaranteed to slow the protocol down, ergo clients will have to wait non-trivial time before they even connect to the resource in question.
This doesn't even account for the DNS resolver's resource usage, given an average resolver's query load, the additional stress needed to do SSL for each query would be operationally unacceptable and having persistant connections hanging open for an ISP-load of users would not be an option either as the servers' open file descriptors would get exhausted.
Re: (Score:1)
How many unique DNS requests leave your network in a 1 hour period? My guess is: fewer than 60, unless you're a search engine or security firm. Even running torrents with DNS resolution won't go much beyond this. How many SSL handshakes are performed in that period? I'd guess hundreds.
Think about it this way: web browsers these days tend to proactively resolve domains. Since most network activity uses a web browser or a fixed domain (email, etc.), the usage should be minimal (except for p2p, where it'l
Re: (Score:1)
This is correct, SSL induces significant overhead both bandwidth and CPU-wise. While most CPUs can handle an SSL website connection that is because the SSL handshake is done every so often (at the beginning of each resource download). However implementing it in a "fast acting" protocol like DNS is guaranteed to slow the protocol down, ergo clients will have to wait non-trivial time before they even connect to the resource in question.
SSL's overhead is in the handshake: in this scenario, the client would only handshake once, on its first DNS request to its upstream resolver.
Your other concerns could be taken care of by DTLS [wikipedia.org].
This doesn't even account for the DNS resolver's resource usage, given an average resolver's query load, the additional stress needed to do SSL for each query would be operationally unacceptable and having persistant connections hanging open for an ISP-load of users would not be an option either as the servers' open file descriptors would get exhausted.
First of all, under no circumstances do you throw AOL's user base at a single server, no matter the service.
Apart from that, Linux can handle millions of open file descriptors (up to 1million/process by default) nowadays, the bottleneck is elsewhere.
In any case though, DNS is mostly stateless and uses UDP by defaul
Re:SSL is heavy (Score:4, Informative)
Everything is a heavier protocol then DNS. By default DNS queries are plain UDP packets, that way you do not have any handshaking overhead.
Re: (Score:3)
One word: Diginotar.
Re: (Score:2)
SSL requires a connection. DNS is (normally) connectionless.
Re: (Score:2)
DNSSEC is probably going to change that anyway.
Re: (Score:2)
Have you checked ? it really isn't that bad. Yes, it happends slightly more frequently.
I wouldn't be surprised if the use of tunnels because of IPv6 has a bigger impact.
Here is a plot for the DNSSEC signing of the root:
https://www.dns-oarc.net/files/blog-2009/plot1.png [dns-oarc.net]
https://www.dns-oarc.net/node/199 [dns-oarc.net]
Most of it is misconfigured servers.
Good idea (Score:5, Interesting)
It's a good idea but:
- It's the equivalent of every DNS server letting you wrap your queries inside SSL. Nothing really special of clever, and requires the co-operation of all your upstream DNS servers.
- It uses elliptic curve rather than some pluggable system to negotiate an encryption method. EC *hasn't* had anywhere near the deployment hours that conventional PKE has had. It's still, to me, a "unknown" in terms of how breakable it is compared to anything else. No doubt effort is put into it but PKE has decades of attacks in its favour and still holds. Why couldn't the encryption just be negotiable?
- The extra burden - hell, DNS responses can hang computers up as it is if upstream servers are slow. God knows what converting every one of their requests to use ECC would do to servers and clients.
That said, in principle, it's something I'd deploy. If it wasn't barely tested, using EC (and having that be non-negotiable) and having hardly any upstream providers support it.
But it's the equivalent of just SSH'ing into a machine that does your DNS lookups for you, really, just that that machine happens to be your upstream resolver. That then has to communicate to either a DNSCurve server again for the actual lookup (and that server to another, and that to another, etc. etc.) or talk to uncertified nameservers in plaintext as usual anyway.
Personally, I have bigger problems than someone with packet-level access to my traffic potentially seeing what DNS records I lookup.
Re: (Score:2)
Elliptic Curve encryption is what the NSA uses and pushes. PKE is definitely breakable--its really a question of when. That is to say, if it has not already been broken by a government or inteligence agency. No one is going to announce that they have cracked factoring large numbers into prime numbers quickly when they do.
Re: (Score:1)
To clarify: This is designed to secure your connection between your laptop over wifi to your DNS server -- that server being an OpenDNS server, which just happens to support this already. If you have your laptop hardwired to use an OpenDNS IP for DNS resolution and enter a Starbucks, someone else on the public network can't mess with the results of your queries, as they're already encrypted all the way to the first DNS hop. After that, it's not as much of an issue (assuming you actually TRUST the person h
Re: (Score:2)
Why couldn't the encryption just be negotiable?
You ask whey encryption can't be negotiated and then answered your own question in your very next bullet point. DNS performance is EVERYTHING for a great many network applications. So having some handshake like IKE where the two sides negotiate adds at least three round trips before you can get to the actual query. That alone could add up to 500ms or more for many clients. So for an app that needs to do lots of DNS requests that means beaucoup wall time for end users.
Re: (Score:2)
First packet, with query, sends a list of the accepted formats.
DNS server replies with answer, encrypted in one of them, and the name of the format it replied in, or an error because it didn't know any suitable ones.
No "round trips" above and beyond a normal DNS request except where the two don't want to talk the same language anyway.
Re: (Score:2)
...That said, in principle, it's something I'd deploy. If it wasn't barely tested, using EC (and having that be non-negotiable) and having hardly any upstream providers support it.
Why do you think they're only releasing it to minority markets at the moment? We could take the current stereotypes of the sorts of users who run the systems mentioned and do an analysis of which part of the client each is a good test bed for, but applying heuristics would probably be seen as an invitation for flaming. Other users can fill in the thread if they think it's a worthwhile discussion.
Re: (Score:2)
It uses elliptic curve rather than some pluggable system to negotiate an encryption method. EC *hasn't* had anywhere near the deployment hours that conventional PKE has had. It's still, to me, a "unknown" in terms of how breakable it is compared to anything else.
It's not just EC, it's also using an elliptic curve that's not one of the widely-used ones and an implementation that probably hasn't received much scrutiny.
Only OpenDNS can tamper with your results now! (Score:5, Insightful)
I'm sure they're no worse than other DNS providers and at least they do appear to have options to opt-out of the above behaviour, but if your DNS provider is fooling with your encrypted DNS requests, what's the point?
Re: (Score:2)
When you use OpenDNS services, OpenDNS stores certain DNS, IP address and related information about you to improve the quality of our service, to provide you with OpenDNS services and for internal business and analysis purposes.
Re: (Score:2)
That said, should OpenDNS's advertising ever be compromised and start distributing malware, that would be a pretty big black eye.
Re: (Score:1)
And they keep VERY good records for anybody who asks.. nicely.. in triplicate..
Re: (Score:2)
They are not the worst. But I'd still say OpenDNS is doing stuff that is worse than what users should put up with. Personally I would have been using Google DNS, if it wasn't because of lack of IPv6 support.
First of all something like this should be opt-in, not opt-out. Secondly, the DNS protocol doesn't even allow for users to configure this. The only way it could be made configurable by the en
If you have a decent ISP (Score:3)
DNSCrypt will stop DNS replay, observation, and timing attacks, as well as Man-in-the-Middle attacks and resolver impersonation attacks.
This will be great for people that don't have ISPs actively redirecting DNS traffic to their specific servers so they can sniff it, Warner, Comcast et el.
DD-WRT / Tomato client? (Score:3, Interesting)
so what will this achieve for the enduser? (Score:2)
i believe this tool hides the dns query from being logged by the isp.
However I'm unsure if that helps the enduser that much.
If i was to ask for say piratebay.org it will send back the ip address without my ISP knowing i have the piratebay.org ip address from opendns but then the next step would be to request a page from that ip and wouldn't that be logged or blocked by the ISP?
Can someone with a clue clarify the matter?
Re:so what will this achieve for the enduser? (Score:4, Interesting)
The purpose isn't to hide your DNS requests from your ISP, its to prevent some of the known attacks that spoof a DNS reply. That's easy to do if they are sent in the clear and have no signatures.
phishing (Score:4, Interesting)
OpenDNS does have an appeal. However it is such a high target for malware writters. If you can poison it you get tons of bussiness andeCommerce bank logins who go out of there way to use openDNS for security. I am nervous switching to it. Especially after CA keeo getting hacked into
Lack of window client doesn't seem too odd to me.. (Score:1)
There is no Windows client, which is odd considering a majority of the 30 million OpenDNS users run Microsoft's operating system.
I would assume they want a public test with less than 30 million users for now. :)
Re: (Score:2)
Re: (Score:1)
All your DNS are belong to us (Score:5, Informative)
This is a bad idea, and it's being deceptively promoted. The OpenDNS site says [opendns.com] "DNSCrypt is a piece of lightweight software that everyone should use to boost online privacy and security." This is willfully misleading.
This isn't a way to make the existing distributed DNS infrastructure more secure. It just establishes an encrypted connection between your machine and one central DNS server farm belonging to OpenDNS. One that makes its money by redirecting nonexistent domains to ad sites.
There have been slimy DNS providers before. Comcast is notorious [dslreports.com] for this. The Wikipedia article on OpenDNS [wikipedia.org] summarizes the privacy issues, conflicts, and problems with OpenDNS. At one point, OpenDNS tried redirecting address bar searches to their own search page. [labnol.org], which is apparently permitted by their terms of service.
OpenDNS isn't that bad. They're only a little evil. But they're also unnecessary.
Re: (Score:2)
It's true that this is last-mile security only. It protects against someone impersonating OpenDNS and that's it. It makes their service more secure.
OpenDNS's resolvers could still be fooled by poisoning attacks and you'd be just as screwed. They could argue that they have all kinds of proprietary secret sauce on their resolvers, along with DNSSEC where applicable, to prevent that from happening, but we can leave that aside for now.
The thing is, both ISPs and attackers-who-p0wn-routers have good reason to in
Re: (Score:2)
What they should have done is include DNSSEC in the client and make that client open source such that it can be verified that it does indeed validate the lookups. That way OpenDNS would not be able to mess with the lookups, that protects against manipulation with the results both by OpenDNS and by attackers who can e
Re: (Score:2)
Don't get too excited yet... (Score:2)
FTA: "(mac only at the moment)"