Résumé

  • La copie datée du 11 septembre du registre Hosted DNS contient 48 lignes AuthDNS : 43 opérationnelles et cinq décommissionnées. Ce total décrit un parc, pas le nombre de populations de résolveurs ayant obtenu un chemin plus court ou plus robuste.
  • Le propre travail de mesure du RIPE NCC révèle le piège géographique : le nœud de Bahreïn était principalement choisi par des sondes en Arabie saoudite, tandis que les sondes du réseau bahreïni Batelco ne l’atteignaient presque jamais.

Ce que certifie une ligne verte

Une ligne marquée « Operational » n’est pas anodine. Elle associe un identifiant à un service, un lieu, une organisation d’accueil, un nom d’hôte et, lorsque la date est disponible, à l’achèvement d’un déploiement. Elle permet de distinguer une machine annoncée d’une machine retirée. Pour un service distribué, ce registre constitue une pièce de responsabilité utile.

La photographie conservée pour cette enquête recense 48 lignes AuthDNS. Quarante-trois sont opérationnelles ; cinq ont été décommissionnées. Le nœud #523, hébergé à Milan par LAKENETWORKS, porte la date du 18 juin 2026. Le #520, à Berlin chez BCIX Management GmbH, celle du 28 juillet. Ces deux dates sont postérieures à la mise à jour, le 11 juin, du plan trimestriel. Rien ne permet cependant d’en déduire que ce plan a déclenché les deux projets, ni qu’un objectif de couverture particulier a été atteint.

Le registre répond donc proprement à une question : combien d’instances Hosted AuthDNS le RIPE NCC présente-t-il comme opérationnelles à la date de capture ? Il ne répond pas à une autre : combien de réseaux d’accès insuffisamment servis ont changé de destination anycast grâce à elles ? Confondre ces réponses transforme un inventaire vérifiable en indicateur de résultat imaginaire.

Le plan parle déjà le langage du routage

Le plan DNS et K-root du troisième trimestre 2026 formule l’objectif avec davantage de finesse que ne le ferait un compteur. Dans les zones où AuthDNS est mal représenté, le RIPE NCC souhaite s’installer dans un grand réseau d’accès national, chez un réseau qui échange avec de grands réseaux d’accès, ou sur un port d’IXP permettant de joindre plusieurs parties. L’action reste « In progress ».

Ces critères ont tous une dimension topologique. Un grand réseau d’accès concentre des résolveurs et des utilisateurs. Un pair peut rendre une annonce locale préférable. Un serveur de routes d’IXP peut ouvrir un chemin direct à plusieurs systèmes autonomes. Le nom d’une ville ne démontre aucune de ces propriétés. L’adresse physique du matériel et son voisinage BGP sont deux descriptions différentes du monde.

Le document ne fournit ni liste publique des pays déficitaires, ni dénominateur de couverture, ni seuil de latence, ni part cible de sondes ou de résolveurs, ni période d’acceptation. Cela ne signifie pas qu’aucune métrique interne n’existe. Cela signifie que l’objectif public et l’inventaire public ne forment pas encore, ensemble, un calcul reproductible.

Le cœur et sa périphérie hébergée

AuthDNS annonce 193.0.9.0/24 et 2001:67c:e0::/48 depuis AS197000. Le service répond pour les zones de résolution inverse sous in-addr.arpa et ip6.arpa, pour ripe.net, pour des zones d’infrastructure des autres RIR, pour certaines organisations soutenues et comme secondaire pour quelques domaines nationaux.

Son architecture publique distingue quatre sites de cœur — Amsterdam, Londres, Stockholm et Tokyo — des instances hébergées. Dans les sites de cœur, un routeur distribue les requêtes vers plusieurs serveurs utilisant BIND, Knot DNS et NSD. Les nœuds hébergés complètent cet ensemble sous la forme d’instances à serveur unique, placées dans des réseaux de fournisseurs d’accès ou raccordées à des points d’échange.

La nuance est essentielle. Une nouvelle instance peut réduire une distance de routage sans reproduire la diversité de logiciels et de serveurs d’un site de cœur. À l’inverse, un site de cœur très robuste peut rester hors du chemin privilégié d’une population de résolveurs. Compter indifféremment nœuds, serveurs, sites et zones de desserte efface les mécanismes que l’on voudrait surveiller.

Bahreïn, ou la géographie démentie par BGP

Le RIPE NCC a déjà montré comment vérifier la desserte. En décembre 2024, une étude RIPE Labs a utilisé des sondes RIPE Atlas en Europe du Sud-Est, en Asie centrale et au Moyen-Orient. Toutes les trente minutes, elles interrogeaient 193.0.9.7 pour 150.6.0.193.in-addr.arpa. Le traitement associait chaque sonde au serveur ayant répondu et calculait notamment la médiane du temps aller-retour par jour.

En Europe du Sud-Est, beaucoup de sondes aboutissaient à Amsterdam. Les nœuds locaux dominaient en Bosnie-Herzégovine et, plus nettement encore, en Roumanie. Certaines sondes atteignaient pourtant Kansas City ou Bahreïn. En Asie centrale, région alors dépourvue d’instance AuthDNS selon l’étude, Amsterdam et Stockholm recueillaient l’essentiel des requêtes observées.

Le résultat le plus instructif concernait Manama. Le nœud de Bahreïn, hébergé par STC Bahrain, servait principalement des sondes situées en Arabie saoudite. Les sondes du réseau Batelco à Bahreïn, AS5416, ne le choisissaient presque jamais. En revanche, celles de Saudi Telecom Company, AS25019, l’atteignaient pendant toute la période. Pour les sondes saoudiennes, ce choix était performant : une médiane inférieure à 50 ms, contre environ 100 ms vers les instances européennes, et bien davantage vers le Venezuela ou Guam.

Le nœud n’avait pas raté sa mission. Il révélait que la mission ne peut être lue dans son adresse. L’anycast confie la sélection à BGP ; annonces, préférences, accords d’échange et transits dessinent la zone effective. Un serveur peut être local sur la carte et lointain dans la table de routage, ou l’inverse.

Une politique d’échange, pas un territoire

La politique AuthDNS aide à suivre la chaîne. AS197000 adopte une politique d’échange généralement ouverte. Sur les sites de cœur et les nœuds hébergés en IXP, le service accepte via les serveurs de routes les préfixes d’au moins /24 en IPv4 et /48 en IPv6 et y annonce ses propres préfixes. Le RIPE NCC encourage l’usage des serveurs de routes et de leurs communautés de filtrage. Les échanges directs sont examinés dans des cas définis ; sur les nœuds IXP hébergés, ils le sont lorsque le point d’échange n’a pas de serveur de routes.

Le registre des nœuds affiche l’organisation d’accueil mais pas, pour chaque ligne, son ASN d’hébergement, la liste de pairs, la part de résolveurs attirée ni une mesure avant-après. Réclamer toute la topologie serait excessif : des accords sont privés, les chemins changent et certains détails peuvent relever de la sécurité. Il suffit d’un reçu agrégé qui prouve le résultat sans exposer l’architecture sensible.

Le cache réduit la population concernée

La FAQ Hosted DNS tempère encore le récit. La plupart des requêtes DNS sont satisfaites par des caches. Pour un réseau déjà bien connecté, le bénéfice d’un nœud local peut être très modeste, voire nul ; seule une faible fraction des requêtes vers les zones supérieures atteint directement un serveur racine ou AuthDNS. Une meilleure destination AuthDNS peut accélérer les recherches concernées, mais elle ne réduit pas mécaniquement toute latence DNS ni le trafic amont du réseau.

Le contrat opérationnel répartit en outre les responsabilités. L’hôte fournit un serveur conforme ou une machine virtuelle convenablement dimensionnée, l’environnement de colocation, l’alimentation redondante, la sécurité physique et la connectivité. Il assume ces coûts. Le RIPE NCC administre le serveur à distance. S’il détecte un problème de nœud ou d’accessibilité, le préfixe est retiré afin que les requêtes basculent vers d’autres serveurs.

Un retrait peut donc modifier la zone de desserte sans déplacer le matériel. Un nouvel accord d’échange peut améliorer un chemin sans ajouter de ligne. Une machine peut rester verte alors que la population qu’elle reçoit évolue. L’inventaire et la couverture vivent sur des horloges distinctes.

Ajouter un reçu de couverture

Le registre actuel doit rester. Il est lisible et attribue mieux les déploiements qu’une carte décorative. Mais le plan public appelle un second document : un reçu de couverture lié à chaque nœud accepté ou à chaque campagne régionale.

Ce reçu pourrait nommer l’identifiant du nœud et la lacune ciblée ; citer une mesure RIPE Atlas, sa règle de sélection des sondes et sa fenêtre ; comparer la distribution des serveurs répondants et les temps aller-retour avant et après ; fixer une condition d’acceptation ; déclarer les exceptions, les mouvements d’échantillon et les limites de représentativité. Les relations d’échange privées et les résolveurs individuels pourraient rester masqués.

Cinq verdicts doivent demeurer séparés. L’inventaire prouve qu’une instance est déclarée active. L’accessibilité prouve qu’un point d’observation reçoit une réponse. La zone de desserte identifie le serveur choisi. La latence décrit un chemin pendant une période. La résilience teste ce qui survit à la disparition d’un nœud ou d’une route. Quarante-trois ne peut pas résumer ces cinq états.

Sources