Eine Domain lässt sich auflösen. Das ist eine gute Nachricht – aber noch kein Nachweis dafür, dass der verwendete Resolver DNSSEC korrekt prüft. Eine falsche Antwort kann genauso schnell eintreffen wie eine richtige. Interessant wird es dort, wo ein Resolver eine Antwort bewusst zurückweisen muss.
Genau dafür entsteht dnssec-test: eine kontrollierte Umgebung mit definierten DNSSEC-Zuständen. Neben korrekt signierten Zonen gehören absichtlich fehlerhafte Fälle dazu. Nicht als Störung, sondern als Prüfmaterial.
Ein Ergebnis braucht eine bekannte Ausgangslage
Wenn ich einen Resolver prüfen möchte, brauche ich mehr als irgendeine öffentliche Domain. Ich muss wissen, welchen Zustand die abgefragte Zone zum Prüfzeitpunkt hat und welches Verhalten daraus folgt.
Bei fremden Domains habe ich diese Kontrolle nicht. Der Betreiber kann Schlüssel wechseln, Signaturen erneuern oder einen Fehler beheben. Das ist für seinen Betrieb richtig, kann aber meine Testgrundlage verändern.
Deshalb trennt mein Ansatz drei Dinge: die definierte Referenzzone, das erwartete Resolververhalten und die tatsächlich beobachtete Antwort. Erst ihr Vergleich ergibt einen Befund.
Ein Labor mit gültigen und ungültigen Zuständen
Der Referenzbestand soll unterschiedliche Situationen abdecken: eine intakte Vertrauenskette, eine abgelaufene Signatur oder eine Delegation, bei der der veröffentlichte DS nicht zum Schlüssel der Kindzone passt. Auch negative Antworten und Wildcards gehören in eine nachvollziehbare Prüfung.
Dabei ist die Beschreibung des Testfalls entscheidend. Ein fehlender DS bedeutet nicht pauschal einen DNSSEC-Fehler. Eine nachweisbar unsignierte Delegation wird anders behandelt als eine beschädigte Vertrauenskette. Der Katalog muss deshalb den jeweiligen Kontext festhalten und darf aus ähnlichen DNS-Antworten keine gleichen Erwartungen ableiten. Die Grundlagen dieser Unterscheidung beschreibt RFC 4033.
Ein solcher Test ist nur dann brauchbar, wenn nicht schon die Testzone zufällig defekt ist. Auch das Labor braucht eine eigene Qualitätskontrolle.
Erzeugen, signieren und ausliefern bleiben getrennt
Das Architekturkonzept sieht einen klaren Weg vor:
- Versionierter TestkatalogDefiniert Referenzzonen und erwartetes Verhalten.
- Zonen erzeugen und signierenGültige und absichtlich fehlerhafte Zustände kontrolliert herstellen.
- Testfälle prüfen und freigebenDie Ausgangslage wird vor der Veröffentlichung kontrolliert.
- Autoritative Test-NameserverStellen die freigegebenen Referenzen bereit.
- Resolver unter TestBeobachtete Antwort mit der Erwartung vergleichen und dokumentieren.
Die öffentliche Auslieferung übernimmt NSD. Die Nameserver sollen fertige Zonen bereitstellen; sie müssen dafür nicht zugleich die Signierumgebung sein. In der aktuellen Infrastrukturplanung sind ein Hidden Primary und zwei öffentliche Test-Nameserver vorgesehen.
Testzonen, Testschlüssel und Veröffentlichung bleiben von produktiven DNS-Zonen getrennt. Die Cascade-/NetHSM-Signchain der eigenen DNS-Verwaltung ist deshalb nicht einfach die Verarbeitungskette dieser Testumgebung. Eine absichtlich beschädigte Testzone darf nicht versehentlich zur Vorlage für eine produktive Domain werden.
Zeit gehört zum Testfall
DNSSEC-Signaturen haben ein Gültigkeitsfenster. Für eine normale Zone bedeutet eine ablaufende Signatur: rechtzeitig erneuern. Für einen Testfall mit absichtlich abgelaufener Signatur kann genau diese Erneuerung den Test unbrauchbar machen.
Deshalb darf die Wartung nicht einfach alle Zonen gleich behandeln. Sie muss wissen, welche Eigenschaft erhalten bleiben soll. Das gilt auch bei Änderungen an Testdaten: Eine neue Signatur ist noch keine neue fachliche Testdefinition, eine veränderte Erwartung dagegen möglicherweise schon.
Ein Bericht soll deshalb nicht nur „bestanden“ ausgeben. Er braucht den verwendeten Katalogstand, den Prüfzeitpunkt, den Zielresolver und die konkrete Referenz, gegen die geprüft wurde.
Ein Katalog macht die Prüfung nachvollziehbar
Im Konzept entsteht aus fachlichen Anforderungen ein versionierter Prüfkatalog. Die Check-Engine führt diese Prüfungen gegen einen Resolver aus. Ein gesonderter Katalogvalidator soll prüfen, ob Anforderungen, Prüfdefinitionen und benötigte Referenzzonen zusammenpassen.
Das sind verschiedene Aufgaben. Ein vollständiger Katalog beweist noch keinen korrekt arbeitenden Resolver. Eine korrekte Resolverantwort beweist umgekehrt nicht, dass der Katalog bereits alle relevanten Fälle abdeckt.
Die Weboberfläche ist als Zugang zu Prüfaufträgen und Berichten vorgesehen. Sie soll die Methode verständlich machen, ohne dafür das interne Prüfwerkzeug an den Nutzer auszuliefern.
Was dieser Ansatz leisten soll
Mein Ziel ist eine prüfbare Aussage: Dieser Resolver hat zu diesem Zeitpunkt die beschriebenen Prüfungen gegen diesen Referenzstand bestanden. Das ist genauer als ein pauschales Gütesiegel und lässt sich bei einer Änderung gezielt wiederholen.
Die Unterlagen beschreiben einen Entwicklungsstand. Teile der Zonen- und Signierwerkzeuge liegen vor; Katalog, automatisierte Prüfkette, Betriebsprozesse und öffentliche Oberfläche müssen jeweils gesondert verifiziert und abgenommen werden. Dieser Artikel kündigt deshalb keinen bereits vollständig verfügbaren Prüfdienst an.
Der Kern des Projekts ist eine einfache Arbeitsweise: Das erwartete Verhalten vorher festlegen, die Ausgangslage kontrollieren und das tatsächliche Ergebnis dokumentieren. Gerade bei Sicherheit ist ein sinnvoll erklärtes Scheitern oft der wertvollere Test.