Résumé

  • RIPE NCC situe l’incident NRTM entre 00 h 06 UTC le 2 août et 12 h 30 UTC le 4 août : 60 h 24 de retard pour les mises à jour du DNS inverse. Les mises à jour en attente ont été traitées après le correctif.
  • À RIPE 93, Ed Shryane a relié la panne au décodage de caractères échappés, qui a introduit une ligne supplémentaire dans un objet RPSL. L’équipe a conservé ces caractères tels quels et vérifié les objets récents ainsi que la fin du flux.

Analyse

Une modification d’objet pouvait être enregistrée dans la base RIPE sans apparaître dans le DNS mondial. Le maillon rompu était le service Near Real Time Mirroring de RIPE NCC, utilisé aussi par le système de provisionnement du DNS inverse. La base et le service publié n’avançaient donc plus au même rythme.

Dans un message du 6 août à son groupe de travail sur la base de données, RIPE NCC fixe l’intervalle d’impact : de 00 h 06 UTC le 2 août à 12 h 30 UTC le 4 août. Le calcul donne 60 heures et 24 minutes. Les changements de DNS inverse ont été retardés pendant cette période; le message précise que toutes les mises à jour en attente ont été traitées après l’application du correctif. La page d’état de RIPE NCC a qualifié l’incident de majeur et a ensuite indiqué le retour du DNS inverse à l’état opérationnel.

Lors de la session Database de RIPE 93, l’ingénieur Ed Shryane a décrit une cause étonnamment petite pour une chaîne aussi longue. Le logiciel décodait des caractères échappés dans un objet RPSL et ajoutait un saut de ligne. L’objet devenait syntaxiquement invalide, alors que RIPE NCC l’avait accepté. Le RFC 2622 décrit la syntaxe de RPSL : dans ce format, les lignes portent une partie de la structure.

La réparation a consisté à ne plus décoder ces caractères et à les laisser tels quels. L’équipe a aussi repris les 1 000 derniers objets du flux, contrôlé leur analyse et vérifié que la réponse NRTM se terminait par un pied de page cohérent. Réparer la syntaxe ne suffisait pas; il fallait aussi s’assurer que les enregistrements suivants pouvaient être lus jusqu’au terme du flux.

La chaîne de dépendance tient en quatre étapes : objet de base, flux miroir, provisionnement du DNS inverse, publication dans le DNS. Une transformation de texte au premier maillon a retardé le dernier. Les sources publiques donnent la durée et le rétablissement, mais aucun nombre de miroirs ou de domaines touchés; ce décompte changerait l’évaluation du périmètre.

Sources

transcription de la session RIPE 93 Database; page de la session RIPE 93; état de l’incident RIPE NCC; message de RIPE NCC au groupe de travail Database; RFC 2622.