Résumé

  • RFC 9527 transporte par DHCPv6 le domaine résidentiel enregistré et les coordonnées des gestionnaires de distribution directe et inverse.
  • La réception correcte des options 145, 146 et 147 établit un fait de configuration, non la délégation effective, la publication de zone, la validité DNSSEC ni l’accessibilité publique.
  • Une exploitation défendable relie sept reçus : configuration, autorité, canal authentifié, publication, validation, observation externe et cycle de vie.

Le bail DHCPv6 a été renouvelé sans erreur. Le routeur a demandé les trois options prévues et le serveur a répondu avec un nom de domaine, un gestionnaire direct et un gestionnaire inverse. Pourtant, depuis un réseau mobile, le nom ne répondait toujours pas.

Ce scénario est une hypothèse de contrôle, pas le récit d’une panne identifiée. Il montre pourquoi RFC 9527 doit être lu comme un mécanisme de fourniture de paramètres. Il permet à une Homenet Naming Authority (HNA) de savoir où poursuivre le travail. Il ne prétend pas que ce travail est déjà achevé.

Trois coordonnées, trois responsabilités

OPTION_REGISTERED_DOMAIN, code 145, indique le FQDN associé au réseau domestique. OPTION_FORWARD_DIST_MANAGER, code 146, fournit le FQDN du Distribution Manager direct et les transports pris en charge. OPTION_REVERSE_DIST_MANAGER, code 147, fournit l’équivalent pour la zone inverse.

Le client place ces codes dans l’Option Request Option. Le serveur, s’il possède des valeurs configurées, les renvoie. Ce dialogue peut être archivé avec ses octets, son interface, son serveur, son bail et son heure. C’est une preuve forte de ce que le client a reçu.

Le nom du gestionnaire doit ensuite être résolu. Une connexion doit aboutir. La HNA doit être authentifiée. Le gestionnaire doit accepter la zone. La délégation parente doit viser les bons serveurs. Les réponses publiques doivent présenter la version attendue. Le Reply DHCPv6 n’atteste aucun de ces événements postérieurs.

Le protocole d’externalisation commence après DHCPv6

RFC 9527 renvoie explicitement à RFC 9526. Celui-ci organise l’externalisation de la zone publique du réseau domestique. Après réception des options, la HNA doit s’authentifier auprès des gestionnaires, produire ses zones et les transférer.

Le champ Supported Transport illustre la frontière. Le bit DomTLS doit être annoncé. Il signifie que le gestionnaire prend en charge DNS sur TLS mutuellement authentifié et le transfert de zone sur TLS. Il ne constitue ni une poignée de main réussie, ni un certificat vérifié, ni un transfert accepté.

Une trace peut donc être correcte et conduire vers un état obsolète. Le serveur DHCPv6 peut détenir une association ancienne entre abonné et domaine. Le FQDN du gestionnaire peut résoudre vers un service qui n’a pas reçu les nouvelles informations. La zone peut être acceptée sans que la délégation parente ait convergé. Les clés DNSSEC peuvent changer à un autre rythme que les enregistrements.

IANA attribue le sens, pas la réalité d’exploitation

Les registres IANA empêchent les collisions de codes et fixent la signification de DomTLS. Ils rendent les implémentations interopérables au niveau du vocabulaire. Ils ne mesurent ni le déploiement sur les CPE, ni la qualité des données d’un fournisseur, ni l’état d’une zone publique.

Le même principe vaut pour un tableau de bord interne. Une coche verte confirme souvent que l’étape observée par ce système a réussi. Si elle est alimentée par le serveur DHCPv6, elle ne peut pas, sans source supplémentaire, parler au nom de la délégation, du serveur faisant autorité ou d’un résolveur externe.

Les chaînes directe et inverse ne sont pas symétriques

Le fournisseur d’accès maîtrise naturellement le préfixe délégué et peut héberger la zone inverse. Le domaine direct peut relever d’un registrar ou d’un opérateur DNS tiers. C’est pourquoi les gestionnaires direct et inverse sont séparés.

Lors d’un changement de préfixe, les enregistrements directs peuvent pointer vers une nouvelle adresse tandis que l’ancienne zone inverse reste publiée. Lors d’un changement de CPE, le nouveau HNA peut téléverser une zone correcte sans retirer l’ancienne. Chaque chaîne doit conserver son domaine ou préfixe, son gestionnaire, son serveur faisant autorité, son numéro de série, son état de signature et son observation publique.

Dire « le nommage est configuré » masque cette dualité. Dire « la zone directe version X est servie par A et B, validée à telle heure ; la zone inverse version Y est servie par C » produit une affirmation vérifiable.

La simplicité déplace le pouvoir

Dans le scénario de base, le fournisseur d’accès peut exploiter DHCPv6, le gestionnaire direct, le gestionnaire inverse et les serveurs faisant autorité. L’utilisateur gagne une configuration presque invisible. Le fournisseur concentre la capacité de nommer, d’authentifier et de publier.

Ce n’est pas en soi une faute. C’est une surface de contrôle. Une observation indépendante doit compléter les journaux du même opérateur. Elle permet de distinguer une erreur interne corrigée d’une réalité publique qui n’a pas encore convergé.

Avec un domaine tiers, l’autorité d’enregistrement, la redirection, les identifiants de la HNA et l’acceptation par le gestionnaire sont répartis entre plusieurs acteurs. Avec plusieurs fournisseurs d’accès, chaque interface peut recevoir un domaine différent. RFC 9527 précise que cette pluralité relève de l’implémentation. Le basculement d’accès ne garantit donc pas le basculement du nommage.

Sept reçus pour une affirmation complète

Le reçu de configuration conserve le dialogue DHCPv6, les options brutes, l’interface, le bail et l’identité du serveur. Le reçu d’autorité établit qui contrôle le domaine enregistré, le préfixe inverse et les délégations attendues.

Le reçu de canal conserve la résolution du gestionnaire, le pair TLS, le certificat, la règle de confiance et la transaction acceptée. Le reçu de publication fixe la version de zone, les serveurs, le numéro de série et l’heure d’acceptation.

Le reçu de validation couvre la chaîne DNSSEC et les réponses négatives. Le reçu d’accessibilité interroge des points de vue indépendants sur IPv4 et IPv6. Enfin, le reçu de cycle de vie couvre renouvellement, rebind, changement de préfixe, remplacement de routeur, basculement multi-FAI, retour arrière et retrait vérifié de l’ancien état.

La distinction de Heng Lu entre spécification, code en fonctionnement et réalité observée devient ici un outil d’exploitation. Le standard fournit le minimum commun. Les décisions locales assemblent les fournisseurs et les identités. Le DNS public révèle le résultat. Aucun niveau ne doit emprunter l’autorité du suivant.

Limites des sources

Les sources ne recensent ni parc installé, ni fournisseur défaillant, ni incident nommé, ni taux d’échec. L’ouverture n’est donc pas une allégation factuelle sur un produit. Elle sert à tester le modèle de preuve.

RFC 9527 accomplit une tâche importante : rendre transportable une configuration auparavant manuelle. Sa réussite autorise à dire que la HNA a reçu des coordonnées normalisées. Pour affirmer que le foyer possède une autorité DNS publique, il faut encore observer toute la chaîne.

Sources