Date de publication du RFC : Septembre 2007
Auteur(s) du RFC : J. Jeong (ETRI/University of Minnesota), S. Park
(SAMSUNG Electronics), L. Beloeil (France Telecom
R&D), S. Madanapalli (SAMSUNG ISO)
Expérimental
Première rédaction de cet article le 25 septembre 2007
Dernière mise à jour le 28 novembre 2009
Comment configurer les serveurs de noms sur toutes les machines du réseau qu'on administre ? DHCP fournit une solution, ce RFC en normalise une autre, fondée sur les RA (Router Advertisements).
Si on gère un gros réseau, avec de nombreuses machines dont
certaines, portables, vont et viennent, s'assurer que toutes ces
machines ont les adresses IP
des serveurs de noms à utiliser n'est pas trivial. On ne peut évidemment pas utiliser le DNS, cela serait tenter de voler en tirant
sur les lacets de ses chaussures. Et configurer à la main les adresses
sur chaque machine (par exemple, sur Unix, en
les écrivant dans le fichier /etc/hosts
)
est bien trop difficile à maintenir.
La solution la plus populaire actuellement est DHCP (RFC 2136 et RFC 3315). Son principal inconvénient est qu'elle est à état : le serveur DHCP doit se souvenir des baux qu'il a attribué. Sur un gros réseau local, le nombre de requêtes à traiter, chacune nécessitant une écriture dans une base de données, peut devenir très lourd.
Une autre solution est sans état et repose sur
une nouveauté d'IPv6, les RA (Router
Advertisements), décrits dans le RFC 4862. Ce sont des messages envoyés à intervalles
réguliers par les routeurs et
qui informent les machines non-routeuses des caractéristiques
essentielles du réseau, comme le préfixe utilisé (par exemple
2001:DB8:BEEF:42::/64
). Le routeur diffuse ses
messages et n'a pas besoin d'écrire quoi que ce soit sur son disque,
ni de faire des traitements compliqués lors d'une sollicitation, il
répond toujours par le même message RA.
Ces RA peuvent diffuser diverses informations, par le biais d'un système d'options. Le principe de notre RFC est donc d'utiliser ces RA pour transporter l'information sur les serveurs de noms récursifs utilisables sur le réseau local, via la nouvelle option nommée RDNSS (le numéro 25 a été affecté par l'IANA).
Initialement prévu pour le chemin des normes, ce RFC a finalement été publié comme « expérimental », suite à des désaccords sur la « bonne » méthode de configuration des serveurs de noms. Notre RFC commence donc, en section 1.1, par un avertissement que le protocole « officiel » reste DHCP. Le RFC 4339 contient une discussion plus détaillée de ce problème du choix d'une méthode de configuration des serveurs de noms (notons qu'il existe d'autres méthodes comme l'anycast avec une adresse « bien connue »). Le successeur de notre RFC, le RFC 6106 a été, lui, publié sur le chemin des normes et la publication de réglages DNS par le Router Advertisement est donc désormais standard.
Sur Linux, le démon rdnssd permet de recevoir ces RA et de modifier la configuration DNS. Pour FreeBSD, on peut consulter une discussion sur leur liste. Les CPE de Free, les Freebox, émettent de telles options dans leurs RA. Voici ce qu'affiche Wireshark :
... Ethernet II, Src: FreeboxS_c3:83:23 (00:07:cb:c3:83:23), Dst: IPv6mcast_00:00:00:01 (33:33:00:00:00:01) ... Internet Control Message Protocol v6 Type: 134 (Router advertisement) ... ICMPv6 Option (Recursive DNS Server) Type: Recursive DNS Server (25) Length: 40 Reserved Lifetime: 600 Recursive DNS Servers: 2a01:e00::2 (2a01:e00::2) Recursive DNS Servers: 2a01:e00::1 (2a01:e00::1)
et les serveurs DNS annoncés répondent correctement. (Vous pouvez récupérer le paquet entier sur pcapr.net.)
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)