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

<!-- {{Decouverte}} -->

==Introduction==

Cette activité introduit le système de nommage communément appelé 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==

Le DNS est un système de base de données hiérarchique et distribué. Il gère les correspondances directes entre les noms de machines (FQDN : ''Fully Qualified Domain Name'') et les adresses IP (IPv4 et/ou IPv6), et les correspondances inverses entre les adresses IP (IPv4 et/ou IPv6) et les noms de machines.  

Le DNS gère également d’autres informations : par exemple, les informations relatives aux agents de transfert de courrier (''Mail eXchanger'', MX) ou encore celles relatives aux serveurs de noms (''Name Servers'', NS) et, plus généralement, d’autres informations utiles pour les applications TCP/IP.  

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms logiques sont plus faciles à mémoriser que les adresses, et souvent, reflètent la fonction de la machine.  Ainsi, ''www.tpt.example.com'' ou ''ftp.tpt.example.com'' représentent respectivement les noms des serveurs Web et FTP de la société '' tpt.example.com''.

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. A l'instar d'un répertoire téléphonique, le DNS est un annuaire global assurant la correspondance entre les noms logiques de machines et leurs références IP, essentiellement leurs adresses, mais d'autres informations techniques peuvent également être référencées.  

===Nommage « à plat »===

Aux débuts de l'Internet, les adresses IPv4 en usage sont peu nombreuses. Il est donc relativement facile de les stocker dans un fichier centralisé : le fichier ''hosts.txt'' (RFC 608). Les noms doivent aussi être uniques. Un nom utilisé dans une organisation ne peut alors pas l’être dans une autre organisation.

Chaque responsable de site transmet ses modifications, ajouts et suppressions à un centre de gestion chargé de mettre à jour le fichier central.

Dès le début des années 80, la croissance exponentielle du nombre de noms et d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu le choix des noms, leur mise à jour, et la mémorisation des adresses dans ce fichier central de plus en plus difficile, voire impossible dans des délais raisonnables. Ce système a donc été abandonné au profit du système de nommage.

===Caractéristiques du système de noms de domaine===

Paul Mockapetris, de l'Université de Californie, conçoit le système de nommage DNS en 1983. Il en écrit la première mise en œuvre à la demande de Jon Postel.  Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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'est imposé 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>Hiérarchique.</b> Le système de nommage est hiérarchique, pour garantir l’unicité des noms. Le système de nommage hiérarchique utilise une structure d'arbre (cf. figure 1). Un arbre est un graphe sans cycle, c'est-à-dire un ensemble de nœuds reliés par des arcs tel qu’il n’existe qu’un seul chemin reliant la racine de l’arbre à chacune de ses feuilles. Un arbre, à son plus haut niveau, se compose d’une racine et d’un ensemble de nœud « fils ». Chaque fils, dans l’arbre, est relié à son père par un arc. Chaque fils, au second niveau, possède à son tour ses propres fils. Et ainsi de suite jusqu'aux feuilles de l’arbre. Une feuille de l’arbre est un nœud qui n’a pas de fils.  Le nommage hiérarchique associe un nom à chaque nœud d’un arbre : l’arbre de nommage. Un domaine correspond à un nœud dans l’arbre de nommage. Chaque nœud, sauf la racine, a un nom. Le nom d’un domaine est alors défini comme la succession des noms des nœuds qui, dans l’arbre de nommage, conduisent de ce nœud à la racine de l’arbre de nommage. Comme un arbre ne contient pas de cycle, chaque nœud n’est accessible que par un seul chemin. Par conséquent, dans un arbre de nommage, les noms de domaines sont uniques.

{{HorsTexte|Arbres informatiques|Les arbres informatiques sont couramment représentés avec la racine positionnée en haut et les feuilles (nœuds sans fils) en bas. Différentes méthodes algorithmiques permettent un parcours efficace de ces structures de données.}}

[[Image:MOOC_dns_figBJ-1.png|666px|thumb|center|Figure 1 : Arbre de nommage.]]

Les nœuds du premier niveau ''(les fils de la racine)'' sont couramment dénommés ''Top Level Domain'' (TLD).

Le nommage se fait, soit en fonction du secteur d’activité, soit en fonction du code pays (ISO). Deux sous-arbres, sous le TLD réservé "arpa" sont dédiés à la résolution inverse : ''in-addr'' pour IPv4 et ''ip6'' pour IPv6.  

* <b>Réparti.</b> Nul n’est mieux placé que le responsable du nommage dans un domaine (de responsabilité administrative), par exemple celui d’une société, pour gérer les ajouts, modifications, suppressions dans le sous-arbre de nommage de cette société. Chaque responsable du nommage gère le nommage dans sa société. Il produit donc une base locale de nommage. Reste ensuite à partager ces informations pour les mettre à disposition des utilisateurs du réseau.  

* <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.  

** ''Équilibrage de charge''. Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple, interroger simultanément les deux serveurs pour déterminer celui des deux qui est le moins sollicité, et utiliser préférentiellement ses services. En cas de non réponse du serveur choisi, le client peut interroger l’autre serveur pour obtenir les réponses à ses questions. En pratique, les demandes des différents clients se répartissent sur les différents serveurs de noms. Et si deux serveurs ne peuvent supporter la charge, il suffit d’en ajouter d’autres.  

[[Image:MOOC_dns_figBJ-2.png|666px|thumb|center|Figure 2 : Extension de l'arbre de nommage.]]

L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela, concrètement basée sur une arborescence de serveurs.

Un serveur DNS est associé à chaque nœud de l’arbre de nommage. En fait, pour des raisons administratives, l’espace de nommage est partitionné en zones, correspondant à des "sous-arbres". Selon le principe de délégation de responsabilité administrative, chaque zone est autonome et responsable de son étendue de nommage.

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).

Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.

[[Image:MOOC_dns_figBJ-4.png|666px|thumb|center|Figure 3 : Réduction de la profondeur de la  hiérarchie de serveurs : avant après.]]

Les clients du service de nommage ne se trouvent qu’au niveau des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client du service de nommage par machine, le résolveur.  Cela signifie que toutes les applications qui s’exécutent sur une machine et qui doivent résoudre un nom sollicitent le seul et unique client DNS de cette machine, le résolveur.

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 ('' Au niveau des systèmes d'exploitation des machines, le resolveur DNS est généralement nativement implanté dans le code de mise en œuvre de la pile IP)''. Pour l’utiliser, les programmes d’application invoquent les procédures de la bibliothèque ''(selon le mécanisme des appels système)''.  

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

-->

[[Image:MOOC_dns_figBJ-5.b.jpg|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_dns_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. -->

On notera que toutes les résolutions itératives démarrent par la racine et que cette dernière pointe vers les serveurs des TLD. 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 (le serveur administrativement responsable du TLD), 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 exemple 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 ultérieures.

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é.

=== Les serveurs de noms ===

L'arborescence des serveurs de noms est composée de plusieurs types de serveurs fonctionnels répartis sur le réseau internet.

====Serveurs de noms primaires et secondaires====

{{HorsTexte|Gestion des données de zone|À l'origine, les données administratives d'une zone étaient gérées par l'administrateur dans de simples fichiers texte. Aujourd'hui, les fournisseurs d'accès à Internet ainsi que les prestataires du service DNS, administrant des zones dont le contenu est volumineux, ont délaissés les fichiers à plat au profit de systèmes de bases de données ou d'annuaires LDAP.}}

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 secondaire 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).

[[Image:MOOC_dns_figBJ-8.png|666px|thumb|center|Figure 5 : Mise à jour d'un fichier de zone du serveur DNS primaire par l'administrateur du réseau.]]

[[Image:MOOC_dns_figBJ-9.png|666px|thumb|center|Figure 6 : Mise à jour d'un  fichier de zone et réinitialisation du serveur DNS primaire par l'administrateur du réseau.]]

{{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. }}

Il configure le mode de déclenchement de la synchronisation des serveurs DNS secondaires, soit à l’initiative du serveur DNS primaire (notification), soit à l’initiative des serveurs DNS secondaires (interrogation).  

<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 attend le temps fixé par la période de scrutation 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_dns_figBJ-11.png|666px|thumb|center|Figure 7 : Transfert des fichiers de zones mises à jour sur le serveur primaire vers les serveurs secondaires.]]

Ainsi, les serveurs qui le peuvent (10 maximum) se synchronisent immédiatement. Les autres attendent pendant une durée au minimum égale au temps de synchronisation de la première vague puis, tentent à nouveau de se synchroniser (cf. figure 7). Notez, qu’ici encore, l’administrateur du réseau peut optimiser le délai de synchronisation en configurant de façon appropriée les serveurs DNS secondaires pour qu’ils se synchronisent à partir du serveur DNS primaire et des serveurs DNS secondaires déjà synchronisés. Il suffit pour cela de définir les serveurs DNS secondaires qui se synchronisent immédiatement, ceux qui se synchronisent dans un deuxième, un troisième, et éventuellement dans un quatrième temps (cf. figure 8).

[[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 8 : Optimisation du transfert des fichiers de zones via l'utilisation de serveurs secondaires déjà synchronisés.]]

Notez qu’un serveur DNS secondaire peut, selon son mode de configuration, stocker localement et sur une mémoire non volatile, une copie des fichiers de nommage. S’il enregistre localement, et dans une mémoire non volatile, une copie de ses fichiers de zone, il peut d’une part, démarrer de façon autonome en cas de panne, catastrophique ou non, du serveur DNS primaire, et d’autre part, très facilement être transformé, si nécessaire, en serveur DNS primaire. Cette bonne pratique est recommandée par l’IETF car elle contribue à la réplication des fichiers de zone.

====Serveur DNS récursif (''caching name server'')====

Les résolveurs sont en général incapables d’effectuer la totalité du processus de résolution d’adresse ''(cf. schéma de principe de la résolution de la figure 4)''. 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 (serveurs DNS généralement en zone dite ''démilitarisée (DMZ)'' de "l'autre coté" du par feu et autorisés à accéder à l'Internet public). 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.

Un serveur DNS BIND ''(BIND Berkeley Internet Name Domain server est l'implémentation logicielle de référence d'un serveur DNS)'' peut simultanément se comporter comme un serveur ayant autorité en qualité de serveur primaire pour certaines zones, secondaire pour d'autres, et se comporter comme serveur DNS récursif pour un certain nombre de clients.  

Les fonctions des serveurs DNS officiels et récursifs sont habituellement activées sur des machines distinctes. Un serveur DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr. Un serveur DNS non officiel et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu. Un serveur DNS peut cependant être configuré comme serveur officiel pour tous les utilisateurs et n'accepter les requêtes récursives que pour les utilisateurs du réseau interne.

===Spécifications du service de nommage===

==== Spécifications du résolveur ====  

Rappelons que pour les applications communicantes (une session web par exemple), une phase pendant laquelle le client DNS local, appelé ''stub resolver'', interroge son serveur DNS récursif (ou cache), précède l’établissement effectif 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.

<!-- Le serveur DNS récursif effectue les requêtes itératives nécessaires, en partant, s'il le faut, de la racine de l'arbre de nommage et renvoie les ressources demandées. -->

{{HorsTexte|Singularité du service DNS|Notez que le DNS est le seul service de l’internet pour lequel le client doit absolument être configuré avec l’adresse IP d’au moins un serveur DNS. C’est généralement l’adresse d’un serveur DNS local. Les adresses IPv6 étant quatre fois plus grande que celle de IPv4, il est d'autant moins probable que les utilisateurs puissent les retenir, ce qui rend le DNS d'autant plus indispensable.}}

Pour les machines Unix, par exemple, le fichier de configuration du client DNS, ''/etc/resolv.conf'', fournit l'adresse IP d’un ou plusieurs serveurs de noms. Le résolveur, lorsqu’il démarre, lit ce fichier de configuration. Il dispose donc de l’adresse d’un ou plusieurs serveurs DNS à interroger, ce qui lui permet d’initialiser sa recherche d’information de nommage pour le compte des applications locales. Dans la pratique, ce fichier est renseigné soit manuellement par l'administrateur de la machine soit, plus généralement, automatiquement lors de la procédure d'auto-configuration avec ou sans état selon les principes détaillés ci-dessous dans le paragraphe intitulé "Découverte de la liste des serveurs DNS récursifs".

Les adresses IPv6 sont quatre fois plus grandes que les adresses IPv4 (16 octets). Elles peuvent être attribuées automatiquement ou auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''. Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. -->

Les ressources logiques de la base de données répartie du DNS sont gérées sous forme d'enregistrements de ressource communément appelées ''Ressource Record'' ou RR. Différents types de RR ont été spécifiés tels que ceux déjà évoqués dans ce documment : RR de type A pour une correspondance d'adresse IPv4, RR de type NS pour un serveur de domaine, ou encore RR de type MX ''(Mail eXchanger)'' pour une correspondance entre un domaine et son ou ses relais de messagerie.

Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) : l’enregistrement de ressource de type AAAA, et un nouveau sous-domaine dédié à la résolution inverse (adresse-nom) en IPv6 : ''ip6.arpa''.

* Le RR de type AAAA ''(prononcé « quad A »)'' enregistre les correspondances nom - adresse IPv6. Le code réservé de ce nouveau type d’enregistrement de ressources vaut 28.

* Le nouveau sous-domaine ''<tt>ip6.arpa.</tt>'' est dédié à la résolution DNS inverse en IPv6 (correspondance "adresse IPv6" vers "nom"). La résolution DNS inverse utilise, pour IPv6, la notion de quartet (''nibble''). ''Rappel : un quartet correspond à un chiffre hexadécimal. Comme nous l'avons vu en séquence 1, une adresse IPv6 est composée de 32 quartets.''

===Nommage direct : enregistrement AAAA ===

Le nouveau type d'enregistrement AAAA, défini pour IPv6, établit la correspondance entre un nom de domaine et ses adresses IPv6. Une machine ayant plusieurs adresses IPv6 globales a, en principe, autant d’enregistrements AAAA publiés dans le DNS. <!--Nous verrons quelques restrictions dans le chapitre ''Deux impossibilités d’accéder au service de nommage''.-->

''(De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque RR type A contient la valeur d’une adresse IPv4. Une machine a autant d’enregistrements de type A qu’elle a d’adresses IPv4 (machine multi-domiciliée ou routeur, par exemple))''.

L'adresse est écrite suivant la représentation classique des adresses IPv6 ''(RFC 4291) (représentation hexadécimale pointée, l'usage de la notation canonique (RFC 5952) est probablement une bonne pratique mais n'est cependant pas obligatoire)''. Par exemple, l'adresse IPv6 de la machine ''ns3.nic.fr'' est publiée dans le fichier de zone ''nic.fr'' comme suit :  

  ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1

Notez que toutes les adresses IPv4 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 :

    IN AAAA 2001:660:3006:1::1:1

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.

<!-- PU : C'est vraiment le résolveur qui est responsable ? C'est l'algo implementé dans la pile IP qui va demander au résolveur une IPv6 plutôt qu'une IPv4 non ? -->

===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. Ainsi l'adresse IPv4 192.168.1.150 pourrait être référencée sous le nom 150.1.168.192.in-addr.arpa dans le DNS inverse.

<!-- 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 (mode miroir) 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.0.6.6.0.1.0.0.2.ip6.arpa.

'''''Note : ''''' ''les quartets à zéro sont significatifs pour cette transformation de l'adresse inverse en nom. Il n'y a donc pas de contraction possible pour cette notation, les 32 quartets (y compris nuls) doivent être notés.''

L'administrateur de la zone inverse concernée publie alors, dans le DNS inverse, l'enregistrement de type PTR ''(PoinTeR)'' correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, le RR de type PTR vaut ''ns3.nic.fr''. En pratique, on procède par délégation de zone inverse, dérivée des préfixes IPv6, 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é.

Notez que pour optimiser le processus de synchronisation des serveurs DNS secondaires, il suffit de ne transmettre que les fichiers modifiés.-->

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 ns2.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.

''''' Note : ''''' ''astuce : la clause $ORIGIN ''(macro)'' en début de fichier zone permet de définir un suffixe commun à chacun des enregistrements PTR de la zone. En positionnant ce suffixe à la valeur inverse du préfixe IPv6 concaténé à la valeur réservée <tt>ip6.arpa.</tt>, on simplifie la notation des enregistrements PTR. Ceux-ci se résument alors à la notation inverse des parties SID et IID de l'adresse.''

==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 :

===Principe des trois propositions : RA, DHCPv6, anycast===

#'''RA :''' le mécanisme à base d'annonce de routeur (RA) est spécifié dans le RFC 8106. 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 8415). 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 8415). 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.

===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 8106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS : ''Recursive DNS Server'') et une option pour définir la liste des noms de domaines recherchés (DNSSL : ''DNS Search List''). 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''.

La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 1 de cette activité.

Le RFC 8415 spécifie le protocole d'autoconfiguration "à état", DHCPv6 : Dynamic Host Configuration Protocol version 6. Ce protocole fournit également les informations de configuration de l’accès au service DNS d’une machine IPv6.