= Activité 34 : Faire correspondre adresse et nom de domaine=

==Introduction==

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms.  Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face. Le lecteur pourra se reporter aux nombreux ouvrages traitant des principes et des éléments de configuration du DNS<ref>Zitrax [http://www.zytrax.com/books/dns/ Livre sur les principes du DNS et les éléments de configuration de bind]</ref>.

==Concepts de base du DNS==

 

 

Une application qui s’exécute sur un équipement A, et qui souhaite communiquer avec une autre application s'exécutant sur un équipement distant B dont elle ne connaît que le nom, a besoin d'en obtenir l'adresse IP. Sans cette adresse, la communication ne peut en général pas avoir lieu : les machines utilisent le protocole IP pour communiquer et ce protocole n’utilise que les adresses IP.

 

 

Chacun de ces responsables peut alors télécharger ce fichier, via FTP par exemple, pour mettre à jour les informations de nommage stockées localement (par exemple, le fichier ''/etc/hosts'' pour les systèmes Unix). Un équipement disposant localement d’une version à jour du fichier de nommage peut ainsi communiquer avec toutes les machines connues dans ce fichier.

 

 

 

Le DNS est initialement un service de résolution, de mise à jour et d’enregistrement des correspondances directes "nom-adresse" et des correspondances inverses "adresse-nom". Il fournit aux utilisateurs, quelle que soit leur localisation, l’adresse IP associée à un nom de domaine. Il distribue, de plus, la responsabilité de la mise à jour des informations de nommage sur chaque site et met en place un système coopératif d’accès aux informations de nommage.

Petit à petit, le DNS s'impose comme infrastructure critique pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système est donc hiérarchique, réparti, robuste et extensible.

 

 

 

* <b>Robuste.</b> Aujourd’hui, tout le fonctionnement de l’internet dépend du bon fonctionnement du système de nommage. D’un point de vue pratique, s’il n’existe qu’un seul serveur officiel pour un domaine, le service de nommage devient indisponible si ce serveur tombe en panne ou est arrêté.  C’est pourquoi, au moins deux serveurs, situés sur des sites géographiquement distincts et indépendants, sont nécessaires pour chaque zone de nommage (zone DNS). Ceci assure à la fois une meilleure disponibilité et un meilleur équilibrage de charge.

**''Disponibilité''. La probabilité d’occurrence simultanée d’une panne catastrophique (avec perte des données) sur les deux sites est faible, plus faible en tout cas que s’il n’y a qu’un seul serveur. Si un des deux serveurs tombe en panne, l’autre continue de fournir le service. Cette probabilité de panne est encore réduite s'il existe plus de deux sites hébergeant des serveurs de noms secondaires.

 

 

L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela.  

 

Chaque zone commence au niveau d’un nœud (un domaine) et s’arrête aux nœuds de l’arbre de nommage qui correspondent à d’autres zones. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone.  Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage (cf. figure 3).

 

 

 

 

Chacune des applications d’une machine s’adresse au résolveur unique de cette machine (''stub resolver'') et lui demande des informations associées à des noms de domaines, comme des adresses IP, des relais de messagerie (enregistrement de type MX) ou des serveurs de noms (enregistrement de type NS). Le résolveur est une application commune à toutes les applications d’une machine. Il est souvent implémenté sous la forme d’une bibliothèque de procédures. Pour l’utiliser, les programmes d’application invoquent les procédures de la bibliothèque.

 

Initialement, le résolveur de la machine locale interrogeait successivement chacun des serveurs (résolution itérative) jusqu’à ce qu’il s’adresse au serveur officiel du domaine concerné. Afin d’accélérer la réponse aux requêtes suivantes, le résolveur conservait dans un cache les informations de nommage. Aujourd’hui, pour optimiser davantage le fonctionnement du système de nommage, les résolveurs fonctionnent en mode récursif. Ils s’adressent à un serveur DNS local et lui demandent de leur fournir les informations de nommage demandées. Ils ne gèrent alors plus de cache local. Ce dernier est mutualisé au niveau du serveur DNS local. Les informations mises en cache bénéficieront à l'ensemble des utilisateurs.

[[Image:MOOC_Act34_figBJ-5.png|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. Le serveur DNS recursif local résout ensuite la requête de manière itérative.

[[Image:MOOC_Act34_figBJ-7.png|666px|thumb|center|Figure 5 : Résolution itérative optimisée depuis un serveur local]]

<!-- PUTODO : Refaire les figures relatives aux requêtes DNS. FAIT. -->

Pour des raisons évidentes de répartition de charge, les serveurs racines sont répliqués. Leurs noms et adresses sont enregistrés dans le fichier ''db.root''. Le serveur DNS local enregistre le contenu de ce fichier dans une partie réservée de la mémoire cache lorsqu’il démarre. Il dispose ainsi des noms et adresses de chacun des serveurs DNS racine. Un serveur racine connaît chacun de ses fils dans l'arbre de nommage du DNS, c'est-à-dire les serveurs en charge des TLD. Il ne dispose localement d’aucune information de nommage. Il n’enregistre pas non plus d'information de nommage dans une mémoire cache. En revanche, en fonction du nom de domaine à résoudre, il sait lequel de ses fils, soit gère la correspondance, soit sait qui la gère. Il fournit donc cette information au serveur DNS local. Notre serveur DNS local s’adresse donc successivement au serveur DNS fils, puis au serveur DNS petit-fils du serveur DNS racine. Il finit par adresser sa demande au serveur DNS ayant autorité sur les informations de nommage recherchées. Le serveur DNS ayant autorité fournit donc ces informations de nommage au serveur DNS local. Celui-ci les enregistre dans sa mémoire cache et les transmet au résolveur à l’origine de la demande. Le résolveur fournit les informations de nommage à l’application à l’origine de la demande. Un explemle de résolution d'adresse est présenté par la figure 4. L'application demande la résolution du FQDN ''tpt.example.com.'' à son résolveur lequel contacte le serveur récursif local. Celui ci contacte le serveur racine puis un serveur en charge du TLD ''.com.'' et enfin le serveur en charge du domaine ''example.com.''. La réponse est alors mise en cache de manière à accélérer la résolution des requêtes suivantes.

  TO DO insérer la figure résolution itérative optimisée depuis un serveur local. Transformer le  

Notez que le serveur DNS local, à chaque étape de la résolution itérative, enregistre dans sa mémoire cache les nom et adresse de chaque serveur DNS interrogé ainsi que les réponses des différents serveurs DNS officiels. Il mutualise donc les informations de nommage pour toutes les machines qui utilisent ses services. Le serveur DNS local, si un résolveur lui pose une question déjà posée par un autre résolveur, fournit immédiatement la réponse à partir de sa mémoire cache lorsque cette information est valide et s’y trouve. Si la question concerne un serveur DNS ayant autorité sur un domaine déjà connu, le serveur DNS local contacte directement le serveur DNS concerné. Notez cependant que les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée. Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

 

Le système DNS distingue, pour une zone donnée, deux types de serveurs de noms : primaire et secondaire. Notez tout d’abord que les serveurs de noms primaire et secondaires pour une zone donnée sont tous des serveurs officiels pour cette zone. Le serveur DNS primaire est le serveur sur lequel l’administrateur du réseau effectue les mises à jour des informations de nommage. Il dispose de fichiers de nommage (les données de zone) enregistrés dans une mémoire locale non volatile. Un serveur DNS primaire peut, par défaut, synchroniser au plus 10 serveurs DNS secondaires. Le numéro de version de chacun des fichiers de zone du serveur DNS primaire change, soit à chaque modification faite par l’administrateur du réseau, soit à l’expiration d’un certain délai en cas de mise à jour dynamique lorsque les mises à jour sont nombreuses.

 

Les serveurs DNS secondaires sont des serveurs de nommage qui acquièrent leurs informations de nommage, soit depuis le serveur DNS primaire, soit depuis un autre serveur DNS secondaire déjà synchronisé, à l’aide d’un protocole de transfert de fichier, par exemple. Notez qu’un serveur DNS secondaire est synchronisé si le numéro de version de chacun de ses fichiers de zone est identique à ceux de chacun des fichiers de zone du serveur DNS primaire. L’administrateur du réseau ne gère les mises à jour du système de nommage qu’au niveau des fichiers de zone du serveur DNS primaire. Il incrémente le numéro de version d’un fichier de zone à chaque modification (c.f. figure 5). Il déclenche la prise en compte des modifications en redémarrant le serveur DNS primaire ou en le réinitialisant (cf. figure 6).

 

 

 

 

 

{{HorsTexte|Redémarrage et réinitialisation d'un serveur DNS|Lorsque l'administrateur redémarre le serveur DNS primaire, celui-ci relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM (''Random Access Memory''). Il n'utilise ensuite que les informations disponibles en RAM. Lorsque l'administrateur réinitialise le serveur DNS, celui-ci ne relit que ses fichiers de zone et les charge en mémoire RAM. Il n'utilise ensuite que les informations disponibles en RAM. }}

 

 

<b>Synchronisation par notification :</b> Lorsque la synchronisation se fait à l’initiative du serveur DNS primaire, ce dernier envoie le nouveau numéro de version de ses fichiers de zone à tous les serveurs DNS secondaires. Tous les serveurs DNS secondaires tentent alors de se synchroniser. La synchronisation peut s’effectuer à partir du seul serveur DNS primaire ou également s’effectuer à partir de serveurs DNS secondaires déjà synchronisés.

 

<b>Synchronisation par interrogation :</b> Lorsque la synchronisation se fait à l’initiative des serveurs DNS secondaires, chaque serveur DNS secondaire vérifie périodiquement le numéro de version de la base de nommage du serveur DNS primaire. Si ce numéro de version de la base de nommage du serveur DNS primaire n’a pas changé, le serveur DNS secondaire attend un certain temps avant de revérifier le numéro de version de la base de nommage du serveur DNS  primaire. Si le numéro de version de la base de nommage du serveur DNS primaire est plus élevé que le sien, le serveur DNS secondaire tente de démarrer une synchronisation de sa base de nommage. Si sa tentative échoue, il attend pendant un certain temps, à l’expiration duquel il tente à nouveau de se synchroniser.

 

 

[[Image:MOOC_Act34_figBJ-11.png|666px|thumb|center|Figure 7 : Transfert des fichiers de zones mises à jour sur le serveur primaire vers les serveurs secondaires.]]

 

 

 

 

 

 

Les résolveurs sont en général incapables d’effectuer la totalité du processus de résolution d’adresse. Ils sont incapables d’interroger directement les serveurs DNS officiels. Ils s’appuient sur un serveur DNS local pour effectuer la résolution. De tels serveurs sont appelés serveurs DNS récursifs ou serveurs DNS "cache". Ces deux termes sont synonymes. Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache. Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

 

 

Un relais DNS peut ne pas effectuer l’intégralité de la recherche lui-même. Il achemine tout ou partie des demandes d’information de nommage reçues et qu’il ne sait pas satisfaire, à partir des données de sa mémoire cache, vers un autre serveur DNS récursif. Ce serveur est dit "relais DNS" (''forwarder''). Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

 

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet. Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes. Les serveurs de relais sont également utiles dans le cas où le délai entre le réseau local et l'Internet est significatif. Dans ce cas, on déploiera un serveur relais dans le réseau local, lequel contactera un serveur récursif déployé ailleurs sur l'internet.

 

 

 

 

 

Rappelons que, pour les applications, une phase pendant laquelle le client DNS local, appelé ''stub resolver'', interroge son serveur DNS récursif (ou cache), précède la communication. Le service DNS fonctionne au niveau de la couche application de la pile TCP/IP. Il s'applique de manière analogue aux réseaux IPv6 et aux réseaux IPv4.

 

 

 

 

L'adresse est écrite suivant la représentation classique des adresses IPv6 (RFC 4291) (représentation hexadécimale pointée). Par exemple, l'adresse IPv6 de la machine ''ns3.nic.fr'' est publiée dans le fichier de zone ''nic.fr'' comme suit :

 

 

Notez que toutes les adresses IPv4 et/ou IPv6 correspondant à un nom de domaine donné (c'est le cas d'un réseau configuré en double pile de communication, ''dual-stack''), doivent cohabiter dans le même fichier de zone renseignant le nom de domaine en question. Ainsi, les adresses de ''ns3.nic.fr'' sont publiées dans le fichier de zone ''nic.fr'' comme suit :

 

 

Cependant, il faut rester vigilant avec une telle configuration puisque certains résolveurs recherchent prioritairement un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le résolveur n'a qu'une connexion IPv6 limitée (une simple adresse locale au lien). Dans ce cas, cet hôte attend l’expiration du délai d’attente d’établissement de la session IPv6 avant de revenir à l’utilisation d’IPv4.

===Nommage inverse : enregistrement PTR===

Trouver le nom de domaine associé à une adresse est un problème quasi insoluble. Néanmoins, une astuce permet de résoudre élégamment ce problème. Il suffit de présenter les adresses comme des noms (succession des noms de domaines conduisant, dans l’arbre de nommage, d’une feuille à la racine de l’arborescence).  

C'est-à-dire que, pour IPv4, il suffit d’écrire l’adresse IP en miroir : au lieu de commencer l’écriture d’une adresse par les octets de poids fort, on commence par celle des octets de poids faible.

<!-- PU : C'est vrai uniquement si on a des adresses de classe A B C. Pour le CIDR ça se complique -->

Pour IPv6, on considère une adresse IPv6 comme une succession de chiffres hexadécimaux (32 quartets par adresse IPv6) séparés par des «.». Une adresse IPv6 est donc transformée en un nom de domaine publié dans le sous-arbre de nommage réservé à la résolution inverse pour IPv6 (ip6.arpa) de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère '.' et concaténés dans l'ordre inverse au suffixe ip6.arpa. Par exemple, l'adresse <tt>2001:660:3006:1::1:1</tt> (adresse de ''ns3.nic.fr'') donne le nom de domaine suivant :

1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.8.0.6.6.0.1.0.0.2.ip6.arpa.

L'administrateur de la zone inverse concernée publie alors, dans le DNS inverse, l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''. En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS. Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

Ainsi, pour une zone inverse donnée, l’administrateur de la zone gère localement la base de correspondance nom-adresse et les bases de données de résolution inverse, à raison d’une par lien dans la zone.

<!--Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version. Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

L'ensemble des fichiers de correspondance directe et inverse constituent, la base de nommage d'un serveur DNS. Le numéro de la base de nommage change dès que le numéro de version d'un de ces fichiers change, c'est-à-dire, dès qu'il a été modifié.

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP, lequel est identique pour IPv4 et IPv6 (cf. figure 9).  

# L'IANA délègue (en termes de provision) de grands blocs d'adresses IPv6 aux registres Internet régionaux (RIR : ''Regional Internet Registry''), typiquement des préfixes de longueur 12 selon la politique actuelle.  

# Les RIR provisionnent des blocs d'adresses IPv6 plus petits pour les registres Internet locaux (LIR : ''Local Internet Registry''), c'est-à-dire aux fournisseurs d'accès Internet locaux, typiquement des préfixes de longueur 32 bits, ou plus courts selon le besoin. Notez que, dans les régions APNIC et LACNIC, des registres nationaux intermédiaires (NIR) existent entre le RIR et les LIR présents dans ces pays.

# Les LIR attribuent des préfixes IPv6 aux clients finaux. Ces préfixes ont typiquement une longueur variable entre 48 et 64 bits. La longueur du préfixe varie selon le besoin du client et selon la politique du LIR en vigueur).  

[[Image:Fig6-1.png|666px|thumb|center|Figure 9 : Délégation du nommage inverse.]]

<!--La figure montre qu’une liste de serveurs DNS est associée à chaque nœud présent dans le sous-arbre de nommage DNS inverse. Cette liste inclut généralement un serveur DNS primaire et un ou plusieurs serveurs DNS secondaires, tous considérés des serveurs DNS officiels pour cette zone DNS inverse. -->

L’administrateur d’un site responsable du nommage publie (ou non, en fonction de la politique locale) les enregistrements PTR correspondant aux adresses IPv6 qu'il utilise dans ses zones DNS inverse.  

Par exemple, Renater a reçu le préfixe <tt>2001:660::/32</tt> et la délégation de la zone DNS inverse 0.6.6.0.1.0.0.2.ip6.arpa de la part du RIPE-NCC. Renater a affecté le préfixe <tt>2001:660:3006::/48</tt> à l'AFNIC et lui a délégué la zone DNS inverse correspondante :

6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.

6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.

L'AFNIC publie alors dans sa zone DNS inverse les enregistrements PTR correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS :

$ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.

1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.

==Découverte de la liste de serveurs DNS récursifs ==

Pour renforcer le déploiement d'IPv6, la communauté IPv6 a mis en œuvre un mécanisme de découverte automatique des serveurs DNS récursifs avec ou sans DHCPv6. Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF. La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs. Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il 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.  

===Extension de l’autoconfiguration "sans état" pour le DNS ===

Le RFC 4862 spécifie l'autoconfiguration IPv6 "sans état". Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs. Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL). Avec ces deux options, les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.  

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6. Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées. L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.  

====Option de liste de serveurs DNS récursifs (RDNSS)====

Cette option d’annonce de routeur contient l’adresse IPv6 d’un ou plusieurs serveurs DNS récursifs (cf. figure 10).

[[Image:MOOC_Act34_Fig1.png|400px|center|thumb|Figure 10 : Format d'une option RDNSS de la RFC 6106.]]

# Le champ <tt>longueur</tt> indique la longueur totale de l’option. Les champs <tt>type</tt> et <tt>longueur</tt> sont inclus (en multiples de 8 octets). Ce champ permet à l’utilisateur de calculer facilement le nombre d’adresses de serveurs DNS récursifs.

# Le champ <tt>durée de vie</tt> indique la durée de vie maximum (en secondes) des adresses associées. Les valeurs de ce champ permettent que la machine sache si elle peut utiliser ces adresses, si leur durée de vie est infinie, si elle doit les rafraîchir ou si elle ne peut plus les utiliser.

# Le champ <tt>addresses</tt> contient les adresses IPv6 des serveurs DNS récursifs, codées sur 128 bits.

====Option de liste de domaines recherchés (DNSSL)====

L’option DNSSL contient un ou plusieurs suffixes de noms de domaines (cf. figure 11). Tous ces suffixes ont la même durée de vie. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.  

[[Image:MOOC_Act34_Fig2.png|400px|center|thumb|Figure 11 : Format d'une option DNSSL prévu par la RFC 6106.]]

# Le champ <tt>length</tt> indique la longueur totale de l’option, champs <tt>type</tt> et <tt>longueur</tt> inclus (en multiples de 8 octets). Le récepteur de cette option utilise ce champ pour calculer le nombre d’adresses de serveurs DNS récursifs.

# Le champ <tt>lifetime</tt> indique la durée de vie maximum, en seconde, des suffixes associés. Les valeurs de ce champ permettent que la machine sache si elle peut utiliser ces adresses, si leur durée de vie est infinie, si elle doit les rafraîchir ou si elle ne peut plus les utiliser.

# Le champ <tt>noms de domaines</tt> contient la liste des noms de domaines à utiliser pour effectuer les résolutions directes.

Pour simplifier les choses, les noms de domaines ne sont pas compressés. Les bits excédentaires sont mis à 0.

===Extension de la configuration "à état", DHCPv6===

 

 

L’option de serveur DNS récursif de DHCPv6 fournit, par ordre de préférence, une liste d’adresses IPv6 de serveurs DNS récursifs à une machine IPv6. La structure de l’option est la suivante (cf. figure 12) :

# Le champ <tt>longueur</tt> représente la longueur de l’option et elle est exprimée en multiple de 16 octets. La valeur du champ indique le nombre d’adresses de serveurs DNS récursifs contenu dans l’option.

 

<center>

[[Image:MOOC_Act34_Fig3.png|400px|center|thumb|Figure 12 : format de l'option de DHCPv6 spécifiant la liste des serveurs DNS récursifs (RFC 3315).]]

 

Le RFC 3315 prévoit également une option spécifiant la liste des suffixes de noms de domaines (cf. figure 13).

[[Image:MOOC_Act34_Fig4.png|400px|center|thumb|Figure 13 : format de l'option de DHCPv6 spécifiant la liste des suffixes de nom de domaine (RFC 3315).]]

# Le code de l'option <tt>OPTION_DOMAIN_LIST</tt> vaut 24.

# Le champ <tt>Longueur</tt> donne la longueur de l’option en octets.  

# Le champ <tt>Searchlist</tt> contient la liste de suffixes de noms de domaines.  

Les noms de domaines ne sont pas compressés par souci de simplification.

Ces deux options ne peuvent apparaître que dans les messages DHCPv6 : SOLICIT, ADVERTISE, REQUEST, RENEW, REBIND, INFORMATION-REQUEST et REPLY.

Une troisième solution est basée sur les adresses anycast réservées. Elle définit plusieurs adresses réservées dans les fichiers de configuration du résolveur d’une machine IPv6. Le RFC 1546 présente plusieurs pistes. Aucun mécanisme de transport ou protocole n’est donc nécessaire. Cette solution s’appuie sur le routage normal des datagrammes et, selon les cas, un filtrage peut être nécessaire en périphérie du réseau.

Ce service est utilisable lorsque les machines IPv6 souhaitent localiser un hôte supportant un service, sans s’intéresser au serveur qui, lorsqu’il y en a plusieurs, rend le service. Le principe est le suivant : une machine envoie un datagramme vers une adresse anycast. L’interconnexion de réseau assure la remise du datagramme à au plus un serveur et, de préférence, à un seul des serveurs répondant à cette adresse anycast. Lorsque des serveurs sont répliqués, une machine peut, par exemple, accéder à la réplique la plus proche. Un certain nombre de questions se posent dans le cas de services "sans état" et "avec état", notamment lorsque plusieurs serveurs sont susceptibles de répondre.

===Résumé des trois propositions : RA, DHCPv6, anycast===

'''RA :''' Le mécanisme à base d'annonce de routeur (RA) est spécifié dans le RFC 6106. Cette proposition étend l'autoconfiguration "sans état" (RFC 4862). Elle définit de nouvelles options. Ces options enrichissent les annonces de routeurs (RFC 4861) en y ajoutant, sous la forme d’options, les informations relatives au DNS. Cette extension est en cours de standardisation à ce jour.  

'''DHCPv6 :''' Le mécanisme à base de DHCPv6 propose deux solutions légèrement différentes. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646. La première utilise un serveur DHCPv6 "à état" (RFC 3315). Celui-ci annonce l’adresse des serveurs de noms récursifs dans des options (ce serveur alloue dynamiquement les adresses IPv6 et les paramètres de configuration du réseau, en particulier les informations de configuration du service de nommage des clients). La seconde propose une utilisation dans le DHCPv6 "sans état" ou serveur DHCPv6-lite (RFC 3736). Celui-ci n'alloue pas d'adresses IPv6, mais informe simplement les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression...).

Dans les deux cas, si un hôte est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), l’administrateur du réseau doit définir une politique d'arbitrage par un client lorsque les deux listes de serveurs DNS récursifs obtenues par IPv4 et IPv6 sont incohérentes.

'''Anycast : '''Mécanisme à base d'adresses anycast réservées (''Well-known anycast addresses''). Ce mécanisme utilise 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. Elle pose de réels problèmes de fonctionnement avec TCP et avec les applications qui gèrent des états au-dessus d’UDP.

==Mises en œuvre du service DNS ==

Cette partie présente les principaux logiciels supportant IPv6. Elle renvoie vers une liste plus complète de logiciels. Elle détaille ensuite comment configurer un service de nommage autonome en IPv6. Elle donne également des exemples de fichiers de configuration.

===Logiciels DNS supportant IPv6 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive. Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Par ailleurs, certaines distributions logicielles comportent l'implémentation du client et du serveur. D'autres n'incluent que l'implémentation du client ou que celle du serveur. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage (enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS. Néanmoins, certains ne supportent encore IPv6 qu'au niveau de la base de nommage.  

Par exemple, l'ISC : ''Internet Systems Consortium'' développe la distribution BIND9. Cette distribution représente la référence de fait dans le domaine. En effet, il s'agit d'un logiciel complet : client, serveur et outils. Il  intègre toutes les extensions DNS récentes (IPv6, DNSSEC...). Les distributions BIND 9 présentent l'avantage d'être disponibles en code source et en format binaire pour la quasi-totalité des plates-formes (Unix, MS Windows, Apple...). Ainsi, la distribution BIND9 a été choisie comme base pour les exemples de fichiers de configuration.  

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir : serveur DNS récursif ou officiel uniquement. Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité générique. Les performances sont reconnues par des tests comparant, d'un côté, NSD et BIND, et de l'autre, Unbound et BIND montrent la supériorité respective des premiers sur les seconds). La diversité générique concerne la diversité des plates-formes logicielles supportant ces serveurs DNS.

===Principe de configuration d’un serveur DNS ===

Cette partie présente le principe de configuration d’un service DNS autonome. Elle précise également les modifications à effectuer pour relier ce service DNS au service de nommage de l’Internet. Pour configurer un service de nommage, il faut successivement installer le paquetage du serveur de nommage sur les machines "serveur", configurer un serveur DNS primaire, configurer au moins un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

La configuration du serveur DNS primaire comprend la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse. Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service. Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.  

La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone. L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS secondaire. Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

L’analyse du fichier journal (''/var/log/syslog'' par exemple, sur un système Linux) donne des indications précieuses sur les erreurs d’exécution relatives au service de nommage ou leur absence.  

La configuration des clients s’effectue au niveau du fichier (''/etc/resolv.conf'' pour les systèmes Linux, par exemple). Le fichier ''resolv.conf'' contient la déclaration du domaine, jusqu’à trois adresses de serveurs DNS, et une liste de noms de domaines recherchés.  

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent, par défaut, les informations contenues dans le fichier ''resolv.conf''. Notez que l’outil ''nslookup'' n’est plus maintenu. Son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

===Définition des fichiers de zone===

Les fichiers de zone contiennent principalement des enregistrements de ressources (''resource record''). Notez que les recherches ignorent la casse des caractères. Cependant, le DNS conserve la casse des caractères. Les commentaires commencent avec un « ; », et se terminent à la fin de la ligne. Les fichiers de zones sont plus faciles à lire s’ils sont documentés. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressources doivent commencer dans la première colonne d’une ligne.

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse). Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.  

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom). Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux, assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.  

Le fichier de configuration du serveur de nommage, ''named.conf'', relie tous les fichiers de zone.  

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie. Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

Dans le cas d’un service de nommage autonome, le serveur DNS primaire sert également de serveur racine. Nous utilisons dans ce cas un fichier ''db.fakeroot'' au lieu du fichier ''db.cache''.  

===Types d’enregistrement de ressource DNS===

Les principaux enregistrements de ressources du DNS sont de deux types : ceux relatifs à la zone et ceux relatifs aux machines.

 

Les enregistrements relatifs à la zone sont : SOA, NS et MX.

 

 

 

* L'enregistrement de ressource ''NS (Name Server)'' désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée. Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

Les principaux enregistrements relatifs aux machines de la zone sont : A, AAAA, PTR et CNAME.  

* L'enregistrement de ressource ''A'' définit une correspondance nom-adresse IPv4.

* L'enregistrement de ressource ''AAAA'' définit une correspondance nom-adresse IPv6.

* L'enregistrement de ressource ''PTR'' définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.<br/>

* L'enregistrement de ressource ''CNAME'' définit un nom canonique ou un surnom (alias) d’une machine.

===Configuration de serveur DNS ===

Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre. Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS (cf. figure 14). La machine serveur '''s-13-v6''' supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 "à état" sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6). Le relais '''r-13-v6''' supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration "à état" en présence d’un relais DHCPv6. Le client '''c-13-v6''' est doté de deux interfaces de réseau. La première est connectée soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration "sans état".

[[Image:MOOC_Act34_figBJ-17.png|666px|thumb|center|Figure 14 : Réseau virtualisé pour générer ces exemples.]]

La configuration DNS proposée correspond à un domaine DNS autonome où le serveur DNS primaire fait également fonction de serveur DNS racine.

<!--Il y a, en IPv6, un fichier de résolution inverse par lien dans la zone.-->

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents. Le fichier de configuration du serveur de nom BIND 9 est, par exemple sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

====Exemple de contenu du fichier ''/etc/bind9/named.conf''====

// This is the primary configuration file for the BIND DNS server named.  

// structure of BIND configuration files in Debian, *BEFORE* you customize

// this configuration file.  

// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.local";

====Configuration du fonctionnement du serveur====

Le fichier ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif, l’affichage ou non du numéro de version du serveur.

====Contenu du fichier ''named.conf.options''====

auth-nxdomain no;

              2001:db8:330f:a0d1::/64;

              2001:db8:330f:a0d2::/64;

inet 127.0.0.1 port 953

L'option ''listen-on'' peut avoir plusieurs valeurs possibles. Avec la valeur ''any'', le serveur écoute sur toutes les adresses IPv4 opérationnelles.

Si une liste d'adresses IPv4 est spécifiée, le serveur écoutera uniquement les requêtes et réponses reçues sur chacune des interfaces configurées avec une de ces adresses. Si la valeur ''none'' est spécifiée, cela signifie que le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''. Si elle vaut ''any'' le serveur écoute sur toutes les adresses IPv6 opérationnelles. Si une liste d'adresses IPv6 est spécifiée, le serveur écoutera uniquement les requêtes et réponses reçues sur chacune des interfaces configurées avec une de ces adresses. La valeur par défaut est ''none'', ce qui signifie que le serveur ne supporte pas IPv6 (valeur par défaut).

====Exemple de configuration locale du serveur de noms BIND9====

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire). Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type "zone". Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'') la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.  

Voici maintenant un extrait du fichier ''named.conf.local'' de notre serveur DNS autonome.

====Exemple de contenu du fichier ''named.conf.local''====

allow-transfer {

====Contenu du fichier ''named.conf.default-zones''====

zone "127.in-addr.arpa" {

file "/etc/bind/db.127";

type master;

file "/etc/bind/db.255";

====Fichier de zone DNS pour la résolution directe (nom - adresse) ====

Voici, à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6. Notez, dans cet exemple, que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291). Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

; numéro de série

3600 ; refresh (1 heure)

c13.tpt.example.com. IN CNAME c-13-v6.tpt.example.com.

===Fichier de zone DNS inverse en IPv6 ===

Voici les fichiers de zone pour la résolution DNS inverse correspondant au préfixe IPv6 d’un lien.  

====Fichier ''db.131.tpt.example.com.rev''====

2 ; Numéro de série

$ORIGIN 1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa.

7.9.1.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR r-13-v6.tpt.example.com.

====Fichier ''db.132.tpt.example.com.rev''====

$ORIGIN 2.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa.

====Fichier ''db.133.tpt.example.com.rev''====

4 ; Numéro de série

7.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR s-13-v6.tpt.example.com.

===Clients du service de nommage===

Un client DNS, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé ''resolver''. Nous utilisons le terme résolveur. Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.  

====Exemple de fichier de configuration ''/etc/resolv.conf'' d’un serveur de noms====

====Exemple de fichier de configuration ''/etc/resolv.conf'' d’une machine====

domain tpt.example.com

===Outils de vérification de la configuration DNS===  

Outre le résolveur, des outils et commandes dépendent des systèmes d'exploitation existants. Ces outils permettent d'interroger un serveur DNS pour le mettre au point et/ou le dépanner. Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.  

Notez que, lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés. Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS). Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin. Voir le chapitre '''Découverte de la liste de serveurs DNS récursifs'''.

====Exemples d'interrogation d’un serveur DNS avec ''dig'' : résolution directe ====

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @2001:db8:330f:a0d1::53 s-13-v6.tpt.example.com -t aaaa

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10043

r-13-v6.tpt.example.com. 10800 IN AAAA 2001:db8:330f:a0d1::197

root@s-13-v6:/etc/bind# host -t aaaa s-13-v6.tp13.tptfctp.  

s-13-v6.tp13.tptfctp has IPv6 address 2001:db8:330f:a0d1::217

s-13-v6.tp13.tptfctp has IPv6 address 2001:db8:330f:a0d2::217

s-13-v6.tp13.tptfctp has IPv6 address 2001:db8:330f:a0d3::217

s-13-v6.tp13.tptfctp has IPv6 address 2001:db8:330f:a0d4::217

s-13-v6.tp13.tptfctp has IPv6 address 2001:db8:330f:a0d1::53

====Exemple d’interrogation d’un serveur DNS avec la commande ''dig'' : résolution inverse====

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @::1 -x 2001:db8:330f:a0d1::217

; (1 server found)  

;7.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa. IN  PTR

7.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa. 10800IN PTR s-13-v6.tp13.tptfctp.

====Exemple d’interrogation d’un serveur DNS avec la commande ''host'' : résolution inverse====