7. Stub Resolver Considerations (Considérations sur les résolveurs stub)

Bien que le protocole ne l'exige pas strictement, la plupart des requêtes DNS proviennent de résolveurs stub. Par définition, les résolveurs stub sont des résolveurs DNS minimaux qui utilisent le mode de requête récursive pour décharger la majeure partie du travail de résolution DNS vers un serveur de noms récursif. Étant donné l'utilisation répandue des résolveurs stub, l'architecture DNSSEC doit prendre en compte les résolveurs stub, mais les fonctionnalités de sécurité nécessaires dans un résolveur stub diffèrent à certains égards de celles nécessaires dans un résolveur itératif conscient de la sécurité.

Même un résolveur stub non conscient de la sécurité peut bénéficier de DNSSEC si les serveurs de noms récursifs qu'il utilise sont conscients de la sécurité, mais pour que le résolveur stub puisse réellement s'appuyer sur les services DNSSEC, le résolveur stub doit faire confiance à la fois aux serveurs de noms récursifs en question et aux canaux de communication entre lui-même et ces serveurs de noms. La première de ces questions est une question de politique locale: en essence, un résolveur stub non conscient de la sécurité n'a d'autre choix que de se mettre à la merci des serveurs de noms récursifs qu'il utilise, car il n'effectue pas lui-même de vérifications de validité DNSSEC. La deuxième question nécessite un certain type de mécanisme de sécurité de canal, l'utilisation appropriée de mécanismes d'authentification de transaction DNS tels que SIG(0) ([RFC2931]) ou TSIG ([RFC2845]) suffirait, tout comme l'utilisation appropriée d'IPsec. Des implémentations particulières peuvent avoir d'autres choix disponibles, tels que des mécanismes de communication interprocessus spécifiques au système d'exploitation. La confidentialité n'est pas nécessaire pour ce canal, mais l'intégrité des données et l'authentification des messages le sont.

Un résolveur stub conscient de la sécurité qui fait confiance à la fois à ses serveurs de noms récursifs et à son canal de communication avec eux peut choisir d'examiner le paramètre du bit Authenticated Data (AD) dans l'en-tête de message des messages de réponse qu'il reçoit. Le résolveur stub peut utiliser ce bit de drapeau comme indice pour savoir si le serveur de noms récursif a pu valider les signatures pour toutes les données dans les sections Answer et Authority de la réponse.

Il y a une étape supplémentaire qu'un résolveur stub conscient de la sécurité peut prendre si, pour quelque raison que ce soit, il n'est pas capable d'établir une relation de confiance utile avec les serveurs de noms récursifs qu'il utilise: il peut effectuer sa propre validation de signature en définissant le bit Checking Disabled (CD) dans ses messages de requête. Un résolveur stub validant est ainsi capable de traiter les signatures DNSSEC comme des relations de confiance entre les administrateurs de zone et le résolveur stub lui-même.