Résumé

  • Un résolveur récursif validant place le bit DNSSEC AD lorsqu'il juge authentiques les RRsets pertinents des sections Answer et Authority ; le bit rapporte sa conclusion, il ne se prouve pas lui-même.
  • Un stub non validant ne peut s'appuyer sur cette conclusion que s'il fait confiance au résolveur et authentifie ou protège le canal qui l'y relie. Un stub validant doit vérifier lui-même.
  • Validation DNSSEC, transport du verdict et décision de l'application sont trois frontières distinctes ; l'absence de AD ne suffit pas à diagnostiquer des données Bogus.

Un bit lumineux après un travail invisible

Un poste demande un nom à son résolveur récursif. Celui-ci peut avoir suivi plusieurs délégations, récupéré des enregistrements DNSKEY et DS, remonté une chaîne vers une ancre de confiance, vérifié des signatures et traité une preuve authentifiée de non-existence. La réponse finale ne raconte pas tout ce parcours. Elle peut seulement porter, dans son en-tête, le bit Authenticated Data : AD.

Cette condensation est utile. Un client léger n'a pas toujours intérêt à recommencer une validation déjà effectuée par un service compétent. Mais elle fait aussi disparaître le contexte. Afficher AD=1 sous le mot « sécurisé » invite à croire que l'ensemble du trajet, de la destination et de l'opération a été certifié. Les textes normalisés disent moins, et le disent avec précision.

La RFC 4035 demande à un serveur récursif conscient de DNSSEC de positionner AD seulement lorsqu'il considère authentiques tous les RRsets des sections Answer et Authority. Le sujet de cette phrase est le résolveur. Il a appliqué ses ancres, sa politique et sa vision de la réponse. Le drapeau est le résultat de cette évaluation ; ce n'est ni une signature de l'en-tête DNS ni un dossier de preuves permettant à n'importe quel destinataire de refaire le raisonnement.

Scott Rose figure avec Roy Arends, Rob Austein, Matt Larson et Dan Massey parmi les cinq auteurs des RFC 4033, 4034 et 4035. Leur architecture ne transforme pas un petit champ en preuve universelle. Elle distingue l'endroit où la validation a lieu, la manière dont son résultat peut être communiqué et la confiance encore nécessaire au saut suivant.

Quatre états ne tiennent pas dans un seul drapeau

La RFC 4033 présente quatre grands états pour une résolution tenant compte de la sécurité : Secure, Insecure, Bogus et Indeterminate. Secure correspond à des données reliées par une chaîne valable à une ancre acceptée. Insecure décrit un statut non signé qui peut être établi. Bogus désigne des données qui devraient être validables mais échouent aux contrôles. Indeterminate couvre le cas où l'information ou la politique disponible ne permet pas de trancher.

Le bit AD ne code pas ces quatre états. Lorsqu'il est présent, il transmet le résultat positif prévu par les règles du résolveur. Lorsqu'il manque, plusieurs explications restent possibles : données correctement Insecure, résolveur non validant, requête ne demandant pas le retour du signal, état différent ou effet d'une politique locale. Assimiler systématiquement AD=0 à « DNSSEC en échec » détruit les distinctions que le protocole avait justement créées.

La RFC 6840 précise aussi le rôle de la requête. Un demandeur peut y placer AD pour indiquer qu'il comprend ce drapeau et souhaite le recevoir, sans nécessairement demander les enregistrements DNSSEC au moyen de DO. Le résolveur validant ne devrait renvoyer AD que si les conditions de validation sont remplies et si la requête portait DO ou AD. Deux clients peuvent donc recevoir la même donnée validée, l'un avec le drapeau et l'autre sans, selon la capacité qu'ils ont annoncée.

Un bit positif ne garantit pas non plus que tous les résolveurs concluraient de la même façon. Les ancres de confiance et les politiques locales peuvent varier ; le cache, l'heure et la réponse observée aussi. DNSSEC fournit la mécanique de vérification. AD rend compte de l'application de cette mécanique par un résolveur déterminé à une réponse déterminée.

Le drapeau ne protège pas le paquet qui le transporte

Imaginons qu'un adversaire puisse modifier le trafic entre le stub et le résolveur. Il n'a pas besoin de fabriquer une signature DNSSEC pour tromper un client qui croit aveuglément AD. Il peut altérer un bit d'en-tête non signé, substituer une réponse ou perturber le canal. Le client ferait alors confiance à une affirmation dont il n'a jamais authentifié le transport.

La RFC 3655 formulait déjà cette limite : un stub ignorant la sécurité ne doit pas se fier aveuglément au bit AD, sauf s'il communique avec un résolveur récursif de confiance par un transport sûr ou par un mécanisme d'authentification des messages. La RFC 4033 conserve cette structure. Déléguer la validation suppose de faire confiance à la fois au serveur récursif et au canal. Pour cette propriété, l'intégrité et l'authentification sont déterminantes ; le chiffrement confidentiel n'est pas, à lui seul, ce qui rend le verdict fiable.

Ces deux exigences ne se remplacent pas. Un canal authentifié vers un résolveur indigne de confiance identifie seulement l'auteur d'une réponse douteuse. Un excellent résolveur atteint par un canal modifiable ne peut garantir ce qui arrive au client. La validation déléguée repose sur l'ensemble.

Le stub qui sait valider suit une autre voie. La RFC 4035 lui demande d'ignorer le bit reçu et de procéder à sa propre validation. Les données DNSSEC de la réponse peuvent alimenter son calcul, mais le verdict naît de la chaîne qu'il contrôle avec ses propres ancres. Le bit devient une observation, pas l'autorité de décision.

Faire confiance à un résolveur est une relation d'exploitation

L'expression « résolveur de confiance » ne devrait pas servir d'étiquette marketing. Elle désigne une relation concrète : le client sait quel service il vise, authentifie convenablement l'échange et accepte la politique de validation appliquée. Une simple adresse configurée ne prouve pas que tous les intermédiaires préservent la conclusion.

Centraliser la validation change donc la gouvernance autant que le calcul. L'exploitant du résolveur choisit les ancres, les versions logicielles, les exceptions, les réactions à l'échec et la durée de cache. Le client hérite de ces choix lorsqu'il ne consomme que le résumé. Cette architecture peut être excellente ; le bit AD n'efface pas la dépendance, il la compacte.

Le parcours de Rose éclaire l'actualité du problème. Son profil au NIST mentionne la protection des infrastructures Internet et les protocoles sûrs. En mars 2026, le NIST a publié une nouvelle révision de son guide de déploiement DNS sécurisé, signée par Scott Rose, Cricket Liu et Ross Gibson. Le sujet y apparaît comme un système exploité au quotidien : signer une zone ne suffit pas si la configuration des résolveurs, la transmission des résultats et la surveillance ne préservent pas la preuve.

L'attribution doit rester exacte. Rose est l'un des cinq auteurs de la suite centrale, pas l'inventeur unique de DNSSEC et pas le contrôleur de ses implémentations. Les RFC 3655 et 6840 ont d'autres groupes d'auteurs. Sa pertinence tient à cette architecture durable : toute authentification a un périmètre, et le consommateur doit savoir de qui vient la conclusion.

Un verdict DNS n'est pas un verdict applicatif

Même correctement produit et livré sur un canal authentifié, AD s'arrête à la frontière des données DNS. Il soutient l'idée que certains RRsets ont été authentifiés sous la chaîne DNSSEC du résolveur. Il n'affirme pas qu'un serveur web est intact, qu'une adresse IP est sans danger, qu'un certificat convient, qu'un destinataire est autorisé ou qu'une transaction doit être exécutée.

Les applications ajoutent d'autres contrôles : TLS et vérification du nom, politiques de certificat, autorisation de compte, fraîcheur, règles métier et intention de l'utilisateur. Certains protocoles utilisent délibérément des enregistrements authentifiés par DNSSEC dans une décision plus large. C'est une composition utile, non une fusion des preuves. Il faut pouvoir nommer le RRset, le verdict du résolveur, la protection du canal et le contrôle applicatif qui ont justifié l'action.

Un journal ne conservant que AD=true gomme ces dépendances. Un meilleur historique sépare l'état de validation et la politique du résolveur, la livraison authentifiée de cet état, puis l'usage ou le rejet par l'application. En cas d'erreur, l'enquête peut distinguer une mauvaise validation, un verdict altéré en transit et une application ayant accordé au DNS une autorité qu'il n'avait pas.

Le bit Authenticated Data n'est donc ni décoratif ni magique. C'est l'énoncé compact d'un validateur particulier sur des données particulières. Bien utilisé, il transmet le fruit de ce travail sans transformer une confiance déléguée en preuve de bout en bout.

Sources