Unbound DNSSec not working?

Help
1

Using a newly installed Pi-hole with my raspberry pi 2b+, I wanted to add unbound which I installed with use of this (official) install manual: Redirecting...
DDNSSec is switched off in Pi Hole.

DNSSec validation works properly if you use the manual's 'test':

          dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5353 # returns SERVFAIL 
          dig sigok.verteiltesysteme.net @127.0.0.1 -p 5353 # returns NOERROR

However. Using other sites to verify that DNSSec is working (like: https://www.cyberciti.biz/faq/unix-linux-test-and-validate-dnssec-using-dig-command-line/), it fails to add an AD flag to the result.

https://dnssec-analyzer.verisignlabs.com alsof fails:

 	No DS records found for google.com in the com zone
	No DNSKEY records found
	www.google.com A RR has value 172.217.20.68
	No RRSIGs found

https://dnssec.vs.uni-due.de/ shows:
"No, your DNS resolver does NOT validate DNSSEC signatures."

Lastly, https://internet.nl/ states:

## Signed domain name (DNSSEC)
Too bad! Your domain is *not* signed with a valid signature ([DNSSEC](https://internet.nl/faqs/dnssec/)).

Is this a problem? How to solve it?

This is myUnbound config file:

server:
# If no logfile is specified, syslog is used
# logfile: "/var/log/unbound/unbound.log"

# Level 2 gives detailed operational information
verbosity: 2

port: 5353
do-ip4: yes
do-udp: yes
do-tcp: yes

# May be set to yes if you have IPv6 connectivity
do-ip6: no

# Use this only when you downloaded the list of primary root servers!
# root-hints: "/var/lib/unbound/root.hints"

# Respond to DNS requests on all interfaces
interface: 0.0.0.0
# Maximum  UDP response size, default is 4096
max-udp-size: 3072

# IPs authorized to access the DNS Server
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.1 allow
access-control: 192.168.1.0/24 allow
# If you have a guest network with a separate DHCP range
#access-control: 172.16.1.0/24 allow
#access-control: 10.0.0.0/24 allow

# Hide DNS Server info
hide-identity: yes
hide-version: yes

# Trust glue only if it is within the servers authority
harden-glue: yes

# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes

# Burdens the authority servers, not RFC standard, and could lead to performance problems
harden-referral-path: no

# Add an unwanted reply threshold to clean the cache and avoid, when possible, DNS poisoning
unwanted-reply-threshold: 10000000

# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no

# Reduce EDNS reassembly buffer size.
# Suggested by the unbound man page to reduce fragmentation reassembly problems
edns-buffer-size: 1472

# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# Fetch the DNSKEYs earlier in the validation process, which lowers the latency of requests
# but also uses a little more CPU
prefetch-key: yes

# Time To Live (in seconds) for DNS cache. Set cache-min-ttl to 0 remove caching (default).
# Max cache default is 86400 (1 day).
cache-min-ttl: 3600
cache-max-ttl: 86400

# If enabled, attempt to serve old responses from cache without waiting for the actual
# resolution to finish.
# serve-expired: yes
# serve-expired-ttl: 3600

# Use about 2x more for rrset cache, total memory use is about 2-2.5x
# total cache size. Current setting is way overkill for a small network.
# Judging from my used cache size you can get away with 8/16 and still
# have lots of room, but I've got the ram and I'm not using it on anything else.
# Default is 4m/4m
msg-cache-size: 128m
rrset-cache-size: 256m

# One thread should be sufficient, can be increased on beefy machines.
# In reality for most users running on small networks or on a single machine it should
# be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1

# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 1m

# Ensure privacy of local IP ranges
private-address: 192.168.1.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10

# Create DNS record for Pi-Hole Web Interface
private-domain: "pi.hole"
local-zone: "pi.hole" static
local-data: "pi.hole IN A 192.168.1.4"
3

"Yes, your DNS resolver validates DNSSEC signatures."

Latest Pihole + Unbound 1.9.0
in Pihole "settings"/DNS: Use DNSSEC is disabled.

It works in my setup. At least this is what https://dnssec.vs.uni-due.de/ reports.

5

Yes. It's switched off.

image
image980×789 52.6 KB

I'm using Pi Hole v5.2.1.
Unbound version 1.9.

6

I added proxy-dnssec to my /etc/dnsmasq.d/01-pihole.conf but it did not change anything.
Its just the lines proxy-dnssec right, nothing else beside the standard config?

And I dont understand the part about the cache size. I'm not that knowledgable.

Thanks for the reply anyway!

7

All the indications are that unbound is properly performing the DNSSEC function. The two tests specified in the Pi-hole unbound guide have verified this to be the case.

This site you are using (https://dnssec-analyzer.verisignlabs.com) does not test your DNS server for DNSSEC. It reports the records it has found for the domain of interest. This is the same result regardless of what DNS server you use with Pi-hole.

Have you verified that (1) the client on which you are running that browser is using Pi-hole (and thus unbound) for DNS resolution and (2) that the browser on which you ran the test is not using private or secure DNS which would bypass Pi-hole?

This is a test that a domain is properly configured for DNSSEC and should have no relationship to whether unbound is properly handling DNSSEC.

2 Likes
9

I don't think any of this is fixing a DNSSEC problem that doesn't appear to exist. The tests run directly on unbound show that DNSSEC in unbound is working properly.

10

Setting the Pi-hole cache to 0 will cause an error if you try to start pihole-FTL with DNSSEC enabled. pihole-FTL will not start.

12

Thanks for your reply.

I'll just focus on https://dnssec.vs.uni-due.de then.
How should I verify that the client is using Pi-Hole? If I look at the Pi-Hole dashboard I see it's ip adress is registered.
Doing this I discovered the following: https://dnssec.vs.uni-due.de isn't working on my other Windows 10 laptop either. However, it's working on my android smartphone. Would it be a JavaScript problem (i've installed JS on both computers)? JavaScript is enabled on all browsers.

Pi-hole cache is set to 0 in /etc/dnsmasq.d/01-pihole.conf which doesnt make a diference (altough I do not get any errors with my current setup.

So it would seem I shouldn't be worried about the DNSSec not validating it according to the test?

13

There is no benefit to disabling the Pi-hole cache.

From a client that you believe should be connected to the Pi-Hole for DNS, from the command prompt or terminal on that client (and not via ssh or Putty to the Pi), what is the output of

nslookup pi.hole

14

Hi jfb, thanks for the quick response this sunday!

nsloopup pi.hole

gives

Address:  192.168.1.4

Name:    pi.hole
Address:  192.168.1.4

I guess it is working but I only failed to use the beforementioned website.

According to this: https://www.cyberciti.biz/faq/unix-linux-test-and-validate-dnssec-using-dig-command-line/. It is working. But I failed to see the ad flag at some websites I assumed would have the DNSSec feature.

pi@raspberrypi:~ $ dig +sigchase +trusted-key=./keys www.cyberciti.biz. A | grep -i validation
;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
15

Just wanted to note that the official pihole/unbound guide uses port 5335 .... the old guide used port 5353, but was changed quite awhile ago. No idea if it affects your issues, just happened to notice that while looking through your config.

16

my output is different:

pi@x-pihole:~ $ nslookup pi.hole
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: pi.hole
Address: 192.168.xxx.x
Name: pi.hole
Address: fd00::xxxx:xxxx:xxxx:xxxx

17

This is showing that the Pi is using Pi-hole for DNS - this is the loopback address on port 53. What this cannot show is the upstream DNS server that Pi-hole is using. This could be Cloudflare, Google, unbound, etc and is invisible to the requesting client.

Client > Pi-hole > upstream DNS server.

The upstream DNS servers for Pi-hole are shown in the web admin dashboard and in file /etc/pihole/setupVars.conf

From a Pi-hole with the current configuration of unbound. The Pi is using Pi-hole for DNS:

nslookup pi.hole

Server: 127.0.0.1
Address: 127.0.0.1#53

Name: pi.hole
Address: 192.168.0.160

That instance of Pi-hole is using unbound as shown here:

grep PIHOLE_DNS /etc/pihole/setupVars.conf

PIHOLE_DNS_1=127.0.0.1#5335
PIHOLE_DNS_2=
18

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.