Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Encryption Security The Internet Linux News

OpenDNS Releases DNS Encryption Tool 94

Posted by timothy from the do-nothing-secret dept.
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."
This discussion has been archived. No new comments can be posted.

OpenDNS Releases DNS Encryption Tool More

OpenDNS Releases DNS Encryption Tool

Comments Filter:
  • I mean... reverse domain name lookups exist. I guess you'll still need to use an encrypted proxy like TOR?
    (Wait, doesn't TOR encrypt your DNS requests?)

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

        by GameboyRMH ( 1153867 ) <`gameboyrmh' `at' `gmail.com'> on Thursday December 08, 2011 @11:49AM (#38303534) Journal

        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)

        by caluml ( 551744 )

        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)

    by janeuner ( 815461 ) on Thursday December 08, 2011 @10:43AM (#38302724)

    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)

      by Anonymous Coward

      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)

        by Sloppy ( 14984 ) on Thursday December 08, 2011 @12:51PM (#38304344) Homepage Journal

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

        • nah, if that were the case the government wouldn't be able to function. Agencies like the NSA work under the assumption that they have already been compromised. There is plenty that can be done to insure integrity of a network's components even when the network itself has been compromised. That said, it is preferable to avoid such a scenario.

      • Re: (Score:2)

        by Machtyn ( 759119 )
        Could it be the user's router? That is, I'm running dd-wrt (Open-wrt, Tomato, or etc.). Could this tool be installed in the router firmware to provide the last mile protection? Then it is up to the user to provide the last 100 meters by ensuring their networks point to their router for DNS resolution.

        Umm, yeah. What Sloppy said up there ^^

      • Re: (Score:2)

        by EdIII ( 1114411 )

        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

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

  • but isn't SSL protocall independent? wouldn't it make more sense just to do DNS with SSL?

    • SSL is also a much heavier protocol than DNS, as I understand it.

      • Re:SSL is heavy (Score:4, Informative)

        by KXeron ( 2391788 ) <kxeron@nOSpam.digibase.ca> on Thursday December 08, 2011 @11:22AM (#38303092) Homepage

        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.

        • 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

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

        by Zironic ( 1112127 ) on Thursday December 08, 2011 @11:29AM (#38303206)

        Everything is a heavier protocol then DNS. By default DNS queries are plain UDP packets, that way you do not have any handshaking overhead.

    • One word: Diginotar.

    • SSL requires a connection. DNS is (normally) connectionless.

  • Good idea (Score:5, Interesting)

    by ledow ( 319597 ) on Thursday December 08, 2011 @11:04AM (#38302918) Homepage

    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.

    • 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:2)

      by DarkOx ( 621550 )

      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)

        by ledow ( 319597 )

        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.

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

      by makomk ( 752139 )

      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)

    by monkeyhybrid ( 1677192 ) on Thursday December 08, 2011 @11:07AM (#38302948)
    From Wikipedia [wikipedia.org]:-

    If a domain cannot be found, the service redirects users to a search page with search results and advertising unless the user has paid for an upgraded service. Users can switch this off via the OpenDNS Control Panel, or specify another page to use for missing domains. This behavior is similar to that of many large ISPs who also redirect failed requests to their own servers containing advertising.

    OpenDNS started resolving requests to Google.com. Some of the traffic is handled by OpenDNS typo-correcting service which corrects mistyped addresses and redirects keyword addresses to OpenDNS's search page, while the rest is transparently passed through to the intended recipient.

    Also, a user's search request from the address bar of a browser that is configured to use the Google search engine (with a certain parameter configured) may be covertly redirected to a server owned by OpenDNS (which is within the OpenDNS Terms of Service).[24] Users can disable this behavior by logging in to their OpenDNS account and unchecking "OpenDNS proxy" option.

    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)

      by Mojo66 ( 1131579 )
      There are also some privacy concerns, at least for Europeans. From the Privacy Policy:

      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.

    • Bear in mind they offer the service free of charge, and their redirects to their own pages provide OpenDNS with advertising revenue. This is all clearly stated in their TOS. I for one would rather be redirected to an OpenDNS page than to a site offering drive-by trojan infections.

      That said, should OpenDNS's advertising ever be compromised and start distributing malware, that would be a pretty big black eye.

    • Re: (Score:2)

      by kasperd ( 592156 )

      I'm sure they're no worse than other DNS providers

      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.

      they do appear to have options to opt-out of the above behaviour

      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)

    by sgt scrub ( 869860 ) <[saintium] [at] [yahoo.com]> on Thursday December 08, 2011 @11:22AM (#38303084)

    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)

    by aka_bigred ( 1366025 ) on Thursday December 08, 2011 @11:36AM (#38303332)
    So anyone know of a client that can be run from a DD-WRT or Tomato router? I'd be up for throwing it on my home router it there's a client that I can just add right into the router.

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

  • phishing (Score:4, Interesting)

    by Billly Gates ( 198444 ) on Thursday December 08, 2011 @11:40AM (#38303400) Journal

    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

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

    • While I haven't investigated it, I would suspect that Windows' DNS functionality isn't quite so pluggable as it is for the *nix OSs. It may well just be impractical to implement.

  • All your DNS are belong to us (Score:5, Informative)

    by Animats ( 122034 ) on Thursday December 08, 2011 @12:38PM (#38304150) Homepage

    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.

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

        by kasperd ( 592156 )

        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.

        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

  • FTA: "(mac only at the moment)"

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close