Eine Antwort beweist gar nichts

An DNS denkt selten jemand, solange es funktioniert. Es taucht in keinem Risikoregister als eigener Eintrag auf, hat keinen Wartungsvertrag und keine Kennzahl. Bis die Auflösung einer Domain jemand anderem gehört.

Im März 2026 hat das NIST seinen Leitfaden zum sicheren DNS-Betrieb neu herausgegeben, SP 800-81 in Revision 3. Die Vorgängerfassung war von 2013. Wir haben die Prüfungen daraus in den letzten Tagen umgesetzt, und dabei war der lehrreichste Teil nicht, was zu prüfen ist, sondern wie leicht man dabei das Falsche misst.

Der abgelaufene Vertrag als Übernahmeweg

Eine Zone nennt ihre eigenen Nameserver, und die übergeordnete Zone nennt sie ebenfalls. Weicht beides voneinander ab, spricht man von einer Lame Delegation, und das ist mehr als ein Schönheitsfehler: Läuft der Vertrag bei einem DNS-Hoster aus, verschwindet die Zone dort, der Name des Hosters bleibt aber in der Delegation der Elternzone stehen. Wer nun beim selben Hoster ein Konto anlegt und genau diese Zone einrichtet, übernimmt die Auflösung. Die Welt fragt weiter denselben Server, und der antwortet jetzt für jemand anderen.

Deshalb prüft die Sonde zuerst, was die Elternzone sagt. Was eine Zone über sich selbst behauptet, ist nachrangig: Maßgeblich ist der Eintrag im Register, denn er bestimmt, wohin gefragt wird.

Warum eine Antwort nichts beweist

Ein autoritativer Nameserver soll autoritativ sein und sonst nichts. Beantwortet er zusätzlich Fragen nach fremden Namen, ist er ein offener Resolver: Reflektor für Überlastungsangriffe und Angriffsfläche für vergiftete Zwischenspeicher zugleich.

Der naheliegende Test lautet: einen fremden Namen abfragen, und wenn eine Antwort kommt, ist der Server offen. Genau dieser Test ist falsch. Im Code steht dazu eine Tabelle aus echten Messungen, und sie erklärt, warum:

Drei von vier Servern antworten, nur einer ist offen. Der Grund ist unspektakulär: Der befragte Server kann für den Probenamen schlicht selbst zuständig sein. Entscheidend ist deshalb nicht, ob geantwortet wird, sondern was in den Kopfmerkmalen der Antwort steht: ob der Server für diesen Namen autoritativ ist und ob er Rekursion überhaupt anbietet.

Wo man fragt, entscheidet, was man erfährt

Bei DNSSEC setzt sich das fort. Die Schlüssel einer Zone stehen im Zoneninhalt, also fragt man den autoritativen Server, und zwar ohne Rekursion, damit die Antwort nicht aus einem Zwischenspeicher stammt. Der Eintrag, der diese Schlüssel in der Elternzone verankert, steht dagegen genau dort. Fragt man den falschen Server, sieht eine korrekt signierte Zone unverankert aus. Und um zu prüfen, wie eine Zone nach einem nicht existierenden Namen antwortet, braucht es einen Namen, den es garantiert nicht gibt: einen zufälligen.

Eine zweite Note statt geänderter Gewichte

Die Ergebnisse fließen in eine eigene Schulnote für die DNS-Infrastruktur, statt die bestehende Domain-Note zu erweitern. Dagegen sprach ein Argument, das mit DNS nichts zu tun hat: Die vorhandene Note bewertet im Kern die E-Mail-Sicherheit und liegt historisiert vor. Ändert man ihre Gewichte, verschiebt sich rückwirkend jede Note und jeder Verlauf knickt, ohne dass sich an einer einzigen Domain etwas geändert hätte. Aus demselben Grund stand die Gewichtstabelle der neuen Note von Anfang an fest, obwohl die Prüfungen in drei Wellen kamen: So hat jede Welle nur Daten hinzugefügt und eine Note nur dort gesenkt, wo ein echter Mangel gefunden wurde.

Eine Kennzahl, die sich ändert, weil das Werkzeug besser geworden ist, ist als Verlauf wertlos.

Mehr auf der Modulseite Attack Surface Management.