Résumé

  • L’option 23 de RFC 3646 ordonne des adresses de résolveurs par préférence et l’option 24 fournit des suffixes de recherche propres au DNS ; leur présence n’atteste pas leur installation.
  • L’organisation doit préserver séparément la provenance, la règle de priorité locale, le nom transformé, le serveur réellement interrogé, la validation et le résultat reçu par l’application.

Le vrai centre de contrôle n’est pas nécessairement le serveur DHCPv6. Une équipe peut administrer le réseau d’accès, une autre imposer un résolveur sur le poste et une troisième exploiter la résolution récursive. Une même adresse peut en outre parvenir par une Router Advertisement. Si l’inventaire final ne garde qu’une chaîne de caractères, il efface la décision qui a donné autorité à cette valeur.

RFC 3646 définit deux objets volontairement modestes. OPTION_DNS_SERVERS, code 23, contient des adresses IPv6 de serveurs récursifs, placées dans l’ordre de préférence du résolveur client. OPTION_DOMAIN_LIST, code 24, contient une liste de recherche utilisée pour les noms d’hôte DNS, et non pour les autres mécanismes de résolution. La version texte limite les deux options aux messages Solicit, Advertise, Request, Renew, Rebind, Information-Request et Reply.

Cet ordre n’est pas une preuve de routabilité ni de choix effectif. Un client peut recevoir la première adresse sans l’installer, l’installer puis employer une autre source, l’essayer avant de basculer, ou répondre depuis un cache. L’adresse préférée ne porte aucun reçu attestant la requête exacte, le transport, la réponse ou l’usage qu’en a fait le logiciel appelant.

La liste de recherche introduit une autre autorité : elle transforme une saisie incomplète en plusieurs noms candidats. RFC 3646 renvoie à RFC 1535 et RFC 1536, qui cadrent les risques des listes implicites et l’ordre d’essai des noms comportant un point. Ici, la question de gouvernance est de savoir si le journal conserve le nom saisi avant toute transformation, chaque suffixe appliqué et le premier résultat accepté.

La sécurité ne se réduit pas à une coche cryptographique. RFC 3646 recommande l’authentification DHCP avant d’installer une liste de serveurs ou d’accepter une liste de recherche. Cela protège la provenance du message selon le mécanisme employé. Cela ne démontre ni la santé du résolveur annoncé ni l’intention du nom obtenu. RFC 4033 encadre DNSSEC : une donnée peut être légitimement signée dans un domaine que la mauvaise liste de recherche a conduit à interroger. La validation est correcte, tandis que le choix du nom reste erroné.

La clause la plus importante pour la responsabilité locale est simple : des paramètres DNS configurés manuellement ne devraient pas être écrasés par DHCP. La capture réseau ne peut donc pas décider seule de l’état attendu. Il faut le dossier de politique du poste : présence du réglage manuel, règle de priorité, décision d’acceptation, configuration installée et durée attachée à chaque source.

RFC 8106 ajoute un second plan automatique en définissant RDNSS et DNSSL dans les Router Advertisements. Des valeurs identiques n’ont pas nécessairement la même provenance ni la même durée de vie. La fusion doit conserver ces dimensions au lieu de faire disparaître la source derrière la valeur.

L’histoire normative aide à borner les affirmations. RFC 3315 est la base DHCPv6 d’origine, désormais remplacée par RFC 8415. RFC 8504 place les options DNS dans les exigences des nœuds IPv6. Ces obligations d’interopérabilité ne sont pas des attestations d’exécution pour une machine particulière.

Le résultat DNS appartient encore à un autre plan. RFC 1034 décrit l’architecture et RFC 1035 les messages et la mise en œuvre. RFC 3397 offre le parallèle DHCPv4 pour les domaines de recherche. Aucun de ces textes ne permet de déduire une requête réellement émise d’une option simplement reçue.

Le registre IANA DHCPv6 attribue les codes 23 et 24. C’est une coordination de vocabulaire, non un verdict sur une annonce, une politique locale ou un résultat. De même, l’entrée Datatracker, la fiche RFC Editor, les errata et l’historique prouvent la provenance du standard, pas son exécution présente.

Les analyses de Heng Lu sur la primauté du code en fonctionnement, la spécification commune minimale et les couches de réalité conduisent à une discipline claire. Le standard commun doit rester assez mince pour permettre l’interopérabilité sans absorber la politique du poste. Seul l’état effectif, observé au bon moment, peut justifier une affirmation sur l’usage.

Un dossier exploitable relie donc l’interface et le réseau, l’identité du serveur DHCP, l’authentification, les octets des options, la priorité du manuel, la décision d’installation, la source et sa durée de vie, le nom original, les expansions, le résolveur et le transport choisis, le cache, la réponse, la validation DNSSEC et le résultat applicatif. Une lacune reste une lacune ; elle ne devient pas une preuve par répétition.