Ginevra Fabrizio : 11 octets de moins, NXDOMAIN déborde

Résumé

Dans un rejeu d’une journée de requêtes .nl, la signature Falcon-512 non rembourrée avait une médiane de 655 octets, soit 11 de moins que la taille fixe de 666 octets. Ce gain n’a pas augmenté de façon notable le nombre de réponses NOERROR sous les seuils de 1 232 et 1 500 octets.
Toutes les réponses NXDOMAIN testées dépassaient ces deux seuils. Plusieurs preuves NSEC3 signées, et non le seul bourrage d’une signature, faisaient gonfler ces réponses négatives.

Le format compressé a gagné le concours des octets. Les paquets NXDOMAIN ont continué de déborder. C’est le résultat saillant de l’exposé de Ginevra Fabrizio à RIPE 93 : une différence nette sur le graphique des signatures s’efface dans une réponse DNS complète.

Fabrizio, chercheuse à l’Université de Twente, a présenté un travail mené avec des collègues de SIDN. Leur article est paru à l’Applied Networking Research Workshop en 2025 ; elle a repris la comparaison des formats pendant la session DNS de RIPE 93, le 29 octobre 2026. La question était concrète : une signature DNSSEC plus courte permet-elle à davantage de réponses réelles de tenir dans un seul paquet ?

DNSSEC ajoute des signatures aux données DNS pour que les résolveurs en vérifient l’authenticité et l’intégrité. Une réponse négative peut réunir plusieurs enregistrements NSEC3 et leurs signatures pour prouver qu’un nom n’existe pas.

L’équipe a utilisé les requêtes reçues par les serveurs autoritaires de .nl pendant 24 heures, le 3 avril 2025. Elle a retiré les données DNSSEC déjà présentes dans la zone, signé deux copies de test avec Falcon-512, puis rejoué les requêtes contre des serveurs NSD : l’un utilisait le format rembourré, l’autre le format non rembourré. L’analyse a porté sur les deux réponses les plus courantes, NOERROR et NXDOMAIN. Falcon n’a pas été déployé dans la zone .nl de production.

La comparaison des signatures semble d’abord donner l’avantage à la compression. Falcon-512 rembourré produit une signature fixe de 666 octets. Dans la zone testée, la médiane non rembourrée était de 655 octets. Onze octets comptent, mais ils ne sont qu’une partie du paquet : le nom interrogé, les enregistrements DNS, les preuves DNSSEC et leurs signatures occupent aussi l’espace.

Pour les réponses NOERROR, la majorité restait sous le budget DNS de 1 232 octets et sous le MTU Ethernet de 1 500 octets utilisé comme deuxième seuil. Une part plus faible, mais non négligeable, les dépassait. Les courbes rembourrée et non rembourrée restaient proches ; le changement de format n’a pas fait passer sensiblement plus de réponses sous les seuils. La plupart tenaient déjà dans le budget, et onze octets modifiaient rarement le côté de la ligne où tombait une réponse.

NXDOMAIN a révélé le cas difficile. Une réponse négative signée doit prouver qu’un nom n’existe pas. Dans cette zone, la preuve pouvait réunir deux ou trois enregistrements NSEC3, chacun accompagné de sa signature. Le rejeu a produit 113 348 878 réponses NXDOMAIN ; toutes dépassaient les deux seuils. Avec deux NSEC3 signés, les réponses mesuraient de 2 269 à 2 420 octets. Avec trois, elles allaient de 3 075 à 3 767 octets. La signature prenait place dans un paquet déjà chargé de preuves.

Le jeu NOERROR comptait 59 312 128 réponses NOERROR après rejeu. Sa minorité au-dessus des seuils importe, mais elle ne doit pas être confondue avec le résultat NXDOMAIN : le premier ensemble était mixte ; le second dépassait les deux limites à chaque fois dans ce test. Le tableau des tailles rend le mécanisme visible. Ajouter une preuve signée déplace la réponse de plusieurs centaines d’octets ; changer le format d’une signature en déplace beaucoup moins.

L’article de Fabrizio montre aussi que la variation de longueur des noms de domaine interrogés est du même ordre que celle de la taille d’une signature Falcon-512 non rembourrée. Ce rapprochement remet le gain de compression à sa place dans l’arithmétique réelle du DNS : les noms varient, le nombre de preuves aussi, et une seule signature ne détermine pas la taille totale de la réponse.

Les auteurs concluent que la taille fixe du format rembourré peut être préférable pour sa prévisibilité et pour limiter les erreurs d’implémentation. Pendant les questions à RIPE 93, Fabrizio a décrit l’arithmétique en virgule flottante comme un défi d’implémentation et l’a mise en regard du recours important au TCP. Le bourrage ne réduit pas une réponse trop grande ; il rend la longueur des signatures prévisible pendant que l’écosystème évalue la complexité d’un gain moyen modeste.

Elle a également indiqué qu’elle et SIDN commençaient un banc d’essai sur les charges côté résolveur et côté serveur faisant autorité, avec Falcon et ML-DSA. Les résultats étaient trop récents pour être présentés. La prochaine mesure utile relierait la distribution des tailles aux tentatives TCP et à la latence réellement observées par les résolveurs. L’étude ne mesure ni ces tentatives récursives en production ni le délai de bout en bout ; ces données pourraient modifier le coût opérationnel attribué aux 11 octets.

La séparation essentielle est déjà nette : la plupart des réponses NOERROR testées tenaient sous les seuils, tandis que toutes les NXDOMAIN les dépassaient. Un choix futur de format Falcon pour DNSSEC doit donc regarder la forme des réponses et le nombre de preuves, pas seulement la médiane d’une signature.