Zusammenfassung

  • Ein NSEC3-Intervall mit Opt-Out kann eine vorhandene unsichere Delegation abdecken, ohne deren Existenz oder Nichtexistenz zu behaupten. Fehlende Knoten sind deshalb kein signierter Löschbeleg.
  • Der Parent-Betreiber muss Quellbestand, Signer-Generation, NS/DS-Antworten aller Autoritäten und Validatorurteile getrennt vergleichen. Vollständigkeit kommt aus dem Register, nicht aus der Denial-Projektion.

Ein Prüfsystem rekonstruiert einen vollständig signierten NSEC3-Ring. Für einen Child-Namen findet es keinen passenden Knoten und meldet eine fehlende Delegation. Eine direkte Abfrage derselben Parent-Zone liefert jedoch einen NS-Verweis ohne DS. Der Name ist delegiert, aber nicht abgesichert.

Beide Beobachtungen sind echt. Falsch ist nur die Annahme, der Ring müsse jeden delegierten Namen enthalten.

RFC 5155 gestattet, den gehashten Owner Name einer unsicheren Delegation wegzulassen, wenn ein NSEC3 Record mit gesetztem Opt-Out-Bit den Hash abdeckt. Dieser Record trifft ausdrücklich keine Aussage darüber, ob die Delegation innerhalb der Spanne existiert. Dadurch kann der Parent geeignete Delegationen ändern, ohne die benachbarten Kettenglieder neu zu bilden.

Das Register ist Eingabe, nicht Ergebnis

Im Quellbestand stehen Name, NS, gegebenenfalls Glue, DS, Änderungszeit und Freigabe. Der Signer erzeugt daraus eine nach Hashwerten geordnete Beweiskette. NSEC3 enthält Algorithmus, Flags, Iterationen, Salt, nächsten Hash und Type Bitmap.

Eine unsichere Delegation besitzt NS, aber kein DS. Nur für diese begrenzte Klasse darf Opt-Out eine Darstellung auslassen. Sichere Delegationen und autoritative Parent-Daten behalten ihre Repräsentationspflicht. Eine beliebige Lücke ist kein Opt-Out, sondern eine fehlerhafte Signer-Generation.

Jede Auslassung braucht deshalb eine Rückverknüpfung: Originalname, NS/DS-Zustand, berechneter Hash, abdeckender Record, Flag, Bitmap, Signer-Generation und Antworten sämtlicher relevanter Autoritäten. Ohne diese Kette sehen zulässige Auslassung, Signerfehler und veralteter Secondary gleich aus.

Opt-Out erzeugt Unbestimmtheit

Für ein Inventarsystem darf ein Name in einer Opt-Out-Spanne nicht als nicht vorhanden gelten. Der korrekte Zustand lautet aus dieser Kette nicht bestimmbar. Vollständigkeit muss aus einer autorisierten Quelldatenbank, einem erlaubten Transfer oder direkten NS- und DS-Abfragen kommen.

RFC 8198 zieht dieselbe Grenze für aggressive negative Zwischenspeicherung. Validierte NSEC/NSEC3-Bereiche können manche neue Negativantwort erzeugen. Trägt der abdeckende NSEC3 Record Opt-Out, beweist er die Nichtexistenz des Namens nicht; die Synthese ist daher unzulässig.

Ein Sicherheitsprodukt, das trotzdem Abwesenheit ableitet, verschärft nicht die Prüfung. Es erfindet eine nicht signierte Aussage.

Der nächste wirkliche Vorfahr kann unbeweisbar bleiben

Wildcard- und Negativbeweise verwenden den Closest Encloser, den längsten vorhandenen Vorfahren. Fehlt für eine ausgelassene Delegation oder ein allein von ihr abgeleitetes Empty Non-Terminal ein NSEC3-Knoten, kann die Kette nur den Closest Provable Encloser zeigen.

Im Beleg gehören Anfrage, NSEC3 und RRSIG, Next-Closer-Berechnung, Match oder Coverage, möglicher Umlauf im Hashraum, Bitmap und Prüfzeit zusammen. Ein grüner Status ohne Rohobjekte verrät nicht, wo der Beweis endete und wo Opt-Out eine Aussage verhinderte.

Weniger Iterationen sind die aktuelle Disziplin

RFC 9276 empfiehlt NSEC, wenn NSEC3 nicht benötigt wird. Für NSEC3 gilt Algorithmus 1 mit null zusätzlichen Iterationen und leerem Salt als empfohlener Ausgangspunkt.

Zusätzliche Iterationen erhöhen Rechenlast und Interoperabilitätsrisiko. Salt macht erratbare Namen nicht geheim. Ein Validator kann Werte oberhalb seiner Grenze als insecure behandeln oder SERVFAIL liefern und nach Prüfung des betreffenden Records EDE 27 ausgeben. Das ist eine Ressourcenentscheidung, kein Delegationsinventar.

Für kleine Zonen ist Opt-Out nicht empfohlen. Es kann bei sehr großen, delegation-zentrierten und überwiegend unsicher delegierten Zonen gerechtfertigt sein. Größe, DS-Anteil, Änderungsrate, Signierkosten und Prüfbarkeit müssen diese Entscheidung tragen.

Eine Parameteränderung ersetzt die ganze Generation

Salt oder Iterationen zu ändern verlangt eine neue vollständige NSEC3-Kette und neue Signaturen. Validatoren prüfen die Parameter im NSEC3 Record; NSEC3PARAM allein ist kein Negativbeweis.

Vor Aktivierung werden Quellbestand, alte und neue Generation, Serial, RRSIG-Fenster und Transferstand jedes Secondary verglichen. Proben umfassen einen bekannten nicht existierenden Namen, eine ausgelassene unsichere Delegation, eine sichere Delegation und eine Wildcard-Grenze an jeder Autoritätsadresse.

Bleiben zwei Generationen außerhalb des geplanten Fensters aktiv, ist Erreichbarkeit kein Konsistenznachweis. TTL und alte Cache-Beweise gehören zur Entscheidung zwischen Abschluss und Rückkehr zur letzten kohärenten Generation.

Quellen