5. Scope of the DNSSEC Document Set and Last Hop Issues (Ambito del set di documenti DNSSEC e problemi dell'ultimo hop)
La specifica in questo set di documenti definisce il comportamento per i firmatari di zone e i name server e resolver consapevoli della sicurezza in modo tale che le entità validanti possano determinare in modo non ambiguo lo stato dei dati.
Un resolver validante può determinare i seguenti 4 stati:
Secure (Sicuro): Il resolver validante ha un'ancora di fiducia, ha una catena di fiducia ed è in grado di verificare tutte le firme nella risposta.
Insecure (Non sicuro): Il resolver validante ha un'ancora di fiducia, una catena di fiducia e, in qualche punto di delegazione, prova firmata della non esistenza di un record DS. Questo indica che i rami successivi nell'albero sono provabilmente non sicuri. Un resolver validante può avere una politica locale per contrassegnare parti dello spazio dei domini come non sicure.
Bogus (Fasullo): Il resolver validante ha un'ancora di fiducia e una delegazione sicura che indica che i dati sussidiari sono firmati, ma la risposta fallisce la validazione per qualche motivo: firme mancanti, firme scadute, firme con algoritmi non supportati, dati mancanti che il RR NSEC rilevante dice dovrebbero essere presenti, e così via.
Indeterminate (Indeterminato): Non c'è alcuna ancora di fiducia che indicherebbe che una porzione specifica dell'albero è sicura. Questa è la modalità operativa predefinita.
Questa specifica definisce solo come i name server consapevoli della sicurezza possono segnalare ai resolver stub non validanti che i dati sono stati trovati essere fasullli (usando RCODE=2, "Server Failure", fallimento del server, vedere [RFC4035]).
Esiste un meccanismo per i name server consapevoli della sicurezza per segnalare ai resolver stub consapevoli della sicurezza che i dati sono stati trovati essere sicuri (usando il bit AD, vedere [RFC4035]).
Questa specifica non definisce un formato per comunicare perché le risposte sono state trovate essere fasulle o contrassegnate come non sicure. L'attuale meccanismo di segnalazione non distingue tra stati indeterminati e non sicuri.
Un metodo per segnalare codici di errore avanzati e politiche tra un resolver stub consapevole della sicurezza e name server ricorsivi consapevoli della sicurezza è un argomento per lavori futuri, così come l'interfaccia tra un resolver consapevole della sicurezza e le applicazioni che lo utilizzano. Si noti, tuttavia, che la mancanza della specifica di tale comunicazione non proibisce il deployment di zone firmate o il deployment di name server ricorsivi consapevoli della sicurezza che proibiscono la propagazione di dati fasullli alle applicazioni.