Résumé

  • RFC 9824 peut répondre à une requête visant un nom inexistant avec NOERROR dans l’en-tête, une section Answer vide et une preuve NSEC ou NSEC3 signée contenant NXNAME. L’affirmation authentifiée se trouve dans le corps ; le RCODE n’est pas protégé cryptographiquement.
  • Le drapeau EDNS Compact Answers OK permet, de façon optionnelle, de restituer NXDOMAIN. Cette capacité est de proche en proche : elle doit accompagner la preuve mise en cache et ne transforme pas la présentation locale en vérité universelle.
  • Les réponses compactes réduisent la taille de la preuve et le travail de signature en ligne par rapport à d’autres formes dynamiques, mais empêchent la synthèse négative agressive. Preuve, présentation, coût, cache et effet applicatif exigent des reçus distincts.

Un bit oublié peut retirer un droit sans altérer la vérité

La scène d’ouverture est construite. Elle montre pourtant le défaut le plus probable d’une migration : conserver les RRsets et perdre le contexte qui autorisait leur présentation. Le résolveur ne devient pas ignorant du nom ; il devient incapable de justifier la forme de réponse promise au prochain pair.

RFC 9824, Compact Denial of Existence in DNSSEC, propose une manière différente de prouver l’inexistence d’un nom. Dans les modèles habituels, une réponse négative DNSSEC doit établir que le nom exact n’existe pas et qu’aucun wildcard ne pouvait produire de réponse. Pour un signataire en ligne, cette démonstration peut nécessiter jusqu’à deux NSEC signés ou trois NSEC3 signés.

La réponse compacte change la forme logique. Pour un nom inexistant qui ne correspond pas à un wildcard, le serveur faisant autorité produit une réponse ayant l’apparence de NODATA : RCODE NOERROR, section Answer vide, et un seul NSEC ou NSEC3 signé qui correspond au QNAME. Pour les besoins de la preuve, elle affirme que le nom existe mais ne possède aucune donnée du type demandé. Un enregistrement couvrant au plus près suffit.

La fiche RFC Editor et la fiche Datatracker classent RFC 9824 comme Proposed Standard publié en septembre 2025. Le texte met à jour RFC 4034 et RFC 4035. Son historique, ses références et les documents qui le référencent décrivent une spécification publique. Ils ne démontrent ni implémentation, ni activation, ni résultat chez un opérateur nommé.

NXNAME distingue l’absence signée du simple vide

Une section Answer vide n’est pas une preuve suffisante. Un nom existant peut ne pas porter le type interrogé. Un empty non-terminal existe parce que des noms descendants existent, tout en ne portant lui-même aucun RRset. Ces cas peuvent ressembler à la réponse compacte d’un nom absent.

RFC 9824 crée donc NXNAME, Meta-TYPE synthétique de valeur 128. Avec NSEC, le bitmap d’un nom inexistant contient RRSIG, NSEC et NXNAME. Avec NSEC3, NXNAME en est l’unique entrée. L’empty non-terminal n’a pas ce marqueur. Ce n’est plus le silence qui tranche, mais une assertion placée dans le matériel signé.

Le registre IANA DNS Parameters attribue un nom et une valeur communs à NXNAME, au drapeau CO et à l’Extended DNS Error 30. L’enregistrement coordonne les identifiants ; il ne prouve pas qu’un logiciel les émet, les valide ou les applique correctement.

NXNAME ne devient pas pour autant une donnée ordinaire de zone. Il ne doit apparaître que dans le bitmap NSEC ou NSEC3 d’une réponse compacte portant sur un nom inexistant. Une requête explicite dont le QTYPE est NXNAME reçoit FORMERR. Le serveur peut ajouter EDE 30, Invalid Query Type, et un résolveur ne doit ni transmettre cette requête, ni lancer une résolution itérative. RFC 8914 fournit le cadre général des EDE ; RFC 9824 fixe ce cas précis.

Le corps est authentifié, pas le verdict commode de l’en-tête

Le point le plus important du texte est aussi le plus facile à perdre dans une API : l’en-tête DNS n’est pas protégé par DNSSEC. Son RCODE ne peut donc pas être authentifié. La preuve signée contenue dans le corps offre un fondement plus solide pour conclure à l’inexistence.

Cela ne rend pas le RCODE inutile. Beaucoup de bibliothèques et d’outils de sécurité lisent d’abord ce champ. L’un peut voir NOERROR et classer la réponse comme NODATA ; un validateur peut vérifier la RRSIG, reconnaître NXNAME et conclure que le nom n’existe pas. Il faut conserver les deux observations avec leur point d’origine, sans donner au champ le plus facile à indexer le pouvoir d’annuler la preuve.

RFC 4034 définit les enregistrements DNSSEC, notamment NSEC et RRSIG. RFC 4035 décrit les modifications de protocole et le traitement du déni authentifié. RFC 9824 introduit l’exception nécessaire à la signature en ligne compacte. RFC 9364 donne une vue d’ensemble de DNSSEC, tandis que RFC 9499 stabilise la terminologie DNS. Aucun de ces textes ne transforme une capture d’en-tête non validée en fait signé.

Le reçu minimal associe le nom et le type demandés, les états DO et CO, le RCODE reçu, la forme NSEC/NSEC3, la présence de NXNAME, les identifiants publics de clé et d’algorithme, le résultat de validation, la version du validateur, l’horodatage et une empreinte de preuve. La clé privée ne doit jamais y entrer.

Restituer NXDOMAIN reste une décision locale entre deux voisins

RFC 9824 recommande de préserver NXDOMAIN lorsque c’est possible. Pour les échanges DNSSEC, il définit le drapeau EDNS Compact Answers OK. Un résolveur qui envoie CO indique qu’il accepte une réponse compacte comprenant NXNAME signé et un RCODE remis à NXDOMAIN. Un serveur faisant autorité qui implémente les deux mécanismes peut répondre avec CO et NXDOMAIN.

Mais RFC 6891 situe EDNS sur chaque saut. Le résolveur doit mémoriser le CO reçu avec les données mises en cache. Si le demandeur DNSSEC suivant n’envoie pas CO, le résolveur remet le RCODE à NOERROR pour la réponse NXNAME.

La preuve reste identique ; seule la présentation change. Un cache qui conserve les RRsets mais perd le bit de capacité ne peut plus reconstruire le contrat. Une métrique qui ne conserve que le dernier RCODE ne dit pas si le résolveur a validé NXNAME, adapté la réponse à son voisin ou simplement recopié l’amont.

Une preuve plus compacte déplace aussi la charge

RFC 4470 décrit les NSEC couvrant au plus près et la signature en ligne. RFC 5155 définit NSEC3. RFC 9824 réduit la taille de la réponse et le nombre d’opérations cryptographiques par rapport aux formes dynamiques plus larges. Les couvertures minimales empêchent également une énumération utile de la zone.

Ce gain local n’est pas une disparition générale du travail. Les réponses compactes ne permettent pas les synthèses NXDOMAIN et wildcard de RFC 8020 et RFC 8198. Des requêtes portant sur des sous-domaines pseudo-aléatoires peuvent donc continuer jusqu’aux serveurs faisant autorité au lieu d’être absorbées par le cache négatif.

Le signataire en ligne doit garder une capacité de signature privée sur une infrastructure exposée à Internet et calculer les signatures à la demande. La forme compacte réduit ce travail par réponse ; elle ne supprime ni le coût, ni l’exposition au déni de service computationnel. Le texte laisse explicitement aux déploiements le choix d’autres méthodes lorsque les avantages attendus ne justifient pas ces contraintes.

L’application ne voit pas l’intention du protocole

Une fonction de résolution d’adresse peut, après une réponse NODATA à une requête AAAA, envoyer une seconde requête A pour le même nom. Un NXDOMAIN ordinaire aurait pu l’éviter. Le chemin applicatif peut donc diverger alors même qu’un validateur capable de lire NXNAME connaît déjà l’inexistence.

La primauté du code exécuté exige de suivre la chaîne réelle : génération de la preuve, validation, interprétation de NXNAME, écriture du cache, évaluation de CO, émission du RCODE, requêtes supplémentaires et résultat de l’application. La discipline des couches de réalité interdit d’appeler “succès” une signature valide sans observer l’usage, ou d’appeler “présent” un nom parce que l’en-tête a dit NOERROR.

Sources

  1. IETF Datatracker : RFC 9824
  2. Historique Datatracker
  3. Documents référençant RFC 9824
  4. Références de RFC 9824
  5. Heng Lu : Minimum Initial Specification
  6. Heng Lu : Reality Layers
  7. Heng Lu : Running-Code Primacy
  8. IANA DNS Parameters
  9. Errata RFC 9824
  10. Informations RFC Editor
  11. RFC 4034
  12. RFC 4035
  13. RFC 4470
  14. RFC 5155
  15. RFC 6891
  16. RFC 8020
  17. RFC 8198
  18. RFC 8914
  19. RFC 9364
  20. RFC 9499
  21. RFC 9824