MOOC:Compagnon Act34-s6
From Livre IPv6
Contents
- 1 Concepts de base du système de noms de domaine, DNS
- 1.1 Nommage « à plat »
- 1.2 Caractéristiques du système de noms de domaine
- 1.3 Principe de fonctionnement du service DNS
- 1.4 Serveurs de noms primaires et secondaires
- 1.5 Serveur DNS récursif (caching name server)
- 1.6 Relais DNS (forwarder)
- 1.7 Serveurs DNS à rôles multiples
- 1.8 Spécifications du service de nommage
- 1.9 Nommage direct : enregistrement AAAA
- 1.10 Nommage inverse : enregistrement PTR
- 2 Découverte de la liste de serveurs DNS récursifs
- 3 Mises en œuvre du service DNS
- 3.1 Logiciels DNS supportant IPv6
- 3.2 Présentation du principe de configuration d’un serveur DNS
- 3.3 Définition des fichiers de zone
- 3.4 Types d’enregistrement
- 3.5 Configuration de serveur/zone DNS
- 3.5.1 Fichier de configuration d'un serveur BIND9
- 3.5.2 Contenu du fichier /etc/bind9/named.conf
- 3.5.3 Configuration du fonctionnement du serveur
- 3.5.4 Contenu du fichier named.conf.options
- 3.5.5 Configuration locale du serveur de noms BIND9
- 3.5.6 Contenu du fichier named.conf.local
- 3.5.7 Contenu du fichier named.conf.default-zones
- 3.5.8 Fichier de zone DNS pour la résolution nom - adresse (DNS direct)
- 3.6 Fichier de zone DNS inverse en IPv6
- 3.7 Clients du service de nommage
- 3.8 Outils de vérification de la configurations DNS
- 3.8.1 Exemples d'interrogation d’un serveur DNS avec dig : résolution directe
- 3.8.2 Exemple d’interrogation d’un serveur DNS avec la commande host : résolution directe
- 3.8.3 =Exemple d’interrogation d’un serveur DNS avec la commande dig : résolution inverse
- 3.8.4 Exemple d’interrogation d’un serveur DNS avec la commande host : résolution inverse
- 4 Recommandations opérationnelles pour l'intégration d'IPv6
- 5 Conclusion
= Système de nommage (DNS) en IPv6 Ce chapitre présente une introduction au système de nommage, le 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 autonome en IPv6.
Les recommandations opérationnelles pour l’intégration d’IPv6 présentent les nouveaux problèmes que pose IPv6 pour le DNS. Elles présentent les recommandations pratiques pour y faire face.
Concepts de base du système de noms de domaine, DNS
Le système de nommage (DNS : Domain Name System) est un système de base de données hiérarchique et distribuée. 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 (FQDN : Fully Qualified Domain Name).
Il gère également d’autres informations, par exemple, les informations relatives 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 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.
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.
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.
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 : Domain Name System, 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 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'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.
Hiérarchique. Le système de nommage, utilise un système de nommage hiérarchique pour garantir l’unicité des noms.
Le système de 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 à 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.
TODO insérer la figure 1
Figure 1. Arbre de nommage. Le nommage se fait, soit en fonction du secteur d’activité, soit en fonction du code pays (ISO). Deux sous-arbres sont dédiées à la résolution inverse : in-addr pour IPv4 et ip6 pour IPv6. 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 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.
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 à 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.
Equilibrage 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.
Extensible. La structure d'arbre est extensible (scalable). Pour ajouter un nom, il suffit, dans l’arbre (entre la racine et les feuilles) d’ajouter, 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.
L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela.
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.
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. Un serveur de nommage officiel gère les données d’une zone.
Une zone correspond à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative.
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.
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.
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.
Principe de fonctionnement du service DNS
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). Initialement, 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 résolveur de chaque machine gère donc localement un cache des informations de nommage. Cela accélère le traitement des requêtes ultérieures, mais s’accompagne d’une réplication potentielle des mêmes informations au niveau de chaque machine. 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. Aujourd’hui, pour optimiser 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.
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. La résolution itérative des requêtes des clients est alors déportée au niveau du serveur DNS local.
Le serveur DNS local résout un nom de façon très simple : il commence par s’adresser à son serveur DNS père et lui demande « Pourrais-tu me fournir l’adresse (ou les adresses) associées à ce nom ? ».
Le serveur DNS père peut, soit disposer de la réponse et il la fournit alors au serveur DNS local, soit ignorer la réponse, et dans ce cas, il demande au serveur DNS local de s’adresser au serveur DNS grand-père. Il fournit alors au serveur DNS local, son client, le nom et l’adresse IP du grand-père.
Le serveur DNS local enregistre alors ces informations dans sa mémoire cache. Il interroge alors le serveur grand-père à qui il repose la même question.
Ce processus se répète jusqu’à ce que le client pose la question au serveur racine de l’arbre.
Notez qu’une optimisation du système consiste à ce que le serveur DNS local interroge directement la racine de l’arbre lorsque son serveur DNS père ne dispose pas des informations de nommage demandées.
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. Il ne dispose localement d’aucune information de nommage. Il n’enregistre également pas 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 officiel qui gère les informations de nommage recherchées.
Le serveur DNS officiel concerné 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.
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 lorsqu’elle s’y trouve. Si la question concerne le serveur déjà connu d’un domaine, le serveur DNS local contacte directement le serveur de nommage concerné. Dans ces deux cas, le traitement des demandes est accéléré.
Notez que les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée. Lorsqu’une demande concerne des données présentes dans la mémoire cache du serveur de nommage et dont la durée de vie a expiré, celui-ci redemande directement cette information au serveur officiel du domaine concerné.
Notez également que lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, elles sont inutilisables fournir des réponses aux applications. Tout se passe de ce point de vue comme si elles ne se trouvaient pas dans la mémoire cache.
Serveurs de noms primaires et secondaires
Le système DNS distingue, pour une zone donnée, deux types de serveurs de noms : primaire et secondaires.
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.
Un serveur DNS secondaire, par exemple de premier niveau, peut jouer le rôle de serveur DNS primaire pour la synchronisation d’un serveur DNS secondaire, de second niveau.
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. Il déclenche la prise en compte des modifications en redémarrant le serveur DNS primaire. 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).
Notification. 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.
Synchronisation à partir du seul serveur DNS primaire. Dix serveurs DNS secondaires, au plus par défaut, peuvent immédiatement établir une session de synchronisation avec le serveur DNS primaire.
Les autres serveurs DNS secondaires attendent pendant un temps supérieur ou égal au délai de synchronisation des serveurs DNS secondaires.
Lorsque les dix premiers serveurs DNS secondaires sont synchronisés, une deuxième vague de 10 serveurs DNS secondaires peut éventuellement démarrer sa synchronisation à partir du serveur DNS primaire.
Les serveurs DNS secondaires qui n’ont pas pu établir de session de synchronisation avec le serveur DNS primaire attendent.
Ce processus continue jusqu’à ce que tous les serveurs DNS secondaires soient synchronisés.
Dans ce processus, les serveurs DNS secondaires se synchronisent 10 par 10, ce qui peut durer longtemps lorsqu’ils sont nombreux.
Synchronisation à partir du serveur DNS primaire et des serveurs DNS secondaires déjà synchronisés. Dans ce cas, l’administrateur du réseau peut avoir configuré chacun des serveurs DNS secondaires synchronisés pour qu’ils notifient leur changement de numéro de version de fichiers de zone à 10 serveurs DNS secondaires de deuxième niveau.
Ainsi dans les domaines de très grande taille où un grand nombre de serveurs DNS secondaires existe, tous ne peuvent alors pas, en pratique, se synchroniser à partir du seul serveur DNS primaire. La synchronisation 10 par 10 de ces serveurs DNS secondaires prendrait trop de temps.
Pour accélérer la synchronisation. Une fois les dix premiers serveurs DNS secondaires synchronisés, le serveur DNS primaire et chacun de ces dix serveurs DNS secondaires synchronisés peuvent à leur tour prendre en charge 10 serveurs DNS secondaires, soit 110 serveurs DNS secondaires. Et si cela ne suffit pas, les serveurs DNS secondaires synchronisés lors des première et seconde vagues de synchronisation permettent la synchronisation d’une troisième vague de 1210 serveurs DNS secondaires ((1+10+110)*10=1210).
Notez que de cette façon, la synchronisation d’un grand nombre de serveurs DNS secondaires est possible rapidement.
Cependant, dans la mesure où un grand nombre de serveurs DNS secondaires se synchronisent simultanément. Une quantité éventuellement importante de bande passante du réseau risque d’être indisponible pendant la phase de synchronisation des serveurs DNS secondaires. Ceci explique la limitation à 10 par défaut du nombre de synchronisations simultanées autorisées au niveau d’un serveur DNS.
L’administrateur du réseau peut modifier cette valeur pour l’adapter à son environnement.
Interrogation. 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 ne 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 (au minimum la durée de la synchronisation), à l’expiration duquel il tente à nouveau de se synchroniser.
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.
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.
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.
Il est alors prudent, s’il ne reste plus alors de secondaire, de configurer un ou plusieurs autres serveurs DNS secondaires conservant une copie des fichiers de zone, localement, dans une mémoire non volatile…
Notez également que 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. 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 serveur 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.
Relais DNS (forwarder)
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 récursif. Ce serveur est dit relais DNS (forwarder).
Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogés à 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.
Serveurs DNS à rôles multiples
Un serveur BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur cache pour un certain nombre de clients.
Cependant comme les fonctions des serveurs DNS officiels et récursifs sont logiquement séparées, il est souvent bénéfique de les activer sur des machines distinctes.
Un serveur 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 récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.
Spécifications du service de nommage
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 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.
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.
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.
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. 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:330f::beef:cafe:deca:102.
Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 dédié à la résolution inverse (adresse-nom) en IPv6, ip6.arpa.
L'enregistrement de ressource AAAA (prononcé « quad A ») enregistre les correspondances nom - adresse IPv6. Le code de ce nouveau type d’enregistrement de ressource 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, pour IPv6, la notion de quartet (nibble). Un quartet correspond à un chiffre hexadécimal.
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 relatif aux deux impossibilités d’accéder au service de nommage.
De façon analogue, 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).
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.
Notez que toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au chapitre 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] (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 :
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 résolveurs recherchent prioritairement un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le resolveur 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.
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 2001:660:3006:1::1:1 (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.
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. Ceci facilite la gestion des données de résolution inverse.
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 la zone.
Notez que la délégation DNS inverse suit le schéma classique d'attribution des adresses IP (identique pour IPv4 et IPv6).
1) 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.
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).
TODO insérer la figure
Figure Exemple de délégation de zones inverses.
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 oDNS fficiels 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.
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 ddes 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. Nous présenterons ensuite un résumé de ces trois propositions.
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 (cache). 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). Ces deux options permettent aux machines IPv6 de configurer complètement leur accès au service DNS pour accéder aux services de l’internet (c'est-à-dire 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.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (25) | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Addresses of IPv6 Recursive DNS Servers | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type. Le champ type a pour valeur 25.
Length. Ce champ indique la longueur totale de l’option. Les champs types et longueur sont inclus (en multiples de 8 octets). Ce champ permet que l’utilisateur calcule facilement le nombre d’adresses de serveurs DNS récursifs.
Lifetime. Ce champ indique la durée de vie durée de vie maximum (en seconde) 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.
Addresses. Ces champs contiennent les adresses IPv6 des serveurs DNS récursifs, codées sur 128 bits.
Option de liste de domaine recherchés (DNSSL)
L’option DNSSL contient un ou plusieurs suffixes de noms de domaines. Tous ces suffixes ont la même durée de vie. Des durées de vies différentes sont possibles pour des suffixes de noms de domaines contenus dans des options DNSSL différentes.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (31) | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Domain Names of DNS Search List : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type. Le champ type a pour valeur 31.
Length. Ce champ indique la longueur totale de l’option, champs type et longueur 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.
Lifetime. Ce champ 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.
Noms de domaines. Ce champ 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 à états, DHCPv6
Le [RFC 3315] spécifie le protocole d'autoconfiguration à états, 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.
Option serveur de nom récursif de 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.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DNS_SERVERS (23) | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-recursive-name-server (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-recursive-name-server (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPTION_DNS_SERVERS. Le code option vaut 23.
option-len. La longueur de l’option 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.
DNS-recursive-name-server. Ce champ contient l’adresse IPv6 d’un serveur DNS récursif. Il peut apparaître plusieurs fois.
Option liste de suffixes de nom de domaine
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DOMAIN_LIST (24) | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | searchlist | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPTION_DOMAIN_LIST. Le code de cette option vaut 24.
Option-len. Ce champ donne la longueur de l’option en octets.
Searchlist. Ce champ donne la liste de suffixes de nom de domaine. 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.
Utilisation d’adresses anycast réservées
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 états et avec états, notamment lorsque plusieurs serveurs sont susceptibles de répondre.
Voici maintenant un 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 propose une utilisation dans le DHCPv6 à états, la seconde propose une utilisation dans le DHCPv6 sans état.
DHCPv6 à états. Un DHCPv6 à états [RFC 3315] 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).
DHCPv6 sans état. Un serveur DHCPv6-lite ou DHCPv6 sans état [RFC 3736] 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, un équipement est en double pile, et s'il 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
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 à la comparaison des logiciels DNS 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, 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) 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, 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 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 de deux raisons : les performances et la diversité génétique.
Performances. Les 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.
Présentation du 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 noms sur les machines serveur, configurer un serveur primaire, configurer un serveur secondaire et configurer le fichier de configuration des clients du service de nommage.
La configuration du serveur 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.
La configuration du serveur 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 fournssent les fichiers de zone. (Il faut également déclarer les serveurs secondaires autorisés au niveau du serveur primaire). L’outil named-checkconf vérifie les fichiers de configuration du serveur secondaire.
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 (ou leur absence) relatives au service de nommage.
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 de noms 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.
Notez que l’outil nslookup n’est plus maintenu, son utilisation est déconseillée. Nous ne présentons donc pas son utilisation.
Définition des fichiers de zone
Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).
La première étape de la configuration d’un serveur de noms primaire correspond à la conversion de la table des machines 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 d’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 et sert pour la résolution inverse des noms en IPv6.
Le serveur primaire a un fichier de résolution inverse pour l’adresse de boucle locale. Chaque serveur, primaire ou secondaire est maître pour cette zone. En effet personne n’a reçu la délégation pour le réseau 127/24, ni pour ::1/128. Chaque serveur doit donc en être responsable.
Le fichier de configuration du serveur de noms, named.conf relie tous les fichiers de zone.
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.
Notez que les fichiers de zones sont plus faciles à lire s’ils sont documentés et que l’ordre des enregistrements n’a aucune importance. Notez également que les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.
Un serveur de noms 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. Dans le cas d’un service de nommage autonome, le serveur primaire sert également de serveur racine. Nous utilisons dans ce cas un fichier db.fakeroot au lieu du fichier db.cache.
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 d’en rapatrier localement une version à jour.
Types d’enregistrement
Les principaux types d’enregistrements de ressource du DNS sont les suivants.
- L’enregistrement SOA : Start Of Authority indique qui est le serveur primaire officiel de la zone. Il n’y en a qu’un par zone. La syntaxe de l’enregistrement SOA est la suivante : SOA nom du serveur primaire officiel, adresse mail de l’administrateur du service de noms (numéro de série, délai de rafraîchissement, délai avant nouvel essai, délai d’expiration de l’information, durée maximum de conservation d’une réponse négative dans le cache d’un serveur de noms)
- L’enregistrement NS : Name Server indique un serveur officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs de noms officiels pour une zone donnée.
- L'enregistrement MX : Mail eXchanger indique un agent de fransfert de courrier officiel pour une zone donnée.
Les autres enregistrements concernent les machines de la zone.
- L’enregistrement A définit une correspondance nom-adresse IPv4.
- L’enregistrement AAAA définit une correspondance nom-adresse IPv6.
- L’enregistrement PTR définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.
- L’enregistrement CNAME définit un nom canonique ou un surnom (alias) d’une machine.
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 est considéré aujourd'hui comme l'implémentation de référence.
Fichier de configuration d'un serveur BIND9
La configuration d’un serveur primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution nom – adresse, la configuration des fichiers de zone pour la résolution inverse adresse – nom, et la mise au point du service. Il y a un fichier de résolution inverse 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’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.
Contenu du fichier /etc/bind9/named.conf
// This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian.gz for information on the // 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.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones";
Configuration du fonctionnement du serveur
Le fichier option 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êtesDNS 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
options {
directory "/var/bind";
auth-nxdomain no;
listen-on { any; };
listen-on-v6 { any; };
version none;
allow-query-cache { any; };
allow-query { any; };
allow-recursion {
2001:db8:330f:a0d1::/64;
2001:db8:330f:a0d2::/64;
2001:db8:330f:a0d1::/64;
};
};
include "/etc/bind/rndc-key";
controls {
inet 127.0.0.1 port 953
allow {127.0.0.1; ::1; } keys { "rndc-key"; };
};
L'option listen-on peut avoir comme valeurs possibles :
• any : dans ce cas, le serveur écoute sur toutes les adresses IPv4 opérationnelles.
• une liste explicite comprenant une ou plusieurs adresses IPv4 données : le serveur écoute 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 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.
L'option listen-on-v6 peut avoir comme valeurs possibles : any : dans ce cas, le serveur écoute sur toutes ses adresses IPv6 opérationnelles, une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoute 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).
Configuration locale du serveur de noms BIND9
Le fichier named.conf.local contient les chemins d’accès aux zones pour lesquelles le serveur 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 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.local de notre serveur de noms de domaine autonome.
Contenu du fichier named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//
include "/etc/bind/zones.rfc1918";
//zones primaires
//
//
//
// Déclaration de la zone tpt.example.com
//
//
zone "tpt.example.com" {
type master;
file "/etc/bind/db.tpt.example.com";
allow-transfer {
2001:db8:330f:a0d1::197;
2001:db8:330f:a0d2::197;
};
};
//
// Déclaration des zones inverses
//
//
// 2001:db8:330f:a0d1::/64
//
zone "1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa." {
type master;
file "/etc/bind/db.131.tpt.example.com.rev";
allow-transfer {
2001:db8:330f:a0d1::197;
2001:db8:330f:a0d2::197;
};
};
//
// 2001:db8:330f:a0d2::/64
//
zone "2.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa." {
type master;
file "/etc/bind/db.132.tpt.example.com.rev";
allow-transfer {
2001:db8:330f:a0d1::197;
2001:db8:330f:a0d2::197;
};
};
//
// 2001:db8:330f:a0d3::/64
//
zone "3.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa." {
type master;
file "/etc/bind/db.132.tpt.example.com.rev";
allow-transfer {
2001:db8:330f:a0d1::197;
2001:db8:330f:a0d2::197;
};
};
//
// Zones secondaires
//
Contenu du fichier named.conf.default-zones
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.fakeroot";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
Fichier de zone DNS pour la résolution nom - adresse (DNS direct)
Voici à titre d'exemple, un extrait du fichier de zone DNS direct tpt.example.com. Elle ne fait apparaître que les adresses IPv6.
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 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.
$TTL 3h tpt.example.com. IN SOA s-13-v6.tpt.example.com. r-13-v6.tpt.example.com. ( 3 ; numéro de série 3600 ; refresh (1 heure) 900 ; nouvel essai (15 minutes) 3600000 ; expiration (5 semaines jours 16 heures) 1h) ; durée de vie minimum (1 heure) @ IN NS s-13-v6.tpt.example.com. @ IN NS r-13-v6.tpt.example.com. s-13-v6.tpt.example.com. IN AAAA 2001:db8:330f:a0d1::217 AAAA 2001:db8:330f:a0d1::53 AAAA 2001:db8:330f:a0d2::217 AAAA 2001:db8:330f:a0d3::217 AAAA 2001:db8:330f:a0d4::217 r-13-v6.tpt.example.com. IN AAAA 2001:db8:330f:a0d1::197 AAAA 2001:db8:330f:a0d2::197 c-13-v6.tpt.example.com. IN AAAA 2001:db8:330f:a0d1::187 AAAA 2001:db8:330f:a0d2::187 s13.tpt.example.com. IN CNAME s-13-v6.tpt.example.com. r13.tpt.example.com. IN CNAME r-13-v6.tpt.example.com. 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.
Fichier db.131.tpt.example.com.rev
$TTL 3h ; @ IN SOA s-13-v6.tpt.example.com. root.s- 13-v6.tpt.example.com. ( 2 ; Numéro de série 3600 ; rafraîchissement (1 heure) 900 ; Nouvelle tentative (15 minutes) 3600000 ; Durée de vie maximale (5 semaines 6 jours et 16 heures) 1h ) ; Durée de vie minimale (1 heure) ; @ IN NS s-13-v6.tpt.example.com. @ IN NS r-13-v6.tpt.example.com. $ORIGIN 1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa. 3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR s-13-v6.tpt.example.com. 7.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR s-13-v6.tpt.example.com. 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
$TTL 3h ; @ IN SOA s-13-v6.tpt.example.com. root.s-13-v6.tpt.example.com. ( 2 ; Numéro de série 3600 ; rafraîchissement (1 heure) 900 ; Nouvelle tentative (15 minutes) 3600000 ; Durée de vie maximale (5 semaines 6 jours ; et 16 heures) 1h ) ; Durée de vie minimale (1 heure) ; @ IN NS s-13-v6.tpt.example.com. @ IN NS r-13-v6.tpt.example.com. $ORIGIN 2.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.133.tpt.example.com.rev
$TTL 3h ; @ IN SOA s-13-v6.tpt.example.com. nobody.localhost. ( 4 ; Numéro de série 3600 ; rafraîchissement (1 heure) 900 ; Nouvelle tentative (15 minutes) 3600000 ; Durée de vie maximale (5 semaines 6 jours et 16 heures) 1h ) ; Durée de vie minimale (1 heure) ; @ IN NS s-13-v6.tpt.example.com. @ IN NS r-13-v6.tpt.example.com. $ORIGIN 3.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa. 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, 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 ce résolveur 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.
Exemple de fichier de configuration /etc/resolv.conf d’un serveur de noms
domain tpt.example.com nameserver ::1 nameserver 2001:db8:330f:a0d1::53 nameserver 2001:db8:330f:a0d1::217 search tpt.example.com
Exemple de fichier de configuration /etc/resolv.conf d’une machine
domain tpt.example.com nameserver 2001:db8:330f:a0d1::197 nameserver nameserver 2001:db8:330f:a0d1::53 nameserver 2001:db8:330f:a0d1::217 search tpt.example.com
Outils de vérification de la configurations 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. Par exemple, les outils dig, host 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.
Exemples d'interrogation d’un serveur DNS avec dig : résolution directe
root@s-13-v6:/etc/bind# dig @2001:db8:330f:a0d1::53 s-13-v6.tpt.example.com -t aaaa ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @2001:db8:330f:a0d1::53 s-13-v6.tpt.example.com -t aaaa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10043 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;s-13-v6.tpt.example.com. IN AAAA ;; ANSWER SECTION: s-13-v6.tpt.example.com. 10800 IN AAAA 2001:db8:330f:a0d1::53 s-13-v6.tpt.example.com. 10800 IN AAAA 2001:db8:330f:a0d1::217 s-13-v6.tpt.example.com. 10800 IN AAAA 2001:db8:330f:a0d2::217 s-13-v6.tpt.example.com. 10800 IN AAAA 2001:db8:330f:a0d3::217 s-13-v6.tpt.example.com. 10800 IN AAAA 2001:db8:330f:a0d4::217 ;; AUTHORITY SECTION: tpt.example.com. 10800 IN NS r-13-v6.tpt.example.com. tpt.example.com. 10800 IN NS s-13-v6.tpt.example.com. ;; ADDITIONAL SECTION: r-13-v6.tpt.example.com. 10800 IN AAAA 2001:db8:330f:a0d2::197 r-13-v6.tpt.example.com. 10800 IN AAAA 2001:db8:330f:a0d1::197 ;; Query time: 0 msec ;; SERVER: 2001:db8:330f:a0d1::53#53(2001:db8:330f:a0d1::53) ;; WHEN: Wed Feb 25 00:55:58 2015 ;; MSG SIZE rcvd: 270
Exemple d’interrogation d’un serveur DNS avec la commande host : résolution directe
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
root@s-13-v6:/etc/bind# dig @::1 -x 2001:db8:330f:a0d1::217 ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @::1 -x 2001:db8:330f:a0d1::217 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65205 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 7 ;; QUESTION SECTION: ;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 ;; ANSWER SECTION: 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. ;; AUTHORITY SECTION: 1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa. 10800 IN NS r-13-v6.tp13.tptfctp. 1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa. 10800 IN NS s-13-v6.tp13.tptfctp. ;; ADDITIONAL SECTION: r-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d2::197 r-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d1::197 s-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d2::217 s-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d3::217 s-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d4::217 s-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d1::53 s-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d1::217 ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Mar 17 11:31:56 2015 ;; MSG SIZE rcvd: 356
Exemple d’interrogation d’un serveur DNS avec la commande host : résolution inverse
root@r-13-v6:/var/bind# host -t aaaa s-13-v6 s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d1::53 s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d1::217 s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d2::217 s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d3::217 s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d4::217 root@r-13-v6:/var/bind# host -t aaaa 2001:660:330f:a0d1::53 3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.d.0.a.f.0.3.3.0.6.6.0.1.0.0.2.ip6.arpa domain name pointer s-13-v6.tp13.tptfctp. root@r-13-v6:/var/bind# host -t aaaa 2001:660:330f:a0d1::197 7.9.1.0.0.0.0.0.0.0.0.0.0.0.0.0.1.d.0.a.f.0.3.3.0.6.6.0.1.0.0.2.ip6.arpa domain name pointer r-13-v6.tp13.tptfctp. root@r-13-v6:/var/bind# host -t aaaa 2001:660:330f:a0d2::197 7.9.1.0.0.0.0.0.0.0.0.0.0.0.0.0.2.d.0.a.f.0.3.3.0.6.6.0.1.0.0.2.ip6.arpa domain name pointer r-13-v6.tp13.tptfctp. root@r-13-v6:/var/bind# host -t aaaa 2001:660:330f:a0d3::217 7.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.3.d.0.a.f.0.3.3.0.6.6.0.1.0.0.2.ip6.arpa domain name pointer s-13-v6.tp13.tptfctp.
L'AFNIC utilise la deuxième version de l’outil ZoneCheck pour vérifier et valider la configuration de 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.
Recommandations opérationnelles pour l'intégration d'IPv6
Le DNS, comme cela a été décrit dans l'introduction de ce chapitre, est à la fois une application TCP/IP et une infrastructure critique.
Le DNS est une application critique parce qu’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. 2.4.1. Deux aspects du DNS Le DNS supporte les enregistrements A et AAAA, et ce, indépendamment de la version d'IP 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 sur IPv4 ou IPv6 ou sur les deux à la fois (machine doble pile). Dans tous les cas, le serveur DNS doit satisfaire une requête donnée en renvoyant les informations qu'il a dans sa base de données, indépendamment de la version d'IP qui lui a acheminé 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 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 forwarder) n'utilisent pas nécessairement la même version d'IP que leurs clients.
Notez en outre, qu’en supposant que le serveur DNS puisse connaître la version d'IP utilisée par le client qui a initié la requête, il n'a pas à faire d'hypothèse sur l'usage de la réponse DNS renvoyée par le client.
Impossibilités d’accéder 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 ces situations.
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é. Dans ce cas, 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.
Recommandation. 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.
Recommandation. 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> ;} dans le fichier named.conf.options.
Taille limitée des messages DNS en UDP, extension EDNS.0
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 induisent un acheminement 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) vaut 1. Ceci signifie implicitement que le client est invité à réinterroger le serveur en utilisant TCP.
Notez que ce scénario justifie le fait que le port 53 en TCP ne doit pas être ouvert exclusivement pour des transferts de zones. Par ailleurs, 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’accroître le nombre de recours à TCP pour satisfaire les requêtes/réponses DNS.
Aujourd'hui, ces dépassements 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', est fortement recommandé.
Notez également que le support d'EDNS.0 est 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 (db.cache) 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.
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). Ces serveurs gèrent les domaines racines (TLD).
Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement 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 ont 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 se convaincre que la publication des adresses IPv6 des serveurs DNS racines supportant IPv6 pouvait 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.
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 qu’il supporte le 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 cependant ne pas supporter IPv6.
La situation suivante risque donc de se produire. L'équipement foo.tpt.example.com héberge plusieurs services : web, ftp, mail, DNS. Les serveurs Web et DNS s'exécutant sur foo.tpt.example.com. Ces services supportent IPv6, mais pas les serveurs FTP et mail. Une adresse IPv6 est publiée dans le DNS pour foo.tpt.example.com.
Un client FTP supportant IPv6 tente d’accéder au serveur de notre équipement : foo.tpt.example.com. Le client choisit l'adresse IPv6 de foo.tpt.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 et finissent ou non par tenter d’y accéder, en dernier recours, en IPv4.
Notez que, 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.tpt.example.com et ns.tpt.example.com associés à des adresses IPv6, et éventuellement, des adresses IPv4, et d'autre part, les noms ftp.tpt.example.com et mail.tpt.example.com associés uniquement à des adresses IPv4.
L'enregistrement AAAA pour foo.tpt.example.com ne serait alors publié que lorsque l'on aurait 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 accessibles depuis l'extérieur, soit à cause d'une portée trop faible 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. Les vues permettent d’exécuter plusieurs serveurs virtuels sur une même machine. Elles permettent que la réponse à une requête DNS dépende de la localisation du client. Par exemple, un client du réseau interne voit les adresses privées des équipements alors que les clients externes ne voient eux que les adresses globales et accessibles depuis l'extérieur.
Pour aller plus loin : mises à jour dynamiques du DNS
Le système de noms de domaine a été initialement conçu pour interroger une base de données statique. Les données pouvaient changer, mais leur fréquence de modification devait rester faible. Toutes les mises à jour se faisaient en éditant les fichiers de zone maîtres.
L’opération de mise à jour, UPDATE, permet l’ajout ou la suppression de RR ou d’ensembles de RR dans une zone spécifiée, lorsque certains prérequis sont satisfaits. Cette mise à jour est possible depuis un serveur DHCPv6, par exemple, ou depuis une machine IPv6 (autoconfiguration sans état). La mise à jour est atomique : tous les prérequis doivent être satisfaits pour que la mise à jour ait lieu. Aucune condition d’erreur relative aux données ne peut être définie après que les prérequis soient satisfaits.
Les prérequis concernent un ensemble de RR ou un seul RR. Ceux-ci peuvent ou non exister. Ils sont spécifiés séparément des opérations de mise à jour. La mise à jour s’effectue sur le serveur primaire de la zone concernée. Si un client s’adresse à un serveur secondaire, ce dernier relaie la demande de mise à jour vers le serveur (update forwarding).
Le serveur primaire incrémente le numéro de version de l’enregistrement SOA de la zone concernée, soit après un certain nombre de mises à jour, par exemple 100, soit à l’expiration d’un certain délai, par exemple 5 minutes en fonction de celle des deux conditions remplie la première.
Les serveurs secondaires obtiennent une copie des fichiers de zone modifiés par le serveur primaire par transfert de zone. Ceci leur permet de prendre en compte les modifications dynamiques effectuées au niveau du serveur.
Des serveurs tels que DHCP utilisent la mise à jour dynamique pour déclarer les correspondances nom – adresse et adresse – nom allouées automatiquement aux machines.
La structure des messages DNS est modifiée pour les messages de mise à jour du DNS. Certains champs sont ajoutés, d’autres sont surchargés. Ils utilisent alors la procédure ns_update du résolveur.
La commande nsupdate permet, sur un système linux, par exemple, les mises à jour dynamiques du DNS en ligne de commande.
Pour en savoir plus
Le [RFC 2136] spécifie les mises à jour dynamiques du DNS. Le [RFC 3007] spécifie la mise à jour sécurisée du DNS. Il met à jour le [RFC 2136]. Les [RFC 4033], [RFC 4034], [RFC 4035] spécifient respectivement l’introduction à la sécurité du DNS et les besoins de sécurité, les enregistrements de ressource pour les extensions de sécurité du DNS, et enfin, les modifications du protocole pour les extensions de sécurité du DNS.
Conclusion
Le système de noms de domaine est une application client-serveur distribuée qui fonctionne à la plus grande échelle qui soit. C’est un système de base de données hiérarchique. Il a été initialement conçu pour stocker des correspondances nom – adresse et des correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert de courrier ou les serveurs de noms. Ce système privilégie la récupération d’information sur la fraîcheur de l’information remise. Un serveur de noms fournit une réponse, en fonction des données dont il dispose, sans attendre la fin d’un transfert éventuel de zone. Pour pallier au délai de mise à jour des données de zone du serveur secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur primaire de la zone. Ce serveur est forcément à jour. Un nom absolu correspond au chemin qui, dans l’arbre de nommage relie une feuille à la racine de l’arbre de nommage.
Le client du système de nommage est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Ce client peut s’initialiser à partir d’un fichier de configuration ou d’informations fournies par un serveur DHCP ou encore d’options spécifiques des annonces de routeur. Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.
L’utilisateur de la machine fournit généralement le nom de la machine cible. Les applications TCP/IP utilisent ces procédures pour obtenir l’adresse IP associée à ce nom. Une fois l’adresse obtenue, elles peuvent établir une session en mode avec ou sans connexion avec un site distant.
Le système de nommage associe une hiérarchie de serveurs de noms à l’arbre de nommage. A chaque nœud de l’arbre correspond un serveur de noms. Chaque serveur dispose d’un pointeur vers chacun de ses fils et un pointeur vers son père. Chaque père connaît chacun de ses fils. Pour équilibrer la charge, le serveur racine est répliqué.
Les enregistrements de ressource de type A, pour IPv4 et AAAA, pour IPv6 gèrent respectivement les correspondances nom – adresse respectivement pour IPv4 et pour IPv6. Ils permettent que les utilisateurs manipulent les noms des machines et non leurs adresses. Dans le cas d’IPv6, cela évite que les utilisateurs aient à retenir des adresses IPv6 représentées en notation hexadécimale pointée. La configuration d’un service de nommage en IPv6 suppose la configuration d’un serveur primaire et d’au moins un serveur secondaire. Ces deux serveurs sont des serveurs officiels pour la zone concernée. Le serveur primaire utilise des fichiers maîtres contenant les informations de nommage direct (un seul fichier) et indirect (un fichier par lien ou sous-réseau). Les serveurs secondaires peuvent gérer une copie des fichiers maîtres, et c’est fortement recommandé par l’IETF, sur une mémoire non volatile. Ceci accélère le démarrage des serveurs secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur primaire.
Les outils de vérification de configuration named-checkconf et named-checkzone vérifient respectivement l’absence d’erreur dans le fichier de configuration de BIND9 et dans les fichiers de zone.
L’analyse des fichiers journaux permet de vérifier l’absence d’erreur à l’exécution du service. Le fichier journal est généralement /var/log/syslog par défaut sur un système Linux.
Les outils dig et host permettent de vérifier le bon fonctionnement de la résolution des noms et de la résolution inverse.
Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer des serveurs duaux ou des relais DNS duaux.
Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances nom – adresse et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Les mises à jour atomiques ne sont effectuées que lorsque tous les prérequis d’une mise à jour sont satisfaits. Sinon, elles ne le sont pas.
