DNSSEC validation not always working

General Customizing Pi-hole
1

Hi all,

I'm using Pi-hole v5.0 with Unbound 1.10.1 (compiled), with this unbound.conf settings:

server:
# mandatory settings - do not change
tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"
chroot: "/etc/unbound"
username: "unbound"
directory: "/etc/unbound"
#logfile: "unbound.log"
root-hints: "root.hints"
pidfile: "unbound.pid"
auto-trust-anchor-file: "root.key"
# end of mandatory settings

# recommended settings
# outgoing-range: 8192
# num-queries-per-thread: 4096
# so-rcvbuf: 4M
# so-sndbuf: 4M
# access-control: 127.0.0.0/8 allow
# end of recommended settings

interface: 127.0.0.1
interface: ::1
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes

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

# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: yes

# Trust glue only if it is within the server's authority
harden-glue: yes

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

# Aggressive NSEC uses the DNSSEC NSEC chain to synthesize NXDOMAIN
    # and other denials, using information from previous NXDOMAINs answers.
    aggressive-nsec: yes

# 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

# 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$
#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.0.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

cache-min-ttl: 0
serve-expired: yes

msg-cache-size: 128m
rrset-cache-size: 256m

# Send minimum amount of information to upstream servers to enhance
# privacy. Only sends minimum required labels of the QNAME and sets
# QTYPE to NS when possible.

# See RFC 7816 "DNS Query Name Minimisation to Improve Privacy" for
# details.

    # https://ripe72.ripe.net/presentations/120-unbound_qnamemin_ripe72.pdf
    # test: drill txt qnamemintest.internet.nl
    # result: "HOORAY - QNAME minimisation is enabled on your resolver :)!"

qname-minimisation: yes
    harden-below-nxdomain: yes

remote-control:
control-enable: yes
control-interface: 127.0.0.1

auth-zone:
# local copy of the DNS root zone (hyperlocal)
# Use servers that provide zone transfer of the root zone (AXFR), see
# https://root-servers.org/faq.html and
# Zone transfer | ICANN DNS Engineering
name: "."
master: 192.5.5.241 # f.root-servers.net
master: 2001:500:2f::f # f.root-servers.net
master: 192.0.32.132 # lax.xfr.dns.icann.org
master: 192.0.47.132 # iad.xfr.dns.icann.org
master: 2620:0:2d0:202::132 # lax.xfr.dns.icann.org
master: 2620:0:2830:202::132 # iad.xfr.dns.icann.org
# Additional download via URL:
url: "https://www.internic.net/domain/root.zone"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "root.zone"

(no other conf files used)

I also enabled DNSSEC in Pi-hole settings, and I use Pi-hole as DNS Server (not DHCP server).

Now, after restarting the raspberry pi (Pi Zero W), when testing DNSSEC validation, the tests sometimes indicate that DNSSEC validation is working and sometimes that it is not. Test sites used include https://dnssec.vs.uni-due.de/ , http://www.dnssec-or-not.com/ and Connection test .

Debug log is here: https://tricorder.pi-hole.net/w64hjqyprs

What could be the reason for this? Testing with dig on the raspberry pi does give the right responses.

Thanks for your input in advance!

2

With DNSSEC, an incorrect system time may compromise DNS resolution, as cryptography used for digitally signing DNS records relies on DNS servers and your RPi using the same time frame.

Just like any RPi, a Zero lacks a real time clock (RTC), so it has to rely on syncing time with NTP servers periodically, where times could wander off a bit in between syncs.

Normally, one of the next few consecutive lookups succeeds, and this goes unnoticed, but on power cycling, it may take as long as a few minutes before you've a correct time. On large offsets, syncing may even not work at all and you'd have to set the time manually.

1 Like
3

I seem to have found the root cause: on my network, there is also a Firewalla Blue device which is supposed to provide extra safety.
I have configured the Pi-hole as DNS server in that device.

However, doing some dig tests on both the Pi-hole, Firewalla (also has a console) and a Windows laptop, I noticed that dig on firewalla does not correctly perform DNS Validation. in the Pi-hole this is always correctly done, and when I change the DNS settings on the Windows laptop directly to the Pi-hole (iso automatic, which the Firewalla is supposed to catch) then DNS validation also works as it should.

Culprit then is the Firewalla device. I will take it up further with them.

Thanks!