Résumé

  • La RFC 3655 a remplacé une indication générale de politique serveur par un signal plus précis : les RRsets pertinents de la réponse ont été authentifiés selon les règles révisées.
  • Le bit AD est un compte rendu du résolveur, ni une signature du paquet DNS ni une preuve de confiance dans le résolveur, son réseau ou le choix de l’utilisateur.

Analyse

La scène commence avec une application ordinaire qui demande un nom à son résolveur local. Celui-ci transmet la requête à un résolveur récursif capable de suivre la chaîne de clés, de récupérer les signatures et de réutiliser le cache. Au retour, un bit de l’en-tête peut transmettre à l’application une information sur ce travail effectué en amont. La difficulté n’est pas la taille du champ : c’est de savoir qui peut formuler cette affirmation et quelles preuves elle résume.

La RFC 2535 donnait au bit Authenticated Data (AD) un sens assez large : le serveur indiquait que les données des sections Answer et Authority étaient authentifiées selon sa propre politique. La RFC 3655, publiée en novembre 2003, estimait que ce signal n’était pas utile en pratique. Un serveur conforme ne devrait déjà pas renvoyer des données qui échouent à sa politique de sécurité ; le bit décrivait donc surtout une posture générale, sans permettre à l’application de comprendre l’état de cette réponse précise.

La révision a rendu le relais plus ciblé. Un serveur récursif ne devait pas définir AD si les RRsets pertinents des sections Answer et Authority ne satisfaisaient pas aux conditions d’authentification. Il devait le faire lorsque les enregistrements de réponse — ainsi que ceux qui étayent une réponse négative — étaient authentifiés. Cela ne signifie pas que chaque paquet DNS porte sa propre signature. DNSSEC authentifie des ensembles d’enregistrements ; AD résume l’évaluation locale du résolveur pour cette réponse.

La distinction explique pourquoi DO et CD ne sont pas des variantes de AD. DO demande l’inclusion des enregistrements DNSSEC ; la RFC 3655 exigeait que ces enregistrements aient été demandés et que les SIG pertinents soient renvoyés avant de pouvoir définir AD. CD désactive la vérification pour la requête. Il n’effaçait pas automatiquement AD : le serveur pouvait encore marquer des données déjà vérifiées ou conformes à sa politique locale. Ces bits correspondent à des étapes différentes : demander les preuves, régler les contrôles et rapporter un résultat.

La RFC 3655 a donc fait du résolveur récursif un intermédiaire de confiance. Les applications n’avaient pas toutes à embarquer un validateur complet, et le travail pouvait être mis en cache. Mais le stub ne pouvait pas considérer AD comme une preuve qui s’authentifie elle-même. Il fallait faire explicitement confiance au résolveur et protéger la communication — par un canal sécurisé ou une authentification de message telle que TSIG ou SIG(0). Sinon, un bit ajouté par un répondant sur le chemin restait une affirmation de validation, et non une preuve livrée de façon sûre.

La règle visant les serveurs faisant autorité a révélé une autre frontière. Un serveur primaire pour une zone sécurisée pouvait être configuré pour définir AD, mais ce choix devait être explicite et désactivé par défaut. Le texte reconnaissait qu’un serveur faisant autorité n’était pas tenu de valider les données de sa propre zone ; vérifier les signatures au chargement ou à chaque requête pouvait avoir un coût opérationnel. Une réponse directe avec AD ne garantissait donc pas, par défaut, une validation comparable à celle d’un résolveur récursif.

Un bit AD effacé se prête lui aussi aux erreurs. Une réponse insecure ne devait pas porter AD, mais l’absence du bit ne révélait pas à elle seule si les données étaient insecure, si le résolveur ne les avait pas vérifiées, si les enregistrements DNSSEC demandés manquaient ou si le serveur avait choisi de ne pas affirmer leur statut. Le bit positif avait un sens dans une relation de confiance ; le bit négatif n’était pas un diagnostic complet.

En 2005, les RFC 4033, 4034 et 4035 ont révisé le cadre DNSSEC et rendu obsolète la RFC 3655. Le relais AD a subsisté, mais dans une description plus complète des validateurs, des stubs, des serveurs faisant autorité et des chemins d’authentification. La RFC 3655 se lit surtout comme la réparation d’une interface étroite : transmettre l’évaluation d’un résolveur sans prétendre que le bit de l’en-tête est une preuve cryptographique.

La chaîne de preuves reste en couches. Une RRSIG peut contribuer à authentifier un RRset au moyen d’une chaîne de clés et d’une ancre de confiance. Un résolveur validant prend une décision locale. AD peut rapporter cette décision. Enfin, un canal sécurisé vers un résolveur explicitement approuvé peut rattacher le message au service choisi. Aucun de ces faits ne prouve, isolément, l’honnêteté du titulaire d’un nom, l’actualité de l’information pour une application ou la sûreté de l’action qui en découle.

Sources