The truth about dnscrypt-proxy and DNSSEC?

FAQs Community How-to's
1

I've been at it for quite some time now, running pihole on raspbian jessie lite, build February 2017. I've been communicating with the developer of dnscrypt-proxy, the developer of dnsmasq and qpad. After all this work, I wanted to share my findings here.

dnscrypt-proxy:

  • Not all dnscrypt-proxy servers are the same, you should find servers that use port 443, support DNSSEC and keep no logs. This isn't obvious, as the port isn't always mentioned in dnscrypt-resolvers.csv, some however explicitly indicate the use of a different port. In my sample configuration, I've enable dnscrypt logging. You can than verify the name, IP and port used in /var/log/dnscrypt-proxy.log
  • Some dnscrypt administrators are lazy, they create certificates that are valid for an extended period of time. It is, from a security point of view, necessary to avoid security risks (Isn't that what we are trying to achieve). It implies you need to run update_resolvers.sh frequently (see this wiki, it will be referenced later)
  • There are different ways to setup dnscrypt-proxy. Qpad has provided a possible (and easy) method here, but it changes your system even more than I will and, as he has indicated here, his configuration doesn't allow for more than 2 proxies. I understand he has since changed his method to my (less invasive) way to upgrade dnsmasq, but you can forget about this, this version doesn't work either. I've explained here how to get a configuration with four (4) proxies, so I'm not going to repeat it here. Be aware however that I've updated the rar file, containing the sample (working) configuration.
    All of this (assuming you followed the wiki configuration) will lead to a working dnscrypt-proxy configuration. You can test it by (example for one proxy) running:
    dig @127.10.10.1 -p 5551 +dnssec www.raspberrypi.org
    Repeat this for all proxies, ensure you get a valid reply.
    Notice (this may not be the case on your system) the message ;; Truncated, retrying in TCP mode., the first line after the dig command, you entered.
    This warning is the reason why dnsmasq v2.76-5 doesn't validate DNSSEC records correctly.
    The dnscrypt developer indicated: “When local DNSSEC validation is enabled, dnsmasq 2.77 sends multiple queries on the same TCP connection which is incompatible with DNSCrypt”
    The dnsmasq developer replied: "Well, that statement may well be true, the first part, about dnsmasq, is, the second part. about dnscrypt, I'd expect to be true also, given it's source."
    So the developer needed to fix dnsmasq. AND HE DID:

dnsmasq:
Long story short; I found all of the above, trying to get dig to respond properly to the requests, sending dozens of emails back and forth with the developer. We finally were sure dig was getting the correct response by trying the instructions in this document. The document itself references explanations.
So the dnsmasq developer rewrote, resulting in:
WARNING: Don't do this if you're not willing to run anything else but the stable build!!!
IMPORTANT: you need to disable DNSSEC during this update, or you may not be able to access the required packages!!!
step 1: add the four (4) files to your system, as indicated by this document. Run sudo apt-get update
step 2: install packages required:

you need to enter q to teminate the readme

select YES to restart the services without asking

sudo apt-get -y install build-essential
sudo apt-get -y install gettext
sudo apt-get -y install libnetfilter-conntrack-dev
sudo apt-get -y install libidn11-dev
sudo apt-get -y install libdbus-1-dev
sudo apt-get -y install libgmp-dev
sudo apt-get -y install nettle-dev

sudo apt-get autoremove

step 3: IMPORTANT: remove the four (4) files (2 files in each dir) you created in /etc/apt/... . Run sudo apt-get update
step 4: create the new dnsmasq:

mkdir -p dnsmasq
cd dnsmasq
wget http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.77test4.tar.gz
tar xzf dnsmasq-2.77test4.tar.gz

cd dnsmasq-2.77test4

you'll get a lot of undefined symbol warnings, you can ignore these,

as per instructions of the developer

fakeroot debian/rules binary

cd ..

verify you have these three (3) files:

- dnsmasq_2.77-1_all.deb

- dnsmasq-base_2.77-1_armhf.deb

- dnsmasq-utils_2.77-1_armhf.deb

#Enter N to keep your current configuration
sudo dpkg -i dnsmasq*.deb

This should now show you are using version 2.77test4

dnsmasq --version

According to the developer, you can keep (backup) the three (3) .deb files.

This for future installations, avoiding the download and compilation.

Read this solution to solve the time synchronization problem, add dnssec-no-timecheck. I've created a separate dnssec.conf configuration file in /etc/dnsmasq.d:

dnssec
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
dnssec-no-timecheck

Make sure these lines are removed from 01-pihole.conf.
You can no longer use the settings page of the pihole admin website, but that wasn't an option anyway, after you installed dnscrypt-proxy.

Read this to find out, how I make my life easy, looking at the pihole log.

Finally, you should now be able to go to www.raspberrypi.org and get a log entry that says:
Feb 11 19:17:23 dnsmasq[1821]: validation result is SECURE
When testing DNSSEC on this site, (hit the start test button) you should get:
Feb 11 19:22:45 dnsmasq[636]: validation 3490-sigfail.verteiltesysteme.net is BOGUS
Feb 11 19:24:03 dnsmasq[636]: validation sigfail.verteiltesysteme.net is BOGUS

Edit: tested on an existing pihole installation, and a clean system.

2 Likes
2

  1. Thanks for the great work

  2. Sorry, but I'm a bit confused. I have a running dnscrypt following the wiki but I plan a reinstall next week. Where supersedes your comments the wiki please ?

  3. Do you have experience with dnscrypt servers out of the fourteen eyes countries ?

Thanks

3

I started out, using the information in the wiki, and build on top of that, looking for dnscrypt-proxy servers that use port 443, support DNSSEC, don't keep a log and have a secure valid certificate.
Compared to the wiki, I've added some settings, to enable logging of dnscrypt-proxy messages, (/var/log/dnscrypt-proxy.log) and improve privacy (ephemeral-keys). I've also changed the restart method. I changed the port (wiki uses port 41) to a port, unique for every proxy, this to ease debugging, I just don't like using ports below 1024. The port numbers have been suggested by the developer of dnscrypt-loader, I don't recommend using this method, read this to find out more (this entry also contains a solution for the random number problem). Some of the additional settings have been suggested by qpad. To make life easier, I provided the rar file, just to save some time for potential users. The resolvers I use, are resolvers that get me a working DNSSEC solution, my ultimate goal. There maybe other resolvers that work!

The fourteen eyes countries: I'm living in one of them, and 3 out 4 dnscrypt-proxy servers I use are in one of those countries. I'm fairly convinced that big brother is watching all of the time, nothing you can do about it, apart from going offline altogether. It isn't even my goal to stop them. The goal I'm trying to achieve is to stop my provider from serving me personalized ads (they do that over here) and to ensure the DNS replies are coming from the resolver of my choice. Of course, the question remains: do you trust the dnscrypt-proxy servers?
Using multiple resolvers (I've read somewhere you can use up to six, without recompiling) makes it harder for big brother to track my internet activity, the down side of it is of course it may just increase their interest.
That being said, It may be a good idea to use dnscrypt-proxy servers outside the fourteen countries, but your request may still be noticed (you have to get out of the country first - if you live in one of them).

1 Like
4

Thanks die the clear answers.

5

@jpgpi250 What do you think of this feature request? :

6

The way I read this, your main concern is privacy.

So, don't use your ISP resolvers. The pi-hole installation doesn't support it, but nothing keeps you from creating /etc/dnsmasq.d/99-resolvers.conf, containing as many SERVER entries as you want, then remove the SERVER settings from /etc/dnsmasq.d/01-pihole.conf and /etc/pihole/setupVars.conf (this will keep you from using the settings page, but survives a pihole update without modifications). This way, the resolvers that do keep a log are all messed up, as none of them contains the full picture of what it is you are doing. If you find resolvers that don't keep logs, you can use these, just make sure you find enough of them (and trust them to do what they claim).

You found the article, use dnscrypt-proxy, just make sure you use resolvers that use port 443. I've read somewhere (can't find it anymore) that the default compilation allows up to six (6) resolvers. If you don't care witch resolvers are used, dnscrypt-proxy allows a random resolver setup, e.g. use any resolver from the list that doesn't keep logs.

Again, don't use your ISP resolvers. Use resolvers outside the UK, preferably outside the fourteen eye countries, as indicated by Koent in one of the above posts.

I think, the more measures you take to protect your privacy, the more you risk you take to get their attention.
Given the recent articles I've been reading (hacking by the CIA), I'm convinced the best protection is to deny devices internet access altogether, e.g. if you don't use the smart functions of your television, just block it's (fixed) IP in your firewall, deny the management (fixed) IP's of switches and other devices internet access
Running a private DNS server (or cache) seems an overkill for private networks, It just increases the burden of maintaining them, creates an extra point of failure, and, eventually, you will have to get the data from the outside world anyway.
For now, I'll stick to pi-hole, dnscrypt-proxy and DNSSEC (requires upgraded dnsmasq).

7

Thanks for your thoughts, very interesting. Especially randomly distributing DNS requests over multiple upstream servers, very nice idea.

Still, I'd like to find a version where external requests are limited as much as possible, except for a once-a-week/month update of the local DNS data, and an obfuscated query in case of a rare miss.

I don't mind risking 'getting their attention'. If enough average citizens start using this, then this will no longer be a signal. There are lots of reasons to want privacy like this, I shouldn't have to think 'ooh, what will the spy agencies think about this'. That's the whole point, not wanting to think "what would they think", which I find more and more people do now. Thoughts like "How will it look to the authorities if I visit this website.. hmm, better not visit it." are a subtle loss of freedom, and can be detrimental to democracy.

Funny that you mention denying internet all together, because that is something I'm also developing. But I'd rather not go into that one online.

User @DanSchaper has his own upstream resolver already: