ZDNS: huit implantations DNS visibles, mais aucune part des 732 baies ne peut lui être attribuée

Résumé

• Les données de routage, les délégations de domaines et le dossier ICANN donnent à la présence réseau et aux services logiques de ZDNS un niveau de preuve moyen: l’activité est visible, mais son exécution physique reste partiellement opaque.
• Les huit lignes d’implantation décrivent des dépendances à Pékin, Chengdu, Hong Kong, Los Angeles, Chicago, Francfort et New York; elles ne prouvent ni huit domaines de panne indépendants, ni une capacité égale ou réservée dans chacun d’eux.
• Les 732 baies du site M5 Phase III sont un total d’installation hôte, pas un actif de ZDNS. Sans inventaire attribuable, charge par site et résultat daté de bascule du site principal, la preuve de capacité physique et de marge de secours demeure faible.

La bonne question n’est pas de savoir si ZDNS existe sur le réseau

Pour évaluer une infrastructure DNS, il est tentant de commencer par ce qui se compte facilement: des villes, des préfixes, des baies, des requêtes par seconde ou un pourcentage de disponibilité. Ces chiffres ne parlent pourtant pas tous de la même chose. Une route BGP atteste qu’une plage d’adresses est annoncée. Une délégation dans la racine indique quels serveurs font autorité pour un domaine de premier niveau. Une fiche commerciale décrit une capacité revendiquée. Un certificat de centre de données inventorie, lui, des équipements appartenant à l’installation qui accueille des clients.

Aucun de ces éléments, pris isolément, ne dit combien de machines ZDNS possède ou loue, quelle charge elles portent, ni ce qu’il resterait si le point le plus important disparaissait.

L’identité réseau est néanmoins bien réelle. L’enregistrement APNIC RDAP d’AS38345 conserve la graphie « Resrarch » utilisée dans le libellé du titulaire, tandis que la demande ICANN actuelle emploie la raison sociale corrigée et le nom commercial ZDNS. Cette différence orthographique ne justifie pas d’imaginer deux sociétés. Elle impose plutôt de distinguer la fidélité aux registres historiques de l’usage éditorial courant. La recherche Whois d’APNIC rappelle aussi que l’enregistrement d’AS38345 est antérieur à la date de création de 2013 avancée par ZDNS et qu’il conserve d’anciens contacts KNET. Ce décalage n’établit ni acquisition, ni filiation, ni transfert de propriété: les documents disponibles ne racontent pas cette histoire.

Les pages institutionnelles de ZDNS permettent seulement de cadrer l’entité qui s’exprime aujourd’hui. La page À propos de ZDNS situe son récit d’entreprise et son offre, et la page de contact donne le point de référence actuel de la société. Leur utilité est certaine pour comprendre la manière dont ZDNS se présente; leur portée est différente de celle d’un inventaire technique vérifié. Une présentation institutionnelle ne transforme pas un ancien enregistrement de numéro de système autonome en preuve d’une chaîne capitalistique, pas plus qu’elle ne transforme une adresse de bureau en salle informatique.

L’enjeu de cette analyse est donc plus exigeant: quelle part des services de registre et de DNS autoritatif, visibles à l’échelle mondiale, peut être reliée à des actifs physiques attribuables, à une capacité de repli utilisable et à une reprise effectivement démontrée ? Sur le premier volet, celui du réseau et des fonctions logiques, les pièces publiques forment un ensemble cohérent mais incomplet: le niveau de preuve est moyen. Sur le second, celui des actifs physiques propres à ZDNS et de la marge disponible après panne, les lacunes sont structurelles: le niveau de preuve est faible.

Fusionner ces deux appréciations en une note générale ferait disparaître la distinction la plus importante.

Une offre logique étendue, mais plusieurs surfaces d’exploitation

Le dossier public de la campagne ICANN 2026 confirme que ZDNS a franchi l’évaluation pour plusieurs familles de fonctions. La liste des demandes évaluées l’indique pour les catégories Main, DNS, DNSSEC et Proxy, avec prise en charge des noms de domaine internationalisés. Cette décision évalue une soumission et les capacités décrites à cette occasion. Elle ne constitue pas une attestation permanente de chaque instance installée, de chaque client servi ni de l’état de chaque site à toute heure.

Le programme ICANN consacré aux opérateurs techniques de registre fournit le cadre dans lequel il faut lire cette évaluation. La pièce centrale reste la demande Main M57 de ZDNS. Elle décrit des fonctions de registre, le dépôt fiduciaire des données, DNSSEC, WHOIS et RDAP, ainsi que des contrôles de sauvegarde, de surveillance et de reprise. L’accord de registre de base de l’ICANN aide à comprendre le contexte contractuel de ces fonctions. Ces documents donnent une substance à l’offre; ils ne révèlent pas automatiquement la topologie matérielle derrière chaque service.

Cette prudence est essentielle, car « ZDNS » recouvre plusieurs surfaces qui ne doivent pas être confondues. La présentation de la plateforme TLD concerne les opérations de registre et les services associés. La page consacrée au DNS en nuage décrit notamment le DNS autoritatif, le GSLB, HTTPDNS et des mécanismes liés au BGP et à l’anycast. La gamme d’équipements principaux déployables correspond, elle, à des appareils pouvant être installés dans l’environnement d’un client. Une fonction hébergée par ZDNS, une composante de registre et un équipement placé chez un client n’ont ni la même frontière opérationnelle, ni les mêmes données, ni le même responsable physique.

Cette pluralité a des conséquences directes pour l’évaluation. Un incident dans un service de registre peut toucher la base d’enregistrements, les interfaces destinées aux bureaux d’enregistrement ou la publication DNS, sans affecter de la même manière un appareil autonome chez un client. À l’inverse, la présence d’un équipement dans les locaux d’une entreprise ne démontre rien sur la capacité disponible dans le réseau mondial de ZDNS. Même quand deux offres partagent un nom de produit, une compétence DNSSEC ou un mécanisme de distribution, il faut conserver leurs périmètres propres.

La visibilité publique est donc suffisante pour conclure que ZDNS ne se réduit pas à une marque sans activité technique observable. Elle est insuffisante pour représenter tous ces services comme une seule ferme de serveurs mondiale dont on pourrait additionner les capacités. Le bon objet d’étude est une chaîne de fonctions: registre, dépôt des données, signature, publication autoritative, routage, résolution spécialisée et, séparément, matériel déployé chez le client. Tant que la correspondance entre ces fonctions et les sites n’est pas publiée, une ville ou une adresse réseau reste un indice de dépendance, pas une unité de capacité.

Huit lignes d’implantation ne font pas huit domaines de panne

La pièce la plus concrète sur la géographie est l’annexe ICANN relative aux centres de données. Elle aligne huit entrées: CSNET à Pékin, Jiuxianqiao à Pékin, Chengdu, HKIX à Hong Kong, puis quatre implantations Cogent à Los Angeles, Chicago, Francfort et New York. Le nombre huit est exact pour les lignes du document. Il serait toutefois abusif de le convertir en huit nœuds physiques indépendants, huit salles contrôlées par ZDNS ou huit parts égales de la charge.

L’annexe associe Pékin, Hong Kong, Los Angeles, Chicago, Francfort et New York à des services anycast. Jiuxianqiao et Chengdu sont, pour leur part, associés à des services unicast. Cette distinction apporte une information sur le mode d’acheminement déclaré, mais elle ne donne ni fonction détaillée par site, ni liste d’équipements, ni volume courant, ni liens de transit, ni correspondance complète entre adresses et implantations. Deux lignes peuvent dépendre d’un même prestataire de réseau, d’un même contrôle logique ou d’une même source de configuration. À l’inverse, une ligne peut cacher plusieurs équipements. Le tableau ne tranche pas.

Les références aux opérateurs hôtes renforcent le constat de dépendance sans résoudre la question de l’attribution. Le site public de HKIX confirme l’existence d’une infrastructure d’échange à Hong Kong; il ne chiffre pas ce que ZDNS y réserve. La carte du réseau Cogent donne le contexte des quatre villes américaines et européenne citées; elle ne prouve pas quatre conduites totalement séparées jusqu’aux équipements de ZDNS. Le nom d’un opérateur et celui d’une ville décrivent un environnement possible de raccordement. Ils ne sont ni un contrat de capacité, ni un relevé de ports, ni une photographie de la redondance interne.

Il faut également éviter de confondre distance géographique et indépendance réelle. Los Angeles et New York sont éloignées, mais une même erreur globale peut atteindre les deux. Deux sites pékinois peuvent être physiquement distincts, mais leur degré d’autonomie dépend de l’électricité, des chemins de fibre, des systèmes de contrôle, des données et des équipes qu’ils partagent. L’annexe ne fournit pas ces corrélations. Elle ne permet donc pas de classer les huit lignes selon leur résistance respective à une panne électrique, à une coupure de transit, à une erreur de configuration ou à une corruption de données.

Pour un acheteur, le résultat utile n’est pas « huit sites », mais une matrice reliant chaque fonction à un lieu et à un domaine de défaillance. Il faudrait savoir où se trouvent les écritures du registre, les répliques en lecture, la signature DNSSEC, les serveurs autoritatifs, les interfaces WHOIS/RDAP, les copies de sauvegarde et les contrôles. Il faudrait ensuite identifier, pour chacun, l’hôte, le réseau, l’alimentation, la capacité installée, la capacité libre et les dépendances communes. Le document public offre la première colonne de cette matrice, parfois la deuxième; il laisse les autres vides.

Les 732 baies décrivent le bâtiment hôte, pas la capacité de ZDNS

Le chiffre le plus spectaculaire du dossier est aussi le plus facile à mal employer. L’annexe mentionne, pour Beijing M5 Phase III, un certificat couvrant 732 baies réparties dans trois salles. Elle énumère également deux groupes frigorifiques de 3 517 kW, deux réservoirs d’eau glacée de 84 mètres cubes et cinq groupes diesel de 2 500 kVA. Ces valeurs décrivent le périmètre de l’installation hôte couvert par le certificat. Elles ne disent pas combien de baies, de kilowatts, de serveurs ou de groupes seraient détenus, loués ou utilisables par ZDNS.

La limite est encore plus nette puisque le réseau et le câblage sont exclus du périmètre du certificat cité. Une installation peut disposer d’une forte capacité électrique et thermique globale sans que l’on connaisse le raccordement d’un client donné, la diversité de ses fibres, son quota d’énergie ou la densité de ses baies. Même une baie attribuée ne renseignerait pas, à elle seule, sur le nombre de serveurs actifs, les alimentations effectivement séparées, le stock de pièces de rechange ou la capacité de traitement. Aucune fraction des 732 baies ne peut donc être portée au bilan d’infrastructure de ZDNS sur cette seule base.

L’autre grande description immobilière concerne Huairou. La présentation évoque environ 20 000 mètres carrés et plus de 1 000 armoires. La page institutionnelle du Computer Network Information Center apporte le contexte de l’organisation mentionnée. Là encore, mètres carrés et armoires sont des attributs agrégés du site. Ils ne constituent pas une allocation nominative. Additionner 732 baies à plus de 1 000 armoires créerait un total sans signification pour ZDNS, car ni la part de l’entreprise ni même l’équivalence exacte des périmètres n’est établie.

La demande Main indique au moins deux centres de données indépendants de niveau Tier III ou équivalent. L’aperçu des niveaux de résilience de l’Uptime Institute permet de replacer cette formulation dans son vocabulaire. Mais « Tier III ou équivalent » ne remplace pas un inventaire propre à ZDNS. Une installation conçue pour la maintenance sans interruption peut héberger un déploiement client modeste, saturé ou dépendant d’un élément extérieur. La qualité générale du bâtiment et la marge spécifique du client sont deux objets de preuve distincts.

La seule conclusion robuste est donc étroite mais importante: le chiffre de 732 baies prouve une dépendance documentée envers une installation hôte d’une certaine ampleur. Il ne prouve aucune capacité totale de ZDNS. Cette nuance change l’économie du service. Sans quantité réservée, puissance contractuelle, inventaire installé, durée d’engagement et capacité libre, il est impossible d’estimer le coût unitaire, l’élasticité réelle ou la facilité avec laquelle ZDNS pourrait absorber une croissance soudaine. L’enveloppe du bâtiment n’est pas la marge du service.

Le routage prouve une surface active, pas des serveurs dans chaque ville

Les observations de routage apportent une preuve indépendante de l’activité réseau. Pendant la période examinée, AS38345 annonçait 24 préfixes IPv4 de taille /24 et 12 préfixes IPv6 de taille /48, avec une visibilité large auprès des collecteurs. L’aperçu RIPEstat d’AS38345, la liste de ses préfixes annoncés et son état de routage permettent de distinguer trois aspects: l’identité du système autonome, les plages qu’il annonce et la manière dont ces annonces sont vues.

Cette présence double pile est substantielle. Elle indique que ZDNS dispose d’une surface d’adressage routée qui n’est pas seulement déclarative. La vue de Cloudflare Radar pour AS38345 offre un autre angle sur cette visibilité. Mais aucune de ces observations ne compte les serveurs derrière les adresses, ne mesure leur débit de requêtes, ne vérifie leur santé DNS et ne localise chaque paquet dans une salle donnée. Une route peut conduire à un ensemble d’équipements, à une plateforme mutualisée ou à un point d’entrée qui renvoie vers une autre couche.

Les relations réseau ne suffisent pas davantage à établir l’indépendance physique. Les données sur les voisins d’AS38345 et la cohérence de ses annonces éclairent l’environnement BGP observé. Elles ne révèlent pas les contrats, la séparation des conduites, la propriété des routeurs ni le nombre de salles traversées. Un voisin distinct peut rejoindre le même bâtiment; deux chemins vus depuis l’extérieur peuvent partager une fibre plus près de la destination.

Le contrôle RPKI fournit enfin une information ciblée, à condition de ne pas l’étendre au-delà de ses échantillons. Le préfixe 150.242.156.0/24 est revenu valide dans l’observation RPKI, tandis que 1.8.1.0/24 est revenu inconnu dans l’autre observation. « Inconnu » ne signifie pas qu’un détournement a eu lieu. Deux préfixes ne donnent pas non plus une note permanente à l’ensemble d’un système autonome dont l’état peut évoluer.

Ces limites n’annulent pas la valeur de la preuve réseau. Elles en déterminent la classe. Le routage est un excellent témoin de la surface publique et un témoin médiocre de l’inventaire matériel. Il justifie, avec les autres éléments logiques, un niveau de preuve moyen pour la réalité de l’exploitation. Il ne peut pas relever le niveau de preuve relatif à la capacité physique attribuable, car il manque précisément le lien entre préfixe, service, machine, baie, site, charge et réserve.

Les délégations de domaines montrent une responsabilité technique partagée

Les fiches de la racine donnent un deuxième point d’observation, indépendant des pages commerciales. Les délégations IANA de .baidu, .icbc et .unicom désignent ZDNS comme contact technique. Elles exposent aussi un motif commun de points d’extrémité autoritatifs. Cela confirme que l’entreprise intervient sur des zones de premier niveau visibles mondialement et que certains éléments de son service autoritatif sont effectivement intégrés à la chaîne DNS publique.

Une délégation ne constitue cependant pas un plan d’hébergement. Elle publie les noms et adresses nécessaires à la résolution, pas les machines, les contrats de colocation, la répartition de clientèle ou la capacité de chaque site. Plusieurs domaines peuvent partager des points d’extrémité tout en restant séparés à d’autres couches; inversement, des noms distincts peuvent aboutir à une même plateforme. La délégation permet d’identifier une responsabilité technique et une interface publique, non d’inférer un nombre de serveurs.

Les adresses autoritatives retenues dans l’examen ont été vues depuis plusieurs origines: AS38345, AS4837, AS56048 et AS24149. Les réponses RIPEstat pour 203.99.24.1, 116.169.54.111, 223.72.199.37 et 2401:8d00:2::1 documentent cette diversité d’origines pour les échantillons concernés. Elle peut refléter plusieurs arrangements de connectivité et contribue à la résilience apparente du plan de service.

Il serait pourtant imprudent d’en déduire quatre propriétaires de serveurs, quatre contrats indépendants ou quatre bâtiments séparés. L’origine BGP annonce le chemin vers une adresse; elle ne révèle pas qui possède l’équipement terminal, qui l’administre, où passe le contrat commercial ni quelles conduites sont communes. Une adresse originaire d’un réseau tiers peut héberger une fonction opérée par ZDNS, une fonction mutualisée ou une dépendance dont les responsabilités sont partagées. Les données publiques ne départagent pas ces possibilités.

Les recommandations de la RFC 2182 sur les serveurs DNS secondaires rappellent pourquoi la diversité ne se réduit pas au nombre de noms ou de réseaux. L’objectif opérationnel est d’éviter des dépendances communes capables d’emporter simultanément les autorités d’une zone. Pour juger ZDNS, il faudrait donc relier les délégations à une carte de défaillances: alimentation, transit, logiciel, stockage de zone, clés de signature et contrôle de configuration. Les délégations montrent que le service est utilisé; elles ne montrent pas que chaque couche possède une séparation suffisante.

L’anycast protège contre certaines pannes, sous deux conditions strictes

L’anycast permet à plusieurs sites d’annoncer une même adresse et laisse le routage diriger chaque utilisateur vers un chemin disponible. Dans le cas favorable, un nœud en panne retire proprement son annonce; le trafic converge alors vers les sites survivants. La RFC 4786 consacrée à l’exploitation des services anycast fournit le cadre technique de cette pratique. La géographie déclarée de ZDNS et ses annonces visibles rendent crédible l’usage de ce mécanisme pour une partie du service autoritatif.

Deux conditions commandent pourtant le résultat. D’abord, le nœud défaillant doit cesser d’attirer le trafic. Un serveur qui ne répond plus tout en continuant d’annoncer sa route peut maintenir des utilisateurs dans une impasse. Un retrait trop lent, incomplet ou mal propagé peut prolonger la dégradation. Ensuite, les sites restants doivent disposer de suffisamment de capacité pour reprendre la charge déplacée. L’existence de plusieurs annonces n’apporte aucune réponse chiffrée à cette seconde question.

L’anycast ne répare pas non plus toutes les catégories d’incident. Une donnée de zone corrompue et distribuée partout, une mauvaise configuration mondiale ou une perte de l’état de signature peuvent affecter simultanément plusieurs lieux. Le routage peut déplacer une requête; il ne reconstitue ni une base saine, ni une clé, ni un contrôle logique correct. De même, une attaque ou une surcharge peut se redistribuer sur les sites survivants et consommer leur marge. La redondance géographique n’est utile que si la faute reste locale et si la réserve est réelle.

Le vocabulaire de « nœuds mondiaux » masque souvent ces préconditions. Pour établir qu’un ensemble anycast résiste à la perte de son point principal, il faut un essai daté: identifier le site le plus chargé, retirer ses routes de manière contrôlée, mesurer la convergence depuis plusieurs régions, observer les erreurs et latences, puis vérifier la charge restante. Il faut aussi confirmer que le service revient sans incohérence lorsque le site réintègre l’ensemble. Aucun résultat public complet de cette nature n’est disponible dans les pièces examinées.

La bonne conclusion n’est donc ni que l’anycast garantit la continuité, ni qu’il n’apporte rien. Il constitue un mécanisme de résilience éprouvé pour les pannes localisées et proprement signalées. Dans le cas de ZDNS, il participe au niveau de preuve moyen de l’architecture logique. Mais faute de marge par site et de résultat de bascule, il ne démontre pas la capacité de secours utilisable. Cette dernière reste dans la catégorie de preuve faible.

Les chiffres commerciaux ne mesurent pas la marge après panne

ZDNS publie plusieurs valeurs de performance: 3 000 opérations de signature par seconde, 15 000 paires de clés, entre 16 000 et 27 000 requêtes WHOIS/RDAP par seconde, deux milliards de résolutions DNS par jour et une disponibilité supérieure à 99,999 %. Ces chiffres décrivent l’ambition et l’échelle annoncées de l’offre. Ils peuvent servir de point de départ à une discussion technique, mais ils ne constituent pas une mesure comparable tant que leurs conditions ne sont pas précisées.

Pour interpréter une capacité, il faut connaître la date, le matériel, le jeu de données, la taille des réponses, la proportion de lectures et d’écritures, la distribution géographique, la durée de l’essai et le seuil d’erreur retenu. Une pointe obtenue sur une plateforme isolée n’est pas un débit soutenu en service. Une capacité agrégée de tous les sites n’est pas la capacité qui survit à la perte du plus grand. Un nombre de paires de clés ne dit pas combien sont actives, ni quelle charge opérationnelle leur cycle de vie impose.

Les deux milliards de résolutions quotidiennes illustrent bien le problème. Il s’agit d’une quantité journalière annoncée, pas d’un profil de charge. Le trafic DNS connaît des variations dans le temps, selon les clients et selon les événements. Une moyenne calculée sur vingt-quatre heures ne révèle ni le pic, ni la concentration sur une ville, ni la part absorbée par les caches ou par des services distincts. Elle ne permet pas davantage de comparer directement le service autoritatif avec HTTPDNS ou d’autres fonctions de résolution.

Le pourcentage de disponibilité appelle la même discipline. Une valeur supérieure à 99,999 % n’a de sens opérationnel que si l’on sait quelle interface est mesurée, depuis quels points, sur quelle période et selon quelle définition d’échec. Une disponibilité du plan de données DNS ne prouve pas celle des écritures de registre, de RDAP, de la signature ou du contrôle client. Une moyenne globale peut aussi masquer une interruption régionale si la méthode ne pondère pas les utilisateurs de la même manière.

La pièce Main affirme au moins deux centres indépendants, des sauvegardes, de la surveillance, des contrôles de reprise et une permanence de vingt-quatre heures. Ces engagements décrivent une organisation raisonnable. Le dossier public ne chiffre pourtant ni matériel installé, ni pièces disponibles, ni capacité de ports, ni réserve contre les attaques, ni part du site le plus chargé, ni débit survivant après sa perte. Il manque donc la donnée économique décisive: la différence entre capacité installée et charge de pointe, par fonction et par site.

Sauvegarder et déposer chaque jour ne suffit pas à prouver une restauration

La demande Main indique que les dépôts complets des données de registre sont effectués chaque jour et qu’un dépôt échoué fait l’objet d’une nouvelle tentative. Cette cadence est importante: elle montre qu’une sortie régulière des données a été prévue. Mais le dépôt fiduciaire poursuit une finalité différente de la continuité immédiate du service. Il protège la possibilité de récupérer des données dans certaines circonstances; il ne remplace ni une réplique en ligne, ni une procédure de restauration testée.

Quatre questions restent ouvertes. Le contenu déposé est-il complet par rapport à la base au moment annoncé ? Peut-il être déchiffré avec les éléments disponibles au moment d’un incident ? Peut-il être chargé dans un environnement propre sans dépendance manquante ? Combien de temps sépare le dernier état récupérable de l’incident, et combien de temps faut-il pour revenir à un service utile ? Une fréquence quotidienne ne répond seule à aucune de ces questions.

Le vocabulaire RPO et RTO aide à les séparer. Le premier porte sur la quantité maximale de données que l’on accepte de perdre dans le temps; le second sur la durée nécessaire au rétablissement. Une cadence nominale de dépôt suggère une intention, mais l’objectif réellement atteint dépend du dernier dépôt complet et exploitable. Une reprise annoncée dépend, elle, d’un exercice qui inclut l’accès aux copies, les clés, les logiciels, les contrôles d’intégrité et la remise en service des interfaces.

La base de registre n’est en outre qu’une composante. Il faut considérer les zones DNS publiées, les journaux nécessaires, les configurations, les comptes, les éléments de signature et les dépendances réseau. Une restauration de base peut réussir alors que la publication autoritative reste incohérente. À l’inverse, le DNS peut continuer à répondre avec un état antérieur pendant que les écritures de registre sont interrompues. C’est pourquoi un résultat agrégé de « reprise » ne suffirait pas; chaque fonction doit avoir son objectif et son résultat.

Les sources publiques établissent donc une conception de sauvegarde et de dépôt, pas une démonstration récente de restaurabilité. Pour relever le niveau de preuve, ZDNS devrait fournir un compte rendu daté d’une restauration sur environnement isolé, avec contrôles de complétude, heure du dernier état récupéré, durée des étapes et écarts constatés. Sans cet élément, la protection des données est documentée sur le plan de l’intention, tandis que la reprise atteinte reste non mesurée publiquement.

DNSSEC: des procédures sérieuses, mais pas de résultat récent publié

La gestion des clés concentre des risques différents de ceux d’une simple panne de serveur. L’annexe de gestion KSK de ZDNS décrit un roulement annuel et un roulement d’urgence, l’usage de modules matériels de sécurité, la surveillance par détection d’intrusion, des communications hors bande, des exercices sur table et une démarche de retour d’expérience. Pris ensemble, ces éléments montrent que le risque de signature n’est pas traité comme un simple accessoire du DNS.

Une procédure de roulement annuel répond à l’entretien normal; une procédure d’urgence doit fonctionner dans un contexte dégradé, lorsque la confiance dans une clé, un module ou un site est compromise. Les communications hors bande sont alors importantes parce que le canal habituel peut être indisponible ou suspect. Les exercices sur table permettent de vérifier les rôles et les décisions. Le retour d’expérience doit, en principe, transformer un incident ou un exercice en amélioration concrète.

La limite probatoire reste néanmoins claire. Une conception documentée ne donne pas la date du dernier exercice exécuté, les entités effectifs, la durée de chaque étape, les erreurs rencontrées ni le résultat final. Elle ne dit pas non plus comment chaque client répartit juridiquement et techniquement les responsabilités entre ZDNS, l’opérateur de registre et d’autres intervenants. Une capacité générale de l’entreprise ne signifie pas que toutes les zones utilisent exactement la même organisation.

La reprise DNSSEC doit aussi être reliée aux autres couches. La disponibilité d’un module matériel ne suffit pas si les données nécessaires à la signature sont incohérentes. Une clé de secours ne suffit pas si la modification ne peut pas être publiée ou si les délégations ne sont pas mises à jour comme prévu. À l’inverse, des serveurs autoritatifs accessibles peuvent continuer à servir des réponses dont la validation pose problème. Il faut donc tester un scénario complet, depuis la décision d’urgence jusqu’à la validation externe des réponses signées.

Le niveau de preuve serait renforcé par un exercice daté et observable: déclenchement selon un scénario défini, activation des canaux hors bande, utilisation des rôles de garde, changement contrôlé de clé, publication, vérification depuis plusieurs réseaux et mesure du temps de retour à un état stable. Le document actuel justifie une appréciation positive de la préparation conçue. Il ne permet pas de présenter la reprise DNSSEC comme récemment démontrée.

La localité d’une réponse DNS ne localise ni les données ni les clés

Le DNS autoritatif de ZDNS possède une surface publique mondiale. Avec l’anycast, un utilisateur peut recevoir une réponse depuis un point réseau relativement proche. Cette proximité améliore potentiellement le chemin d’accès et réduit l’exposition à certaines pannes lointaines. Elle ne détermine pourtant pas où résident les données de registre, les journaux, les sauvegardes, les clés ou les fonctions de contrôle.

Cette distinction est centrale pour la souveraineté et la localisation. Le plan de données public répond à une requête DNS; le plan de contrôle décide quelles données seront publiées et comment. Le registre conserve des informations et traite des changements; le système de signature protège l’authenticité cryptographique; les sauvegardes et dépôts suivent encore d’autres chemins. Une réponse obtenue à Francfort pourrait dépendre d’une configuration préparée ailleurs. La présence d’une annonce à Hong Kong ne prouve pas qu’une base de registre ou une clé y soit stockée.

Les huit lignes d’implantation n’offrent pas la matrice juridique et technique nécessaire. Elles ne précisent pas, pour chaque territoire, la fonction traitée, la catégorie de données, la durée de conservation, la copie principale, la copie de secours ou le contrôle administratif. Elles ne disent pas davantage si les journaux d’un site sont centralisés, si les sauvegardes franchissent une frontière ou si les opérations sur clés sont limitées à certains lieux. La géographie du paquet n’est pas la géographie de la donnée.

Un acheteur qui a une exigence de localité doit donc la formuler par objet. Veut-il que les réponses DNS soient servies depuis une région ? Que les données de registre ne soient pas stockées hors d’un territoire ? Que les journaux restent locaux ? Que les clés et les opérations de signature soient confinées ? Que le personnel d’administration se trouve dans une zone donnée ? Chacune de ces demandes appelle une preuve différente et peut conduire à une architecture différente.

La portée mondiale du service reste un atout de disponibilité et de performance, mais elle ne répond pas automatiquement à une exigence de souveraineté. La preuve publique autorise à parler d’un plan de données DNS mondial. Elle n’autorise pas à promettre une résidence locale des données sensibles. En l’absence d’une carte fonctionnelle et contractuelle, la formule la plus exacte est donc la suivante: la réponse peut être proche, tandis que le lieu de stockage, de contrôle ou de reprise reste indéterminé.

Les utilisateurs ne dépendent pas tous de la même couche

Les opérateurs de registre, bureaux d’enregistrement, titulaires de noms, résolveurs récursifs, entreprises clientes du DNS et utilisateurs finaux rencontrent ZDNS à des endroits différents de la chaîne. Pour un opérateur de registre, l’enjeu peut être l’écriture fiable des données, la signature et la publication de la zone. Pour un bureau d’enregistrement, ce sont les interfaces de commande et leurs délais. Pour un résolveur, c’est la disponibilité des serveurs autoritatifs. Pour une entreprise utilisant un service DNS spécialisé, la dépendance peut inclure GSLB ou HTTPDNS.

Cette diversité interdit de convertir un nombre de domaines ou de clients en nombre de personnes affectées. Un domaine peut être peu utilisé ou soutenir un service important; un client peut gérer de nombreuses zones; un résolveur peut mettre certaines réponses en cache. Les conséquences d’une interruption dépendent de sa durée, de la couche touchée, de l’état des caches et des solutions de repli. Aucun total public ne permet une conversion fiable vers un nombre d’utilisateurs ou de services critiques.

Elle interdit aussi d’utiliser un seul indicateur de disponibilité. Si la publication DNS continue tandis que les écritures sont arrêtées, les sites existants peuvent rester accessibles pendant un temps, mais les modifications urgentes ne passent plus. Si RDAP ralentit, la résolution peut demeurer intacte. Si une erreur de signature se propage, les résolveurs validants peuvent échouer même lorsque les serveurs répondent. Chaque scénario dessine une population affectée différente.

Pour apprécier la concentration de risque, il faut donc cartographier les services consommés et leurs dépendances. Un client de registre doit savoir quelles fonctions sont assurées par ZDNS, lesquelles restent sous son contrôle et lesquelles reposent sur un tiers. Un client DNS d’entreprise doit distinguer la publication autoritative du contrôle de trafic ou de la résolution applicative. Un exploitant d’équipement local doit comprendre ce qui continue à fonctionner si la liaison vers les services centraux disparaît.

La documentation publique décrit une offre large, mais elle n’assigne pas toutes ces responsabilités client par client. Cette lacune ne signifie pas que les accords individuels sont insuffisants; elle signifie simplement qu’on ne peut pas généraliser à partir du domaine public. L’évaluation doit rester centrée sur ce qui est prouvé: une activité logique visible, des mécanismes déclarés, une géographie partielle et une attribution physique trop limitée pour mesurer l’impact maximal.

La preuve qu’un acheteur devrait demander avant de signer

Une décision d’achat sérieuse peut transformer les lacunes publiques en demandes vérifiables. La première pièce devrait être une matrice site-fonction à jour. Pour chaque lieu, elle associerait registre, base de données, DNS autoritatif, DNSSEC, WHOIS/RDAP, sauvegarde, dépôt et contrôle. Elle indiquerait aussi l’hôte, le réseau, les dépendances communes et la distinction entre ressources propres, colocation, service mutualisé et équipement installé chez le client.

La deuxième pièce devrait être un inventaire attribuable, sans dévoiler inutilement des détails sensibles. Le nombre de serveurs actifs et de secours, la capacité des ports, les limites d’alimentation pertinentes et les pièces de rechange peuvent être présentés par catégories. Le point essentiel est de séparer l’installation totale du site de l’allocation ZDNS. C’est cette preuve qui empêcherait d’assimiler les 732 baies de M5 Phase III à une capacité de l’entreprise.

La troisième pièce devrait rapprocher charge et réserve. Pour chaque fonction, l’acheteur a besoin de la charge ordinaire, du pic observé, de la capacité soutenable et de la part portée par le site le plus important. La marge doit être exprimée avant et après la perte de ce site. Si les deux milliards de résolutions quotidiennes ou les débits WHOIS/RDAP servent de référence, leur définition et leur fenêtre de mesure doivent être jointes afin de rendre la comparaison possible.

La quatrième pièce devrait être un résultat daté de retrait de routes. L’essai doit montrer la convergence anycast, les erreurs, les latences et la charge reportée. Il doit inclure le cas où un nœud devient malsain, ainsi que le contrôle de son retrait complet. La cinquième devrait être une bascule du site le plus chargé, avec confirmation que les services survivants gardent une marge et que le retour du site ne provoque pas d’incohérence.

La sixième pièce devrait couvrir une restauration réelle de base et de configuration. Elle indiquerait l’état de départ, la copie utilisée, les contrôles de complétude, la perte temporelle atteinte et la durée jusqu’au service utile. La septième porterait sur une urgence DNSSEC exécutée de bout en bout. La huitième vérifierait qu’un dépôt fiduciaire choisi peut être déchiffré, contrôlé et chargé. Ensemble, ces résultats donneraient des RTO et RPO atteints, pas seulement visés.

Enfin, l’acheteur devrait demander la date, le périmètre et les écarts de chaque exercice. Un résultat ancien ou limité à une discussion sur table ne vaut pas une bascule récente. Un succès sans charge comparable à l’usage courant ne mesure pas la réserve. Une attestation de bâtiment ne remplace pas l’allocation du client. La qualité de la réponse tient moins au nombre de documents qu’à la continuité du lien entre fonction, actif, charge, panne testée et résultat observé.

Deux niveaux de preuve à conserver séparément

La présence logique de ZDNS est étayée par plusieurs familles de sources qui se recoupent. Le dossier ICANN décrit des fonctions de registre, DNS, DNSSEC et Proxy. Les pages de l’entreprise détaillent des services autoritatifs et des produits connexes. Les délégations IANA montrent une responsabilité technique sur des domaines de premier niveau. Le routage révèle une surface IPv4 et IPv6 active, et les adresses observées passent par plusieurs systèmes autonomes. Cet ensemble mérite un niveau de preuve moyen pour le réseau et les services logiques.

« Moyen » ne signifie ni complet, ni faible. Les éléments proviennent de registres, de mesures et de déclarations convergentes; ils démontrent davantage qu’une simple promesse commerciale. Mais ils ne fournissent pas le détail par site, la correspondance exhaustive des adresses, la santé des requêtes ou une surveillance continue de chaque service. La note reconnaît donc une exploitation publique visible tout en gardant ses limites.

La situation est différente pour la capacité physique attribuable. Les documents nomment des installations et citent des totaux impressionnants, mais ces totaux appartiennent aux sites hôtes. Aucune part des 732 baies, des équipements énergétiques associés, des quelque 20 000 mètres carrés ou des plus de 1 000 armoires de Huairou ne peut être affectée à ZDNS. Les huit lignes d’implantation ne révèlent ni l’inventaire, ni la charge, ni les ports, ni la réserve. Le niveau de preuve est donc faible.

La capacité de repli utilisable appartient à la même catégorie faible. L’anycast, les sauvegardes, la permanence, les procédures de clés et les dépôts quotidiens constituent des mécanismes plausibles et structurés. Ce sont des conditions nécessaires, non un résultat de résistance. Il manque la perte testée du site principal, la convergence mesurée, la charge survivante, la restauration datée, l’urgence DNSSEC exécutée et les RTO/RPO atteints.

Il serait trompeur de moyenner ces deux notes. Une forte visibilité réseau ne remplit pas des baies de secours; une grande installation hôte ne prouve pas que ZDNS en dispose; une procédure écrite ne mesure pas le temps de reprise. La conclusion la plus fidèle est donc dissociée: preuve moyenne pour la couche réseau et les services logiques, preuve faible pour la capacité physique propre à ZDNS et la marge de bascule réellement disponible.

Ce que les sources publiques permettent finalement d’affirmer

ZDNS apparaît comme un acteur technique réel du registre et du DNS autoritatif, doté d’une présence routée double pile et associé à des délégations visibles mondialement. Son dossier 2026 décrit un éventail large de fonctions et une organisation de continuité comprenant centres indépendants, sauvegardes, surveillance, dépôt des données et gestion d’urgence des clés. Les huit lignes géographiques rendent l’architecture plus tangible qu’une simple formule de couverture mondiale.

Elles ne rendent pas pour autant les actifs comptables. Une implantation nommée est une dépendance; une origine BGP est un chemin; une délégation est une responsabilité logique; une capacité annoncée est une valeur à contextualiser; un certificat d’installation est un total hôte. Pour transformer ces éléments en capacité ZDNS, il faudrait le chaînon absent: allocation nominative, inventaire, charge, réserve et test de perte.

Le cas des 732 baies résume toute l’analyse. Le chiffre est documenté et pertinent parce qu’il renseigne l’échelle d’un site dont dépend le dossier. Il devient faux dès qu’on le présente comme un parc de ZDNS. Il ne permet même pas de fixer une borne basse, puisqu’aucune part réservée n’est rendue publique. La formulation correcte est donc celle d’une dépendance envers une installation de 732 baies, jamais celle d’une capacité ZDNS de 732 baies.

La même discipline doit s’appliquer aux huit implantations et aux performances commerciales. Huit entrées ne garantissent pas huit domaines de panne. Deux milliards de résolutions par jour ne mesurent pas la charge du site principal. Une disponibilité annoncée au-delà de 99,999 % ne révèle pas la méthode ni la marge après bascule. Les mécanismes de reprise décrits inspirent davantage confiance que leur absence, mais ils ne remplacent pas un résultat daté.

Pour un client, la décision peut rester favorable si les preuves non publiques complètent ce dossier. Une matrice site-fonction, un inventaire attribuable et quelques comptes rendus d’exercices suffiraient à lever une grande partie de l’incertitude. Tant qu’ils ne sont pas disponibles à l’examen public, la conclusion doit rester mesurée: ZDNS montre bien son réseau et ses services; elle ne montre pas encore combien de capacité physique lui appartient opérationnellement, ni combien survivrait à la panne qui compte le plus.