8. Validator Considerations (Considerazioni sul validatore)

8.1. Responses with Unknown Hash Types (Risposte con tipi di hash sconosciuti)

Un validatore DEVE ignorare gli RR NSEC3 con tipi di hash sconosciuti. Il risultato pratico è che le risposte contenenti solo tali RR NSEC3 saranno in genere considerate false (bogus).

8.2. Verifying NSEC3 RRs (Verifica degli RR NSEC3)

Un validatore DEVE ignorare gli RR NSEC3 con valore del campo Flags diverso da zero o uno.

Un validatore PUÒ trattare una risposta come falsa se la risposta contiene RR NSEC3 con valori diversi per algoritmo di hash, iterazioni o salt tra loro per quella zona.

8.3. Closest Encloser Proof (Prova dell'incapsulante più vicino)

Per verificare una prova dell'incapsulante più vicino, il validatore DEVE trovare il nome più lungo, X, tale che

X è un antenato del QNAME che è corrispondente a un RR NSEC3 presente nella risposta. È un candidato per l'incapsulante più vicino, e
Il nome lungo un'etichetta in più di X (ma ancora antenato di, o uguale a, QNAME) è coperto da un RR NSEC3 presente nella risposta.

Un possibile algoritmo per verificare questa prova è il seguente:

Impostare SNAME=QNAME. Azzerare il flag.
Verificare se SNAME esiste:
- Se non c'è alcun RR NSEC3 nella risposta che corrisponde a SNAME (cioè un RR NSEC3 il cui nome del titolare è uguale all'hash di SNAME, prefissato come singola etichetta al nome della zona), azzerare il flag.
- Se c'è un RR NSEC3 nella risposta che copre SNAME, impostare il flag.
- Se c'è un RR NSEC3 corrispondente nella risposta e il flag era impostato, allora la prova è completa e SNAME è l'incapsulante più vicino.
- Se c'è un RR NSEC3 corrispondente nella risposta ma il flag non è impostato, allora la risposta è falsa.
Troncare SNAME di un'etichetta da sinistra, tornare al passo 2.

Una volta scoperto l'incapsulante più vicino, il validatore DEVE verificare che l'RR NSEC3 che ha l'incapsulante più vicino come nome del titolare originale provenga dalla zona corretta. Il bit di tipo DNAME NON DEVE essere impostato e il bit di tipo NS PUÒ essere impostato solo se il bit di tipo SOA è impostato. Se non è così, sarebbe un'indicazione che un attaccante li sta usando per negare falsamente l'esistenza di RR per cui il server non è autoritativo.

Nelle descrizioni seguenti, la frase "una prova dell'incapsulante (più vicino) dimostrabile per X" significa che l'algoritmo sopra (o un algoritmo equivalente) dimostra che X non esiste dimostrando che un antenato di X è il suo incapsulante più vicino.

8.4. Validating Name Error Responses (Convalida delle risposte Name Error)

Un validatore DEVE verificare che sia presente nella risposta una prova dell'incapsulante più vicino per il QNAME e che ci sia un RR NSEC3 che copre il jolly all'incapsulante più vicino (cioè il nome formato anteponendo l'etichetta asterisco all'incapsulante più vicino).

8.5. Validating No Data Responses, QTYPE is not DS (Convalida delle risposte No Data, QTYPE non è DS)

Il validatore DEVE verificare che sia presente un RR NSEC3 che corrisponde al QNAME e che né il QTYPE né il tipo CNAME siano impostati nel suo campo Type Bit Maps.

Si noti che questa verifica copre anche il caso in cui l'RR NSEC3 esiste perché corrisponde a un non terminale vuoto, nel qual caso l'RR NSEC3 avrà un campo Type Bit Maps vuoto.

8.6. Validating No Data Responses, QTYPE is DS (Convalida delle risposte No Data, QTYPE è DS)

Se è presente nella risposta un RR NSEC3 che corrisponde al QNAME, quell'RR NSEC3 NON DEVE avere i bit corrispondenti a DS e CNAME impostati nel suo campo Type Bit Maps.

Se non esiste tale RR NSEC3, il validatore DEVE verificare che sia presente nella risposta una prova dell'incapsulante più vicino dimostrabile per il QNAME e che l'RR NSEC3 che copre il nome "next closer" abbia il bit Opt-Out impostato.

8.7. Validating Wildcard No Data Responses (Convalida delle risposte Wildcard No Data)

Il validatore DEVE verificare una prova dell'incapsulante più vicino per il QNAME e DEVE trovare nella risposta un RR NSEC3 che corrisponde al nome jolly generato anteponendo l'etichetta asterisco all'incapsulante più vicino. Inoltre i bit corrispondenti sia al QTYPE sia a CNAME NON DEVONO essere impostati nell'RR NSEC3 che corrisponde al jolly.

8.8. Validating Wildcard Answer Responses (Convalida delle risposte Wildcard Answer)

L'RRSet risposta jolly verificato nella risposta fornisce al validatore un (candidato) incapsulante più vicino per il QNAME. Questo incapsulante più vicino è l'antenato immediato del jolly generatore.

I validatori DEVONO verificare che sia presente nella risposta un RR NSEC3 che copre il nome "next closer" rispetto al QNAME. Ciò dimostra che il QNAME stesso non esisteva e che è stato usato il jolly corretto per generare la risposta.

8.9. Validating Referrals to Unsigned Subzones (Convalida dei referral verso sottozone non firmate)

Il nome della delega in un referral è il nome del titolare dell'RRSet NS presente nella sezione authority della risposta di referral.

Se è presente nella risposta un RR NSEC3 che corrisponde al nome della delega, il validatore DEVE assicurarsi che il bit NS sia impostato e che il bit DS non sia impostato nel campo Type Bit Maps dell'RR NSEC3. Il validatore DEVE anche assicurarsi che l'RR NSEC3 provenga dalla zona corretta (cioè genitore). Ciò si fa assicurandosi che il bit SOA non sia impostato nel campo Type Bit Maps di questo RR NSEC3.

Si noti che la presenza del bit NS implica l'assenza del bit DNAME, quindi non occorre verificare il bit DNAME nel campo Type Bit Maps dell'RR NSEC3.

Se non è presente alcun RR NSEC3 che corrisponde al nome della delega, il validatore DEVE verificare una prova dell'incapsulante più vicino dimostrabile per il nome della delega. Il validatore DEVE verificare che il bit Opt-Out sia impostato nell'RR NSEC3 che copre il nome "next closer" rispetto al nome della delega.