Résumé

  • Le projet DNS Delegation Extensions classe les nouveaux types selon qu’ils remplacent NS, le complètent ou ne doivent être obtenus qu’à la demande ; le segment numérique détermine le comportement de la réponse.
  • Lorsqu’un type « NS-Omitting » est présent, revenir silencieusement à NS est interdit, même si ce chemin semble disponible ; la résistance cryptographique au retrait des nouveaux types dépend séparément de DNSSEC, d’ADT et de la validation.

Un centre d’exploitation voit deux informations dans la même réponse : un nouveau type de délégation et un jeu d’enregistrements NS connu depuis longtemps. Le nouveau mécanisme pointe vers des serveurs qui ne répondent pas. Les serveurs NS, eux, restent accessibles. Le réflexe ordinaire est évident : essayer NS pour sauver la résolution.

Le texte étudié demande l’inverse. Si au moins un type de délégation appartenant à la catégorie « NS-Omitting » figure dans la réponse, le résolveur doit utiliser cette information et ignorer les enregistrements NS présents. Il ne doit ni les valider ni les mettre en cache. Si les données nouvelles sont connues mais inutilisables, il traite la liste comme composée de serveurs injoignables ; il ne réactive pas l’ancien chemin.

Cette asymétrie révèle la véritable décision. Un repli qui améliorerait la disponibilité pourrait défaire la propriété de sécurité pour laquelle le nouveau type a remplacé NS, notamment empêcher un retour discret au DNS classique non chiffré. L’échec visible devient préférable à une réussite dont les garanties ont changé sans autorisation.

La révision 11 de DNS Protocol Modifications for Delegation Extensions est datée du 17 septembre 2026 et expire le 21 mars 2027. Il s’agit d’un Internet-Draft actif du groupe DNSOP, destiné à la voie des normes. Ce n’est ni un RFC définitif, ni une preuve de mise en œuvre, ni une mesure d’adoption. Il faut donc lire ses obligations comme une architecture proposée, non comme la description de l’Internet déjà observé.

Quatre segments, quatre comportements

Le projet réserve la plage 0xF000 à 0xF1FF aux Delegation Types. Ces données sont autoritatives au point de délégation et destinées au traitement par le résolveur. NS et DS ne deviennent pas pour autant des Delegation Types au sens du texte.

La première tranche, 0xF0000xF07F, regroupe les types qui fournissent assez d’information pour se passer de NS. La deuxième, 0xF0800xF0FF, accueille ceux qui complètent NS. La troisième, 0xF1000xF1EF, contient les types « On-Demand », absents des réponses de délégation ordinaires et interrogés explicitement. Enfin, 0xF1F00xF1FF est réservée à l’usage privé, avec un comportement qui conserve NS.

Ce découpage donne une sémantique au numéro lui-même. Un serveur qui comprend le cadre général mais ignore un type particulier peut néanmoins savoir si NS doit disparaître, rester ou si la donnée ne doit pas être envoyée spontanément. L’allocation n’est donc pas une formalité de registre. Placer un type conçu pour remplacer NS dans le segment qui le conserve ferait exécuter aux logiciels génériques une politique contraire au dessein du type.

Lorsque le drapeau DE est à un, le serveur autoritatif inclut les types NS-Omitting, NS-Preserving et privés présents au nom délégué. Il n’ajoute pas les types On-Demand, sauf requête explicite. La présence d’un seul type NS-Omitting l’emporte sur tous les autres et fait disparaître NS, même pour une requête de type NS.

Cette priorité n’est pas une préférence de performance. Elle exprime le contrat de la délégation. Un outil d’exploitation qui « essaie tout ce qui répond » ne se contente pas d’être plus robuste ; il substitue sa propre règle à celle annoncée par le parent.

Négocier n’est pas authentifier

Le drapeau EDNS(0) DE, demandé sur le bit 2, sert à négocier la compréhension du mécanisme. Un résolveur averti le place dans sa requête. Un résolveur récursif averti qui reçoit ce signal d’un stub averti le renvoie dans sa réponse. Si DE vaut zéro à l’arrivée chez le serveur autoritatif, celui-ci adopte le comportement historique et traite les nouveaux types comme des données ordinaires.

Ce dispositif protège la compatibilité, mais le drapeau de requête peut être supprimé par un attaquant situé sur le chemin. Le serveur autoritatif répond alors légitimement avec NS seulement. De même, un attaquant peut retirer les nouveaux RRsets et les preuves associées d’une réponse, en laissant des NS non signés. La simple présence de DE à une autre frontière ne prouve pas que l’échange autoritatif a conservé le signal ni que la délégation reçue est complète.

Le projet confie donc la résistance à la rétrogradation à un engagement distinct : ADT, proposé sur le bit 14 de DNSKEY. Un validateur apprend l’état d’ADT dans le jeu DNSKEY authentifié de la zone délégante. Si au moins une clé porte ADT, toute délégation doit comporter une preuve NSEC ou NSEC3 de la présence ou de l’absence des Delegation Types au nom concerné.

Le validateur confronte les RRsets NS-Omitting, NS-Preserving et privés de la réponse aux Type Bit Maps authentifiées. Une donnée annoncée par la preuve mais absente de la réponse révèle une altération ; la réponse doit être ignorée. Les types On-Demand constituent l’exception attendue : leur présence dans la carte n’impose pas leur transport dans une délégation ordinaire.

La force d’ADT vient de son emplacement. L’obligation a été établie par une DNSKEY validée, en dehors de la requête courante. Retirer DE de cette requête ne retire pas l’engagement de la zone. Le validateur sait encore quelle preuve il doit exiger.

Une protection sous conditions

Cette formulation ne doit pas être abrégée en « ADT empêche la rétrogradation ». La zone délégante doit être signée. ADT doit être positionné. Le résolveur doit valider DNSSEC et appliquer la vérification prescrite. Sans l’une de ces conditions, le mécanisme n’offre pas de protection cryptographique contre le retrait de DE ou des Delegation Types.

Inversement, ADT à zéro ne rend pas automatiquement une réponse positive DELEG invalide. Le projet précise qu’elle ne devrait pas être déclarée DNSSEC-bogus pour cette seule raison. Elle suit les règles ordinaires. Il faut savoir consigner simultanément deux conclusions : la donnée n’est pas rejetée par cette règle, et l’engagement de détection de rétrogradation n’existe pas.

Dans une zone non signée, un adversaire peut également injecter un type NS-Omitting et forcer le résolveur à ignorer les NS légitimes. DNSSEC protège l’authenticité du nouveau RRset dans une zone signée ; aucune protection cryptographique correspondante n’existe dans une zone non signée. Le même code de priorité peut donc servir la sécurité lorsqu’il est authentifié et devenir une surface d’attaque lorsqu’il ne l’est pas.

L’échec fait partie du contrat

Supposons maintenant que le parent n’ait plus du tout de NS et ne publie que de nouveaux types. Un résolveur non averti envoie une requête sans DE. Le serveur autoritatif ne peut pas lui produire une délégation qu’il saurait exploiter et renvoie une réponse négative. Le projet recommande le code Extended DNS Error 34, « New Delegation Only ».

Ce code rend l’incident lisible. Il signale que le nom n’a pas simplement disparu et que le client se trouve devant une forme de délégation qu’il ne comprend pas. Il ne fournit cependant ni les données absentes ni l’algorithme requis. Une explication n’est pas un chemin de résolution.

Si un attaquant retire DE pour provoquer ce résultat négatif, le validateur engagé par ADT peut exiger la preuve NSEC ou NSEC3 adéquate. Dans le cas de Compact Denial of Existence, une réponse fondée sur NXNAME au nom interrogé masquerait les bits de type au point de délégation. Le projet exige alors une preuve conventionnelle de Name Error. Là encore, la preuve permet de refuser une réponse altérée ; elle ne rétablit pas à elle seule la disponibilité.

Cette différence est cruciale pour les tableaux de bord. « Attaque détectée » n’équivaut pas à « service rendu ». Le refus peut être le résultat correct, et pourtant laisser l’utilisateur sans réponse. Mesurer seulement l’intégrité masque l’impact ; mesurer seulement la disponibilité récompense un repli interdit.

La liste des candidats ne dit pas lequel a servi

Le projet étend la structure conceptuelle SLIST afin qu’elle accepte plusieurs formes d’information de délégation et fonctionne comme un ensemble. Les doublons exacts n’y apparaissent qu’une fois. Les chaînes peuvent toutefois créer des dépendances cycliques, des références répétées et une quantité de travail incontrôlée. Les implémentations doivent imposer des limites.

Surtout, le texte dit ce que ni RFC 1034 ni ce projet ne définissent : la manière dont le résolveur utilise SLIST. Ils expliquent comment la remplir. Une entrée dans l’ensemble ne prouve donc pas qu’un serveur a été choisi, contacté ou qu’une liaison chiffrée a abouti. Confondre population et usage revient à transformer une possibilité calculée en résultat opérationnel.

Un reçu complet sépare les étapes : valeur de DE à chaque frontière, réponse autoritative, état DNSSEC, DNSKEY et ADT validés, preuve NSEC/NSEC3, segment du type, décision de priorité, candidats placés dans SLIST, serveur finalement choisi, transport constaté et réponse obtenue. Chaque étape a sa propre affirmation négative.

Le maillon intermédiaire compte

Un stub averti et sensible à la sécurité doit utiliser un résolveur qui possède les mêmes propriétés. Un résolveur validant averti qui s’appuie sur des forwarders doit choisir des forwarders avertis et sensibles à la sécurité. Sinon, les zones sécurisées peuvent échouer à la validation et les zones non sécurisées produire des réponses divergentes.

Cette exigence rend la transition peu compatible avec un indicateur global « activé ». Deux extrémités capables ne garantissent pas qu’un intermédiaire préserve le signal, la preuve ou la sémantique. Une zone signée qui publie des Delegation Types est tenue, selon le projet, de positionner ADT ; une zone qui compte sur ces types pour un transport chiffré doit être signée. Ces obligations ne sont pas des observations de conformité.

Le résolveur qui a ignoré le serveur NS encore vivant n’a pas manqué de pragmatisme. Il a refusé de convertir une panne visible en une réussite obtenue sous une politique différente. Le défi de gouvernance consiste à rendre cette décision compréhensible avant l’incident, afin que le premier réflexe de dépannage ne soit pas d’annuler silencieusement la garantie recherchée.

Sources