[guide] Using dnscrypt-proxy2 & kresd to maximize privacy & security for DNS queries

Hello, here is a small guide to use kresd & dnscrypt-proxy2 in order to maximize safety and anonymity over your dns queries.

1)Go to /etc/resolver/dns_servers and create a file to describe dnscrypt resolver.

name=“99_localhost.conf”
description=“localhost”
enable_tls=“0”
port=“5300”
ipv4=“192.168.1.1”
ipv6=""
ca_file="/etc/ssl/certs/ca-certificates.crt"
hostname=“localhost”

As you understand we will use a dnscrypt-proxy listening on port 5300 without tls. There is no need to encrypt traffic between kresd & dnscrypt-proxy.

After you create the file you should be able to select it from the dropdown list of DNS servers:

Then you need to install dnscrypt-proxy2 and configure it to your liking. Beware of the listening port.

I activated only dnssec enabled,non-logging, non-filtering, dnscrypt2 servers (not DoH), anonymized them and activated local DoH for firefox use. I also activated loadbalancing.

The end result is this:

All my DNS queries are anonymous, encrypted and verified for validity.
Firefox can also use the encrypt SNI to further enhance https privacy.
You can also activate on top dns ad blocking either via kresd or dnscrypt-proxy.

Enjoy!

Open question: Does kresd verifies unsigned dnssec queries like dnsmasq?

I don’t know what you mean exactly. Full DNSSEC validation is done (unless you explicitly disable it).

dnsmasq offers this:

–dnssec-check-unsigned[=no]
As a default, dnsmasq checks that unsigned DNS replies are legitimate: this entails possible extra queries even for the majority of DNS zones which are not, at the moment, signed. If –dnssec-check-unsigned=no appears in the configuration, then such replies they are assumed to be valid and passed on (without the “authentic data” bit set, of course). This does not protect against an attacker forging unsigned replies for signed DNS zones, but it is fast.
Versions of dnsmasq prior to 2.80 defaulted to not checking unsigned replies, and used –dnssec-check-unsigned to switch this on. Such configurations will continue to work as before, but those which used the default of no checking will need to be altered to explicitly select no checking. The new default is because switching off checking for unsigned replies is inherently dangerous. Not only does it open the possiblity of forged replies, but it allows everything to appear to be working even when the upstream namesevers do not support DNSSEC, and in this case no DNSSEC validation at all is occurring.

Does kresd offers similar checks? (or does it full trusts dns servers that they will not hide dnssec info?)

If a server doesn’t do that, it can’t be saying it validates. What would be the use if attacker could just strip all signatures?

1 Like