Appendice C. Authentication Examples (Esempi di autenticazione)
Gli esempi in questa sezione mostrano come vengono autenticati i messaggi di risposta nell'Appendice B.
C.1. Authenticating an Answer (Autenticazione di una risposta)
La query nell'Appendice B.1 ha restituito un RRset MX per x.w.example.com. Il RRSIG corrispondente indica che il RRset MX è stato firmato da una DNSKEY "example" con algoritmo 5 e tag chiave 38519. Il resolver necessita del RR DNSKEY corrispondente per autenticare questa risposta. La discussione seguente descrive come un resolver potrebbe ottenere questo RR DNSKEY.
Il RRSIG indica che il TTL originale del RRset MX era 3600 e, ai fini dell'autenticazione, il TTL corrente viene sostituito con 3600. Il valore del campo delle etichette RRSIG di 3 indica che la risposta non era il risultato di un'espansione wildcard. Il RRset MX x.w.example.com viene posto in forma canonica e, assumendo che l'ora corrente cada tra le date di inizio e scadenza della firma, la firma viene autenticata.
C.1.1. Authenticating the Example DNSKEY RR (Autenticazione del RR DNSKEY di esempio)
Questo esempio mostra il processo di autenticazione logico che parte da una DNSKEY radice configurata (o un RR DS) e scende nell'albero per autenticare il RR DNSKEY "example" desiderato. Si noti che l'ordine logico è presentato per chiarezza. Un'implementazione può scegliere di costruire l'autenticazione man mano che vengono ricevuti i riferimenti o di costruire la catena di autenticazione solo dopo che tutti gli RRset sono stati ottenuti, o in qualsiasi altra combinazione ritenga appropriata. L'esempio qui dimostra solo il processo logico e non detta alcuna regola di implementazione.
Assumiamo che il resolver inizi con un RR DNSKEY configurato per la zona radice (o un RR DS configurato per la zona radice). Il resolver verifica se questo RR DNSKEY configurato è presente nel RRset DNSKEY radice (o se il RR DS corrisponde a qualche DNSKEY nel RRset DNSKEY radice), se questo RR DNSKEY ha firmato il RRset DNSKEY radice e se la durata della firma è valida. Se tutte queste condizioni sono soddisfatte, tutte le chiavi nel RRset DNSKEY sono considerate autenticate. Il resolver quindi utilizza uno (o più) dei RR DNSKEY radice per autenticare il RRset DS "example". Si noti che il resolver potrebbe dover interrogare la zona radice per ottenere il RRset DNSKEY radice o il RRset DS "example".
Una volta che il RRset DS è stato autenticato utilizzando la DNSKEY radice, il resolver controlla il RRset DNSKEY "example" per un RR DNSKEY "example" che corrisponda a uno dei RR DS "example" autenticati. Se viene trovata una tale DNSKEY "example" corrispondente, il resolver verifica se questo RR DNSKEY ha firmato il RRset DNSKEY "example" e se la durata della firma è valida. Se queste condizioni sono soddisfatte, tutte le chiavi nel RRset DNSKEY "example" sono considerate autenticate.
Infine, il resolver verifica che qualche RR DNSKEY nel RRset DNSKEY "example" utilizzi l'algoritmo 5 e abbia un tag chiave di 38519. Questa DNSKEY viene utilizzata per autenticare il RRSIG incluso nella risposta. Se più RR DNSKEY "example" corrispondono a questo algoritmo e tag chiave, ogni RR DNSKEY viene provato e la risposta viene autenticata se uno qualsiasi dei RR DNSKEY corrispondenti convalida la firma come descritto sopra.
C.2. Name Error (Errore di nome)
La query nell'Appendice B.2 ha restituito RR NSEC che dimostrano che i dati richiesti non esistono e che nessun wildcard si applica. La risposta negativa viene autenticata verificando entrambi i RR NSEC. I RR NSEC vengono autenticati in modo identico a quello del RRset MX discusso sopra.
C.3. No Data Error (Errore nessun dato)
La query nell'Appendice B.3 ha restituito un RR NSEC che dimostra che il nome richiesto esiste, ma il tipo di RR richiesto non esiste. La risposta negativa viene autenticata verificando il RR NSEC. Il RR NSEC viene autenticato in modo identico a quello del RRset MX discusso sopra.
C.4. Referral to Signed Zone (Riferimento a zona firmata)
La query nell'Appendice B.4 ha restituito un riferimento alla zona firmata "a.example.". Il RR DS viene autenticato in modo identico a quello del RRset MX discusso sopra. Questo RR DS viene utilizzato per autenticare il RRset DNSKEY "a.example".
Una volta che il RRset DS "a.example" è stato autenticato utilizzando la DNSKEY "example", il resolver controlla il RRset DNSKEY "a.example" per un RR DNSKEY "a.example" che corrisponda al RR DS. Se viene trovata una tale DNSKEY "a.example" corrispondente, il resolver verifica se questo RR DNSKEY ha firmato il RRset DNSKEY "a.example" e se la durata della firma è valida. Se queste condizioni sono soddisfatte, tutte le chiavi nel RRset DNSKEY "a.example" sono considerate autenticate.
C.5. Referral to Unsigned Zone (Riferimento a zona non firmata)
La query nell'Appendice B.5 ha restituito un riferimento alla zona non firmata "b.example.". Il RR NSEC dimostra che nessun RR DS è associato alla delega "b.example.". Il RR NSEC viene autenticato in modo identico a quello del RRset MX discusso sopra.
Il resolver determina che "b.example." è una zona non firmata e che le risposte da "b.example." saranno non sicure.
C.6. Wildcard Expansion (Espansione wildcard)
La query nell'Appendice B.6 ha comportato un'espansione wildcard. L'esame del campo delle etichette RRSIG mostra che la risposta era il risultato di un'espansione wildcard. Il nome wildcard "*.w.example." viene posto in forma canonica e autenticato come nell'Appendice C.1. Il resolver deve anche verificare il RR NSEC per dimostrare che non esiste alcuna corrispondenza più vicina nella zona che sarebbe stata utilizzata al posto della corrispondenza wildcard.
C.7. Wildcard No Data Error (Errore nessun dato wildcard)
La query nell'Appendice B.7 è stata risolta utilizzando un wildcard, ma la risposta è una risposta "nessun dato". Il valore del campo delle etichette RRSIG di 2 nel RRSIG indica che il RR NSEC è stato derivato da un wildcard e fornisce il nome del wildcard. Il RR NSEC wildcard "*.w.example." viene autenticato come nell'Appendice C.1. Il resolver deve anche verificare il RR NSEC per dimostrare che non esiste alcuna corrispondenza più vicina nella zona che sarebbe stata utilizzata al posto della corrispondenza wildcard.
C.8. DS Child Zone No Data Error (Errore nessun dato zona figlia DS)
La query nell'Appendice B.8 è stata inviata alla zona figlia e ha restituito un RR NSEC che mostra che non esiste alcun RR DS nella zona figlia. Si noti che il RR NSEC indica che c'è un RR SOA all'apice della zona figlia, il che consente al resolver di determinare che questa risposta proviene dalla zona figlia anziché dalla zona padre. Il RR NSEC viene autenticato in modo identico a quello del RRset MX discusso sopra.