Zusammenfassung

  • NSEC und NSEC3 authentisieren präzise negative Aussagen über den Inhalt einer signierten Zone. Der Beweis hängt von Signierer, Zone, Abfrage, TTL und Signaturzeitraum ab.
  • Opt-Out lässt bestimmte unsichere Delegationen aus der NSEC3-Kette aus. Das Intervall kann das Fehlen eines DS belegen, ohne jeden übersprungenen Namen für nicht existent zu erklären.

Ein signiertes „nicht vorhanden“ ist keine Ewigkeit

Ein Resolver fragt einen fehlenden Adressdatensatz ab. Der autoritative Server antwortet mit NXDOMAIN oder mit einem vorhandenen Namen ohne den gefragten Typ. In einer signierten Zone kann der Resolver Vertrauenskette, Signaturen und die NSEC- oder NSEC3-Begründung prüfen.

Damit lässt sich eine positive Antwort nicht beliebig durch eine gefälschte Negation ersetzen. RFC 4035 begrenzt die Aussage jedoch auf ein RRset, das in einer signierten Zone nicht vorhanden ist. Der Beweis durchsucht weder die gesamte Historie noch entscheidet er vertragliche Ansprüche.

Ein Name kann fehlen, weil er nie registriert, abgelaufen, gesperrt, falsch provisioniert, umdelegiert oder irrtümlich aus der signierten Zone entfernt wurde. DNSSEC trennt authentisierte von nicht authentisierten Aussagen. Es unterscheidet diese Ursachen nicht selbst.

NSEC macht Reihenfolge beweisbar

Ein NSEC verbindet einen owner name mit dem nächsten Namen in kanonischer Ordnung und enthält eine Bitmap der vorhandenen Typen. Das signierte Intervall belegt, dass dazwischen kein anderer owner name liegt. Die Bitmap belegt, dass ein vorhandener Name einen Typ nicht besitzt.

NXDOMAIN und NODATA sind deshalb verschieden. Das eine verneint den Namen, das andere den Typ. Ein empty non-terminal kann selbst kein RRset und dennoch Nachfahren haben. Wildcards verlangen zusätzlich den Ausschluss einer näheren Quelle für eine Expansion.

Die validierte Negation ist ein Argument. Der Validator bestimmt zuständige Zone, überdeckendes Intervall, Typ-Bitmap, mögliche Wildcards, Signaturfenster sowie DS- und DNSKEY-Kette bis zum lokalen Vertrauensanker.

Die NSEC-Reihenfolge erlaubt zugleich Zone Walking. NSEC3 sollte diese direkte Offenlegung erschweren. Das zeigt den Zielkonflikt: Prüfbarkeit kann operative Struktur sichtbar machen.

NSEC3 verschleiert, ohne Geheimhaltung zu schaffen

NSEC3 hasht Namen mit veröffentlichten Parametern und signiert Intervalle der Ergebnisse. Der Resolver wiederholt die Berechnung für closest encloser, Abfragenamen und Wildcard-Kandidaten.

Vorhersagbare Labels lassen sich weiterhin offline testen. Das IANA-Register weist derzeit nur SHA-1 als NSEC3-Hashalgorithmus zu. RFC 9276 erläutert, dass weitere Iterationen die Kosten für Signierer und Validatoren erhöhen, moderne Ratesuche aber kaum proportional bremsen. Die normale Empfehlung lautet null Iterationen, leerer Salt und NSEC, wenn Enumeration nicht problematisch ist.

Der größere Parameter ist nicht automatisch die bessere Governance. Entscheidend ist, welchen Schutz laufender Code erzeugt und wer seine gemeinsamen Kosten trägt.

Opt-Out lässt einen Bereich bewusst unentschieden

Große delegationszentrierte Zonen würden stark wachsen, wenn jedes unsichere Kind ein eigenes NSEC3 und eine Signatur bräuchte. Opt-Out erlaubt, Delegationen ohne DS und abgeleitete empty non-terminals auszulassen.

RFC 7129 nennt die Grenze deutlich: Ein Opt-Out-NSEC3 kann die Existenz von Namen in seinem Intervall weder beweisen noch verneinen. Es kann zeigen, dass kein authentisierter DS die Kandidatendelegation sichert und der weitere Pfad insecure ist. Es rechtfertigt kein name_absent=true für jedes ausgelassene Label.

Ein belastbares Ereignis speichert Intervall, Opt-Out, DS-Abwesenheit, mögliche unsichere Delegation und Validatorstatus getrennt. Ein grünes „authentisiert“ ohne diese Felder verliert die wichtigste Semantik.

Bei einem Streit kann ein Kind ohne DS tatsächlich delegiert sein und im Opt-Out-Intervall liegen. Der Elternbeweis entscheidet weder Registry-Absicht noch Konsistenz aller Autoritäten oder Legitimität der Provisionierung.

Der Cache kann ohne neue Autoritätsabfrage antworten

RFC 2308 definiert negative Zwischenspeicherung. RFC 8020 erlaubt einen NXDOMAIN Cut für Nachfahren. RFC 8198 lässt validierende Resolver weitere negative Antworten aus bereits geprüften NSEC- oder NSEC3-Intervallen synthetisieren.

Das senkt Latenz, Last und Query-Leakage. Zugleich verwahrt der Resolver Beweismaterial. Ein Nutzer kann eine gültige Negation erhalten, obwohl die Autorität nicht erneut befragt wurde. Selbst nach einer Zonenänderung darf altes Material bis zu TTL- und Signaturgrenze weiterwirken.

Ein Audit braucht Name, Typ, rcode, Zone, Beweisrecords, closest encloser, Wildcard, Opt-Out, Empfangszeit, TTL, Signaturbeginn und -ende, Vertrauenskette sowie die Angabe, ob die Antwort autoritativ oder synthetisiert war. Ein NXDOMAIN-Screenshot reicht nicht.

Ein negativer Beweis ist kein Löschbefehl

Registry und Registrar steuern unterschiedliche Transaktionen. Der autoritative Betreiber veröffentlicht die Zone. Der Registrant kann Vertragsrechte haben. Ein Review-Gremium kontrolliert definierte Rechtsbehelfe. Der Resolver kontrolliert seinen Cache. NSEC verschmilzt diese Rollen nicht.

Die Signatur beweist weder Benachrichtigung, Zahlungsverzug, Ende einer Berechtigung noch Abschluss einer Beschwerde. Sie vergibt den Namen nicht an Dritte und macht den Signierer nicht zum Eigentümer des zugrunde liegenden Anspruchs.

Die Verantwortungskette verbindet vier getrennte Akten: Registrierung oder Berechtigung, autorisierte Provisionierungsentscheidung, signierte Zonenversion und validierte Beobachtungen. Die Zone ist die laufende öffentliche Realität; die anderen Akten erklären Entstehung und Korrektur.

Die dünne gemeinsame Schicht

Heng Lus Prinzip der minimalen Schicht ordnet die Funktion richtig ein. Die gemeinsame Ebene muss validierte Daten, validierte Abwesenheit, unsichere Delegation und bogus evidence unterscheiden. Sie muss keinen globalen Namensanspruch entscheiden.

Technisch zählen Zone Cut, DS/DNSKEY-Kette, Parameter, Intervalle, Opt-Out, Wildcard, TTL, Signaturfenster und Validatorpolitik. Policy heilt keinen ungültigen Beweis; eine gültige Signatur verleiht privater Policy keine Souveränität.

Die haltbare Formulierung bleibt eng: DNSSEC authentisiert, was eine signierte Zone zu einem begrenzten Zeitpunkt nicht enthielt. Ursache und Namensanspruch sind andere Entscheidungen.

Quellen