question on ACL

[Yorgos Thessalonikefs]

Hi Måns,

Not allowing 127.0.0.1 in the access-control forbids DNS queries from 
that localhost address to Unbound. The daemon itself does not rely on 
that address and you can forbid it if you don't want queries from that 
address.

unbound-control commands from localhost have their own configuration in 
the 'remote-control' clause and are not subject to the access-control 
settings.

Now with me just assuming based on what you shared, I believe during the 
DDOS attack Unbound started caching resolution failures (for the queries 
themselves and the infrastructure cache).
Reloading Unbound clears all that state.

For SERVFAILs of individual queries (Unbound could not resolve for 
reasons) these stay in the cache for 5 seconds and work as a back off 
mechanism.

For the infrastructure failures (Unbound can not reach nameservers or 
timeouts start piling up) you have a couple of options:
- Tweak the infra-* options.
   - You can bring the 'infra-host-ttl' [1] lower than the default 900.
   - You can turn on 'infra-keep-probing'; that could help with
     nameserver RTT exploration.
- Flush the infrastructure cache with 'unbound-control flush_infra all'
   after a major networking event instead of waiting for the individual
   entries to expire after 'infra-host-ttl'.

Both of those strategies don't save you from the SERVFAILs that are 
produced during the DDOS if Unbound is not able to resolve.

What could help you in this case is the serve-expired related options 
[2] but these come with their own caveats because you will be serving 
expired records that may or may not make sense.

There is also a blog post [3] about the feature and Unbound's behaviour.

Hope that helps.

Best regards,
-- Yorgos

[1] 
https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-infra-host-ttl
[2] 
https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-serve-expired
[3] https://blog.nlnetlabs.nl/some-country-for-old-men/

On 11/06/2025 08:18, Måns Nilsson via Unbound-users wrote:
> Hi,
> 
> Recently I've been having some issues with queries under load on
> 1.22 from FreeBSD pkg. We've seen some nasty DDOS attacks affecting
> us and during these one of the side effects has been massive SERVFAILs
> all over the board. We run an internal anycast system with a couple
> dedicated forwarders to the rest of the name space.
> 
> I during trouble shooting of this discovered that I'd excluded
> 127.0.0.1 from the access-control: list. Once I changed this, purely
> as a convenience to myself, I experienced a complete service
> restoration without the massive SERVFAIL storms. I changed the value
> using text editor on config file, and then reloaded the daemon using
> unbound-control. So a few other things happened as well, of course.
> Muddying the waters.
> 
> So, my question is:
> 
> Would not having 127.0.0.1 in the access-control: list make life
> bad for the daemon in any way? Or was I just lucky that reloading
> managed to clear the problem at the same time as the "external
> influence" subsided. Tall order to answer, but I'm mostly after
> some input as to whether this _could_ have the described effect.
> 
> Thanks in advance,
>