Résumé

  • Le journal cumulatif APNIC du 3 novembre enregistre le 2 novembre 2026 à 23:38:39 UTC le passage de 202.89.220.0–202.89.223.255, soit 1 024 adresses, de Indonesia Network Information Center/dnk-id à Indonesia Network Information Center/SCBD-ID. Le fichier étendu du 3 novembre contient un /20 entier ; celui du 4 novembre le répartit en un /21 et deux /22. Le /22 transféré porte un identifiant de titulaire distinct dans ce dernier fichier.
  • Le WHOIS public pour le /22 présente un objet fils exact SCBD-NET, modifié à 23:38:47 UTC, puis l’ancien parent DNK-NET venu d’IDNIC. La réponse RDAP pour ce même /22 ne présente que le parent /20. Huit secondes séparent les deux horodatages administratifs ; elles ne mesurent pas un délai de propagation.

La ressource sort d’un cadre ancien sans effacer ce cadre. Avant la division, 202.89.208.0/20 représente 4 096 adresses dans le fichier statistique du 3 novembre. Le lendemain, l’original quotidien inscrit 2 048 adresses dès 202.89.208.0, puis 1 024 dès 202.89.216.0 et 1 024 dès 202.89.220.0. Les trois intervalles ne se chevauchent pas. Ils remplissent exactement le /20 de départ. La dernière tranche correspond à l’intervalle nommé dans le journal de transfert.

Dans le fichier du 4 novembre, les deux tranches conservées portent A92AB1BD, la dernière A92B4C5C. Le mode d’emploi des fichiers étendus précise qu’un même identifiant opaque regroupe les ressources d’un titulaire dans un fichier, mais que la chaîne n’est pas garantie stable d’une version à l’autre. Il faut donc comparer les trois lignes entre elles dans la même photographie du 4 novembre. L’identifiant ne révèle aucun nom à lui seul ; le journal de transfert nomme le nouveau destinataire.

Ce journal donne aussi une heure. Son entrée à 23:38:39 UTC indique Indonesia Network Information Center/dnk-id comme source et Indonesia Network Information Center/SCBD-ID comme destinataire. Selon la définition APNIC du format, la ligne documente la ressource transférée et ses deux parties. Elle ne publie pas le prix, les contrats ni un changement de route. La date 20050419, toujours attachée aux trois morceaux du fichier quotidien, est la date historique de délégation. La norme statistique décrit ces fichiers comme des états présents dépourvus d’historique transactionnel. Prendre 2005 pour l’heure du transfert de 2026 reviendrait à lire la date de naissance à la place du changement d’adresse.

Le WHOIS est plus explicite. À la recherche de la première tranche, il présente le /21 exact DNK-NET. Pour la deuxième, il présente le /22 exact DNK-NET. Pour la tranche transférée, il présente le /22 exact SCBD-NET. Les trois objets fils portent la même heure de dernière modification : 23:38:47 UTC. Huit secondes plus tôt, le journal a inscrit le transfert. Les réponses WHOIS conservent aussi, après le fils, le /20 DNK-NET marqué source: IDNIC, dont la dernière modification date de 2011. L’historique et le nouvel état cohabitent dans la sortie, à condition de lire les deux objets.

La réponse RDAP raccourcit cette histoire au mauvais endroit. La requête de la première tranche, celle de la deuxième et celle du bloc transféré aboutissent toutes à 202.89.208.0–202.89.223.255, le parent DNK-NET. Leurs avis déclarent une origine IDNIC et une copie partielle chez APNIC. Les objets fils APNIC visibles dans le WHOIS n’apparaissent pas dans ces résultats RDAP. Cela décrit les réponses publiques constatées, pas le fonctionnement d’un routeur ni le traitement réel d’un signalement d’abus.

APNIC recommande dans son format de journal de vérifier la possession du destinataire en consultant le Whois Database. La recommandation devient un petit examen d’orientation : il faut choisir le WHOIS qui montre le fils, puis reconnaître que le parent IDNIC n’est pas l’unique réponse. Un outil qui interroge RDAP seul et retient le premier objet ne voit pas la tranche transférée. Le registre possède les pièces du puzzle ; son interface publique n’en livre pas toujours le bon morceau.