4. Il record di risorsa NSEC (The NSEC Resource Record)
Il record di risorsa NSEC elenca due cose separate: il nome del proprietario successivo (nell'ordine canonico della zona) che contiene dati autorevoli o un RRset NS di punto di delega (delegation point), e l'insieme dei tipi RR presenti al nome del proprietario del RR NSEC [RFC3845]. L'insieme completo dei RR NSEC in una zona indica quali RRsets autorevoli esistono in una zona e forma anche una catena di nomi di proprietari autorevoli nella zona. Queste informazioni sono utilizzate per fornire una negazione autenticata dell'esistenza (authenticated denial of existence) per i dati DNS, come descritto in [RFC4035].
Poiché ogni nome autorevole in una zona deve far parte della catena NSEC, i RR NSEC DEVONO essere presenti ai nomi contenenti un RR CNAME. Questo è un cambiamento rispetto alla specifica DNS tradizionale [RFC1034], che affermava che se un CNAME è presente per un nome, è l'unico tipo consentito per quel nome. In una zona firmata, RRSIG (vedere Sezione 3) e NSEC DEVONO esistere allo stesso nome del record di risorsa CNAME.
Vedere [RFC4035] per una discussione su come un firmatario di zona determina precisamente quali RR NSEC deve includere in una zona.
Il valore di tipo per il tipo RR NSEC è 47.
Il RR NSEC è indipendente dalla classe.
Il RR NSEC DOVREBBE avere lo stesso valore TTL del campo TTL minimo SOA. Questo è nello spirito del caching negativo ([RFC2308]).
4.1. Formato wire RDATA NSEC (NSEC RDATA Wire Format)
Il RDATA del RR NSEC è come mostrato di seguito:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. Il campo Next Domain Name (The Next Domain Name Field)
Il campo Next Domain contiene il nome del proprietario successivo (nell'ordine canonico della zona) che ha dati autorevoli o contiene un RRset NS di punto di delega; vedere Sezione 6.1 per una spiegazione dell'ordine canonico. Il valore del campo Next Domain Name nell'ultimo record NSEC nella zona è il nome dell'apice della zona (zone apex) (il nome del proprietario del RR SOA della zona). Questo indica che il nome del proprietario del RR NSEC è l'ultimo nome nell'ordine canonico della zona.
Un mittente NON DEVE utilizzare la compressione del nome DNS sul campo Next Domain Name quando trasmette un RR NSEC.
I nomi dei proprietari di RRsets per i quali la zona data non è autorevole (come i record colla (glue records)) NON DEVONO essere elencati nel Next Domain Name a meno che almeno un RRset autorevole non esista allo stesso nome del proprietario.
4.1.2. Il campo Type Bit Maps (The Type Bit Maps Field)
Il campo Type Bit Maps identifica i tipi di RRset che esistono al nome del proprietario del RR NSEC.
Lo spazio di tipo RR è diviso in 256 blocchi finestra, ciascuno rappresentante i 8 bit meno significativi dello spazio di tipo RR a 16 bit. Ogni blocco che ha almeno un tipo RR attivo è codificato utilizzando un singolo ottetto numero finestra (da 0 a 255), un singolo ottetto lunghezza bitmap (da 1 a 32) che indica il numero di ottetti utilizzati per la bitmap del blocco finestra, e fino a 32 ottetti (256 bit) di bitmap.
I blocchi sono presenti nel RDATA del RR NSEC in ordine numerico crescente.
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
dove "|" denota la concatenazione.
Ogni bitmap codifica i 8 bit meno significativi dei tipi RR all'interno del blocco finestra, in ordine di bit di rete. Il primo bit è il bit 0. Per il blocco finestra 0, il bit 1 corrisponde al tipo RR 1 (A), il bit 2 corrisponde al tipo RR 2 (NS), e così via. Per il blocco finestra 1, il bit 1 corrisponde al tipo RR 257, il bit 2 corrisponde al tipo RR 258, e così via. Se un bit è impostato, indica che un RRset di quel tipo è presente per il nome del proprietario del RR NSEC. Se un bit è cancellato, indica che nessun RRset di quel tipo è presente per il nome del proprietario del RR NSEC.
I bit che rappresentano pseudo-tipi (pseudo-types) DEVONO essere cancellati, poiché non appaiono nei dati di zona. Se incontrati, DEVONO essere ignorati alla lettura.
I blocchi senza tipi presenti NON DEVONO essere inclusi. Gli ottetti zero finali nella bitmap DEVONO essere omessi. La lunghezza della bitmap di ogni blocco è determinata dal codice di tipo con il valore numerico più grande, all'interno di quel blocco, tra l'insieme dei tipi RR presenti al nome del proprietario del RR NSEC. Gli ottetti zero finali non specificati DEVONO essere interpretati come ottetti zero.
La bitmap per il RR NSEC a un punto di delega richiede attenzione speciale. I bit corrispondenti al RRset NS di delega e a qualsiasi RRset per cui la zona genitore ha dati autorevoli DEVONO essere impostati; i bit corrispondenti a qualsiasi RRset non-NS per cui il genitore non è autorevole DEVONO essere cancellati.
Una zona NON DEVE includere un RR NSEC per qualsiasi nome di dominio che contiene solo record colla.
4.1.3. Inclusione di nomi wildcard in NSEC RDATA (Inclusion of Wildcard Names in NSEC RDATA)
Se un nome del proprietario wildcard appare in una zona, l'etichetta wildcard ("*") viene trattata come simbolo letterale ed è trattata allo stesso modo di qualsiasi altro nome del proprietario ai fini della generazione dei RR NSEC. I nomi dei proprietari wildcard appaiono nel campo Next Domain Name senza alcuna espansione wildcard. [RFC4035] descrive l'impatto dei wildcard sulla negazione autenticata dell'esistenza.
4.2. Formato di presentazione RR NSEC (The NSEC RR Presentation Format)
Il formato di presentazione della porzione RDATA è il seguente:
Il campo Next Domain Name è rappresentato come nome di dominio.
Il campo Type Bit Maps è rappresentato come sequenza di mnemonici di tipo RR. Quando il mnemonico non è noto, DEVE essere utilizzata la rappresentazione TYPE descritta nella Sezione 5 di [RFC3597].
4.3. Esempio di RR NSEC (NSEC RR Example)
Il seguente RR NSEC identifica i RRsets associati ad alfa.example.com. e identifica il nome autorevole successivo dopo alfa.example.com.
alfa.example.com. 86400 IN NSEC host.example.com. (
A MX RRSIG NSEC TYPE1234 )
I primi quattro campi di testo specificano il nome, TTL, classe e tipo RR (NSEC). La voce host.example.com. è il nome autorevole successivo dopo alfa.example.com. in ordine canonico. I mnemonici A, MX, RRSIG, NSEC e TYPE1234 indicano che ci sono RRsets A, MX, RRSIG, NSEC e TYPE1234 associati al nome alfa.example.com.
La sezione RDATA del RR NSEC sopra sarebbe codificata come:
0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20
Supponendo che un validatore possa autenticare questo record NSEC, potrebbe essere utilizzato per dimostrare che beta.example.com non esiste, o per dimostrare che non c'è alcun record AAAA associato ad alfa.example.com. La negazione autenticata dell'esistenza è discussa in [RFC4035].
Navigazione dei capitoli correlati: