DNSCrypt Traffic Flow Diagram 2019-07-30
In my travels I occasionally come across someone setting up dnscrypt-wrapper or proxy who wants to test whether or not their DNS queries are actually encrypted. You could use Wireshark or tcpdump to capture your traffic and then examine it to see if your queries are showing up in plain text, but that only confirms that your queries are not found to be plain text, as opposed to confirming the presence of encrypted queries. A subtle difference, but significant to some people. The dnscrypt-proxy client has a filter feature that can be used to check whether or not queries are going through the proxy. Another way to confirm that your DNS queries are encrypted is to simply stop the DNSCrypt connection and see if your DNS stops working. To start with, let's see where DNSCrypt actually functions.
In this diagram, clear text DNS traffic is shown with orange lines while encrypted DNS traffic is shown with blue lines. Grey boxes are devices on the user's home network, while red boxes are devices on the Internet somewhere. Routers are shown in white since they are [sort of] both on the Internet and on your home LAN at the same time. As you can see, DNSCrypt really only encrypts a portion of the DNS traffic.
Scenario 1: Typical Unencrypted DNS
In the first scenario, your device is doing its DNS lookups with a regular clear text DNS server. In many cases, the router in this scenario will use DHCP to tell your device to use your router as its DNS server. When this happens, your router is acting as a stub resolver, and is simply forwarding the DNS queries to your ISP's recursive DNS servers. None of the DNS traffic is encrypted.
Scenario 2: Encrypting DNS For One Device
In the previous scenario, your device is contacting your router (or perhaps your ISP's DNS servers directly) on port 53 with unencrypted queries. To encrypt your DNS traffic you must manually tell your device to send your DNS queries to a dnscrypt-proxy listener that has a connection to an upstream server running dnscrypt-wrapper. You begin by setting up dnscrypt-proxy on your device which connects to a DNSCrypt [or DoH] server and will also "listen" on port 53 of your local machine. It is basically pretending to be a DNS server, accepts DNS queries, and sends them to the upstream provider. The dnscrypt-proxy config file allows you to set various requirements (such as DNSSEC support or no-logs) for which servers it will connect to, or you can specifically name which servers you want to use. dnscrypt-proxy does not process the queries at all, it simply wraps the queries in encryption, passes them to a server running the wrapper application, and then decrypts the replies when they come back.
Once the proxy is running you need to tell your device to start using it. How you make that change depends on your operating system. If you have Windows it'll be in your network properties, in Linux it is usually managed by resolvconf in your /etc/resolv.conf file, and so on. If you can get past the crappy ads and autoplay video you can find a fairly comprehensive guide to setting DNS servers here (just be sure to point your DNS at your local machine's 127.0.0.1 address instead of Google's metadata collection servers). After pointing your device's DNS at your local dnscrypt-proxy you can test whether or not your queries are encrypted by stopping the dnscrypt-proxy service. For example, run
nslookup snork.ca
in a terminal. Confirm that you get a proper IP address, then stop your dnscrypt-proxy and run it again. It should fail to give you the IP address the second time because dnscrypt-proxy is no longer passing on your queries. Start up dnscrypt-proxy again and try the nslookup one more time. If it works, then you know your queries are being passed through dnscrypt-proxy.
One of the advantages of this setup is that if you take your device to another network, such as work or public wifi somewhere, your queries will still be encrypted. It also has the advantage that [since dnscrypt-proxy is installed locally] the queries are encrypted before they even leave your machine, which may be a concern if you are on an untrusted network or wireless of any kind. The disadvantage is that you need to manage this dnscrypt-proxy installation separately... meaning that if you have a bunch of machines setup this way then your configuration changes need to be made multiple times.
Scenario 3: Protect Your Whole Home Network
If you have a bunch of networked devices at home... like a desktop, a phone, a tablet, a media player, a laptop, a smart TV, and a IoT toaster, then you might want to setup a small DNS server on your LAN that encrypts queries for all of them. Seriously if you have a smart toaster you may need to rethink some of the choices you have made in life. Anyways, if you setup a small virtual machine or a low-power device like a Banana Pi you can use it as your DNS server for all the devices on your network. To do this, install dnscrypt-proxy on this machine, which I'll call a DNS Gateway. Change the listen_addresses directive in the .toml file from 127.0.0.1 to whatever IP address the DNS Gateway has on your LAN (probably 192.168.X.Y), and then change your DHCP (possibly on your router) configuration so that it specifies the DNS Gateway machine address (192.168.whatever) as the DNS server clients should use. Now renew your IP addresses on your clients and they will use your new DNS Gateway.
A nice advantage of this setup is that if you add a new device to your network you do not have to do anything, it just uses your encrypted DNS setup by default. It also means that if you setup any kind of blocking or filtering on the DNS Gateway it will immediately take effect for all of your devices. The disadvantage is that this setup requires you to have your DNS Gateway machine running all the time. If you're lucky and adventurous you might try installing OpenWRT on your router and then follow the instructions to install dnscrypt-proxy on it. That way you don't need an extra piece of hardware or a virtual machine to be "always on".
Conclusion
Don't forget though, that DNSCrypt only encrypts the queries between the proxy and the wrapper applications. The rest of the DNS traffic (to root and authoritative servers) is still clear text. This means that running your own DNSCrypt server only relocates the apparent source of your clear text queries, unless you make your server public and allow your queries to be mixed in with other people's. There is also the problem of SNI which needs to be dealt with separately, and the consideration of a VPN or proxy for your actual browser traffic. DNSCrypt isn't the answer to online privacy, it is just a part of an overall plan to manage your online privacy.