8. DNSSEC Generale

La maggior parte dei termini DNSSEC sono definiti in [RFC4033], [RFC4034], [RFC4035] e [RFC5155]. I termini che hanno causato confusione nella comunità DNS sono evidenziati qui.

Consapevole e non consapevole di DNSSEC (DNSSEC-aware and DNSSEC-unaware): Questi due termini, che sono utilizzati in alcuni RFC, non sono stati formalmente definiti. Tuttavia, la Sezione 2 di [RFC4033] definisce molti tipi di resolver e validatori, inclusi "non-validating security-aware stub resolver" (resolver stub consapevole della sicurezza non validante), "non-validating stub resolver" (resolver stub non validante), "security-aware name server" (name server consapevole della sicurezza), "security-aware recursive name server" (name server ricorsivo consapevole della sicurezza), "security-aware resolver" (resolver consapevole della sicurezza), "security-aware stub resolver" (resolver stub consapevole della sicurezza) e "security-oblivious 'anything'" (qualsiasi cosa 'ignara della sicurezza'). (Si noti che il termine "validating resolver" (resolver validante), che è utilizzato in alcuni punti nei documenti relativi a DNSSEC, non è anch'esso definito.)

Zona firmata (Signed zone): "Una zona i cui RRset sono firmati e che contiene record DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC) e (opzionalmente) DS correttamente costruiti." (Citato da [RFC4033], Sezione 2.) È stato notato in altri contesti che la zona stessa non è realmente firmata, ma tutti gli RRset rilevanti nella zona sono firmati. Tuttavia, se una zona che dovrebbe essere firmata contiene RRset che non sono firmati (o esclusi), quegli RRset saranno trattati come bogus, quindi l'intera zona deve essere gestita in qualche modo.

Si dovrebbe anche notare che, dalla pubblicazione di [RFC6840], i record NSEC non sono più richiesti per le zone firmate: una zona firmata potrebbe includere invece record NSEC3. [RFC7129] fornisce ulteriore commento di sfondo e contesto per i meccanismi NSEC e NSEC3 utilizzati da DNSSEC per fornire risposte di denial-of-existence autenticate.

Zona non firmata (Unsigned zone): La Sezione 2 di [RFC4033] definisce questo come "una zona che non è firmata". La Sezione 2 di [RFC4035] definisce questo come "Una zona che non include questi record [record DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC) e (opzionalmente) DS correttamente costruiti] secondo le regole in questa sezione". C'è una nota importante alla fine della Sezione 5.2 di [RFC4035] che definisce una situazione aggiuntiva in cui una zona è considerata non firmata: "Se il resolver non supporta nessuno degli algoritmi elencati in un RRset DS autenticato, allora il resolver non sarà in grado di verificare il percorso di autenticazione alla zona figlio. In questo caso, il resolver DOVREBBE trattare la zona figlio come se non fosse firmata."

NSEC: "Il record NSEC consente a un resolver consapevole della sicurezza di autenticare una risposta negativa per la non esistenza di nome o tipo con gli stessi meccanismi utilizzati per autenticare altre risposte DNS." (Citato da [RFC4033], Sezione 3.2.) In breve, un record NSEC fornisce un denial of existence autenticato.

"Il record di risorse NSEC elenca due cose separate: il nome proprietario successivo (nell'ordinamento canonico della zona) che contiene dati autorevoli o un RRset NS di punto di delega, e l'insieme di tipi RR presenti al nome proprietario del RR NSEC." (Citato dalla Sezione 4 di RFC 4034)

NSEC3: Come il record NSEC, anche il record NSEC3 fornisce un denial of existence autenticato; tuttavia, i record NSEC3 mitigano contro l'enumerazione di zona e supportano l'Opt-Out. I record di risorse NSEC3 sono definiti in [RFC5155].

Si noti che [RFC6840] afferma che [RFC5155] "è ora considerato parte della famiglia di documenti sulla sicurezza DNS come descritto dalla Sezione 10 di [RFC4033]". Questo significa che alcune delle definizioni degli RFC precedenti che parlano solo di record NSEC dovrebbero probabilmente essere considerate come riferite sia a NSEC che a NSEC3.

Opt-out (Esclusione): "Il flag Opt-Out indica se questo RR NSEC3 può coprire deleghe non firmate." (Citato da [RFC5155], Sezione 3.1.2.1.) L'Opt-out affronta gli alti costi della protezione di una delega a una zona non sicura. Quando si utilizza l'Opt-Out, i nomi che sono una delega non sicura (e i non-terminali vuoti che sono derivati solo da deleghe non sicure) non richiedono un record NSEC3 o i suoi record RRSIG corrispondenti. I record NSEC3 Opt-Out non sono in grado di provare o negare l'esistenza delle deleghe non sicure. (Adattato da [RFC7129], Sezione 5.1)

Enumerazione di zona (Zone enumeration): "La pratica di scoprire il contenuto completo di una zona tramite query successive." (Citato da [RFC5155], Sezione 1.3.) Questo è anche talvolta chiamato "zone walking" (percorrimento della zona). L'enumerazione di zona è diversa dall'indovinare il contenuto della zona dove chi indovina utilizza un grande dizionario di possibili label e invia query successive per esse, o confronta il contenuto dei record NSEC3 con tale dizionario.

Key signing key (KSK - Chiave di firma delle chiavi): Chiavi DNSSEC che "firmano solo il RRset DNSKEY apex in una zona." (Citato da [RFC6781], Sezione 3.1)

Zone signing key (ZSK - Chiave di firma della zona): "Chiavi DNSSEC che possono essere utilizzate per firmare tutti gli RRset in una zona che richiedono firme, diversi dal RRset DNSKEY apex." (Citato da [RFC6781], Sezione 3.1) Si noti che i ruoli KSK e ZSK non sono mutualmente esclusivi: una singola chiave può essere sia KSK che ZSK allo stesso tempo. Si noti anche che una ZSK viene talvolta utilizzata per firmare il RRset DNSKEY apex.

Combined signing key (CSK - Chiave di firma combinata): "Nei casi in cui non viene fatta la differenziazione tra KSK e ZSK, cioè dove le chiavi hanno il ruolo sia di KSK che di ZSK, parliamo di uno schema di firma di tipo singolo." (Citato da [RFC6781], Sezione 3.1) Questo è talvolta chiamato "combined signing key" (chiave di firma combinata) o CSK. È la pratica operativa, non il protocollo, che determina se una particolare chiave è una ZSK, una KSK o una CSK.

Secure Entry Point (SEP - Punto di ingresso sicuro): Un flag nel RDATA DNSKEY che "può essere utilizzato per distinguere tra chiavi che sono destinate ad essere utilizzate come punto di ingresso sicuro nella zona quando si costruiscono catene di fiducia, cioè sono (o saranno) indicate da RR DS parentali o configurate come ancoraggio di fiducia. Pertanto, si suggerisce che il flag SEP sia impostato sulle chiavi che sono utilizzate come KSK e non sulle chiavi che sono utilizzate come ZSK, mentre in quei casi in cui non viene fatta una distinzione tra una KSK e ZSK (cioè per uno schema di firma di tipo singolo), si suggerisce che il flag SEP sia impostato su tutte le chiavi." (Citato da [RFC6781], Sezione 3.2.3.) Si noti che il flag SEP è solo un suggerimento, e la sua presenza o assenza non può essere utilizzata per squalificare un dato RR DNSKEY dall'uso come KSK o ZSK durante la validazione.

DNSSEC Policy (DP - Politica DNSSEC): Una dichiarazione che "stabilisce i requisiti e gli standard di sicurezza da implementare per una zona firmata DNSSEC." (Citato da [RFC6841], Sezione 2)

DNSSEC Practice Statement (DPS - Dichiarazione di pratica DNSSEC): "Un documento di divulgazione delle pratiche che può supportare ed essere un documento supplementare alla politica DNSSEC (se esiste), e dichiara come la gestione di una data zona implementa procedure e controlli ad alto livello." (Citato da [RFC6841], Sezione 2)