How To: Privacy-centric DNS

For those who aren’t as technically minded, it’s worth talking about what happens when you type a URL into your web browser and how that impacts privacy. The first thing is that the string you type in, say https://mycoolsite.com needs to be turned into a numeric IP address. This is done using a protocol called “Domain Name Service” or DNS that is as old as the hills. When you get an IP address from your Internet Service Provider (ISP), it’s usually done using something called Dynamic Host Configuration Protocol, or DHCP. At the same time you get that IP address, the ISPs DHCP server will generally pass other configuration parameters such as your DNS server.

OK, so that’s the mechanics of it. What is the privacy implication. Well, ISPs like to make money. And while they make money from you by providing you with Internet service, they also like to make money other ways. One of those is selling information on you to data brokers and advertisers. Since they are turning your URLs into IP addresses using their servers, it’s a pretty easy thing for them to sell the URLs that you like to visit to those data brokers and advertisers. Given that they have to log this information in order to sell it, they can also turn it over to government agencies when they are either subpoenaed or (worst case) handed a national security letter which they can’t even disclose that they were given.

In other words, your ISP knows every web site you visit and happily tells other people about it that you might not want told. Let that sink in for a moment. All of the work you might (or might not <sigh>) do to stay private online goes out the window when you type that address into your URL. By the way, this also goes for your mobile service provider. When you are out and about (i.e. not on WiFi), your cell service provider is your ISP and they have all of that same power and information. Yikes, eh?

So, what can you do about it? Well, using some other regular DNS provider like Google (with the famous 8.8.8.8 DNS server) or CloudFlare doesn’t really help because who trusts their motives? You could use a privacy-respecting DNS provider that doesn’t log their information and has a warrant canary (a mechanism where they regularly post on their website that they haven’t been issued a national security letter until they stop posting that – which means they have), but since the DNS protocol is as old as the hills, that traffic is sent unencrypted over the internet and an adversary could capture it anyhow.

What to do? Well, there is a clever multi-part solution that I’m going to outline here for Linux, OpenBSD (of course) and Windows. It involves running a local DNS resolver on your laptop or desktop machine (why let your ISP resolve them when you can do so yourself) and when your local resolver doesn’t know the answer, using a protocol called DNScrypt to send that DNS request in an encrypted fashion, upstream to a DNS server that doesn’t log and is privacy respecting. It’s not airtight (that upstream server could be lying about being privacy respecting or could get compromised and not even know it) but like most privacy and security, the goal isn’t to be perfect, it’s to make yourself a much harder target so that the bad guys look for easier sheep to fleece.

Linux

For my example in Linux, I’ll be using Ubuntu 20.10 as the target operating system and version so if you are on a different distribution, your mileage may vary but the building blocks will be the same. I based this how-to on a combination of a Reddit post that I found while searching DuckDuckGo (you REALLY should stop using Google and who uses Bing anyhow?), a great article on LinuxConfig that I found the same way and finally

First things first, you need to install the necessary open source tools:

# apt install dnscrypt-proxy dnsmasq

Next, add the line “dns=127.0.0.1” to the [main] section in your local /etc/NetworkManager/NetworkManager.conf file. This tells NetworkManager to force the DNS manager to be the one installed locally (hence the “localhost” bit) on your machine.

After that is out of the way (please don’t reboot now because you won’t have the necessary other bits configured, please be patient <grin>), edit your local /etc/dnscrypt-proxy/dnscrypt-proxy.toml configuration file to set up the upstream server you want to use. I’d recommend taking a look at this list because 1) it’s from the documentation site for DNScrypt; and 2) it has a list of servers that are privacy respecting and don’t log connections. I’d also recommend refreshing your memory as to who the “Fourteen Eyes” nations are who do intelligence sharing with the US and try to pick a resolver that is in a country not on that list. Just sayin’…

Anyhow, add the following lines in the global section of the file:

listen_addresses = [‘127.0.0.1:53000′,'[::1]:53000’]
server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]

I chose to use multiple servers in my configuration to make it resilient in case one of them happens to fail. I’m making the assumption (check my math on this) that the first two (the ones in Switzerland – my privacy-respecting country of choice) are the primary and the other one is there as a back-up in case the first two don’t respond.

Because I couldn’t get the “listen_addresses” bit working from the config file (I left it in there just in case), I also edited the /etc/systemd/system/sockets.target.wants/dnscrypt-proxy.socket file to specify the port I want this service running on. In the [Socket] section, I modified the two lines with the port 53000 setting that I have in the config file:

ListenStream=127.0.2.1:53000
ListenDatagram=127.0.2.1:53000

Now that we have DNScrypt set up, we need to set up the dnsmasq service to be our local, lightweight caching resolver that forwards its upstream resolution requests to DNScrypt. To do this, we need to edit it’s configuration file /etc/dnsmasq.conf and add the following lines (the default file has everything commented out so instead of searching for them and un-commenting them, I just slammed this at the end of the file):

no-resolv
server=::1#53000
server=127.0.0.1#53000
listen-address=::1,127.0.0.1

After setting this up, there is a REALLY IMPORTANT STEP you need to do and that is to disable systemd-resolvd:

# sudo systemctl disable systemd-resolved

After you have done this, you should be able to reboot and resolve DNS names (easy test, go to a site you rarely visit in your browser). To verify that it is your privacy-respecting configuration that is doing this, try the following tests:

# sudo lsof -iTCP:53000 -sTCP:LISTEN

You should see several lines showing tha t the proxess “dnscrypt” running as user “_dnscrypt-proxy” is listening on this socket.

Next, check who is listening on port 53 (the “regular” DNS port):

# sudo lsof -iTCP:53 -STCP:LISTEN

You should see that the process ‘dnsmasq’ running as user ‘dnsmasq’ is listening on this socket. So far so good.

Now, use the ‘dig’ command to force the resolution of a URL that you don’t normally visit:

# dig -t A microsoft.com @127.0.0.1

You should get a display of the IPs that match that URL. Finally, if you are really paranoid (and I am), verify that by turning off dnscrypt-proxy that you CANNOT resolve DNS queries:

# systemctl stop dnscrypt-proxy
# systemctl stop dnscrypt-proxy.socket
# dig -t A oracle.com @127.0.0.1
# dig -t A oracle.com

This should fail to resolve things. Make sure you restart the two systemd services after you have verified this.

Congratulations. You have just significantly improved the privacy of your machine. Now go do this on all of your Linux systems.

OpenBSD

I listed these sections in alphabetical order so don’t read into my choice of having “Linux” first as an indication that I don’t love me some OpenBSD! For this part, I used my coreboot+tianocore Thinkpad T440p running OpenBSD 6.8 off of a secondary drive (the primary drive had the fresh Windows 10 install on it for the Windows version of this how-to).

First things first, we need to install dnscrypt-proxy:

# pkg_add dnscrypt-proxy

The configuration file is logically /etc/dnscrypt-proxy.toml and you need to edit it and add our server_names and listen_addresses to it:

server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]
listen_addresses = [‘127.0.0.1:53000′,'[::1]:53000’]

Once you have that saved, you should enable the daemon using the following command:

# rcctl enable dnscrypt_proxy

Note the underscore instead of a dash there for the daemon name. Now start it up:

# rcctl start dnscrypt_proxy

To verify that the daemon is running and listening on our desired port, simply use netstat:

# netstat -an | grep LISTEN

You should see that there is a process listening on port 53000 in both localhost IPv4 and IPv6.

Now we need to get a local resolver running and forwarding to DNScrypt. Fortunately, OpenBSD has a really nice builtin one called unbound. Enable and start it using the following commands:

# rcctl enable unbound
# rcctl start unbound

Now we need to tweak our dhcp configuration (if you are not running a static IP address) to override any “suggested” name server from your dhcp server. To do that, edit the /etc/dhclient.conf file and add the line:

supersede domain-name-servers 127.0.0.1;

Restart your network with the following command:

# sh /etc/netstart

And then check your /etc/resolv.conf file to verify that the name server is in there along with no other.

Use the following commands to verify that your DNS resolution is working using unbound locally:

# dig -t A microsoft.com @127.0.0.1
# dig -t A microsoft.com

Assuming that goes well, now we need to edit unbound’s configuration file to use localhost port 53000 for our upstream resolver. That file is in /var/unbound/etc/unbound.conf and you need to edit the forward-zone section to look like this:

forward-zone:
name “.”
forward-addr: 127.0.0.1@53000

In addition, in the “server:” section of the file, you need to add the following line in order to get the forwarding working properly between the unbound daemon and the dnscrypt-proxy daemon. Without it, localhost will be ignored for queries:

do-not-query-localhost: no

Use the following commands to restart the service and validate that name resolution is working:

# rcctl restart unbound
# dig -t A oracle.com @127.0.0.1
# dig -t A oracle.com

Now, to verify that you have unbound listening on port 53 and dnscrypt-proxy listening on port 53000, run the following:

# netstat -an | grep LISTEN

If you see listening processes on both the IPv4 and IPv6 ports, you should be good. Finally, to verify that the upstream requests are being forwarded to dnscrypt-proxy, stop its daemon and test using dig:

# rcctl stop dnscrypt_proxy

Windows

OK. Whew. I’m going to be a bit out of my depth on this one (I’m not a big-time Windows power user any more) but the Internet has some good stuff on it so here goes nothing. For my setup, I had a dead-fresh install of Windows 10 on my coreboot + tianocore Thinkpad T440p that I’m using. I figured that way no extra configuration would get in there that might mess things up.

I figured there are a lot of bad actors on the Internet who might post some bad info on how to set this up in such as way as to route all of your traffic to them (forgive me, I’m paranoid <grin>), so I thought the best place to go would be the GitHub repository for the DNScrypt-proxy project.

From there, I clicked the link to download the latest version of DNScrypt-proxy for Windows. Given that, I read the documentation on how to install the service myself, not using a possibly compromised “helper”. Also, this helps me learn where the files are and how to configure things which is always good. I’ll document my process here. From this point forward, assume that I’m running a PowerShell command prompt with the “run as Administrator” option.

I copied the contents of the “win64” directory to C:\Program Files\DNScrypt-proxy to start things off. Best to have it in a “standard” (I think) place. I then move to that as my current directory. Next, copy the example-dnscrypt-proxy.toml file to “dnscrypt-proxy.toml”:

PS > copy example-dnscrypt-proxy.toml dnscrypt-proxy.toml

Edit the file using notepad (I guess) to have the same server_names line that we had for the Linux install above:

server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]

Now, let’s make sure everything is working by running ./dnscrypt-proxy from that PowerShell prompt:

PS > ./dnscrypt-proxy

You should see some diagnostic information finishing up with “dnscrypt-proxy is ready – live servers: 2” in your PowerShell prompt.

The instructions are a little off on the version of the page I was looking at (or maybe my Windows 10 fu is weak). Anyhow, I went old-school and went to my “Wi-Fi” settings in the UI and selected “Change adapter options” from the link on the right. I then went to my “Ethernet” and “Wi-Fi” icons, right clicked on them, selected “Properties” and then went to the “Internet Protocol Version 4 (TCP/IPv4)” item and clicked the “Properties” button.

For both adapters (Ethernet and Wi-Fi), I changed the page to “Use the following DNS server addresses” radio button and entered 127.0.0.1 in the “Prefered DNS server” address and “9.9.9.9” as the “Alternate DNS server” per the instructions. Just for shits and giggles I checked the “Validate settings upon exit” checkbox and hit OK. I didn’t get any error messages so I’m assuming it’s good.

I then repeated the process with the IPv6 properties, setting the “Preferred DNS Server” to “::1” (without the quotes) – the equivalent of localhost in IPv6 land. I also set the “Alternate DNS server” to “0:0:0:0:0:ffff:909:909” which is the IPv6 address of that server.

Back to the PowerShell prompt, I hit “Ctrl+C” to break out of the dnscrypt-proxy process that was running and executed the following command:

PS > ./dnscrypt-proxy -resolve example.com

This successfully verified that I was able to resolve the DNS query using my configuration file. Now for the fun part, installing the service. To do this, run the following command:

PS > ./dnscrypt-proxy -service install

If you don’t get any error messages, start the service:

PS > ./dnscrypt-proxy -service start

Assuming you are error free there, you actually have a working (without a local caching resolver) install of DNScrypt-proxy. The final step is to fiddle with a Windows 10 group policy setting for the Network Connect Status Indicator (NCSI) to prevent it from showing your network as “offline”.

To do this, run “gpedit.msc” to launch the Group Policy Editor. From there, drill down to:

Computer Configuration -> Administrative Templates -> Network .> Network Connectivity Status Indicator

In the right-hand pane, select the “Specify global DNS” policy and click the “Enabled” radio button. Now check the “Use global DNS” checkbox and hit OK.

At this point you should be safe to reboot and verify that things are working. After the reboot, bring up a “run as Administrator” PowerShell prompt and run the following command:

PS > netstat -a -b

You should see dnscrypt-proxy.exe listening on port 53 of the localhost IP address. Bring up a browser and hit a site you rarely visit to verify that you have name resolution working.

I don’t have the local cache part of this working on Windows yet but all I’m losing there is efficiency because I’m doing the DNS lookup each time I need to resolve something. All said, I think I improved the privacy of my Windows 10 install by a non-zero amount! 🙂

Mobile?

So what about mobile? That tends to be a platform that we all spend a lot of time on these days and I’d hate to leave it out. While my experience and expertise doesn’t allow me to truly test that this works like I can on desktop operating systems where I can use tcpdump, turn services on or off, etc. some sites that I trust lay down some recommendations that appear to be working when I test them. Therefore, use this at your own risk and do testing that you think makes sense for you and your threat model.

For iOS, I found the following link from PrivacyTools.IO (one of my favorite sites) that walks you through how to use an app on the iPhone to run dnscrypt-proxy as your local DNS resolver on iOS. Essentially, you need to install the app, click on the “edit” button in the toolbar when you launch it and add our standard “server_names” line below, then hit the checkmark button in the toolbar to save it:

server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]

Then, you will want to click on the “hamburger button” in the toolbar on the left and turn on the “Connect On Demand” general option. After that I rebooted my phone just for good measure and I appear to be up and running.

For Android, I found an application on the Google Play store called Quad9Connect. It appears to use secure DNS to access servers but it lacks the fine-grained control I would like in order to specify which countries I want those DNS queries to be tunnelled through.

Another Android app that I have seen recommended on a variety of sites is InviZible Pro. This app allows you to have more control over your DNScrypt-proxy setup. The settings I’m running with are to turn off the Tor support, leave the DNSCrypt support on and set it to run at boot-time. I also turn on the “require_nolog” feature in the DNSCrypt Settings page. Finally, I go into the Network & Internet settings in Android, selecct VPN, select settings for InviZible Pro and enable “Always-on VPN”.