5. Scope of the DNSSEC Document Set and Last Hop Issues (Périmètre de l'ensemble documentaire DNSSEC et problèmes du dernier saut)

La spécification de cet ensemble de documents définit le comportement des signataires de zone et des name servers et resolvers conscients de la sécurité de telle sorte que les entités de validation puissent déterminer sans ambiguïté l'état des données.

Un resolver validateur peut déterminer les 4 états suivants :

Secure (Sécurisé) : Le resolver validateur possède une ancre de confiance, possède une chaîne de confiance, et est capable de vérifier toutes les signatures de la réponse.

Insecure (Non sécurisé) : Le resolver validateur possède une ancre de confiance, une chaîne de confiance, et, à un point de délégation, une preuve signée de la non-existence d'un enregistrement DS. Cela indique que les branches ultérieures de l'arbre sont prouvables comme non sécurisées. Un resolver validateur peut avoir une politique locale pour marquer des parties de l'espace de noms de domaine comme non sécurisées.

Bogus (Falsifié) : Le resolver validateur possède une ancre de confiance et une délégation sécurisée indiquant que les données subordonnées sont signées, mais la réponse échoue à la validation pour une raison quelconque : signatures manquantes, signatures expirées, signatures avec des algorithmes non pris en charge, données manquantes que le RR NSEC concerné indique comme devant être présentes, etc.

Indeterminate (Indéterminé) : Il n'y a pas d'ancre de confiance qui indiquerait qu'une portion spécifique de l'arbre est sécurisée. C'est le mode de fonctionnement par défaut.

Cette spécification définit uniquement la manière dont les name servers conscients de la sécurité peuvent signaler aux stub resolvers non validateurs que des données ont été trouvées falsifiées (en utilisant RCODE=2, « Server Failure » ; voir [RFC4035]).

Il existe un mécanisme permettant aux name servers conscients de la sécurité de signaler aux stub resolvers conscients de la sécurité que des données ont été trouvées sécurisées (en utilisant le bit AD ; voir [RFC4035]).

Cette spécification ne définit pas de format pour communiquer la raison pour laquelle des réponses ont été trouvées falsifiées ou marquées comme non sécurisées. Le mécanisme de signalisation actuel ne distingue pas les états indéterminé et non sécurisé.

Une méthode de signalisation de codes d'erreur avancés et de politique entre un stub resolver conscient de la sécurité et des name servers récursifs conscients de la sécurité est un sujet de travaux futurs, tout comme l'interface entre un resolver conscient de la sécurité et les applications qui l'utilisent. Notez toutefois que l'absence de spécification d'une telle communication n'interdit pas le déploiement de zones signées ni le déploiement de name servers récursifs conscients de la sécurité qui interdisent la propagation de données falsifiées aux applications.