Livre IPv6 - User contributions [en]

MOOC:Manuel Apprenant

2015-10-31T12:48:27Z

Bstevant2: /* Console / Ligne de commande */

= Introduction =
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il aborde :
* L'installation de la plateforme
* L'outil GNS3
* Le déroulement d'une activité pratique
* L'utilisation des outils liées aux activités
* Les commandes utilisées pour les activités

= Installation de la plateforme =

= Utilisation de GNS3 =

= Déroulement d'une activité =

== Démarrage d'une activité ==

== Pause / Sauvegarde / Reprise ==

== Retour arrière ==

= Outils fournis par la plateforme =

== Console / Ligne de commande ==

L'interaction avec les machines de la plateforme se fait au travers de fenêtres présentant la console de ces machines. La console permet de s'authentifier auprès du système des machines avant d'interagir avec lui grâce à la ligne de commande.

L'affichage des consoles des machines se fait dans l'interface GNS3 en cliquant sur l'icône juste à gauche du triangle vert ("Console connect to all devices"). Le titre de la fenêtre vous précise à quelle machine cette console appartient. Vous pouvez n'afficher qu'une console particulière en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie.

Il est conseillé de garder les consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer la plateforme.

Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support préfixe chaque commande avec l'invite du système, afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple
apprenant@MOOCIPv6:~$ '''ifconfig'''
est une commande à saisir sur une des machines Linux. Les caractères à saisir sont <tt>ifconfig</tt> suivis d'un retour chariot pour exécuter la commande.

Le copier-coller est possible entre les différentes consoles, afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont
* Copier : '''Ctrl-Inser''' ou sélection à la souris
* Coller : '''Shift-Inser''' ou bouton milieu de la souris

== Capture réseau ==

= Synthèse des commandes des systèmes =

== A propos des modes VyOS ==

VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le systèmes VyOS précisent donc le mode dans lequel elles sont valides.

'''Mode utilisateur''' : Ce mode est obtenu après connexion au système avec les identifiants :
login: '''vyos'''
password: '''vyos'''

L'invite de commande dans ce mode est
vyos@vyos:~$

Ce mode permet d'observer la configuration du système et de passer au '''Mode Quagga''' ou au '''Mode Administrateur'''

'''Mode Quagga''' : Ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande :
vyos@vyos:~$ '''vtysh'''

L'invite de commande dans ce mode est
vyos#

Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage.

'''Mode Administrateur''' : Ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande :
vyos@vyos:~$ '''configure'''

L'invite de commande dans ce mode est
vyos@vyos#

Ce mode permet de configurer les services et autres fonctionnalités de VyOS.

== Commandes pour les paramètres des interfaces réseau ==

=== Visualiser la configuration IPv6 des interfaces réseau ===

Linux :
apprenant@MOOCIPv6:~$ '''ifconfig'''
apprenant@MOOCIPv6:~$ '''ifconfig -a''' (pour voir toutes les interfaces, même inactives)
apprenant@MOOCIPv6:~$ '''ip -6'''

VyOS (Mode Utilisateur)
vyos@vyos:~$ '''show interfaces detail'''

=== Activer une interface réseau ===

Linux :
apprenant@MOOCIPv6:~$ '''ifconfig <interface> up'''

VyOS (Mode Quagga)
vyos# '''configure terminal'''
vyos(config)# '''interface <interface>'''
vyos(config-if)# '''no shutdown'''
vyos(config-if)# '''exit'''

=== Ajouter une adresse IPv6 à une interface réseau ===

Linux :
apprenant@MOOCIPv6:~$ '''sudo ifconfig <interface> <adresse IPv6>/<lg. prefixe>'''
apprenant@MOOCIPv6:~$ '''sudo ip -6 addr add <adresse IPv6> dev <interface>'''

VyOS (Mode Quagga)
vyos# '''configure terminal'''
vyos(config)# '''interface <interface>'''
vyos(config-if)# '''ipv6 address <adresse IPv6>/<lg. prefixe>'''
vyos(config-if)# '''exit'''

=== Enlever une adresse IPv6 à une interface réseau ===

Linux :
apprenant@MOOCIPv6:~$ '''sudo ip -6 addr del <adresse IPv6>/<lg. prefixe> dev <interface>'''

VyOS (Mode Quagga)
vyos# '''configure terminal'''
vyos(config)# '''interface <interface>'''
vyos(config-if)# '''no ipv6 address <adresse IPv6>/<lg. prefixe>'''
vyos(config-if)# '''exit'''

== Commandes propres à la table de routage ==

== Autres commandes utiles pour IPv6 ==

MOOC:Manuel Apprenant

2015-10-30T16:33:22Z

Bstevant2: /* Activer une interface réseau */

MOOC:Manuel Apprenant

2015-10-30T16:32:17Z

Bstevant2: /* = Activer une interface réseau */

MOOC:Manuel Apprenant

2015-10-30T16:31:57Z

Bstevant2: /* Commandes propres aux interfaces réseau */

MOOC:Manuel Apprenant

2015-10-30T15:46:27Z

Bstevant2: /* Synthèse des commandes */

MOOC:Manuel Apprenant

2015-10-30T14:20:32Z

Bstevant2: Created page with "= Introduction = Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il aborde : * L'i..."

MOOC:Gestion de projet

2015-10-30T14:07:11Z

Bstevant2:

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|Gestion de projet]]
----
= Documents de travail =
* [[MOOC:Formalisation de la structure]]
* [[MOOC:Matrice des séquences]]
* [[MOOC:Matrice des auteurs]]
* [[MOOC:Suivi Relecture Compagnon]]
* [[MOOC:Guide de rédaction]]
* [[MOOC:Faire des quizz]]
* [[MOOC:Figures]]
* [[MOOC:Corrections des videos]]
* [[MOOC:Manuel Apprenant]]

= Réunions =
* [[MOOC:Réunion 20151006|20151006 Réunion finalisation]]
* [[MOOC:Réunion 20150904|20150904 Réunion d'avancement]]
* [[MOOC:Réunion 20150311|20150311 Réunion de synchronisation]]
* [[MOOC:Réunion 20150306|20150306 Réunion d'avancement]]
* [[MOOC:Réunion 20150216|20150216 Réunion d'avancement]]
* [[MOOC:Réunion 20150203|20150203 Réunion d'avancement]]
* [[MOOC:Réunion 20150115|20150115 Réunion d'avancement]]
* [[MOOC:Réunion 20141211|20141211 Rencontre MOOC Paris]]
* [[MOOC:Réunion 20141201|20141201 Réunion d'avancement]]
* [[MOOC:Réunion 20141124|20141124 Réunion Articulation PRD/IPv6]]
* [[MOOC:Réunion 20141031|20141031 Réunion de démarrage]]

= Outils =
* [http://wiki.g6.asso.fr/index.php?title=Annuaire_Intervenants_MOOC Annuaire Intervenants MOOC]
* Liste de diffusion [mailto:moocipv6@mlistes.telecom-bretagne.eu mooc ipv6]
* [[MOOC:Lille| Séjour à IMT Lille]]

=Communication=
* Page d'annonce du MOOC IPv6 sur FUN : [https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about Objectif IPv6 : vers l'internet nouvelle génération]
* Annonces faites par l'Université de la Réunion:
** [[MOOC:comUR | Message du 15 juillet]]
** Sur le site institutionnel : [http://www.univ-reunion.fr/actualites/ipv6-le-premier-mooc-de-luniversite-de-la-reunion/ Actualités]

* Presentation du plan: https://prezi.com/jjmq_45fjhfr/mooc-objectif-ipv6-plan-du-cours/

File:MOOC Act34 figBJ-17.png

2015-10-27T15:14:46Z

Bstevant2:

File:MOOC Act34 figBJ-11.png

2015-10-27T15:14:30Z

Bstevant2:

File:MOOC Act34 figBJ-10.png

2015-10-27T15:14:15Z

Bstevant2:

File:MOOC Act34 figBJ-9.png

2015-10-27T15:13:52Z

Bstevant2:

File:MOOC Act34 figBJ-8.png

2015-10-27T15:13:34Z

Bstevant2:

File:MOOC Act34 figBJ-7.png

2015-10-27T15:13:22Z

Bstevant2:

File:MOOC Act34 figBJ-6.png

2015-10-27T15:13:09Z

Bstevant2:

File:MOOC Act34 figBJ-5.png

2015-10-27T15:12:54Z

Bstevant2:

File:MOOC Act34 figBJ-4.png

2015-10-27T15:12:42Z

Bstevant2:

File:MOOC Act34 figBJ-2.png

2015-10-27T15:12:27Z

Bstevant2:

File:MOOC Act34 figBJ-1.png

2015-10-27T15:12:12Z

Bstevant2:

MOOC:Compagnon Act34-s6

2015-10-27T15:11:52Z

Bstevant2: /* Réseau virtualisé utilisé pour générer ces exemples */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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

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.
* 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 de nommage, 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.

[[Image:MOOC_Act34_figBJ-2.png|666px|thumb|center|Extension 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. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage.
Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.

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

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

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

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

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

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

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

[[Image:MOOC_Act34_figBJ-9.png|666px|thumb|center|Notification d'un changement de version de base de nommage par le serveur DNS primaire]]

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

[[Image:MOOC_Act34_figBJ-10.png|666px|thumb|center|Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire]]

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

[[Image:MOOC_Act34_figBJ-6.png|666px|thumb|center|Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire et les serveurs secondaires déjà synchronisés]]

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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).

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

La figure montre qu’une liste de serveurs DNS est associée à chaque nœud présent dans le sous-arbre de nommage DNS inverse.

Cette liste inclut généralement un serveur DNS primaire et un ou plusieurs serveurs DNS secondaires, tous considérés des serveurs DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3.png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

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

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T15:10:18Z

Bstevant2: /* Nommage inverse : enregistrement PTR */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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

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.
* 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 de nommage, 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.

[[Image:MOOC_Act34_figBJ-2.png|666px|thumb|center|Extension 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. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage.
Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.

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

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

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

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

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

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

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

[[Image:MOOC_Act34_figBJ-9.png|666px|thumb|center|Notification d'un changement de version de base de nommage par le serveur DNS primaire]]

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

[[Image:MOOC_Act34_figBJ-10.png|666px|thumb|center|Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire]]

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

[[Image:MOOC_Act34_figBJ-6.png|666px|thumb|center|Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire et les serveurs secondaires déjà synchronisés]]

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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).

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

La figure montre qu’une liste de serveurs DNS est associée à chaque nœud présent dans le sous-arbre de nommage DNS inverse.

Cette liste inclut généralement un serveur DNS primaire et un ou plusieurs serveurs DNS secondaires, tous considérés des serveurs DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3.png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T15:08:18Z

Bstevant2: /* Serveurs de noms primaires et secondaires */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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

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.
* 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 de nommage, 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.

[[Image:MOOC_Act34_figBJ-2.png|666px|thumb|center|Extension 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. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage.
Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.

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

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

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

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

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

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

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

[[Image:MOOC_Act34_figBJ-9.png|666px|thumb|center|Notification d'un changement de version de base de nommage par le serveur DNS primaire]]

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

[[Image:MOOC_Act34_figBJ-10.png|666px|thumb|center|Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire]]

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

[[Image:MOOC_Act34_figBJ-6.png|666px|thumb|center|Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire et les serveurs secondaires déjà synchronisés]]

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3.png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T15:05:28Z

Bstevant2: /* Principe de fonctionnement du service DNS */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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

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.
* 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 de nommage, 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.

[[Image:MOOC_Act34_figBJ-2.png|666px|thumb|center|Extension 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. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage.
Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.

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

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

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

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

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3.png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T15:01:44Z

Bstevant2: /* Caractéristiques du système de noms de domaine */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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

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.
* 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 de nommage, 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.

[[Image:MOOC_Act34_figBJ-2.png|666px|thumb|center|Extension 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. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage.
Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.

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

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

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

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3.png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T15:01:14Z

Bstevant2: /* Caractéristiques du système de noms de domaine */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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

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.
* 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 de nommage, 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.

[[Image:MOOC_Act34_figBJ-2.png|666px|thumb|center|Extension 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. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage.
Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.

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

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

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

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3.png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T09:21:09Z

Bstevant2: /* Introduction */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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.
* 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 de nommage, 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.

TO DO ajouter la figure extension de l'arbre de nommage, ajout de la société1.

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

TO DO insérer la figure réduction de la profondeur de l'arbre de serveurs associée à l'arbre de nommage.

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.

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3.png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T09:11:31Z

Bstevant2: /* Caractéristiques du système de noms de domaine */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenu pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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.
* 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 de nommage, 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.

TO DO ajouter la figure extension de l'arbre de nommage, ajout de la société1.

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

TO DO insérer la figure réduction de la profondeur de l'arbre de serveurs associée à l'arbre de nommage.

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.

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3.png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T08:23:51Z

Bstevant2: /* Option serveur de nom récursif de DHCPv6 */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenu pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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.
* 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 de nommage, 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.

TO DO ajouter la figure extension de l'arbre de nommage, ajout de la société1.

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.

TODO insérer la figure arbre de serveurs associée à l'arbre de nommage.

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

TO DO insérer la figure réduction de la profondeur de l'arbre de serveurs associée à l'arbre de nommage.

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.

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3.png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

File:MOOC Act34 Fig3-1.png

2015-10-27T08:23:33Z

Bstevant2:

File:MOOC Act34 Fig4.png

2015-10-27T08:21:22Z

Bstevant2:

File:MOOC Act34 Fig3.png

2015-10-27T08:21:02Z

Bstevant2:

File:MOOC Act34 Fig2.png

2015-10-27T08:20:41Z

Bstevant2:

File:MOOC Act34 Fig1.png

2015-10-27T08:20:18Z

Bstevant2:

MOOC:Compagnon Act34-s6

2015-10-27T08:19:45Z

Bstevant2: /* Option serveur de nom récursif de DHCPv6 */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenu pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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.
* 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 de nommage, 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.

TO DO ajouter la figure extension de l'arbre de nommage, ajout de la société1.

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.

TODO insérer la figure arbre de serveurs associée à l'arbre de nommage.

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

TO DO insérer la figure réduction de la profondeur de l'arbre de serveurs associée à l'arbre de nommage.

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.

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T08:19:33Z

Bstevant2: /* Option de liste de domaine recherchés (DNSSL) */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenu pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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.
* 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 de nommage, 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.

TO DO ajouter la figure extension de l'arbre de nommage, ajout de la société1.

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.

TODO insérer la figure arbre de serveurs associée à l'arbre de nommage.

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

TO DO insérer la figure réduction de la profondeur de l'arbre de serveurs associée à l'arbre de nommage.

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.

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T08:19:16Z

Bstevant2: /* Extension de la configuration à états, DHCPv6 */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenu pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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.
* 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 de nommage, 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.

TO DO ajouter la figure extension de l'arbre de nommage, ajout de la société1.

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.

TODO insérer la figure arbre de serveurs associée à l'arbre de nommage.

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

TO DO insérer la figure réduction de la profondeur de l'arbre de serveurs associée à l'arbre de nommage.

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.

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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.

[[File:MOOC_Act34_Fig3png|666px]]

<tt>OPTION_DNS_SERVERS</tt> Le code option vaut 23.

<tt>Longueur</tt> 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.

<tt>DNS-recursive-name-server</tt>. 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====

[[File:MOOC_Act34_Fig4.png|666px]]

<tt>OPTION_DOMAIN_LIST</tt> Le code de cette option vaut 24.

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

<tt>Searchlist</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T08:17:04Z

Bstevant2: /* Option de liste de domaine recherchés (DNSSL) */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenu pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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.
* 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 de nommage, 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.

TO DO ajouter la figure extension de l'arbre de nommage, ajout de la société1.

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.

TODO insérer la figure arbre de serveurs associée à l'arbre de nommage.

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

TO DO insérer la figure réduction de la profondeur de l'arbre de serveurs associée à l'arbre de nommage.

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.

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.

[[File:MOOC_Act34_Fig2.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 31.

<tt>Length</tt> 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.

<tt>Lifetime</tt> 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.

<tt>Noms de domaines</tt> 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-27T08:15:47Z

Bstevant2: /* Option de liste de serveurs DNS récursifs (RDNSS) */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenu pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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.
* 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 de nommage, 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.

TO DO ajouter la figure extension de l'arbre de nommage, ajout de la société1.

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.

TODO insérer la figure arbre de serveurs associée à l'arbre de nommage.

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

TO DO insérer la figure réduction de la profondeur de l'arbre de serveurs associée à l'arbre de nommage.

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.

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

[[File:MOOC_Act34_Fig1.png|666px]]

<tt>Type</tt> Le champ type a pour valeur 25.

<tt>Longueur</tt> 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.

<tt>Durée de vie</tt>. 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.

<tt>Addresses</tt> 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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Activité 46

2015-10-27T07:12:40Z

Bstevant2: /* Description */

> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Ateliers|Ateliers]]>[[MOOC:Activité 46 |Activité 46]] 
> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_4|Séquence 4]]>[[MOOC:Activité 46 |Activité 46]]

----

= Activité 46: Faites interopérer des applications IPv6 et IPv4 =

== Objectifs pédagogiques ==

* Définir un plan d'adressage pour la traduction en IPv4 et en IPv6
* Définir les adresses IPv6 embarquant une adresse IPv4
* installation d'une machine en double pile
* Installation d'un DNS64
* Résoudre un nom d'une machine ayant une adresse IPv4 uniquement pour un noeud IPv6
* Mettre en oeuvre NAT64 sans état
* Installer le routage du trafic pour la traduction NAT64
* Capturer et analyser le trafic echangé passant par un NAT64
* Capturer et analyser le trafic echangé passant par un DNS64

== Description ==

L'objectif de cette activité pratique est de pouvoir faire interopérer un client web IPv6-seul avec un service web IPv4-seul. Les différentes étapes de cette activité vont montrer la mise en oeuvre de différents mécanismes de transition pour réaliser cette interopérabilité :
* Tout d'abord, le client seul atteindra le service au travers d'un dispositif NAT64.
* Ensuite un tunnel IPv6 au dessus d'IPv4 permettra d'amener la connectivité proche du service.
* Enfin une passerelle applicative permettra l'interopérabilité côté serveur.

Même si la plateforme est de taille trop modeste pour montrer les mécanismes déployer à échelle réelle, vous allez pouvoir quand même observer leur fonctionnement de manière réaliste.

Le support de cette activité pratique est disponible en suivant ce lien (http://mooc.ipv6.rennes.telecom-bretagne.eu/Support_Act46.pdf)

Le support vous donne l'ensemble des opérations à réaliser pour aller jusqu'au bout de l'activité. Vous trouverez un résumé de ces commandes dans le Manuel Apprenant disponible en suivant ce lien (http://mooc.ipv6.rennes.telecom-bretagne.eu/Manuel_Apprenant.pdf)

== Scénario du TP ==

=== Idée PA ===
Topologie
PC1 ---- R1---R2---- PC2

Configuration initiale:
* PC1 est le client IPv6
* PC2 est le serveur IPv4 et le DNS
* R1 est le DNS64 double pile
* R2 est le NAT64 double pile

* Réseau PC1-R1 : IPv6 uniquement
* Réseau R1-R2 en double pile, il comporte IPv6/IPv4
* Réseau R2-PC2 : IPv4 uniquement

-> Comment PC1 peut accéder au service sur PC2

Etape 0:
* Découverte du réseau et vérification de la configuration
* Le réseau IPv4 est opérationnel et configuré
* le réseau IPv6 est opérationnel et configuré
* le DNS fonctionne pour obtenir des adresses IPv4. Les adresses IPv6 sont dans le DNS
* le serveur web fonctionnel

Etape 1:
* Définir les adresses de translations
* Déployer le serveur de nom pour IPv6 et DNS64
* Configurer PC1 pour avoir DNS64 comme name server (accessoirement R1 et R2)

Etape 2:
* Deployer le NAT64

Etape 3:
* Test de joignabilité + Analyse des échanges

Bonus:
* le serveur devient accessible à IPv6 par un reverse proxy
* Mise à jour du DNS
* Installation du reverse proxy

=== Idée BS ===

Topologie
PC1 ---- R1 ---- R2 ---- PC2

Configuration initiale:
* Réseau PC1-R1 : IPv6 déployé
* Réseau R1-R2, R2-PC2 : IPv4
* PC2 : Serveur (Web ?) + Serveur DNS
=> Comment PC1 peut accéder au service sur PC2

Etape 1 : NAT64
* R1: NAT64+DN64 déployé, mais à configurer (conf minimum à saisir)
* Test de joignabilité + Analyse des échanges

Etape 2 : Tunnel
* Faire un tunnel configuré 6in4 entre R1 et R2
* Analyse de l'encapsulation

Etape 3 : Reverse-Proxy
* Configurer un RProxy sur R2

Etape 4 (facultatcive) : IPv6 sur PC2
* Service en IPv6

== [[MOOC:Scenario_TP4 | Informations techniques TP 4]] ==

== [[MOOC:Support_Act46 |Commandes du TP]] ==

== Vidéo ==
1 vidéo introductive (3 min max.)

1 vidéo déroulant le TP avec commentaire voix off (10-15min ?)

MOOC:Activité 36

2015-10-27T07:12:10Z

Bstevant2: /* Description */

> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Ateliers|Ateliers]]>[[MOOC:Activité 35 |Activité 35]] 
> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_3|Séquence 3]]>[[MOOC:Activité 35 |Activité 45]]
----
= Mise en oeuvre =

== Objectifs pédagogiques ==

Mettre en oeuvre
* Mise en oeuvre d'un réseau avec autoconf
* L'auto-configuration des paramètres
* La configuration via DHCPv6
* Le DNS

== Description ==

Dans cette activité pratique, vous allez mettre en oeuvre les mécanismes décrits dans cette troisième séquence.
* Tout d'abord vous allez mettre en oeuvre l'auto-configuration sans état et observer les échanges entre la station et le routeur.
* Puis vous allez configurer l'auto-configuration avec état sur un second réseau
* Enfin l'ensemble des adresses seront enregistrées dans un DNS local.

Dans cette activité, les captures des échanges seront primordiales pour vous permettre de comprendre les mécanismes de configuration. Prenez donc le temps d'étudier les messages et leur contenu.

Le support de cette activité pratique est disponible en suivant ce lien (http://mooc.ipv6.rennes.telecom-bretagne.eu/Support_Act35.pdf)

Le support vous donne l'ensemble des opérations à réaliser pour aller jusqu'au bout de l'activité. Vous trouverez un résumé de ces commandes dans le Manuel Apprenant disponible en suivant ce lien (http://mooc.ipv6.rennes.telecom-bretagne.eu/Manuel_Apprenant.pdf)

== Scénario TP ==

Topologie
PC1 ------ R1 ------ R2 ------ PC2

Situation initiale
* Lien R1 et R2 configuré
* Routage activé pour les préfixes de chaque sous-réseau
* PC1 et PC2 : interfaces réseau desactivées

Etape 1
* Activation des annonces de routeurs sur R1
* Lancer la capture réseau
* Activation de l'interface réseau de PC1
* Analyser la capture des échanges d'auto-configuration
* Tester la connectivité PC1/R1/R2

Etape 2
* Configuration du serveur DHCPv6 sur R2 pour fournir des adresses sur le réseau de PC2
* Activation des annonces de routeurs sur R2 avec managed-config-flag
* Lancer la capture réseau
* Activation de l'interface réseau de PC2
* Analyser la capture des échanges d'auto-configuration
* Configuration du client DHCPv6 sur PC2 pour demander une adresse
* Test pour Valider de la configuration
* Capture des échanges DHCPv6
* Tester la connectivité PC2/R2/R1/PC1

Etape 3
* Configuration du serveur DNS sur PC2
* Validation de la configuration en local

Etape 4
* Configuration de R2 pour fournir l'adresse du serveur DNS
* Configuration du client DHCPv6 sur PC1 pour demander le serveur DNS
* Configuration de l'annonce de routeur sur R1 avec other-configs-flag
* Test de la configuration => ça ne marche pas
* Configuration du relais DHCPv6 sur R1
* Test et Validation de la configuration
* Test DNS depuis PC1

== [[MOOC:Scenario_TP3 | Informations techniques TP 3]] ==

== [[MOOC:Support_Act35 | Texte du TP3]] ==

MOOC:Activité 46

2015-10-27T07:09:17Z

Bstevant2: /* Objectifs pédagogiques */

> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Ateliers|Ateliers]]>[[MOOC:Activité 46 |Activité 46]] 
> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_4|Séquence 4]]>[[MOOC:Activité 46 |Activité 46]]

----

= Activité 46: Faites interopérer des applications IPv6 et IPv4 =

== Objectifs pédagogiques ==

* Définir un plan d'adressage pour la traduction en IPv4 et en IPv6
* Définir les adresses IPv6 embarquant une adresse IPv4
* installation d'une machine en double pile
* Installation d'un DNS64
* Résoudre un nom d'une machine ayant une adresse IPv4 uniquement pour un noeud IPv6
* Mettre en oeuvre NAT64 sans état
* Installer le routage du trafic pour la traduction NAT64
* Capturer et analyser le trafic echangé passant par un NAT64
* Capturer et analyser le trafic echangé passant par un DNS64

== Description ==

L'objectif de cette activité pratique est de pouvoir faire interopérer un client web IPv6-seul avec un service web IPv4-seul. Les différentes étapes de cette activité vont montrer la mise en oeuvre de différents mécanismes de transition pour réaliser cette interopérabilité :
* Tout d'abord, le client seul atteindra le service au travers d'un dispositif NAT64.
* Ensuite un tunnel IPv6 au dessus d'IPv4 permettra d'amener la connectivité proche du service.
* Enfin une passerelle applicative permettra l'interopérabilité côté serveur.

Même si la plateforme est de taille trop modeste pour montrer les mécanismes déployer à échelle réelle, vous allez pouvoir quand même observer leur fonctionnement de manière réaliste.

== Scénario du TP ==

=== Idée PA ===
Topologie
PC1 ---- R1---R2---- PC2

Configuration initiale:
* PC1 est le client IPv6
* PC2 est le serveur IPv4 et le DNS
* R1 est le DNS64 double pile
* R2 est le NAT64 double pile

* Réseau PC1-R1 : IPv6 uniquement
* Réseau R1-R2 en double pile, il comporte IPv6/IPv4
* Réseau R2-PC2 : IPv4 uniquement

-> Comment PC1 peut accéder au service sur PC2

Etape 0:
* Découverte du réseau et vérification de la configuration
* Le réseau IPv4 est opérationnel et configuré
* le réseau IPv6 est opérationnel et configuré
* le DNS fonctionne pour obtenir des adresses IPv4. Les adresses IPv6 sont dans le DNS
* le serveur web fonctionnel

Etape 1:
* Définir les adresses de translations
* Déployer le serveur de nom pour IPv6 et DNS64
* Configurer PC1 pour avoir DNS64 comme name server (accessoirement R1 et R2)

Etape 2:
* Deployer le NAT64

Etape 3:
* Test de joignabilité + Analyse des échanges

Bonus:
* le serveur devient accessible à IPv6 par un reverse proxy
* Mise à jour du DNS
* Installation du reverse proxy

=== Idée BS ===

Topologie
PC1 ---- R1 ---- R2 ---- PC2

Configuration initiale:
* Réseau PC1-R1 : IPv6 déployé
* Réseau R1-R2, R2-PC2 : IPv4
* PC2 : Serveur (Web ?) + Serveur DNS
=> Comment PC1 peut accéder au service sur PC2

Etape 1 : NAT64
* R1: NAT64+DN64 déployé, mais à configurer (conf minimum à saisir)
* Test de joignabilité + Analyse des échanges

Etape 2 : Tunnel
* Faire un tunnel configuré 6in4 entre R1 et R2
* Analyse de l'encapsulation

Etape 3 : Reverse-Proxy
* Configurer un RProxy sur R2

Etape 4 (facultatcive) : IPv6 sur PC2
* Service en IPv6

== [[MOOC:Scenario_TP4 | Informations techniques TP 4]] ==

== [[MOOC:Support_Act46 |Commandes du TP]] ==

== Vidéo ==
1 vidéo introductive (3 min max.)

1 vidéo déroulant le TP avec commentaire voix off (10-15min ?)

MOOC:Activité 36

2015-10-27T06:59:28Z

Bstevant2: /* Mise en oeuvre */

> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Ateliers|Ateliers]]>[[MOOC:Activité 35 |Activité 35]] 
> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_3|Séquence 3]]>[[MOOC:Activité 35 |Activité 45]]
----
= Mise en oeuvre =

== Objectifs pédagogiques ==

Mettre en oeuvre
* Mise en oeuvre d'un réseau avec autoconf
* L'auto-configuration des paramètres
* La configuration via DHCPv6
* Le DNS

== Description ==

Dans cette activité pratique, vous allez mettre en oeuvre les mécanismes décrits dans cette troisième séquence.
* Tout d'abord vous allez mettre en oeuvre l'auto-configuration sans état et observer les échanges entre la station et le routeur.
* Puis vous allez configurer l'auto-configuration avec état sur un second réseau
* Enfin l'ensemble des adresses seront enregistrées dans un DNS local.

Dans cette activité, les captures des échanges seront primordiales pour vous permettre de comprendre les mécanismes de configuration. Prenez donc le temps d'étudier les messages et leur contenu.

== Scénario TP ==

Topologie
PC1 ------ R1 ------ R2 ------ PC2

Situation initiale
* Lien R1 et R2 configuré
* Routage activé pour les préfixes de chaque sous-réseau
* PC1 et PC2 : interfaces réseau desactivées

Etape 1
* Activation des annonces de routeurs sur R1
* Lancer la capture réseau
* Activation de l'interface réseau de PC1
* Analyser la capture des échanges d'auto-configuration
* Tester la connectivité PC1/R1/R2

Etape 2
* Configuration du serveur DHCPv6 sur R2 pour fournir des adresses sur le réseau de PC2
* Activation des annonces de routeurs sur R2 avec managed-config-flag
* Lancer la capture réseau
* Activation de l'interface réseau de PC2
* Analyser la capture des échanges d'auto-configuration
* Configuration du client DHCPv6 sur PC2 pour demander une adresse
* Test pour Valider de la configuration
* Capture des échanges DHCPv6
* Tester la connectivité PC2/R2/R1/PC1

Etape 3
* Configuration du serveur DNS sur PC2
* Validation de la configuration en local

Etape 4
* Configuration de R2 pour fournir l'adresse du serveur DNS
* Configuration du client DHCPv6 sur PC1 pour demander le serveur DNS
* Configuration de l'annonce de routeur sur R1 avec other-configs-flag
* Test de la configuration => ça ne marche pas
* Configuration du relais DHCPv6 sur R1
* Test et Validation de la configuration
* Test DNS depuis PC1

== [[MOOC:Scenario_TP3 | Informations techniques TP 3]] ==

== [[MOOC:Support_Act35 | Texte du TP3]] ==

MOOC:Intro Séquence 3

2015-10-26T15:54:57Z

Bstevant2: Bstevant2 moved page MOOC:Intro Séquence 3 to MOOC:Intro Sequence 3

#REDIRECT [[MOOC:Intro Sequence 3]]

MOOC:Intro Sequence 3

2015-10-26T15:54:56Z

Bstevant2: Bstevant2 moved page MOOC:Intro Séquence 3 to MOOC:Intro Sequence 3

= Introduction =

La séquence précédente vous a montré qu'IPv6 constitue un retour aux fondamentaux du protocole IP : transporter des données d'un point à un autre du réseau, avec une intervention minimale des équipements intermédiaires, intervention réduite la plus part du temps à la fonction de routage.

Cette séquence va se concentrer sur les mécanismes qui ont été spécifiés autour du standard IPv6 pour assurer le bon fonctionnement d'un réseau IP. La première activité va vous présenter le protocole '''ICMPv6''' qui permet de faire, à l'échelle de l'internet, le contrôle du fonctionnement et l'envoi de rapport d'erreur si besoin. La seconde activité décrira les mécanismes définis pour assurer la '''configuration automatique''' des paramètres réseau au niveau du réseau local. La troisième activité abordera la '''configuration automatique avec état'''. Enfin pour la dernière activité, vous pourrez étudier le fonctionnement du '''système de nommage''', essentiel pour qu'utilisateur et administrateur puisse désigner machines et services par des noms plutôt que par des adresses IP.

MOOC:Activité 26

2015-10-26T15:20:54Z

Bstevant2: /* Description */

__NOTOC__
> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Ateliers|Ateliers]]>[[MOOC:Activité 26 |Activité 26]] 
> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_2|Séquence 2]]>[[MOOC:Activité 26 |Activité 26]]
----
= Configurez votre premier réseau en IPv6 =

== Objectifs pédagogiques ==

* Maitriser l'outil d'émulation de réseau GNS3
* Mettre en oeuvre un test d'accessibilité entre équipement
* Analyser le résultat d'un test d'accessibilité
* Mettre en oeuvre une capture réseau
* Analyser le résultat d'une capture réseau
* Identifier les entêtes et leurs champs dans un paquet désassemblé
* Comprendre la différence de portée entre une adresse lien local et une adresse globale
* Mettre en oeuvre la configuration d'une adresse IPv6 sur une interface
* Identifier les adresses IPv6 configurées sur une interface réseau
* Mettre en oeuvre la configuration d'une route dans la table de routage
* Identifier les routes disponibles dans une table de routage

Bonus :
* Comprendre le mécanisme de découverte et d'adaptation à la MTU minimale
* Comprendre le mécanisme de routage par la source

== Description ==
L'objectif de cette première activité pratique sera pour vous de configurer un réseau IPv6 et de faire communiquer les différentes machines de ce réseau entre elle. Vous allez ainsi vous familiariser :
* avec l'outil GNS3, le contrôle de l'émulation de réseau et la capture de traces
* avec les interfaces de configuration des différents systèmes utilisés pour les machines
* avec les commandes de configuration utilisées pour IPv6

Différentes étapes dans cette activité vont vous permettre d'observer les communications locales au lien, d'effectuer la mise en place du routage et ainsi d'établir des communications à travers plusieurs réseaux.

Le support de cette activité pratique est disponible en suivant ce lien (http://mooc.ipv6.rennes.telecom-bretagne.eu/Support_Act26.pdf)

Le support vous donne l'ensemble des opérations à réaliser pour aller jusqu'au bout de l'activité. Vous trouverez un résumé de ces commandes dans le Manuel Apprenant disponible en suivant ce lien
(http://mooc.ipv6.rennes.telecom-bretagne.eu/Manuel_Apprenant.pdf)

== Scénario TP ==

=== Topologie ===
[[image:2015_10_20_TP2_screenshot1.png|thumb|center|600px|TP2]]

Situation initiale
* Les interfaces des PCs et routeurs sont toutes désactivées
* Les liens entre les équipements ne sont pas définis

Etape 0
* L'apprenant crée les liens entre les équipements
* Il active les interfaces réseau des équipements
* Il examine les adresses IPv6 disponibles sur ces interfaces
* Il teste l'accessibilité des équipements les uns par rapport aux autres
* Il analyse les résultats de ces tests
* Il en conclut sur la portée et l'utilisation des adresses lien-local

Etape 1
* L'apprenant construit un mini-plan d'adressage sur la base d'un préfixe ULA, et définit les 3 /64 devant être déployés sur chaque réseau
* Il définit les adresses à configurer sur chaque interface
* Il met en oeuvre la configuration des adresses sur chaque interface
* Il observe le résultat de cette configuration sur l'interface et la table de routage
* Il teste l'accessibilité des équipements les uns par rapport aux autres
* Il analyse les résultats de ces tests
* Il en conclut sur le manque de configuration de routage pour avoir une connectivité complète

Etape 2
* Après avoir constaté le besoin de routage pour avoir une connectivité complète
* Il configure les tables de routage de R1 et R2 pour rendre effective cette connectivité
* Il configure une route par defaut sur PC1 et PC2 pour faciliter la connectivité
* Il vérifie l'accessibilité des équipements les uns par rapport aux autres
* Il fait une capture réseau et examine les paquets désassemblés

== [[MOOC:Scenario_TP2 | Informations techniques TP 2]] ==

== [[MOOC:Support_Act26|Texte du TP2]] ==

* Version Netkit pouvant servir de base: [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/1-IPv6_TP-TP2MiseEnOeuvre.pdf TP-2]

===Conclusion===
Grâce à cette deuxième séquence du Mooc IPv6 vous avez découvert et appréhendé différents aspects du protocole:

* Après avoir passé en revue le format de l’en-tête des paquets IPv6,
* Vous avez compris l'importance des mécanismes d’encapsulation,
* Vous avez intégré les principes de routage,
* Vous avez appréhendé les extensions de l’en-tête IPv6
* Enfin après avoir mis en oeuvre une configuration simplifiée

Dorénavent vous êtes aptes à approfondir d'autres mécanismes importants pour faciliter l'intégration du protocole dans toutes les infrastructures où IPv6 sera utile d'être déployer. C'est bien ce que vous allez découvrir dans les prochaines séquences.

MOOC:Activité 26

2015-10-26T15:20:08Z

Bstevant2: /* Configurez votre premier réseau en IPv6 */

__NOTOC__
> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Ateliers|Ateliers]]>[[MOOC:Activité 26 |Activité 26]] 
> [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_2|Séquence 2]]>[[MOOC:Activité 26 |Activité 26]]
----
= Configurez votre premier réseau en IPv6 =

== Objectifs pédagogiques ==

* Maitriser l'outil d'émulation de réseau GNS3
* Mettre en oeuvre un test d'accessibilité entre équipement
* Analyser le résultat d'un test d'accessibilité
* Mettre en oeuvre une capture réseau
* Analyser le résultat d'une capture réseau
* Identifier les entêtes et leurs champs dans un paquet désassemblé
* Comprendre la différence de portée entre une adresse lien local et une adresse globale
* Mettre en oeuvre la configuration d'une adresse IPv6 sur une interface
* Identifier les adresses IPv6 configurées sur une interface réseau
* Mettre en oeuvre la configuration d'une route dans la table de routage
* Identifier les routes disponibles dans une table de routage

Bonus :
* Comprendre le mécanisme de découverte et d'adaptation à la MTU minimale
* Comprendre le mécanisme de routage par la source

== Description ==
L'objectif de cette première activité pratique sera pour vous de configurer un réseau IPv6 et de faire communiquer les différentes machines de ce réseau entre elle. Vous allez ainsi vous familiariser :
* avec l'outil GNS3, le contrôle de l'émulation de réseau et la capture de traces
* avec les interfaces de configuration des différents systèmes utilisés pour les machines
* avec les commandes de configuration utilisées pour IPv6

Différentes étapes dans cette activité vont vous permettre d'observer les communications locales au lien, d'effectuer la mise en place du routage permettant des communications à travers plusieurs réseaux.

Le support de cette activité pratique est disponible en suivant ce lien (http://mooc.ipv6.rennes.telecom-bretagne.eu/Support_Act26.pdf)

Le support vous donne l'ensemble des opérations à réaliser pour aller jusqu'au bout de l'activité. Vous trouverez un résumé de ces commandes dans le Manuel Apprenant disponible en suivant ce lien
(http://mooc.ipv6.rennes.telecom-bretagne.eu/Manuel_Apprenant.pdf)

== Scénario TP ==

=== Topologie ===
[[image:2015_10_20_TP2_screenshot1.png|thumb|center|600px|TP2]]

Situation initiale
* Les interfaces des PCs et routeurs sont toutes désactivées
* Les liens entre les équipements ne sont pas définis

Etape 0
* L'apprenant crée les liens entre les équipements
* Il active les interfaces réseau des équipements
* Il examine les adresses IPv6 disponibles sur ces interfaces
* Il teste l'accessibilité des équipements les uns par rapport aux autres
* Il analyse les résultats de ces tests
* Il en conclut sur la portée et l'utilisation des adresses lien-local

Etape 1
* L'apprenant construit un mini-plan d'adressage sur la base d'un préfixe ULA, et définit les 3 /64 devant être déployés sur chaque réseau
* Il définit les adresses à configurer sur chaque interface
* Il met en oeuvre la configuration des adresses sur chaque interface
* Il observe le résultat de cette configuration sur l'interface et la table de routage
* Il teste l'accessibilité des équipements les uns par rapport aux autres
* Il analyse les résultats de ces tests
* Il en conclut sur le manque de configuration de routage pour avoir une connectivité complète

Etape 2
* Après avoir constaté le besoin de routage pour avoir une connectivité complète
* Il configure les tables de routage de R1 et R2 pour rendre effective cette connectivité
* Il configure une route par defaut sur PC1 et PC2 pour faciliter la connectivité
* Il vérifie l'accessibilité des équipements les uns par rapport aux autres
* Il fait une capture réseau et examine les paquets désassemblés

== [[MOOC:Scenario_TP2 | Informations techniques TP 2]] ==

== [[MOOC:Support_Act26|Texte du TP2]] ==

* Version Netkit pouvant servir de base: [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/1-IPv6_TP-TP2MiseEnOeuvre.pdf TP-2]

===Conclusion===
Grâce à cette deuxième séquence du Mooc IPv6 vous avez découvert et appréhendé différents aspects du protocole:

* Après avoir passé en revue le format de l’en-tête des paquets IPv6,
* Vous avez compris l'importance des mécanismes d’encapsulation,
* Vous avez intégré les principes de routage,
* Vous avez appréhendé les extensions de l’en-tête IPv6
* Enfin après avoir mis en oeuvre une configuration simplifiée

Dorénavent vous êtes aptes à approfondir d'autres mécanismes importants pour faciliter l'intégration du protocole dans toutes les infrastructures où IPv6 sera utile d'être déployer. C'est bien ce que vous allez découvrir dans les prochaines séquences.

MOOC:Intro Sequence 3

2015-10-26T15:02:34Z

Bstevant2: Created page with "= Introduction = La séquence précédente vous a montré qu'IPv6 constitue un retour aux fondamentaux du protocole IP : transporter des données d'un point à un autre du r..."

MOOC:Conclusion 3

2015-10-26T14:45:37Z

Bstevant2:

=Conclusion=

Cette séquence a présenté un ensemble de mécanismes permettant de déployer et opérer efficacement un réseau IPv6 :

* '''ICMPv6''' fournit premièrement un protocole complet pour contrôler le bon fonctionnement du réseau et renvoyer si besoin des rapport d'erreur à l'émetteur d'un message problématique.
* La '''découverte des voisins''' et '''l'auto-configuration''' avec ou sans état permettent au réseau de se configurer automatiquement sans que l'utilisateur et l'administrateur n'ait besoin d'intervenir trop souvent.
* Enfin le '''système de nommage DNS''' offre une gestion de correspondance entre nom et IP permettant de mieux identifier les services de l'internet.

La tâche d'administration d'un réseau IPv6 n'est pas très différente de celle d'un réseau IPv4. Les points qui nécessitent une vigilance particulière sont :
* l'utilisation d'ICMPv6 pour les rapports d'erreur demande de bonnes pratiques de filtrage
* les annonces de routeurs, garants du bon fonctionnement du réseau local, ne doivent pas être perturbés (voir cet [http://www.bortzmeyer.org/6104.html article] de S.Bortzmeyer discutant du problème des RAcailles)
* le choix entre auto-configuration avec ou sans état doit être réfléchi
* l'auto-configuration sans-état des postes client peut demander une mise à jour dynamique du DNS si la politique d'administration demande un enregistrement systématique de tous les postes dans le système de nommage.

Aujourd'hui les réseaux IPv6 seuls ou déployés conjointement avec IPv4 (double-pile) deviennent de plus en plus courant. Les bonnes pratiques de déploiement et d'administration émergent progressivement. Il est donc important de se tenir informer, de partager et d'adapter ses propres pratiques en fonction des expériences de chacun.

MOOC:Compagnon Act34-s6

2015-10-26T14:18:26Z

Bstevant2: /* Activité 34: Faire correspondre adresse et nom de domaine */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenu pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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.
* 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 de nommage, 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.

TO DO ajouter la figure extension de l'arbre de nommage, ajout de la société1.

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.

TODO insérer la figure arbre de serveurs associée à l'arbre de nommage.

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

TO DO insérer la figure réduction de la profondeur de l'arbre de serveurs associée à l'arbre de nommage.

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.

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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 auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''.

Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. 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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le RFC 4862 spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le RFC 6106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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). 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

==Conclusion ==
Le système de nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act34-s6

2015-10-26T14:13:29Z

Bstevant2: /* Exemple d’interrogation d’un serveur DNS avec la commande host : résolution inverse */

__NOTOC__

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

Cette activité introduit le système de nommage communément appelé le DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenu pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face.

==Concepts de base du DNS==

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

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms 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 en 1983. Il en écrit la première mise en œuvre, à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».

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

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.
* 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 de nommage, 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.

TO DO ajouter la figure extension de l'arbre de nommage, ajout de la société1.

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.

TODO insérer la figure arbre de serveurs associée à l'arbre de nommage.

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

TO DO insérer la figure réduction de la profondeur de l'arbre de serveurs associée à l'arbre de nommage.

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.

TODO ajouter la figure relations entre les applications d'une machine, le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. 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 DNS racine de l’arbre.

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

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.

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

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.

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

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 lorsquque cette information est valide et s’y trouve.

Si la question concerne le serveur DNS officiel, déjà connu, d’un domaine, le serveur DNS local contacte directement le serveur DNS concerné.

Les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée.

Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Notez que dans tous ces cas, le traitement des demandes d'information de nommage est accéléré.

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

TO DO insérer figure mise à jour d'un serveur DNS primaire par l'administrateur du réseau

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 ou en le réinitialisant.

''Redémarage''. Le serveur DNS primaire relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

''Réinitialisation''. Le serveur DNS primaire ne relit que ses fichiers de zone et les charge en mémoire RAM : Random Access Memory. Il n'utilise ensuite que les informations disponibles en RAM.

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

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.

TO DO insérer la figure Notification d'un changement de version de base de nommage par le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le serveur DNS primaire.

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

TO DO insérer la figure Mise à jour des serveurs DNS secondaires depuis le
serveur DNS primaire et les serveurs secondaires déjà synchronisés.

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.

TO DO insérer la figure Vérification par le serveur DNS secondaire du numéro
de version de base de nommage du serveur DNS primaire.

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 DNS cache. Ces deux termes sont synonymes.

Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache.

Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

===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 DNS récursif. Ce serveur est dit relais DNS (forwarder).

Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet.

Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire. Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes.

===Serveurs DNS à rôles multiples===

Un serveur DNS BIND peut simultanément se comporter comme un serveur primaire pour certaines zones, comme serveur DNS secondaire pour certaines autres zones, et comme serveur DNS récursif 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 DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr.

Un serveur DNS, non officiel, et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu.

===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:db8: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 ''Deux impossibilités d’accéder au service de nommage''.

De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque 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.
L'administrateur de la zone concernée publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut ''ns3.nic.fr''.

En pratique, on procède par délégation de zone inverse afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS.

Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.

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

Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version.

Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.

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

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

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP (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 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 DNS officiels pour cette zone DNS inverse.

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

Par exemple, Renater a reçu le préfixe ''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 des serveurs DNS récursifs avec ou sans DHCPv6.

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF.

La première concerne l’ajout d’options dans les annonces de routeur. La seconde concerne l’ajout d’options spécifiques dans DHCPv6. La troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique [RFC 4339].

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

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

Le [RFC 4862] spécifie l'autoconfiguration IPv6 sans état. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs.

Le [RFC 6106] définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS) et une option pour définir la liste des noms de domaines recherchés (DNSSL).

Avec ces deux options les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6.

Elle fonctionne sur tout réseau supportant la découverte des voisins. Les configurations du réseau et du service DNS sont alors simultanées.

L’administrateur du réseau configure manuellement les annonces des routeurs pour cette cette autoconfiguration.

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

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

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. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont 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 ===

De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive.

Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage : enregistrements AAAA et PT) et au niveau du transport IPv6 des messages DNS.

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

Par 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. Il intègre toutes les extensions DNS récentes (IPv6, DNSSEC...).

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

Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, serveur DNS récursif ou officiel uniquement.

Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité géné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 DNS.

===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 nommage sur les machines serveur, configurer un serveur DNS primaire, configurer un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.

Configuration du serveur DNS primaire. La configuration du serveur DNS primaire comprend : la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse.

Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service.

Configuration du serveur DNS secondaire. La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone.

Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.

Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.

L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS 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 relatives au service de nommage ou leur absence.

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

Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent pas défaut les informations contenues dans le fichier ''resolv.conf''.

Notez que l’outil ''nslookup'' n’est plus maintenu, son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.

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

Les fichiers de zone contiennent principalement des enregistrements de ressources (resource record).

La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse).

Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.

La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom.

Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.

Le serveur DNS 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 nommage, ''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. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressource doivent commencer dans la première colonne d’une ligne.

Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie.

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

Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.

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

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

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

''SOA : Start Of Authority''. Cet enregistrement de ressource indique qui est le serveur DNS 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 DNS 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 nommage).

''NS : Name Server''. Cet enregistrement de ressource désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée.

Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.

''MX : Mail eXchanger''. Cet enregistrement de ressource désigne un agent de transfert ou un serveur de courrier officiel pour une zone donnée.

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

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

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

''PTR''. Cet enregistrement de ressource définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.

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

===Configuration de serveur DNS ===
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre.

Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme l'implémentation de référence en matière de DNS.

===Réseau virtualisé utilisé pour générer ces exemples ===

Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS.

La machine serveur, ''s-13-v6'', supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 à états sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6).

Le relais, ''r-13-v6'', supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration à états en présence d’un relais DHCPv6.

Le client, ''c-13-v6'', doté de deux interfaces de réseau. La première est connectée d’une part, soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration sans états.

TO DO insérer la figure présentation du réseau virtualisé utilisé
pour générer les exemples

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

====Fichier de configuration d'un serveur BIND9 ====

La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (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, en IPv6, un fichier de résolution inverse par lien dans la zone.

Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents.

Le fichier de configuration du serveur de nom BIND 9 est, par exemple, sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.

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

// This is the primary configuration file for the BIND DNS server named.
//
// 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 ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif l’affichage ou non du numéro de version du serveur.

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

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.

''liste''. Une liste explicite comprenant une ou plusieurs adresses IPv4 données indique que, pour le transport IPv4, le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv4.

''none''. Dans ce cas, le serveur ne supporte pas IPv4.

Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''.

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

''any''. Dans ce cas, le serveur DNS écoute sur toutes ses adresses IPv6 opérationnelles.

''liste'' Une liste explicite comprenant une ou plusieurs adresses IPv6 données indique que le serveur DNS le serveur n'écoute les requêtes et réponses DNS que sur les interfaces configurées avec ces adresses IPv6.

''none''. Dans ce cas, le serveur ne supporte pas IPv6 (valeur par défaut).

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

Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire).

Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type zone.

Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'' la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.

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

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

//
// 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 directe (nom - adresse) ====

Voici à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6.

Notez, dans cet exemple que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée [RFC 4291].

Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.

$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 d’un lien.

====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, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé resolver. Nous utilisons le terme résolveur.

Rappelons que toutes les applications TCP/IP s'exécutant sur une machine donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes.

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

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.

Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.

Notez que lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés.

Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS).

Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin , Voir le chapitre Découverte de la liste de serveurs DNS récursifs.

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

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.

==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 l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit.

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

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. Le chapitre qui suit, ''Deux impossibilités d’accéder au service de nommage et remèdes'', résume ces recommandations.

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 double 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. Des serveurs DNS intermédiaires (cache forwarders) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le processus de résolution d’une requête DNS. Ces serveurs DNS 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 par le client de la réponse DNS renvoyée.

=== Deux impossibilités d’accéder au service de nommage et leurs 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 par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.

====Premier scénario : client IPv4 et serveur IPv6 ====

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

Recommandation. Faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci 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 hébergée sur des serveurs DNS 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 DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6.

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

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des 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 pour 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 DNS 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.

Notez, par ailleurs, 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’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]. 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, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS.

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 « glue » sont nécessaires au démarrage du processus de résolution des noms.

En effet, rappelons que les serveurs DNS racine ne répondent pas eux-mêmes aux requêtes des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS racine (TLD), les serveurs DNS qui gèrent les domaines racines (TLD).

Les informations d'aiguillage incluent la liste des serveurs racine qui gèrent officiellement les informations de nommage d'une zone. 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. Aujourd’hui (en 2015) 10 serveurs DNS racine fonctionnent en IPv6.

===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. Malgré tout, 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'' 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 associée à''foo.tpt.example.com'' comme adresse destination. Sa 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 (du serveur DNS primaire).

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 toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveurs DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (update forwarding).

Le serveur DNS 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 qui est satisfaite la première.

Les serveurs DNS secondaires obtiennent une copie des fichiers de zone modifiés par le serveur DNS 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.

Ainsi la commande nsupdate permet, sur un système Linux, les mises à jour dynamiques du DNS en ligne de commande.

Pour des raisons évidentes de sécurité, les mises à jour dynamiques du DNS utilisent des mécanismes de sécurité.

===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 nommage est l'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 utilise un arbre de nommage pour garantir l’unicité des noms de domaine.

Il a été initialement conçu pour stocker des correspondances directes, nom – adresse et les correspondances inverses, adresse – nom. Mais il peut, plus généralement, stocker tout type d’information, en particulier, celles concernant les agents de transfert ou serveurs 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 nommage 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 serveurs DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des informations du serveur DNS 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. La racine sans nom de l’arbre de nommage est représentée par un « . ». Un domaine est un nœud de l’arbre de nommage.

Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à 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 fichier de configuration du résolveur s’appelle généralement ''resolv.conf''.

Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un serveur est obligatoire.

L’utilisateur qui souhaite communiquer avec une machine distante fournit généralement le nom de cette machine.

Les applications TCP/IP utilisent les procédures de la bibliothèque du résolveur 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 cette machine distante.

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 nommage. 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 directes, 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 DNS primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS officiels pour la zone concernée.

Le serveur DNS primaire utilise des fichiers maîtres contenant les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire non volatile.

Le fichier de nommage direct est unique. Il contient les correspondances nom-adresse IPv4 et IPv4 pour toutes les machines de la zone.

Le fichier de nommage inverse contient un fichier par lien en IPv6 ou par sous-réseau en IPv4.

Les serveurs DNS secondaires peuvent enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone.

L’IETF le recommande fortement. Cette pratique qui réplique la base de nommage accélère le démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de panne catastrophique ou non du serveur DNS 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.

L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec les outils ''dig'' et ''host''. c'es commandes utilisent par défaut les informations du fichier ''resolv.conf''.

Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseau doivent configurer au moins un serveur dual ou un relais DNS dual dans chaque zone.

Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent la déclarer les correspondances directes et les correspondances inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des mécanismes de sécurité pour interdire les modifications non autorisées du service DNS.

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.

MOOC:Compagnon Act33-s7

2015-10-26T14:10:53Z

Bstevant2: /* Annexe 2. Codes d’état du protocole DHCPv6 */

__NOTOC__
= Activité 33: Contrôler la configuration réseau par DHCPv6 =

== Introduction ==

L'auto-configuration à états utilise un serveur pour allouer des adresses IPv6 et/ou des paramètres de configuration à des machines IPv6. Elle réduit les efforts de configuration des machines IPv6, tout comme l'auto-configuration sans état. Elle offre, à la différence de l'auto-configuration sans état, une information de configuration plus riche et un meilleur contrôle de l'affectation des paramètres de configuration. Elle permet en outre la reconfiguration éventuelle des équipements du réseau.

Les deux techniques d'auto-configuration, avec et sans états, ne sont pas exclusives et peuvent coexister dans un même environnement.

Une machine peut, par exemple, obtenir son adresse unicast globale par auto-configuration sans état et obtenir les informations relatives au service de noms (DNS) par l'auto-configuration à états.

Tout le mécanisme d'auto-configuration à états est bâti sur le modèle client-serveur. Il utilise le protocole DHCPv6 (''Dynamic Host Configuration Protocol for IPv6'').

== Principe de fonctionnement du protocole DHCPv6 ==

Le RFC 3315 définit le principe de fonctionnement du protocole DHCPv6. Ce document spécifie l'architecture de communication, les principes de fonctionnement de chaque entité et le format des messages échangés par ces entités.

La mise au point de ce standard a cependant fait l'objet de nombreux débats. DHCP est un élément important du fonctionnement d'un réseau. En conséquence, la parution tardive d'un standard finalisé a entraîné une adoption lente, de son support et de son déploiement.

=== Présentation générale du protocole DHCPv6 ===
Le protocole DHCPv6 est un protocole de niveau application. Il fonctionne conformément au modèle client-serveur.

Ces échanges utilisent une pile de communication UDP/IPv6/réseau physique.
Ils font intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (Requestor).

Les clients sollicitent les serveurs pour obtenir des adresses IPv6 et/ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien.

Les relais relaient les messages des clients et les acheminent vers les serveurs lorsque clients et serveurs ne se trouvent pas sur les mêmes liens. Ils relaient également dans ce cas les messages des serveurs destinés aux clients.

Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6.

Les échanges DHCPv6 se composent de requêtes et de réponses. Il existe deux types de messages : ceux échangés entre client et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.

== Pile de communication utilisée par DHCPv6 ==
DHCPv6 utilise le protocole de transport UDP. Il utilise deux ports : 546 pour le client et 547 pour les serveurs ou les relais.

Un client DHCPv6 envoie les requêtes depuis le port 546 et les envoie vers le port 547.

Lorsque le client et le serveur sont sur le même lien, le serveur reçoit la requête du client sur son port 547.

Lorsque le client n’est pas sur le même lien que le serveur, un relais reçoit la demande du client sur son port 547. Le relais réexpédie ensuite ce message vers le port 547 du relais suivant ou du serveur.

Le serveur DHCPv6 envoie ses réponses depuis son port 547 les envoie vers le port 546 du client si la remise directe est possible. Sinon, le serveur envoie sa réponse au premier relais du chemin de retour, sur le port 547.

Les messages UDP sont encapsulés dans des datagrammes IPv6.

En fonction des indications du serveur DHCPv6, les communications peuvent, au niveau IPv6, se faire en point à point ou en diffusion sélective (multicast) pour la découverte des serveurs DHCPv6 d'un site.

IPv6 s'appuie ensuite sur les fonctions de diffusion, générale ou sélective, du réseau physique sous-jacent pour assurer le transport effectif des messages vers leur destination. Lorsque le réseau n'est pas diffusant, il fait, par exemple, appel à un serveur de diffusion.

== Présentation des entités du protocole DHCPv6 ==

Le protocole DHCPv6 utilise quatre entités pour fonctionner : le client, le serveur, le relais et l'interrogateur. L’utilisation de la quatrième entité, l'interrogateur, est facultative.

Le client DHCPv6 est une machine candidate à une connectivité globale IPv6. Il demande des informations de configuration du réseau à un serveur DHCPv6 pour activer cette connectivité. Il est en relation directe (c'est-à-dire être sur le même lien), soit avec un relais DHCPv6, soit avec le serveur DHCPv6. Il ignore l'existence des relais DHCPv6. Il émet des messages DHCPv6 qu’il envoie au serveur DHCPv6. Il a l'impression de communiquer directement avec le serveur DHCPv6.

Le serveur DHCPv6 centralise les paramètres de configuration des équipements du réseau. Il peut ou non se trouver sur le même lien qu'un client DHCPv6. Il gère la configuration des clients situés sur le même lien ou sur des liens différents. Lorsqu'il ne se trouve pas sur le même lien que son client, les échanges DHCP transitent par un ou plusieurs relais DHCPv6.

Les relais DHCPv6 sont des équipements éventuellement reliés à plusieurs liens. Ils interceptent le trafic des clients DHCPv6 pour l'acheminer vers les serveurs DHCPv6, lorsque ces derniers ne se trouvent pas sur le lien du client. Leur action est transparente pour les clients. Ils transmettent éventuellement des informations locales aux serveurs. Ils utilisent pour cela des options spécifiques des relais.

Notez que ni les relais, ni le serveur ne modifient les messages du client. Les relais se contentent de les encapsuler dans une option de message de relais avant de les relayer vers le serveur.

Les interrogateurs (Requestors) [RFC 5007] sont des entités spécifiques. Les administrateurs les utilisent les interrogateurs pour demander des informations relatives aux clients à un serveur DHCPv6.

Un administrateur peut, ainsi, obtenir des informations relatives aux baux d’un client ou à la machine qui utilise une adresse à un instant donné ou encore pour connaître les adresses allouées à un client donné. Nous ne détaillerons pas ici leur utilisation.

=== Gestion centralisée des ressources allouées ===
Le client, dans la configuration DHCPv6 sans état (stateless), a configuré ses adresses IPv6, soit de façon manuelle (fichier interface, intervention de l’administrateur, soit à partir d’informations extraites d’annonces de routeurs (auto-configuration sans état). Il a alors besoin pour communiquer d'informations telles que l'adresse IPv6 du serveur DNS (le service de nommage convertit, en particulier, les noms en adresses IP).

Lorsque le serveur DHCPv6 transmet des informations statiques, ces dernières ne nécessitent pas de conserver un état. Elles ne font donc pas l’objet d’un enregistrement dans le fichier des baux du serveur DHCPv6.

Le serveur DHCPv6, dans la configuration avec états (''stateful''), alloue une ou plusieurs adresses IPv6 au client. Ces adresses font l’objet d’un contrat de location temporaire, un bail de location. Il consigne alors ce contrat de location dans un registre spécial enregistré dans une mémoire non volatile : le fichier des baux (lease file). Pour cette raison, ce type de configuration est dit avec états.

De plus, un serveur qui redémarre, relit son fichier des baux. Il peut alors exactement reprendre son activité là où il l'avait laissée.

== Fonctions des Messages du protocole DHCPv6 ==
Cette partie présente les messages du protocole DHCPv6. Ce protocole distingue deux types de messages : d’une part, les messages échangés entre client et serveur, et d’autre part, les messages échangés entre serveur et relais. Nous les présentons successivement dans cet ordre.

En général les messages échangés transportent des identificateurs de transaction et des associations d'identités.

Les serveurs DHCPv6 utilisent les identificateurs de transaction pour associer leurs réponses aux demandes correspondantes des clients.

Les identificateurs de transaction changent pour chaque transaction et sont globalement uniques.

Les associations d'identités permettent aux serveurs et aux clients de s'identifier mutuellement. Elles identifient également les interfaces de réseau concernées par les demandes de paramètres de configuration du réseau des clients ou par les réponses des serveurs. Elles sont également transmises dans des options du protocole DHCPv6.

=== Messages échangés entre client et serveur ===
SOLICIT / ADVERTISE

Un client utilise le message SOLICIT (champ type 1) pour localiser les serveurs configurés pour allouer des adresses et/ou des paramètres de configuration du réseau.

Un serveur configuré pour fournir des adresses ou des paramètres de configuration du réseau aux clients annonce sa disponibilité au client DHCPv6 à l'aide d'un message ADVERTISE (champ type 2).
Messages de demande d'information de configuration

REQUEST / REPLY

Un client utilise le message REQUEST (champ type 3) pour demander des adresses et/ou des paramètres de configuration au serveur DHCPv6 choisi. Une option options demandées contient la liste des paramètres de configuration qu’il demande.

Un serveur utilise le message REPLY (champ type 7) pour répondre à un message SOLICIT, REQUEST, RENEW, REBIND reçu d’un client DCHPv6.
=== Messages de gestion des ressources allouées ===

Un client utilise le message CONFIRM (champ type 4) pour indiquer au serveur qui lui a alloué adresses et paramètres de configuration du réseau que ces paramètres sont adaptés au lien auquel le client est raccordé.

Un client utilise le message RENEW (champ type 5) pour prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès du serveur qui les lui a alloués. Le client utilise ce message à la demande explicite du serveur.

Un client utilise le message REBIND (champ type 6) pour obtenir un bail de location des adresses et actualiser des paramètres de configuration auprès de tout serveur DHCPV6, si le serveur DHCPv6 auquel il s'est adressé pour renouveler le bail de ses adresses et ses paramètres de configuration du réseau ne répond pas à son message RENEW.

Un serveur utilise le message REPLY (champ type 7) pour répondre à un message SOLICIT, REQUEST, RENEW ou REBIND reçu d’un client.

Un client utilise le message RELEASE (champ type 8) pour indiquer au serveur DHCPv6 qu'il libère des adresses IPv6.

Un client utilise le message DECLINE (champ type 9) pour signaler au serveur qu’une ou des adresses allouées par le serveur sont déjà utilisées sur le lien du client. La DAD : détection d'adresses dupliquées d'IPv6 peut, par exemple, fournir cette information.

Notez que la détection d’adresses dupliquées incombe toujours au client DHCPv6. En effet, le serveur DHCPv6 ne peut effectuer la DAD que lorsqu’il se trouve sur le même réseau que son client, ce qui n’est pas toujours le cas. Or la DAD n’est possible que sur un lien donné.

Un serveur utilise le message RECONFIGURE (champ type 10) pour signaler au client qu'il a de nouveaux paramètres de configuration du réseau ou les a actualisés. Ce message précise en particulier si le client doit utiliser le message RENEW ou REBIND.

Un client utilise le message INFORMATION-REQUEST (champ type 11) pour demander au serveur des paramètres de configuration du réseau, sans demander d’adresse.

=== Messages échangés entre relais et serveur===

Un relais DHCPv6 utilise le message RELAY-FORWARD (champ type 12) pour relayer des messages DHCPv6 vers un serveur DHCPv6. Le message relayé est soit le message DHCPv6 du client, soit le message RELAY-FORWARD du relais précédent (sur le chemin reliant le client au serveur DHCPv6). Un relais DHCPv6 ne modifie jamais le message d'un client.

Le message du client DHCPv6 est relayé, sans être modifié, dans une option message relayé du message RELAY-FORWARD du premier relais rencontré sur le chemin reliant le client au serveur DHCPv6.

Un serveur DHCPv6 utilise le message RELAY-REPLY (champ type 13) pour envoyer un message à un client, via un relais.

Chaque relais qui reçoit un message RELAY-REPLY extrait le message contenu dans l'option message relayé et le réexpédie vers le client. Seul le contenu de l'option message relayé est donc transmis vers le client.

Le dernier relais extrait le message REPLY destiné au client et contenu dans l'option message relayé de ce message RELAY-REPLY pour le lui remettre. Ici encore, le message du client reste inchangé.

=== Tableau récapitulatif des messages DHCPv6 ===
Le tableau ci-dessous résume le nom, le type, l'émetteur et la fonction des messages DHCPv6 échangés entre client et serveur.

{| class="wikitable"
! Message DHCPv6
! Type
! Emetteur
! Fonction
!
!
!
|-
| SOLICIT
| 1
| Client
| Localiser les serveurs configurés pour fournir des adresses ou des paramètres de configuration .
|
|
|
|-
| ADVERTISE
| 2
| Serveur
| Annoncer la disponibilité du serveur DHCPv6.
|
|
|
|-
| REQUEST
| 3
| Client
| Demander des adresses et/ou des paramètres de configuration au serveur choisi.
|
|
|
|-
| CONFIRM
| 4
| Client
| Indiquer au serveur qui a alloué adresses et paramètres de configuration que ces paramètres sont adaptés au lien auquel le client est raccordé.
|
|
|
|-
| RENEW
| 5
| Client
| Prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès du serveur qui les a alloués.
|
|
|
|-
| REBIND
| 6
| Client
| Obtenir un bail de location des adresses et actualiser des paramètres de configuration auprès de tout serveur en cas de non réponse au message RENEW.
|
|
|
|-
| REPLY
| 7
| Serveur
| Répondre à un message SOLICIT, REQUEST, REBIND reçu d'un client.
|
|
|
|-
| RELEASE
| 8
| Client
| Indiquer au serveur que le client n'utilise plus des adresses IPv6.
|
|
|
|-
| DECLINE
| 9
| Client
| Signaler au serveur qu'une ou des adresses allouées par le serveur sont déjà utilisées sur le lien du client.
|
|
|
|-
| RECONFIGURE
| 10
| Serveur
| Signaler au client que le serveur a de nouveaux paramètres ou les a actualisés.
|
|
|
|-
| INFORMATION-REQUEST
| 11
| Client
| Demander des paramètres de configuration au serveur, sans demander d'adresse.
|
|
|
|-
| RELAY-FORW
| 12
| Relai
| Relayer des messages vers un serveur DHCPv6. Le message relayé (celui du client DHCPv6 ou du relais précédent ) est placé dans une option de ce message RELAY-FORW.
|
|
|
|-
| RELAY-REPL
| 13
| Serveur
| Envoyer, depuis un serveur, un message à un client via un relais . Le relais extrait le message destiné au client ou au relais suivant contenu dans l'option de message relayé de ce message pour le lui remettre.
|
|
|
|}

=== Pour en savoir plus : extension du protocole DHCPv6 [RFC 6422] ===
Notez qu'un mécanisme d'option de relais spécifique permet qu'un relais DHCPv6 communique des paramètres de configuration susceptibles d'intéresser un client DHCPv6 et dont il a connaissance, au serveur DHCPv6.

Le serveur DHCPv6 peut ensuite décider ou non, en fonction de la politique définie par l'administrateur du réseau, de communiquer au client tout ou partie des paramètres de configuration du réseau spécifiques issus du relais.

== Structure des messages DHCPv6 ==

Le document RFC 3315 décrit l'ensemble des éléments du protocole DHCPv6. A l'instar de nombreux protocoles de l'Internet, le protocole d'échange d'informations est découplé de l'information elle-même. La nature des informations échangées peut donc changer et évoluer rapidement, sans impacter les mécanismes de cet échange. Cette séparation assure la stabilité et l'extensibilité du protocole.

La structure des unités de données du protocole reprend ce découpage : un en-tête de taille fixe pour les informations du protocole lui-même et une charge utile transportée dans des champs d'option pour les informations applicatives.

Pour étendre le protocole, il suffit de définir de nouvelles options et de concevoir leur traitement, en émission et en réception.
Dans la terminologie DHCPv6, le terme message désigne une unité de données du protocole DHCPv6. Chaque type de message DHCPv6 (client-serveur ou relais-serveur) a un format d'en-tête identique. De ce point de vue, DHCPv6 reprend les principes de simplification du processus de développement du protocole qui ont guidé la conception du format du segment TCP : un seul format pour l'ensemble des fonctions de TCP.

=== Structure des messages émis par les serveurs et clients DHCPv6 ===
La structure générale des messages échangés entre client et serveur DHCPv6 est la suivante : un champ type, type-msg, un champ identificateur de transaction, id-transaction, et une liste variable d’options, option list.

[[File:MOOC_Act33_Fig1.png|666px]]

''Type-msg''. Le champ type de message identifie la nature du message DHCPv6. Il est codé sur un octet.

''Id-transaction''. L'identificateur de transaction identifie un échange (question-réponse). Il change pour chaque échange et est globalement unique. Il est codé sur 3 octets.

''Option list''. La liste des options du message est de taille variable. Elle correspond à une succession d'options rangées séquentiellement, les unes derrière les autres, et uniquement alignées sur des frontières d'octets. Il n'y a pas de bourrage entre deux options consécutives. Elles transportent, soit les adresses IPv6, soit les paramètres de configuration du réseau (hors adresse IPv6) nécessaires au fonctionnement du réseau.

Pour en savoir plus sur les options, reportez-vous à l’annexe 1. ''Annexe1. Options du protocole DHCPv6''.

=== Structure des messages échangés entre relais et serveur DHCPv6 ===
La structure des messages échangés entre relais et serveur est la suivante :

[[File:MOOC_Act33_Fig2.png|666px]]

Les messages utilisés pour la communication entre serveur et relais sont différents des messages utilisés pour la communication entre client et serveur.
Un message RELAY-FORWARD transite d'un relais, vers le serveur. Un message RELAY-REPLY transite du serveur vers le client. *

''Type-msg''. Le type du message identifie le type du message DHCPv6.

''Hop-count''. Le nombre de sauts identifie, soit le nombre de relais déjà traversés pour atteindre le serveur, soit le nombre de relais restant à traverser pour atteindre le client.

''Link-address''. L'adresse locale au lien désigne l'interface du relais émettrice du message (RELAY-FORWARD) ou destinataire du message (RELAY-REPLY).
''Peer-address''. L'adresse du pair est une adresse globale ou locale au site.
Elle identifie, pour chaque relais, l'interface du relais, côté client. Pour le dernier relais, dans le cas du transit d'un message du serveur vers le client, cette adresse identifie l'interface du relais derrière laquelle se trouve le client.

Ainsi, même en présence de plusieurs relais DHCPv6, le serveur sait auquel des relais s'adresser pour répondre à un client donné.

Chacun des relais, lorsqu'il faut en traverser plusieurs pour atteindre le client, sait à qui transmettre le message de relais contenu dans l'option de message de relais du message RELAY-REPLY reçu. Ce message contient l'adresse locale au lien du relais suivant ou, pour le dernier relais, l'adresse locale au lien du client. Le dernier relais peut donc envoyer au client la réponse du serveur.

==== Message DHCPv6 RELAY-FORWARD ====

''Type-msg''. Le champ type de ce message vaut 12.

''Hop-count''. Le nombre de saut indique le nombre de relais traversés par ce message pour atteindre le serveur.

''Link-address''. L’adresse locale au lien d’un message RELAY-FORWARD est une adresse globale ou une adresse locale au site que le serveur utilise pour identifier le lien où se trouve le client (adresse du relais côté client). C'est l'adresse du relais, du côté du client.

''Peer-address''. L’adresse du pair est l’adresse IPv6 de l'interface depuis laquelle le relais a envoyé le message au serveur. C'est l'adresse du relais du côté du serveur.

''Option list''. La liste d’options de ce message contient obligatoirement une option de message relayé (Relay Message Option) et éventuellement d’autres options ajoutées par le relais.

Notez qu'en aucun cas le relais ne modifie le message DHCPv6 du client.
==== Message DHCPv6 RELAY-REPLY ====

Le serveur envoie ce message au premier relais sur le chemin du retour vers le client demandeur.

''Type-msg''. Le champ type de ce message vaut 13.
''Hop-count''. Le nombre de saut indique le nombre de relais que ce message traversera pour atteindre le client.

''Link-address'' et ''Peer-address''. Les adresses du lien et du pair sont recopiées à partir du message RELAY-FORWARD précédent.

''Option list''. La liste d’options doit obligatoirement contenir une option de message relayé (Relay Message option). Cette option transporte la réponse du serveur DHCPv6 destinée au client DHCPv6.

=== Types de DUID : DHCPv6 Unique IDentifier ===

Le RFC 3315 définit 3types d’identificateurs unique DHCPv6 (DUID).

Afin de connaître l'état des ressources gérées (représentées par les paramètres de configuration), le serveur DHCP gère une liste d'associations entre le paramètre attribué et le client. Comme l'adresse unicast du client est une ressource dépendant du serveur, celle-ci n'est pas utilisable par le serveur DHCP pour identifier un client. Le serveur identifie donc le client par un identifiant unique à usage exclusif de DHCP : le DUID : DHCP Unique IDentifier.

Chaque station génère son identifiant. Cet identifiant doit être permanent et avoir une grande durée de vie. Une station peut, par exemple, et à un instant donné, générer un DUID à partir de l'adresse MAC d'une de ses cartes réseau. Elle le conservera alors son identifiant, même en cas de remplacement ultérieur de cette carte réseau.

Les clients utilisent les DUID pour identifier les serveurs quand et là où ils en ont besoin, par exemple, pour mémoriser l'identité du serveur qui leur a alloué des adresses IPv6 et/ou des paramètres de configuration du réseau.
Le contenu des DUID n’est pas interprété, mais uniquement utilisé pour des comparaisons pour vérifier l'identité du correspondant. Le DUID concerne la machine (client ou serveur) et non une de ses interfaces.

Les DUID peuvent être générés selon 3 méthodes : combinaison d'une adresse physique et d'une horodate, dérivée d'un numéro de constructeur ou d'un numéro unique affecté par un constructeur, ou enfin, dérivée de l'adresse MAC d'une interface de réseau.

Les valeurs des champs type de DUID sont les suivantes.

*1 : Link-layer address plus time (DUID-LLT)
*2 : Vendor-assigned unique ID based on Enterprise Number (DUID-EN)
*3 : Link-layer address (DUID-LL)

Le type de DUID est codé sur 2 octets. Un nombre variable d’octets suit et constitue l’identificateur. La longueur maximale d’un identificateur est 128 octets.

Le DUID est lui-même une structure de donnée qui selon le mode de construction, contient des types de valeurs différents.

==== DUID construit à partir de l'adresse physique + horodate (DUID-LLT) ====

[[File:MOOC_Act33_Fig3.png|666px]]

<tt>Msg-type</tt> Le champ type (2 octets) vaut 1

<tt>Hardware type</tt> Deux octets contiennent le type de réseau physique.

<tt>Time</tt> L’horodate est codée sur 4 octets.

<tt>Link-layer address</tt> La longueur de l’adresse physique (adresse MAC) varie en fonction du type du réseau physique.

Le choix de l’interface dont on utilise l’adresse physique est indifférent tant que l’identification est unique. Le DUID doit être enregistré dans une mémoire non volatile et doit continuer à être utilisé, même en cas de remplacement ultérieur de l’interface qui a servi à le générer.

Ce type de DUID est recommandé pour les ordinateurs de bureau, les ordinateurs portables, ou plus généralement pour tout équipement doté d'une mémoire non volatile où l’écriture est possible.

====DUID dérivé du numéro d’entreprise affecté par un constructeur (DUID-EN) ====

Un constructeur affecte ce type d’identificateur à un équipement. Le DUID-EN combine le numéro unique affecté à l’entreprise et un identificateur de longueur variable, unique pour l’entreprise et défini par elle. Le numéro d’entreprise est généralement un entier non signé codé sur 32 bits.

La structure de l'option est la suivante :

[[File:MOOC_Act33_Fig4.png|666px]]

Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction. Il l’enregistre généralement dans une mémoire non volatile de l’équipement.

==== DUID dérivé de l’adresse physique de l’équipement (DUID-LL) ====

Le DUID-LL n’utilise que l’adresse physique de l’équipement. La longueur de l’adresse physique (adresse MAC) varie en fonction du réseau physique. Le choix de l’interface dont on utilise l’adresse physique est indifférent tant que l’identification est unique. Le DUID doit être enregistré dans une mémoire non volatile et doit continuer à être utilisé, même en cas de remplacement ultérieur de l’interface qui a servi à le générer.

La structure de l'option est la suivante :

[[File:MOOC_Act33_Fig5.png|666px]]

Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction. Il l’enregistre généralement dans une mémoire non volatile de l’équipement.

Ce format est recommandé pour les équipements dépourvus de mémoire de stockage et qui ont une interface de réseau connectée en permanence au réseau (une imprimante réseau, par exemple).

=== Association d'identités ===

Une association d’identités IA : Identity Association permet qu’un serveur ou un client identifie, groupe ou gère un ensemble d’adresses IPv6 associées. Chaque association se compose d’un identificateur d’association et des informations de configuration associées. Ces informations sont enregistrées dans des options de l'association.

Un client associe au moins une association d’identités, IA, à chacune des interfaces de réseau pour laquelle il requiert une adresse IPv6.

Cette IA reste affectée en permanence à l'interface. Elle simplifie le format des messages DHCPv6, la gestion de la durée de vie des adresses IPv6 ou encore la renumérotation du réseau IPv6 (voir le principe de la renumérotation).

Les informations de configuration correspondent à une ou plusieurs adresses IPv6 et à leurs temporisations associées : T1 et T2, où T1 représente la durée de vie de l‘adresse dans l’état préféré. T2 représente la durée de validité de l’adresse IPv6.

Un serveur DHCPv6 peut allouer deux types d'adresses IPv6 : des adresses non temporaires et des adresses temporaires.

==== Allocation des adresses non temporaires ====

Le serveur choisit les adresses d’un client en fonction du lien du client, du DUID du client, des options fournies par le client, et des informations fournies par le relais DHCPv6.

Les adresses allouées font l'objet d'une écriture dans le fichier des baux.
Allocation des adresses temporaires

DHCPv6 gère les adresses temporaires comme les adresses non temporaires. Une association d’identités pour adresse temporaire ne contient au plus qu’une seule adresse temporaire.

Ici encore, l'allocation d'adresse fait l'objet d'une écriture dans le fichier des baux.

Le serveur DHCPv6, s'il est configuré pour cela effectue des mises à jour dynamiques sécurisées du service de noms de domaine.

=== Options du protcole DHCPv6===

Un champ type d'option identifie chaque option d'un paquet DHCPv6. Il permet l'interprétation des données transportées. Certaines options peuvent en contenir d'autres ou être structurée en plusieurs champs (voir Annexe 1. Options du protocole DHCPv6).

Chaque option est codée en format TLV : type, longueur, valeur, à savoir, le type de l'option, la longueur, en octet, du champ valeur du paramètre qui suit et le champ valeur du paramètre de configuration.

Le champ type de l'option est toujours codé sur 2 octets.
Le champ longueur est codé sur 2 octets. Il est toujours présent, même en l'absence de valeur ou pour une information de longueur fixe. Il exclut le champ type de l'option.

La longueur totale en octet d'une option est donc souvent 4 + longueur de la valeur du champ longueur de l'option. Elle peut être plus importante si l'en-tête de l'option inclut des informations de taille fixe.

Le tableau qui suit présente les options du protocole DHCPv6, leur code et leur définition. L’annexe 1 ''Annexe1. Options du protocole DHCPv6'' présente leur structure.

{|
|+'''Options de DHCPv6'''
! Désignation || Code || Définition
|-style="background:silver"
|<tt>OPTION_CLIENTID</tt>
||1
||Identification du client
|-
|<tt>OPTION_SERVERID</tt>
||2
||Identification du serveur
|-style="background:silver"
|<tt>OPTION_IA_NA</tt>
||3
||Association d’identités pour les options d’adresse non temporaire
|-
|<tt>OPTION_IA_TA</tt>
||4
||Association d’identités pour les options d’adresse temporaire
|-style="background:silver"
|<tt>OPTION_IAADDR</tt>
||5
||Adresse associée à IA_NA ou IA_TA
|-
|<tt>OPTION_ORO</tt>
||6
||Identifie une liste d’options dans les messages échangés entre un client
|-style="background:silver"
|<tt>OPTION_PREFERENCE</tt>
||7
||Annonce au client la priorité du serveur DHCPv6 et comment gérer cette priorité.
|-
|<tt>OPTION_ELAPSED_TIME</tt>
||8
||Temps écoulé depuis le démarrage d'un échange pour la machine qui tente d’achever sa configuration.
|-style="background:silver"
|<tt>OPTION_RELAY_MSG</tt>
||9
||Transporte un message DHCPv6 relayé dans des messages relay-forw ou relay-repl
|-
|<tt>OPTION_AUTH</tt>
||11
||Transporte les informations d’authentification de l’identité et du contenu des messages DHCPv6.
|-style="background:silver"
|<tt>OPTION_UNICAST</tt>
||12
||Permet au serveur d'indiquer au client qu’il peut utiliser l’adresse individuelle (unicast) du serveur pour échanger aavec lui.
|-
|<tt>OPTION_STATUS_CODE</tt>
||13
||Indique le statut du message DHCPv6 qui transporte cette option.
|-style="background:silver"
|<tt>OPTION_RAPID_COMMIT</tt>
||14
||Permet, dans un message solicit, à un client de demander ce mode de fonctionnement pour réaliser des échanges en deux temps au lieu de quatre. Le serveur doit inclure cette option dans la réponse correspondante (Solicit reply).
|-
|<tt>OPTION_USER_CLASS</tt>
||15
||Définit la classe d’utilisateur associée à un utilisateur ou à une application.
|-style="background:silver"
|<tt>OPTION_VENDOR_CLASS</tt>
||16
||Identifie le constructeur du matériel utilisé par le client.
|-
|<tt>OPTION_VENDOR_OPTS</tt>
||17
||Permet que les client et serveur échangent des informations spécifiques d’un constructeur.
|-style="background:silver"
|<tt>OPTION_INTERFACE_ID</tt>
||18
||Identifie l’interface de réception du message du client DHCPv6.
|-
|<tt>OPTION_RECONF_MSG</tt>
||19
||Indique, dans un message reconfiguration, si le client doit répondre par un message renew ou information-request.
|-style="background:silver"
|<tt>OPTION_RECONF_ACCEPT</tt>
||20
||Indique à un serveur si le client accepte ou refuse les messages reconfigure ou annonce à un client qu'il peut ou non accepter les messages reconfigure.
|}

==Principe de l’allocation d’adresse IPv6 à un client en l’absence de relais ==

Un client relié au même lien que le serveur DHCPv6, utilise le message DHCPv6 SOLICIT pour découvrir les serveurs configurés pour lui fournir des adresses IPv6 ou des paramètres de configuration du réseau. Comme a priori ce client ignore l'adresse IPv6 du serveur, le client DHCPv6 envoie toujours (c'est le mode de fonctionnement par défaut) ce message à l’adresse de diffusion sélective IPv6 ''ALL_DHCP_And_ Relay_Agent''.

Les serveurs capables d’allouer des adresses au client répondent avec un message DHCPv6 ADVERTISE. Ils font une offre au client DHCPv6.

Le client, si plusieurs serveurs DHCPV6 sont disponibles, ne collecte leurs réponses que pendant un certain temps. Il sélectionne ensuite l'offre qui satisfait le mieux ses besoins. Il émet alors un message REQUEST destiné au serveur sélectionné. Il envoie ce message à l’adresse de diffusion sélective ''ALL_DHCP_And_ Relay_Agent''.

Tous les serveurs qui ont répondu à la demande du client savent ainsi si leur offre a ou non été retenue. Le serveur dont l'offre à été retenue, et lui seul, renvoie un message REPLY au client.

La figure ci-dessous résume les messages DHCPv6 échangés dans ce cas.

[[Image:MOOC_Act33_Fig6.png|666px]]

=== Recherche des serveurs DHCPv6 par le client : fonctionnement de la pile de communication ===

Le client DHCPv6 demande au serveur une adresse IPv6 et un certain nombre de paramètres de configuration du réseau. Il fabrique donc un message DHCPv6 SOLICIT. Il émet ensuite ce message DHCPv6 SOLICIT pour découvrir les serveurs DHCPv6 disponible.

Il s’adresse localement au protocole UDP sur le port local du client DHCPv6 (546) pour expédier ce message vers le port UDP destination du serveur (547). Comme à ce stade le client DHCPv6 ignore l’adresse IPv6 du serveur, il fournit à UDP l’adresse IPv6 de diffusion sélective (multicast) réservée au protocole DHCPv6, comme adresse IPv6 de destination.

UDP ne gère pas les adresses IPv6. Il transmet donc simplement l’adresse IPv6 de destination du message UDP à transmettre à la couche IPv6.

IPv6 fabrique l’en-tête du datagramme qui transporte le message DHCPv6 encapsulé dans UDP. Si notre client n’a qu’une interface, celle-ci est associée à la route par défaut. Sinon, le client envoie le message depuis l'interface de réseau associée à la route par défaut. L'adresse IPv6 source utilisée dans le datagramme IPv6 est l'adresse locale au lien de cette interface.

Notez que l'administrateur du réseau définit l'interface de réseau à utiliser par défaut. Il peut effectuer cette configuration au niveau d'une image disque ou encore au niveau d'un fichier de configuration du client DHCPv6.

L’adresse de destination est une adresse de diffusion sélective. Elle n’est associée à aucune route spécifique. Le trafic destiné à ce groupe emprunte la route par défaut. L’adresse IPv6 source utilisée ici est donc l’adresse locale au lien de cette interface.

IPv6 demande ensuite à Ethernet d’expédier ce datagramme. L’adresse IPv6 de diffusion sélective de destination est ensuite associée à l’adresse Ethernet de diffusion sélective spécifique d’IPv6. Ceci permet d’utiliser, au niveau Ethernet, la diffusion sélective et de ne pas recourir, sur le lien, à la diffusion générale, ce qui dérangerait un nombre potentiellement considérable de machines sur un réseau IPv6.

Le client DHCPv6 envoie donc la trame Ethernet sur le lien, vers le serveur DHCPv6.

== Principe de l’allocation d’adresse IPv6 à un client en présence d’un relais DHCPv6 ==

Lorsque le client se trouve sur un lien différent de celui du serveur DHCPv6, ce dernier ignore sur quel lien se trouve le client. Il ne peut alors allouer des adresses correspondant aux liens du client qu'à condition de pouvoir identifier ces liens, et donc d'identifier le ou les préfixes à y utiliser.

Le routeur intermédiaire entre le client et le serveur DHCPv6 doit supporter une fonction relais DHCPv6. Comme DHCPv6 est un nouveau protocole spécifique d’IPv6, il n’a pas de contrainte de compatibilité ascendante. C’est pourquoi le fonctionnement des relais DHCPv6 est différent de celui des relais DHCPv4.

L'activation de la fonction relais DHCPv6 sur le routeur le transforme en relais DHCPv6. Nous ferons un abus de langage en nommant ce routeur relais DHCPv6 (nous l'avions déjà fait, mais sans le dire...).

Notez que pour un routeur Linux, par exemple, il suffit de configurer un processus relais DHCPv6 et d'activer ce processus pour que le relais soit opérationnel.

Un relais DHCPv6 qui reçoit un message DHCPv6 d’un client l'encapsule dans un message DHCPv6 RELAY-FORWARD. Le message du client est inclus dans l'option message relayé du message RELAY-FORWARD que le relais envoie au serveur. Le relais DHCPv6 envoie ensuite le message RELAY-FORWARD au serveur DHCPV6, soit en utilisant l’adresse de diffusion sélective réservée, et dans ce cas aucune configuration n'est nécessaire, soit en utilisant l’adresse individuelle (unicast) du serveur.

L'administrateur du réseau doit, bien entendu dans ce cas, adapter la configuration du serveur et des relais en fonction du type d’adresse, individuelle ou diffusion sélective, utilisé.

Lorsque le message DHCPv6 d’un client doit traverser plusieurs relais DHCPv6, chaque relais encapsule le message RELAY-FORWARD reçu du relais précédent dans l'option message relayé de son propre message RELAY-FORWARD.

Chaque relais traversé identifie (adresse globale ou locale au lien) dans son message RELAY-FORWARD, l’interface sur laquelle il a reçu le message du client ou du relais précédent et l’adresse locale au lien de l’interface par laquelle il réexpédie son message RELAY-FORWARD au serveur ou au relais suivant.

Notez que le message du client est recopié dans l'option message relayé message RELAY-FORWARD du premier relais DHCPv6 traversé.

Si le message traverse plusieurs relais, l'option message relayé du relais courant contient le message RELAY-FORWARD du relais précédent.

Lorsque serveur DHCPv6 reçoit le message RELAY-FORWARD du dernier relais DHCPv6, l'en-tête de ce message contient l'adresse IPv6 du dernier relais. Il saura donc où envoyer son message RELAY-REPLY.

Chaque relais intermédiaire procède de la sorte en extrayant le message RELAY-REPLY du relais précédent de l’option message relayé du message RELAY-REPLY reçu.

Le chemin inverse n’est par conséquent pas difficile à calculer. Le protocole DHCPv6 peut donc ainsi faire parvenir sa réponse du serveur au client.

[[Image:MOOC_Act33_Fig7.png|666px]]

Après la phase d'acquisition de l'adresse IPv6, le client DHCPv6 vérifie (DAD) que l'adresse ipv6 allouée n'est pas déjà en service (DAD : détection d'adresse dupliquée). Il configure alors ses interfaces de réseau.

L'utilisateur qui travaille sur le client DHCPv6 peut alors accéder au réseau.

Le processus DHCPv6 client devient alors inactif jusqu'à ce que l'utilisateur qui travaille sur le client DHCPv6 ferme sa session et arrête le client. Il se réactive alors pour libérer (release) l'adresse IPv6 allouée.

== Libération de l'adresse IPv6 par le client DHCPv6 avec présence d'un relais ==
Le processus d'arrêt normal du client DHCPv6 inclut la libération de l'adresse IPv6 allouée par le serveur. La figure ci-dessous présente la libération de l'adresse IPv6 en présence d'un relais.

[[Image:MOOC_Act33_Fig8.png|666px]]

La figure ci-dessous présente la libération de l'adresse IPv6 en l'absence de relais;

[[Image:MOOC_Act33_Fig9.png|666px]]

== Délégation de préfixe à états ==
La délégation de préfixe à états fait intervenir deux routeurs : un routeur délégataire et un routeur demandeur. Le routeur délégataire alloue les préfixes. Le routeur demandeur demande un ou plusieurs préfixes au routeur délégataire.

La délégation de préfixe à états utilise le protocole DHCPv6 pour déléguer les préfixes. Elle définit deux options : une association d'identités pour l'allocation de préfixes (IA_PD) et une option de préfixe d'association d'identités pour la délégation de préfixes (IA_PD Prefix).
Le routeur demandeur émet ses demandes sur l'interface qui donne accès au routeur délégataire.

Le routeur délégataire répond sur l'interface qui donne accès au routeur demandeur. Lorsque ces deux routeurs ne se trouvent pas sur le même réseau, des relais DHCPv6 interviennent, comme dans le cas de l'allocation d'adresses. Leur fonctionnement est inchangé.

La délégation de préfixe à états se fait sans relais lorsque les routeurs délégataire et demandeur sont sur le même lien.

Les options de délégation de préfixe permettent au routeur délégataire de déléguer la gestion d'un ou plusieurs préfixes à un routeur demandeur.

L'association d'identités pour l'allocation de préfixes associe notamment les DUID des routeurs demandeur et délégataire, et les préfixes alloués.
L'option de préfixe d'association d'identités pour la délégation de préfixe transporte un préfixe qu'un routeur délégataire a délégué à un routeur demandeur. Cette option peut apparaître plusieurs fois dans une association d'identités (IA_PD).

Notez que la délégation de préfixe à états est indépendante de l'allocation des adresses IPv6.

=== Applications de la délégation de préfixe ===

La délégation de préfixe convient pour des situations où le routeur délégataire ignore la topologie du réseau auquel le routeur demandeur donne accès et n'a pas d'autre information à connaître que l'identité du routeur demandeur pour allouer le préfixe.

C'est, par exemple, le cas du routeur d'un FAI : fournisseur d'accès Internet) (ISP : Internet service Provider) qui alloue un préfixe au routeur d'accès d'un client (CPE : Customer Premise Equipment) reliant un réseau interne au réseau du FAI.

La figure ci-dessous présente un exemple où la délégation de préfixe à états est possible.

[[Image:MOOC_Act33_Fig10.png|666px]]

La délégation de préfixe facilite également la renumérotation. Elle permet, par exemple, d'allouer le préfixe qui servira à générer les nouvelles adresses IPv6.

Les préfixes sont censés avoir une grande durée de vie. En cas de renumérotation, la cohabitation pendant un certain temps de l'ancien et du nouveau préfixe est fort probable. C'est, par exemple le cas pour la renumérotation passive présentée ci-dessous.

==== Renumérotation des réseaux ====
La renummérotation peut se faire de deux façons : passive ou active.

===== Renumérotation passive =====
Dans la renumérotation passive, chaque machine du réseau dispose de deux adresses IPv6 : une ancienne et une nouvelle.

Sur chaque machine, toutes les communications utilisant l'ancienne adresse sont préservées aussi longtemps que nécessaire (RENEW).

Toutes les nouvelles communications sont établies à l'aide de la nouvelle adresse.

Lorsque la dernière machine du réseau cesse d'utiliser son ancienne adresse, la renumérotation est terminée.

===== Renumérotation active =====
Dans la renumérotation active, chaque machine, comme dans le cas précédent, dispose d'une ancienne adresse et d'une nouvelle.

Le serveur DHCPv6 force les clients à cesser d'utiliser leur ancienne adresse à une date donnée. Le serveur réduit la durée de vie des anciennes adresse en fonction de la date d'échéance cible.

Lorsque la date d'échéance arrive, aucune utilisation d'ancienne adresse n'est plus possible. TOutes les communications utilisant les anciennes adresses sont coupées.

Elles sont, en cas de besoin, rétablies en utilisant les nouvelle adresses.

Ici encore la délégation de préfixe à états peut faciliter les choses en permettant que les machines auto-configurent leurs nouvelles adresses.

Notez que l'utilisation du préfixe alloué sur le routeur demandeur est impossible sur le lien donnant accès au routeur délégataire. Ceci empêche par conséquent l'agrégation des routes d'acès au routeur demandeur et d'accès au réseau qu'il dessert.

Deux autres options [RFC 6603], permettent d'exclure un seul préfixe pour l'affecter au lien qui, sur le routeur demandeur, donne accès au routeur délégataire.

Certains réseaux mobiles doivent pouvoir agréger les routes (vers le routeur demandeur et le réseau interne). Dans ce cas, le routeur demandeur doit utiliser le préfixe du réseau interne que l'interface qui le relie au routeur délégataire. il utilise alors des deux options du [RFC 6603]

=== Structure de l'option d'association d'identités pour la délégation de préfixes (RFC 3633, RFC 7550) ===

La structure de cette option est la suivante :

[[Image:MOOC_Act33_Fig11.png|666px]]

''OPTION_IA_PD''. Le champ type de cette option a pour valeur 25.

''Option-length''. La longueur de l'option est la longueur, en octet, de la valeur des options IA_PD options.

''IAID''. L'IAID est l'identificateur d'association d'identités.
''T1, T2''. Les temporisations T1 et T2 représentent en secondes les durées de vie du préfixe en mode préféré et durée de vie totale.

=== Option de préfixe d'association d'identités pour la délégation de préfixe ===
L'option de préfixe d'association d'identités pour la délégation de préfixe (IA_PD Prefix) contient les préfixes associés à une IA_PD. Elle est incluse dans l'option IA_PD.

La structure de cette option est la suivante :

[[Image:MOOC_Act33_Fig12_1.png|666px]]

<tt>Msg-type</tt> Le champ type de cette option vaut 26.

<tt>Option-length</tt> Le champ longueur du champ option est la longueur en octet du champ d'option de cette option.

<tt>Preferred- lifetime, valid lifetime</tt> Les durées de vie préférée et totale sont celles du préfixe.

<tt>Prefix-length</tt> Le champ donne la longueur en bits du préfixe.

<tt>IPv6 prefix</tt> La valeur du préfixe, codée sur 16 octets, donne la valeur du préfixe.

<tt>IAprefix-options</tt> Liste les options relatives à ce préfixe.

=== Principe de l'allocation de préfixe à états sans relais ===

[[Image:MOOC_Act33_Fig13.png|666px]]

Le routeur demandeur se comporte comme un client DHCPv6. Il émet un message SOLICIT contenant une association d'identités pour l'allocation de préfixes à états, IA_PD.

Le routeur délégataire se comporte comme un serveur DHCPV6. Il alloue les préfixes en fonction de l'identité du routeur demandeur et des options de préfixe indiquées.

=== Principe de l'allocation de préfixe à états avec relais ===

[[Image:MOOC_Act33_Fig14.png|666px]]

Le relais encapsule le message SOLICIT du client dans l'option message relayé de son message RELAY-FORWARD. Il achemine ensuite ce message vers le serveur.

Le serveur renvoie son message RELAY-REPLY au relais.

Le relais extrait le message ADVERTISE de l'option message relayé du message RELAY-REPLY du serveur. Il le transmet ensuite au client. Il identifie l'interface d'accès au client grâce à l'adresse du lien incluse dans l'en-tête du message RELAY-REPLY.

== Conclusion ==
DHCPv6 est un protocole de niveau application. Il utilise le service de transport d'UDP. Il fonctionne en mode client-serveur. Les messages échangés transportent l'identité de l'émetteur (DUID), celui du récepteur ou les deux, en fonction du sens de transmission du message et de l'avancement de l'échange.

Ce protocole permet qu'un administrateur centralise et gère simplement les paramètres de configuration du réseau, répercute les changements de configuration à l'initiative du serveur DHCPv6 (renumérotation active), ou au contraire laisse aux clients la possibilité de les prendre en compte, lorsqu'ils le souhaitent (renumérotation passive).

Il fonctionne sans relais lorsque le client et le serveur se trouvent sur le même lien. Il fait intervenir des relais lorsque client et serveur sont sur des liens distincts.

Les relais utilisent des messages spécifiques pour communiquer avec les serveurs DHCPv6. Ils encapsulent les messages relayés dans une option de message relayé. Ainsi les messages des clients, ceux des serveurs ou ceux des relais ne sont jamais modifiés.

Lorsque les relais disposent d’informations locales, des options spécifiques des messages RELAY-FORWARD leur permettent de les communiquer aux serveurs DHCPv6.

Les serveurs DHCPv6, en fonction de leur configuration par l’administrateur du réseau, peuvent communiquer tout ou partie de ces informations à leurs clients.
Tous les paramètres de configuration du réseau sont transportés dans des options des messages, ce qui fait de DHCPv6 un protocole extensible. Pour étendre le protocole, il suffit d’y ajouter de nouvelles options.

Initialement, ni la délégation de préfixe, ni l'exclusion de préfixe n'existaient. Il a suffit de définir deux options et leur gestion en émission et en réception pour ajouter cette nouvelle fonctionnalité dans DHCPv6.

Ceci a impliqué RFC 7550 des modifications pour clarifier ou préciser la spécification de DHCPv6 RFC 3315 et entraînera prochainement la publication d'une nouvelle version de la spécification du protocole DHCPv6.

== Annexe 1. Structure des options du protocole DHCPv6 ==
La structure générale des options est la suivante. Elle correspond à un codage TLV : type, longueur, valeur.

Le type ou code est un entier non signé. Il précise quelle est l’option. La longueur de l’option précise la taille en octet du champs de données de l’option. Le champs type de l'option en est exclus. Les données de l’option suivent. Dans certains cas, une option peut en contenir d’autres.

la portée des options est définie par encapsulation. Certaines options s'appliquent globalement, d'autres sont spécifiques d'un association d'identités, d'autres encore sont spécifiques d'une adresse, dans une association d'identités.

La structure générale d'une 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-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option d'identification du client ===
L'option d'identification du client (Client Identifier Option) transporte le DUID (DHCPv6 User Identification) du client dans les messages DHCPv6 échangés entre client et serveur.

La structure de cette 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_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option identification du serveur (Server Identification Option)===
L'option identification du serveur (Server Identification Option) transporte le DUID (DHCPv6 User Identification) du serveur dans les messages DHCPv6 échangés entre client et serveur.

La structure de cette 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_SERVERID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option association d’identité pour les adresses non temporaires ===
L'Option association d’identité pour les adresses non temporaires (option IA_NA : Identity Association for Non Temporary Addresses) inclut les paramètres de cette association et les adresses non temporaires associées. Elle apparaît une ou plusieurs fois dans le champ d'options d'un message DHCPv6.

Cette association transporte un identificateur d'IA_NA, les temporisations T1 durée de vie préférée d'une adresse et T2 durée de vie maximum d'une adresse et les options de cette association, par exemple la liste des options d'adresse spécifiques de cette association.

La structure de cette 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_IA_NA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_NA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option d'association d’identité pour les adresses temporaires ===
L'option d'association d’identité pour les adresses temporaires (option IA_TA : Identity Association for Temporary Addresses) inclut les paramètres de cette association et au plus une adresses temporaires associées par préfixe autorisé sur le lien du client. Elle apparaît une ou plusieurs fois dans le champ d'options d'un message DHCPv6. Une option statut indique l'état de toute opération impliquant cette option.

La structure de cette 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_IA_TA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_TA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option d’adresse d'association d'identités ===
L'option d'adresse'association d'identités (IA Address Option) spécifie une adresse IPv6 associée à une association d'identités IA_NA ou IA_TA. Elle apparaît dans le champ d'option d'une association d'identités pour adresse non temporaire ou temporaire. Une option statut indique l'état de toute opération impliquant cette adresse.

La structure de cette 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_IAADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IAaddr-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option de demande d’options ===
L'option de demande d'option (Options Request Option) identifie la liste des options demandées par le client ou fournies ou cconcernées pour le serveur.

La structure de cette 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_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option de priorité (du serveur) ===
L'option de priorité (Preference Option) indique la priorité du serveur au client.

Un client choisit le serveur de priorité la plus élevée. En cas d'égalité des priorités, il choisit le serveur de priorité la plus élevée qui lui propose la meilleure offre. Il peut ne pas choisir l'offre du serveur le plus prioritaire. Le choix repose alors sur l'adéquation de l'offre.

La structure de cette 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_PREFERENCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref-value |
+-+-+-+-+-+-+-+-+

=== Option temps écoulé (depuis le début d'un échange) ===
L'option temps écoulé mesure le temps écoulé (Elapsed Time Option) depuis l'émission du premier message d'un échange DHCPv6 inachevé. Cette option vaut 0 dans le premier message d'un échange.

Serveurs et agents utilisent la valeur de cette option pour déterminer leur façon de traiter le message DHCPv6 correspondant. La valeur ffff en hexadécimal (0xffff) représente une durée supérieure à la plus grande durée représentable.

La structure de cette 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_ELAPSED_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| elapsed-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option message relayé ===
L'option message relayé (RELAY Message Option) contient le message DHCPv6 relayé dans un message RELAY-FORWARD ou RELAY-REPLY.

Le message relayé, dans le cas d'un message qui transite du client vers le serveur, est soit le message DHCPv6 du client (premier relais), soit le message RELAY-FORWARD du relais précédent (du deuxième relais au dernier).

Le message relayé dans le cas d'un message qui transite du serveur vers le client est, soit le message REPLY du serveur (premier relais), soit le message RELAY-REPLY du relais précédent (du deuxième relais au dernier).

La structure de cette 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_RELAY_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCP-relay-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option d’authentification ===
L'option d'authentification (Authetication Option) transporte une information d'authentification. Cette information authentifie l'identité de l'émetteur et l'intégrité du message DHCPv6. Cette option fournit un environnement qui prend en compte différents protocoles d'authentification, ce qui permettra d'en prendre en compte de nouveaux.

Cette option décrit donc le protocole d'authentification utilisé, la méthode de protection contre le rejeu, l'algorithme de génération du condensé (MAC : Message Authentification Code) qui authentifie le message, et bien entendu la valeur du condensé (128 bits, pa exemple).

Rappel : le principe de l'authentification consiste à calculer un condensé de taille fixe qui ne dépend que de l'information prise en compte (le message DHCPv6, par exemple) en utilisant un algorithme tel que deux informations différentes produisent très probablement des condensés différents. La comparaison des condensés reçu et calculé par le récepteur permet de décider si les données reçues sont ou ne sont pas acceptables. Si ces condensés sont ientiques, l'information est acceptable. Elle ne l'est pas sinon.

La sécurisation des échanges DHCPv6 entre serveurs et relais adjacents utilise IPsec.

La structure de cette 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_AUTH | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | algorithm | RDM | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| replay detection (64 bits) +-+-+-+-+-+-+-+-+
| | auth-info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. authentication information .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option d’utilisation de l'adresse individuelle du serveur ===
L'option d'utilisation de l'adresse individuelle du serveur (Server Unicast Option), qu'émet un serveur, autorise le client DHCPv6 qui reçoit cette option à échanger avec le serveur en utilisant son adresse individuelle au lieu de l'adresse de diffusion sélective All_DHCP_Relay_Agents_and_Servers address.

La structure de cette 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_UNICAST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option de code d’état ===
L'option code d'état Status Code Option) renvoie une indication d'état relative au message DHCPv6 ou à l'option dans laquelle cette option apparaît. L'omission du code d'état dans un message ou dans une option où son utilisation est possible signifie succès (success).

La structure de cette 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_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. status-message .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L'annexe 2 présente les valeurs des différents codes d'état.

=== Option de Validation rapide ===
L'option de validation rapide (Rapid Commit Option) indique l'utilisation d'un échange à deux messages pour l'allocation d'adresses ipv6. Le principe de cette allocation est le suivant :

Un client, prêt à utiliser la validation rapide peut inclure cette option dans son message SOLICIT.

Un serveur doit inclure cete option le message REPLY qui répond au SOLICIT du client transportant l'option de validation rapide.

La structure de cette 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_RAPID_COMMIT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option classe d'utilisateur ===
L'option classe d'utilisateur (User Class Option)identifie un type ou une classe d'utilisateurs ou d'applications qu'ils représentent. La partie données de cette option contient plusieurs champs non interprétés (Opaque) par DHCPV6. Ces champs représentent la classe d'utilisateur à laquelle appartient le client.

Un serveur choisit les informations de configuration du client en fonction de la classe identifiée par l'option.

La structure de cette option est la suivante :

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_USER_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. user-class-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

La structure de la partie données de cette option peut apparaître plusieurs fois. Elle est la suivante :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

=== Option de classe de constructeur ===
L'option de classe de constructeur (Vendor Class Option)identifie le constructeur du matériel qui supporte le client DHCPv6. Le numéro d'entreprise identifie le constructeur.

La structure de cette option est la suivante :

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_VENDOR_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-class-data .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Les paramètres définissant la classe du constructeur se suivent les uns les autres dans le champ de données de classe de constructeur. Chaque paramètre est codé en format LV. DHCPv6 n'interprète pas la valeur (opaque) de ces paramètres.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

=== Option d'information spécifique d'un constructeur ===
L'option d'information spécifique d'un constructeur (Vendor-specific Information Option) permet que les clients et serveurs DHCPv6 échangent des informations spécifiques d'un constructeur. Le numéro d'entreprise identifie le constructeur.

La structure de cette option est la suivante :

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_VENDOR_OPTS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

La spécification des données échangées dépend du constructeur. Chacune de ces options de données est codée en format TLV. Le constructeur définit leur code. Plusieurs options de données peuvent se succéder dans le champ de données de l'optiond'information spécifique d'un constructeur.

La structure de l'option de donnée spécifique d'un constructeur est la suivante :

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| opt-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Option d'identification d'interface ===
L'option d'identification d'interface (Interface-Id Option)identifie sur un relais, l'interface de réception du message d'un client.

Un relais qui reçoit un message incluant une option d'identification d'interface relaie le message reçu sur l'interface identifiée dans l'option.

Les serveurs qui reçoivent cette option dans un message RELAY-FORWARD doivent la recopier dans leur message RELAY-REPLY. cette option es spécifique des messages RELAY-FORWARD et RELAY-REPLY. Ils peuvent également utiliser cete information pour appliquer une politique d'allocation basée sur la correspondance exacte de la valeur de cette option.

La structure de cette 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_INTERFACE_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. interface-id .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=== Option de message de reconfiguration ===
L'option de message de reconfiguration (Reconfigure Message Option)présente dans un message de reconfiguration issue d'un serveur indique au client s'il doit répondre à l'aide d'un message RENEW ou INFORMATION-REQUEST.Cette option est spécifique du message de reconfiguration.

La structure de cette 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_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |
+-+-+-+-+-+-+-+-+
=== Option d'acceptation de reconfiguration ===
L'option d'acceptation de reconfiguration (Reconfigure Accept Option) annonce au serveur que le client accepte les messages de reconfiguration.

Un serveur utilise cette option pour dire au client s'il doit ou non accepter les messages de reconfiguration. L'absence de cette option indique le refux d'accepter des messages de reconfiguration. La présence de cette option indique au client s'il doit ou non accepter les messsages de reconfiguration.

La structure de cette 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_RECONF_ACCEPT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=== Extension du protocole DHCPv6 : options spécifiques des relais ===
Dans certains cas les relais DHCPv6 connaissent des informations qui seraient utiles aux clients DHCPv6.

Le protocole DHCPv6 est étendu (RFC 6422) pour que les relais puissent inclure une option RSSO : RELAY-SUPPLIED OPTIONS OPTION dans les messages RELAY-FORW adressés au serveur DHCPv6.

L'option d'options spécifiques de relais (RELAY-SUPPLIED OPTIONS OPTION) dans les messages RELAY-FORW adressés au serveur DHCPv6 contient alors toutes les options correspondant à des paramètres que le relais souhaite porter à la connaissance du client. Cette possibilité n’est effective que pour des paramètres classés RSOO.

Le serveur DHCPv6 qui reçoit un message RELAY-FORW contenant une option RSSO enregistre les option classées RSOO fournies par le relais DHCPv6. Il peut ensuite transmettre ces informations aux clients en ajoutant les options de classe RSOO qu’il accepte de transmette au client.

Notez que le relais transmet ces paramètres spécifiques de relais au serveur. Le serveur décide ensuite de transmettre tout ou partie de ces informations au client, éventuellement en fonction de la politique définie par l'administrateur du réseau.

Un relais DHCPv6 n’a pas le droit de modifier le contenu d’une réponse (REPLY) destinée à un client.

La structure de cette 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_RSOO (66) | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options ...
+-+-+-+-+-+-+-+-+-+-+-+

Pour en savoir plus lisez le RFC 6422.

== Annexe 2. Codes d’état du protocole DHCPv6 ==
Cette annexe présente les codes d’état du protocole DHCPv6. Ils sont extraits du RFC 3315.
Name Code Description
---------- ---- -----------
Success 0 Success.
UnspecFail 1 Failure, reason unspecified; this
status code is sent by either a client
or a server to indicate a failure
not explicitly specified in this
document.
NoAddrsAvail 2 Server has no addresses available to assign to
the IA(s).
NoBinding 3 Client record (binding) unavailable.
NotOnLink 4 The prefix for the address is not appropriate for
the link to which the client is attached.
UseMulticast 5 Sent by a server to a client to force the
client to send messages to the server.
using the All_DHCPV6_Relay_Agents_and_Servers
address.