SERVFAIL exceeded the maximum number of sends

I keep getting these messages in DNS Unbound system log:

error: SERVFAIL < PTR IN>: exceeded the maximum numb er of sends

Looking at Network-Domain Name System

DNS: **working**
all the nameservers have **OK** status

I get those messages also.

Do you get 1000’s or 10’s of those messages?

1 Like

10’s but it will completely prevent any nslookup for few hours

Just for reference I see about 110 in the last 12 months.

Are there any other errors in the log? Are there errors related to nslookup?

Or maybe messages directly above and below the error: SERVFAIL message?

1 Like

Thank you Jon,

nslookup just times out, so I had to reboot IPfire to restore the Internet access.

It keeps happening so often, so I started the backup resolver ( Pi-hole with IPfire as Upstream DNS)

and this is the error pihole shows:

 DNSMASQ_WARN Warning in `dnsmasq` core:
Maximum number of concurrent DNS queries reached (max: 150)



shows just that 1 error

less /var/log/messages | grep unbound

[15449:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Apr  3 15:11:18 IPFire unbound: [15449:0] error: SERVFAIL < PTR IN>: exceeded the maximum number of sends
Apr  3 17:31:18 IPFire unbound: [15449:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Apr  3 23:10:30 IPFire unbound: [15449:0] info: server stats for thread 0: 5718 queries, 2082 answers from cache, 3636 recursions, 68 prefetch, 0 rejected by ip ratelimiti

Searching on the Unbound and DNSMASQ messages they are saying the same thing. That somewhere on your network a machine(s) are making more than the maximum allowed number of DNS requests. This must be in a very short time frame as the DNS requests tend to be dealt with very quickly.

Somewhere in the IPFire logs there must be something about DNS requests to IPFire and/or pihole. If the machine or machines making these requests can be identified then the reason why should be easier to identify.

I don’t know if it is possible to make unbound provide more detailed logs with some debug setting to run for only a short time because it will probably generate a lot of material. I haven’t been able to find anything at the moment.


Hi all,

just for the sake of completeness: Way back in 2016 (with Core Update 106), we switched from dnsmasq to unbound as a DNS resolver. Hence, the dnsmasq log sections do not provide any information ever since, and were only kept to allow old dnsmasq logs still be viewed via the web interface - though I think we can safely remove it nowadays. :slight_smile:

To figure out which client behind IPFire generates all these queries, you can enable logging of DNS queries. (It is disabled by default due to privacy reasons, since DNS queries basically leak most parts of the browsing history of users.)

To do so, create a new file in /etc/unbound/local.d/ (such as /etc/unbound/local.d/log-queries.conf - the .conf suffix is important) with the following contents:

	log-queries: yes

Afterwards, reload Unbound by executing

/etc/init.d/unbound reload

You will then see DNS queries logged in /var/log/message - for example, by running this command:

tail -f /var/log/messages | grep -i unbound

This should be sufficient to get the client IP address emitting the PTR queries.

Thanks, and best regards,
Peter Müller


The culprit were DNSSEC queries to Unbound and when they didn’t get a valid response. This caused the maximum allowed number of retries.

1 Like