Résumé

  • RIPE NCC attribue les échecs intermittents du 28 octobre à une brève coupure du lien du répartiteur principal, suivie d'un basculement. Une erreur de configuration orientait les nouvelles connexions de mise à jour Whois vers une base en lecture seule; les connexions existantes restaient sur la base principale.
  • La plage de défaillance publiée va de 11 h 42 à 19 h 40 UTC. Après vérification, RIPE NCC affirme qu'aucune requête de délégation inverse échouée n'aurait produit de modification : les unes ne changeaient rien, les autres échouaient aux contrôles préalables de zonemaster.

Le trajet des nouveaux arrivants

Un répartiteur de secours peut répondre parfaitement à la question « où envoyer une connexion ? » et se tromper sur la question décisive : « vers quelle base pour cette opération ? ». Le rapport post-incident de RIPE NCC décrit une courte interruption du lien du répartiteur principal. Le secours a pris la main. Une mauvaise configuration a alors dirigé les nouvelles connexions de mise à jour Whois vers la base en lecture seule au lieu de la base primaire. Les anciennes connexions applicatives demeuraient sur la primaire et n'ont pas été touchées.

Cette séparation explique le caractère intermittent du problème sans inventer de pannes aléatoires. La session déjà établie conserve sa route d'écriture; celle qui vient d'arriver trouve une porte fermée. Pour une institution chargée du registre, c'est une différence essentielle : la continuité d'une partie des utilisateurs peut cacher une défaillance systématique du nouveau chemin.

RIPE NCC situe les échecs de mise à jour du 28 octobre entre 11 h 42 et 19 h 40 UTC. L'avis initial signalait des mises à jour non traitées et des objets liés au DNS inverse. Le rapport du 3 novembre apporte la cause technique qui manquait alors. Il ne donne ni le paramètre fautif, ni la répartition des échecs par méthode de soumission, ni le nombre d'objets concernés. Un journal des connexions et des résultats par méthode permettrait de mesurer cette portée.

Le DNS inverse appelle une précision plus sévère. Après examen, RIPE NCC indique qu'aucune des requêtes de délégation inverse échouées n'aurait modifié la délégation. Certaines étaient sans changement; les autres échouaient aux vérifications préalables de zonemaster. Le chemin d'écriture avait bien un défaut. Cette série de requêtes ne fournit pas un cas documenté de zone inverse valide perdue.

Le reçu plutôt que le voyant

La documentation du traitement des objets explique que chaque objet d'un message est traité séparément, avec un accusé de résultat à la fin. Le guide des accusés précise même qu'un HTTP 200 de Syncupdates peut accompagner des opérations individuelles en échec : le détail du reçu décide. Pour l'opérateur, le répartiteur qui répond et la connexion qui tient ne remplacent pas la confirmation de l'écriture voulue.