Trying to Disable DNSSEC for problem solving

The issue I am facing:
Some websites are breaking, and my Thunderbird is having issue with Gmail, and I suspect it's the DNSSEC. However, I don't have DNSSEC enable under Setup/DNS, I even reboot the RPI. When I tested for DNSSEC after reboot, it is “still active” as shown in the image. My set-up use unbound only and thought that was the case. How do I disable DNSSEC to see if it causes issue with some website as well as thunderbird with Gmail?

Details about my system:
Raspberry 4B+
Raspberry OS
Torguard VPN Services
DD-WRT with DHCP Disable
DD-WRT with WireGuard Services

What I have changed since installing Pi-hole:
Disable DNSSEC in unbound.

https://tricorder.pi-hole.net/UkE41LLW/

Can you please post your unbound configuration.

server:

# The  verbosity  number, level 0 means no verbosity, only errors.
# Level 1 gives operational information. Level  2  gives  detailed
# operational  information. Level 3 gives query level information,
# output per query.  Level 4 gives  algorithm  level  information.
# Level 5 logs client identification for cache misses.  Default is
# level 1.
# logfile: "/var/log/unbound/unbound.log"
verbosity: 0

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

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

# 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: no

# Use this only when you downloaded the list of primary root servers!
# Read  the  root  hints from this file. Make sure to 
# update root.hints evry 5-6 months.
root-hints: "/var/lib/unbound/root.hints"

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

# Ignore very large queries.
harden-large-queries: yes

# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
# If you want to disable DNSSEC, set harden-dnssec stripped: no
harden-dnssec-stripped: no

# Number of bytes size to advertise as the EDNS reassembly buffer
# size. This is the value put into  datagrams over UDP towards
# peers. The actual buffer size is determined by msg-buffer-size
# (both for TCP and UDP).
edns-buffer-size: 1232

# Rotates RRSet order in response (the pseudo-random 
# number is taken from Ensure privacy of local IP 
# ranges the query ID, for speed and thread safety).  
# private-address: 192.168.0.0/16
rrset-roundrobin: yes

# Time to live minimum for RRsets and messages in the cache. If the minimum
# kicks in, the data is cached for longer than the domain owner intended,
# and thus less queries are made to look up the data. Zero makes sure the
# data in the cache is as the domain owner intended, higher values,
# especially more than an hour or so, can lead to trouble as the data in
# the cache does not match up with the actual data anymore
cache-min-ttl: 300
cache-max-ttl: 86400

# Have unbound attempt to serve old responses from cache with a TTL of 0 in
# the response without waiting for the actual resolution to finish. The
# actual resolution answer ends up in the cache later on. 
serve-expired: yes

# Harden against algorithm downgrade when multiple algorithms are
# advertised in the DS record.
harden-algo-downgrade: yes

# Ignore very small EDNS buffer sizes from queries.
harden-short-bufsize: yes

# Refuse id.server and hostname.bind queries
hide-identity: yes

# Report this identity rather than the hostname of the server.
identity: "Server"

# Refuse version.server and version.bind queries
hide-version: yes

# Prevent the unbound server from forking into the background as a daemon
do-daemonize: no

# Number  of  bytes size of the aggressive negative cache.
neg-cache-size: 4m

# Send minimum amount of information to upstream servers to enhance privacy
qname-minimisation: yes

# Deny queries of type ANY with an empty response.
# Works only on version 1.8 and above
deny-any: yes

# Do no insert authority/additional sections into response messages when
# those sections are not required. This reduces response size
# significantly, and may avoid TCP fallback for some responses. This may
# cause a slight speedup
minimal-responses: yes

# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
# This flag updates the cached domains
prefetch: yes

# Fetch the DNSKEYs earlier in the validation process, when a DS record is
# encountered. This lowers the latency of requests at the expense of little
# more CPU usage.
prefetch-key: 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-threads above 1.
num-threads: 2

# more cache memory. rrset-cache-size should twice what msg-cache-size is.
msg-cache-size: 50m
rrset-cache-size: 100m

# Faster UDP with multithreading (only on Linux).
so-reuseport: yes

# Ensure kernel buffer is large enough to not lose messages in traffix spikes
so-rcvbuf: 4m
so-sndbuf: 4m

# Set the total number of unwanted replies to keep track of in every thread.
# When it reaches the threshold, a defensive action of clearing the rrset
# and message caches is taken, hopefully flushing away any poison.
# Unbound suggests a value of 10 million.
unwanted-reply-threshold: 100000

# Minimize logs
# Do not print one line per query to the log
log-queries: no
# Do not print one line per reply to the log
log-replies: no
# Do not print log lines that say why queries return SERVFAIL to clients
log-servfail: no
# Do not print log lines to inform about local zone actions
log-local-actions: no
# Do not print log lines that say why queries return SERVFAIL to clients
logfile: /dev/null

# 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

● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-05-24 14:36:42 AEST; 4s ago
Docs: man:unbound(8)
Process: 16855 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
Process: 16858 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
Main PID: 16862 (unbound)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/unbound.service
└─16862 /usr/sbin/unbound -d

May 24 14:36:41 raspberrypi systemd[1]: Starting Unbound DNS server...
May 24 14:36:42 raspberrypi package-helper[16858]: /var/lib/unbound/root.key has content
May 24 14:36:42 raspberrypi package-helper[16858]: success: the anchor is ok
May 24 14:36:42 raspberrypi systemd[1]: Started Unbound DNS server.

What OS is running on the client(s)?

Clients !
iMac Big Sur 11.6.5, this OS is pushing out "doh.dns.apple.com" even though I personally never touch Safari. But this domain is blocked since it leaks info.
WireGuard is the only program running on DD-WRT. And no other special setting either.
Everything goes through the VPN.

I'm looking more into the DNSSEC situation at present.

Can you run some digs for domains that are showing you errors? And also check the Pi-hole admin interface to see what the logged query status shows?

Also, you can use pihole-FTLs configuration file to expose the internal queries that Pi-hole would use for DNSSEC up and down.

https://docs.pi-hole.net/ftldns/configfile/#show_dnssec

This will not help, there is a reason why, DNSSEC can't be disabled, it comes to my attention last night while digging around on the Internet that various VPN providers have quietly implemented DNSSEC by default on their system. Which is a surprise to me, so I run some test on the VPN's.

With both Torguard and free ProtonVPN desktop apps, I worked each separately over time, it helped to bypass pi-hole and ran the provider's VPN desktops app through my Wi-Fi, which is connected to the ISP modem, not my standard router.

For each vpn services, I checked against several sites by various browsers to verify DNSSEC connection, well it true, the Torguard and ProtonVPN both have DNSSEC running on their system by default. The only way to bypass the DNSSEC is disabling VPN services.

Now, the bigger question is, if the user is using VPN services that have DNSSEC services enable. Does the user need unbound DNSSEC enables ?

Hope this helps.

DNSSEC doesn't quite work that way. All DNSSEC does is sign the records so that you can tell if the query response was modified in route. Having an upstream or a provider with DNSSEC enabled doesn't change the records at all. You can have a client or Pi-hole with DNSSEC disabled and a provider with DNSSEC enabled. You just wont have the verification of the record if it was signed. And not many domains/zones are actually signed.

Yes, otherwise you're just doing a plain query and won't use the DNSSEC information (if provided) to verify the query response.

I think you may be confusing DoT or DoH that set up encrypted connections between the client and the resolver?

1 Like

I understand what saying is true, and I also know how these two, DoT or DoH function and how each handle queries differentially. If I disable the vpn, then website work, enable vpn and some website break. I founded out that Pi-hole and DNSSEC work with the broke site, it's a vpn issue, I take the issue up with the VPN providers. Sorry for troubling you.

1 Like

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