Summary

  • Les conditions de transfert d'APNIC font payer les frais au titulaire APNIC qui envoie des ressources à un membre d'un autre RIR. APNIC efface alors de sa base Whois les objets associés, s'il y en a : sous-attributions, routes et domaines.
  • Le nouveau titulaire apparaît au registre destinataire, tandis que les anciennes instructions publiques conservées par APNIC disparaissent. Le dossier de cession doit donc inventorier ces objets avant la clôture.
  • Une route Whois indique le préfixe et son AS d'origine. Un objet de domaine porte la délégation DNS inverse. Ces deux fiches ont des lecteurs et des responsables différents.

Le prix du bloc occupe généralement la première page du dossier. Chez APNIC, la phrase décisive se trouve plus bas, dans les conditions de transfert. Pour une sortie d'un compte APNIC vers un membre d'un autre registre Internet régional, tous les objets Whois liés aux ressources transférées sont supprimés de la base APNIC. Le texte cite les sous-attributions, les objets route et les objets domain. Le compte APNIC paie les frais de transfert. Une fois l'opération terminée, l'ancien titulaire perd ses droits et le nouveau est enregistré. La propriété administrative change de main; le contexte opérationnel exige une autre passation.

L'expression « tous les objets associés » interdit de traiter Whois comme une simple fiche portant le nom du propriétaire. Un bloc peut comporter des enregistrements qui disent qui utilise une sous-plage, quel AS est censé annoncer une route et quels serveurs reçoivent les questions de DNS inverse. Ces lignes intéressent des équipes différentes : exploitation réseau, clients, réponse aux incidents et DNS. Avant de promettre une date de clôture, il faut demander la liste des objets existants et nommer le destinataire de chacun. Après la clôture, l'interrogation de l'ancien registre n'offrira plus ce tableau.

Le champ de la règle est précis. L'aperçu des transferts d'APNIC énumère cinq scénarios, des échanges entre comptes APNIC aux passages avec registres nationaux ou régionaux. La suppression décrite ici vise la sortie inter-RIR depuis un titulaire APNIC. Elle ne décrit pas, à elle seule, le traitement de chaque transfert national ou entre deux comptes APNIC. Cette distinction importe aussi pour les frais : dans ce scénario de sortie, APNIC désigne son titulaire comme payeur. Les clauses commerciales peuvent répartir la charge entre vendeur et acheteur, mais elles ne changent pas le compte auquel le registre adresse son étape de paiement.

Prenons la route. Le guide APNIC de création d'objets de routage décrit route et route6 comme les entrées Whois qui associent un itinéraire interdomaines à son AS d'origine. Leur création suppose les objets d'adresse et d'AS pertinents, ainsi qu'une autorisation mnt-routes cohérente. Un objet route supprimé cesse d'être une assertion publiée dans cette base. Un acheteur prudent veut savoir quel registre acceptera la nouvelle fiche, quel mainteneur pourra l'autoriser et quand les données seront visibles pour les réseaux qui consultent les registres. Le numéro du bloc et le nom du nouveau titulaire ne répondent à aucune de ces questions.

Les sous-attributions demandent un travail moins spectaculaire, mais plus fastidieux. Une partie du bloc peut être confiée à un client ou à une unité d'exploitation. APNIC inclut explicitement ces objets dans sa liste de suppressions. Si leur inventaire n'est pas récupéré avant le transfert, la nouvelle inscription du titulaire dira peu sur la répartition effective des adresses. Il faudra reconstituer les bornes des sous-plages, les contacts et le responsable de chaque usage.

Pour un incident touchant une seule adresse, c'est cette granularité qui permet de joindre le bon opérateur au lieu d'envoyer une demande au hasard à la société mère.

Le troisième ensemble touche le DNS inverse. Le guide APNIC explique qu'un objet domain contient les noms des serveurs faisant autorité pour une zone in-addr.arpa ou ip6.arpa. APNIC fabrique ses délégations de zones inverses à partir de la base Whois et recharge ses serveurs toutes les deux heures; les caches DNS ajoutent ensuite leur propre calendrier. Le titulaire exploite les serveurs de sa zone et les enregistrements PTR. APNIC publie l'orientation vers ces serveurs. Supprimer l'objet du registre source retire donc une instruction de cette chaîne. Le registre destinataire doit avoir un dossier de délégation, un contact DNS et une chronologie de vérification dans le plan de transfert.

Le danger pratique tient à la confusion des preuves. Un document prouve que le transfert est accepté. Une recherche Whois montre le nouveau titulaire. Ni l'un ni l'autre ne décrit automatiquement les sous-attributions, les routes et les délégations qui ont quitté la base APNIC. La clôture devrait produire des constats datés : export des objets avant l'opération, confirmation du transfert, nouvelle inscription du titulaire, fiches de routage et de clients au registre destinataire, délégation inverse consultable. Chaque constat a son responsable.

Une case « transfert terminé » masque ces étapes au moment précis où elles deviennent vérifiables.

Les pages publiques d'APNIC ne donnent pas la date de création des objets de remplacement pour une opération particulière; une fiche horodatée du registre destinataire établirait ce fait pour un préfixe donné.