4. Resolving (Résolution)
Cette section décrit le comportement des entités qui incluent des fonctions de résolveur sensible à la sécurité. Dans de nombreux cas, ces fonctions feront partie d'un serveur de noms récursif sensible à la sécurité.
4.1. EDNS Support (Support EDNS)
Les implémentations de résolveurs sensibles à la sécurité doivent (MUST) prendre en charge l'extension de taille de message EDNS0, doivent (MUST) prendre en charge une taille de message d'au moins 1220 octets et devraient (SHOULD) prendre en charge une taille de message de 4000 octets.
4.2. Signature Verification Support (Support de vérification de signature)
Un résolveur sensible à la sécurité doit (MUST) prendre en charge les mécanismes de vérification de signature décrits dans la Section 5, et doit (MUST) les appliquer à chaque réponse reçue, sauf lorsque :
- Le résolveur sensible à la sécurité fait partie d'un serveur de noms récursif sensible à la sécurité, et la réponse est le résultat d'une récursion au nom d'une requête reçue avec le bit CD défini
- La réponse est le résultat d'une requête générée directement via une forme d'interface d'application qui a demandé au résolveur sensible à la sécurité de ne pas effectuer de validation pour cette requête
- La validation pour cette requête a été désactivée par une politique locale
Le support de vérification de signature d'un résolveur sensible à la sécurité doit (MUST) inclure le support de la vérification des noms de propriétaire joker (Wildcard Owner Names).
Les résolveurs sensibles à la sécurité peuvent (MAY) interroger pour les RR de sécurité manquants dans une tentative d'effectuer la validation. Lors de la tentative de récupération de RR NSEC manquants qui résident du côté parental à une coupure de zone, un résolveur en mode itératif sensible à la sécurité doit (MUST) interroger les serveurs de noms de la zone parente, et non de la zone enfant.
Lors de la tentative de récupération d'un DS manquant, un résolveur en mode itératif sensible à la sécurité doit (MUST) interroger les serveurs de noms de la zone parente, et non de la zone enfant.
4.3. Determining Security Status of Data (Détermination du statut de sécurité des données)
Un résolveur sensible à la sécurité doit (MUST) être capable de déterminer s'il doit s'attendre à ce qu'un RRset particulier soit signé. Un résolveur sensible à la sécurité doit être capable de distinguer quatre cas :
Secure (Sécurisé) : Un RRset pour lequel le résolveur est capable de construire une chaîne de RR DNSKEY et DS signés depuis une ancre de sécurité de confiance jusqu'au RRset. Dans ce cas, le RRset devrait être signé et est soumis à la validation de signature.
Insecure (Non sécurisé) : Un RRset pour lequel le résolveur sait qu'il n'a pas de chaîne de RR DNSKEY et DS signés depuis un point de départ de confiance jusqu'au RRset. Cela peut se produire lorsque le RRset cible se trouve dans une zone non signée ou dans un descendant d'une zone non signée. Dans ce cas, le RRset peut être signé ou non, mais le résolveur ne pourra pas vérifier la signature.
Bogus (Falsifié) : Un RRset pour lequel le résolveur croit qu'il devrait être capable d'établir une chaîne de confiance mais pour lequel il est incapable de le faire, soit en raison de signatures qui pour une raison quelconque ne parviennent pas à valider, soit en raison de données manquantes que les RR DNSSEC pertinents indiquent devraient être présentes. Ce cas peut indiquer une attaque mais peut également indiquer une erreur de configuration ou une forme de corruption de données.
Indeterminate (Indéterminé) : Un RRset pour lequel le résolveur n'est pas capable de déterminer si le RRset devrait être signé, car le résolveur n'est pas capable d'obtenir les RR DNSSEC nécessaires. Cela peut se produire lorsque le résolveur sensible à la sécurité n'est pas capable de contacter les serveurs de noms sensibles à la sécurité pour les zones pertinentes.
4.4. Configured Trust Anchors (Ancres de confiance configurées)
Un résolveur sensible à la sécurité doit (MUST) être capable d'être configuré avec au moins une clé publique de confiance ou un RR DS et devrait (SHOULD) être capable d'être configuré avec plusieurs clés publiques de confiance ou RR DS.
Étant donné qu'un résolveur sensible à la sécurité ne sera pas capable de valider les signatures sans une telle ancre de confiance configurée, le résolveur devrait (SHOULD) avoir un mécanisme raisonnablement robuste pour obtenir ces clés lors de son démarrage.
4.5. Response Caching (Mise en cache des réponses)
Un résolveur sensible à la sécurité devrait (SHOULD) mettre en cache chaque réponse comme une entrée atomique unique contenant la réponse entière, y compris le RRset nommé et tous les RR RRSIG et NSEC associés, quel que soit le statut de sécurité de la réponse.
Un résolveur sensible à la sécurité ne doit pas (MUST NOT) mettre en cache les RR RRSIG indépendamment des RRsets qu'ils signent, car cela pourrait permettre à un attaquant de rejouer d'anciens RRSIG avec de nouvelles données.
4.6. Handling of the CD and AD Bits (Traitement des bits CD et AD)
Le bit CD contrôle si un résolveur sensible à la sécurité effectue la validation pour une requête particulière. Un résolveur sensible à la sécurité doit (MUST) définir le bit AD dans une réponse si et seulement si le résolveur considère tous les RRsets dans les sections Answer et Authority de la réponse comme authentiques.
Un résolveur qui n'est pas sensible à la sécurité ne doit pas (MUST NOT) définir le bit AD dans une réponse. Un résolveur sensible à la sécurité ne doit pas (MUST NOT) définir le bit AD à moins qu'il n'ait validé les données selon les règles décrites dans cette spécification.
4.7. Caching BAD Data (Mise en cache de données incorrectes)
Un résolveur peut (MAY) mettre en cache les données avec un statut de sécurité « incorrect » différemment des données avec un statut de sécurité « correct ». Cependant, un résolveur ne doit pas (MUST NOT) utiliser les données mises en cache avec un statut de sécurité incorrect à moins que :
- Le résolveur réponde à une requête avec le bit CD défini
- Les données incorrectes étaient le résultat d'une requête avec le bit CD défini
- La politique locale autorise explicitement l'utilisation de données incorrectes
4.8. Synthesized CNAMEs (CNAME synthétisés)
Un résolveur sensible à la sécurité doit (MUST) appliquer des règles de traitement spéciales lors de la gestion des RR CNAME synthétisés comme décrit dans [RFC2672]. Le résolveur ne doit pas (MUST NOT) s'attendre à ce qu'un CNAME synthétisé soit signé, mais doit (MUST) valider le RR DNAME à partir duquel le CNAME a été synthétisé.
4.9. Stub Resolvers (Résolveurs stub)
Un résolveur stub sensible à la sécurité est une entité qui agit comme un résolveur DNS et qui a la capacité d'effectuer la validation de signature mais n'agit pas comme un serveur de noms récursif sensible à la sécurité complet. Les résolveurs stub s'appuient généralement sur un serveur de noms récursif pour effectuer la plupart des opérations DNS en leur nom.
4.9.1. Handling of the DO Bit (Traitement du bit DO)
Un résolveur stub sensible à la sécurité devrait (SHOULD) définir le bit DO dans les requêtes pour indiquer qu'il souhaite recevoir des RR DNSSEC dans la réponse.
4.9.2. Handling of the CD Bit (Traitement du bit CD)
Un résolveur stub sensible à la sécurité peut (MAY) définir le bit CD dans les requêtes pour indiquer qu'il est prêt à effectuer la validation lui-même plutôt que de s'appuyer sur le serveur de noms auquel il envoie la requête pour effectuer la validation en son nom.
4.9.3. Handling of the AD Bit (Traitement du bit AD)
Un résolveur stub sensible à la sécurité peut (MAY) utiliser le paramétrage du bit AD dans une réponse pour indiquer si le serveur de noms qui a envoyé la réponse a validé les données au nom du résolveur stub.
Un résolveur stub sensible à la sécurité qui définit le bit CD dans une requête doit (MUST) ignorer le bit AD dans la réponse, car le serveur de noms a été explicitement demandé de ne pas effectuer de validation au nom du résolveur stub.