Hello,
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
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:
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
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.
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
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)?
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.
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
Interesting! See below why. First, let's take a look at the definition of this option I wanted you to set:
dnssec-limits=[,.......]
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
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
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
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?
