Résumé

  • Dans les données recueillies le 3 septembre 2026, environ 1,1 % des enregistrements de délégation sont signalés comme défaillants, contre 10,9 % des détenteurs représentés. Les dénominateurs ne sont pas interchangeables.
  • Le nombre observé passe de 39 814 au début de la série à 1 936 dans sa dernière ligne, datée du 2 septembre 2026. Cette baisse d’environ 95,1 % n’est pas un taux de réparation d’une population suivie à périmètre constant.
  • L’historique distinct des suppressions totalise 27 726 opérations sur des délégations et 9 036 sur des objets de domaine. Retirer une indication devenue fausse et rétablir une réponse utile sont deux résultats différents.

Environ 1,1 % d’un côté, 10,9 % de l’autre. Ces deux proportions peuvent décrire exactement le même ensemble de problèmes sans se contredire. La première porte sur les enregistrements de délégation ; la seconde sur les détenteurs de ressources figurant dans le récapitulatif. C’est ce que montre le fichier de synthèse du DNS inverse d’AFRINIC, recueilli le 3 septembre 2026. Données de synthèse d’AFRINIC

La différence est plus qu’une précaution de statisticien. Un responsable du registre peut mesurer une quantité d’erreurs relativement petite, tandis que les équipes chargées de les corriger doivent coordonner leur action avec un nombre non négligeable de détenteurs. Le travail ne se répartit pas nécessairement comme les enregistrements. Un indicateur qui répond à la question « combien de références sont signalées ? » ne répond pas encore à « qui doit intervenir ? », et moins encore à « quel service a été rétabli ? ».

Le bon dénominateur change le diagnostic

Le récapitulatif comporte deux états, signalé et non signalé, pour trois populations. En additionnant les deux états de chaque population, on obtient les proportions suivantes. Il s’agit d’un calcul sur les catégories du fichier, non d’une mesure indépendante de disponibilité.

Population du récapitulatif Signalés Total des deux états Proportion signalée
Enregistrements de délégation 1 936 172 702 Environ 1,1 %
Objets de domaine 1 358 52 450 Environ 2,6 %
Détenteurs de ressources 194 1 774 Environ 10,9 %

Il serait tentant de transformer la dernière ligne en une affirmation sur tous les membres d’AFRINIC. Le fichier ne l’autorise pas : 1 774 est le total des détenteurs représentés par ces deux états. De même, les 1 358 objets de domaine constituent une catégorie agrégée dont la requête de regroupement n’est pas publiée dans ces données. Rien ne permet d’en conclure que chacun de ces domaines est entièrement impossible à résoudre, ni de reconstituer la distribution des 1 936 références entre eux.

Un domaine peut avoir plusieurs serveurs déclarés. L’un peut ne plus remplir son rôle tandis qu’un autre répond encore. Le décompte d’une référence défaillante ne suffit donc pas à annoncer une interruption complète. À l’inverse, le dernier serveur utilisable peut être décisif même si le nombre d’enregistrements en cause est faible. Pour organiser une intervention, la structure restante compte autant que le volume.

Le portail offre justement plusieurs vues et une table séparée des suppressions. Son intérêt est de rendre ces questions distinctes, plutôt que d’obliger le lecteur à interpréter un compteur unique comme une note générale. Tableau de bord des délégations défaillantes

Une catégorie de contrôle, pas une promesse universelle

Le mot anglais lame demande lui-même une définition. Le RFC 9499 rappelle que son usage a évolué et recouvre différentes défaillances ; il recommande des termes plus précis. Deux chiffres portant ce même nom ne deviennent donc comparables qu’après examen de ce qui est effectivement testé. RFC 9499, section 7

Dans son explication de 2021, AFRINIC inclut l’absence de réponse, une réponse pour le mauvais domaine et une réponse dépourvue du bit d’autorité. Les vérifications sont décrites comme mensuelles pour l’ensemble des serveurs enregistrés, puis quotidiennes pour les cas détectés. Au moins trois positions géographiques sont utilisées ; une seule réponse faisant autorité, depuis l’une d’elles, suffit à ne pas classer le serveur comme défaillant. Ce texte expose une méthode publiée, pas les résultats d’un audit de son exécution actuelle. Méthode publiée par AFRINIC

Ce seuil peut avoir une logique prudente : ne pas supprimer une référence sur la seule base d’un échec depuis un point du réseau. Mais il ne certifie pas tous les usages, tous les types de requêtes ou toutes les situations rencontrées par les clients. Le contrôle du registre et les exigences de disponibilité d’un opérateur ne sont pas le même test. Reconnaître cette différence ne prouve ni la faiblesse du programme ni une violation d’une norme.

Le besoin de maintenance, lui, est réel. Envoyer répétitivement des requêtes vers un serveur incapable de remplir le rôle annoncé consomme du travail et entretient une indication trompeuse. Le RFC 4697 explique plusieurs formes de ce comportement, en distinguant notamment l’échec de tous les serveurs d’une zone et celui d’une partie seulement. Ses exemples ne mesurent pas le trafic d’AFRINIC : ils éclairent le mécanisme, sans chiffrer ici les économies obtenues. RFC 4697

Ce qui disparaît du registre, ce qui revient en service

Prenons une situation hypothétique : deux serveurs sont déclarés pour une zone inverse, mais l’un n’en fournit plus les réponses faisant autorité. Le remettre en état corrige le service de ce serveur. Retirer sa référence, en conservant l’autre, corrige plutôt la description du service disponible. Dans les deux cas, une erreur peut quitter la liste. Le chemin suivi et la capacité restante ne sont pourtant pas identiques.

Si toutes les références sont devenues inutilisables, leur retrait ne crée pas une nouvelle réponse. Il met fin à une indication qui conduisait vers une impasse. Cette clarification peut être utile, mais le détenteur qui a encore besoin du service doit le rétablir autrement. Une absence correctement annoncée est plus honnête qu’un aiguillage erroné ; elle n’est pas une restauration.

La méthode d’AFRINIC distingue précisément l’attribut du serveur et l’objet de domaine. Elle prévoit le retrait de l’attribut concerné et celui de l’objet lorsqu’il ne reste plus de serveur déclaré, après une séquence de contrôles et de notifications pouvant conduire à l’action au trentième jour. Elle indique qu’une recherche sur un domaine supprimé reçoit alors NXDOMAIN. Cette portée limitée ne doit pas être transformée en retrait d’adresses IP, suppression de routes ou sanction d’une organisation. Les données ne montrent pas de tels actes.

Il faut aussi résister à l’erreur inverse : conserver une référence manifestement inutilisable n’est pas nécessairement protéger la continuité. Cela peut simplement reporter sur les résolveurs le coût de découvrir, requête après requête, que le service promis n’existe plus à cet endroit. La qualité du registre comprend cette obligation de ne pas annoncer ce qu’il ne peut plus raisonnablement décrire.

Une baisse ne raconte pas tous les mouvements

La page d’accueil affichait 1 936 délégations défaillantes et une baisse de 95 % lors de la collecte. Le début et la fin du fichier historique sont compatibles avec cet ordre de grandeur : 39 814 au 28 septembre 2018, puis 1 936 au 2 septembre 2026, soit 37 878 de moins et environ 95,1 % de baisse. Ce rapprochement ne démontre pas la formule utilisée par la page d’accueil, ni la stabilité du périmètre sur près de huit ans. Portail statistique ; série historique

La table des suppressions commence plus tard, le 30 mai 2021, et se termine au 31 août 2026. Ses 996 lignes totalisent 27 726 retraits de délégations et 9 036 retraits d’objets de domaine. Sans identifiants individuels, ces sommes ne prouvent pas un nombre d’objets distincts : une réapparition éventuelle ne peut pas être exclue par une addition. Historique des suppressions

Soustraire ces retraits à la baisse du stock pour obtenir les « réparations » serait donc injustifié. Les périodes diffèrent. De nouvelles défaillances peuvent entrer dans le stock pendant que d’autres en sortent. Une configuration corrigée, une liste de serveurs modifiée, une suppression ou une évolution de la couverture observée peuvent changer le total. Ce sont des possibilités à distinguer, pas des causes attribuées à des lignes particulières.

Les dernières observations illustrent le problème : 2 016 le 30 août, 3 354 le 31 août, puis 1 936 le 2 septembre. Aucune ligne ne porte la date du 1er septembre. La baisse finale de 1 418 ne peut être appelée ni 1 418 réparations, ni le résultat d’un seul contrôle. Elle ne s’explique pas davantage par les quatre retraits inscrits dans la dernière ligne de l’autre table. Il manque le lien entre les événements et les objets observés.

Une date absente ne démontre pas non plus un arrêt du contrôle ou du service DNS. Elle décrit la série disponible. Quant aux valeurs nulles de suppression présentes dans le récapitulatif courant, elles ne signifient évidemment pas qu’aucune suppression n’a jamais eu lieu : l’historique distinct en contient. L’échelle temporelle fait partie de la définition d’un chiffre.

Une transparence utile, sans conclusion forcée

Les cinq tables communes aux fichiers CSV téléchargeables et aux données JSON ont été comparées ligne par ligne pour cette analyse. Les deux formats concordent, notamment sur les 2 719 observations historiques et les 996 lignes de suppressions. Cette cohérence facilite la vérification du calcul. Elle ne révèle pas les liens individuels absents des données et ne vaut pas audit des serveurs contrôlés. Archive des données brutes

On peut donc reconnaître plusieurs acquis sans les confondre : un stock observé bien moindre qu’au début de la série, des actions de maintenance publiquement documentées et des représentations cohérentes des agrégats. Aucun de ces acquis n’a besoin de devenir un taux de rétablissement pour être intéressant.

La question de fond est celle du résultat laissé à l’usager. Une indication fausse en moins, un serveur réparé et une zone de nouveau utilisable peuvent être liés, mais ne se remplacent pas. Le registre est mieux évalué lorsqu’on lui reconnaît la valeur d’une maintenance exacte tout en réservant une preuve distincte au service effectivement retrouvé.