AFRINIC : des objets DNS inverses bloquent la correction d’un bloc

Chez AFRINIC, corriger l’adresse pourrait défaire le DNS inverse

Pourquoi c'est important

Jaco Kroon décrit une suppression refusée tant que les objets de délégation restent attachés au bloc. La base exige des registres à jour, puis complique leur mise à jour.

Theo March28 octobre 2026Temps de lecture 2 minDernière mise à jour: 28 octobre 2026

Le blocage de suppression décrit chez AFRINIC relie une fiche d’adresse à quatre domaines inverses et une route.

Résumé

Le 22 octobre, Jaco Kroon a signalé qu’un objet d’adresse parent ne pouvait être supprimé en présence de quatre objets domain et d’un objet route enfants.
La règle 10.5.2 d’AFRINIC subordonne la délégation DNS inverse à un sous-bloc enregistré ; la procédure de correction décrite par Kroon menace de défaire temporairement cet enregistrement de délégation.

Le registre demande une comptabilité exacte des adresses. Pour rectifier une ligne, il faudrait d’abord détacher ce qui pend à cette ligne. C’est la difficulté exposée par Jaco Kroon sur la liste de discussion d’AFRINIC. Son exemple utilise 10.0.0.0/22 : quatre domaines inverses couvrant des /24, plus un objet de routage, empêchent la suppression de l’objet inetnum parent. Les messages d’erreur reproduits désignent chacun comme enfant. L’adresse privée sert à illustrer le mécanisme ; aucun réseau public touché n’est identifié.

L’architecture explique l’embarras. Un inetnum documente l’usage du bloc. Un domain porte la délégation inverse vers les serveurs de noms du titulaire. Le mode d’emploi d’AFRINIC indique que la création de cet objet, via le portail, le WHOIS ou le courrier électronique, précède la publication de la délégation par le registre. Le titulaire exploite ses propres zones et entrées PTR. Déplacer l’objet domain revient donc à toucher à l’aiguillage publié par AFRINIC.

La section 10.5.2 du manuel en vigueur interdit une délégation sans affectation ou sous-allocation enregistrée dans le bloc concerné. Un /24 exige au moins une affectation, pas l’occupation complète de ses 256 adresses. Le guide WHOIS exige des données conformes à l’usage réel et explique qu’un objet référencé ne peut être effacé librement. Kroon situe la collision dans l’ordre des opérations : pour refaire l’affectation, il dit devoir retirer provisoirement ses objets de délégation.

Il propose de supprimer toute la section 10.5 pour permettre d’assouplir les contraintes de la base. Ce geste toucherait aussi la section 10.5.1, qui traite des demandes des registres locaux membres en règle. Son courriel ouvre un débat ; aucun projet numéroté n’y est joint. Les documents publics consultés ne contiennent ni reproduction technique par AFRINIC ni trace d’une interruption effective. Une transaction documentée par le registre préciserait le chemin réellement disponible.