Recursive loop or script conflict? unbound fails on specific external hooks

DNS Libraries & Tools
1

Hi everyone,
I’ve been running a local Unbound instance (v1.24.2) to handle recursive lookups for my development environment, but I’ve recently hit a wall with some intermittent SERVFAIL responses that seem to be tied to background automation. My setup is fairly standard, but I’m seeing strange behavior whenever my local testing scripts initiate high-frequency calls to external services.

I actually started digging into this after spending some time on deltaexector com to see how their high-performance script handling is structured, as I was looking for the best roblox executor to use as a case study for lightweight, rapid-fire execution that doesn’t bloat the local system’s memory. While comparing their method of handling external injections to my own, I noticed that Unbound starts logging “Request list exceeded” errors specifically when these types of background executors are active.

I’m also seeing a related issue where DNSSEC validation fails for certain subdomains only when the script is polling the server. Has anyone else noticed if Unbound’s infra-cache or msg-cache can get overwhelmed by rapid-fire queries from an external automation tool? I’ve already tried increasing the num-queries-per-thread and adjusting the outgoing-range, but the intermittent failures persist. Is there a way to prioritize the local UI thread so these background scripts don’t cause a “denial of service” on my own resolver? Any advice on how to sandbox these high-frequency requests so they don’t trigger the Unbound rate-limiter would be a huge help!

4

Hi @aliya989,

You can use wait-limit: 0 if you trust Unbound’s clients. This will allow more queries per IP.

Increasing num-queries-per-thread but also num-threads will allow more queries that need resolution if the above does not help.

Configuring log-servfail: yes will output the cause of the SERVFAIL in all verbosity levels so you can configure something lower for verbosity. High verbosity levels, from 2 upwards, bring performance down since Unbound needs to exponentially log a lot of information.

Does your Unbound perform DNS resolution itself or do you have forwarders configured (via forward-zone)?
If you generate a lot of traffic you could also be ratelimited upstream. In that case Unbound will start counting resolution errors (likely from timeouts) that can lead to SERVFAIL.
You can see if that is the case by running unbound-control dump_infra and checking what Unbound thinks about upstream nameserver responsiveness. You can compare before and during when those scripts run.