Using CloudNS For DNS Resolution – Integrity, Authenticity, Confidentiality

CloudNS is a DNS host that supports a few cool security features. I’ve set it up, and it’s working for me on Linux Ubuntu 13.04. I think its security features give it the potential to be the preferred choice for those looking for that higher level of security and privacy.

* DNSCrypt Support
We only allow connections to our service using DNSCrypt, this 
provides confidentially and message integrity to our DNS 
resolver, and makes it harder for an adversery watching the 
traffic of our resolver to identify the origin of a DNS query as
all the traffic is mixed together.

* DNSSEC Validation
Our server does complete trust validation of DNSSEC enabled 
names, protecting you from upstream dns poisoning attacks or 
other DNS tampering.

* Namecoin resolution
Namecoin is an alternative, decentralized DNS system, that is 
able to prevent domain name censorship. Our DNS server does local
namecoin resolution of .bit domain names making it an easy way to
start exploring namecoin websites.

* Hosted in Australia
Our DNS Server is hosted in Australia, making it a faster 
alternative to other open public DNS resolvers for Australian 

* No domain manipulation or logging
We will not tamper with any domain queries, unlike some 
public providers who hijack domain resolution for domains that
fail to resolve. Our servers do not log any data from connecting 
users including DNS queries and IP addresses that make 

I think those are some really interesting features. For one thing, it forces DNSCrypt and validates with DNSSEC, and it appears to be the only resolver to do both of these things. And it’s also hosted outside of the US, which has its own implications for security.

So I went ahead and set up CloudNS using the following command (and setting this in rc.local) after configuring DNSCrypt from this guide. You can check for the updated information, but as of today (Aug 8th, 2013) this command works for me.

dnscrypt-proxy --user=dnscrypt
--daemonize --resolver-address= --provider-key=1971:7C1A:C550:6C09:F09B:ACB1:1AF7:C349:6425:2676:247F:B738:1C5A:243A:C1CC:89F4

To use the secondary server as well the command is:

dnscrypt-proxy --user=dnscrypt --daemonize --resolver-address= --provider-key=67A4:323E:581F:79B9:BC54:825F:54FE:1025:8B4F:37EB:0D07:0BCE:4010:6195:D94F:E330

So the three big improvements for me are DNSSEC, DNSCrypt, and Australia hosting.


DNSSEC is an extension of DNS that aims to provide authentication and integrity of DNS results; it ensures that you know who the result is from and that no one else has tampered with it. DNS responses are authenticated but they are not encrypted, so DNSSEC does not prevent someone between you and the resolver from viewing the request.


DNSCrypt provides encryption of DNS requests, which provides confidentiality of the requests, meaning that an attacker between you and the resolver can not view the traffic between you and your DNS resolver.

Stacking DNSSEC and DNSCrypt works out very well, as you end up covering your bases and achieving confidentiality, integrity, and authentication.

Hosting In Australia

While I’m not particularly familiar with Australia’s laws, hosting outside of the US definitely provides a bit more peace of mind. Just yesterday we learned that Lavabit (the email provider chosen by Edward Snowden) has shut down due to the US government trying to compromise their ability to protect their users. The truth is that hosting in the US just makes a service less trustworthy at this point, and hosting outside is a big plus. This, combined with Namecoin and their pledge to not log, is really somewhat comforting.

So, while I can’t absolutely recommend it at this point (I haven’t been using it long enough) I think there’s a lot of potential here.

16 thoughts on “Using CloudNS For DNS Resolution – Integrity, Authenticity, Confidentiality

  1. The only problem for me is that I have very long pings to it.
    I’d have to set up caching to get things to load reasonably quickly, which has its own security and privacy implications.

    • Your browser should already prefetch most requests. Like if I link you to your browser already fetches the IP for it automatically before you ever click it. Plus I think most browsers cache on their own, though they may rely on the OS for that.

  2. I had almost forgotten that DNS was a thing that could go down, but this resolver has been down noticeably since I switched over to test it out.

  3. They have added a secondary server now, so if you add both there shouldn’t be any problems.

  4. Thank you for putting together the most informative collection on DNSCrypt, especially on how to use with alternate DNS servers and how to harden the protocol.

    I have no issue connecting to CloudNS using this command:
    dnscrypt-proxy --daemonize --resolver-address= --provider-key=67A4:323E:581F:79B9:BC54:825F:54FE:1025:8B4F:37EB:0D07:0BCE:4010:6195:D94F:E330

    However, if I add the –user=dnscrypt parameter then a connection is not made and I receive no error readouts. I followed your instructions on creating a user for DNSCrypt and altered the command and parameters for my Arch Linux machine. I also tried creating a user without any parameters with no success. Am I missing something with regard to privilege escalation for the dnscrypt user? I have a feeling that permissions is the culprit but I cannot figure out where the alterations must be made. I appreciate the support.

    • The issue is likely that /run/dnscrypt deletes after reboot. Add:

      mkdir /run/dnscrypt

      to your /etc/rc.local

      Let me know if that fixes it.

  5. Thanks that did the trick. Are there any advantages to having the home directory in ‘/run/dnscrypt’ as opposed to ‘/home/dnscrypt’?

    • It’s what’s used in the official DNSCrypt documentation. I assume it’s because it’s a file system that gets mounted early, and it’s kind of the ‘place’ for programs like DNSCrypt to leave their stuff.

      I’ll make a note in the guide to add the command to rc.local.

  6. Is there an easy/recommended way to set up a secondary resolver on Windows?

    AFAICT installing it as a service only allows the one resolver/instance to be running in the background.

  7. As nobody has yet given an answer to this question; “Is there an easy/recommended way to set up a secondary resolver on Windows?” or “How to add a second DNScrypt-enabled resolver as backup in case the first goes offline in Windows?” Wouldn’t that be an additional missing registry string value under the “Parameters” key?

    Windows Registry Editor Version 5.00


    ADDITIONAL Thoughts;
    1) How to discover more DNScrypt-enabled resolvers to test and try?

    2) Is there an easy method of checking the Decrypt-enabled “queries” for both DNSSEC and DNSCrypt to be functioning properly? Other than by just checking at the browser loading of sites. So that the PC user would be confident that the two services are verified, for authenticity and cipher strength. Isn’t it possible that the NSA might offer a weaken exploitable version and call it DNScrypt? So how to know if what we got and are using is indeed what we expected?

    3) Would it be a good idea to harden DNScrypt on Windows using the Enhanced Mitigation Experience Toolkit (EMET v4 –

    • 1) shows which ones use it, not many do.

      I use to verify DNSSEC support. I don’t know how to verify DNSCrypt, but cloudns only allows DNSCrypt to connect to it, so that’s one way.

      In terms of getting what you expect, you can talk to the author about that. He can implement code signing or HTTPS.

      Yes, definitely.

  8. Howdy, thanks for the great writeup. Any chance you could give step by step instructions how to setup DNScrypt and cloudNS for the Mac OS X operating system?

Leave a Reply

Your email address will not be published. Required fields are marked *