[pihole] [unbound] [DNSMASQ] validation failed: resource limit exeeded

The issue I am facing:

I got the repeatly warning of dnsmasq_warning, that "validation of google.com failed: resource limit exceeded."

How can i proceed?
Shall i ignore the message of DNSMASQ_core as only an DNSMASQ_warning or how can i adjust the resource limit, so the validation will be completed?

The linked documentation didn't give me any further hint how to proceed here.
A further started google search does not give me any relatable information.

Any simply deletion of this error/warning only leads to the warning periodically reappearing in the pihole admin panel (backend).

Details about my system:

pihole v5.17.3 / FTL v5.25 / web interface: v5.21
OS: dietpi v9.0.2 ( debian Bullseye / Linux 6.1.21-v7+ armv7l)
raspberry pi 3B Model 4GB

What I have changed since installing Pi-hole:

installation and integration of unbound with official pihole/unbound tutorial found at unbound - Pi-hole documentation

This is a new warning available as of FTL v5.25 building on dnsmasq v2.90 so it is very new and your findings here may really be the first ones on the web. This is part of the recently added protection against a DNSSEC vulnerability that could take down your Pi-hole in a denial-of-service kind of attack. More details here:

Please run

sudo kill -s SIGUSR1 $(cat /var/run/pihole-FTL.pid)
grep "DNSSEC per-" /var/log/pihole/pihole.log

and quote the output here. Another question: Is the unbound you've set up your sole upstream server?

Depending on the result of the commands above, we may need to increase the validation limit.

We need to add this, thanks for the reminder!

root@DietPi:~# sudo kill -s SIGUSR1 $(cat /var/run/pihole-FTL.pid)

root@DietPi:~# grep "DNSSEC per-" /var/log/pihole/pihole.log
Feb 17 10:32:25 dnsmasq[3008]: DNSSEC per-query subqueries HWM 10
Feb 17 10:32:25 dnsmasq[3008]: DNSSEC per-query crypto work HWM 20
Feb 17 10:32:25 dnsmasq[3008]: DNSSEC per-RRSet signature fails HWM 0

pihole / unbound as sole DNS-upstream provider on Fritzbox
pihole and unbound are set as the only (available) DNS-Upstream-Provider on my AVM Fritzbox 7590AX (latest OS V7.8 installed) so no DNS-request on my network setup can bypass and by accidentally answered by fritzbox as an (main / sole) router

Thank you for all of your help!

Interesting, please try

echo "dnssec-limits=100,1000,200,750" | sudo tee /etc/dnsmasq.d/99-dnssec-limits.conf
sudo service pihole-FTL restart

Whether or not the warning appears again, I'd be very interested in the output of the two commands above after some time as we may need to report upstream that the currently chosen default limits are too low.

2024-02-17 17_36_01- - PuTTY

root@DietPi:~# echo "dnssec-limits=100,1000,200,750" | sudo tee /etc/dnsmasq.d/9                                                                        9-dnssec-limits.conf

root@DietPi:~# sudo service pihole-FTL restart

I've had the same problem since the last update.
Apparently it only occurs when I use unbound as an upstream server. When I enter my ISP's DNS server it doesn't seem to happen.
Raspberry Pi 3B+, Raspberry OS Lite bullseye, Pi-hole v5.17.3 FTL v5.25 Web Interface v5.21

@Karlo3000 Hmm, interesting. I'm running a sole unbound upstream as well and haven't seen it so far. Could you also try setting a higher limit using

and later report back to us the actual numbers found on your system


I hope @the-piholer will keep us updated as well after some testing :slight_smile:

Out of interest, question applying to both of you: Are you already using a version of unbound where said DNSSEC issue is fixed (version 1.19.1 and newer)?

1 Like

Saw a similar error. I'm using unbound upstream, but also a secondary pihole. Seeing these errors every 12 hours or so. Infrequently, but was curious.

I just added the dnssec-limits conf, hopefully that resolves.

After updating I grepped the pihole.log as requested above. adding my output to help the team:

Feb 17 19:37:17 dnsmasq[468554]: DNSSEC per-query subqueries HWM 6
Feb 17 19:37:17 dnsmasq[468554]: DNSSEC per-query crypto work HWM 15
Feb 17 19:37:17 dnsmasq[468554]: DNSSEC per-RRSet signature fails HWM 0

For what it's worth, it doesn't look like an unbound through version 1.19.1 is available for RaspOS on Rpi5 and apt currently only updates through unbound/stable-security,now 1.17.1-2+deb12u2 arm64.

According to these Debian pages, version 1.17.1-2+deb12u2 has been fixed:

1 Like

Thank you. That makes sense. The update to the current version was this week.

I'm using the last available version via apt: unbound:arm64/bullseye-security 1.13.1-1+deb11u2

After I adjusted the limits, the message appeared again after a few hours


Feb 18 08:05:58 dnsmasq[37643]: DNSSEC per-query subqueries HWM 4
Feb 18 08:05:58 dnsmasq[37643]: DNSSEC per-query crypto work HWM 12
Feb 18 08:05:58 dnsmasq[37643]: DNSSEC per-RRSet signature fails HWM 0

btw: thank you for your great work and support!

1 Like

Hello DL6ER

im still using: unbound Version 1.13.1 (latest given stable version of debian release bullseye on dietpi)
I set already the limit to dnssec-limits=100,1000,200,750

sudo kill -s SIGUSR1 $(cat /var/run/pihole-FTL.pid)
grep "DNSSEC per-" /var/log/pihole/pihole.log

Output again

Feb 18 07:32:04 dnsmasq[15605]: DNSSEC per-query subqueries HWM 9
Feb 18 07:32:04 dnsmasq[15605]: DNSSEC per-query crypto work HWM 26
Feb 18 07:32:04 dnsmasq[15605]: DNSSEC per-RRSet signature fails HWM 0

The warnings do not reappeared in the meantime

1 Like

Interesting! See below why. First, let's take a look at the definition of this option I wanted you to set:

Override the default resource limits applied to DNSSEC validation. Cryptographic operations are expensive and crafted domains can DoS a DNSSEC validator by forcing it to do hundreds of thousands of such operations. To avoid this, the dnsmasq validation code applies limits on how much work will be expended in validation. If any of the limits are exceeded, the validation will fail and the domain treated as BOGUS.

There are four limits, in order(default values in parens):

  • number a signature validation fails per RRset(20), [now 100]
  • number of signature validations and hash computations per query(200), [now 1000]
  • number of sub-queries to fetch DS and DNSKEY RRsets per query(40), [now 200] and the
  • number of iterations in a NSEC3 record(150) [now 750].

The maximum values reached during validation are stored, and dumped as part of the stats generated by SIGUSR1. Supplying a limit value of 0 leaves the default in place, so --dnssec-limits=0,0,20 sets the number of sub-queries to 20 whilst leaving the other limits at default values.

Formating and comments in italics added by me.

Unfortunately, there is no logging for the last limit (NSEC3). Please run

pihole checkout ftl tweak/nsec3_iters_warning

and - when the warning reappears - also run

grep "NSEC3 iterations" /var/log/pihole/FTL.log

to confirm my theory that it is this last of the four limits that is exceeded here - even though we increased it from 150 -> 750 already.

IMPORTANT Do not run this command when you are currently using the v6 beta. This branch is only meant for those currently using Pi-hole FTL v5.25 (there will be an error if you are on the v6 beta preventing your from running above's command, though).

The error is only triggered by one client (of about 30) - my wife's smart phone :face_with_hand_over_mouth:
I can reproduce the error immediately by restarting the WLAN on the smartphone.

I checked the 99-dnssec-limits.conf several times and restarted the rasperry pi.


No NSEC3 entries in FTL.log

pihole.log looks like yesterday

I'll check the log files later to see what happens when I restart the WiFi

@DL6ER I have narrowed down the problem as much as I can:

  • DNS1:

  • Rasperry Pi 3B+, Raspberry OS Lite bullseye

  • Pi-hole v5.17.3 FTL v5.25 Web Interface v5.21 / FTL tweak nsec3_iters_warning

  • Unbound 1.13.1-1+deb11u2

  • DNS2 (completely reinstalled):

  • Rasperry Pi 5, Raspberry OS Lite bookworm

  • Pi-hole v5.17.3 FTL v5.25 Web Interface v5.21 / FTL tweak nsec3_iters_warning

  • Unbound 1.17.1-2+deb12u2

  • The problem occurres since the last Pi-Hole update

  • The problem occurs on both DNS

  • The problem doesn't occur when I enter the ISP DNS in Pi-hole

  • The problem appears to be caused by only one client on the network.

  • The problem occurs immediately after this client logs into the WLAN, then not for a few hours

  • The client is a Galaxy-A34 smartphone

  • The problem is reproducible

  • Adjusting the resource limits apparently has no effect on this

  • So far no usable information about the 4 limits in the log files

I have now divided my network between the 2 DNS so that only the problematic smartphone uses DNS1.
After the smartphone logs into the WLAN, it takes a maximum of 5 seconds for the error to occur. The FTL.log and pihole.log are now restricted to the problem case.

Can I send you the log files somehow? Do you need any other information?
It's not that easy to get my wife's smartphone :rofl:


I am also repeatedly receiving this warning since upgrading to FTL 5.25, but it's for a different URL (it appears to be a URL associated with my wife's employer). If there is any diagnostic information which may be of help, I'll be happy to provide.


Thanks for your further information. Even though I haven't had mich time today, I just took a quick look at the the changes that have been merged into dnsmasq 2.90 last week and found at least one other path through which this warning might be logged incorrectly: If the upstream server replied with REFUSED.

Please check your /var/log/pihole/pihole.log at the timestamp the warning was triggered for the mentioned domain. What are the related log lines?

You should be able to find them quickly using

grep -C 20 "resource limit" /var/log/pihole/pihole.log

Notes: If there was a lot of activity going on, 20 may not be enough. If the event was yesterday, you may need to append .1 to the filename.


I've ran the above command, which did reveal a REFUSED response...


If it helps, I also generated a debug log.

Token is https://tricorder.pi-hole.net/dFnQVqaS/


Always the same 2 domains: