Résumé

  • Du 27 janvier 2026 à 15 h 45 au 28 janvier à 9 h 45, UTC+10, un changement involontaire de configuration Cloudflare a soumis le RDAP d’APNIC à un contrôle d’intégrité de navigateur plus strict.
  • APNIC estime qu’environ 10 % des requêtes portant un User-Agent différent des chaînes courantes de navigateurs ont été bloquées pendant ces dix-huit heures.
  • La défense contre les robots abusifs et les dénis de service est légitime ; l’apparence d’un navigateur ne prouve cependant ni l’identité, ni le mandat, ni l’innocuité du demandeur.
  • Un test ponctuel réalisé en septembre a obtenu le même JSON RDAP avec quatre profils de User-Agent. Il décrit un instant et un chemin, pas l’ensemble du service ni le passé.
  • Un reçu par classe de clients, reliant la décision de l’edge à l’arrivée à l’origine, suffit à rendre ce risque contrôlable sans publier les règles de sécurité.

La bonne défense mérite un meilleur périmètre

Il faut commencer par ce qui plaide en faveur d’APNIC. Un service public de consultation du registre ne peut pas accepter un volume illimité en supposant que toute automatisation est bienveillante. RDAP est utile précisément parce qu’il peut être automatisé ; cette qualité attire aussi des collectes agressives, des comportements répétitifs et des attaques destinées à épuiser la capacité. Protéger la disponibilité fait partie de l’exploitation du registre.

La présentation de l’infrastructure publiée par APNIC en 2020 place Cloudflare devant les services RDAP d’APNIC et des registres nationaux associés. Le prestataire répartit la charge, apporte une protection contre les attaques par déni de service et relaie les requêtes vers l’infrastructure hébergée dans Google Cloud. La décision prise à cette frontière appartient donc à la chaîne de service vécue par l’utilisateur, même si elle précède l’application RDAP.

La documentation de Cloudflare donne également une raison rationnelle au contrôle concerné. Browser Integrity Check recherche des en-têtes HTTP souvent associés au trafic indésirable et peut présenter un défi lorsqu’un User-Agent est absent ou atypique. Comme signal parmi d’autres, cette information peut contribuer à défendre un site. La documentation indique aussi que le mécanisme peut être désactivé ou borné par des règles de configuration.

Le choix n’oppose donc pas un Internet sans filtrage à un registre fermé. Il porte sur le périmètre : une heuristique élaborée autour du trafic web interactif peut-elle décider seule de l’admission à un protocole dont les clients ordinaires sont des logiciels non interactifs ? L’incident montre qu’en janvier la réponse opérationnelle a été, involontairement, oui.

Le compte rendu fixe une frontière, pas une population

L’annonce de service d’APNIC note un début le mardi 27 janvier 2026 à 15 h 45 et une fin le mercredi 28 janvier à 9 h 45, en UTC+10. Elle désigne RDAP comme service touché et une durée de dix-huit heures. Son explication tient en deux éléments : une modification de la configuration Cloudflare a renforcé sans intention le contrôle d’intégrité du navigateur ; environ 10 % des requêtes RDAP dont le User-Agent ne correspondait pas aux User-Agent usuels des navigateurs ont été bloquées.

Cette formulation doit être gardée entière. « Environ » interdit une fausse précision. « Des requêtes » ne veut pas dire des utilisateurs. Une application peut émettre des milliers de requêtes, plusieurs applications peuvent partager une bibliothèque, et un opérateur peut réessayer après un refus. On ne connaît ni le nombre de clients distincts, ni leur rôle, ni les décisions éventuellement retardées.

Le texte ne donne pas non plus les codes HTTP, le contenu de la réponse, les chaînes exactes, les points de présence ou le seuil de la règle. Il ne permet pas d’affirmer que tous les scripts ont échoué ou qu’un outil déterminé a été touché. Compléter ces blancs par intuition transformerait un compte rendu d’incident en récit inventé.

Ce que l’on sait est déjà important. Le tri s’est produit avant que le comportement normal du service soit visible pour une partie des demandes. Une mesure prise seulement à l’origine aurait pu ne pas voir ces requêtes. Inversement, une sonde portant les attributs attendus d’un navigateur aurait pu annoncer un service sain. La fraction manquante se situait entre deux observateurs.

Un protocole de machines ne possède pas de navigateur canonique

APNIC présentait RDAP en 2021 comme du JSON transmis par HTTP ou HTTPS, facilement analysable par une machine. Un même client peut traiter les réponses de la plupart des services RDAP et tirer parti du cache HTTP. Cette description n’est pas celle d’un site web dont l’utilisateur normal serait toujours une personne devant une interface graphique.

RFC 9082 définit des requêtes REST uniformes pour les domaines, serveurs de noms, entités, réseaux IP et systèmes autonomes. RFC 7480 précise l’usage de HTTP. Les applications exécutées dans un navigateur font bien partie des clients possibles—les dispositions relatives au partage entre origines l’anticipent—mais elles n’épuisent pas l’ensemble. Un outil en ligne de commande, une bibliothèque, un système d’inventaire ou un flux de traitement d’abus n’a aucune raison protocolaire de se déguiser en Chrome, Safari ou Firefox.

Le contrôle de janvier n’a donc pas simplement distingué un navigateur correct d’un navigateur défectueux. D’après le compte rendu d’APNIC, il a distingué des chaînes ressemblant aux navigateurs courants de celles qui ne leur ressemblaient pas. Or les secondes peuvent être la forme la plus honnête d’un client RDAP.

Un service peut limiter le débit de ces clients. RFC 7481 reconnaît explicitement le déni de service comme un enjeu et laisse aux exploitants la possibilité de ralentir des demandeurs. RFC 7480 recommande le code 429 pour une limitation de débit et prévoit que le client réduise ses demandes et respecte Retry-After lorsqu’il est fourni. Ces mécanismes ont une vertu : un programme peut interpréter la contrainte et adapter son comportement.

Il serait excessif d’en conclure que chaque blocage du contrôle Cloudflare devait obligatoirement être un 429. Une règle antirrobot et une limite de débit sont des décisions différentes ; l’annonce ne donne pas le détail des réponses. Elle suffit cependant à montrer pourquoi les résultats doivent être observés par classe de clients et pourquoi la décision de l’edge ne doit pas être confondue avec celle de l’origine.

Le User-Agent ne porte pas le mandat de celui qui l’envoie

Dans RFC 9110, User-Agent contient des renseignements sur le logiciel qui émet la requête. La chaîne sert à l’interopérabilité, au diagnostic et à l’adaptation des réponses. Elle est déclarée par le client. Elle peut être raccourcie, omise dans certaines conditions ou imitée. La spécification envisage elle-même qu’un agent se fasse passer pour un autre.

Cette chaîne ne dit pas qui commande le logiciel. Elle ne prouve pas qu’il s’agit d’un membre d’APNIC, d’une équipe réseau, d’un chercheur ou d’un collecteur abusif. Elle ne définit ni un droit d’accès, ni un objectif, ni un rythme acceptable. Une allure de navigateur n’accorde aucun mandat ; le nom explicite d’un script n’en retire aucun.

Le signal n’est pas sans valeur. Une chaîne anormale, mise en relation avec le débit, la réputation, la séquence des requêtes et d’autres observations, peut aider à évaluer un risque. Le problème apparaît lorsque le signe de logiciel devient la preuve décisive de légitimité. L’autorité du demandeur n’est alors plus examinée : elle est remplacée par un costume.

Cette substitution modifie les incitations. Le développeur d’un outil légitime apprend qu’une identification honnête réduit sa disponibilité. Il copie alors une chaîne de navigateur. Le robot hostile peut faire exactement la même chose. À mesure que chacun imite la forme autorisée, le signal perd l’information que le filtre voulait exploiter. La règle ne sélectionne plus les bons acteurs ; elle sélectionne ceux qui ont compris la règle.

Quatre réponses égales ne font pas une garantie

Une observation limitée a été réalisée le 5 septembre 2026 sur https://rdap.apnic.net/ip/202.12.29.0. Quatre requêtes GET à faible cadence demandaient application/rdap+json. La première ne fournissait pas explicitement de User-Agent. La deuxième utilisait un User-Agent d’automatisation qui en indiquait la finalité, la troisième curl/8.7.1, et la quatrième portait une chaîne de type Mozilla/Safari.

Les quatre réponses étaient des HTTP 200 de type application/rdap+json. Chacune comptait 3 857 octets et produisait la même empreinte SHA-256 : d6983abd9266f7ac6d6a23b8b5cf67c186aae673a64030fc04e4e457837bb853. Les en-têtes confirmaient le passage par Cloudflare.

Il s’agit d’un bon résultat et d’une preuve actuelle. Sur ce point d’accès, depuis ce chemin réseau, à cet instant et à ce rythme, les quatre présentations ont abouti au même objet RDAP. Il serait raisonnable de dire que l’observation ne reproduit pas la différence de janvier.

La portée s’arrête là. L’essai ne couvre pas toutes les requêtes RDAP, les méthodes, les origines réseau, les régions, les points de présence ou les cadences. Il ne reconstitue pas la configuration historique. Il ne garantit pas qu’une future modification conservera cette égalité. Un canari devient utile par sa répétition et sa datation, non parce qu’une exécution unique serait universelle.

Le reçu doit montrer le passage, non la serrure

APNIC n’a pas à publier l’expression exacte de son pare-feu, ses seuils, ses listes de réputation ou une recette de contournement. Un reçu de service peut rester beaucoup plus mince. Il doit répondre à la question que l’utilisateur ne peut pas résoudre seul : quelles classes légitimes atteignent un résultat RDAP lisible à travers la chaîne réellement déployée ?

Quatre canaris contrôlés par le registre forment un minimum pratique : User-Agent absent, automatisation nommée, client courant en ligne de commande et navigateur. Pour chacun, conserver séparément la décision de l’edge et la présence à l’origine. Noter la classe du statut, le type de contenu, la latence et, lorsqu’il s’agit de limitation de débit, l’éventuelle instruction Retry-After. Un blocage avant l’origine ne doit pas disparaître d’un tableau construit uniquement avec les journaux du serveur RDAP.

Le reçu doit également porter la lignée du changement : identifiant de configuration, propriétaire, relecteur, périmètre, heure de déploiement, heure de retour arrière et heure de validation. Il n’est pas nécessaire de révéler la règle sensible pour démontrer qu’un contrôle orienté navigateur n’est pas appliqué par erreur à l’ensemble du nom d’hôte ou du chemin RDAP. Une part agrégée des décisions par classe peut compléter la preuve si elle n’expose pas les seuils.

APNIC dispose déjà d’un vocabulaire de mesure côté utilisateur. Son rapport du deuxième trimestre 2025 définit le succès d’un contrôle RDAP par une réponse HTTP sans erreur obtenue en moins de cinq secondes et calcule un rapport entre tests réussis et tests totaux. Ajouter une dimension de classe de clients rendrait cette perspective plus fidèle au protocole.

La mise à jour du premier trimestre 2026 affirme que tous les services essentiels du registre ont atteint ou dépassé 99,99 % de disponibilité. Son résumé ne fournit pas le dénominateur nécessaire pour rapprocher cette phrase de l’incident de janvier. Il ne faut pas l’accuser d’être fausse. Il faut demander le raccord : quels résultats de l’edge, quelles classes de clients et quels intervalles entrent dans la mesure ?

Une conclusion bornée reste une conclusion

Rien dans les sources examinées ne montre une panne actuelle, un préjudice chiffré pour des opérateurs identifiés ou le blocage de tous les clients automatisés. Le test de septembre ne comble pas les détails absents du compte rendu. Rien ne permet non plus de dire qu’APNIC ou Cloudflare a délibérément ignoré une norme.

APNIC parle d’un effet involontaire. Cette qualification déplace utilement le débat : le sujet n’est pas l’intention, mais la capacité d’une configuration générique à déborder son contrat de service. Dans la doctrine d’un registre, l’apparence d’une participation ne vaut pas mandat. Dans la pratique d’un protocole, l’apparence d’un navigateur ne vaut pas autorisation.

Préserver la protection et rendre cette différence observable sont deux objectifs compatibles. Le reçu par classe de clients est l’objet commun qui les relie.

Sources

  1. APNIC, annonce de service du 28 janvier 2026
  2. APNIC Blog, nouvelle infrastructure pour servir RDAP
  3. APNIC Blog, RDAP est-il prêt à remplacer whois ?
  4. APNIC Blog, disponibilité des services de registre au T2 2025
  5. APNIC Blog, mise à jour du secrétariat au T1 2026
  6. Cloudflare Docs, Browser Integrity Check
  7. RFC 7480, usage de HTTP dans RDAP
  8. RFC 7481, services de sécurité pour RDAP
  9. RFC 9082, format des requêtes RDAP
  10. RFC 9110, sémantique de HTTP