Zusammenfassung

  • DNSSEC machte eine negative DNS-Antwort zu prüfbarer Evidenz, indem es die geordneten Grenzen um fehlende Namen und Record-Typen signierte.
  • NSEC3, Opt-Out und die Wiederverwendung validierter Cache-Einträge verteilen Offenlegung, Rechenlast, Delegationsgarantie und den Zeitpunkt, zu dem ein neuer Name funktionieren kann.

Man stelle sich ein Archiv vor, in dem jede vorhandene Akte echt signiert ist. Die Signatur beweist die Echtheit der gezeigten Akten, aber nicht, dass der Archivar die gesuchte Akte zurückhält. Für den Beweis der Abwesenheit braucht es zusätzlich einen signierten Katalog, dessen Ordnung die Lücke sichtbar macht.

Genau diesen gedanklichen Schritt vollzog DNSSEC mit dem authentisierten Existenzverneinungsnachweis.

Gewöhnliches DNS liefert NXDOMAIN, wenn ein Name nicht existiert, oder eine Antwort ohne Daten, wenn der Name vorhanden ist, aber nicht der angefragte Typ. Ohne DNSSEC-Validierung ist diese Verneinung nur so vertrauenswürdig wie der Antwortweg. Ein Angreifer auf dem Pfad muss einen Dienst nicht einmal umleiten; ihn verschwinden zu lassen, kann genügen.

RFC 4034 gab einer signierten Zone eine Sprache für ihre Lücken. Ein NSEC-Record nennt den nächsten autoritativen Eigentümernamen in kanonischer Reihenfolge und führt die am aktuellen Namen vorhandenen Typen in einer Bitmap. RFC 4035 beschreibt die Prüfung. Fällt der angefragte Name zwischen zwei signierte Grenzen, belegt das Intervall, dass der exakte Name fehlt. Existiert der Name, aber nicht der Typ in der signierten Bitmap, gilt der Nachweis dem Typ. Ein Namensfehler muss außerdem einen passenden Wildcard-Namen ausschließen.

Das Protokoll erzeugt nicht für jede denkbare Frage einen negativen Record. Der Namensraum wäre dafür zu groß. Der Beweis ist das geordnete Intervall: Zwei authentisierte Tatsachen begrenzen einen leeren Raum.

Der erste Nachweis zeigte den Katalog

Die Klarheit von NSEC hat eine zweite Eigenschaft. Da jeder Record auf den nächsten autoritativen Namen zeigt, kann ein geduldiger Fragesteller die Kette ablaufen und die Zone rekonstruieren.

Dieses „Zone Walking“ entschlüsselt kein Geheimnis, das DNS zu schützen versprach. Eine leicht aufzählbare Liste kann trotzdem Namensmuster, intern wirkende Dienste oder eine Aufklärungskarte offenlegen. Der Validator braucht scharfe Grenzen; der Zonenbetreiber möchte nicht zwingend einen lesbaren Index liefern.

RFC 5155 führte NSEC3 ein. Die Kette bleibt, doch lesbare Eigentümernamen werden gehasht. Der Validator kann weiterhin feststellen, dass der Hash einer Anfrage in einem signierten Bereich liegt; der Aufzähler muss Kandidaten offline erraten.

Das ist Reibung, keine Vertraulichkeit. Häufige Bezeichner sind vorhersehbar und erscheinen in Zertifikaten, Protokollen und Links. RFC 9276 beschreibt den abnehmenden Ertrag: Mehr Iterationen belasten autoritative Server und Validatoren, ohne erratbare Namen geheim zu machen.

Opt-Out schreibt Skalierungskosten in den Nachweis

In sehr großen, delegationsreichen Zonen kann ein eigener NSEC3-Record für jedes unsignierte Kind Signatur- und Speicheraufwand erzeugen. Opt-Out lässt einen Bereich unsichere Delegationen überdecken, ohne für jede einen eigenen Hash-Record zu führen.

Die Einsparung ist real, die semantische Einschränkung ebenso. Laut RFC 5155 behauptet ein Opt-Out-Bereich weder Existenz noch Nichtexistenz einer unsicheren Delegation darin. Andere autoritative Daten bleiben geschützt, doch der Nachweis ist an dieser Grenze bewusst schmaler. Die Zone erhält günstigere Delegationsänderungen und gibt dafür die gleiche kryptografische Aussage über jedes unsignierte Kind auf.

Opt-Out ist damit eine Governance-Entscheidung, keine neutrale Option. Es bestimmt, für welche Abwesenheiten der Betreiber einsteht. RFC 9276 rät kleinen Zonen davon ab und sieht einen sinnvollen Einsatz nur bei sehr großen, dynamischen und dünn signierten Delegationszonen.

Eine gecachte Lücke beantwortet spätere Fragen

RFC 8198 erlaubt validierenden Resolvern, gecachte NSEC- oder NSEC3-Bereiche aggressiv zu nutzen. Fällt eine spätere Anfrage in einen bereits leer bewiesenen Bereich, kann der Resolver die negative Antwort erzeugen, ohne erneut beim autoritativen Server nachzufragen.

Das senkt Latenz, Last und die Offenlegung nutzloser Anfragen und kann einen Teil zufälliger Label-Angriffe abfangen. Der Cache wendet nun aber eine signierte Aussage auf künftige Fragen an; ihre Lebensdauer wird zur Betriebsbedingung.

Die TTLs von NSEC oder NSEC3 bestimmen zusammen mit den negativen Cache-Werten der Zone, wann ein neu angelegter Name funktionieren kann. Wird er kurz nach einem breiten Abwesenheitsnachweis veröffentlicht, dürfen Validatoren noch korrekt „nicht vorhanden“ aus dem Cache antworten. Nicht das Protokoll ist fehlerhaft, sondern der Änderungsplan hat das Gültigkeitsfenster ignoriert.

Aktuelle Praxis bevorzugt Einfachheit

RFC 9276 empfiehlt NSEC, wenn die Eigenschaften von NSEC3 nicht gebraucht werden. Ist NSEC3 erforderlich, verlangt es null zusätzliche Iterationen und empfiehlt ein leeres Salt. Zusätzliche Iterationen erhöhen Rechenlast, CPU-Erschöpfungsrisiko und Interoperabilitätsfehler; ein statisches Salt hilft wenig, weil der vollständige Name die Berechnung bereits zonenspezifisch macht.

Nach Parameteränderungen sollen Betreiber bekannte nicht vorhandene Namen über die Secondary-Server prüfen. Positive Records können gesund aussehen, während die negative Kette veraltet, abweichend oder für eine Implementierung zu teuer ist.

Die RFCs definieren Mechanismus und heutige Praxis; sie beweisen keine konkrete Betriebsqualität. Diese muss an den tatsächlichen autoritativen und validierenden Rändern gemessen werden.

Quellen