Welcome to the brown age of computing! Partly Cloudy, 22.3°C [H: 32°C] - No precip

Update: DNSCrypt Server On A Whatever 2019-07-03

Earlier today I was emailing with someone about dnscrypt-wrapper instructions when I noticed that the link for the named.cache file was dead. So I updated it to the new https location. Some of the instructions may also be outdated, but of course possibly still helpful.

Update: DNSCrypt Server On Raspberry Pi B 2017-11-22

A half year ago when I wrote this it seemed to work well enough on a PC running Debian Jessie, but recently I setup a DNSCrypt server on a Raspberry Pi B and as I followed my own instructions there were a couple things that didn't fit quite right. So I have fairly heavily modified these instructions to fit my rpi install, but the information should be still quite useful for someone installing on plain old Jessie too.

Host A DNSCrypt Server On Jessie 2017-04-02

Fair Warning

If you are planning to run your own DNSCrypt server because you are concerned about mass surveillance such as PRISM, then your DNSCrypt server will have to be public, or you are wasting your time. Having your own DNSCrypt server can't hide your DNS queries entirely (recursive lookups are in clear text), it can only help to blend your queries in with everyone else on the same server. Having said that, it might be educational to look through the process to learn more about how DNSCrypt servers are built and how they function.

I should also note that these instructions are [mostly] intended to be used when logged in as root. These instructions make your device act as a server and nobody should be fucking with a browser, downloading scripts/software, or running shit that has not already been examined on a server. Especially a server with any kind of public facing service. Anyone who still thinks these instructions should use sudo or su may leave now because I don't care.

woof Mishka eating lumber.


Okay, if you're reading this you hopefully know enough about DNS that you don't need an explanation. So let's jump right in to the instructions. I started by using Raspbian Jessie mostly because the two attempts I made at upgrading [a PC] to Stretch were pretty miserable (and I have little/no patience). A fresh install may have been better, but if the upgrade is going to go that poorly, just don't offer it. I got my Raspbian Jessie Lite image from here, the last Jessie build offered in Raspbian. There's no need to use the full sized install, it is pretty bloated. You can use whatever distro you like of course, which may have slightly different applications installed by default. There are lots of instructions on how to write rpi images to [micro]SD cards, choose one that suits your needs.

Step 1: Startup

Boot the Raspbian image which should resize the partition automatically for you and reboot. When it comes back up, log in as "pi" with the default password "raspberry", then run:

$ passwd

to set a new password on the pi account. Then run:

$ sudo systemctl enable ssh
$ sudo reboot

You could also "sudo systemctl start ssh" to get it going, but I am a big fan of overkill and if you can't wait the 30 seconds it takes to reboot a fresh rpi, then running a DNSCrypt server may not be for you.

Step 2: Setup root Login Via SSH

Go to another PC, SSH in to your DNSCrypt server as pi, and run:

$ sudo passwd root

Which will of course confirm that SSH was properly enabled and will set the root password. If you really want to you can change "without-password" to "yes" in your /etc/ssh/sshd_config to let root log in by password but it might be a better idea to use a key to authenticate your logins. Create a /root/.ssh/authorized_keys file and add your key to it. Now logoff and SSH back in as root to make sure your key (or password) is working.

Step 3: Prepare Your OS First

Just get these out of the way first. It'll help to reduce the errors that get barfed up by subsequent commands.

# dpkg-reconfigure tzdata
# dpkg-reconfigure locales
# reboot

Yes, wait the 30 seconds for the reboot, it won't kill you and it'll make the following apt-get commands happier.

# apt-get update
# apt-get install dnsutils automake libtool
# apt-get purge avahi-daemon alsa-utils bluez bluez-firmware cifs-utils lua5.1 luajit
# apt-get purge samba-common v4l-utils wireless-regdb wireless-tools
# apt-get autoremove --purge
# apt-get upgrade

Step 4: Setup Unbound As Your Recursive Resolver

Now that you have dumped a few unnecessary applications and prepared your OS, it is time to start putting some useful software on this thing:

# apt-get install unbound
# nano /etc/unbound/unbound.conf

Your unbound.conf should look pretty boring, just add these lines at the end:

do-daemonize: yes
username: "unbound"
logfile: "/var/log/unbound.log"
hide-identity: yes
hide-version: yes
harden-glue: yes
harden-dnssec-stripped: yes
access-control: allow
root-hints: "/etc/unbound/named.cache"

Then download the current root-hints, restart unbound, and make sure it works:

# wget -O /etc/unbound/named.cache
# systemctl restart unbound
# nslookup

That should give you the IP address of, if it doesn't you might want to check to make sure you do not have an install of another DNS server already using port 53. Now that you have unbound resolving for you, move on to dnscrypt-wrapper.

Step 5: DNSCrypt And Dependencies

On a raspberry Pi these builds can take a while, be prepared to have a couple short naps along the way here. You could opt to pump all these commands in to a script or something but it is kind of a good idea to run them one at a time to make sure you haven't screwed anything up along the way.

# mkdir ~/src && cd ~/src
# wget -O
# wget -O libsodium-latest.tar.gz
# wget -O

# unzip
# tar xzf libsodium-latest.tar.gz
# unzip

# cd libevent-master
# ./
# ./configure
# make
# make install

# cd ../libsodium-stable/
# ./configure
# make
# make install
# ldconfig

# cd ../dnscrypt-wrapper-master
# make configure
# ./configure
# make install

If you are getting a barf on dnscrypt-wrapper, I bet you missed running ldconfig after you built libsodium.

Step 6: Keys And Connecting

At this point you have all the required software, but you'll of course still need to setup keys.

# mkdir /etc/dnscrypt && cd /etc/dnscrypt
# dnscrypt-wrapper --gen-provider-keypair
# dnscrypt-wrapper --show-provider-publickey --provider-publickey-file public.key > public.asc

# dnscrypt-wrapper --gen-crypt-keypair --crypt-secretkey-file=1.key
# dnscrypt-wrapper --gen-cert-file --crypt-secretkey-file=1.key --provider-cert-file=1.cert --provider-publickey-file=public.key --provider-secretkey-file=secret.key --cert-file-expire-days=1

# dnscrypt-wrapper --resolver-address= --listen-address=YOURIP:5353 --provider-name=2.dnscrypt-cert.FANCYNAME --crypt-secretkey-file=/etc/dnscrypt/1.key --provider-cert-file=/etc/dnscrypt/1.cert &

In the commands above it is important to note that:

At this point you should have a working dnscrypt'ed server that is ready to take on your queries. To test it you'll want to grab the dnscrypt-proxy and use it from a client to do some queries. I used a Windows [XP] box to test mine, but the idea is generally the same on whatever OS you're using. Since your resolver is not listed in dnscrypt's public list, you'll have to connect to it like this:

> dnscrypt-proxy --local-address= --resolver-address=YOURSERVER:5353 --provider-name=2.dnscrypt-cert.FANCYNAME --provider-key=1111:2222:3333:4444:5555:6666:7777:8888:9999:0000:AAAA:BBBB:CCCC:DDDD:EEEE:FFFF

Here, when connecting with the proxy, it is important to note that:

You should see some information that tells you about your dnscrypt'ed connection to your server and you should now be able to open another command prompt and use nslookup to test a few queries:


Now, to make sure that you really are going through the proxy and wrapper, you should kill the wrapper process on the server and try your nslookups again on your test proxy machine.

# killall -v dnscrypt-wrapper

If the queries now fail, then you know the wrapper is being used for them.

Step 7: Key Rotation

If you haven't read it yet you should really look at the key rotation section of the wrapper install. In the commands above, when you created your initial query key/cert, they were set to expire after one day. Set them any longer and the proxy will barf up an error message when it connects to your server. It won't stop it from working, it'll just barf up the error message which looks bad. If you are planning to be the only one using this server, you can ignore the error message, but if you want to get rid of the error message (and you should), you'll need a script that generates new keys and kills/starts wrappers to use the new keys. Then you'll have to cron the script to run a few times daily. The guy who runs has this post explaining a bit more about the error message, and how he setup his key rotation... but I kind of went my own way.

Have a look at my script.

If you followed my instructions pretty closely you can probably use the script with only a few modifications, see the comments at the top of the script for instructions. The idea of the script (if you didn't read the info at the link above) is that it will create a new set of keys and temporarily run two instances of the wrapper. Then after an hour it kills off the old wrapper and its keys, leaving only the new key set. The next time it runs it does the same thing except it will switch from 2.key and 2.cert back to 1.key and 1.cert. This basically allows time for any connected clients to update to the new key before dropping the old one. To use the script you'll need to give it execute permissions (after modifying the variables at the top):

# chmod +x /etc/dnscrypt/

I added the script to my crontab to run every four hours, I guess you could choose any schedule that suits your needs. As long as it rotates at least once a day it'll make dnscrypt-proxy clients happy.

# crontab -e 15 1,7,13,19 * * * /etc/dnscrypt/

Step 8: Make Your Server Public

Seriously, if anyone has the ability to record your DNS queries when you use your ISP's DNS servers, then they have the digital intelligence to figure out where your DNSCrypt server is, and will know that all DNS traffic is yours anyways. Using a dnscrypt'ed server is really only effective if you have numerous clients making queries to it, because even if the upstream queries are recorded, the person recording them doesn't know which client (behind the DNSCrypt server) is doing the requesting.

Some might agrue that [on a heavily used public DNSCrypt server] it might be possible to trap the outbound queries from it, as well as the traffic from your PC/network/VPN and be able to piece together who is making which queries. In all reality, that is kind of a stretch, because it doesn't take in to account the fact that many queries would be cached and would never have to go upstream. It would also be hard to essentially trap every bit of Internet traffic continuously in order to compare the packet times against. Don't get me wrong, if someone could trap just your traffic and the outbound traffic from your DNSCrypt provider, then maybe they could piece together which queries are yours, but that is a lot of trouble to go to for DNS queries, and if someone was that interested in your traffic, they'd be doing a lot more than just some DNS query sniffing.

Made with Notepad++ & FastStone, without javascript, cookies, or the help of Clippy or ai. Hosted on Devuan with nginx & powered by NK shrooms.