Résumé

  • L’UIXP répertorie séparément « AFRINIC - DNS - AFDSP » sous AS37177 et « AFRINIC - DNS - DotARPA » sous AS37181. Le guide d’AFRINIC attribue à chacun son propre couple de préfixes IPv4 et IPv6.
  • NS2 fournit du DNS secondaire à des zones, notamment des ccTLD africains ; DotARPA relève d’une infrastructure distincte de DNS inverse. Une preuve obtenue pour l’un ne doit pas être transférée à l’autre.
  • Les pages d’annuaire, RDAP et PeeringDB établissent des identités et une surface d’interconnexion. Elles ne prouvent ni l’annonce actuelle des routes, ni l’usage des serveurs de routes, ni l’instance qui répond, ni la latence, la disponibilité ou la résilience.
  • Le reçu pertinent doit suivre chaque service de bout en bout : ASN, préfixes annoncés, mode de peering, état de santé, espaces de noms servis, point de mesure, instance répondante et heure d’observation.

Un même point d’échange, deux identités réseau

L’information la plus solide tient d’abord dans la formulation de l’UIXP. La page précise que les réseaux énumérés sont directement connectés au LAN de peering. Pour AS37177, elle affiche AFDSP, une politique ouverte et l’année 2025 dans le champ d’ancienneté. Pour AS37181, elle affiche DotARPA avec les mêmes indications générales. Ce sont bien deux raccordements attribués à la même institution, mais deux raccordements nommés séparément.

L’UIXP ajoute une réserve opératoire essentielle : il faut consulter son looking glass pour savoir si un réseau utilise les serveurs de routes et quels préfixes il annonce. Autrement dit, la page d’annuaire n’ambitionne pas de servir de table BGP. Elle renseigne l’existence d’une interface d’échange ; elle ne décrit pas l’état instantané des sessions, les filtres appliqués, les voisins qui apprennent une route ou l’étendue de sa propagation.

PeeringDB donne un autre angle sur la même surface. Dans les données capturées, les deux ASN apparaissent au point d’échange identifié par ix_id 422. AS37177 dispose d’adresses de LAN de peering se terminant par .5 en IPv4 et ::5 en IPv6. AS37181 utilise les terminaisons .6 et ::6. Ces adresses permettent aux routeurs de se joindre sur la plateforme d’échange. Elles ne sont pas les adresses de service anycast annoncées au reste du réseau.

Cette différence entre adresse de peering et préfixe de service n’est pas un détail de présentation. Une interface visible permet de demander : « avec qui ce réseau peut-il échanger des routes ici ? » Le préfixe annoncé permet de demander : « quel service devient-il atteignable par ce chemin ? » Si les deux valeurs sont confondues, une présence administrative peut être prise pour une disponibilité technique.

Une carte peut donc raisonnablement dessiner un point AFRINIC à Kampala. Un dossier d’exploitation doit conserver deux lignes.

La chaîne NS2 commence à AS37177

Le guide de déploiement d’AFRINIC relie NS2 à AS37177, au préfixe IPv4 196.216.168.0/24 et au préfixe IPv6 2001:43f8:120::/48. La page du programme présente ce réseau comme une infrastructure anycast destinée au service secondaire de ccTLD africains et à d’autres besoins DNS régionaux.

Le mot « secondaire » fixe le partage d’autorité. Dans sa documentation sur AfDSP, AFRINIC explique que le service reçoit les données depuis le serveur primaire de la zone. Il ne décide pas du contenu de cette zone et ne le gère pas. Son rôle n’en est pas mineur : une copie faisant autorité, distribuée par anycast, peut ajouter un chemin de réponse et isoler certains incidents. Mais la capacité à répondre ne transfère pas la maîtrise de la zone à l’opérateur de la copie.

Ce point distingue également cette enquête d’un inventaire des zones hébergées. Compter les ccTLD associés aux préfixes NS2 répond à la question « quelles zones semblent utiliser ce service ? ». Examiner UIXP répond à une autre question : « l’instance rattachée à cet échange annonce-t-elle ces préfixes, et quelles requêtes l’atteignent effectivement ? » Le total des zones et l’état d’une instance sont deux mesures différentes.

Les enregistrements RDAP relient AS37177 et les blocs publiés au dossier organisationnel d’AFRINIC. Ils stabilisent l’identité administrative du service. Ils ne montrent pas que 196.216.168.0/24 ou 2001:43f8:120::/48 était annoncé à l’UIXP au moment de la capture. Ils ne disent pas non plus si l’annonce était reçue par un serveur de routes, un pair bilatéral ou les deux, ni quel exemplaire du service a traité une requête.

Le passage de l’identité à l’observation comporte donc plusieurs jointures : ASN vers préfixe, préfixe vers session, session vers politique de route, route vers instance anycast, instance vers processus DNS et processus vers zone demandée. La page publique rend la première jointure lisible ; elle ne prétend pas fermer les suivantes.

DotARPA suit une autre chaîne

Pour DotARPA, le guide indique AS37181, 196.216.169.0/24 en IPv4 et 2001:43f8:110::/48 en IPv6. Les valeurs ressemblent à celles de NS2, mais ne les recouvrent pas. Un chiffre change dans le préfixe IPv4, un groupe change dans le préfixe IPv6, l’ASN change et la fonction change. Une procédure qui agrégerait ces champs sous une seule étiquette « DNS AFRINIC » perdrait précisément les informations nécessaires au diagnostic.

AFRINIC rattache ce service à l’infrastructure de DNS inverse décrite par le RFC 5855. Ce texte réserve des identités de serveurs dédiées aux arbres IN-ADDR.ARPA et IP6.ARPA. La séparation réduit les dépendances communes : une difficulté touchant un autre service DNS ne doit pas forcément perturber l’infrastructure inverse. Une identité de routage distincte rend cette frontière visible jusque dans l’interconnexion.

Il faut toutefois résister à une extrapolation inverse. La présence d’AS37181 à l’UIXP ne signifie pas que toute requête inverse émise en Ouganda aboutit sur cette instance. Le DNS suit des délégations, des renvois et des caches. L’anycast ajoute le choix d’instance par routage. Le nom interrogé, l’état du cache du résolveur, les routes qu’il reçoit et la santé applicative de l’instance participent tous au résultat.

DotARPA ne doit pas non plus être assimilé au programme de copies de serveurs racine. AFRINIC décrit ce dernier comme une activité de facilitation : l’organisation hôte du serveur racine reste l’opérateur de la copie. Les deux programmes peuvent viser une meilleure distribution de fonctions DNS critiques, mais ni l’autorité ni l’exploitation ne se transfèrent d’un programme à l’autre.

Les données RDAP et PeeringDB concernant AS37181 ont donc la même force, et la même limite, que pour AS37177. Elles authentifient une association publique entre une identité, des ressources et un point d’échange. Elles ne remplacent pas une observation BGP ou DNS.

Avec l’anycast, le lieu est une propriété mesurée

Dans un service anycast, plusieurs instances annoncent le même espace d’adresses. Le routage choisit l’instance atteinte depuis une origine donnée. Cette architecture rend possible une distribution mondiale sans demander au client de sélectionner lui-même un site. Elle rend aussi dangereuse une phrase trop courte comme « le DNS est désormais local ».

Local peut d’abord signifier que le matériel ou la machine virtuelle se trouve dans le pays. Il peut ensuite signifier que l’ASN est raccordé au point d’échange national. Il peut vouloir dire que les préfixes sont appris par un réseau local. Enfin, il peut signifier qu’une requête envoyée depuis un résolveur déterminé reçoit effectivement la réponse de cette instance. Ces quatre affirmations ne sont pas équivalentes.

Le RFC 4786 insiste sur le rapport entre routage et santé applicative. Une route BGP peut rester visible alors que le démon DNS ne répond plus correctement. L’opérateur doit donc relier le signal de santé de l’application à un retrait de route ou à un mécanisme qui empêche l’instance défaillante d’attirer le trafic. À l’inverse, une application saine peut rester inutilisée par un réseau si la politique de routage préfère un autre chemin.

Le routage anycast ne garantit pas davantage la proximité géographique. Il optimise selon les informations et politiques BGP disponibles, non selon une promesse de distance physique. Un résolveur ougandais peut être conduit ailleurs ; un résolveur extérieur peut atteindre l’instance ougandaise. Pour savoir ce qui se passe, il faut observer depuis plusieurs points.

Le RFC 7094 traite précisément cette nécessité de mesure distribuée. Un looking glass décrit la vision d’un collecteur. Une sonde DNS décrit le trajet et la réponse depuis son propre réseau à un instant donné. Ni l’un ni l’autre ne suffisent seuls à conclure sur toute une région. Une série de mesures, avec un identifiant d’instance ou un moyen fiable de l’inférer, transforme l’affirmation de localisation en résultat vérifiable.

AFRINIC expose des objectifs de performance et de résilience pour son programme. L’architecture rend ces effets plausibles. Le paquet de sources étudié ici ne comporte pourtant pas de mesure avant/après propre au raccordement UIXP, ni de série démontrant le basculement ou la disponibilité. La conclusion correcte n’est donc pas que le déploiement est inutile. Elle est que l’objectif, la présence réseau et le résultat mesuré appartiennent à trois registres différents.

L’exploitation est partagée, elle aussi

Le guide de déploiement décrit un hôte capable de BGP, deux réseaux séparés — gestion et peering — et une appliance virtuelle dont la base publiée comprend deux processeurs virtuels, quatre gigaoctets de mémoire et dix gigaoctets de disque. Ce cahier des charges décrit ce qu’AFRINIC demande à un site hôte. Il ne révèle pas la topologie exacte de l’installation ougandaise : une machine ou deux, redondance ou non, serveur physique partagé ou non.

Les obligations sont réparties. L’hôte fournit l’infrastructure, l’alimentation et la connectivité ; il maintient les conditions de disponibilité et prévient AFRINIC des interruptions. AFRINIC conserve la maintenance logicielle et la configuration, prend en charge la sécurité, coordonne BGP, surveille la santé du service et participe au dépannage.

Cette répartition est normale, mais elle impose une journalisation plus fine que le nom d’un nœud. Si le processus DNS tombe alors que le préfixe reste annoncé, la chaîne santé-retrait mérite d’être examinée. Si le service fonctionne mais qu’un pair local n’apprend pas la route, l’attention se déplace vers la session, le serveur de routes, les filtres ou la politique du pair. Si AS37177 répond et AS37181 non, le problème ne peut être qualifié correctement par un simple état « AFRINIC DNS : en ligne ».

L’unité de preuve doit suivre l’unité de contrôle. Le diagnostic a besoin du service, de l’ASN, de la famille d’adresses, de la méthode de peering, du signal de santé, de l’instance répondante et de l’acteur responsable de chaque transition.

Deux reçus plutôt qu’une épingle

Un reçu public minimal pourrait commencer par les identifiants stables. Pour NS2 : AS37177 et ses préfixes IPv4/IPv6 publiés. Pour DotARPA : AS37181 et son autre paire. Il devrait conserver à part les adresses du LAN de peering UIXP. Puis il indiquerait, pour chaque famille d’adresses, si le préfixe attendu est visible, depuis quel collecteur, via un serveur de routes ou une session bilatérale, et à quelle heure.

La partie DNS nommerait la classe de service ou les espaces de noms vérifiés, l’état de santé de l’application et l’identifiant de l’instance observée. La partie mesure enregistrerait le point de vue, le mode de résolution, le nom et le type de requête, le code de réponse, le délai et l’horodatage. Un condensat de la série permettrait de vérifier que la synthèse renvoie au même jeu d’observations.

Ce reçu ne chercherait pas un champ magique. Le statut « mis en service » ne prouve pas la route actuelle. La route ne prouve pas la santé DNS. Une réponse correcte ne prouve pas que toutes les zones attendues sont chargées. Un bon délai depuis une sonde ne prouve pas un gain régional. La valeur vient de l’enchaînement explicite, non de la force apparente d’une seule donnée.

Les sources publiques permettent déjà une affirmation utile et circonscrite : deux identités réseau d’AFRINIC, affectées à deux services DNS distincts, sont répertoriées comme directement connectées à l’UIXP. Elles ne permettent pas encore d’affirmer que toutes les requêtes pertinentes restent en Ouganda, ni de chiffrer un gain de performance ou de résilience. Une telle affirmation pourrait être démontrée. Elle devrait alors être accompagnée de deux reçus, car l’échec de l’un ne dit rien automatiquement sur l’autre.

Sources

  1. Guide AFRINIC de déploiement DNS anycast : https://dns.afrinic.net/deployment-guide/
  2. Programme DNS d’AFRINIC : https://dns.afrinic.net/
  3. Réseaux raccordés à l’UIXP : https://www.uixp.co.ug/networks
  4. Services et serveurs de routes de l’UIXP : https://www.uixp.co.ug/services
  5. Service DNS secondaire AfDSP : https://afrinic.net/dns-support.html
  6. Programme de copies de serveurs racine : https://afrinic.net/root-server-copy.html
  7. RFC 5855 : https://www.rfc-editor.org/rfc/rfc5855.html
  8. RFC 4786 : https://www.rfc-editor.org/rfc/rfc4786.html
  9. RFC 7094 : https://www.rfc-editor.org/rfc/rfc7094.html
  10. RFC 1034 : https://www.rfc-editor.org/rfc/rfc1034.html
  11. RDAP AFRINIC, AS37177 : https://rdap.afrinic.net/rdap/autnum/37177
  12. RDAP AFRINIC, AS37181 : https://rdap.afrinic.net/rdap/autnum/37181
  13. RDAP, 196.216.168.0/24 : https://rdap.afrinic.net/rdap/ip/196.216.168.0
  14. RDAP, 196.216.169.0/24 : https://rdap.afrinic.net/rdap/ip/196.216.169.0
  15. RDAP, 2001:43f8:120::/48 : https://rdap.afrinic.net/rdap/ip/2001:43f8:120::
  16. RDAP, 2001:43f8:110::/48 : https://rdap.afrinic.net/rdap/ip/2001:43f8:110::
  17. API PeeringDB, AS37177 : https://www.peeringdb.com/api/netixlan?asn=37177
  18. API PeeringDB, AS37181 : https://www.peeringdb.com/api/netixlan?asn=37181