Unbound returning SERVFAIL intermittently when resolving dynamic lookup domain

Unbound
1

Hi everyone,
I am running a local Unbound recursive resolver instance on my network, and I have hit a weird DNS resolution issue with an external regional portal. Whenever users on our local network try to query and retrieve their monthly utility statements from here, Unbound intermittently fails the lookup and returns a SERVFAIL response. However, if I bypass Unbound and query public recursive resolvers or test direct UDP queries against upstream root servers, the A records resolve without any issue.

I suspect the problem might be linked to how Unbound handles EDNS buffer sizes or aggressive DNSSEC validation fallbacks when communicating with authoritative servers that send misconfigured or non-compliant DNS responses.

I am also running into a couple of related resolution glitches with this domain setup. First, the negative cache in Unbound seems to hold onto the failed response for much longer than expected, blocking subsequent user retry attempts unless I manually flush the cache for that specific zone. Second, when checking verbosity logs, I notice repeated timeout messages and SERVFAIL logging during key DNSSEC chain-of-trust validation steps, even though the zone itself does not appear to have valid DS records published at the parent TLD level.

Has anyone encountered similar SERVFAIL validation loops or EDNS fallback timeouts in Unbound when resolving legacy external Web portals, and are there specific unbound.conf parameters like harden-dnssec-stripped or edns-buffer-size adjustments you would recommend tweaking to stabilize these lookups?

2

From a quick skim, I think it may be that there is connectivity loss. At first I thought close to the utility statement site, but the chain of trust issue makes me think the connectivity loss is either close to ‘.pk’, or close to the resolver. As in, the upstream connectivity has (perhaps periods) of bad connectivity, high packet loss or no packets whatsoever for a while. That would trigger EDNS backoff, so that fits the theory. If that continues, consider enabling serve-stale to continue serving old data during the connectivity loss, or perhaps disabling DNSSEC if that take too many messages on the low chance of hitting a reply.