Zusammenfassung

  • NSD 4.15.2 vom 2. September enthält eine Korrektur, die den Zertifikatsnamen zusammen mit den Adress- und TSIG-Bedingungen desselben Zugriffseintrags prüft.
  • Anlass war ein Bericht über einen abgewiesenen legitimen Zonentransfer bei zwei konfigurierten Identitäten. Der Regressionstest prüft beide gültigen Zertifikate, bildet aber nicht alle Bedingungen des ursprünglichen Aufbaus ab.

Bei einem Zugriffstest sind zwei erfolgreiche Anmeldungen mit unterschiedlichen Identitäten oft aussagekräftiger als eine. NSD lieferte dafür ein konkretes Beispiel: Eine einzeln funktionierende Transferregel konnte versagen, sobald eine zweite mit einem anderen Zertifikatsnamen hinzukam.

Der Bericht vom 24. Juli beschreibt NSD 4.14.0 aus EPEL auf RHEL 9.8 als Primärserver. Zwei Sekundärserver mit anderer Software hatten jeweils eigene Adressen und Zertifikatsnamen; die Regeln verwendeten denselben TSIG-Schlüssel. Den Protokollen zufolge waren der TLS-Handshake und die TSIG-Prüfung erfolgreich. Auch der erste Name passte. Anschließend führte die Abweichung vom anderen Namen zur Transferverweigerung. Mit nur einem Eintrag funktionierte der Abruf.

Ein Maintainer bestätigte am 28. August die Reproduktion und die Korrektur. Die Release-Mitteilung zu 4.15.2 nennt am 2. September ausdrücklich die Zuordnung zur selben Regel. Die Downloadseite führte 4.15.2 bei der Prüfung am 8. September weiterhin als aktuelle Version.

Das belegt einen gemeldeten Test, eine Bestätigung durch die Wartung und die Aufnahme in das Release. Es belegt keinen flächendeckenden Ausfall. Die privaten Adressen gehören zum beschriebenen Testaufbau; eine erneute Prüfung durch den ursprünglichen Melder nach Veröffentlichung ist im Gespräch nicht dokumentiert.

Die Alternative muss vollständig passen

Der Quellcode-Patch verbindet Adressabgleich, TSIG-Schlüsselprüfung und Zertifikatsnamen innerhalb desselben Zugriffseintrags. Die frühere, separate Schleife über Zertifikatsnamen konnte bei einer anderen Identität bereits mit einem Fehler enden.

Ein falscher Name wird dadurch nicht richtig. Er erfüllt weiterhin nicht die Regel, die einen bestimmten Namen verlangt. Aber die erwartbare Abweichung von einer anderen Identität soll eine gültige Alternative nicht mehr zu Unrecht verwerfen. Explizite Sperrregeln bleiben relevant; die gesamte NSD-Zugriffslogik lässt sich deshalb nicht als uneingeschränktes „irgendein Treffer erlaubt alles“ beschreiben.

Das ist besonders bei Zertifikatswechseln wichtig. Alte und neue Namen können vorübergehend nebeneinanderstehen, ohne dass ein Client beide zugleich besitzen muss. Wer nur den aufgebauten TLS-Kanal überwacht, kann die nachgelagerte Verweigerung der eigentlichen Zonendaten übersehen.

Aussagekräftig, aber kein vollständiger Produktionstest

Die Erweiterung des Regressionstests ergänzt eine zweite Zertifikatsidentität. Im vollständigen, auf das Release festgelegten Test müssen beide legitimen Zertifikate eine Markierung aus dem Zoneninhalt erhalten. Ablehnungsprüfungen für falsche Namen, unbekannte Zertifizierungsstellen und Anfragen ohne Clientzertifikat bleiben erhalten.

Die beiden Zertifikatsregeln erlauben dort jedoch beliebige IPv4-Quellen und verwenden NOKEY. Im Ausgangsbericht waren es getrennte Adressen und ein gemeinsamer TSIG-Schlüssel. Damit prüft der Test die Koexistenz der Zertifikatsidentitäten, nicht jede denkbare Kombination aus Adresse, Schlüssel und Name. Für diesen Artikel wurden Code und Testbedingungen gelesen; NSD wurde nicht ausgeführt und der Fehler nicht unabhängig nachgestellt.

Ein gesonderter TSIG-Eintrag erlaubt im Test zudem Transfers über gewöhnliches TLS oder TCP. Das ist eine ausdrücklich konfigurierte Alternative, keine neu nachgewiesene Umgehung. RFC 9103 trennt Authentifizierung und Vertraulichkeit: TSIG verschlüsselt den Zoneninhalt nicht selbst. Der Schutz einer gesamten Transfergruppe hängt von allen maßgeblichen Übertragungsbeziehungen ab, nicht allein von einer erfolgreichen verschlüsselten Sitzung.

Auch die ältere CVE-2026-12490 gehört nicht unter dieselbe Überschrift. Laut den Sicherheitshinweisen von NLnet Labs wurde diese andere Umgehung der Zertifikatsanforderung im Juni veröffentlicht und mit 4.14.3 behoben. Ihre Kennung und ihr Versionsbereich dürfen nicht auf die hier untersuchte Mehrfachidentitäts-Verweigerung übertragen werden. Eine neue Ausnutzung, eine Zahl betroffener Kunden oder eine vollständige Liste betroffener Versionen ist nicht belegt.

Lu Heng plädiert für präzise, lokal überprüfbare Sicherheitsbedingungen. Auf diesen begrenzten Betriebsfall angewandt heißt das: klar festlegen, welche Kombination Zugriff gewährt, statt die Anforderungen stillschweigend zu lockern. Das ist die Einordnung des Autors, kein Lu Heng zugeschriebenes Urteil über NSD.