Difference between revisions of "Découverte de la liste de serveurs DNS récursifs"

From Livre IPv6

m
(mises à jour références)
 
Line 1: Line 1:
 
{{suivi|Recommandations opérationnelles pour l'intégration d'IPv6|Recommandations opérationnelles pour l'intégration d'IPv6|Propagation et mise à jour dynamique du DNS|Propagation et mise à jour dynamique du DNS}}
 
{{suivi|Recommandations opérationnelles pour l'intégration d'IPv6|Recommandations opérationnelles pour l'intégration d'IPv6|Propagation et mise à jour dynamique du DNS|Propagation et mise à jour dynamique du DNS}}
  
−
L'autoconfiguration IPv6 sans état, telle que spécifiée dans le RFC 2462, n'a pas prévu de mécanisme de découverte automatique de la liste des serveurs DNS récursifs (cache). En revanche, il était prévu que ces informations complémentaires soient fournies par l'autoconfiguration avec état. Les spécifications du protocole d'autoconfiguration avec état, [[DHCPv6]], ont mis longtemps (six ans environ) à passer en RFC (RFC 3315) et le besoin de découverte des serveurs DNS récursifs s'est accentué davantage. En effet, afin de renforcer le déploiement d'IPv6, la communauté IPv6 s'est vite trouvée dans l'urgence de mettre en oeuvre un mécanisme de découverte automatique du DNS avec ou sans DHCPv6 (qui était justement près de sortir).
+
L'autoconfiguration IPv6 sans état, telle que spécifiée dans le RFC 4862, n'a pas prévu de mécanisme de découverte automatique de la liste des serveurs DNS récursifs (cache). En revanche, il était prévu que ces informations complémentaires soient fournies par l'autoconfiguration avec état. Les spécifications du protocole d'autoconfiguration avec état, [[DHCPv6]], ont mis longtemps (six ans environ) à passer en RFC (RFC 3315) et le besoin de découverte des serveurs DNS récursifs s'est accentué davantage. En effet, afin de renforcer le déploiement d'IPv6, la communauté IPv6 s'était vite trouvée dans l'urgence de mettre en oeuvre un mécanisme de découverte automatique du DNS avec ou sans DHCPv6 (qui était justement près de sortir).
  
−
Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop ». C'est le groupe dnsop qui a pris en charge les débats sur ces propositions. Le niveau de maturité et de stabilité (en termes de discussions et d'implémentations) est variable d'une proposition à l'autre. À ce jour, et après de longs débats, aucun consensus n'a encore été trouvé pour adopter la meilleure solution (s'il y en a). En revanche, les co-auteurs de ces trois propositions ont conjointement rédigé un document synthétique décrivant pour chaque technique le fonctionnement ainsi que les scénarios d'utilisation [[Bibliographie#Jeong-id|[Jeong-id]]]. Ce document, qui a déjà acquis une certaine stabilité , donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.
+
Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop ». C'est le groupe dnsop qui a pris en charge les débats sur ces propositions. Les co-auteurs de ces trois propositions ont conjointement rédigé un document synthétique (RFC 4339) décrivant pour chaque technique le fonctionnement ainsi que les scénarios d'utilisation. Ce document donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.
  
 
Voici maintenant un résumé des trois propositions :
 
Voici maintenant un résumé des trois propositions :
  
−
* Proposition 1 : mécanisme à base de DHCP : deux solutions légèrement différentes ont été proposées. Elles proposent toutes les deux d'utiliser la même option DHCPv6 DNS Recursive Name Server spécifiée dans le RFC 3646 :
+
* Proposition 1, mécanisme à base de DHCP : deux solutions légèrement différentes ont été proposées. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646 :
 
** découverte via un serveur DHCPv6 complet (RFC 3315 : c'est-à-dire qui alloue dynamiquement les adresses IPv6 ;
 
** découverte via un serveur DHCPv6 complet (RFC 3315 : c'est-à-dire qui alloue dynamiquement les adresses IPv6 ;
 
** découverte du DNS via un serveur DHCPv6-lite (RFC 3736) : celui-ci n'alloue pas d'adresses IPv6 mais il est simplement chargé d'informer les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression, ...) ;
 
** découverte du DNS via un serveur DHCPv6-lite (RFC 3736) : celui-ci n'alloue pas d'adresses IPv6 mais il est simplement chargé d'informer les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression, ...) ;
 
** Dans les deux cas, si l'équipement est en double pile et s'il est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), il faut définir une politique d'arbitrage entre les deux listes de serveurs DNS récursifs obtenues si celles-ci sont incohérentes ;
 
** Dans les deux cas, si l'équipement est en double pile et s'il est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), il faut définir une politique d'arbitrage entre les deux listes de serveurs DNS récursifs obtenues si celles-ci sont incohérentes ;
−
* Proposition 2 : mécanisme à base d'annonce de routeur (RA) [[Bibliographie#Jeong-id|[Jeong-id]]] : cette proposition apporte un complément à l'autoconfiguration sans état (RFC 2462) et consiste à surcharger l'annonce du routeur, en tant que message de la découverte des voisins (RFC 2461) par l'information DNS nécessaire ;
+
* Proposition 2, RFC 5006, mécanisme à base d'annonce de routeur (RA): cette proposition apporte un complément à l'autoconfiguration sans état (RFC 4862) et consiste à surcharger l'annonce du routeur, en tant que message de la découverte des voisins (RFC 4861) par l'information DNS nécessaire. Une telle extension n'a pas été standardisée à ce jour, le RFC étant dans un état EXPERIMENTAL ;
−
* Proposition 3 : mécanisme à base d'adresses anycast bien connues (''Well-known anycast addresses'') : trois adresses IPv6 [[anycast]] (et trois autres en IPv4) qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement.
+
* Proposition 3, mécanisme à base d'adresses anycast bien connues (''Well-known anycast addresses'') : des adresses IPv4 et IPv6 [[anycast]] qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée.
  
−
En attendant l'avancement et la publication en RFC du document [[Bibliographie#Jeong-id|[Jeong-id]]] synthétisant les approches décrites ci-dessus, la liste des serveurs DNS récursifs est généralement configurée aujourd'hui selon l'une des trois méthodes suivantes :
 
  
−
* par configuration manuelle (en éditant le fichier <tt>/etc/resolv.conf</tt> par exemple pour les systèmes Unix) sur les équipements ne supportant qu'IPv6 ou en l'absence de serveur DHCP ;
 
−
* par configuration automatique via DHCPv4 pour les équipements en double pile IPv4/IPv6 lorsqu'un serveur DHCPv4 est disponible.
 
−
* Par configuration automatique via DHCPv6 pour les environnements où une implémentation de DHCPv6 (avec l'option de découverte de DNS) est disponible.
 
 
{{suivi|Recommandations opérationnelles pour l'intégration d'IPv6|Recommandations opérationnelles pour l'intégration d'IPv6|Propagation et mise à jour dynamique du DNS|Propagation et mise à jour dynamique du DNS}}
 
{{suivi|Recommandations opérationnelles pour l'intégration d'IPv6|Recommandations opérationnelles pour l'intégration d'IPv6|Propagation et mise à jour dynamique du DNS|Propagation et mise à jour dynamique du DNS}}

Latest revision as of 01:01, 26 October 2007

Recommandations opérationnelles pour l'intégration d'IPv6 Table des matières Propagation et mise à jour dynamique du DNS

L'autoconfiguration IPv6 sans état, telle que spécifiée dans le RFC 4862, n'a pas prévu de mécanisme de découverte automatique de la liste des serveurs DNS récursifs (cache). En revanche, il était prévu que ces informations complémentaires soient fournies par l'autoconfiguration avec état. Les spécifications du protocole d'autoconfiguration avec état, DHCPv6, ont mis longtemps (six ans environ) à passer en RFC (RFC 3315) et le besoin de découverte des serveurs DNS récursifs s'est accentué davantage. En effet, afin de renforcer le déploiement d'IPv6, la communauté IPv6 s'était vite trouvée dans l'urgence de mettre en oeuvre un mécanisme de découverte automatique du DNS avec ou sans DHCPv6 (qui était justement près de sortir).

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop ». C'est le groupe dnsop qui a pris en charge les débats sur ces propositions. Les co-auteurs de ces trois propositions ont conjointement rédigé un document synthétique (RFC 4339) décrivant pour chaque technique le fonctionnement ainsi que les scénarios d'utilisation. Ce document donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

Voici maintenant un résumé des trois propositions :

  • Proposition 1, mécanisme à base de DHCP : deux solutions légèrement différentes ont été proposées. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646 :
    • découverte via un serveur DHCPv6 complet (RFC 3315 : c'est-à-dire qui alloue dynamiquement les adresses IPv6 ;
    • découverte du DNS via un serveur DHCPv6-lite (RFC 3736) : celui-ci n'alloue pas d'adresses IPv6 mais il est simplement chargé d'informer les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression, ...) ;
    • Dans les deux cas, si l'équipement est en double pile et s'il est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), il faut définir une politique d'arbitrage entre les deux listes de serveurs DNS récursifs obtenues si celles-ci sont incohérentes ;
  • Proposition 2, RFC 5006, mécanisme à base d'annonce de routeur (RA): cette proposition apporte un complément à l'autoconfiguration sans état (RFC 4862) et consiste à surcharger l'annonce du routeur, en tant que message de la découverte des voisins (RFC 4861) par l'information DNS nécessaire. Une telle extension n'a pas été standardisée à ce jour, le RFC étant dans un état EXPERIMENTAL ;
  • Proposition 3, mécanisme à base d'adresses anycast bien connues (Well-known anycast addresses) : des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée.


Recommandations opérationnelles pour l'intégration d'IPv6 Table des matières Propagation et mise à jour dynamique du DNS
Retrieved from "http://livre.g6.asso.fr/index.php?title=Découverte_de_la_liste_de_serveurs_DNS_récursifs&oldid=3570"
Personal tools