Zusammenfassung

  • RFC 5155 erlaubt, bestimmte unsignierte Delegationen aus der NSEC3-Kette auszulassen, wenn der abdeckende Datensatz das Opt-Out-Flag trägt.
  • Dieser Datensatz behauptet weder die Existenz noch die Nichtexistenz der abgedeckten unsicheren Delegationen; er authentifiziert eine enger gefasste Negativaussage.
  • Eine sichere Delegation braucht ein signiertes DS-RRset und eine validierte Vertrauenskette, nicht bloß eine gültige NSEC3-Signatur in der Nähe des abgefragten Hashes.
  • Betriebsnachweise müssen sicher, unsicher, bogus und unbestimmt auseinanderhalten, statt alles als „DNSSEC bestanden“ zusammenzufassen.

Man stelle sich einen Resolver-Trace vor, in dem jede RRSIG validiert wird, die NSEC3-Intervalle zusammenpassen und das Ergebnis grün erscheint. Ein späterer Audit-Export macht daraus „Child-Delegation gesichert“. Der abgefragte Name liegt jedoch in einem Opt-Out-Intervall. Der Nachweis war authentisch; die Schlussfolgerung war zu weit.

Das Beispiel ist hypothetisch und keinem Register oder Betreiber zugeschrieben. Es zeigt ein Reichweitenproblem: Kryptografische Gültigkeit erweitert nicht die Aussage, die ein signierter Datensatz tatsächlich enthält.

Was Opt-Out verändert

RFC 5155 definiert NSEC3 als gehashte Form des authentifizierten Nichtexistenznachweises. Statt lesbare Owner-Namen in kanonischer Reihenfolge offenzulegen, signiert eine Zone Datensätze, die eine nach Hashwerten geordnete Kette bilden.

In einer delegationsreichen Zone kann es aufwendig sein, für jedes unsignierte Child einen NSEC3-Datensatz samt Signatur zu pflegen. Opt-Out erlaubt, die Namen qualifizierter unsicherer Delegationen auszulassen. Ein Datensatz mit gesetztem Flag kann null oder mehrere solcher Delegationen überspannen; sie lassen sich hinzufügen oder entfernen, ohne diesen Teil der Kette neu aufzubauen.

Diese betriebliche Einsparung verändert die Bedeutung des Nachweises. RFC 5155 sagt ausdrücklich, dass ein Opt-Out-NSEC3 weder Existenz noch Nichtexistenz der unsicheren Delegationen behauptet, die es abdecken kann. Andere autoritative Daten im Intervall können weiterhin authentifiziert sein, doch das unsignierte Child bleibt bewusst außerhalb des vollständigen kryptografischen Inventars.

Ein gültiger Nachweis kann „unsicher“ ergeben

Am Delegationspunkt ist die Evidenz der Parent-Zone entscheidend. RFC 5155 unterscheidet eine sichere Delegation — NS-RRset plus signiertes DS-RRset — von einer unsicheren Delegation mit NS, aber ohne DS. Erst DS verbindet die authentifizierten Daten des Parents mit dem DNSKEY des Childs.

Eine validierte RRSIG über NSEC3 beweist, dass der Parent genau diese NSEC3-Aussage signiert hat. Sie erzeugt keinen DS-Datensatz für ein abgedecktes Child. Auch das Opt-Out-Bit allein belegt nicht, dass eine bestimmte Delegation existiert. RFC 7129 formuliert die Folge klar: Opt-Out-Datensätze können die Existenz der abgedeckten unsicheren Delegationen weder beweisen noch widerlegen; diese Delegationen erhalten nicht den kryptografischen Schutz von DNSSEC.

Ein Resolver braucht daher mehr als ein grünes Ergebnis einer kryptografischen Einzelprüfung. Er muss den Delegationspunkt bestimmen, DS finden oder dessen Fehlen authentifizieren, den einschlägigen NSEC3-Nachweis bewerten und bei vorhandener Vertrauenskette weiter validieren. Sicher, unsicher, bogus und unbestimmt sind verschiedene Ergebnisse.

Die Reichweite am Ergebnis festhalten

Der Nachweis sollte Anfrage, Antwortcode, Zone und Delegationspunkt nennen. Für NSEC3 gehören Hashalgorithmus, Iterationen, Salt, Owner-Hash, nächster Owner-Hash, Typ-Bitmap und Opt-Out-Flag dazu. Wenn der closest provable encloser Teil des Nachweises ist, sind auch dessen Elemente sowie DNSKEY-, RRSIG-Ergebnisse und Vertrauensanker aufzubewahren.

Cache und Zeit begrenzen die Aussage ebenfalls. TTL, Beginn und Ende der Signaturgültigkeit, Veröffentlichung im Parent und Cache-Alter des Resolvers bestimmen das Beobachtungsfenster. Eine spätere DS-Änderung kann den Sicherheitszustand der Delegation verändern, obwohl der ältere Nachweis im Audit-Speicher bleibt.