Your ISP provides name to IP address resolution for any domain that is not resolvable within your local network. These unsecured requests can be spoofed by an attacker which could lead to a man-in-the-middle attack. Your ISP may also be able to monitor your traffic. Fortunately there is a simple solution to ensure data integrity while also protecting your privacy.
DNSCrypt encrypts and authenticates DNS traffic between your computer and a DNS resolver. This ensures the IP addresses being returned to you have not been manipulated while also maintaining data confidentiality. In the following example we are going to demonstrate how to install DNSCrypt on a system running Linux and then cache those requests using Dnsmasq.
The distribution we will be working with today is Arch Linux. Let’s start out by installing the necessary packages
sudo pacman -S dnscrypt-proxy dnsmasq
Next enable the service
sudo systemctl enable dnscrypt-proxy.socket
Modify the nameserver entry within the /etc/resolv.conf file to point to the localhost
sudo vi /etc/resolv.conf
Certain processes such as NetworkManager can overwrite the resolv.conf file following a reboot. To fix this refer to the following link and select the process which applies to your system.
As configured all DNS requests will now be sent to the default resolver which is dnscrypt.eu-nl. It is recommended that you select the server closest to you for faster name resolution.
Pick a server from the following list
sudo localc /usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv
Replace the server with the one you selected within the dnscrypt-proxy.service file
sudo systemctl edit dnscrypt-proxy.service --full
Restart the service
sudo systemctl restart dnscrypt-proxy.service
Check that the service is running and that there are no certificate errors reported with the DNS resolver
sudo systemctl status dnscrypt-proxy.service
● dnscrypt-proxy.service - DNSCrypt client proxy Loaded: loaded (/etc/systemd/system/dnscrypt-proxy.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2015-08-27 18:59:31 EDT; 2h 46min ago Main PID: 578 (dnscrypt-proxy) CGroup: /system.slice/dnscrypt-proxy.service └─578 /usr/bin/dnscrypt-proxy -R okturtles Aug 27 20:01:14 arch dnscrypt-proxy: [INFO] Refetching server certificates Aug 27 20:01:14 arch dnscrypt-proxy: [INFO] Server certificate #808464433 received Aug 27 20:01:14 arch dnscrypt-proxy: [INFO] This certificate looks valid Aug 27 20:01:14 arch dnscrypt-proxy: [INFO] Chosen certificate #808464433 is valid from [2015-02-04] to [2016-02-04] Aug 27 20:01:14 arch dnscrypt-proxy: [INFO] Server key fingerprint is CB51:0B61:7A1F:FCEB:27CE:26B5:8934:978A:04FF:D9E7:42A4:6A6B:0960:0F0F:F084:595C
Confirm the socket is running
sudo systemctl status dnscrypt-proxy.socket
● dnscrypt-proxy.socket - dnscrypt-proxy listening socket Loaded: loaded (/etc/systemd/system/dnscrypt-proxy.socket; enabled; vendor preset: disabled) Active: active (running) since Thu 2015-08-27 18:59:31 EDT; 2h 46min ago Listen: 127.0.0.1:40 (Stream) 127.0.0.1:40 (Datagram)
Next we will setup a local DNS cache using Dnsmasq and configure DNSCrypt to forward to it. This will speed up name resolution and avoid sending repeat requests to the DNS resolver.
sudo systemctl edit dnscrypt-proxy.socket --full
Since the DNS cache needs to listen on port 53 we will configure DNScrypt to listen on an alternate port. In this example we will use port 40
[Unit] Description=dnscrypt-proxy listening socket #After=network.target [Socket] ListenStream=127.0.0.1:40 ListenDatagram=127.0.0.1:40 [Install] WantedBy=sockets.target
Next restart dnscrypt-proxy.socket so that the changes can take effect
sudo systemctl restart dnscrypt-proxy.socket
Configure Dnsmasq strictly as a local cache
no-resolv server=127.0.0.1#40 listen-address=127.0.0.1
Next enable the Dnsmasq service
sudo systemctl enable dnsmasq
And finally start the Dnsmasq service
sudo systemctl start dnsmasq
For a quick test try looking up a domain on the Internet using dig
dig google.com ; <<>> DiG 9.10.2-P3 <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<
If Dnsmasq is working correctly then a subsequent request will resolve the domain almost instantly. The line to use for comparison is the “Query time”
[red@arch ~]$ dig google.com ; <<>> DiG 9.10.2-P3 <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<