5

I have been doing an effort to go full on DNSSEC on my system with the following setup:

  • dnscrypt-proxy installed, up and running on 127.0.0.1 with require_dnssec = true
  • systemd-resolved running, with DNSSEC=yes and DNS=127.0.0.1
  • only nameserver 127.0.0.1 in /etc/resolv.conf
  • connected through NetworkManager to a WiFi network about which I know DHCP configuration sets 8.8.8.8 and 8.8.8.4 as DNS servers

/run/systemd/resolve/resolv.conf lists 8.8.8.8 and 8.8.8.4 below 127.0.0.1.

resolvectl status shows

DNSSEC setting: yes
DNSSEC supported: yes
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1

in the Global section, but

 DNSSEC setting: yes
 DNSSEC supported: yes
 Current DNS Server: 8.8.8.8
 DNS Servers: 8.8.8.8
                           8.8.8.4

in my interface's section (why?).

tcpdump shows no activity at all on udp:53 when using a web browser, dig, or other normal usage. This I take to mean that my local dnscrypt-proxy is dealing with all DNS requests on my system. I also assume that because of the configuration settings mentioned above, I am going DNSSEC all the way.

However, from time to time the journal contains lines like:

Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question bolt.v.dropbox.com IN DS: failed-auxiliary
Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question bolt.v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question bolt.v.dropbox.com IN A: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d.v.dropbox.com IN A: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d.v.dropbox.com IN A: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d2e801s7grwbqs.cloudfront.net IN SOA: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d2e801s7grwbqs.cloudfront.net IN A: failed-auxiliary
  • resolvectl query v.dropbox.com results in the same DNSSEC validation error
  • dig v.dropbox.com works just fine
  • dig v.dropbox.com @8.8.8.8 also works just fine (of course resulting in two lines of output for tcpdump)

I also checked https://dnsleaktest.com, which tells me that a lot of 172.253.x.x servers are receiving a request to resolve domain names I enter into my webbrowser. These IPs seem to be owned by Google.

So, what does this mean? Is there any (non DNSSEC) querying going on on this system?

Any insights are appreciated!

Bart Van Loon
  • 153
  • 5
  • make sure /etc/systemd/resolved.conf : DNSStubListener=yes/no is to your liking. – dotbit Dec 10 '19 at 15:17
  • resolved.conf(5) doesn't really help me in figuring out the relevance of this entry. It is set to no, but would never resultin a stub since dnscrypt is already listening on port 53. Am I missing something? – Bart Van Loon Dec 11 '19 at 23:23

1 Answers1

2

If both dnscrypt-proxy and systemd-resolved are using 127.0.0.1:53, this should not be the case. You need to disable systemd-resolved as recommended by dnscrypt-proxy wiki, and also lock /etc/resolv.conf for possible changes made by your Network Manager. So, here are the steps:

  • Disable systemd-resolved:
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved

  • Check if there is anything else using the same address:port pair as dnscrypt-proxy: sudo ss -lp 'sport = :domain'. If there are, disable them.

  • If dnscrypt-proxy is listening on 127.0.0.1:53 and resolv.conf has nameserver 127.0.0.1, add options edns0(required to enable DNS Security Extensions) below the nameserver entry in resolv.conf so that it looks like:

nameserver 127.0.0.1
options edns0
  • Lock /etc/resolv.conf file for changes: sudo chattr +i /etc/resolv.conf.
  • You might want to restart dnscrypt-proxy.

Overall, the point is to make sure that:

  • Only dnscrypt-proxy is using 127.0.0.1:53
  • resolv.conf has the same address used by dnscrypt-proxy
  • resolv.conf is protected from changes made by other software such as your Network Manager.

Also, just because the dnsleak test shows Google IPs does not mean that the dns resolver service is operated by Google. It could be that the servers are owned by Google but operated by another entity. If you dont' want it, you can choose a different resolver from dnscrypt-proxy public resolvers list. Make sure that dnssec support is present for the selected resolver. I personally use dnscrypt.eu resolvers, which are no-log, no-filter, non-google and dnssec-enabled.

References:

kmotoko
  • 441
  • 1
  • 4
  • 11
  • Amazing, thank you so much. I indeed needed to simply read the `dnscrypt-proxy` documentation in more detail... Things seem to be working as expected now. – Bart Van Loon Dec 30 '19 at 13:41