Chez ARIN, le DNS inverse dépend du bloc d’origine

Résumé

• ARIN construit ses délégations inverses à partir des composantes CIDR de l’allocation directe : un /23 donne deux délégations /24, alors qu’un /16 en donne une seule au niveau /16.
• L’exception au partage de gestion dépend du bloc amont du fournisseur. Elle ne supprime pas la possibilité technique d’une délégation DNS subordonnée, mais oblige à identifier qui doit l’organiser.

Deux objets, puis un seul

Imaginons une entreprise qui reçoit un /24 de son fournisseur d’accès. Elle sait quelles adresses elle peut utiliser. Son équipe souhaite maintenant choisir les serveurs qui répondront pour les noms inverses correspondants. La demande paraît proportionnée : administrer son propre sous-réseau, pas ceux de ses voisins. Pourtant, la taille du réseau client ne suffit pas à dire quel droit d’édition ARIN peut lui présenter.

Deux exemples de la documentation d’ARIN sur le DNS inverse expliquent pourquoi. Une allocation directe /23 produit deux délégations /24, dont les serveurs de noms peuvent être gérés séparément. Une allocation directe /16 produit une délégation /16 ; la gestion des serveurs s’effectue alors à ce niveau. Le bloc le plus vaste n’offre donc pas nécessairement le plus grand nombre d’objets de délégation indépendamment modifiables dans le registre.

Il ne s’agit pas d’une limitation arithmétique du DNS. ARIN prend les blocs CIDR qui composent une Direct Allocation et crée pour chacun les plus grandes délégations qu’il prend en charge. En IPv4, ces frontières sont /8, /16 et /24, avec une taille minimale prise en charge de /24. Un /23 ne correspond à aucune frontière proposée : il se répartit en deux /24. Un /16 correspond exactement à l’une d’elles. La règle repose sur l’allocation directe, non sur toute plage plus petite qu’un titulaire pourrait ensuite enregistrer pour un client.

Cette précision évite deux conclusions excessives. Le détenteur du /16 ne perd pas toute maîtrise parce qu’il voit moins d’objets dans le registre : il dispose d’une délégation couvrant davantage d’adresses. Et le bénéficiaire d’un /24 ne peut pas déduire de la seule taille de son réseau qu’ARIN lui fournira un objet /24 distinct. Le découpage commercial, le découpage des enregistrements et celui des zones DNS peuvent coïncider ; ils ne le font pas automatiquement. Pour IPv6, ARIN décrit des frontières de quatre bits. L’exception /16 étudiée ici concerne IPv4 et ne doit pas être transposée à cet autre régime.

L’exception se lit du côté du fournisseur

ARIN prévoit une gestion partagée du DNS inverse entre titulaires directs et indirects lorsque les conditions sont réunies. Une organisation autorisée, indiquée pour la zone concernée, peut participer à la gestion pour les adresses qui lui ont été déléguées. Mais la même documentation écarte le partage lorsqu’une réattribution ou une réallocation provient du bloc /16 ou plus vaste d’un fournisseur d’accès.

Le mot décisif est « provient ». L’exception ne vise pas seulement un client qui aurait lui-même reçu un /16. Dans notre exemple hypothétique, un /24 prélevé sur le /16 du fournisseur relève précisément de la relation amont décrite. Et « plus vaste » signifie davantage d’adresses, donc un préfixe numérique plus court, non un nombre après la barre oblique plus élevé.

Il serait tout aussi trompeur de présenter cette réserve comme la preuve d’un refus subi par une entreprise. Les sources décrivent un modèle de gestion ; cette enquête n’a testé aucun compte ARIN ni aucune autorisation client. On peut en tirer une question opérationnelle précise, pas une statistique sur les difficultés des abonnés : sur quelle délégation réelle la demande du client devrait-elle porter ?

La gestion des enregistrements de ressources apporte une autre séparation utile. Une modification de réseau peut changer son nom, ses contacts ou ses commentaires publics ; elle ne modifie pas la délégation DNS inverse. Les dispositions générales sur la gestion partagée des ressources se lisent donc avec la réserve particulière du service DNS. Il n’est pas nécessaire de supposer une contradiction entre deux pages pour expliquer qu’un dossier client soit modifiable et que la zone correspondante ne le soit pas de la même manière.

La fin de la relation compte aussi. ARIN demande au fournisseur de retirer l’enregistrement de réattribution ou de réallocation d’un client déconnecté afin de supprimer les droits partagés associés. C’est une procédure de cycle de vie documentée, non le constat de droits abandonnés chez un opérateur donné. Elle n’autorise évidemment pas à retirer les ressources d’un client actif au seul motif qu’un organigramme de permissions semblerait plus simple ainsi.

Le relais peut se trouver dans le DNS

Revenons au /24 de l’entreprise. Si le partage d’édition au niveau d’ARIN n’est pas disponible, la question suivante n’est pas nécessairement celle d’un compte plus puissant. C’est celle de la zone parente. Le fournisseur, ou le prestataire qui exploite son DNS, peut-il établir une délégation subordonnée vers les serveurs du client ?

La structure décrite par le RFC 1034 permet à l’exploitant d’une zone de déléguer une sous-zone. La partie parente doit publier les indications nécessaires, notamment les enregistrements NS et, lorsque requis, les adresses de raccordement ; les deux côtés de la coupure doivent rester cohérents. Un /24 situé sous un /16 peut ainsi relever d’une sous-délégation DNS ordinaire. Le client n’a pas besoin, pour cette possibilité technique, de recevoir le compte ARIN du fournisseur ni la maîtrise de tout le /16.

Cela ne prouve pas qu’un fournisseur particulier propose cette prestation. Il faut un opérateur pour l’établir, l’entretenir et intervenir lorsque les serveurs changent. L’absence de bouton dans le registre et l’absence d’offre chez un fournisseur sont deux constats différents ; aucun ne se déduit automatiquement de l’autre.

Pour moins de 256 adresses IPv4, le RFC 2317 décrit une autre construction : des noms délégués supplémentaires et des liens CNAME permettent une administration sans modifier le mécanisme de résolution du DNS. Le parent reste une dépendance. Cette technique ne signifie ni qu’ARIN crée librement des délégations /25, ni que tout client doit l’employer. L’appliquer comme explication universelle brouillerait justement le cas simple d’un /24 sous un /16.

Modifier la bonne couche

Les méthodes Reg-RWS reflètent la distinction entre réseau et délégation. Les objets de délégation apparaissent et disparaissent avec les réseaux associés ; ils ne se créent ou ne se suppriment pas indépendamment. Ils sont désignés par un nom de délégation, pas par un identifiant NET. La documentation prévoit de récupérer les délégations liées à un NET et de consulter l’état courant avant modification. Lire ces méthodes établit la logique documentée de l’interface, pas le résultat d’un essai avec des identifiants réels.

Dans ARIN Online, le guide de gestion DNS présente les zones effectives, leurs serveurs, les identifiants de clés DS et les organisations partageant l’autorité. Une modification de serveurs remplace les valeurs précédentes pour toutes les délégations sélectionnées. Ce détail importe davantage qu’une ressemblance entre le nom du réseau client et celui d’une zone : c’est la sélection effective qui détermine la portée de l’opération.

Le guide indique aussi un TTL par défaut de 86 400 secondes lorsque le champ est vide, une modification immédiate de la base et une visibilité DNS pouvant prendre jusqu’à 24 heures. Ce sont des indications de fonctionnement, non une mesure de panne ni une garantie uniforme d’expiration des caches.

Les sources consultées au 3 septembre 2026 permettent donc de distinguer une attribution d’adresses, un droit d’édition dans le registre et l’exploitation d’une zone enfant. Elles ne mesurent ni refus, ni migration, ni incident. Un PTR correct ne prouve d’ailleurs ni le routage, ni la propriété, ni une identité complète. La bonne question reste modeste : pour cette plage précise, qui peut faire changer la réponse du DNS, et à quel endroit ?