8. Validator Considerations (Hinweise für Validatoren)

8.1. Responses with Unknown Hash Types (Antworten mit unbekannten Hash-Typen)

Der Validator MUSS NSEC3 RRs mit unbekanntem Hash-Typ ignorieren. Praktisch werden Antworten, die nur solche NSEC3 RRs enthalten, typischerweise als falsch (bogus) eingestuft.

8.2. Verifying NSEC3 RRs (Verifizierung von NSEC3 RRs)

Der Validator MUSS NSEC3 RRs ignorieren, deren Flag-Felder (Flag fields) nicht den Wert null oder eins haben.

Enthält die Antwort NSEC3 RRs dieser Zone mit unterschiedlichen Werten für Hash-Algorithmus (hash algorithm), Iterationen (iterations) oder Salt (salt), KANN der Validator die Antwort als falsch behandeln.

8.3. Closest Encloser Proof (Beweis des nächsten einschließenden Vorfahren)

Zur Validierung des Closest-Encloser-Beweises MUSS der Validator den längsten Namen X finden, sodass

X ein Vorfahr des QNAME ist und von einem in der Antwort vorhandenen NSEC3 RR getroffen wird (match). Dies ist der Kandidat für den nächsten einschließenden Vorfahren, und
der um ein Label längere Name (aber weiterhin Vorfahr des QNAME oder gleich dem QNAME) von einem in der Antwort vorhandenen NSEC3 RR abgedeckt wird (cover).

Ein möglicher Algorithmus zur Verifikation dieses Beweises:

Setzen Sie SNAME=QNAME. Löschen Sie das Flag (flag).
Prüfen Sie, ob SNAME existiert:
- Gibt es in der Antwort keinen zu SNAME passenden NSEC3 RR (Owner-Name entspricht dem Hash von SNAME als einzelnes Label dem Zonennamen vorangestellt), löschen Sie das Flag.
- Gibt es in der Antwort einen NSEC3 RR, der SNAME abdeckt, setzen Sie das Flag.
- Gibt es einen passenden NSEC3 RR und ist das Flag gesetzt, ist der Beweis abgeschlossen; SNAME ist der nächste einschließende Vorfahr.
- Gibt es einen passenden NSEC3 RR, aber das Flag ist nicht gesetzt, ist die Antwort falsch.
Kürzen Sie SNAME um ein Label von links, gehen Sie zu Schritt 2.

Ist der nächste einschließende Vorfahr gefunden, MUSS der Validator prüfen, ob der NSEC3 RR, der den nächsten einschließenden Vorfahren als ursprünglichen Owner-Namen hat, aus der richtigen Zone stammt. Das DNAME-Typbit DARF NICHT gesetzt sein, und das NS-Typbit darf nur gesetzt sein, wenn das SOA-Typbit gesetzt ist. Andernfalls deutet dies darauf hin, dass ein Angreifer versucht, die Existenz von RRs zu verleugnen, für die der Server nicht autoritativ ist.

Im Folgenden bedeutet die Formulierung „Closest (Provable) Encloser Proof für X“, dass der obige Algorithmus (oder ein äquivalenter) durch den Nachweis beweist, dass ein Vorfahr von X sein nächster einschließender Vorfahr ist, um die Nichtexistenz von X zu zeigen.

8.4. Validating Name Error Responses (Validierung von Namensfehler-Antworten)

Der Validator MUSS prüfen, dass der Closest-Encloser-Beweis für den QNAME in der Antwort vorhanden ist und dass ein NSEC3 RR existiert, der die Wildcard am nächsten einschließenden Vorfahren abdeckt (d. h. der Name, der durch Voranstellen eines Stern-Labels vor dem nächsten einschließenden Vorfahren gebildet wird).

8.5. Validating No Data Responses, QTYPE is not DS (Validierung von No-Data-Antworten, QTYPE ist nicht DS)

Der Validator MUSS prüfen, dass ein zum QNAME passender NSEC3 RR existiert und im Feld Type Bit Maps die Typen QTYPE und CNAME NICHT gesetzt sind.

Dieser Test deckt auch den Fall ab, dass der NSEC3 RR wegen eines leeren Nicht-Endknotens existiert; dann hat der NSEC3 RR ein leeres Type-Bitmap-Feld.

8.6. Validating No Data Responses, QTYPE is DS (Validierung von No-Data-Antworten, QTYPE ist DS)

Gibt es in der Antwort einen zum QNAME passenden NSEC3 RR, DÜRFEN im Feld Type Bit Maps die Bits für DS und CNAME NICHT gesetzt sein.

Gibt es keinen solchen NSEC3 RR, MUSS der Validator prüfen, dass der Closest-Provable-Encloser-Beweis für den QNAME in der Antwort vorhanden ist und dass der NSEC3 RR, der den „next closer“-Namen abdeckt, das Opt-Out-Bit gesetzt hat.

8.7. Validating Wildcard No Data Responses (Validierung von Wildcard-No-Data-Antworten)

Der Validator MUSS den Closest-Encloser-Beweis für den QNAME verifizieren und MUSS in der Antwort einen NSEC3 RR finden, der zum Wildcard-Namen passt, der durch Voranstellen eines Stern-Labels vor dem nächsten einschließenden Vorfahren erzeugt wird. Außerdem DÜRFEN im zum Wildcard passenden NSEC3 RR die Bits für QTYPE und CNAME nicht gesetzt sein.

8.8. Validating Wildcard Answer Responses (Validierung von Wildcard-Antworten)

Das in der Antwort verifizierte Wildcard-Antwort-RRSet liefert dem Validator den (Kandidaten-)nächsten einschließenden Vorfahren des QNAME. Dieser ist der direkte Vorfahr der erzeugenden Wildcard.

Der Validator MUSS prüfen, dass in der Antwort ein NSEC3 RR existiert, der den „next closer“-Namen zum QNAME abdeckt. Damit wird bewiesen, dass der QNAME selbst nicht existiert und die richtige Wildcard zur Erzeugung der Antwort verwendet wurde.

8.9. Validating Referrals to Unsigned Subzones (Validierung von Verweisen auf unsignierte Unterzonen)

Der Delegationsname in einem Verweis ist der Owner-Name des NS RRSets im Authority-Abschnitt der Verweisantwort.

Gibt es einen zum Delegationsnamen passenden NSEC3 RR, MUSS der Validator sicherstellen, dass im Feld Type Bit Maps des NSEC3 RR das NS-Bit gesetzt und das DS-Bit nicht gesetzt ist. Der Validator MUSS außerdem sicherstellen, dass der NSEC3 RR aus der richtigen (Eltern-)Zone stammt; dies geschieht durch Prüfung, dass im Feld Type Bit Maps dieses NSEC3 RR das SOA-Bit nicht gesetzt ist.

Hinweis: Das Vorhandensein des NS-Bits impliziert das Fehlen des DNAME-Bits; ein separates Prüfen des DNAME-Bits ist nicht erforderlich.

Gibt es keinen zum Delegationsnamen passenden NSEC3 RR, MUSS der Validator den Closest-Provable-Encloser-Beweis für den Delegationsnamen verifizieren. Der Validator MUSS prüfen, dass im NSEC3 RR, der den „next closer“-Namen zum Delegationsnamen abdeckt, das Opt-Out-Bit gesetzt ist.