Résumé

  • L’avis d’APNIC du 5 août 2026 attribue à un problème de changement de configuration l’indisponibilité de api.apnic.net, de 09 h 52 à 10 h 51 UTC+10, soit 59 minutes.
  • Cinq services sont cités : APNIC Login, APNIC Conference Website, MyAPNIC, APNIC Website et Membership Applications. L’hôte distinct registry-api.apnic.net ne figure pas dans cette liste.
  • La documentation de l’API du registre décrit cet hôte avec trait d’union comme une interface authentifiée permettant de gérer Whois, le DNS inverse et les objets de routage. Les sources ne disent pas s’il fonctionnait ou non le 5 août.
  • Un avis exploitable doit donc associer chaque impact à un identifiant stable, une fonction, une classe d’autorité et un point d’observation. « Non cité », « non observé », « non testé » et « non touché » ne sont pas des synonymes.

Le trait d’union change la portée du fait

L’avis de service du 5 août 2026 est précis sur plusieurs points. Il donne une heure de début, une heure de fin et le fuseau UTC+10. Il relie l’événement à un changement de configuration et nomme l’hôte devenu indisponible. Il indique enfin qu’APNIC améliorait sa surveillance et ajoutait des mesures de sécurité pour les changements de configuration.

Cette publication a de la valeur. Elle offre un événement vérifiable plutôt qu’une formule vague. Elle ne force pas le lecteur à deviner si l’incident a duré dix minutes ou une journée, ni si l’explication relève du réseau, d’un fournisseur ou d’une modification interne.

La précision s’arrête pourtant au seuil de l’autorité. Une API est une forme d’interface ; ce n’est pas une description de ce qu’elle autorise. Elle peut distribuer une information publique, initier une session d’authentification, recevoir un dossier d’adhésion ou modifier un enregistrement qui participe au fonctionnement du registre Internet. La disponibilité de ces fonctions n’a ni la même urgence ni les mêmes conséquences.

Le risque de confusion est concret parce qu’APNIC publie aussi registry-api.apnic.net. Raccourcir les deux noms en « l’API d’APNIC » suffit à transformer, dans une reprise, un incident touchant des portails en panne supposée de l’API du registre. L’erreur inverse consiste à croire que l’absence du second nom garantit son bon fonctionnement.

Le dossier public n’autorise aucune de ces conclusions. Il permet seulement d’écrire que l’avis du 5 août a nommé api.apnic.net et n’a pas nommé registry-api.apnic.net. Le silence ne mesure pas l’état du second service.

Cinq services touchés ne dessinent pas une architecture

La liste publiée réunit des surfaces de nature différente. APNIC Login relève de l’identité. La page actuelle de MyAPNIC présente ce portail sécurisé comme l’endroit où les membres gèrent leurs ressources Internet, leurs enregistrements, la sécurité du routage et du DNS, leurs comptes et leurs contacts. Membership Applications est une chaîne de dépôt de demandes. Les sites APNIC et de conférence fournissent de l’information publique.

Leur présence dans une même liste d’impact n’en fait pas cinq noms d’un système unique. L’avis n’affirme pas que chacun a été totalement indisponible pendant les 59 minutes. Il ne précise pas davantage lequel dépendait directement de l’hôte cité, lequel a subi une conséquence indirecte, ni dans quel ordre les usages sont revenus.

Les publications historiques d’APNIC éclairent la terminologie sans résoudre cette topologie. En 2020, « MyAPNIC is changing » décrivait APNIC Login comme une plateforme de gestion des identités mettant en œuvre l’authentification unique. Le bilan des produits 2021 évoquait l’architecture en microservices de MyAPNIC et la préparation d’une nouvelle plateforme SSO.

Ces textes sont datés. Ils ne constituent pas un schéma des dépendances en production en août 2026. Une hypothèse peut être raisonnable tout en restant une hypothèse. Un compte rendu mature doit distinguer la relation mesurée de celle déduite à partir d’une documentation antérieure.

L’autorité du registre possède une autre adresse publique

Le contraste est établi par le document OpenAPI de l’APNIC Registry API. Il nomme le produit, fixe le serveur à registry-api.apnic.net et documente la gestion des données Whois, du DNS inverse et des objets de routage, ainsi que la consultation des délégations. Les opérations qui modifient un état passent par des tâches asynchrones.

La page des démonstrations de produits d’APNIC 58 renvoie au même hôte et mentionne des mises à jour liées à Whois, au RPKI et au DNS inverse. Il s’agit d’une surface d’autorité que l’on ne peut attribuer à un autre nom par simple ressemblance.

Un portail peut, bien sûr, mener à une opération comparable. Cela ne rend pas identiques le point d’entrée public, la frontière d’authentification, le mode de soumission et la preuve de reprise. C’est précisément la raison pour laquelle une identité de service doit précéder l’inférence sur l’impact.

APNIC sait employer le nom distinct dans ses avis. Le communiqué séparé du 28 août 2026 cite explicitement registry-api.apnic.net parmi les services touchés. Cet autre incident ne permet aucune déduction sur le 5 août et possède sa propre analyse. Il sert ici uniquement de preuve lexicale : le nom avec trait d’union fait bien partie du vocabulaire opérationnel public d’APNIC.

Il faut donc conserver les inconnues. Nous ne savons pas si l’API du registre a été testée, si elle partageait une dépendance avec la configuration modifiée, ni si des opérations Whois, DNS inverse, route ou RPKI ont échoué. Les sources ne font état ni de perte de données, ni de corruption, ni d’accès non autorisé. Une case vide ne doit devenir ni verte ni rouge par habitude.

Nommer le service avant de donner son état

Un participant à une conférence, un candidat à l’adhésion et l’opérateur d’un réseau ne posent pas la même question. Le premier veut lire un programme. Le deuxième veut savoir si son dossier a été reçu. Le troisième veut vérifier qu’un objet de route ou une modification DNS inverse a bien rejoint le registre. Une équipe de sécurité cherchera encore autre chose : l’incident concernait-il seulement la disponibilité, ou aussi l’intégrité ?

La réponse n’exige pas la publication d’une architecture interne. Elle exige un reçu de service court. Pour chaque ligne d’impact : un identifiant stable, le nom d’hôte public, le libellé humain, la fonction et une classe d’autorité. Quelques valeurs contrôlées suffisent : information publique, identité, dépôt de procédure, lecture du registre, écriture du registre.

Viennent ensuite l’état et sa provenance. Un test direct, une alerte de surveillance, une confirmation du responsable et une déduction par dépendance n’ont pas la même force. La relation peut rester « inconnue » sans révéler les adresses internes, les paramètres sensibles ou la conception du basculement.

Les temps doivent eux aussi être reliés au bon objet. Début, détection, atténuation, rétablissement visible et validation interne peuvent différer. Une durée exacte de 59 minutes reste peu utile si personne ne sait à quel service et à quelle opération elle s’applique.

Le même principe vaut pour l’intégrité et la perte de données. L’avis du 5 août ne les mentionne pas. Une structure honnête retient « non observé », « inconnu » ou « sans objet » selon la preuve disponible, au lieu de faire du silence une assurance implicite.

Un petit contrat suffit

APNIC n’a pas à exposer des secrets d’exploitation pour rendre cette identité vérifiable. Un registre public minimal des services peut être plus robuste qu’un grand diagramme : ID, nom d’hôte, fonction, autorité, version, date d’effet et historique des corrections.

Le contrôle devient déterministe. À partir d’un incident et d’un service, un membre peut-il retrouver l’hôte observé, l’autorité concernée, les surfaces listées, les dépendances seulement inférées et les états encore inconnus ? Si la réponse suppose de deviner le sens d’« API », le dossier n’est pas achevé.

APNIC a déjà fourni la fenêtre de 59 minutes, le lien avec le changement de configuration et cinq noms de services. L’étape suivante ne demande pas une promesse plus vaste. Elle demande une ligne d’identité pour chaque ligne d’impact. Un trait d’union peut signaler la frontière ; il ne devrait pas être le seul mécanisme qui la protège.

Sources