Ubuntu hat mit USN-8474-1 neue Sicherheitsupdates für NSD veröffentlicht, weil speziell präparierter Netzwerkverkehr DNS-Server abstürzen lassen oder unter Umständen Code mit den Rechten des NSD-Servers ausführen konnte. Canonical veröffentlichte die Meldung am 25. Juni 2026. Für Admins, Hoster, kleine Firmen und Selfhoster mit Linux-Servern ist das ein schnelles Patch-Thema, weil autoritative DNS-Server zur kritischen Infrastruktur gehören.
NSD steht für Name Server Daemon. Die Software dient als autoritativer DNS-Server. Sie beantwortet also Anfragen zu DNS-Zonen, für die ein Server zuständig ist. Ein Ausfall kann Webseiten, Mailrouting, APIs, interne Dienste und Monitoringketten treffen. Deshalb wiegen Abstürze oder mögliche Codeausführung in DNS-Komponenten besonders schwer.
Ubuntu nennt mehrere betroffene Versionen: Ubuntu 26.04 LTS, 24.04 LTS, 22.04 LTS, 20.04 LTS, 18.04 LTS und 16.04 LTS. Die Korrekturen betreffen das Paket nsd. Bei Ubuntu 16.04 LTS führt Canonical zusätzlich nsd3 auf. Mehrere der älteren Ausgaben erhalten die Fixes über Ubuntu Pro und ESM Apps.
Der wichtigste praktische Punkt: Admins sollten nicht nur auf die CVE-Nummern schauen. Entscheidend ist, ob ein Server NSD installiert hat, ob er autoritative Zonen ausliefert, ob er als sekundärer DNS-Server arbeitet und ob DNS over TLS oder Zonentransfers über TLS aktiv sind. Einige der Schwachstellen betreffen laut Ubuntu nur Ubuntu 26.04 LTS. Andere können breitere Installationen treffen.
USN-8474-1 schließt vier NSD-Schwachstellen
Canonical fasst die Lage klar zusammen. NSD konnte durch speziell präparierten Netzwerkverkehr zum Absturz gebracht werden oder Programme ausführen. Dahinter stehen vier CVEs mit unterschiedlichen Angriffspfaden. Zwei Fehler betreffen Speicherüberläufe mit möglicher Codeausführung. Ein Fehler kann NSD über DNS over TLS abstürzen lassen. Ein weiterer Fehler betrifft die Authentifizierung bei Zonentransfers über TLS.
CVE-2026-12246 betrifft APL Resource Records. NSD verarbeitete laut Ubuntu Adresslängen falsch, wenn diese größer waren als für die jeweilige Adressfamilie erlaubt. Beim Schreiben der Zone auf die Festplatte konnte daraus ein stackbasierter Buffer Overflow entstehen. Ein entfernter Angreifer konnte dadurch potenziell Code mit den Rechten des NSD-Servers ausführen.
CVE-2026-12244 betrifft SVCB Resource Records. Ubuntu beschreibt einen Heap Overflow mit möglicher Codeausführung. Dieses Problem betrifft laut Canonical nur Ubuntu 26.04 LTS. CVE-2026-12245 liegt im Fehler-Logging von TLS-Verbindungen. Ein Angreifer konnte den Serverprozess durch einen Use-after-free-Absturz lahmlegen. Auch dieses Problem nennt Ubuntu nur für Ubuntu 26.04 LTS.
CVE-2026-12490 betrifft TLS-Authentifizierung für Zonentransfers. Unter bestimmten Bedingungen konnte ein Angreifer Transfer-Sicherheitsbeschränkungen umgehen. Ubuntu nennt auch diese Schwachstelle nur für Ubuntu 26.04 LTS. NLnet Labs beschreibt dazu, dass über Client-Zertifikate authentifizierte Secondaries bei Zonentransfers über TLS die Prüfung umgehen konnten, wenn der Transfer über TCP erfolgte.
| CVE | Technischer Bereich | Ubuntu-Einordnung |
|---|---|---|
| CVE-2026-12246 | APL Resource Records | Stackbasierter Buffer Overflow mit möglicher Codeausführung |
| CVE-2026-12244 | SVCB Resource Records | Heap Overflow mit möglicher Codeausführung, nur Ubuntu 26.04 LTS |
| CVE-2026-12245 | TLS-Connection-Logging | Use-after-free mit DoS-Risiko, nur Ubuntu 26.04 LTS |
| CVE-2026-12490 | TLS-Authentifizierung bei Zonentransfers | Bypass von Transfer-Sicherheitsregeln, nur Ubuntu 26.04 LTS |
Die Kombination macht USN-8474-1 wichtig. Ein reiner Denial-of-Service wäre bei DNS-Servern bereits ernst. Ein potenzieller Codeausführungspfad erhöht den Druck. DNS-Dienste hängen oft an Firewalls, Load Balancern, Hosting-Automation und externen Registrars. Ein kompromittierter oder instabiler autoritativer DNS-Server kann deshalb deutlich mehr stören als nur eine einzelne Anwendung.
Die Meldung erinnert an frühere Server- und Proxy-Sicherheitsfälle. Squidbleed betraf zwar einen anderen Dienst, aber der Admin-Alltag ähnelt sich: Netzwerknahe Software braucht schnelle Updates, saubere Konfiguration und klare Betriebsprüfung nach dem Patch.
Admins sollten Paketstand, Rolle und Zonentransfers prüfen
Ubuntu schreibt, dass ein normales Systemupdate die notwendigen Änderungen einspielt. In produktiven Umgebungen reicht ein blindes Update aber nicht immer aus. Admins sollten zuerst erfassen, welche Systeme NSD tatsächlich nutzen. Danach zählt die Rolle. Ein primärer DNS-Server hat andere Risiken als ein sekundärer Server mit Zonentransfers. Ein Server mit DNS over TLS hat eine andere Angriffsfläche als eine Installation ohne DoT.
Für die Paketstände nennt Ubuntu mehrere korrigierte Versionen. Ubuntu 26.04 LTS erhält nsd 4.14.0-1ubuntu0.1~esm1. Ubuntu 24.04 LTS bekommt nsd 4.8.0-1ubuntu0.1~esm1. Ubuntu 22.04 LTS landet bei nsd 4.3.9-1ubuntu0.1~esm1. Für Ubuntu 20.04 LTS nennt Canonical nsd 4.1.26-1ubuntu0.1~esm1. Ubuntu 18.04 LTS bekommt nsd 4.1.17-1ubuntu0.1~esm1. Ubuntu 16.04 LTS wird mit nsd 4.1.7-1ubuntu0.1~esm1 und nsd3 4.1.7-1ubuntu0.1~esm1 aufgeführt.
| Ubuntu-Version | Korrigiertes Paket laut Canonical | Admin-Hinweis |
|---|---|---|
| Ubuntu 26.04 LTS | nsd 4.14.0-1ubuntu0.1~esm1 | Besonders prüfen, weil drei CVEs nur diese Version betreffen |
| Ubuntu 24.04 LTS | nsd 4.8.0-1ubuntu0.1~esm1 | ESM Apps beachten |
| Ubuntu 22.04 LTS | nsd 4.3.9-1ubuntu0.1~esm1 | ESM Apps beachten |
| Ubuntu 20.04 LTS | nsd 4.1.26-1ubuntu0.1~esm1 | ESM Apps beachten |
| Ubuntu 18.04 LTS | nsd 4.1.17-1ubuntu0.1~esm1 | ESM Apps beachten |
| Ubuntu 16.04 LTS | nsd 4.1.7-1ubuntu0.1~esm1 und nsd3 4.1.7-1ubuntu0.1~esm1 | Legacy-Umgebung gesondert behandeln |
Nach dem Paketupdate sollten Admins den Dienststatus prüfen. Dazu gehören Systemd-Status, NSD-Logs, Zonendateien, Zonentransfers, DNSSEC-Signaturen und externe Abfragen. Ein DNS-Patch ist erst abgeschlossen, wenn der Dienst stabil läuft und autoritative Antworten wieder korrekt ausgeliefert werden. Monitoring sollte nach dem Update mindestens SOA, NS, A, AAAA, MX und DNSSEC-relevante Antworten prüfen.
Besonders wichtig sind sekundäre DNS-Server. Mehrere Schwachstellen hängen mit Zonendaten, AXFR oder Transferlogik zusammen. Betreiber sollten daher ihre Primaries, erlaubten Transferquellen, TSIG-Konfigurationen, TLS-Einstellungen und ACLs kontrollieren. Eine alte Transferregel aus einem früheren Hosting-Setup kann sonst länger bestehen bleiben als der eigentliche Dienstvertrag.
- Inventar prüfen: Welche Server haben das Paket nsd oder nsd3 installiert.
- Rolle klären: Primärserver, Sekundärserver, Hidden Primary oder Testsystem unterscheiden.
- DoT prüfen: DNS over TLS nur aktiv lassen, wenn es wirklich benötigt und überwacht wird.
- Zonentransfers absichern: ACLs, TSIG und TLS-Transferpfade kontrollieren.
- Nach dem Update testen: Dienststatus, Logs, externe DNS-Abfragen und Monitoring abgleichen.
Die Betriebsprüfung gehört zur Sicherheitsarbeit. Fedora SELinux behandelt ein anderes Linux-Problem, hilft aber beim Denken in Ursachenketten: Ein Dienst kann korrekt gepatcht sein und trotzdem wegen Rechten, Labels oder Konfiguration nicht sauber starten. Bei NSD gilt derselbe Grundsatz für Dateien, Zonen, Schlüssel und Netzwerkzugriff.
Auch automatisierte Sicherheitsprozesse bleiben relevant. GitHub Dependabot gehört eher in die Entwicklerwelt. Das Prinzip passt trotzdem zu Admin-Teams: Sicherheitsupdates brauchen Erkennung, Priorisierung, Testlauf und kontrollierte Ausbringung. Bei DNS-Infrastruktur kommt noch ein Rollback-Plan hinzu, weil falsche Änderungen schnell nach außen sichtbar werden.
Für kleine Firmen und Selfhoster ist der Hinweis auf Ubuntu Pro und ESM Apps wichtig. Ältere LTS-Systeme laufen oft länger als geplant. Sie erhalten nicht automatisch denselben Wartungsumfang wie aktuelle Releases. Wer NSD auf älteren Ubuntu-Versionen betreibt, sollte deshalb prüfen, ob die nötigen Sicherheitsquellen wirklich aktiviert sind. Fehlt ESM-Zugriff, kann ein System trotz „apt update“ ungepatcht bleiben.
Das Thema passt in den größeren Sicherheitsrahmen für Infrastruktur. Der Digitaltag 2026 rückt digitale Sicherheit als Grundaufgabe in den Fokus. Bei DNS zeigt sich das sehr konkret. Fällt Namensauflösung aus, wirken viele andere Dienste kaputt. Ein stabiler Patchprozess gehört deshalb zur Basis jeder vernetzten Organisation.
Admins mit On-Premises-Software sollten außerdem beachten, dass DNS oft Teil größerer Betriebslandschaften ist. Der Artikel zu Kaseya VSA 10.27 greift einen anderen Updatebereich auf, unterstreicht aber denselben Punkt: Lokal betriebene Dienste brauchen aktive Wartung, dokumentierte Zuständigkeiten und regelmäßige Kontrolle.
Ubuntu USN-8474-1 schließt mehrere Sicherheitslücken in NSD, darunter Speicherfehler mit möglicher Codeausführung und DoS-Risiken. Besonders Ubuntu 26.04 LTS braucht Aufmerksamkeit, weil drei der genannten Schwachstellen nur diese Version betreffen. Admins sollten NSD-Pakete zeitnah aktualisieren, Zonentransfers prüfen und nach dem Update aktiv testen, ob autoritative DNS-Antworten stabil funktionieren.