Summary

  • RIPE NCC indique des échecs intermittents de la base et des délégations inverses jusqu’à 19 h 40 UTC le 28 octobre.
  • La page d’incident affiche une résolution à 20 h 32 CET (19 h 32 UTC) ; le bilan du 30 octobre indique qu’aucune requête échouée n’aurait modifié une délégation.

La première mise à jour de la page d’état décrivait un incident en cours : certaines mises à jour de la base RIPE n’étaient pas traitées et des objets de domaine affectaient aussi le service DNS inverse. L’incident s’est étendu du 28 octobre à 11 h 42 UTC jusqu’à 19 h 40 UTC. RIPE NCC a appliqué un correctif, surveillé le service, puis marqué l’incident résolu à 20 h 32, heure d’Europe centrale.

Le 28 octobre, les deux heures doivent être ramenées au même fuseau. Le calendrier 2026 de la Commission européenne fixe la fin de l’heure d’été au 25 octobre ; l’horodatage de 20 h 32 CET correspond donc à 19 h 32 UTC. L’historique RIPE termine la période affectée à 19 h 40 UTC. L’heure de résolution précède ainsi de huit minutes la fin indiquée.

Deux jours plus tard, le bilan public a précisé le résultat. L’examen des requêtes en échec a montré qu’aucune n’aurait modifié une délégation inverse. Certaines ne contenaient aucun changement ; les autres échouaient aux contrôles préalables de Zonemaster. Le chemin de mise à jour ne fonctionnait pas de façon fiable, mais les requêtes examinées n’avaient pas franchi les contrôles requis pour modifier l’enregistrement.

C’est cette distinction qui compte. Une panne peut interrompre une opération sans changer l’état que cette opération devait contrôler. RIPE NCC indique que la création, la modification et la suppression de délégations inverses échouaient par intermittence ; son examen ultérieur indique que les requêtes concernées n’auraient de toute façon pas changé ces délégations. L’historique fournit les deux constats, sans préciser le nombre de requêtes dans chaque groupe.

RIPE NCC n’a pas précisé si les mises à jour ont repris à 19 h 32 ou à 19 h 40 UTC ; une heure de rétablissement corrigée et normalisée permettrait de savoir si l’écart vient de l’affichage ou si l’incident a été clos avant la fin de la période affectée.

La chronologie est instructive. À 20 h 04, RIPE NCC signalait des mises à jour non traitées et des objets de domaine qui affectaient le DNS inverse. À 20 h 23, un correctif était en place et la surveillance avait commencé. À 20 h 32, l’incident était déclaré résolu. Le 30 octobre, RIPE NCC a ajouté l’explication portant sur les requêtes. Les trois premières entrées décrivent le retour du service ; la dernière précise l’effet sur l’état du registre.

La chronologie passe des mises à jour en échec au correctif et à la surveillance, puis à l’examen des requêtes. Publier leur issue après réessai ou reprise montrerait si des changements valides restaient à traiter après le rétablissement.

Documents : chronologie de l’incident RIPE NCC ; historique d’état et mise à jour du 30 octobre; calendrier 2026 de l’heure d’été de la Commission européenne.