I am no longer using or recommending this approach to encrypted DNS. The difficulty in finding and provisioning reliable DNSCrypt servers make this approach somewhat flaky, and the trend favor DNS over TLS. Please see Encrypted DNS with Caching using Unbound for a better solution.

Encrypted DNS with Caching using DNSCrypt and DNSMasq (deprecated)

Domain Name Service (DNS) is an important vulnerability for most systems, and particularly so for laptops which are generally set up to be quite promiscuous when it comes to DNS.

The basic concern is that when you connect to a network that uses DHCP (most WiFi networks are this way), then you generally accept the network’s choice of name servers. They may offer a nefarious name server. The name server converts domain names to IP addresses. In that way it is like a phone book. The problem is that a nefarious name server might convert the domain name of your bank to the IP address of a site that is looks just like your banks site but is designed to steal your username and password. To see a humorous and largely harmless version of this, see Upside-Down-Ternet. This note tells you how to reduce your chances of succumbing to this particular attack.

In order to harden DNS on my laptop, I compiled and ran dnscrypt as a daemon and configured my laptop to always use it to provide DNS service. This protects me in two ways: first, dnscrypt assures that it talks only to the name server I have chosen, and second, it encrypts the connection so the responses cannot be observed or modified. I use OpenNIC as my trusted source of name servers because of its open and democratic policies (

In addition, I will also install and configure DNSMasq, which is optional. DNSMasq provides DNS caching to speed up your DNS performance.

I will describe how I did all of this on Fedora Linux.

Compiling and Installing DNSCrypt

When this was first written dnscrypt was not available through yum. That has changed. On Redhat systems you can now install it using:

sudo yum install dnscrypt-proxy

If that works for you, you can skip the rest of this section, which describes how to compile and install dnscrypt manually.

First, install the dnscrypt dependencies:

sudo yum install libsodium-devel

Download the source for dnscrypt from and untar it into a convenient directory.

Change into the dnscrypt directory and configure and make the program:

cd ~/packages/dnscrypt-proxy
sudo make install

Now, dnscrypt-proxy should be in /usr/local/sbin.

Alternatively, you can use get the absolute latest version of dnscrypt by using the version on github:

sudo yum install libtool-ltdl-devel libsodium-devel
git clone
cd dnscrypt-proxy
sudo make install

You can update your local repository and reinstall using:

git pull
sudo make install

Finding a DNSCrypt Resolver

There are dnscrypt resolvers all over the world. You should choose one that is near you. To do so, get the generate-dnscrypt-cmdline script:

git clone

You may need to install some dependences (see the README file for instructions). Then run it to get a list of resolvers:

cd generate-dnscrypt-cmdline

Choose a suitable resolver. I like the policies of OpenNIC, so I tend to choose the closest OpenNIC server. Before you follow my lead, you should know that the OpenNIC servers are run by volunteers, and the servers can come and go. At least I have this problem in California. If you are using dnscrypt and the service stops working, you simply repeat this process and choose another resolver.

Once you have chosen your resolver, say the OpenNIC server in Dallas, generate the dnscrypt-proxy command line using:

./generate-dnscrypt-cmdline fvz-rec-us-dal-01

You will need this for the next step.

Running DNSCrypt as a Daemon

For security reasons, dnscrypt should not be run as root. Instead it will be run as nobody, a user with few if any privileges. If you try to run dnscrypt-proxy as a normal user on its default port (53, a privileged port), you will get a permission denied message when it tries to open the port. So you either have to use a non-privileged port (1024 to 65535) or you can label the executable in such a way that it can open secured ports. You can do the latter with:

sudo setcap cap_net_bind_service=ep /usr/local/sbin/dnscrypt-proxy

To run dnscrypt-proxy as a daemon that starts automatically, create a file named /etc/systemd/system/dnscrypt.service that contains:

Description = DNSCrypt
After =

PermissionsStartOnly = true
ExecStartPre = /bin/touch /var/run/
ExecStartPre = /bin/chmod 666 /var/run/
ExecStart = /usr/local/sbin/dnscrypt-proxy
Restart = always
Type = forking
User = nobody
PIDFile = /var/run/

WantedBy =

where the value given for ExecStart should be the output produced by generate-dnscrypt-cmdline.


For clarity the ExecStart command was given above using multiple lines, but in the dnscrypt.service file the entire ExecStart entry should be on the same line.

The dnscrypt process is run as nobody, which would not normally have permission to write the pid file in /var/run. We cannot create a directory to hold the PID file manually in advance because /var/run is deleted and re-created whenever the system is rebooted. To resolve this issue, prestart commands are added to the systemd config file that create the PID file in advance, and then make it writeable by all.


The PID file specified on the dnscrypt-proxy command line should match the file specified for PIDFile.

The local address is configured to be port 2053 on localhost ( Normally DNS should be served on port 53, but in this case a DNS caching service (dnsmasq) will be used and dnsmasq will serve from port 53, and it will be configured to talk to dnscrypt via 2053.

If you do not wish to use DNSMasq, you can simple tell dnscrypt-proxy to use for --local-address and skip the next steps where DNSMasq is configured and started.

After updating the dnscrypt.service file, you should run:

sudo systemctl daemon-reload

To assure that dnscrypt-proxy starts automatically when the machine boots, run:

sudo systemctl enable dnscrypt

To start dnscrypt-proxy now, without waiting for a reboot, run:

sudo systemctl start dnscrypt

To assure it is working correctly, run:

sudo systemctl status dnscrypt

Be sure the status messages include the message: ‘This certificate looks valid’. If not, there may be a problem with the resolver you chose. You might try choosing another.

To rerun dnscrypt after you have changed the .service file:

sudo systemctl --system daemon-reload
sudo systemctl restart dnscrypt
sudo systemctl status dnscrypt

Testing DNSCrypt

To test dnscrypt-proxy to assure it is working properly, run:

dig @localhost -p 2053

It should complete quickly with a list of IP addresses for

Configuring and Running DNSMasq

Generally Linux is configured such that NetworkManger controls DNS, and while NetworkManager is easily configured to use dnsmasq, it is difficult to control and will often subvert our desire to use dnscrypt when running on networks that use DHCP. So, our first step is to configure NetworkManager so that it does not manage dns. To do so, edit the file /etc/NetworkManager/NetworkManager.conf and assure that it contains the line:


If you changed this file, restart NetworkManager so it honors the new setting:

sudo systemctl restart NetworkManager

Now add dnscrypt.conf to /etc/dnsmasq.d where dnscrypt.conf contains:

# Configure DNSMasq to provide DNS caching, but not DHCP service.
# This file configures DNSMasq to work with DNSCrypt, which is expected to be
# running on localhost#2053. If there is no response via DNSCrypt, DNSMasq
# will try to directly query the OpenNIC servers.

# Servers seem to be taken in reverse order (highest priority server should be given last).
# These dns servers were culled from
server=  # Missouri
server= # Texas
server=   # Texas
server=   # Texas
server=   # Washington
server=  # California
server=  # California

Do not use these server addresses blindly. If you are using OpenNIC, visit their Wiki to determine the best servers to use. The OpenNIC servers seem to be somewhat transient, so if you go with OpenNIC you will have to review and update your servers from time to time.

Now configure dnsmasq to run as a daemon:

sudo systemctl enable dnsmasq
sudo systemctl start dnsmasq
sudo systemctl status dnsmasq

The first command causes dnsmasq to start up automatically everytime your machine restarts, the second starts it immediately, and the third prints out status information on dnsmasq so that you can tell whether it is running properly or not.

Testing DNSMasq

To test dnsmasq to assure it is working properly, run:

dig @localhost
dig @localhost

It should complete quickly with a list of IP addresses for Then view /var/log/messages. You should see commentary from dnsmasq that is similar to this:

Oct 27 18:01:49 hostname dnsmasq[24670]: query[A] from
Oct 27 18:01:49 hostname dnsmasq[24670]: forwarded to
Oct 27 18:01:49 hostname dnsmasq[24670]: reply is
Oct 27 18:02:12 hostname dnsmasq[24670]: query[A] from
Oct 27 18:02:12 hostname dnsmasq[24670]: cached is

The first line acknowledges our first request. The second line indicates that the request was forwarded to, which is dnscrypt (the port is not shown). The third line indicates that dnscrypt was able to retrieve the address for The fourth line acknowledges our second request. And the fifth line indicates that dnsmasq has the address for in its cache.

Once you are comfortable that things are working properly, comment out the ‘log-queries’ line from /etc/dnsmasq.d/dnscrypt.conf to suppress the extensive logging.

Configuring Your Machine to Use DNSMasq and DNSCrypt

Change /etc/resolv.conf so that it contains:

# Name Servers

# Assumes that dnsmasq and dnscrypt are running to provide encrypted dns with caching

# Provide alternative trusted name servers in case something goes wrong with the default
# These dns servers were culled from

# California
# Washington
# Texas
# Missouri

# These are from Google. They should always work.

# This file was made immutable using "chattr +i /etc/resolv.conf" so that the
# file is not overwritten by Network Manager.
# Use "chattr -i /etc/resolv.conf" to remove the immutable attribute.
# Use "lsattr" to list immutable attributes.
# Use "chattr +i /etc/resolv.conf" to make the file immutable again.

Doing so tells all of the network aware services on your machine to use localhost for DNS traffic. Of course, you should change the alternative name servers to ones that would be appropriate for your location.

Finally, you must make this file immutable, otherwise NetworkManager will replace it whenever the network changes. To do so, use:

chattr +i /etc/resolv.conf

This will not work properly is /etc/resolv.conf is a symbolic link. In this case, you should delete the symbolic link, then create the file, then make it immutable.


To assure things are working as expected, run:


It should complete quickly with a at least one IP address for It should indicate the DNS server with:


Finally, visit and make sure you are actually using the dns server you specified to dnscrypt.

My Experience With The OpenNIC Project

I have been using The OpenNIC Project DNS servers for some time. It has very good policies and I am quite pleased with the service except for one thing. The DNS servers are run by volunteers, and the servers that support DNSCrypt seem to come and go. At least that seems to be the case in the United States. When a server you have chosen disappears, your computer will start using the backup DNS servers you specified, but the resolution process can become quite slow and painful as it first tries your primary DNS server, that times out, and then it uses your backup server.

To cope with this I have written two scripts that check the DNS server and emails me a warning if they are not working. The are named check-dnscrypt-resolver and you can find them on github. I simply place them in a cron script that runs every 10 minutes.

The first script, check-dnscrypt-resolver, must run as root. It examines /var/log/messages looking for a ‘No useable certificates found’ message, which indicates that the resolver used by dnscrypt has gone stale. The date on these messages are checked (after reconstructing the year) and if they are newer than the modification date on the dnscrypt.service file a warning is mailed to the maintainer.

The second script, check-dnscrypt-resolvers, runs:

dig @localhost -p 2053

to see if dnscrypt is able to resolve addresses.

The first script can be slow to recognize problems. The second script is much faster but will complain about transient problems.