Revision as of 12:05, 15 May 2018 (view source) Panelli (Talk | contribs) (→‎ANNEXE 4 Activité 33 : Options pour la délégation de préfixes (RFC 3633, RFC 7550)) ← Older edit		Latest revision as of 15:28, 6 June 2019 (view source) Jlandru (Talk | contribs)
(4 intermediate revisions by 2 users not shown)
Line 5:		Line 5:
	__NOTOC__		__NOTOC__
		+	= ANNEXE 2 Activité 33 :  Faire correspondre adresse et nom de domaine =
−	= ANNEXE Activité 33 : Format DHCPv6 =	+	==Options DNS des RA ==
		+	===Option de liste de serveurs DNS récursifs (RDNSS)===
−	==Structure des options du protocole DHCPv6 ==	+	Cette option d’annonce de routeur contient l’adresse IPv6 d’un ou plusieurs serveurs DNS récursifs (cf. figure 10).
−	La structure générale des options est décrite ci-dessous. 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 nombre d'octets du champs de données de l’option. Le champ <tt>type</tt> de l'option en est exclu. Les données de l’option suivent. Dans certains cas, une option peut en contenir d’autres.	+	<center>
		+	[[Image:MOOC_dns_Fig1.png|400px|center|thumb|Figure 10 : Format d'une option RDNSS de la RFC 8106.]]
		+	</center>
−	La portée des options est définie par encapsulation. Certaines options s'appliquent globalement, d'autres sont spécifiques d'une association d'identités, d'autres encore sont spécifiques d'une adresse, dans une association d'identités.	+	# Le champ <tt>type</tt> a pour valeur 25.
		+	# Le champ <tt>longueur</tt> indique la longueur totale de l’option. Les champs <tt>type</tt> et <tt>longueur</tt> sont inclus (en multiples de 8 octets). Ce champ permet à l’utilisateur de calculer facilement le nombre d’adresses de serveurs DNS récursifs.
		+	# Le champ <tt>durée de vie</tt> indique la durée de vie maximum (en secondes) des adresses associées. Les valeurs de ce champ permettent que la machine sache si elle peut utiliser ces adresses, si leur durée de vie est infinie, si elle doit les rafraîchir ou si elle ne peut plus les utiliser.
		+	# Le champ <tt>addresses</tt> contient les adresses IPv6 des serveurs DNS récursifs, codées sur 128 bits.
−	La structure générale d'une option est la suivante :	+	===Option de liste de domaines recherchés (DNSSL)===
−	0                  1                  2                  3	+	L’option DNSSL contient un ou plusieurs suffixes de noms de domaines (cf. figure 11). Tous ces suffixes ont la même durée de vie. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.
−	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)                       |	+
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−		+	<center>
−	=== Option d'identification du client ===	+	[[Image:MOOC_dns_Fig2.png|400px|center|thumb|Figure 11 : Format d'une option DNSSL prévu par la RFC 8106.]]
−	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.	+	</center>
−	La structure de cette option est la suivante :	+	# Le champ <tt>type</tt> a pour valeur 31.
		+	# Le champ <tt>length</tt> indique la longueur totale de l’option, champs <tt>type</tt> et <tt>longueur</tt> inclus (en multiples de 8 octets). Le récepteur de cette option utilise ce champ pour calculer le nombre d’adresses de serveurs DNS récursifs.
		+	# Le champ <tt>lifetime</tt> indique la durée de vie maximum, en seconde, des suffixes associés. Les valeurs de ce champ permettent que la machine sache si elle peut utiliser ces adresses, si leur durée de vie est infinie, si elle doit les rafraîchir ou si elle ne peut plus les utiliser.
		+	# Le champ <tt>noms de domaines</tt> contient la liste des noms de domaines à utiliser pour effectuer les résolutions directes.
−	0                   1                  2                  3	+	Pour simplifier les choses, les noms de domaines ne sont pas compressés. Les bits excédentaires sont mis à 0.
−	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'') ===	+	== Options DNS du protocole DHCPv6==
−	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.	+	===Option serveur de nom récursif de DHCPv6===
−	La structure de cette option est la suivante :	+	L’option de serveur DNS récursif de DHCPv6 fournit, par ordre de préférence, une liste d’adresses IPv6 de serveurs DNS récursifs à une machine IPv6. La structure de l’option est la suivante (cf. figure 12) :
		+	# Le champ <tt>OPTION_DNS_SERVERS</tt> vaut le code 23.
		+	# Le champ <tt>longueur</tt> représente la longueur de l’option et elle est exprimée en multiple de 16 octets. La valeur du champ indique le nombre d’adresses de serveurs DNS récursifs contenu dans l’option.
		+	# Le champ <tt>DNS-recursive-name-server</tt> contient l’adresse IPv6 d’un serveur DNS récursif. Il peut apparaître plusieurs fois.
−	0                  1                  2                  3	+	<center>
−	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	+	[[Image:MOOC_dns_Fig3.png|400px|center|thumb|Figure 12 : format de l'option de DHCPv6 spécifiant la liste des serveurs DNS récursifs (RFC 8415).]]
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+	</center>
−	| OPTION_SERVERID                | option-len                  |	+
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−	.                                                              .	+
−	.                              DUID                            .	+
−	.                        (variable length)                     .	+
−	.                                                              .	+
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−	=== Option association d’identité pour les adresses non temporaires ===	+	===Option liste de suffixes de nom de domaine===
−	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.	+	Le RFC 8415 prévoit également une option spécifiant la liste des suffixes de noms de domaines (cf. figure 13).
−	La structure de cette option est la suivante :	+	<center>
		+	[[Image:MOOC_dns_Fig4.png|400px|center|thumb|Figure 13 : format de l'option de DHCPv6 spécifiant la liste des suffixes de nom de domaine (RFC 8415).]]
		+	</center>
−	0                  1                  2                  3	+	# Le code de l'option <tt>OPTION_DOMAIN_LIST</tt> vaut 24.
−	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	+	# Le champ <tt>Longueur</tt> donne la longueur de l’option en octets.
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+	# Le champ <tt>Searchlist</tt> contient la liste de suffixes de noms de domaines.
−	|            OPTION_IA_NA      |          option-len          |	+
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−	|                      IAID (4 octets)                          |	+
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−	|                              T1                              |	+
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−	|                              T2                              |	+
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−	|                                                              |	+
−	.                          IA_NA-options                        .	+
−	.                                                               .	+
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−	=== Option d'association d’identité pour les adresses temporaires ===	+	Les noms de domaines ne sont pas compressés par souci de simplification.
−	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 adresse temporaire associée 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.	+	Ces deux options ne peuvent apparaître que dans les messages DHCPv6 : SOLICIT, ADVERTISE, REQUEST, RENEW, REBIND, INFORMATION-REQUEST et REPLY.
−	La structure de cette option est la suivante :	+	==Mises en œuvre du service DNS ==
−	0                  1                  2                  3	+	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.
−	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 ===	+	===Logiciels DNS supportant IPv6 ===
−	L'option d'adresse d'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 :	+	De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive. Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Par ailleurs, certaines distributions logicielles comportent l'implémentation du client et du serveur. D'autres n'incluent que l'implémentation du client ou que celle du serveur. Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base de nommage (enregistrements AAAA et PTR) et au niveau du transport IPv6 des messages DNS. Néanmoins, certains ne supportent encore IPv6 qu'au niveau de la base de nommage.
−	0                  1                  2                  3	+	Par exemple, l'ISC : ''Internet Systems Consortium'' développe la distribution BIND9 (''Berkley Internet Name Domain''). Cette distribution représente la référence de fait dans le domaine. En effet, il s'agit d'une pile logicielle complète : 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.
−	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 ===	+	Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir : serveur DNS récursif ou officiel uniquement. Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité générique. Les performances sont reconnues par des tests comparant, d'un côté, NSD et BIND, et de l'autre, Unbound et BIND montrent la supériorité respective des premiers sur les seconds). La diversité générique concerne la diversité des plates-formes logicielles supportant ces serveurs DNS.
−	L'option de demande d'option (''Options Request Option'') identifie la liste des options demandées par le client ou fournies ou concernées pour le serveur.	+
−	La structure de cette option est la suivante :	+	===Principe de configuration d’un serveur DNS ===
−	0                  1                  2                  3	+	Cette partie présente le principe de configuration d’un service DNS autonome. Elle précise également les modifications à effectuer pour relier ce service DNS au service de nommage de l’Internet. Pour configurer un service de nommage, il faut successivement installer le paquetage du serveur de nommage sur les machines "serveur", configurer un serveur DNS primaire, configurer au moins un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.
−	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) ==	+	La configuration du serveur DNS primaire comprend la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse. Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service. Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.
−	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 configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou des serveurs primaires qui fournissent les fichiers de zone. L’outil ''named-checkconf'' vérifie les fichiers de configuration du serveurs DNS secondaire. Notez qu'un serveur DNS secondaire peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS secondaire déjà synchronisé.
−	La structure de cette option est la suivante :	+	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.
−	0                  1                  2                  3	+	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.
−	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) ===	+	Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un client. La vérification se fait à l’aide des outils ''dig'' ou ''host'', utilisables en ligne de commande. Ces outils utilisent, par défaut, les informations contenues dans le fichier ''resolv.conf''. Notez que l’outil ''nslookup'' n’est plus maintenu. Son utilisation est désormais déconseillée. Nous ne présentons donc pas ici son utilisation.
−	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.	+	===Définition des fichiers de zone===
−	La structure de cette option est la suivante :	+	Les fichiers de zone contiennent principalement des enregistrements de ressources (''RR resource record''). Notez que les recherches ignorent la casse des caractères. Cependant, le DNS conserve la casse des caractères. Les commentaires commencent avec un « ; », et se terminent à la fin de la ligne. Les fichiers de zones sont plus faciles à lire s’ils sont documentés. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressources doivent commencer dans la première colonne d’une ligne.
−	0                  1                  2                  3	+	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.
−	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é" ===	+	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.
−	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 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 <tt>127/24</tt>, ni pour <tt>::1/128</tt>. Chaque serveur doit donc en être responsable.
−	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).	+	Le fichier de configuration du serveur de nommage, ''named.conf'', relie les domaines dont le serveur a la responsabilité administrative à leur fichier de zone respectif.
−	La structure de cette option est la suivante :	+	Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur associer une durée de vie. Pour obtenir les adresses des serveurs racine, établissez une session ftp anonyme avec la machine ''ftp.rs.internic.net'' et rapatriez le fichier ''db.cache'' du répertoire ''domain''. Ce fichier change de temps en temps. Il est donc nécessaire, périodiquement, d’en rapatrier localement une version à jour.
−	0                  1                  2                  3	+	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''.
−	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 ===	+	===Types d’enregistrement de ressource DNS===
−	L'option d'authentification (Authentication 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 Authentication Code'') qui authentifie le message et, bien entendu, la valeur du condensé (128 bits, par exemple).	+	Les principaux enregistrements de ressources du DNS sont de deux types : ceux relatifs à la zone et ceux relatifs aux machines.
−	Rappel : le principe de l'authentification consiste à calculer un condensé (ou empreinte, ou ''hash'') 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 identiques, l'information est acceptable. Sinon, elle est rejetée.	+	Les enregistrements relatifs à la zone sont : SOA, NS et MX.
−	La sécurisation des échanges DHCPv6 entre serveurs et relais adjacents utilise IPsec.	+	* L'enregistrement de ressource SOA (''Start Of Authority'') 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.
−	La structure de cette option est la suivante :	+	* L'enregistrement de ressource ''NS (Name Server)'' désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée. Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.
		+	* L'enregistrement de ressource ''MX (Mail eXchanger)'' désigne un agent de transfert ou un serveur de courrier officiel pour un domaine donné.
−	0                  1                  2                  3	+	Les principaux enregistrements relatifs aux machines de la zone sont : A, AAAA, PTR et CNAME.
−	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'enregistrement de ressource ''A'' définit une correspondance nom-adresse IPv4.
−	L'option d'utilisation de l'adresse individuelle du serveur (''Server Unicast Option'') qu'envoie 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.	+	* L'enregistrement de ressource ''AAAA'' définit une correspondance nom-adresse IPv6.
		+	* L'enregistrement de ressource ''PTR'' définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.<br/>
		+	* L'enregistrement de ressource ''CNAME'' définit une corespondance entre le nom canonique d'une ressource (A ou AAAA) et un nom secondaire surnom (alias) d’une machine.
−	La structure de cette option est la suivante :	+	===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 mise en oeuvre de référence en matière de DNS.
−	0                  1                  2                  3	+	===Réseau virtualisé utilisé pour générer ces exemples ===
−	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 ===	+	Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS (cf. figure 14). La machine serveur '''s-13-v6''' supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 "à état" sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6). Le relais '''r-13-v6''' supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration "à état" en présence d’un relais DHCPv6. Le client '''c-13-v6''' est doté de deux interfaces de réseau. La première est connectée soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration "sans état".
−	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".	+
−	La structure de cette option est la suivante :	+	<center>
		+	[[Image:MOOC_dns_figBJ-17.png|666px|thumb|center|Figure 14 : Réseau virtualisé pour générer ces exemples.]]
		+	</center>
−	0                  1                  2                  3	+	La configuration DNS proposée correspond à un domaine DNS autonome où le serveur DNS primaire fait également fonction de serveur DNS racine.
−	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.	+	====Fichier de configuration d'un serveur BIND9 ====
−	=== Option de Validation rapide  ===	+	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.
−	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 :	+	<!--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.
−	(1) Un client, prêt à utiliser la validation rapide peut inclure cette option dans son message SOLICIT.	+	====Exemple de contenu du fichier ''/etc/bind9/named.conf''====
−	(2) Un serveur doit inclure cette option dans le message REPLY qui répond au SOLICIT du client transportant l'option de validation rapide.	+	// 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";
−	La structure de cette option est la suivante :	+	====Configuration du fonctionnement du serveur====
−	0                  1                  2                  3	+	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.
−	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 ===	+	====Contenu du fichier ''named.conf.options''====
−	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.	+	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"; };
		+	};
−	La structure de cette option est la suivante :	+	L'option ''listen-on'' peut avoir plusieurs valeurs possibles. Avec la valeur ''any'', le serveur écoute sur toutes les adresses IPv4 opérationnelles.
		+	Si une liste d'adresses IPv4 est spécifiée, le serveur écoutera uniquement les requêtes et réponses reçues sur chacune des interfaces configurées avec une de ces adresses. Si la valeur ''none'' est spécifiée, cela signifie que le serveur ne supporte pas IPv4.
−	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	+	Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option ''listen-on-v6''. Si elle vaut ''any'' le serveur écoute sur toutes les adresses IPv6 opérationnelles. Si une liste d'adresses IPv6 est spécifiée, le serveur écoutera uniquement les requêtes et réponses reçues sur chacune des interfaces configurées avec une de ces adresses. La valeur par défaut est ''none'', ce qui signifie que le serveur ne supporte pas IPv6 (valeur par défaut).
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−	|        OPTION_USER_CLASS    |        option-len            |	+	====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.
−	.                        user-class-data                      .	+
−	.                                                               .	+	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";
		+	};
−	La structure de la partie "données" de cette option peut apparaître plusieurs fois. Elle est la suivante :	+	// 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) ====
−	|      user-class-len          |          opaque-data        |	+
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+	+
−	=== Option de classe de constructeur ===	+	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.
−	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 :	+	$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.
−	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	+	===Fichier de zone DNS inverse en IPv6 ===
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−	|      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.	+	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''====
−	|        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 :	+	$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.
−	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	+	====Fichier ''db.132.tpt.example.com.rev''====
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+
−	|    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'option d'information spécifique d'un constructeur.	+	$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.
−	La structure de l'option de donnée spécifique d'un constructeur est la suivante :	+	====Fichier ''db.133.tpt.example.com.rev''====
−	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	+	$TTL 3h
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+	;
−	|            opt-code          |            option-len          |	+	@ IN SOA s-13-v6.tpt.example.com. nobody.localhost. (
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+	4 ; Numéro de série
−	.                                                               .	+	3600 ; rafraîchissement (1 heure)
−	.                         option-data                          .	+	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.
−	=== Option d'identification d'interface ===	+	===Clients du service de nommage===
−	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.	+	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.
−	Les serveurs qui reçoivent cette option dans un message RELAY-FORWARD doivent la recopier dans leur message RELAY-REPLY. cette option est spécifique des messages RELAY-FORWARD et RELAY-REPLY. Ils peuvent également utiliser cette information pour appliquer une politique d'allocation basée sur la correspondance exacte de la valeur de cette option.	+	====Exemple de fichier de configuration ''/etc/resolv.conf'' d’un serveur de noms====
−	La structure de cette option est la suivante :	+	domain tpt.example.com
		+	nameserver ::1
		+	nameserver 2001:db8:330f:a0d1::53
		+	nameserver 2001:db8:330f:a0d1::217
		+	search tpt.example.com
−	0                  1                  2                  3	+	====Exemple de fichier de configuration ''/etc/resolv.conf'' d’une machine====
−	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 ===	+	domain tpt.example.com
−	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.	+	nameserver 2001:db8:330f:a0d1::197
		+	nameserver 2001:db8:330f:a0d1::53
		+	nameserver 2001:db8:330f:a0d1::217
		+	search tpt.example.com
−	La structure de cette option est la suivante :	+	===Outils de vérification de la configuration DNS===
−	0                  1                  2                  3	+	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.
−	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 ===	+	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'''.
−	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 refus d'accepter des messages de reconfiguration. La présence de cette option indique au client s'il doit ou non accepter les messages de reconfiguration.
−	La structure de cette option est la suivante :	+	====Exemples d'interrogation d’un serveur DNS avec ''dig'' : résolution directe ====
−	0                  1                  2                  3	+	root@s-13-v6:/etc/bind# dig @2001:db8:330f:a0d1::53 s-13-v6.tpt.example.com -t aaaa
−	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	+
−	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+	; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @2001:db8:330f:a0d1::53 s-13-v6.tpt.example.com -t aaaa
−	|      OPTION_RECONF_ACCEPT    |                0             |	+	; (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
−	=== Extension du protocole DHCPv6 : options spécifiques des relais ===	+	====Exemple d’interrogation d’un serveur DNS avec la commande ''host'' : résolution directe====
−	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.	+	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
−	L'option d'options spécifiques de relais (RELAY-SUPPLIED OPTIONS OPTION) dans les messages RELAY-FORWARD 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.	+	====Exemple d’interrogation d’un serveur DNS avec la commande ''dig'' : résolution inverse====
−	Le serveur DHCPv6 qui reçoit un message RELAY-FORWARD contenant une option RSSO enregistre les options 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 transmettre au client.	+	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
−	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.	+	====Exemple d’interrogation d’un serveur DNS avec la commande ''host'' : résolution inverse====
−	Un relais DHCPv6 n’a pas le droit de modifier le contenu d’une réponse (REPLY) destinée à un client.	+	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.
−	La structure de cette option est la suivante :	+	==Recommandations opérationnelles pour l'intégration d'IPv6 ==
−	0                  1                  2                  3	+	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. C'est l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit. C'est une application critique parce qu’elle permet à toutes les autres applications TCP/IP classiques (web, mail, ftp...) de fonctionner.
−	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, consulter le RFC 6422.	+	L'intégration progressive d'IPv6 entraîne de nouveaux problèmes opérationnels liés au DNS. Ces problèmes sont dus à la fragmentation de l’espace de nommage. Il convient donc soit de les éviter, soit de trouver les solutions adéquates 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. Dans un article en ligne, l'auteur revient sur des cas problématiques du déploiement du DNS en IPv6 <ref>Evans R. (2015).  [https://medium.com/ Medium] [https://medium.com/@rvedotrc/on-dns-and-ipv6-9d0638091e67 On DNS and IPv6]</ref>.
−	==Codes d’état du protocole DHCPv6 ==	+	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 en 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.
−	Cette annexe présente les codes d’état du protocole DHCPv6. Ils sont extraits du RFC 3315.	+	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 forwarder'') 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.
−	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.	+
−	==Structure des identifiants DUID du protocole DHCPv6 ==	+	=== Deux impossibilités d’accéder au service de nommage et leurs remèdes ===
−	=== DUID construit à partir de l'adresse physique + horodate (DUID-LLT) ===	+	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.
−	<center>	+	====Premier scénario : client IPv4 et serveur IPv6 ====
−	[[Image:MOOC_Act33_Fig3.png|400px|center|thumb|Figure 1 : Format du DUID-LLT.]]	+
−	</center>	+
−		+
−	<tt>Msg-type</tt> : le champ <tt>type</tt> (2 octets) vaut 1.	+
−	<tt>Hardware type</tt> : deux octets contiennent le type de réseau physique.	+	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. La recommandation est de faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci remédie à ce problème.
−	<tt>Time</tt> : l’horodate est codée sur 4 octets.	+	====Second scénario : client IPv6 et serveur IPv4 ====
−	<tt>Link-layer address</tt> : la longueur de l’adresse physique (adresse MAC) varie en fonction du type du réseau physique.	+	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. La recommandation est de 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.
−	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.	+	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''.
−		+
−	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) ===	+	===Taille limitée des messages DNS en UDP, extension EDNS.0 ===
−	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 figure 2 présente la structure de l'option.	+	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...).
−	<center>	+	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.
−	[[Image:MOOC_Act33_Fig4.png|400px|center|thumb|Figure 2 : Format du DUID-EN.]]	+
−	</center>	+
−		+
−	Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction et l’enregistre dans une mémoire non volatile de l’équipement.	+
−	=== DUID dérivé de l’adresse physique de l’équipement (DUID-LL) ===	+	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.
−	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 figure 3 présente la structure de l'option.	+	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''.
−	<center>	+	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.
−	[[Image:MOOC_Act33_Fig5.png|400px|center|thumb|Figure 3 : Format du DUID-LL.]]	+
−	</center>	+
−	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.	+	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 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 : [[https://www.iana.org/domains/root/files]].
−	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).	+	<!-- PUTODO-->
−	==Options pour la délégation de préfixes (RFC 3633, RFC 7550) ==	+	===Glue IPv6 ===
−	=== Structure de l'option d'association d'identités pour la délégation de préfixes (RFC 3633, RFC 7550) ===	+	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.
−	La figure 4 présente la structure de cette option.	+	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 "racine" (TLD).
−	<center>	+	<!-- PUTODO ici il ne s'agit pas des serveurs racines mais des serveurs qui gerent les TLD.-->
−	[[Image:MOOC_Act33_Fig11.png|400px|center|thumb|Figure 4 : Format de l'option d'association d'identités pour la délégation de préfixes.]]	+	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…
−	</center>	+
−	''OPTION_IA_PD'' : le champ <tt>type</tt> de cette option a pour valeur 25.	+	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. <!--PUTODO Pas certain d'avoir compris cette phrase -->
		+	L'IANA/ICANN a fini par se convaincre que la publication des adresses IPv6 des serveurs DNS "racine" 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 "racine" 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.
−	''Option-length'' : la longueur de l'option est la longueur, en nombre d'octets, de la valeur des options IA_PD options.	+	===Publication des enregistrements AAAA dans le DNS ===
−	''IAID'' : c'est l'identificateur d'association d'identités.	+	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.
−		+
−	''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 ===	+	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.
−	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 figure 5 présente la structure de cette option.	+
−	<center>	+	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.
−	[[Image:MOOC_Act33_Fig12_1.png|400px|center|thumb|Figure 5 : Format de l'option de préfixe d'associations d'identités pour la délégation de préfixe.]]	+
−	</center>	+	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 (adresse 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 domaines 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, c'est-à-dire qu'elle sera effectuée intégralement avant qu'une autre opération soit effectuée et tous les prérequis doivent au préalable être satisfaits pour que la mise à jour soit possible et qu'elle 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 serveur 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, 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 le délai de mise à jour des données de zone du serveur 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é.
−	<tt>Msg-type</tt> : le champ <tt>type</tt> de cette option vaut 26.	+	Les enregistrements de ressources 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.
−	<tt>Option-length</tt> : le champ <tt>longueur</tt> du champ <tt>option</tt> est la longueur en nombre d'octets du champ <tt>option</tt> de cette option.	+	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.
−	<tt>Preferred-lifetime, valid lifetime</tt> : les durées de vie préférée et totale sont celles du préfixe.	+	Le fichier de nommage direct, unique pour chaque zone, contient les correspondances "nom-adresse" IPv4 et IPv6 pour toutes les machines de la zone. Le 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.
−	<tt>Prefix-length</tt> : ce champ donne la longueur en bits du préfixe.	+	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''. ces commandes utilisent par défaut les informations du fichier ''resolv.conf''.
−	<tt>IPv6 prefix</tt> : la valeur du préfixe, codée sur 16 octets, donne la valeur du préfixe.	+	Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les administrateurs de réseaux doivent configurer au moins un serveur ''dual'' ou un relais ''DNS dual'' dans chaque zone.
−	<tt>IAprefix-options</tt> : liste les options relatives à ce préfixe.	+	Les mises à jour dynamiques du système de nommage ont été introduites pour que des services comme DHCP puissent 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.

---

Latest revision as of 15:28, 6 June 2019

ANNEXE 2 Activité 33 : Faire correspondre adresse et nom de domaine

Options DNS des RA

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

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

Figure 10 : Format d'une option RDNSS de la RFC 8106.

1. Le champ type a pour valeur 25.
2. Le champ longueur indique la longueur totale de l’option. Les champs type et longueur sont inclus (en multiples de 8 octets). Ce champ permet à l’utilisateur de calculer facilement le nombre d’adresses de serveurs DNS récursifs.
3. Le champ durée de vie indique la durée de vie maximum (en secondes) des adresses associées. Les valeurs de ce champ permettent que la machine sache si elle peut utiliser ces adresses, si leur durée de vie est infinie, si elle doit les rafraîchir ou si elle ne peut plus les utiliser.
4. Le champ addresses contient les adresses IPv6 des serveurs DNS récursifs, codées sur 128 bits.

Option de liste de domaines recherchés (DNSSL)

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

Figure 11 : Format d'une option DNSSL prévu par la RFC 8106.

1. Le champ type a pour valeur 31.
2. Le champ length 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.
3. Le champ lifetime 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.
4. Le champ noms de domaines 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.

Options DNS du protocole DHCPv6

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 (cf. figure 12) :

1. Le champ OPTION_DNS_SERVERS vaut le code 23.
2. Le champ longueur représente la longueur de l’option et elle est exprimée en multiple de 16 octets. La valeur du champ indique le nombre d’adresses de serveurs DNS récursifs contenu dans l’option.
3. Le champ DNS-recursive-name-server contient l’adresse IPv6 d’un serveur DNS récursif. Il peut apparaître plusieurs fois.

Figure 12 : format de l'option de DHCPv6 spécifiant la liste des serveurs DNS récursifs (RFC 8415).

Option liste de suffixes de nom de domaine

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

Figure 13 : format de l'option de DHCPv6 spécifiant la liste des suffixes de nom de domaine (RFC 8415).

1. Le code de l'option OPTION_DOMAIN_LIST vaut 24.
2. Le champ Longueur donne la longueur de l’option en octets.
3. Le champ Searchlist contient la liste de suffixes de noms de domaines.

Les noms de domaines ne sont pas compressés par souci de simplification. Ces deux options ne peuvent apparaître que dans les messages DHCPv6 : SOLICIT, ADVERTISE, REQUEST, RENEW, REBIND, INFORMATION-REQUEST et REPLY.

Mises en œuvre du service DNS

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

Logiciels DNS supportant IPv6

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

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

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

Principe de configuration d’un serveur DNS

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

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

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

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

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

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

Définition des fichiers de zone

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

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

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

Le 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 les domaines dont le serveur a la responsabilité administrative à leur fichier de zone respectif.

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

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

Types d’enregistrement de ressource DNS

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

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

• L'enregistrement de ressource SOA (Start Of Authority) 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.

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

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

• L'enregistrement de ressource A définit une correspondance nom-adresse IPv4.
• L'enregistrement de ressource AAAA définit une correspondance nom-adresse IPv6.
• L'enregistrement de ressource PTR définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.
  
• L'enregistrement de ressource CNAME définit une corespondance entre le nom canonique d'une ressource (A ou AAAA) et un nom secondaire 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 mise en oeuvre 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 (cf. figure 14). La machine serveur s-13-v6 supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 "à état" sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6). Le relais r-13-v6 supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration "à état" en présence d’un relais DHCPv6. Le client c-13-v6 est doté de deux interfaces de réseau. La première est connectée soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration "sans état".

Figure 14 : Réseau virtualisé pour générer ces exemples.

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

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. 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 plusieurs valeurs possibles. Avec la valeur any, le serveur écoute sur toutes les adresses IPv4 opérationnelles. Si une liste d'adresses IPv4 est spécifiée, le serveur écoutera uniquement les requêtes et réponses reçues sur chacune des interfaces configurées avec une de ces adresses. Si la valeur none est spécifiée, cela signifie que le serveur ne supporte pas IPv4.

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

Exemple de configuration locale du serveur de noms BIND9

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

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

Exemple de contenu du fichier named.conf.local

// 
// 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 2001:db8:330f:a0d1::53
nameserver 2001:db8:330f:a0d1::217
search tpt.example.com

Outils de vérification de la configuration DNS

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

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

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

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. C'est l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit. C'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. Ces problèmes sont dus à la fragmentation de l’espace de nommage. Il convient donc soit de les éviter, soit de trouver les solutions adéquates 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. Dans un article en ligne, l'auteur revient sur des cas problématiques du déploiement du DNS en IPv6 ^[1].

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 en 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 forwarder) 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. La recommandation est de 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. La recommandation est de 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 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 "racine" (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 par se convaincre que la publication des adresses IPv6 des serveurs DNS "racine" 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 "racine" 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 (adresse 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 domaines 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, c'est-à-dire qu'elle sera effectuée intégralement avant qu'une autre opération soit effectuée et tous les prérequis doivent au préalable être satisfaits pour que la mise à jour soit possible et qu'elle 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 serveur 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, 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 le délai de mise à jour des données de zone du serveur 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 ressources 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, unique pour chaque zone, contient les correspondances "nom-adresse" IPv4 et IPv6 pour toutes les machines de la zone. Le 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. ces 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éseaux 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 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.

1. ↑ Evans R. (2015). Medium On DNS and IPv6