Pihole-unbound: Unbound returns SERVFAIL on some domains

Hey all, I’ve been having this issue for a while now and troubleshooting has been driving me crazy. Maybe someone more knowledgeable can help figure out what’s going on.

About a week ago I noticed that when using my pihole-unbound DNS server, very specific domains always fail to resolve when previously they would be resolved correctly. It is very particular which domains fail, the vast majority of domains I visit get resolved. The following domains always fail to resolve on any device using pi-hole:

After taking a look at the pihole WebUI’s query log, I noticed that every query that fails to resolve had the same SERVFAIL message in the reply column: (Using duck.ai as the affected domain)

This pointed me to the issue being with Unbound, so I used docker exec to add the following lines to the end of /etc/unbound/unbound.conf to generate a log file:

    verbosity: 1
    log-servfail: yes
    log-replies: yes
    log-queries: yes

Here are the contents of said newly created log: (Using debian.org as the affected domain)

[1734580590] unbound[944:0] info: start of service (unbound 1.13.1).
[1734580595] unbound[944:0] info: 127.0.0.1 debian.org. A IN
[1734580596] unbound[944:0] info: generate keytag query _ta-4f66. NULL IN
[1734580597] unbound[944:0] info: validation failure <debian.org. A IN>: No DNSKEY record from 192.36.148.17 for key debian.org. while building chain of trust
[1734580597] unbound[944:0] info: 127.0.0.1 debian.org. A IN SERVFAIL 2.088680 0 39
[1734580597] unbound[944:0] info: 127.0.0.1 debian.org. A IN
[1734580597] unbound[944:0] info: 127.0.0.1 debian.org. A IN SERVFAIL 0.000000 1 39
[1734580597] unbound[944:0] info: 127.0.0.1 debian.org. A IN
[1734580597] unbound[944:0] info: 127.0.0.1 debian.org. A IN SERVFAIL 0.000000 1 39
[1734580597] unbound[944:0] info: 127.0.0.1 debian.org. A IN
[1734580597] unbound[944:0] info: 127.0.0.1 debian.org. A IN SERVFAIL 0.000000 1 39
[1734580598] unbound[944:0] info: 127.0.0.1 debian.org. A IN
[1734580598] unbound[944:0] info: 127.0.0.1 debian.org. A IN SERVFAIL 0.000000 1 28
[1734580598] unbound[944:0] info: 127.0.0.1 debian.org. A IN
[1734580598] unbound[944:0] info: 127.0.0.1 debian.org. A IN SERVFAIL 0.000000 1 28
[1734580607] unbound[944:0] info: 127.0.0.1 google.com. A IN
[1734580607] unbound[944:0] info: 127.0.0.1 accounts.youtube.com. A IN
[1734580607] unbound[944:0] info: 127.0.0.1 google.com. A IN NOERROR 0.351449 0 55
[1734580607] unbound[944:0] info: 127.0.0.1 accounts.youtube.com. A IN NOERROR 0.144987 0 93
[1734580607] unbound[944:0] info: 127.0.0.1 google.com. AAAA IN
[1734580607] unbound[944:0] info: 127.0.0.1 www3.l.google.com. TYPE65 IN
[1734580607] unbound[944:0] info: 127.0.0.1 google.com. AAAA IN NOERROR 0.030153 0 67
[1734580607] unbound[944:0] info: 127.0.0.1 www3.l.google.com. TYPE65 IN NOERROR 0.038562 0 96
[1734580614] unbound[944:0] info: 127.0.0.1 rr1---sn-vgqsknly.googlevideo.com. A IN
[1734580615] unbound[944:0] info: 127.0.0.1 rr1---sn-vgqsknly.googlevideo.com. A IN NOERROR 0.258469 0 97

Now this is where I’m out of my depth. The line No DNSKEY record from 192.36.148.17 for key debian.org. while building chain of trust is of particular interest to me, as it seems to be where the issue resides, but I’m not experienced enough with unbound or DNSSEC to understand how to solve it, or really what it fully means to be honest.

Here’s what I have already tried in my troubleshooting:

  • Verify the CasaOS server date/time/timezone is correct
  • Verify the TZ environment variable for the container is set to the local timezone
  • Export config, delete pihole-unbound from CasaOS UI, then reinstall from config
  • Verify DNSSEC is NOT enabled in pi-hole
  • Inside container, delete /var/lib/unbound/root.key + run unbound-anchor (As suggested here)

I haven’t had any luck so far. Any solutions or troubleshooting tips would be greatly appreciated!

Hey all, I think I’ve found my issue: DNS Hijacking!! Unbound was doing the correct thing by rejecting those domains, they’re protected by DNSSEC and thus it immediately knew something was wrong.

I noticed that when using ipleak.net the DNS server shown is not my public IP address nor is it any of the servers in my pihole config (I had switched back to resolving through public DNS servers). So, thinking it strange, I started investigating DNSSEC.

On a test system, I ran the following command:

user@test:~$ delv @1.1.1.1 debian.org
;; truncated TCP response resolving './DNSKEY/IN': 1.1.1.1#53
;; broken trust chain resolving 'org/DS/IN': 1.1.1.1#53
;; broken trust chain resolving 'org/DNSKEY/IN': 1.1.1.1#53
;; broken trust chain resolving 'debian.org/DS/IN': 1.1.1.1#53
;; broken trust chain resolving 'debian.org/DNSKEY/IN': 1.1.1.1#53
;; broken trust chain resolving 'debian.org/A/IN': 1.1.1.1#53
;; resolution failed: broken trust chain

As you can see, the DNS query fails as expected because of a DNSSEC failure. However, if I then connect my test system to a Wireguard VPN, thereby bypassing my ISP, I get the following (successful) output:

user@test:~$ delv @1.1.1.1 debian.org             
; fully validated
debian.org.             300     IN      A       151.101.2.132
debian.org.             300     IN      A       151.101.66.132
debian.org.             300     IN      A       151.101.130.132
debian.org.             300     IN      A       151.101.194.132
debian.org.             300     IN      RRSIG   A 8 2 300 20250514115654 20250404115311 6004 debian.org. i7CPqqsn//+Vn2VDfdGDgvXtBcYJAIXtre/8GCb9AKLtlnP2yJWVI7GB cTK9nODtGZo66P3NNK1TAr7kpegrkhycmqCOK0mSha3JnNg9omNRIhZo ziDWN9txkEGYFznFh101ROOwgQR1nrUN65wmAs2XNAYDooowsRJ8mxJk +VL3bMhBpZUgAZb9VnMSfxYS7wIgR/8Ft6TuLLamF/AmqW1qXeyWogcH uwC9kSbzxdYFz1MFUNQkrlZPC9ZQcUPs

I get the same results using any other public DNS server that supports DNSSEC, so it’s not cloudflare’s fault. I’m suspecting something is up with my ISP provided router, I’m thinking of replacing it with something running OpenWRT. The idea that my DNS queries aren’t going where I’m sending them is terrifying! And if replacing the router doesn’t work? Well, I might just end up routing all my DNS traffic over a VPN.