Software-update: Unbound 1.26.1

Als je een DNS-look-up uitvoert, begint een recursor in eerste instantie met het stellen van de look-upvraag aan een DNS-rootserver. Deze kan dan doorverwijzen naar andere servers, vanaf waar weer doorverwezen kan worden naar andere servers enzovoort, totdat uiteindelijk een server is bereikt die het antwoord weet, of weet dat de look-up niet mogelijk is. Van dit laatste kan sprake zijn als de naam niet bestaat of de servers niet reageren. Het proces van het langslopen van verschillende authoritative servers heet recursie. Unbound is een DNS-recursor met ondersteuning voor moderne standaarden, zoals Query Name Minimisation, Aggressive Use of Dnssec-Validated Cache en authority zones. Versie 1.26.1 is uitgebracht en hier zijn de volgende beveiligingsproblemen verholpen:

Bug Fixes

• Fix CVE-2026-81642, Heap buffer overflow and possible Remote Code Execution when digesting DNSKEY.
• Fix CVE-2026-81634, Possible heap buffer overflow during DNSSEC canonicalization.
• Fix CVE-2026-82717, CNAME synthesis could lead to heap corruption.
• Fix CVE-2026-77955, Possible ZONEMD verification bypass window.
• Fix CVE-2026-78227, Use-after-free in DoQ stream output buffer on reset re-transmission.
• Fix CVE-2026-80225, Possible degradation of service from continuous queries on the same TCP/DoT connection.
• Fix CVE-2026-82720, Use-after-free in DoH stream cleanup code path.
• Fix CVE-2026-85501, Retrap: Novel Vulnerabilities to launch Algorithmic Complexity Attacks on DNSSEC.
• Fix CVE-2026-77860, 'serve-expired' can bypass Unbound 'wait-limit'.

Versienummer	1.26.1
Releasestatus	Final
Besturingssystemen	Linux, BSD, macOS, Solaris, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11, Windows Server 2022, Windows Server 2025
Website	Stichting NLnet Labs
Download	https://nlnetlabs.nl/projects/unbound/download
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (17)

[MeNTaL_TO]

Iemand enig idee waarom Debian zo ver achterloopt? Die hebben versie 1.22.0 als meest recente versie.
[edit] Snap dat het om stabiliteit gaat, maar 2 jaar achterlopen vind ik wel wat veel.
Maar er wordt in ieder geval getest met recentere versies.
https://packages.debian.org/search?keywords=unbound

[Reactie gewijzigd door MeNTaL_TO op 17 september 2026 11:33]

[CH4OS]

Het staat natuurlijk ook altijd vrij om Unbound via een container te draaien, dan blijft de host tenminste schoon. Ik kan me dan best voorstellen dat software zoals Unbound, niet per se baremetal geïnstalleerd hoeft te worden. Doe ik met Technitium die ik draai ook niet.

[MeNTaL_TO]

Ik heb als een LXC onder proxmox draaien, echter onder Debian. Maar gezien jullie reacties (@Twiet) hoef ik me niet echt zorgen te maken over eventuele exploits

[twiet]

Debian doet aan backporting. Dat wil zeggen dat ze bugfixes uit een nieuwere versie 'backporten' in een bestaande versie, zodat de major/minor versie gelijk blijft gedurende de looptijd van de distributie.

Voorbeeld: de vulnerabilities van Unbond 1.25.1, zoals CVE-2026-33278, zijn gebackport in unbound (1.22.0-2+deb13u3) link

Onder andere Redhat doet dit ook voor RHEL.

[Reactie gewijzigd door twiet op 17 september 2026 12:30]

[Thidox]

De reden dat Debian zo stabiel is, is dat ze versies pinnen bij een release (In het geval van Trixie was dat dus 1.22.X voor Unbound). En daarna (normaliter) enkel security patches introduceren voor de software... Pas bij de volgende release van Debian (Waarschijnlijk 2027 ergens), zal 1.26.X dus worden geïntroduceerd.

[8-Track]

Volgens deze blog post staat de teller met CVEs voor Unbound in 2026 nu op 44, tegenover 2 à 3 per jaar in het afgelopen decennium. De manier van werken van Debian in het tijdperk van AI-assisted security scanning is waarschijnlijk onhoudbaar.

[Thidox]

Zoals @twiet ook al aangaf, worden security patches wel gewoon terug gepatcht naar 1.22.X. Met dan dus een Debian specifieke "-X~debY" suffix op de versie. Waarbij ze dus rap opvolgende CVEs ook in 1 patch kunnen uitrollen.

De manier van werken van Debian zou in mijn ogen dan ook prima houdbaar (Zij het misschien wat drukker) moeten blijven, en daarbij: De huidige lawine van security patches zal ergens een keer moeten af schalen, doordat de lekken dan wel gevonden zijn.

[TheCeet]

Hier zonet mijn installatie algemeen onderhoud gegeven en Unbound heeft op mijn Trixie nu versie 1.26.1 binnen gehaald.

Wou dit toch even vermelden hier

[CharmingDemon]

Ik wilde het ook net melden. De versiesprong is best groot: van 1.22.0-2+deb13u3 naar 1.26.1-0+deb13u1.

PS: ik deed mijn updates altijd handmatig als het uitkwam. Maar een paar weken geleden heb ik een cronjob aangemaakt die elke zondagnacht om 04:00 uur (DNS1) en 04:30 uur (DNS2) automatisch de updates verzorgt en de resultaten wegschrijft in een logfile met datum-tijdstempel:

sudo crontab -e (selecteer optie 1. nano bij vraag)

0 4 * * 0 { echo "===== START $(/bin/date '+\%F \%T') ====="; /usr/bin/apt-get update && /usr/bin/apt-get -y dist-upgrade; rc=$?; echo "===== EINDE $(/bin/date '+\%F \%T') - exitcode: $rc ====="; echo; } >> /var/log/weekly-upgrade.log 2>&1

(en starten met '30 4 * * 0' bij de tweede raspi)

Logfile checken:

sudo tail -100 /var/log/weekly-upgrade.log

[Reactie gewijzigd door CharmingDemon op 20 september 2026 14:30]

[lenwar]

Sommige/(veel?) distro's houden vast aan versies van software binnen een release en backporten patches. Dit zorgt er dan voor dat je binnen een versie van een distro dezelfde functionaliteit houdt, en dat alles dus binnen die versie binary compatible blijft. (ofwel. Alles wat werkt op dag 1 van de distro werkt gegarandeerd ook na 5 jaar patchen.) Als software packages functioneel ge-updated worden, dan veranderd er gedrag.

In het geval van je Debian link:

bullseye (oldoldstable) (net): 1.13.1-1+deb11u7
bookworm (oldstable) (net): 1.17.1-2+deb12u4:
trixie (stable) (net): 1.22.0-2+deb13u3:
forky (testing) (net): 1.26.0-2:
sid (unstable) (net): 1.26.1-1:

Hier zie je dat bullseye 1.13.1 heeft, bookworm 1.17.1, trixie 1.22.0, enz.

Verder zie je dat bijvoorbeeld bij Trixie de -2, waar waarschijnlijk neerkomt op de tweede versie van die versie van de package. (hij is dus een keer gepatched geweest)

[Reactie gewijzigd door lenwar op 17 september 2026 17:51]

[ashemedai]

Wellicht interessant om ook deze blogpost van NLnet Labs te lezen over software onderhoud in de tijd van AI-assisted vulnerability scans. Het heeft direct verband met deze versie.

[Reactie gewijzigd door ashemedai op 17 september 2026 09:09]

[mdavids]

Als je elders de term `resolver` tegenkomt, of zelfs `recursive resolver` - dan wordt daar in de meeste gevallen[1] hetzelfde mee bedoeld als wat hier `recursor` wordt genoemd. Mocht je je dat afvragen. :-)

[1] stub-resolver uitgezonderd.

[Reactie gewijzigd door mdavids op 17 september 2026 20:14]

[®i©ha®d]

Goed voorbeeld hiervan is:

Technitium DNS Server is an open source authoritative as well as recursive DNS server that can be used for self hosting a DNS server for privacy & security.

Technitium DNS Server | An Open Source DNS Server For Privacy & Security

[lenwar]

Technitium vind ik dan voor thuisgebruik ook een beter product dan Unbound.

Technitium kan zelf ook richting de root-servers (voor als iemand dat belangrijk vindt), spreekt native DoH/DoT/DoQ en fungeert als adblocker. (Je kunt je browser DoH laten praten met je interne Technitium.)

Technitium is nog niet zo heel oud, en moet zich in de basis nog bewijzen hoe goed het onder zware last gedraagt. Unbound is mega-licht en daarmee ook potentieel geschikt voor corporate omgevingen.

En voor de geïnteresseerden. Veel apparaten (inclusief Apple/Windows/Android) kun je configureren om DoH te praten in je eigen LAN middels de resolver.arpa zone, en dan met '_dns' als SVCB-records:

_dns.resolver.arpa. 300 IN SVCB 10 internednsserver.mijnhuis.nl. alpn=doq port=853
_dns.resolver.arpa. 300 IN SVCB 20 internednsserver.mijnhuis.nl. alpn=h3,h2 port=443 dohpath=/dns-query{?dns}

(prioriteit is op DoQ (is sneller) daarna DoQ over http (h3) en daarna DoH)

[Biturbodiesel]

Thanks super interessant

[lenwar]

We moeten het ook niet ingewikkelder maken.

Een resolver is alles dat een hostnaam vertaalt naar een ip-adres
Een recorsor gaat de DNS-verzoeken zelf doen via de root-name servers, enz, enz.

Je hebt de 'stub-resolvers' die het, het eerste regelen. Dit wordt veelal voor caching gebruikt. Zo heeft (vrijwel) ieder besturingssysteem een stub-resolver intern, zodat het niet iedere keer het hoeft a te vragen bij een recorsor.

Een mooi voorbeeld is het gebruik van /etc/hosts (of c:\windows\system32\etc\hosts (uit m'n hoofd)). De stub-resolver zal eerst hier kijken voordat het, het aan de recursor gaat vragen.

Als we het stap voor stap bekijken komt het neer op:

- Applicatie vraag om ip-adres voor hostname betrouwbaar.ru aan het besturingssysteem. De stub-resolver reageert.
- De stub-resolver kijkt het in de interne cache,
- Daarna de hosts file,
- (optioneel doet het een mDNS-verzoek),
- Daarna richting de geconfigureerde DNS-servers (en/of DoH/DoT/DoQ tegenwoordig) vragen.
- De stub-resolver geeft het antwoord terug aan de applicatie.

ergo:
Iedere recursor is een resolver, maar niet iedere resolver is een recursor

[Reactie gewijzigd door lenwar op 17 september 2026 18:03]

[mdavids]

Iedere recursor is een resolver, maar niet iedere resolver is een recursor

I like it.

En voor de echte puristen is er anders altijd nog dit:

https://www.rfc-editor.org/info/rfc9499/