Résumé

  • Le RFC 2317 place dans la zone parente un CNAME par adresse et dirige la requête vers une zone enfant administrée séparément.
  • L’enfant publie les PTR, mais le parent conserve le point de passage qui rend cette autorité visible.
  • La réponse obtenue ne prouve ni allocation, ni autorisation BGP, ni contrôle du DNS direct, ni authentification du courrier, ni disponibilité.

Le DNS inverse d’IPv4 a été construit autour des octets. La zone 2.0.192.in-addr.arpa correspond commodément à un /24, mais un /26 ne fournit aucun endroit ordinaire où poser une coupure de zone. Dans l’exemple du RFC 2317, le même /24 est partagé entre un /25 et deux /26. Sans artifice, une seule organisation devrait administrer les PTR des trois parties.

Le document crée donc des noms intermédiaires, par exemple 128/26. La zone parente leur associe des NS, puis transforme chaque nom d’adresse en alias. 129.2.0.192.in-addr.arpa devient un CNAME vers 129.128/26.2.0.192.in-addr.arpa; la zone enfant fournit ensuite le PTR. Un résolveur classique sait déjà suivre un CNAME : aucun nouvel algorithme n’est requis.

Le libellé 128/26 n’est pourtant pas un objet de routage. C’est une convention DNS. Le RFC autorise d’autres libellés, voire une cible située ailleurs dans l’arbre. Ce détail empêche une confusion importante : le nom décrit le chemin de résolution choisi par l’opérateur du parent, pas la nature juridique ou topologique du bloc.

Le prix opérationnel est visible. Il faut presque 256 CNAME pour un /24 ainsi partagé. Le site enfant dépend d’un site de plus pour que la résolution fonctionne. Le RFC recommande même aux serveurs du parent d’être secondaires des zones enfants afin d’aider les anciens logiciels qui pouvaient renvoyer l’alias sans la donnée cible. Il interdit aussi de répéter la technique après une première subdivision, car une chaîne CNAME-vers-CNAME serait moins robuste.

Les auteurs indiquaient en 1998 que la méthode fonctionnait depuis plusieurs années dans de nombreuses installations, apparemment sans effet néfaste. Cette observation historique soutient la faisabilité de la convention. Elle ne mesure pas son déploiement actuel et ne garantit aucune plateforme.

Une réponse PTR reste une affirmation de nommage. Le DNS direct est distinct ; le RFC 1912 recommande de faire correspondre PTR et A précisément parce qu’ils peuvent diverger. Le RPKI est encore un autre système : le RFC 6480 décrit les certificats de ressources et les ROA qui autorisent explicitement un AS à annoncer des préfixes. Aucun CNAME du RFC 2317 ne porte cette autorisation.

Le courrier électronique ajoute SPF, DKIM et DMARC, avec leurs identifiants, signatures et règles d’alignement. Un PTR cohérent peut être utile à un destinataire, mais il ne produit aucun de ces résultats et ne supprime ni l’historique de réputation ni la décision du filtre. De même, un nom inverse peut répondre alors que la route est absente, le port fermé ou l’application hors service.

Le RFC 2317 a donc déplacé l’administration des PTR sans fusionner les autorités. Le parent contrôle la redirection ; l’enfant contrôle le contenu PTR ; les autres preuves restent dans leurs systèmes respectifs.