Résumé

  • Selon APNIC, un pare-feu réseau a détecté une panne matérielle puis redémarré le 28 août 2026, entre 19 h 10 et 19 h 18 en UTC+10.
  • La liste des services touchés réunit MyAPNIC, l’API du registre, Orbit, FTP, les protocoles de provisionnement et de publication RPKI, ainsi que l’accès RPKI par rsync.
  • APNIC ne signale ni perte de données, ni corruption, ni double mise à jour, ni incident de sécurité. L’avis ne fournit pas non plus l’état des tâches, des files d’attente ou de la cohérence de chaque interface.
  • Un relevé minimal par classe d’opération permettrait de distinguer réception, acceptation, validation, visibilité, reprise et vidage des files sans publier les demandes des membres ni le plan du réseau.

Une petite panne traverse plusieurs mondes

L’avis de service du 28 août fixe le cadre sans ambiguïté : début à 19 h 10, fin à 19 h 18, fuseau UTC+10. L’un des pare-feu réseau d’APNIC a détecté une panne matérielle et a redémarré. L’organisation attribue à cet événement des interruptions sur six surfaces nommées. Elle enquête avec le fournisseur du matériel et travaille à améliorer le basculement du trafic entre pare-feu.

Le flux des annonces de service conserve le même intervalle et la même cause déclarée. Rien dans ces textes n’autorise à parler d’un arrêt total du registre. Rien n’établit non plus qu’un enregistrement, un message ou un objet RPKI ait disparu. « Interruption » décrit ici un effet d’accès ; ce mot ne précise ni le taux d’erreur, ni la durée propre à chaque service, ni le sort d’une opération déjà reçue.

La brièveté de l’incident joue en faveur d’APNIC. Pourtant, plus l’événement est court, plus une frontière devient facile à manquer : le trafic peut revenir avant que l’application sache ce qu’elle a fait de la requête qui a perdu sa connexion.

L’API connaît des tâches, pas seulement des réponses HTTP

APNIC explique dans la présentation de son API de registre que celle-ci sert à consulter les délégations et à gérer des objets Whois, des enregistrements DNS inverses, des ROA et des objets de route. Certaines opérations ne lisent donc pas un état : elles le modifient.

Deux précisions de cette documentation changent la manière de lire un incident réseau. D’abord, les lots concernant le DNS inverse et la gestion abstraite des routes prennent effet de manière transactionnelle lorsque cela est possible. Ensuite, toutes les mises à jour sont asynchrones. Une soumission produit un objet de tâche ; le client interroge ensuite ce lien jusqu’au résultat.

Une coupure peut survenir avant la réception, après la réception mais avant la création de la tâche, après l’acceptation de la tâche ou après la validation de la modification. Ces quatre positions ne réclament pas la même conduite. Dans un cas, il faut soumettre de nouveau. Dans un autre, il vaut mieux interroger la tâche existante. Dans un troisième, une nouvelle écriture risque seulement de brouiller un résultat déjà acquis.

Ce ne sont pas des affirmations sur l’incident du 28 août. L’avis ne dit pas qu’un tel scénario s’est produit. Ce sont les états que l’architecture publique de l’API rend possibles et que l’heure de fin du pare-feu ne peut départager.

MyAPNIC complète la question. APNIC indique que les fonctions de l’API correspondent à celles du portail : une modification effectuée d’un côté devient visible de l’autre. Voir à nouveau une page du portail à 19 h 18 prouve qu’une lecture est possible. Cela ne prouve pas automatiquement qu’une tâche antérieure est terminée, que les deux représentations ont convergé ou que la file d’attente est vide.

Pour un membre, la phrase utile serait donc plus précise : aucune tâche n’a été admise pendant la période ; ou bien les tâches admises ont été vérifiées et peuvent être interrogées sans nouvelle soumission ; ou encore certaines restent en cours. Le retour du réseau est une condition de ces réponses, pas leur substitut.

Orbit et FTP ne se réparent pas de la même façon

Orbit est présenté comme une plateforme de communication de la communauté et une évolution des listes de diffusion. On y lit des archives, on y publie des messages et on peut recevoir des échanges par courrier électronique. L’avis cite Orbit sans distinguer ces chemins.

Une lecture d’archive qui échoue se répète aisément. Une publication dont le résultat est incertain doit d’abord être recherchée dans l’archive, sous peine de créer un doublon. Un courriel retardé obéit encore à une autre horloge. Le fait que l’avis n’en dise rien ne prouve aucune perte ; il laisse simplement ces questions ouvertes.

FTP représente une surface de distribution publique. Le format d’échange des statistiques des RIR prévoit des fichiers lisibles par tous, sans contrôle d’accès, avec des noms persistants pour la version la plus récente et des moyens de validation. Là aussi, plusieurs états sont possibles : fichier intact mais téléchargement impossible, nouvelle version retardée, pointeur latest encore ancien, ou publication et lecture revenues ensemble.

L’avis ne permet d’en retenir aucun. Le relevé proportionné n’aurait pas besoin de révéler les serveurs : « interruption de lecture seulement », « publication différée », « objet inchangé », « pointeur vérifié » ou « état inconnu » suffiraient pour guider une nouvelle collecte.

RPKI : un seul sigle, quatre interfaces

La déclaration des pratiques de certification d’APNIC sépare le protocole de provisionnement, le protocole de publication, l’accès au dépôt par rsync et l’accès par RRDP. Les sens de circulation diffèrent. Un titulaire échange avec son autorité de certification ; un moteur publie des objets signés vers un dépôt ; une partie utilisatrice récupère ensuite ces objets.

Les RFC confirment cette topologie fonctionnelle. La RFC 6492 encadre les requêtes et réponses du provisionnement des certificats de ressources. La RFC 8181 décrit les opérations de publication. La RFC 8182 définit RRDP au-dessus de HTTPS.

L’avis du 28 août rassemble « RPKI Provisioning and Publication protocol », puis cite « RPKI rsync ». Il ne nomme pas RRDP. Cette absence n’est ni un certificat de disponibilité, ni une preuve d’indisponibilité. Elle interdit simplement de transformer la liste en déclaration générale sur tout le dépôt RPKI.

Chaque interface appelle une vérification différente. Une requête de provisionnement a-t-elle reçu sa réponse correspondante ? Une publication a-t-elle été validée ou doit-elle être rejouée ? Le jeu d’objets présenté par rsync est-il revenu dans un état cohérent ? RRDP a-t-il été observé, et son état appartient-il au périmètre public de l’incident ?

Une interruption de collecte ne signifie pas davantage que les routeurs aient aussitôt perdu leur politique courante. Les validateurs travaillent à partir de données récupérées et validées localement, selon leurs propres cycles. Aucun élément public n’indique ici l’âge des caches, l’expiration d’objets ou une conséquence de routage.

L’horloge commune reste utile

Il serait injuste d’exiger d’un avis rapide qu’il contienne le résultat complet d’une enquête. APNIC a publié un déclencheur matériel, les services concernés, le travail avec le fournisseur et la direction du correctif de basculement. Huit minutes après le début, la priorité était de rétablir le trafic, pas d’exposer les détails de chaque file applicative.

L’horloge commune sert donc bien à quelque chose. Elle indexe les observations des utilisateurs, mesure l’incident d’infrastructure et alimente les statistiques de disponibilité. APNIC a d’ailleurs montré dans son bilan de disponibilité du quatrième trimestre 2025 qu’elle distinguait les sondes externes des mesures de réussite des requêtes vues par les utilisateurs, tout en évitant de compter deux fois la même panne.

Cette discipline offre la solution. L’alerte initiale peut rester courte. Un objet de clôture, publié après réconciliation, peut préciser ce qui est revenu avec le trafic et ce qui a continué à se vider ou à se vérifier.

Un relevé d’opérations, sans dossier privé

Le relevé minimal garde un identifiant unique pour l’incident et sa fenêtre de huit minutes. Il ajoute, pour chaque interface, le sens et la classe de travail : écriture du registre, consultation ou sondage de tâche, publication ou lecture communautaire, génération ou récupération de fichier, provisionnement RPKI, publication RPKI, récupération rsync et, si APNIC choisit de l’observer publiquement, RRDP.

Les états peuvent rester sobres : non reçu, rejeté avant admission, accepté, validé, annulé, en attente, visible dans telle représentation, sûr à rejouer, à interroger plutôt qu’à resoumettre, non observable. Il faut séparer le rétablissement de l’interface du vidage de sa file et enregistrer les incohérences éventuelles entre MyAPNIC, l’API et les sorties publiques.

Des bandes de volume protègent mieux les utilisateurs que des requêtes brutes. Les preuves internes peuvent rester des références ou des empreintes. Les identités des membres, le contenu des objets, les adresses privées, les identifiants du matériel et les détails exploitables du réseau n’ont pas à être publiés.

Une valeur inconnu vaut mieux qu’une conclusion fabriquée. Si l’analyse ultérieure montre qu’une tâche d’abord classée inconnue avait été acceptée et menée à terme, la correction doit conserver l’état précédent et sa date.

À 19 h 18, APNIC a pu fermer l’incident du pare-feu. Une écriture de registre se ferme lorsqu’elle est reçue, décidée et rendue visible selon son contrat. Une publication RPKI se ferme lorsqu’on sait ce que le dépôt a accepté. Une lecture se ferme lorsqu’un consommateur obtient une représentation vérifiée. Une seule horloge peut les relier. Elle ne peut pas leur donner le même sens.

Sources