Revision as of 11:36, 24 June 2015

> MOOC>Contenu>Séquence 3

Le système de nommage (DNS) en IPv6

Ce chapitre présente une introduction au système DNS, ses spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6.

L’introduction présente la problématique à résoudre et les principes généraux de fonctionnement de ce service. Les spécifications du protocole présentent la résolution des noms et la résolution inverse ainsi que les ressources nécessaires pour IPv6. Les principes de mise en œuvre du service DNS expliquent comment configurer un service DNS. Les recommandations opérationnelles pour l’intégration d’IPv6 présentent les nouveaux problèmes que pose IPv6 pour le DNS et présente les recommandations pratiques pour y faire face.

Introduction

Le système de noms de domaine (DNS : Domain Name System) gère la correspondance entre les noms de machines et les adresses IP (IPv4 et/ou IPv6).

Aujourd’hui, les utilisateurs utilisent principalement les noms de machines. Ces noms sont plus faciles à mémoriser que les adresses, et souvent, reflètent la fonction de la machine.

Ainsi www.example.com ou ftp.example.com représentent respectivement les noms des serveurs Web et FTP de la société 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.

Aux débuts de l'Internet, les adresses IPv4 en usage étaient peu nombreuses. Il était donc relativement facile de les stocker dans un fichier centralisé, le fichier hosts.txt (RFC 608).

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

Chacun de ces responsables pouvait 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 pouvait ainsi communiquer avec toutes les machines connues dans ce fichier.

Dès le début des années 80, la croissance exponentielle du nombre d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu la mise à jour et la mémorisation de ces adresses de plus en plus difficile, voire impossible dans des délais raisonnables.

Paul Mockapetris, de l'Université de Californie, a conçu le système des noms de domaine (DNS) en 1983. Il en a écrit la première mise en œuvre, à la demande de Jon Postel.

Le DNS est initialement un service de résolution, de mise à jour et d’enregistrement des correspondances nom-adresse. Il fournit aux utilisateurs l’adresse IP associée à un nom de domaine, et ce, quelle que soit la localisation de ceux-ci. De plus, il distribue la responsabilité de la mise à jour des correspondances nom adresse 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 étant une infrastructure 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.

Hiérarchique. Le système de noms de domaine, pour garantir l’unicité des noms utilise un système de nommage hiérarchique. Le nommage hiérarchique utilise une structure d'arbre. 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 à une feuille. 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 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. 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 la racine à une feuille. Comme un arbre ne contient pas de cycle, chaque feuille n’est accessible que par un seul chemin. Par conséquent dans un arbre de nommage, les noms sont uniques.

Le système de système de fichiers d’Unix utilise un arbre de nommage pour garantir l’unicité des noms de fichiers. Ainsi le nom de fichier utilisé précédemment /etc/hosts. Correspond au chemin d’accès à un fichier dans un arbre de nommage. / désigne la racine de l’arbre. Le nom etc représente le nom d’un répertoire (dossier). Ce répertoire contient des fichiers (ses fils) un de ces fils se nomme hosts. La contrainte est évidemment qu’un « père » ne peut avoir deux fils portant le même nom !

Extensibilité. La structure d'arbre rend le système extensible (scalable). Pour ajouter un nom, il suffit de d’ajouter, dans l’arborescence (entre la racine et les feuilles) un nœud et toute sa descendance et de relier ce nœud à un père, en vérifiant que ce père n’a pas deux fils de même nom.

Ainsi, si l’on considère une nouvelle société dont le nom de domaine est société1.com. Déclarer cette société dans le système de nommage revient à ajouter un fils : société1 sous le nœud (père) com, lequel est lui-même fils de « . » (point), la racine (sans nom) de l’arbre de nommage.

Réparti : 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 correspondant à 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. L’idée simple, mais géniale a été de concevoir un système client-serveur pour cela. A chaque niveau de la hiérarchie de nommage, on associe un serveur de nommage. Chaque serveur gère donc un domaine. Dans ce domaine, il peut gérer des sous-domaines, puis finalement gérer des machines.

Les serveurs 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. Les clients du service de nommage se trouvent uniquement au niveau des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client DNS, le resolveur, par machine. Cela signifie que toutes les applications qui s’exécutent sur une machine et qui ont besoin de résoudre un nom sollicitent le seul et unique client DNS de cette machine, le resolveur.

Le client DNS, le resolveur, résout un nom de façon très simple : il commence par s’adresser à son père et lui demande « Pourrais-tu me fournir l’adresse (ou les adresses) associées à ce nom ? ».

Soit le père, le serveur de nom du domaine local, dispose de la réponse et alors il la fournit au client, soit le père ignore la correspondance, et dans ce cas il demande au client de s’adresser au grand-père et il fournit au client le nom et l’adresse IP du grand-père. Ce processus se répète jusqu’à ce que le client pose la question au serveur racine de l’arborescence.

Le serveur racine connaît tous ses fils. Il ne dispose localement d’aucune information de nommage. 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. De cette façon, notre client DNS, le resolveur, finit par adresser sa demande au serveur officiel qui gère les correspondances nom adresse pour ce domaine. Ce serveur fournit donc la réponse au client DNS. Ce processus d’interrogation est dit itératif car le client adresse successivement au serveur local, a ses ascendants, jusqu’à poser la question au serveur racine, lequel renvoie à un de ses fils. Ce fils sait lequel de ses fils gère la correspondance ou sait lequel de ses fils gère cette correspondance.

Le client DNS finit par poser la question au serveur local qui gère officiellement les correspondances nom-adresse pour la machine cible. Le client DNS est malin, il enregistre les noms et adresses de tous les serveurs consultés dans une mémoire cache. Ceci lui permettra ultérieurement de consulter directement un serveur déjà connu. L’efficacité est alors maximale.

Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs de noms distincts peuvent être regroupés sur une seule machine physique. Ces regroupements permettent de réduire la profondeur de la hiérarchie de serveurs, ce qui permet d’en accélérer le balayage.

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

Equilibrage de charge. Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple, interroger simultanément les deux serveurs pour déterminer lequel est 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.

N’oublions pas néanmoins l’administrateur du réseau, responsable de la gestion du nommage dans sa zone. Pour lui simplifier la vie, le système DNS, distingue deux types de serveurs de noms : primaire et secondaires.

Notez tout d’abord que les serveurs de noms primaire et secondaires sont tous des serveurs officiels pour la zone concernée.

Le serveur 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 enregistrés dans une mémoire non volatile.

Les serveurs secondaires sont des serveurs de nommage qui acquièrent leurs informations de nommage auprès du serveur primaire, à l’aide d’un protocole de transfert de fichier, par exemple. Un serveur secondaire, selon son mode de configuration, peut stocker localement et sur une mémoire non volatile, une copie des fichiers de nommage.

Un serveur secondaire qui enregistre localement et dans une mémoire non volatile une copie de la base de nommage peut, d’une part démarrer de façon autonome en cas de panne catastrophique ou non du serveur primaire, et d’autre part, peut très facilement être transformé en serveur primaire. Il est alors prudent, s’il n’en reste plus, de configurer un ou plusieurs autres serveurs secondaires conservant localement une copie des fichiers de nommage…

Définitions

Introduisons maintenant trois notions importantes pour comprendre le système de nommage et son fonctionnement : domaine, sous-domaine et zone.

Un domaine correspond au nœud racine d’un sous-ensemble (sous-arbre) de l’arbre de nommage. Un domaine, dans une grande entreprise, par exemple, peut comporter plusieurs sous-domaines. Chacun de ces sous-domaines peut, par exemple, correspondre à un service de l’entreprise : personnel, finance, commercial, production, maintenance, recherche et développement.

Si nous supposons que les services production, maintenance, et recherche et développement disposent d’informaticiens capable d’y gérer le nommage, l’administrateur du nommage de cette société peut déléguer la responsabilité du nommage à un informaticien de chacun de ces départements et peut gérer le nommage pour les départements incapables de le prendre en charge : personnel, finance, commercial.

Un sous-domaine est un sous-ensemble d’un domaine donné. Ainsi le domaine société1 est un sous-ensemble du domaine.com. Autrement dit le nœud société1 est un fils du nœud com.

De même, finance est un sous-domaine du domaine société1. Le nom de domaine correspondant serait alors « finance.société1.com. ».

Notez que dans cette façon d’écrire les noms on chemine des feuilles (finance)de l’arbre de nommage vers sa racine (sans nom, représentée par « . »).

Le responsable du nommage de la société gère une zone qui correspond aux sous-domaines : personnel, finance, commercial, et aux informations de délégation de responsabilité pour les sous-domaines : production, maintenance, recherche et développement.

Chacun des informaticiens des départements, production, maintenance, recherche et développement gère les informations de nommage pour son sous-domaine. Si aucun d’eux ne délègue le nommage dans sa zone, ils gèrent chacun une zone et cette zone correspond dans ce cas à un sous-domaine.

Une zone contient tous les noms contenus dans le domaine de même nom, mais exclut tous les noms qui se trouvent dans des sous-domaines délégués (production, maintenance, recherche et développement, par exemple). Une zone peut inclure plusieurs sous-domaines (personnel, finance, commercial) et des informations de délégation de zone.

Spécifications du service de noms

Le DNS avait initialement comme objectif premier d'offrir un service de résolution de noms de domaines Internet complètement qualifié (FQDN : Fully'' Qualified Domain Name) garantissant l'unicité de la conversion du nom (exemple : ns3.nic.fr) en adresses IP et vice-versa.

En pratique, système DNS est un service de base de données à grande échelle. Il permet, plus généralement, de gérer tout type d’information. Il utilise pour cela des enregistrements de ressources (RR : Resource Records) spécifiques de chaque type d’information.

Chacune des applications d’une machine s’adresse au résolveur (unique) de la machine 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 de la machine locale interroge successivement chacun des serveurs (résolution itérative), jusqu’à ce qu’il s’adresse au serveur officiel du domaine concerné.

Le serveur officiel de ce domaine renvoie les informations demandées dans des enregistrements de ressource appropriés. Le résolveur mémorise ces informations dans une mémoire cache, puis les fournit à l’application qui en a fait la demande.

Rappelons au passage que pour ces applications, une phase lors de laquelle le client DNS local, appelé « stub resolver », interroge son serveur DNS récursif (ou cache) précède la communication .le serveur récursif effectue les requêtes itératives nécessaires, en partant de la racine de l'arbre DNS, s'il le faut, et renvoie les ressources demandées.

Par exemple, pour les machines Unix, le fichier /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 à interroger, ce qui lui permet d’initialiser sa recherche d’information pour le compte des applications locales.

Le service de résolution 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.

Les adresses IPv6 sont quatre fois plus grandes que les adresses IPv4 (16 octets). Elles peuvent être attribuées automatiquement ou autoconfigurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, 2001 :3006 ::beef :cafe :deca :102.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. Le service de nommage devient plus que jamais un service critique pour le fonctionnement correct des applications TCP/IP classiques. Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) : l’enregistrement de ressource AAAA et un nouveau sous-domaine : ipv6.arpa.

L'enregistrement de ressource AAAA (prononcé « quad A ») enregistre les correspondances nom - adresse IPv6. Pour le nommage direct (correspondance : nom vers adresse). Ce le code de ce nouveau type vaut 28.

Le nouveau sous-domaine ip6.arpa est dédié à la résolution DNS inverse en IPv6 (correspondance : adresse IPv6 vers nom). La résolution DNS inverse utilise la notion de nibble. Un nibble correspond à un chiffre hexadécimal.

Nommage direct : enregistrement AAAA

La correspondance entre un nom de domaine et son (ou ses) adresse(s) IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque enregistrement de 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 multidomiciliée ou routeur, par exemple)

De manière analogue, 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.

Une requête DNS de type AAAA concernant une machine particulière renvoie dans ce cas tous les enregistrements AAAA publiés dans le DNS et correspondant à cette machine. Toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au paragraphe Publication des enregistrements AAAA dans le DNS.

Le format textuel d'un enregistrement AAAA tel qu'il apparaît dans le fichier de zone DNS est le suivant :

<nom> [ttl] IN AAAA <adresse>

L'adresse est écrite suivant la représentation classique des adresses IPv6 (RFC 4291). 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:3006:3006:1::1:1

notez que toutes les adresses IPv4 et/ou IPv6 correspondant à un équipement 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 l'équipement en question. Ainsi, les adresses de ns3.nic.fr sont publiées dans le fichier de zone nic.fr comme suit :

$ORIGIN nic.fr.
ns3   IN A    192.134.0.49
      IN AAAA 2001:db8:3006:1::1:1

Cependant, il faut rester vigilant avec une telle configuration, puisque certains resolveurs recherchent toujours un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le resolver n'a qu'une connection 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

L'enregistrement de type PTR, est stocké dans le sous-arbre de nommage dédié à la résolution inverse (DNS inverse) in-addr.arpa. Pour IPv4, ce sous-domaine établit la correspondance entre une adresse IPv4 et un (ou plusieurs) nom(s). Pour IPv6, ce même type d'enregistrement PTR, stocké dans le sous-arbre de nommage dédié à la résolution inverse (DNS inverse) ip6.arpa, met en correspondance une adresse IPv6 avec un ou plusieurs noms de domaines.

Notons au passage qu'auparavant, le RFC 1886, rendu obsolète par le RFC 3596, spécifiait une autre arborescence : ip6.int. Cette dernière a été abandonnée en 2006.

Un nom de domaine à partir d’une adresse est un problème quasi insoluble. Néanmoins une astuce permet de résoudre simplement ce problème. Il suffit de présenter les adresses comme des noms. C'est-à-dire que, pour IPv4n, 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. Pour IPv6, on considère une adresse IPv4 comme une succession de chiffres hexadécimaux (32 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 2001:db8:3006:1::1:1 (adresse de ns3.nic.frdonne 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.8.B.d.1.0.0.2.ip6.arpa.

On 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 zones inverses 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.

Ainsi, pour un domaine donné, l’administrateur du domaine 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 le site.

Soulignons que la délégation DNS inverse suit le schéma classique d'attribution des adresses IP. C’est le même pour IPv4 et IPv6).

Schéma de délégation de la gestion des adresses IP

1) L'IANA délègue (en terme 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.

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

3) Les LIR attribuent des préfixes IPv6 aux clients finaux. Ces préfixes ont typiquement des 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).

Figure 6-1 Exemple de délégation de zones inverse

La figure 6-1 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 primaire et un ou plusieurs serveurs secondaires, tous considérés des serveurs 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 2001:660::/32 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 2001:660:3006::/48 à 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.
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.

Mises en œuvre du service DNS

Présentation du principe de configuration d’un serveur DNS

Configuration du fonctionnement du serveur

Configuration de la zone

Configuration des zones inverses

Logiciels DNS supportant IPv6

Il existe aujourd'hui de nombreux logiciels DNS, 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 à cet article sur Wikipedia.

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 données (enregistrements AAAA et PTR) et aussi au niveau transport IPv6 des messages DNS.

Néanmoins, certains ne supportent encore IPv6 qu'au niveau de la base de données.

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.

Par exemple, la distribution http://www.isc.org/downloads/bind/ BIND 9] développée par l'ISC (Internet Systems Consortium) représente la référence de fait dans le domaine. En effet, il s'agit d'un logiciel complet (client, serveur et outils) intégrant toutes les extensions DNS récentes (IPv6, DNSSEC...).

Les distributions BIND 9 ont l'avantage d'être disponibles en code source et en format binaire pour la quasi-totalité des plates-formes (Unix, MS Windows*...). Ainsi, la distribution BIND 9 a été choisie comme base pour les exemples de fichiers de configuration.

Notons 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, 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 récursif pour l'une et/ou l'autre deux raisons : leurs performances et leurs diversité génétique.

• Performances. leurs performances sont reconnues (des tests de performances 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) ;
• Diversité génétique. La diversité générique concerne la diversité des plates-formes

logicielles supportant ces serveurs.

Clients et outils de vérification de configurations DNS

Un client DNS, résolveur, se présente souvent sous forme d'une bibliothèque de nommage. Cette dernière se nomme « libresolv ». Ce client est appelé « resolver » ou encore « stub resolver ».

Rappelons que ce resolveur est sollicité par les applications TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

Outre le resolveur, Des outils et commandes dépendant des systèmes d'exploitation existent. Ils permettent d'interroger un serveur DNS dans un but de mettre au point et/ou dépanner. Par exemple, les outils dig, host et nslookup font partie des distributions BIND. 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 sont interrogés.

Il peut, par exemple, s’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 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 dans la section découverte de la liste de serveurs DNS récursifs, Voir Découverte de la liste de serveurs DNS récursifs.

L'exemple suivant décrit le fichier resolv.conf d’un système Unix :

search nic.fr # domaine de recherche par défaut
nameserver ::1 # prefer localhost-v6
nameserver 192.134.4.162 # backup v4

Exemples d'interrogation d’un serveur DNS avec dig

Les six exemples suivants illustrent l'utilisation des outils résolveur dig, host et nslookup pour obtenir l’adresse IPv6 de la machine `ns3.nic.fr'.

$ dig ns3.nic.fr aaaa
; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa
;; global options: printcmd

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3032
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 172800 IN AAAA 2001:db8:3006:1::1:1

;; AUTHORITY SECTION:
nic.fr. 78032 IN NS ns1.nic.fr.
nic.fr. 78032 IN NS ns2.nic.fr.
nic.fr. 78032 IN NS ns3.nic.fr.
nic.fr. 78032 IN NS ns-sec.ripe.net.
[...]

;; ADDITIONAL SECTION:
ns1.nic.fr. 78032 IN A 192.93.0.1
ns1.nic.fr. 17168 IN AAAA 2001:db8:3005:1::1:1
ns2.nic.fr. 25737 IN A 192.93.0.4
ns2.nic.fr. 25737 IN AAAA 2001:db8:3005:1::1:2
ns-sec.ripe.net. 96368 IN A 193.0.0.196
ns-sec.ripe.net. 96368 IN AAAA 2001:610:240:0:53::4
 
;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Oct 25 19:13:54 2007
;; MSG SIZE rcvd: 350

 $ dig ns3.nic.fr aaaa @ns.ripe.net
; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa @ns-sec.ripe.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16927
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 5

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 345600 IN AAAA 2001:db8:3006:1::1:1
;; AUTHORITY SECTION:

[...]
;; SERVER: 2001:610:240:0:53::4#53(ns-sec.ripe.net)

$ host -t aaaa ns3.nic.fr
ns3.nic.fr has AAAA address 2001:db8:3006:1::1:1

$ host -t aaaa ns3.nic.fr ns.ripe.net
Using domain server:
Name: ns.ripe.net
Address: 2001:67c:e0::6#53
Aliases:

ns3.nic.fr has AAAA address 2001:db8:3006:1::1:1

Dans les exemples 1, 3 et 5, la requête est envoyée au serveur récursif par défaut (2001:db8:3003:2::1:1). Dans les exemples 2, 4 et 6, la requête est envoyée au serveur ns.ripe.net (qui est secondaire pour la zone nic.fr).

L'AFNIC utilise la deuxième version de l’ooutil ZoneCheck pour vérifier et valider la configurationde la délégation de zones DNS des domaines .fr et .re. Cet outil supporte complètement IPv6.

ZoneCheck interroge la liste de ses serveurs officiels d’une zone DNS pour vérifier leur bon fonctionnement et la bonne configuration de la zone DNS en question.

Cet outil vérifie le bon fonctionnement, en termes de transports UDP et TCP, au-dessus d'IPv4 et d'IPv6, si IPv6 est supporté. Il vérifie également la cohérence de la base de données. C'est-à-dire, celle des enregistrements DNS sur les différents serveurs officiels.

Configuration de serveur/zone 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 avons choisi de fournir des exemples suivant la syntaxe et les règles de BIND 9. Ce logiciel estconsidéré aujourd'hui comme l'implémentation de référence.

Fichier de configuration d'un serveur BIND9

La configuration d’un serveur BIND9 concerne quatre aspects : la configuration du fonctionnement du serveur, la configuration du statut du serveur, primaire ou secondaire, la configuration du fichier de zone pour la résolution nom - adresse et la configuration des fichiers de zone pour la résolution inverse. Il y a un fichier de zone par lien ou sous-réseau dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’d’inclure d’autres fichiers gérant spécifiquement un 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.

Configuration du fonctionnement du serveur. Le fichier option contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif

Configuration des zones. Le fichier confient les chemins d’accès aux zones pour lesquelles le serveur est officiel, il définit également le chemin d'accès aux données (option directory) et le rôle du serveur pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur (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, on indique (à l'aide de la sous-rubrique slave ) la liste des adresses IPv4 et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici maintenant un extrait du fichier named.conf du serveur DNS ns3.nic.fr :

options {
  directory "/usr/local/bind";
  recursion no;
  listen-on { any; };
  listen-on-v6 { any; };
  [...]
};

L'option listen-on peut avoir comme valeurs possibles :

• any : dans ce cas-là, le serveur écoutera sur toutes ces adresses IPv4 opérationnelles ;
• une liste explicite comprenant une ou plusieurs adresses IPv4 données : le serveur écoutera uniquement sur ses adresses pour ce qui est du transport IPv4 des requêtes et réponses ;
• none : pas de support d'IPv4

Par défaut, le serveur de nom BIND 9 ne va pas écouter les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option listen-on-v6

L'option listen-on-v6 peut avoir comme valeurs possibles :

• any : dans ce cas-là, le serveur écoutera sur toutes ses adresses IPv6 opérationnelles ;
• une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoutera uniquement sur ces adresses pour ce qui est du transport IPv6 des requêtes et réponses ;
• none : pas de support d'IPv6 (valeur par défaut).

[...]
zone "." {
  type hint;
  file "named.root";
};
zone "localhost" {
  type master;
  file "localhost";
};
// Zone contenant l'enregistrement inverse pour l'adresse loopback en IPv4
zone "0.0.127.in-addr.arpa" {
  type master;
  file "localhost.rev";
}; 
// Zone inverse (sous ipv6.arpa) contenant l'enregistrement inverse pour 
// l'adresse loopback en IPv6
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
  type master;
  file "localhost.rev";
};
[...]
zone "nic.fr" {
  type slave;
  file "zone/nic.fr";
  masters {
    2001:db8:3005:1::1:1; 192.93.0.1;
    2001:db8:3005:1::1:2; 192.93.0.4;
  };
};
[...]
// Zone inverse IPv4 pour la réseau AFNIC-SFINX en 192.134.0/24
zone "0.134.192.in-addr.arpa" {
  type slave;
  file "rev/nic.fr.192.134.0";
  masters {
    2001:db8:3005:1::1:1; 192.93.0.1;
    2001:db8:3005:1::1:2; 192.93.0.4;
  };
};
[...]
// Blocs Ripe sous ip6.arpa.
zone "6.0.1.0.0.2.ip6.arpa" {
  type slave;
  file "rev/6.0.1.0.0.2.ip6.arpa";
  masters {
    2001:610:240:0:53::3;
    193.0.0.195;
  };
};
[...]
// Zone inverse IPv6 pour le reseau AFNIC-SFINX en 2001:db8:3006::/48
zone "6.0.0.3.0.8.B.d.1.0.0.2.ip6.arpa" {
  type slave;
  file "rev/6.0.0.3.0.8.B.d.1.0.0.2.ip6.arpa";
  masters {
    2001:db8:3005:1::1:1; 192.93.0.1;
    2001:db8:3005:1::1:2; 192.93.0.4;
  };
};
[...]

Les cinq premières zones déclarées font partie de la configuration d'un serveur BIND de base. Les quatre zones restantes sont données à titre d'exemple parmi les nombreuses zones sur lesquelles le serveur ns3.nic.fr fait autorité.

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

Voici à titre d'exemple, un extrait du fichier de zone DNS direct `nic.fr', faisant apparaître en même temps des adresses IPv4 et IPv6.

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

$TTL 172800
$ORIGIN nic.fr.
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
                2007102200 ;serial
                21600 ;refresh (6 h)
                3600 ;retry (1 h)
                3600000 ;expire
                86400 ) ;minimum (2 j)

IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]

IN MX 10 mx1.nic.fr.
IN MX 20 mx2.nic.fr.
[...]

ns1    IN A 192.93.0.1
       IN AAAA 2001:db8:3005:1::1:1
ns2    IN A 192.93.0.4
       IN AAAA 2001:db8:3005:1::1:2
ns3    IN A 192.134.0.49
       IN AAAA 2001:db8:3006:1::1:1
[...]

www      IN CNAME rigolo
rigolo   IN A 192.134.4.20
         IN AAAA 2001:db8:3003:2::4:20
kerkenna IN A 192.134.4.98
         IN AAAA 2001:db8:3003:8::4:98
[...]

Fichier de zone DNS inverse en IPv6

Voici un extrait de fichier de zone DNS inverse correspondant au préfixe IPv6 2001:db8:3003::/48 (réseau AFNIC-Saint-Quentin-en-Yvelines) et représentant quelques enregistrements de type PTR d'équipements supportant IPv6 :

$ORIGIN 3.0.0.3.0.8.B.d.1.0.0.2.ip6.arpa.
$TTL 172800
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
               2007031200 ;serial
               43200 ;refresh (12 h)
               14400 ;retry (4 h)
               3600000 ;expire
               3600 );

IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]

0.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR rigolo.nic.fr.
7.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR funk.nic.fr.
1.3.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR wood.nic.fr.
8.9.0.0.4.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0 IN PTR kerkenna.nic.fr.
[...]

1.4. Recommandations opérationnelles pour l'intégration d'IPv6

Comme cela a été décrit dans l'introduction de ce chapitre, le DNS a la particularité d'être à la fois une application TCP/IP et une infrastructure critique.

Le DNS est une application critique prcequ’elle permet à toutes les autres autres applications TCP/IP classiques (web, mail, ftp, ...) de fonctionner.

Le DNS est une infrastructure critique car c’est la base de données distribuée la plus grande échelle qui soit.

L'intégration progressive d'IPv6, entraîne de nouveaux problèmes opérationnels liés au DNS : la fragmentation de l’espace de nommage,

Il convient donc, soit de les éviter, soit de trouver les solutions adéquate pour y remédier.

À cet effet les RFC 3901 et RFC 4472 identifient les principaux problèmes et formulent une série de recommandations pratiques pour y faire face. Les sections qui suivent tentent de résumer ces recommandations

1.4.1. Les deux aspects du DNS

Le DNS supporte les enregistrements A et AAAA et ce, indépendamment de la version d'IP qui est utilisée pour transporter les requêtes et réponses DNS relatives à ces enregistrements.

Par ailleurs, en tant qu'application TCP/IP, un serveur DNS utilise les transports UDP IPv4 ou IPv6 ou les deux à la fois.

Dans tous les cas, le serveur DNS doit satisfaire une requête donnée en revoyant les informations qu'il a dans sa base de données, indépendamment de la version d'IP sur laquelle il a reçu cette requête.

Un serveur DNS ne peut pas, a priori, savoir si le résolveur initiateur de la requête l’a transmis à son serveur récursif (cache) en utilisant IPv4 ou en IPv6.

En effet des serveurs intermédiaires (cache forwarders) peuvent intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs intermédiaires (cache forwarders) n'utilisent pas nécessairement la même version d'IP que leurs clients.

En outre, en supposant que le serveur DNS puisse connaître la version d'IP utilisée par le client qui a initié la requête, notez qu’il n'a pas à faire d'hypothèse sur l'usage de la réponse DNS renvoyée par le client.

1.4.2. Impossibilités d’accès au service DNS et remèdes

Cette partie présente deux scénarios où l’accès au DNS est impossible et les remèdes qui permettent d’éviter cette situation.

Avant IPv6, le processus de résolution DNS ne faisait intervenir qu’IPv4. Le service était donc garanti pour tous les clients DNS.

Avec IPv6, on risque de se trouver confronté à des cas où l'espace de nommage est fragmenté où certains fragments de cet espace ne sont accessibles que via IPv4, et d'autres ne sont accessibles que via IPv6.

Voici par exemple deux scénarios illustrant ce problème de fragmentation de l’espace d’adressage ainsi que la solution recommandée dans chaque scénario :

Premier scénario : client IPv4 et serveur IPv6

Un client ne supportant qu'IPv4 envoie une requête relative à une zone DNS hébergée sur des serveurs ne supportant qu'IPv6. Dans ce cas, le processus de résolution échoue du fait de l'impossibilité d'accéder aux serveurs officiels de cette zone.

Faire en sorte que toute zone DNS soit servie par au moins un serveur officiel supportant IPv4 remédie à ce problème.

Second scénario : client IPv6 et serveur IPv4

Un client ne supportant qu'IPv6 envoie une requête relative à une zone DNS hébergée sur des serveurs ne supportant qu'IPv4. Si le serveur récursif interrogé ne supporte pas non plus IPv4, le processus de résolution risque d'échouer du fait de l’impossibilité pour ce serveur récursif de joindre les serveurs officiels de la zone concernée supportant IPv6.

Configurer le serveur récursif en le faisant pointer vers un serveur forwarder en double pile IPv4/IPv6 remédie à ce problème.

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option :

forwarders {<liste des adresses de serveurs forwarders> ;}

sous la rubrique « options » dans le fichier named.conf.

1.4.3. Taille limitée des messages DNS en UDP

Les implémentations DNS s'appuient essentiellement sur deux standards de l'IETF (RFC 1034 et RFC 1035). De nombreux autres RFC complémentaires ont été publiés plus tard pour clarifier certains aspects pratiques ou pour apporter de nouvelles extensions répondant à de nouveaux besoins (enregistrements AAAA, SRV, extensions DNSSEC, ...). Le DNS, en tant qu'application TCP/IP, doit supporter les deux modes de transport UDP et TCP (RFC 1035), le port associé à l’application DNS est le même pour TCP et UDP : 53.

Le protocole de transport UDP est généralement utilisé pour acheminer les requêtes/réponses DNS. Le protocole de transport TCP est généralement utilisé pour les transferts de zones entre serveur primaire et secondaires.

Lorsque le DNS utilise le protocole de transport UDP, la taille des messages DNS est limitée à 512 octets. Certaines requêtes, trop grandes pour être acheminées par UDP provoquent le sont par TCP.

Dans ce cas, le client reçoit, dans un premier temps, un message dont la section réponse (answer' section) est vide et dont le bit TC (Truncated) est positionné. Ceci signifie implicitement que le client est invité à réinterroger le serveur en utilisant TCP.

Notez que ce scénario constitue une justification du fait que le port 53 en TCP ne doit pas être ouvert exclusivement pour des transferts de zones et qu'un recours trop fréquent à TCP risque de consommer davantage de ressources, et par conséquent, de dégrader les performances du serveur DNS.

Certains nouveaux types d'enregistrements (AAAA) risquent d'augmenter significativement la taille des réponses DNS. ceci risque donc d’accoître le nombre de recours à TCP pour satisfaire les requêtes/réponses DNS.

Aujourd'hui, ces dépassemens sont rares. La plupart des réponses DNS ont une taille qui ne dépasse guère 400 octets. En effet, les sections answer, authority et additional, qui constituent l’essentiel de la réponse DNS, ne contiennent qu'un nombre limité d'enregistrements lorsque cette réponse ne concerne pas directement une zone racine telle que .com, .net, .fr, .de...

Face à ce risque, l’IETF a proposé l'extension EDNS.0 du protocole DNS (RFC 6891. Cette extension est déjà déployée dans les versions récentes des logiciels DNS. Elle permet qu’ un client DNS informe le serveur interrogé qu’il supporte des réponses de taille supérieure à la limite des 512 octets (par exemple, 4096 octets). Ainsi, en présence d'IPv6, le support de l’extension du DNS, 'EDNS.0, devient fortement recommandé.

Notez également que le support d'EDNS.0 devient aussi indispensable en présence des extensions de sécurité de DNS, DNSSEC.

Le faible taux de pénétration d'EDNS.0 dans les logiciels DNS, surtout les clients est resté pendant plusieurs années un des principaux motifs du refus de l'IANA/ICANN de publier de nouvelles adresses (IPv4 ou IPv6) pour des serveurs racine.

Depuis le 4 février 2008, l'IANA publie l'adresse IPv6 (enregistrement AAAA) des serveurs racine supportant le transport IPv6 dans la zone racine. La nouvelle version du fichier de de démarrage named.root de BIND 9) contient également ces adresses.

Notez enfin que des informations sur les adresses IPv4 et IPv6 des serveurs de la racine ainsi que sur la répartition géographique de ces serveurs sont publiées sur le site web : [[1]].

1.4.4. Glue IPv6

La zone racine publie également les adresses des différents serveurs DNS de chacun des domaines racines (TLD : Top Level Domain). Ces adresses, appelées « glues » sont nécessaires au démarrage du processus de résolution.

En effet, rappelons que les serveurs DNS de la racine ne sont pas censés répondre eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs racine (TLD).

Les informations d'aiguillage incluent la liste des serveur racine sous lequel se trouve la ressource. Elles incluent également les adresses (glues) de ces serveurs. Sans ces adresses, la résolution ne peut se faire. Le client aurait le nom du serveur, mais pas son adresse et ne pourrait l’obtenir…

En attendant que les serveurs racine puissent recevoir des requêtes DNS et répondre en IPv6, les domaines racine TLD avaient pendant des années milité pour l'introduction des « glues » IPv6 qui leurs sont associées dans la zone racine.

L'IANA/ICANN a fini par être convaincue que la publication des adresses IPv6 des serveurs DNS racines supportant IPv6 pouvaitt se faire sans risque pour la stabilité du DNS.

L'ICANN/IANA a démarré, en juillet 2004, la publication des adresses IPv6 des domaines racines TLD dans la zone racine. Les trois TLD .fr, .jp et .kr ont les premiers vu leur glue IPv6 publiée.

1.4.5. Publication des enregistrements AAAA dans le DNS

On choisit généralement de publier dans le DNS les enregistrements AAAA d’un équipement donné lorsque l'on souhaite que les applications communiquant avec cet équipement découvrent le support du transport IPv6.

Par exemple, un navigateur supportant IPv6, découvre ainsi grâce au DNS qu'il est possible d’accéder en IPv6 au site http://www.afnic.fr/. Il peut alors choisir de privilégier la connexion HTTP au serveur en IPv4 ou en IPv6.

Or avec l'intégration progressive d'IPv6 l'adresse IPv6 d’un équipement peut être publiée dans le DNS. certaines applications s'exécutant sur cet équipement peuvent ne pas supporter IPv6.

La situation suivante risque donc de se produire :

L'équipement foo.example.com héberge plusieurs services : web, ftp, mail, DNS. Les serveurs Web et DNS s'exécutant sur foo.example.com supportent IPv6, mais pas les serveurs FTP et mail.Une adresse IPv6 est publiée dans le DNS pour foo.example.com ;

Un client FTP supportant IPv6 tente d’accéder au serveur de notre équipement : foo.example.com. Le client choisit l'adresse IPv6 de foo.example.com comme adresse destination. La tentative d’accès au serveur FTP en IPv6 échoue. Selon les implémentations, les clients tentent ou non d’utiliser d'autres adresses IPv6 s'il y en a ou finissent ou non par tenter d’y accéder, en dernier recours, en IPv4.

Pour pallier à ce problème l’IETF recommande d'associer des noms DNS aux services et non aux équipements.

Ainsi, pour notre exemple précédent, il serait judicieux de publier dans le DNS, d'une part, les noms www.example.com et ns.example.com associés à des adresses IPv6, et éventuellement, des adresses IPv4, et d'autre part, les noms ftp.example.com et mail.example.com associés uniquement àdes adresses IPv4.

L'enregistrement AAAA pour foo.example.com ne serait alors publié que lorsque l'on a la certitude que toutes les applications s'exécutant sur cet équipement supportent IPv6.

Par ailleurs, le DNS étant une ressource publique, il est fortement déconseillé (sauf si l'administrateur DNS sait très bien ce qu'il fait !) d'y publier des adresses IPv6 non joignables de l'extérieur, soit à cause d'une portée faible (adresses locale au lien, par exemple), soit parce que toutes les communications provenant de l'extérieur du réseau et allant vers ces adresses sont filtrées.

Notez que cette règle est déjà appliquée pour les adresses IPv4 privées (RFC 1918) et que certains logiciels DNS récents supportent aujourd'hui les vues DNS. On parle de two''-face DNS, de split-view DNS ou encore de split DNS.

Avec ce système de vues, la réponse à une requête DNS dépend de l'origine du client. Par exemple un client appartenant au réseau interne verra les adresses privées des équipements alors que les clients externes ne verront eux que les adresses globales et accessibles de l'extérieur.

Pour aller plus loin : Enregistrement et mise à jour du DNS par les clients

TODO: Parler du DNS Dynamic Update pour les adresses IPv6 auto-configurées