Résumé

  • RIPE-400 estimait qu’environ 11 à 13 % des serveurs de noms examinés en mars 2006 étaient défaillants selon son test. Ce taux de configuration n’était pas une mesure de l’impact pondéré par les requêtes.
  • Les débats de 2009 ont montré qu’un délai d’attente et une réponse nette mais non autoritative ne produisaient pas le même coût, et que l’envoi d’un courriel ne prouvait ni sa prise en charge ni la réparation.
  • Le rapport annuel 2009 de RIPE NCC dit que les contrôles périodiques ont continué alors que les alertes par courriel ont cessé. La bonne unité d’évaluation est donc une chaîne complète, de la détection au résultat utilisateur.

Deux décisions, pas un seul interrupteur

Il serait tentant de résumer l’épisode ainsi : RIPE NCC a mesuré des délégations DNS défaillantes, les opérateurs n’ont pas toutes corrigées, puis le programme a été arrêté. Le rapport annuel 2009 interdit ce raccourci. Il affirme que les contrôles périodiques ont continué et que la décision a porté sur l’arrêt des alertes par courriel.

La distinction révèle la vraie nature du problème. Une mesure peut rester utile quand une intervention fondée sur cette mesure ne produit pas assez de valeur. Inversement, une alerte peut être parfaitement remise sans que la mesure qui l’a déclenchée représente un risque important. Le système de 2006 à 2009 testait simultanément trois choses : la précision du diagnostic, la qualité du chemin de contact et la capacité du message à provoquer une amélioration.

RIPE-400, publié en janvier 2007, partait d’un relevé réalisé en mars 2006. Environ 11 à 13 % des serveurs de noms présents dans les délégations d’IANA vers RIPE NCC étaient classés comme défaillants. La méthode exigeait que le nom du serveur fournisse une adresse A ou AAAA, puis qu’une requête SOA en UDP, sans récursion, envoyée à cette même adresse obtienne une réponse autoritative comportant un seul SOA. Les échecs étaient vérifiés cinq fois sur dix jours.

Le service prévu devait répéter l’opération chaque mois, utiliser le champ RNAME du SOA et les données du mainteneur pour contacter les responsables, limiter l’envoi à un message par serveur, publier des statistiques et réexaminer périodiquement son efficacité.

Cette procédure établissait un défaut observable. Elle ne démontrait pas encore que tous les défauts avaient le même poids, que l’adresse trouvée menait à la personne qui contrôlait la délégation, ni que la correction d’un enregistrement améliorait l’expérience d’un résolveur.

Changer de dénominateur

Une enquête de configuration compte des enregistrements. Un utilisateur rencontre des requêtes. La différence commande toute l’analyse.

Un serveur incorrect peut ne recevoir presque aucun trafic si d’autres serveurs répondent ou si le cache absorbe les demandes. Un autre peut se trouver sur un chemin très sollicité et ajouter un délai à chaque tentative. Dans l’inventaire, chacun vaut un défaut. Dans l’expérience de l’utilisateur, leurs conséquences n’ont rien d’équivalent.

La discussion technique d’avril 2009 a également relevé que la méthode de RIPE-400 ne distinguait pas les délais d’attente des autres réponses qui ne remplissaient pas le critère autoritatif. Pour un résolveur, attendre jusqu’à l’expiration d’un délai puis réessayer n’est pas la même chose que recevoir rapidement une réponse non autoritative et passer à une autre cible. Les deux états signalent une incohérence possible, mais pas la même latence ni la même charge de reprise.

À RIPE 59, l’étude « Falling Trees » a relié les constats de configuration à une heure de trafic observé sur un serveur maître de DNS inverse. Sur plus de 16 millions de paquets analysés, elle a estimé environ 0,3 % d’enregistrements NS défectueux, environ 0,8 % de situations A/AAAA causant un échec de recherche, et près de 1 % de requêtes observées affectées. Ces valeurs sont des estimations de cette expérience, pas des constantes générales. La présentation précisait qu’elle ne modélisait pas le cache et que certaines classifications travaillaient par adresse IP plutôt que par couple IP-domaine.

Son apport était de confronter la prévalence à l’usage.

Le courriel n’était qu’une étape

En février 2009, RIPE NCC expliquait que les réponses à un petit lot de notifications envoyé en octobre 2008 avaient fait apparaître des défauts dans les sondes et dans l’interprétation des résultats. Le système a été corrigé avant la reprise de petits lots à partir du 26 février. La réaction des destinataires servait donc aussi à améliorer le diagnostic.

La suite de la chaîne restait incertaine. Un champ de contact prouve qu’une adresse existe, pas qu’une équipe responsable l’observe. La remise d’un message ne prouve pas qu’il mérite la priorité. À RIPE 58, des participants demandaient en outre comment un opérateur pouvait reproduire exactement le contrôle après correction ; les outils disponibles utilisaient des tests légèrement différents.

La présentation de RIPE 59 observait que les serveurs défaillants non utilisés avaient tendance à rester tels quels, alors que ceux qui servaient effectivement étaient corrigés. Cela peut traduire une allocation rationnelle de l’attention selon l’impact. Cela ne prouve pas qu’un courriel précis a causé la réparation.

La discussion s’est donc déplacée vers la proportionnalité. Les minutes de RIPE 59 relèvent le risque que des relances à des destinataires qui ignorent activement les messages s’apparentent à du harcèlement. Une proposition d’octobre recommandait de remplacer la diffusion massive par un rapport annuel aux LIR et des contacts ciblés sur les cas les plus dommageables. Une option plus coercitive allant jusqu’au retrait de la délégation a été débattue ; les sources examinées ne l’établissent pas comme politique adoptée.

Évaluer l’intervention, pas le volume de messages

Un dispositif moderne commencerait par séparer les catégories : délai d’attente, réponse explicitement non autoritative, échec de résolution d’adresse et autorité incohérente. Des observations répétées distingueraient l’incident fugitif du défaut persistant.

Il est ensuite nécessaire d’estimer l’exposition, avec des données de trafic bornées et respectueuses de la vie privée lorsque le droit et la technique le permettent. Le but n’est pas de publier un classement, mais de réserver l’interruption humaine aux situations qui provoquent une latence ou des échecs significatifs.

Chaque étape de l’intervention doit garder son propre état : alerte créée, remise, reconnue, attribuée, modification effectuée, nouveau test réussi. Puis il faut une comparaison : contact échelonné selon la gravité, groupe témoin approprié, ou cohortes semblables recevant des messages différents. Les résultats sont le délai de réparation, la récidive et l’évolution des échecs pondérés par les requêtes. Sans comparaison, une amélioration avant-après peut venir d’une maintenance indépendante ou d’un changement de sonde.

Dans cette architecture, le courriel cesse d’être le produit. Les cas à faible exposition peuvent rester visibles dans un rapport annuel ou un tableau de bord. Les cas à fort impact reçoivent un diagnostic ciblé, une reproduction exacte et un chemin de vérification. Si aucun canal ne modifie les résultats, le programme doit changer de forme plutôt qu’augmenter le nombre de messages.

La documentation actuelle consultée décrit des contrôles des serveurs de noms lors de la création ou de la modification d’une délégation DNS inverse. Elle ne permet pas d’affirmer ce qu’est devenu aujourd’hui l’ancien programme périodique. La conclusion demeure historique : en 2009, RIPE NCC a maintenu la mesure et arrêté les alertes.

Sources