5. Portée de l'ensemble de documents DNSSEC et problèmes du dernier saut
La spécification dans cet ensemble de documents définit le comportement des signataires de zones et des serveurs de noms et résolveurs conscients de la sécurité de manière à ce que les entités validantes puissent déterminer sans ambiguïté l'état des données.
Un résolveur validant peut déterminer les 4 états suivants:
Secure (Sécurisé): Le résolveur validant a une ancre de confiance, a une chaîne de confiance et est capable de vérifier toutes les signatures dans la réponse.
Insecure (Non sécurisé): Le résolveur validant a 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 subséquentes dans l'arbre sont prouvablement non sécurisées. Un résolveur validant peut avoir une politique locale pour marquer des parties de l'espace de domaine comme non sécurisées.
Bogus (Frauduleux): Le résolveur validant a une ancre de confiance et une délégation sécurisée indiquant que les données subsidiaires sont signées, mais la réponse échoue à valider pour une raison quelconque: signatures manquantes, signatures expirées, signatures avec des algorithmes non supportés, données manquantes que le RR NSEC pertinent dit devraient ê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 d'opération par défaut.
Cette spécification définit seulement comment les serveurs de noms conscients de la sécurité peuvent signaler aux résolveurs stub non validants que les données ont été trouvées frauduleuses (en utilisant RCODE=2, "Server Failure", échec du serveur, voir [RFC4035]).
Il existe un mécanisme pour que les serveurs de noms conscients de la sécurité signalent aux résolveurs stub conscients de la sécurité que les 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 pourquoi les réponses ont été trouvées frauduleuses ou marquées comme non sécurisées. Le mécanisme de signalisation actuel ne distingue pas entre les états indéterminé et non sécurisé.
Une méthode pour signaler des codes d'erreur avancés et une politique entre un résolveur stub conscient de la sécurité et des serveurs de noms récursifs conscients de la sécurité est un sujet pour des travaux futurs, tout comme l'interface entre un résolveur conscient de la sécurité et les applications qui l'utilisent. Notez cependant que l'absence de spécification d'une telle communication n'interdit pas le déploiement de zones signées ou le déploiement de serveurs de noms récursifs conscients de la sécurité qui interdisent la propagation de données frauduleuses aux applications.