Résumé

  • Les mises à jour de la RIPE Database ont échoué par intermittence pendant presque huit heures le 28 octobre, y compris les demandes de DNS inverse.
  • Le suivi de RIPE NCC précise qu’aucune requête échouée n’aurait changé une délégation : certaines ne portaient aucune modification, les autres ont échoué aux tests Zonemaster.

Une fiche d’incident peut raconter deux choses à la fois : le service d’écriture tombe, tandis que l’état public reste stable. C’est la lecture utile du problème survenu chez RIPE NCC le 28 octobre. L’avis initial signalait des mises à jour bloquées et un effet sur des objets de domaine. Le 30 octobre, l’historique de statut a apporté une précision décisive : aucune des requêtes échouées n’aurait changé une délégation inverse.

RIPE NCC situe les défaillances intermittentes entre 11 h 42 et 19 h 40 UTC. Le premier avis d’enquête est arrivé à 20 h 04 CET, un correctif était suivi à 20 h 23, puis l’incident a été déclaré résolu à 20 h 32. Le détail publié deux jours plus tard répartit les requêtes en deux groupes : certaines ne contenaient aucun changement ; les autres échouaient aux contrôles de pré-délégation de Zonemaster.

Une délégation inverse passe par un objet de domaine dans la RIPE Database. Les attributs nserver désignent les serveurs de noms autorisés pour la zone. RIPE NCC s’appuie sur les objets de la base pour produire les zones DNS ; une modification acceptée peut donc finir dans la zone parente et devenir visible aux résolveurs.

Entre l’envoi et cette publication, il y a un contrôle. La documentation de RIPE NCC indique que les mises à jour assorties d’un résultat ERROR ou CRITICAL sont rejetées. Après acceptation, la délégation peut encore mettre jusqu’à 24 heures à apparaître dans le DNS. La chaîne distingue donc la requête reçue, l’objet modifié et la donnée publiée.

L’incident d’octobre a interrompu le traitement des requêtes. Le suivi établit que celles qui ont échoué étaient des opérations sans changement ou auraient été rejetées par le contrôle technique. Cette différence évite de confondre l’indisponibilité d’un formulaire de mise à jour avec une modification de l’état DNS. Pour un opérateur, l’alerte appelle deux vérifications séparées : l’historique de l’objet, puis la délégation dans le DNS.

RIPE NCC n’a publié ni le nombre de requêtes échouées ni la cause technique ; ces éléments permettraient de mesurer l’ampleur et d’expliquer l’interruption.

Sources