Résumé

  • Le fichier CSV de la carte actuelle contient 27 ccTLD et le code de la page déclare chaque ligne hébergée ; 24 délégations seulement portent « afrinic » dans un nom de serveur.
  • Les trois autres, .so, .ng et .ml, possèdent chacune une adresse IPv4 et IPv6 située dans les préfixes NS2 qu’AFRINIC publie.
  • Un reçu daté par zone rendrait ce rapprochement vérifiable sans confondre adresse, contrat, localisation du nœud, disponibilité et maîtrise du contenu DNS.

Une carte publique doit pouvoir simplifier sans demander un acte de foi. Celle d’AFRINIC annonce un service DNS faisant autorité pour plus de 25 ccTLD africains. Le jeu de données auquel elle renvoie en énumère exactement 27. Dans le code du navigateur, chaque pays provenant du CSV reçoit directement l’état isHosted: true, puis la longueur de la liste devient le chiffre présenté.

À première vue, la délégation DNS semble confirmer 24 lignes. Les noms ns-bi.afrinic.net ou ns-ci.afrinic.net rendent le prestataire visible avant même de résoudre une adresse. Trois pays cassent cette méthode commode. Aucun serveur délégué pour la Somalie, le Nigeria ou le Mali ne contient le mot afrinic dans son nom. Ce n’est pourtant pas une absence de service.

Les adresses rétablissent les trois lignes

Pour .so, le serveur d.nic.so répondait, lors de la capture du 12 septembre, aux adresses 196.216.168.54 et 2001:43f8:120::54. La fiche de délégation de l’IANA donne les mêmes valeurs. La forme locale du nom est conservée ; l’infrastructure apparaît dans l’adresse.

Le Nigeria suit le même modèle avec ns5.nic.net.ng : 196.216.168.41 et 2001:43f8:120::41. Au Mali, d.nic.ml mène à 196.216.168.37 et 2001:43f8:120::37. Là encore, les fiches IANA correspondent au relevé DNS.

Le guide de déploiement d’AFRINIC permet de terminer la démonstration. Il attribue le service NS2 à l’AS37177 et indique les préfixes anycast 196.216.168.0/24 et 2001:43f8:120::/48. Les trois paires d’adresses appartiennent à ces plages. Plus largement, chacune des 27 zones du CSV présentait au moins une adresse dans chacun des deux préfixes au moment de l’observation.

Le chiffre 27 est donc techniquement défendable. Mais sa preuve ne tient pas dans le fichier affiché : elle résulte d’une jointure entre l’inventaire, la délégation, la résolution d’adresse et la documentation du service. Le lecteur voit le résultat, pas le chemin.

Un nom n’est pas une attribution d’opérateur

L’épisode illustre une règle utile pour les infrastructures partagées. Un nom d’hôte peut rester sous la convention du gestionnaire national tout en pointant vers un service secondaire commun. Imposer le nom du fournisseur dans chaque serveur n’améliorerait ni la résilience ni l’autorité DNS. Cela créerait surtout une dépendance d’étiquetage.

L’adresse apporte une autre forme de preuve, mais elle ne doit pas devenir un raccourci excessif. Appartenir à un préfixe publié ne révèle pas le lieu physique du nœud anycast ayant répondu. Cela ne mesure ni disponibilité, ni latence, ni respect d’un engagement de service. Cela ne publie pas le contrat entre le gestionnaire du ccTLD et AFRINIC.

Surtout, cela ne transfère aucune maîtrise sur la zone. La page historique du programme DNS d’AFRINIC le dit nettement : le registre fournit un service esclave ou secondaire, reproduit les données du serveur maître ou primaire et ne gère ni la zone ni son contenu. Le service technique n’est pas un mandat sur le domaine national.

Le fichier public ne porte pas sa propre preuve

Le CSV ne contient que le pays, le ccTLD et un drapeau. Il ne date pas chaque ligne et ne donne ni serveur délégué, ni adresse, ni préfixe correspondant, ni historique. Le code considère toutes les lignes comme hébergées. Ce choix rend l’interface légère, mais il empêche de distinguer une relation confirmée aujourd’hui d’une entrée en cours de mise à jour.

Si un gestionnaire renomme un serveur tout en conservant le même service, une vérification fondée sur le texte peut annoncer à tort une disparition. Si une adresse quitte un préfixe, la carte ne montre pas si l’entrée est suspendue, retirée ou simplement en cours de correction. L’absence d’historique oblige à recommencer toute l’enquête.

Il suffit pourtant d’un reçu de zone hébergée, ouvert depuis chaque ligne. Il réunirait le ccTLD, le nom délégué utilisé pour le service, les adresses IPv4 et IPv6 observées, le préfixe reconnu, la source, l’horodatage et un état : actif, en attente, retiré ou temporairement indisponible. Les dates de première observation, de dernière confirmation et de changement permettraient de suivre une transition sans effacer le passé.

Ce reçu n’a pas à dévoiler des coordonnées de site, des contacts internes ou des clauses commerciales. Il doit seulement expliquer pourquoi la zone entre dans le total public et comment contester ou corriger cette conclusion.

La meilleure défense de la carte actuelle est qu’elle vise un public qui n’a pas besoin d’un rapport DNS complet. Elle affiche un nombre compréhensible, et ce nombre a passé le contrôle figé. Mais un niveau de détail repliable ne compromettrait pas cette simplicité. Il éviterait surtout que les trois cas les plus instructifs soient pris pour des erreurs.

.so, .ng et .ml montrent comment fonctionne réellement ce service : le nom reste local, l’adresse rejoint une infrastructure commune, et AFRINIC résume la relation dans un inventaire. La confiance ne vient pas de l’uniformité des noms. Elle vient de la possibilité de refaire la jointure.

Sources