Résumé

  • Dans ses notes du 19 août, AFRINIC fait d’un contrôle IPv6 des serveurs du ccTLD une conclusion sur tous les sites placés sous ce domaine. Le transport DNS ne détermine pourtant pas la famille d’adresses contenue dans la réponse.
  • Un résolveur récursif à double pile suffit à montrer la limite du raisonnement. La récursion exclusivement en IPv6, sans autre accès à une autorité nécessaire, reste un cas réellement contraint ; aucune panne n’a été mesurée ici.

Entre le téléphone et le registre, il y a une machine que la phrase oublie : le résolveur. Elle peut répondre au téléphone en IPv6 et interroger un serveur faisant autorité en IPv4. La route prise par la demande de l’usager n’impose pas celle des recherches effectuées pour son compte.

Cette liberté explique pourquoi une nouvelle mesure d’AFRINIC mérite une formulation plus précise, non pourquoi il faudrait l’abandonner.

L’observatoire du déploiement IPv6 et DNSSEC a élargi son examen aux domaines nationaux. Les notes de la version 2.14.0, datées du 19 août 2026, vérifient trois choses : la présence d’une adresse IPv6, une réponse par ce transport et une réponse DNS effective. Distinguer ces étapes est utile. Le commentaire va plus loin : des serveurs du registre injoignables en IPv6 rendraient également tout ce qui est situé sous le domaine injoignable en IPv6.

Même en limitant le propos aux noms réellement délégués sous ce ccTLD, cette conséquence ne suit pas. La hiérarchie DNS oblige à trouver les bonnes autorités. Elle n’oblige pas tous les échanges de résolution, puis la connexion au site, à emprunter une seule version d’IP.

La délégation et la connexion ne sont pas une seule liaison

La RFC 3596, publiée en octobre 2003, distingue le protocole qui transporte la question des adresses que les enregistrements décrivent. Une demande envoyée en IPv4 peut obtenir des données AAAA, donc des adresses IPv6. À l’inverse, des données A peuvent voyager dans une réponse DNS en IPv6.

Il faut toutefois éviter un raccourci supplémentaire : le ccTLD ne fournit pas nécessairement l’adresse finale du site. Le résolveur peut obtenir du parent une délégation, joindre ensuite l’autorité du domaine enfant par un transport disponible, puis y récupérer l’enregistrement AAAA. Il renvoie cette information au client, qui établit sa propre connexion IPv6 vers un service accessible.

Ce scénario suppose des délégations utilisables, des données valides et un chemin fonctionnel vers l’application. C’est un contre-exemple architectural, pas une mesure effectuée dans un pays. Il n’a pas besoin d’une réponse déjà en cache. Le recours à IPv4 lors d’une étape autoritative n’empêche pas, à lui seul, la dernière connexion d’utiliser IPv6.

La RFC 4472, document informatif d’avril 2006, reprend cette indépendance. La machine qui pose une question à une autorité DNS n’est souvent pas celle qui utilisera l’adresse obtenue. Les capacités du résolveur intermédiaire font donc partie de l’explication.

Le résultat inverse n’est pas davantage garanti : une adresse AAAA publiée ne prouve pas qu’un serveur web répond. Le routage, le filtrage, l’écoute du service et le trajet jusqu’à celui-ci restent à examiner. La réussite d’une requête au ccTLD ne mesure pas ces éléments.

Le cas difficile demeure

Un résolveur qui effectue toute sa récursion uniquement en IPv6 peut se heurter à une autorité nécessaire disponible seulement en IPv4. Sans transfert utilisable vers un service à double pile, traduction ou autre voie, la difficulté est réelle. Elle dépend d’une configuration précise ; elle ne frappe pas automatiquement tous les clients qui emploient IPv6.

La RFC 3901, recommandations de septembre 2004 sur le transport DNS IPv6, distingue la recherche directe du transfert vers un résolveur récursif à double pile. Son conseil historique n’est pas une nouvelle interdiction, en 2026, des clients exclusivement IPv6. Un service accessible au client en IPv6 et un résolveur n’employant qu’IPv6 vers l’amont sont deux situations différentes.

AFRINIC apporte elle-même des limites utiles : les contrôles partent d’un seul endroit en Afrique ; une réponse DNS est plus probante qu’un ping ; la version 2.15.0 examine aussi de grandes réponses signées et la cohérence des délégations. Cette progression renforce l’outil sans transformer ses résultats en test universel.

Nous examinons en septembre le commentaire d’une fonction publiée en août. Les anciens chiffres des notes ne sont pas des sondages réalisés pour cet article. Aucune panne nationale, défaillance actuelle d’un serveur ou vérification complète de l’usager jusqu’au site n’est établie. Il reste à nommer correctement la dépendance que le contrôle observe.