Résumé

  • La révision 01 de dry-run DNSSEC propose un état intermédiaire : un résolveur compatible valide le domaine et signale les anomalies, mais rend au client ordinaire la réponse non sécurisée lorsque la validation à blanc échoue.
  • Le rapport NOERROR proposé confirme la présence d’un participant ayant réussi son contrôle. Il ne donne ni le nombre des résolveurs restés muets ni celui des clients qu’ils desservent ; les rapports de la RFC 9567 sont amortis et non authentifiés.
  • Avant que le parent remplace le DS à blanc par un vrai DS, une preuve de passage doit conserver la définition de la cohorte, les tests côté client, l’état du parent, les limites du transport et les inconnues restantes. C’est une recommandation de Daniel Kade, non une règle de l’IETF.

Le dernier geste d’un déploiement DNSSEC paraît minuscule : publier, dans la zone parente, un enregistrement DS qui relie le nom enfant à sa clé. Son effet ne l’est pas. Avant ce geste, une erreur de signature peut rester un défaut interne. Après lui, un résolveur validant peut convertir le défaut en échec de résolution pour des utilisateurs éloignés, derrière des caches et des réseaux que l’opérateur ne dirige pas.

Le projet actif du groupe DNSOP intitulé dry-run DNSSEC cherche à ouvrir un palier entre ces deux états. Sa révision 01 date du 21 juin 2026. Le document vise la filière Standards Track, mais demeure un Internet-Draft de groupe de travail : ce n’est ni un RFC, ni une norme approuvée, ni la preuve qu’un fournisseur l’a déployé. Plusieurs codes qu’il propose restent à déterminer.

Le mécanisme s’appuie sur la règle de la RFC 6840 concernant un algorithme de condensat DS inconnu. Un validateur ignore un DS authentifié dont il ne sait pas traiter l’algorithme. S’il ne reste aucun chemin d’authentification utilisable, il considère l’enfant comme non signé. Le projet associe à chaque algorithme ordinaire une valeur à bit fort positionné et demande que le parent ne publie, dans cet ensemble, que des DS à blanc.

Les résolveurs se séparent alors en deux populations. Celui qui ne connaît pas la proposition ignore le condensat inconnu et résout le domaine comme non sécurisé. Celui qui la connaît reconnaît le signal, tente la validation et peut rapporter son résultat. Si la preuve est valide, il peut marquer les données comme authentiques. Si elle est « bogus », il cache au client ordinaire l’échec DNSSEC et lui livre la réponse non sécurisée qu’il aurait reçue sans ce DS expérimental.

Cette tolérance n’est pas une protection DNSSEC réduite. Le projet dit explicitement que la délégation à blanc ne doit pas être tenue pour signée. Sa section de sécurité rappelle que le repli non sécurisé suspend la garantie d’intégrité et peut laisser une réponse falsifiée atteindre le domaine. L’expérience achète de l’observabilité avec une période d’exposition ; elle ne constitue donc pas un état stable à conserver par confort.

Observer une panne sans encore l’imposer

La RFC 8914 donne un vocabulaire aux erreurs DNS étendues. La RFC 9567 décrit ensuite leur remontée : le résolveur construit une requête vers le domaine d’un agent de surveillance annoncé par le serveur faisant autorité. Le nom demandé y encode notamment le nom fautif, le type de requête et le code d’erreur.

Pour un opérateur, ce signal est plus riche qu’un test de laboratoire. Il provient d’un chemin réel, avec son logiciel de validation, ses caches et ses requêtes. Il démontre qu’une certaine chaîne a rencontré une certaine anomalie à un moment donné.

Il ne démontre pas l’identité institutionnelle de cette chaîne. La RFC 9567 n’authentifie pas le résolveur auprès de l’agent. TCP ou les DNS Cookies rendent l’usurpation d’adresse plus difficile, sans transformer une adresse source en identité garantie. Un rapport UDP ou son origine apparente peut être faux. Le mécanisme peut aussi révéler des problèmes propres au résolveur, par exemple une ancre de confiance périmée ; la minimisation du nom demandé reste donc une précaution de confidentialité.

Le volume est volontairement façonné. La mise en cache amortit les répétitions. Un nom de rapport trop long peut empêcher l’émission. Le tableau de bord ne reçoit ainsi ni un événement par requête ni un inventaire des utilisateurs. Il voit un échantillon limité par le transport, l’état du cache, la joignabilité de l’agent et le comportement du logiciel.

Ces limites ne rendent pas le rapport insignifiant. Elles bornent la phrase qu’il autorise : « un chemin de signalement a observé cette erreur ». Elles interdisent d’en déduire directement le nombre de personnes touchées, le taux d’échec total ou l’existence d’une population indépendante de taille connue.

Le silence avait besoin d’un témoin positif

Une page sans erreur peut raconter plusieurs histoires. La zone est peut-être correctement signée. Peut-être aussi qu’aucun résolveur compatible ne l’a interrogée, que le rapport a été amorti, que l’agent était injoignable, que le nom construit dépassait la limite DNS ou que le résolveur ne mettait pas en œuvre le mécanisme.

La révision 01 propose donc un code NOERROR. Après une validation à blanc réussie, un résolveur compatible peut envoyer un rapport positif. Le nom est construit au sommet de la zone et les mêmes règles de cache limitent les répétitions. L’opérateur apprend au moins qu’un observateur participant était présent.

Cette innovation résout l’ambiguïté de présence à l’intérieur de la cohorte ; elle ne fournit toujours pas son dénominateur extérieur. Les résolveurs incompatibles sont silencieux par construction puisqu’ils traitent le domaine comme non signé. Un résolveur compatible qui n’a reçu aucune requête reste lui aussi absent. Enfin, un NOERROR n’énumère ni tous les clients situés derrière son émetteur, ni leurs futures routes, ni tous les états de cache.

Le projet rapproche cette logique des rapports DMARC, de la sentinelle d’ancre racine de la RFC 8509 et du signalement d’ancres de la RFC 8145. Ces précédents montrent qu’un petit groupe d’observateurs actuels et bien placé peut apporter une information opérationnelle importante. Ils ne transforment pas ce groupe en représentation statistique automatique de l’Internet.

Wet-Run déplace le consentement vers le client

Le repli protège la continuité de service du client ordinaire, mais il ne montre pas comment une application réagirait au vrai refus DNSSEC. Le projet ajoute donc une option EDNS dite Wet-Run. Un client qui l’envoie à un résolveur compatible accepte de recevoir l’échec réel de la validation à blanc. Le résolveur doit conserver le statut expérimental à côté du statut ordinaire de la réponse mise en cache et renvoyer l’option avec l’erreur. Un résolveur incompatible ignore simplement la demande.

Ce test répond à une question différente du rapport NOERROR. Le premier vérifie un parcours choisi entre une application, un réseau et un résolveur. Le second atteste qu’un résolveur participant a réussi une validation. Les fusionner dans un unique voyant vert détruirait l’identité de ce qui a été testé et de celui qui a accepté la panne.

Les réponses négatives ouvrent un troisième front. La RFC 8198 autorise un validateur à produire des réponses depuis des preuves NSEC ou NSEC3 déjà en cache. Cette optimisation peut masquer une preuve négative défectueuse, puisque le serveur faisant autorité n’est plus interrogé. Le projet demande au résolveur à blanc de suspendre cette synthèse, d’effectuer une requête explicite, de comparer les réponses et de signaler toute divergence au moyen d’un code EDE proposé.

Le parent tient l’interrupteur d’exécution

L’enfant ne peut pas installer seul cet état. Le parent doit accepter et publier le DS particulier. Lorsqu’il reçoit directement des DS, l’enfant fournit la valeur à blanc. Lorsqu’il fabrique un DS depuis DNSKEY, il lui faut une interface indiquant le mode ou une logique qui lise un CDS joint. CDNSKEY seul ne transporte pas le signal proposé ; le projet conseille donc de publier CDS et CDNSKEY ensemble.

Le passage à l’exécution dépend encore du parent : il remplace l’ensemble de DS à blanc par l’ensemble réel. Cette formulation cache plusieurs instants qu’un registre de décision doit séparer. Une demande soumise n’est pas encore acceptée ; une demande acceptée n’est pas nécessairement visible dans le DNS ; une première observation n’épuise pas les anciens caches.

La substitution change surtout le régime de conséquence. Pendant l’essai, un résolveur compatible signale l’état invalide et rend une réponse non sécurisée. Après publication du vrai DS, le même défaut peut devenir un échec de validation. Le seuil d’un tableau de bord est donc une décision de gouvernance : il contribue à choisir quand une population extérieure commencera à appliquer les déclarations cryptographiques de l’enfant.

Un signal proposé, pas encore attribué

La révision 01 propose d’utiliser le bit de poids fort de la valeur d’algorithme de condensat DS et demande à l’IANA d’identifier 128 à 255 comme domaine du DNSSEC à blanc. Le registre IANA en vigueur ne contient pas cette attribution. Dans sa version mise à jour le 13 janvier 2026, 128 à 252 sont réservés, 253 et 254 relèvent de l’usage privé, et 255 reste non attribué, en référence à la RFC 9904.

L’écart exige une conciliation explicite si le projet avance. Il ne prouve ni rejet de l’IANA ni impossibilité technique : les actions IANA proposées dans un Internet-Draft ne prennent normalement effet qu’au terme du processus approprié. Une expérience ne doit toutefois pas présenter le bloc demandé comme déjà public.

La RFC 9904 offre une analogie utile en séparant les recommandations d’usage des recommandations d’implémentation. La présence d’un code dans un logiciel n’est pas son emploi par un opérateur. De même, un résolveur peut prendre en charge le mode à blanc sans rencontrer cette zone ; un parent peut publier le signal sans garantir que les clients importants passent par des résolveurs compatibles.

Une preuve de passage à l’exécution

Une décision révisable commence par les artefacts exacts : empreinte de la zone signée, ensemble DNSKEY, DS à blanc proposé, demande au parent, acceptation et publication effectivement observée. La fenêtre d’observation et les points de mesure doivent être nommés.

Le document doit ensuite décrire la cohorte sans feindre un recensement. Quels résolveurs ont pu être distingués ? Quels rapports ne possèdent qu’une adresse source renforcée par TCP ou Cookie ? Quels NOERROR et quelles erreurs ont survécu à l’amortissement ? Quels noms, types de requêtes et codes ont été touchés, et quelles corrections ont été closes ? L’agrégation peut protéger les personnes sans effacer les faits nécessaires à l’autorisation.

Les tests clients forment une rubrique autonome : parcours Wet-Run par réseau, résolveur et classe d’application ; repli ordinaire ; réponses positives et négatives ; contrôles explicites de NSEC/NSEC3 ; horizons de cache ; voies impossibles à atteindre. L’état courant du registre IANA et les codes expérimentaux utilisés doivent être annexés sans les présenter comme attribués.

Enfin, la preuve nomme l’autorité autorisée à demander le vrai DS, les critères qu’elle accepte, les inconnues résiduelles et le propriétaire du retour arrière. Soumission, acceptation, publication observée et validation postérieure gardent des horodatages distincts.

Ce reçu ne certifie pas tous les résolveurs. Il empêche seulement qu’un échantillon choisi devienne silencieusement « Internet » dans le dossier de décision. Une preuve bornée peut justifier l’action ; elle doit simplement laisser aux responsables des conséquences la possibilité d’examiner sa frontière.

Sources

  1. dry-run DNSSEC — révision 01
  2. Fiche Datatracker de dry-run DNSSEC
  3. Historique du document
  4. Documents actifs de DNSOP
  5. Charte de DNSOP
  6. RFC 9567 — DNS Error Reporting
  7. RFC 8914 — Extended DNS Errors
  8. RFC 6840 — notes de mise en œuvre DNSSEC
  9. RFC 8198 — usage agressif du cache validé
  10. RFC 8509 — sentinelle d’ancre racine
  11. RFC 8145 — signalement des ancres connues
  12. RFC 9904 — mise à jour des recommandations algorithmiques
  13. Registre IANA des algorithmes de condensat DS