Résumé

  • LocalRoot remplace de nombreux petits échanges avec les serveurs racine par des opérations moins fréquentes mais plus volumineuses de distribution de zone.
  • Dans le banc d’essai d’Ilyas Rahimi, les quatre configurations mesurées dépassent la référence estimée du modèle classique ; la logique de mise à jour compte davantage que l’étiquette du transport.
  • La fenêtre est courte et l’environnement contrôlé : ces résultats décrivent des configurations, pas une loi universelle sur la bande passante.

Deux compteurs qui ne racontent pas la même histoire

Un tableau de bord peut annoncer une chute spectaculaire des requêtes racine sortantes. C’est exact et incomplet. La copie locale doit encore suivre la publication commune. Le réseau transporte alors moins de petits paquets de résolution et davantage d’objets complets ou incrémentaux, accompagnés de contrôles et parfois de nouvelles tentatives.

Le travail de Rahimi, enregistré par NLnet Labs en janvier 2026, met les deux modèles dans une unité commune : mégaoctets par résolveur et par jour. La référence classique provient de sept jours de données RSSAC002. La partie LocalRoot vient de captures sur quatre jours, dans un environnement virtuel, avec BIND, Unbound par DNS, Unbound par HTTPS et Knot Resolver.

La référence n’est pas uniforme. Les moyennes par lettre racine se situent surtout entre 0,67 et 1,34 Mo par jour, tandis que f-root atteint 11,18 Mo. L’exercice d’échelle retient ensuite environ 2 Mo en moyenne. Il s’agit d’une estimation fondée sur des agrégats et des sources uniques approximatives, non de la consommation observée de chaque résolveur.

La cadence domine le nom du protocole

BIND transfère environ 1,45 Mo lors d’un changement et atteint 4,35 Mo par jour en moyenne. Unbound utilisant les mécanismes DNS transfère environ 1,31 Mo par changement, soit 3,93 Mo par jour. Les deux suivent le serial SOA et leur coût varie avec le nombre de modifications réelles.

L’instance Unbound sur HTTPS télécharge au contraire la zone complète, environ 2,19 Mo, toutes les trente minutes. Quarante-huit téléchargements produisent 105,12 Mo par jour. L’étude rapporte que cette absence de vérification préalable du serial est considérée comme un bogue. Ce chiffre appartient donc à la version et à la configuration testées, pas à HTTPS en général.

Knot Resolver utilise aussi HTTPS, mais effectue environ un téléchargement quotidien. Sa moyenne est de 2,65 Mo. Deux parcours portant le même nom de transport aboutissent ainsi aux deux profils les plus éloignés. La planification, le contrôle de changement et la capacité incrémentale déterminent le résultat.

Recevoir n’est pas activer

Le projet individuel draft-wkumari-dnsop-localroot-bcp-07, mis à jour en juillet 2026, propose une discipline plus explicite. Le résolveur choisit une source, vérifie d’abord la fraîcheur par HEAD ou par SOA, refuse un serial inférieur et essaie une autre source après échec. Il devrait éviter de retélécharger l’intégralité à chaque intervalle.

Une zone reçue reste candidate. Son enregistrement ZONEMD doit être vérifié, puis authentifié par DNSSEC avec l’ancre de confiance racine IANA. Aucune donnée ne doit être servie avant la réussite de cette chaîne. Si la copie devient indisponible ou périmée, les requêtes ordinaires vers le Root Server System reprennent, au plus tard avant l’expiration SOA.

RFC 8806 ajoute des limites déjà établies : zone complète, données identiques à la racine publique, validation DNSSEC et service réservé aux résolveurs du même hôte. La proximité change la livraison ; elle ne supprime ni publication, ni ancre, ni sortie de secours.

Une étude de trafic, pas un verdict de déploiement

Quatre jours ne couvrent pas les versions, politiques et incidents d’Internet. L’étude ne mesure ni latence, ni complexité d’exploitation, ni résultat réel de confidentialité. Elle suppose aussi qu’un ensemble de sources uniques RSSAC peut approcher une population de résolveurs. Ces limites interdisent de transformer le ratio observé en promesse mondiale.

Elles renforcent pourtant une règle utile : le nombre de requêtes, les octets, la fraîcheur et la disponibilité sont quatre faits distincts. Un transfert léger peut être ancien. Un transfert lourd peut être correct. Une baisse des requêtes visibles peut améliorer la confidentialité vis-à-vis d’un observateur tout en laissant le résolveur, les serveurs autoritaires suivants et les journaux d’actualisation capables d’observer d’autres éléments.

Les reçus nécessaires

Pour chaque cycle, conserver le compteur et les octets des requêtes, le contrôle de changement, la source choisie, les octets utiles et répétés, le mode AXFR/IXFR/HTTPS, la version logicielle, le serial et les timers SOA, les résultats ZONEMD/DNSSEC, le hash du candidat, la décision d’activation, le repli et le résultat de résolution vu par l’utilisateur.

Ces preuves peuvent partager un identifiant. Elles ne doivent pas devenir un unique voyant vert. Sinon, une baisse exemplaire des requêtes peut masquer un téléchargement inchangé en boucle, une copie non validée ou un repli déjà actif.

Sources

Rapport de Rahimi, registre NLnet Labs, entretien APNIC, Internet-Draft et RFC 8806.