How to fix Pi-hole FTL error: EDE: DNSSEC bogus
If you are instead searching for an explanation of the error code have a look at RFC 8914.
I noticed that the DNS resolution on my secondary Pi-hole instance wasn't working. host
wouldn't resolve a single DNS name. As the /etc/resolv.conf
included only the DNS servers running on localhost (127.0.0.1
and ::1
) DNS resolution didn't work at all. Naturally I started looking at the Pi-hole logfiles.
/var/log/pihole/pihole.log
would log this for all domains.
Jun 4 00:02:54 dnsmasq[4323]: query 1.de.pool.ntp.org from 127.0.0.1
Jun 4 00:02:54 dnsmasq[4323]: forwarded 1.de.pool.ntp.org to 127.0.0.1#5335
Jun 4 00:02:54 dnsmasq[4323]: forwarded 1.de.pool.ntp.org to ::1#5335
Jun 4 00:02:54 dnsmasq[4323]: validation 1.de.pool.ntp.org is BOGUS
Jun 4 00:02:54 dnsmasq[4323]: reply error is SERVFAIL (EDE: DNSSEC bogus)
Ok that was a first hint. I checked /var/log/pihole/FTL.log
and there would be this message repeated all over again.
2025-06-03 00:02:52.505 CEST [841/T22762] ERROR: Error NTP client: Cannot resolve NTP server address: Try again
2025-06-03 00:02:52.509 CEST [841/T22762] INFO: Local time is too inaccurate, retrying in 600 seconds before launching NTP server
NTP is not the culprit
I checked the local time and it matched the time on the primary Pi-hole instance. Strange. I even opened https://uhr.ptb.de/ which is the official time clock for Germany (yes, per law). And it matched to the second. timedatectl
would also print the correct time for both UTC and CEST and state that the system clock is synchronized.
root@host:~# timedatectl
Local time: Wed 2025-06-04 00:51:07 CEST
Universal time: Tue 2025-06-03 22:51:07 UTC
RTC time: n/a
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
What the heck was going on?
Unbound leftovers
I googled "EDE: DNSSEC bogus" dnsmasq
and found the solution in https://www.reddit.com/r/pihole/comments/zsrjzn/2_piholes_with_unbound_breaking_dns/.
Turns out I forgot to execute two critical steps.
- I didn't delete
/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
- I didn't comment out the line starting with
unbound_conf=
in/etc/resolvconf.conf
Or they came back, when I updated that Raspberry from Debian Bullseye to Bookworm today. Anyway after doing these two steps and restarting Unbound it now works flawlessly.
And I learned which files are not kept in sync by nebula-sync. 😉