Eine DNS-Zone zu signieren ist zunächst eine kryptografische Aufgabe. Im Betrieb kommen weitere Fragen hinzu: Woher stammt der neue Stand? Darf er verarbeitet werden? Welche Prüfungen sind nötig, bevor öffentliche Nameserver ihn ausliefern?
Die DNSSEC-Signqueue ist als Verarbeitungskette angelegt. Eine Änderung soll einen definierten Weg von der Eingabe über Prüfung und Signierung bis zur Veröffentlichung durchlaufen. Nicht jeder technisch erzeugte Stand soll automatisch ein öffentlich ausgelieferter Stand werden.
Die Kette beginnt vor dem Signieren
Die Architektur trennt den Ursprung einer Zone von ihrer späteren Auslieferung. Ein interner Eingangs-Nameserver, im Projekt origin genannt, stellt die zu verarbeitenden Zonendaten bereit. Die Verarbeitung liest diese Daten und gibt das Ergebnis an einen getrennten Hidden Master weiter. Von dort beziehen die öffentlichen Secondaries ihren Stand.
Das ist das Architekturmodell, keine Behauptung, dass alle Bausteine bereits produktiv laufen. Insbesondere sind V1 und V2 alternative Verarbeitungswege; eine Zone soll nicht nacheinander durch beide laufen.
Der Nutzen dieser Trennung liegt im Arbeitsablauf. Die Pflege bleibt an der Quelle, die Verarbeitung hat einen klaren Übergabepunkt und die öffentlichen Nameserver übernehmen die Auslieferung.
Cascade als Referenzaufbau
Für den signierenden Weg gibt es mit cascade-dockerized einen eigenen Containeraufbau. Er verbindet die DNSSEC-Pipeline Cascade von NLnet Labs mit einem Eingangs-NSD, einem nachgelagerten NSD und einem NetHSM-Dienst für die Schlüsselanbindung. Eine Bridge verbindet Cascade mit dem HSM-Backend. Ein Control-Container stellt die Werkzeuge für Einrichtung und Bedienung bereit.
Die Pipeline erhält Zonendaten über DNS-Zonentransfers. Die Transferbeziehungen werden mit TSIG abgesichert. Das ersetzt keine fachliche Prüfung des Inhalts: Ein authentisierter Transfer kann auch eine sachlich falsche Zone übertragen.
Der Aufbau dient dazu, das Zusammenspiel dieser Komponenten zu prüfen. Sein README warnt ausdrücklich vor einem Produktionseinsatz und nennt Beta- beziehungsweise Testkomponenten. Die Containerinstanz des NetHSM-Dienstes ist außerdem kein Nachweis für den Einsatz eines physischen HSM.
Die Referenzimplementierung ist auf Codeberg verfügbar.
Schlüsselanbindung ist eine eigene Aufgabe
Eine Signierkette muss DNS-Daten verarbeiten können, ohne dass jede beteiligte Komponente dieselben Zugriffe auf Schlüssel und Verwaltung erhält. Deshalb ist die Schlüsselanbindung im Referenzaufbau ein eigener Baustein.
Daraus folgt aber noch keine pauschale Aussage über die Sicherheit der gesamten Installation. Entscheidend bleiben unter anderem Berechtigungen, Provisionierung, Sicherung und die tatsächliche Laufzeitumgebung. Ein HSM-Backend innerhalb eines Container-Testaufbaus darf nicht mit einer fertig abgenommenen Schlüsselhaltungsarchitektur gleichgesetzt werden.
Ebenso ist diese Konstruktion von der lokalen ldns-Signierumgebung der DNSSEC-Testzonen zu unterscheiden. Das sind getrennte Projekte mit unterschiedlichen Betriebszielen.
Vor dem Signieren prüfen
Die Unterlagen zu Cascade beschreiben einen Review-Hook vor dem Signieren. An dieser Stelle liegt noch eine unsignierte Zone vor. Hier lassen sich Struktur und Records beurteilen – nicht bereits die Gültigkeit der noch gar nicht erzeugten DNSSEC-Signaturen.
Der Hook erhält Angaben zur Zone und zur konkreten Instanz. Das Prüfprogramm kann diese Instanz per AXFR abrufen und daraus seine Entscheidung ableiten. Der vorgesehene Rückkanal ist ein Exit-Code: Freigabe oder Ablehnung.
Ein Exit-Code erklärt allerdings noch nicht, welche Prüfungen liefen. Deshalb sieht der Entwurf einen zusätzlichen Nachweis der Einzelbefunde vor. Speicherformat, Kataloganbindung und der genaue Ausbau dieser Prüflogik sind in den Unterlagen noch offen.
Für einen abgelehnten Stand ist ein bewusstes Anhalten vorgesehen. Ob der Operator die Ablehnung überschreibt oder die Instanz verwirft, soll eine erkennbare Entscheidung sein. Eine entsprechende Konfiguration ist etwas anderes als der Nachweis, dass ein vollständiger Prüfkatalog bereits umgesetzt ist.
Nach dem Signieren bleibt eine zweite Frage
Eine strukturell brauchbare Eingabe garantiert noch kein korrektes signiertes Ergebnis. Darum gehört ein Post-Check zum Zielbild: Er betrachtet den verarbeiteten Stand, bevor dieser weitergegeben wird.
Die Aufgaben sind unterschiedlich. Der Pre-Check beurteilt die Eingabe. Der Post-Check beurteilt das Ergebnis. Die Auslieferungskontrolle stellt anschließend fest, was auf den vorgesehenen Nameservern tatsächlich angekommen ist.
Diese Grenzen helfen bei Fehlern. Ein Problem beim Transfer muss nicht in der Signierung gesucht werden. Ein Fehler im signierten Ergebnis darf nicht durch einen erfolgreichen Containerstart verdeckt werden.
Warum es einen Bypass gibt
Der zweite Weg V2 ist ausdrücklich unsigniert. Er soll den DNS-Grundpfad unabhängig davon nutzbar machen, ob die Cascade-Integration schon bereitsteht. Bypass bedeutet hier nicht, eine signierte Zone zu simulieren, sondern einen anderen Verarbeitungsmodus klar zu benennen.
In der Signchain-Spezifikation ist auch für diesen Zweig ein Pre-Check vorgesehen. Ein dokumentierter Übergangsplatzhalter meldet jedoch zunächst „OK, 0 Prüfungen“. Das muss sichtbar bleiben: Die Existenz einer Prüfschnittstelle ist noch kein bestandener fachlicher Test.
Eine weitere Anforderung betrifft die Seriennummer. Ein neuer Stand soll gegenüber dem bisher veröffentlichten Stand entsprechend den DNS-Serial-Regeln fortgeschritten sein. Die konkrete Umsetzung ist getrennt von dieser Anforderung zu bewerten.
Referenz, Ziel und Betrieb auseinanderhalten
Die vorliegenden Unterlagen beschreiben mehrere Entwicklungsstände. cascade-dockerized ist der Test- und Referenzaufbau. signchain beschreibt die Verarbeitung mit zwei Zweigen. Die spätere Modellierung unter souveraen-dns ordnet diese Verarbeitung in eine umfassendere eigene DNS-Verwaltung ein.
Eine Betriebsdokumentation vom 14./15. Oktober 2026 beschreibt daneben noch eine Übergangskette mit einem bisherigen DNS-Produktionsdienst und öffentlichen Secondaries. Sie belegt nicht, dass die vollständige Cascade-Kette inzwischen produktiv eingesetzt wird. Eine solche Aussage erfordert eine aktuelle Betriebsprüfung.
Auch Registrar-Anbindung und ein vollständiges Monitoring sind nicht automatisch Bestandteil des kleinen Cascade-Referenzstacks. Diese Grenzen nennt dessen README ausdrücklich.
Was ich damit erreichen möchte
Die Kette soll eine DNS-Änderung nachvollziehbar vom definierten Eingang zur kontrollierten Veröffentlichung führen. Dazu gehören erkennbare Verarbeitungsschritte, getrennte Verantwortlichkeiten und Prüfungen, deren Umfang sichtbar ist.
Der entscheidende Fortschritt ist nicht allein eine automatisch erzeugte Signatur. Es ist die Möglichkeit, später erklären zu können, welcher Zonenstand welchen Weg genommen hat und warum er veröffentlicht wurde – oder eben nicht.