unbound request list exceeded stat ubuntu 20 vs ubuntu 22

[Olivier Benghozi]

Very simple.

As you can see here:
https://changelogs.ubuntu.com/changelogs/pool/main/u/unbound/unbound_1.13.1-1ubuntu5.5/changelog

... Unbuntu has backported to 1.13.1 the CVE-2024-33655 / DNSBomb patch
from Unbound 1.20.0, described in their own release notes here:
https://www.nlnetlabs.nl/projects/unbound/download/#unbound-1-20-0


This fix basically kills the requests queued that are waiting for a
recursive resolution, for which there's nothing know in the cache, and that
have been waiting for way too long ; that is, the attempt to resolve in a
proper amount of time, compatible with the usual DNS clients timeouts, is
failing – maybe because the authoritative DNS servers are not answering.

Answering to these requests would have been useless anyway as the client is
not waiting for an answer anymore after a few seconds (because of its own
timeout).

Therefore, you now see dropped queries counters incrementing, and it's
expected (as you always will have a few authoritative servers not
responding).

Shorter: all is fine.


Le mer. 24 juil. 2024 à 22:27, Shanmuga Rao via Unbound-users <
unbound-users at lists.nlnetlabs.nl> a écrit :

> Our ubuntu 20 vms run unbound version 1.9.4
> received new ubuntu 22 vms and installed unbound version 1.13.1 via
> package manager.  I have started noticing that on the ubuntu 22 machines,
> the *total.requestlist.exceeded* stat started getting non-zero values.
> unbound v1.9.4 in ubuntu 20, always shows 0.
>
> The queries received by each node looks to be  at most 20k or less and are
> distributed equally. All sysctl parameters are identical between ubuntu 20
> and ubuntu 22 vms. Unbound config is identical on both. Most unbound.conf
> parameters are left to defaults, the following are the important ones I
> believe influence unbound performance.
>
>  num-threads: 8
>  outgoing-range: 60000
>  num-queries-per-thread: 30000
>  so-reuseport: yes
>  module-config: "iterator"
>  msg-cache-slabs: 2
>  rrset-cache-slabs: 2
>  infra-cache-slabs: 2
>  key-cache-slabs: 2
>  rrset-cache-size: 512m
>  msg-cache-size: 256m
>  so-rcvbuf: 4m
>  so-sndbuf: 4m
>
> Unbound service starts and occupies available ports and FDs. CPU and
> memory utilisation on both are very minimal. less than 25%
> # ulimit -n
> 1048576
> unbound[764890:0] debug: total of 59463 outgoing ports available
> *Ubuntu 20 stats_noreset: *
> total.num.queries=15979
>
> *total.requestlist.max=5**total.requestlist.exceeded=0*
>
> *total.requestlist.current.all=9total.requestlist.current.user=7*
>
> *Ubuntu22 **stats_noreset**: *
> total.num.queries=9157
>
> *total.requestlist.max=5*
>
>
> *total.requestlist.exceeded=3total.requestlist.current.all=3total.requestlist.current.user=3*
>
> ubuntu 22 systems constantly have non-zero values. Ubuntu 20 systems and
> even Centos7 ( unbound version 1.7.1) always have zero. As per my
> understanding of the config parameters, the system itself has enough
> resources available to handle atleast 2x the current traffic.
>
> As a test I have compiled version 1.13.1 on a ubuntu 20 VM and still the
> request list exceeded stat is zero.  On Ubuntu 22 I have also compiled and
> installed the latest unbound version 1.20.0 and it's still the same - non
> zero values.
>
> I can see that the queries dropped is less than 1 req/s but it's still
> confusing since its only seen on ubuntu 22 vms with little resource
> utilisation.
>
> Has anyone run into something similar ? Do you know if any ubuntu 22
> specific parameters should be modified ? Happy to provide more information
> if needed.
>

-- 
*Ce message et toutes les pièces jointes (ci-après le "message") sont 
établis à l’intention exclusive des destinataires désignés. Il contient des 
informations confidentielles et pouvant être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de détruire le message. Toute utilisation de 
ce message non conforme à sa destination, toute diffusion ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
de l'émetteur*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20240724/311d2125/attachment.htm>