Difference between revisions of "MOOC:Compagnon Act33-s7"

From Livre IPv6

Revision as of 21:38, 22 May 2019

ANNEXE 3 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.

Le champ type a pour valeur 25.
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.
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.
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.

Le champ type a pour valeur 31.
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.
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.
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) :

Le champ OPTION_DNS_SERVERS vaut le code 23.
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.
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 3315).

Option liste de suffixes de nom de domaine

Le RFC 3315 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 3315).

Le code de l'option OPTION_DOMAIN_LIST vaut 24.
Le champ Longueur donne la longueur de l’option en octets.
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.

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

Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act33-s7&oldid=15669"

@@ Line 5: / Line 5: @@
 __NOTOC__
-= Activité 33 : Contrôler la configuration réseau par DHCPv6 =
+= ANNEXE 3 Activité 33 :  Faire correspondre adresse et nom de domaine =
-== Introduction ==
+==Options DNS des RA ==
+===Option de liste de serveurs DNS récursifs (RDNSS)===
-L'auto-configuration "à état" utilise un serveur pour allouer des adresses IPv6 et/ou des paramètres de configuration à des noeuds IPv6. Elle réduit les efforts de configuration des noeuds IPv6, tout comme l'auto-configuration "sans état". Elle offre, à la différence de l'auto-configuration "sans état", une information de configuration plus riche et un meilleur contrôle de l'affectation des paramètres de configuration. Elle permet en outre la reconfiguration éventuelle des équipements du réseau.
+Cette option d’annonce de routeur contient l’adresse IPv6 d’un ou plusieurs serveurs DNS récursifs (cf. figure 10).
-Les deux techniques d'auto-configuration, "avec état" et "sans état", ne sont pas exclusives et peuvent coexister dans un même environnement. Un noeud peut, par exemple, obtenir son adresse "unicast globale" par auto-configuration "sans état" et obtenir les informations relatives au(x) serveur(s) de noms (DNS) par l'auto-configuration "à état".
+<center>
+[[Image:MOOC_dns_Fig1.png|400px|center|thumb|Figure 10 : Format d'une option RDNSS de la RFC 8106.]]
+</center>
-L'autoconfiguration "avec état" permet :
+# Le champ <tt>type</tt> a pour valeur 25.
-* d'assigner des des adresses IPv6 stables et prédicitibles à la demande de manière contrôlée,
+# 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.
-* de provisionner au préalable les adresses à assigner aux noeuds,
+# 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.
-* d'automatiser le mécanisme d'assignement,
+# Le champ <tt>addresses</tt> contient les adresses IPv6 des serveurs DNS récursifs, codées sur 128 bits.
-* de centraliser les configurations.
-Tout le mécanisme d'auto-configuration "à état" est bâti sur le modèle client-serveur. Il utilise le protocole DHCPv6 (''Dynamic Host Configuration Protocol for IPv6'').
+===Option de liste de domaines recherchés (DNSSL)===
-<!--
-Dans les deux cas, si le noeud est en double pile et s'il est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), il faut définir une politique d'arbitrage entre les deux listes de serveurs DNS obtenues quand  celles-ci sont incohérentes.
--->
-== Principe de fonctionnement du protocole DHCPv6 ==
+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.
-Le RFC 3315 définit le principe de fonctionnement du protocole DHCPv6. Ce document spécifie l'architecture de communication, les principes de fonctionnement de chaque entité et le format des messages échangés par ces entités.
+<center>
-La mise au point de ce protocole a cependant fait l'objet de nombreux débats au sein du groupe de travail de l'IETF. DHCP est un élément important du fonctionnement d'un réseau. En conséquence, la parution tardive d'un standard finalisé a entraîné un déploiement lent.
+[[Image:MOOC_dns_Fig2.png|400px|center|thumb|Figure 11 : Format d'une option DNSSL prévu par la RFC 8106.]]
+</center>
-=== Présentation générale du protocole DHCPv6 ===
+# Le champ <tt>type</tt> a pour valeur 31.
-Le protocole DHCPv6 est un protocole de niveau application. Il fonctionne conformément au modèle client-serveur. Il utilise une communication en mode "non connecté", sous forme d'échanges de type requêtes / réponses . Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (''Requestor'').
+# 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.
-Les clients sollicitent les serveurs pour obtenir des adresses IPv6 et/ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs . Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6.
+# 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.
-Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.
+# Le champ <tt>noms de domaines</tt> contient la liste des noms de domaines à utiliser pour effectuer les résolutions directes.
-===  Communication en DHCPv6 ===
+Pour simplifier les choses, les noms de domaines ne sont pas compressés. Les bits excédentaires sont mis à 0.
-DHCPv6 utilise le protocole de transport UDP. Les messages UDP sont encapsulés dans des datagrammes IPv6. Les numéros de ports d'écoute utilisés sont 546 pour le client et 547 pour les serveurs ou les relais.
-Lorsque le client et le serveur sont sur le même lien, le serveur reçoit la requête du client sur son port 547. Lorsque le client n’est pas sur le même lien que le serveur, un relais reçoit la demande du client sur son port 547. Le relais réexpédie ensuite ce message vers le port 547 du relais suivant ou du serveur.
+== Options DNS du protocole DHCPv6==
+===Option serveur de nom récursif de DHCPv6===
-Le serveur DHCPv6 envoie ses réponses depuis son port 547. Il les envoie vers le port 546 du client si la remise directe est possible. Sinon, le serveur envoie sa réponse au premier relais du chemin de retour, sur le port 547.
+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.
-En fonction des indications du serveur DHCPv6, les communications peuvent, au niveau IPv6, se faire en point à point ou en multidiffusion pour la découverte des serveurs DHCPv6. IPv6 s'appuie ensuite sur les fonctions de diffusion, générale ou sélective, du réseau physique sous-jacent pour assurer le transport effectif des messages vers leur destination. Lorsque le réseau n'est pas diffusant, il fait, par exemple, appel à un serveur de diffusion.
+# 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.
-=== Les entités du protocole ===
+<center>
+[[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 3315).]]
-Le protocole DHCPv6 utilise quatre entités pour fonctionner : le client, le serveur, le relais et l'interrogateur. L’utilisation de la quatrième entité, l'interrogateur, est facultative.
+</center>
-* Le serveur DHCPv6 centralise les paramètres de configuration des équipements du réseau.
-* Le client DHCPv6 est une machine candidate à une connectivité globale IPv6. Il demande des informations de configuration du réseau à un serveur DHCPv6 pour activer cette connectivité. Il est en relation directe (c'est-à-dire qu'il est sur le même lien), soit avec un relais DHCPv6, soit avec le serveur DHCPv6. Il émet des messages DHCPv6 au serveur DHCPv6.
-* Les relais sont transparents,le client ignore l'existence des relais DHCPv6 et a l'impression de communiquer directement avec le serveur DHCPv6. Ce sont des équipements reliés à plusieurs liens. Ils interceptent le trafic des clients DHCPv6 pour l'acheminer vers les serveurs DHCPv6, lorsque ces derniers ne se trouvent pas sur le lien du client. Ils utilisent pour cela des options spécifiques des relais. ''Notez que ni les relais, ni le serveur ne modifient les messages du client. Les relais se contentent de les encapsuler dans une option de message de relais avant de les relayer vers le serveur.''
-* Les interrogateurs (Requestors) [RFC 5007] sont des entités spécifiques. Les administrateurs les utilisent pour demander à un serveur DHCPv6 des informations relatives aux clients. Un administrateur peut ainsi obtenir des informations relatives au bail d’un client ou à la machine qui utilise une adresse à un instant donné, ou encore pour connaître les adresses allouées à un client donné. Nous ne détaillerons pas ici leur utilisation.
-=== Gestion centralisée des ressources allouées ===
-Le client, dans la configuration DHCPv6 "sans état" (''stateless''), a configuré ses adresses IPv6, soit de façon manuelle (fichier interface, intervention de l’administrateur), soit à partir d’informations extraites d’annonces de routeurs (auto-configuration "sans état"). Il a alors besoin, pour communiquer, d'informations supplémentaires telles que l'adresse IPv6 du serveur DNS.
-Lorsque le serveur DHCPv6 transmet des informations statiques, ces dernières ne nécessitent pas de conserver un état. Elles ne font donc pas l’objet d’un enregistrement dans le fichier des baux du serveur DHCPv6.
-Le serveur DHCPv6, dans la configuration "avec état" (''stateful''), alloue une ou plusieurs adresses IPv6 au client. Ces adresses font l’objet d’un contrat de location temporaire : un bail. Il consigne alors ce contrat de location dans un registre spécial enregistré dans une mémoire non volatile : le fichier des baux (''lease file''). Pour cette raison, ce type de configuration est dit "avec état".
-==Principe de l’allocation d’adresse IPv6 à un client en l’absence de relais ==
-Un client DHCPv6 utilise le message DHCPv6 SOLICIT pour découvrir les serveurs configurés pour lui fournir des adresses IPv6 ou des paramètres de configuration du réseau. Comme ''a priori'' le client ignore l'adresse IPv6 du serveur, le client DHCPv6 envoie toujours ce message à l’adresse multicast <tt>FF02::1:2</tt> qui identifie le groupe des serveurs et relais DHCPv6 (''ALL_DHCP_Relay_Agents_And_Servers'').
+===Option liste de suffixes de nom de domaine===
-Les serveurs capables d’allouer des adresses au client répondent avec un message DHCPv6 ADVERTISE. Ils font une offre au client DHCPv6.
+Le RFC 3315 prévoit également une option spécifiant la liste des suffixes de noms de domaines (cf. figure 13).
-Si plusieurs serveurs DHCPV6 sont disponibles, le client ne collecte leurs réponses que pendant un certain temps. Il sélectionne ensuite l'offre qui satisfait le mieux ses besoins. Il émet alors un message REQUEST destiné au serveur choisi. Il envoie ce message à l’adresse de diffusion sélective ''ALL_DHCP_Relay_Agents_And_Servers''.
-Tous les serveurs qui ont répondu à la demande du client savent ainsi si leur offre a été retenue ou non. Le serveur dont l'offre à été retenue, et lui seul, retourne un message REPLY au client.  La figure 1 résume les messages DHCPv6 échangés dans ce cas.
 <center>
-[[Image:MOOC_Act33_Fig6.png|400px|center|thumb|Figure 1 : Dialogue entre client et serveur DHCPv6 présents sur le même lien physique.]]
+[[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 3315).]]
 </center>
-=== Recherche des serveurs DHCPv6 par le client : fonctionnement de la pile de communication ===
-Le client DHCPv6 demande au serveur une adresse IPv6 et un certain nombre de paramètres de configuration du réseau. Il fabrique donc un message DHCPv6 SOLICIT. Il émet ensuite ce message DHCPv6 SOLICIT pour découvrir les serveurs DHCPv6 disponibles.
+# Le code de l'option <tt>OPTION_DOMAIN_LIST</tt> vaut 24.
+# 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.
-Il s’adresse localement au protocole UDP sur le port local du client DHCPv6 (546) pour expédier ce message vers le port UDP destination du serveur (547). Comme, à ce stade, le client DHCPv6 ignore l’adresse IPv6 du serveur, il fournit à UDP l’adresse IPv6 de multicast réservée au protocole DHCPv6 comme adresse IPv6 de destination.
+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.
-UDP ne gère pas les adresses IPv6. Il transmet donc simplement l’adresse IPv6 de destination du message UDP à la couche IPv6.
+==Mises en œuvre du service DNS ==
-IPv6 fabrique l’en-tête du datagramme qui transporte le message DHCPv6 encapsulé dans UDP. Si notre client n’a qu’une interface, celle-ci est associée à la route par défaut. Sinon, le client envoie le message depuis l'interface de réseau associée à la route par défaut. L'adresse IPv6 "source" utilisée dans le datagramme IPv6 est l'adresse locale au lien de cette interface.
+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.
-Notez que l'administrateur du réseau définit l'interface de réseau à utiliser par défaut. Il peut effectuer cette configuration au niveau d'une image disque ou encore au niveau d'un fichier de configuration du client DHCPv6.
+===Logiciels DNS supportant IPv6 ===
-L’adresse de destination est une adresse de diffusion sélective. Elle n’est associée à aucune route spécifique. Le trafic destiné à ce groupe emprunte la route par défaut. L’adresse IPv6 "source" utilisée ici est donc l’adresse locale au lien de cette interface.
+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.
-IPv6 demande ensuite à Ethernet d’expédier ce datagramme. L’adresse IPv6 de diffusion sélective de destination est ensuite associée à l’adresse Ethernet de diffusion sélective spécifique d’IPv6, ''(selon le mécanisme d'association d'une adresse IPv6 de multicast à une adresse MAC de multicast, tel qu'il est présenté dans l'activité 15 de la séquence 1)''. Ceci permet d’utiliser, au niveau d'Ethernet, la diffusion sélective et de ne pas recourir, sur le lien, à la diffusion générale ; ce qui dérangerait un nombre potentiellement considérable de machines sur un réseau IPv6.
+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.
-== Principe de l’allocation d’adresse IPv6 à un client en présence d’un relais DHCPv6 ==
+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.
-Lorsque le client se trouve sur un lien différent de celui du serveur DHCPv6, ce dernier ignore sur quel lien se trouve le client. Il ne peut alors allouer des adresses correspondant aux liens du client qu'à condition de pouvoir identifier ces liens, et donc d'identifier le (ou les) préfixe(s) à y utiliser.
+===Principe de configuration d’un serveur DNS ===
-Le routeur intermédiaire, entre le client et le serveur DHCPv6, doit supporter une fonction relais DHCPv6. Comme DHCPv6 est un nouveau protocole spécifique d’IPv6, il n’a pas de contrainte de compatibilité ascendante. C’est pourquoi le fonctionnement des relais DHCPv6 est différent de celui des relais DHCPv4.
+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.
-L'activation de la fonction relais DHCPv6 sur le routeur le transforme en relais DHCPv6. Nous ferons un abus de langage en nommant ce routeur "relais DHCPv6" ''(nous l'avions déjà fait, mais sans le dire...)''. Notez que, pour un routeur Linux, par exemple, il suffit de configurer un processus relais DHCPv6 et d'activer ce processus pour que le relais soit opérationnel.
+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.
-Un relais DHCPv6 qui reçoit un message DHCPv6 d’un client l'encapsule dans un message DHCPv6 RELAY-FORWARD. Le message du client est inclus dans l'option "message relayé" du message RELAY-FORWARD que le relais envoie ensuite au serveur DHCPV6, soit en utilisant l’adresse de diffusion sélective réservée, et dans ce cas aucune configuration n'est nécessaire, soit en utilisant l’adresse individuelle (unicast) du serveur DHCPv6. L'administrateur du réseau doit, bien entendu dans ce cas, adapter la configuration du serveur et des relais en fonction du type d’adresse, individuelle ou diffusion sélective, utilisé.
+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é.
-Lorsque le message DHCPv6 d’un client doit traverser plusieurs relais DHCPv6, chaque relais encapsule le message RELAY-FORWARD reçu du relais précédent dans l'option "message relayé" de son propre message RELAY-FORWARD.
+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.
-Chaque relais traversé identifie (adresse globale ou locale au lien) dans son message RELAY-FORWARD, l’interface sur laquelle il a reçu le message du client ou du relais précédent et l’adresse locale au lien de l’interface par laquelle il réexpédie son message RELAY-FORWARD au serveur ou au relais suivant.
+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.
-Notez que le message du client est recopié dans l'option "message relayé" du message RELAY-FORWARD du premier relais DHCPv6 traversé. Si le message traverse plusieurs relais, l'option "message relayé" du relais courant contient le message RELAY-FORWARD du relais précédent.
+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.
-Lorsque le serveur DHCPv6 reçoit le message RELAY-FORWARD du dernier relais DHCPv6, l'en-tête de ce message contient l'adresse IPv6 du dernier relais. Il saura donc où envoyer son message RELAY-REPLY.
+===Définition des fichiers de zone===
-Chaque relais intermédiaire procède de la sorte en extrayant le message RELAY-REPLY du relais précédent de l’option "message relayé" du message RELAY-REPLY reçu.
+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.
-Le chemin inverse n’est par conséquent pas difficile à construire. Le protocole DHCPv6 peut ainsi faire parvenir la réponse du serveur au client.
+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.
-<center>
+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.
-[[Image:MOOC_Act33_Fig7.png|400px|center|thumb|Figure 2 : Dialogue entre client et serveur DHCPv6 non présents sur le même lien physique.]]
-</center>
-Après la phase d'acquisition de l'adresse IPv6, le client DHCPv6 vérifie que l'adresse IPv6 allouée n'est pas déjà en service (DAD : détection d'adresse dupliquée). Il configure alors ses interfaces de réseau, et l'utilisateur qui travaille sur le client DHCPv6 peut accéder au réseau.
+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 processus DHCPv6 client devient alors inactif jusqu'à ce que l'utilisateur qui travaille sur le client DHCPv6 ferme sa session et arrête le client. Il se réactive alors pour libérer (''release'') l'adresse IPv6 allouée.
+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.
-== Libération de l'adresse IPv6 par un client DHCPv6 ==
+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.
-Le processus d'arrêt normal du client DHCPv6, par échange des messages RELEASE / REPLY inclut la libération de l'adresse IPv6 allouée par le serveur.
-La figure 3 ci-dessous présente la libération de l'adresse IPv6 en l'absence de relais :
+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''.
-<center>
-[[Image:MOOC_Act33_Fig9.png|400px|center|thumb|Figure 3 : Libération d'une adresse IPv6 obtenue directement d'un serveur DHCPv6.]]
-</center>
-La figure 4 ci-dessous présente la libération de l'adresse IPv6 en présence d'un relais :
+===Types d’enregistrement de ressource DNS===
-<center>
+Les principaux enregistrements de ressources du DNS sont de deux types : ceux relatifs à la zone et ceux relatifs aux machines.
-[[Image:MOOC_Act33_Fig8.png|400px|center|thumb|Figure 4 : Libération d'une adresse IPv6 obtenue via un relais DHCPv6. ]]
-</center>
-== Fonctions des messages du protocole DHCPv6 ==
+Les enregistrements relatifs à la zone sont : SOA, NS et MX.
-Cette partie introduit les messages du protocole DHCPv6. Ce protocole distingue deux types de messages : d’une part, les messages échangés entre client et serveur, et d’autre part, les messages échangés entre serveur et relais. Nous les présentons successivement dans cet ordre.
-En général, les messages échangés transportent des identificateurs de transactions et des associations d'identités. Les serveurs DHCPv6 utilisent les identificateurs de transactions pour associer leurs réponses aux demandes correspondantes des clients. L'identificateur de transaction change pour chaque transaction et est globalement unique pour une transaction donnée. Mais les messages associés à une transaction se distinguent notamment par le champ <tt>Type</tt> de l'en-tête DHCPv6.
+* 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.
-Les associations d'identités permettent aux serveurs et aux clients de s'identifier mutuellement. Elles identifient également les interfaces de réseau concernées par les demandes de paramètres de configuration du réseau des clients ou par les réponses des serveurs. Elles sont également transmises dans des options du protocole DHCPv6.
+* 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é.
-=== Messages échangés entre client et serveur ===
+Les principaux enregistrements relatifs aux machines de la zone sont : A, AAAA, PTR et CNAME.
-Un client utilise le message SOLICIT (champ <tt>Type</tt> = 1) pour localiser les serveurs configurés pour allouer des adresses et/ou des paramètres de configuration du réseau.
+* 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.<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.
-Un serveur configuré pour fournir des adresses ou des paramètres de configuration du réseau aux clients annonce sa disponibilité au client DHCPv6 à l'aide d'un message ADVERTISE (champ <tt>Type</tt> = 2).
+===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.
-Un client utilise ensuite le message REQUEST (champ <tt>Type</tt> = 3) pour demander des adresses et/ou des paramètres de configuration au serveur DHCPv6 choisi. Une option ''options demandées'' contient la liste des paramètres de configuration qu’il demande.
-Un serveur utilise le message REPLY (champ <tt>Type</tt> = 7) pour répondre à un message SOLICIT ou REQUEST reçu d’un client DCHPv6.
+===Réseau virtualisé utilisé pour générer ces exemples ===
-=== Messages de gestion des ressources allouées ===
+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".
-Un client utilise le message CONFIRM (champ <tt>Type</tt> = 4) pour indiquer au serveur qui lui a alloué adresses et paramètres de configuration du réseau et que ces paramètres sont adaptés au lien auquel il est raccordé.
+<center>
+[[Image:MOOC_dns_figBJ-17.png|666px|thumb|center|Figure 14 : Réseau virtualisé pour générer ces exemples.]]
+</center>
-Un client utilise le message RENEW (champ <tt>Type</tt> = 5) pour prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès du serveur qui les lui a alloués. Le client utilise ce message à la demande explicite du serveur.
+La configuration DNS proposée correspond à un domaine DNS autonome où le serveur DNS primaire fait également fonction de serveur DNS racine.
-Un client utilise le message REBIND (champ <tt>Type</tt> = 6) pour obtenir un bail de location des adresses et actualiser des paramètres de configuration auprès de tout serveur DHCPV6, si le serveur DHCPv6 auquel il s'est adressé pour renouveler le bail de ses adresses et ses paramètres de configuration du réseau ne répond pas à son message RENEW.
+====Fichier de configuration d'un serveur BIND9 ====
-Un serveur utilise le message REPLY (champ <tt>Type</tt> = 7) pour répondre à un message RENEW ou REBIND reçu d’un client.
+La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (nom – adresse), la configuration des fichiers de zone pour la résolution inverse (adresse – nom), et la mise au point du service.
+<!--Il y a, en IPv6, un fichier de résolution inverse par lien dans la zone.-->
+Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents. Le fichier de configuration du serveur de nom BIND 9 est, par exemple sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.
-Un client utilise le message RELEASE (champ <tt>Type</tt> = 8) pour indiquer au serveur DHCPv6 qu'il libère des adresses IPv6.
+====Exemple de contenu du fichier ''/etc/bind9/named.conf''====
-Un client utilise le message DECLINE (champ <tt>Type</tt> = 9) pour signaler au serveur qu’une ou des adresses allouées par le serveur sont déjà utilisées sur le lien du client. La DAD (détection d'adresses dupliquées) d'IPv6 peut, par exemple, fournir cette information.
+ // 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";
-Notez que la détection d’adresses dupliquées incombe toujours au client DHCPv6. En effet, le serveur DHCPv6 ne peut effectuer la DAD que lorsqu’il se trouve sur le même réseau que son client, ce qui n’est pas toujours le cas. Or, la DAD n’est possible que sur un lien auquel on est connecté.
+====Configuration du fonctionnement du serveur====
-Un serveur utilise le message RECONFIGURE (champ <tt>Type</tt> = 10) pour signaler au client qu'il a de nouveaux paramètres de configuration du réseau ou les a actualisés. Ce message précise en particulier si le client doit utiliser le message RENEW ou REBIND.
+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.
-Un client utilise le message INFORMATION-REQUEST (champ <tt>Type</tt> = 11) pour demander au serveur des paramètres de configuration du réseau, sans demander d’adresse.
+====Contenu du fichier ''named.conf.options''====
-=== Messages échangés entre relais et serveur===
+ 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 {
+:db8:330f:a0d1::/64;
+:db8:330f:a0d2::/64;
+: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"; };
+ 	 };
-Un relais DHCPv6 utilise le message RELAY-FORWARD (champ <tt>Type</tt> = 12) pour relayer des messages DHCPv6 vers un serveur DHCPv6. Le message relayé est soit le message DHCPv6 du client, soit le message RELAY-FORWARD du relais précédent (sur le chemin reliant le client au serveur DHCPv6). Un relais DHCPv6 ne modifie jamais le message d'un client.
+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.
-Le message du client DHCPv6 est relayé, sans être modifié, dans une option ''message relayé'' du message RELAY-FORWARD du premier relais rencontré sur le chemin reliant le client au serveur DHCPv6.
+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).
-Un serveur DHCPv6 utilise le message RELAY-REPLY (champ <tt>Type</tt> = 13) pour envoyer un message à un client, via un relais.
+====Exemple de configuration locale du serveur de noms BIND9====
-Chaque relais qui reçoit un message RELAY-REPLY extrait le message contenu dans l'option "message relayé" et le réexpédie vers le client. Seul le contenu de l'option "message relayé" est donc transmis vers le client.
+Le 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.
-Le dernier relais extrait le message REPLY destiné au client et contenu dans l'option "message relayé" de ce message RELAY-REPLY pour le lui remettre. Ici encore, le message du client reste inchangé.
+Voici maintenant un extrait du fichier ''named.conf.local'' de notre serveur DNS autonome.
-=== Tableau récapitulatif des messages DHCPv6 ===
+====Exemple de contenu du fichier ''named.conf.local''====
-Le tableau ci-dessous résume le nom, le type, l'émetteur et la fonction des messages DHCPv6 échangés entre client et serveur.
-{|
+ //
-|+'''Message DHCPv6'''
+ // Do any local configuration here
-! Type || || Emetteur || Fonction
+ //
-|-style="background:silver"
+ // Consider adding the 1918 zones here, if they are not used in your
-| '''SOLICIT'''
+ // organization
-|| 1
+ //
-|| Client
+ include "/etc/bind/zones.rfc1918";
-|| Localiser les serveurs configurés pour fournir des adresses ou des paramètres de configuration .
+ //zones primaires
-|-
+ //
-| '''ADVERTISE'''
+ //
-|| 2
+ //
-|| Serveur
+ // Déclaration de la zone tpt.example.com
-|| Annoncer la disponibilité du serveur DHCPv6.
+ //
-|-style="background:silver"
+ //
-| '''REQUEST'''
+ zone "tpt.example.com" {
-|| 3
+ 	type master;
-|| Client
+ 	file "/etc/bind/db.tpt.example.com";
-|| Demander des adresses et/ou des paramètres de configuration au serveur choisi.
+ 	allow-transfer {
-|-
+:db8:330f:a0d1::197;
-| '''CONFIRM'''
+:db8:330f:a0d2::197;
-|| 4
+ 		};
-|| Client
+ 	};
-|| Indiquer au serveur qui a alloué adresses et paramètres de configuration que ces paramètres sont adaptés au lien auquel le client est raccordé.
+ //
-|-style="background:silver"
+ // Déclaration des zones inverses
-| '''RENEW'''
+ //
-|| 5
+ //
-|| Client
+ // 2001:db8:330f:a0d1::/64
-|| Prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès du serveur qui les a alloués.
+ //
-|-
+ zone "1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa." {
-| '''REBIND'''
+ 	type master;
-|| 6
+ 	file "/etc/bind/db.131.tpt.example.com.rev";
-|| Client
+ 	allow-transfer {
-|| Obtenir un bail de location des adresses et actualiser des paramètres de configuration auprès de tout serveur en cas de non réponse au message RENEW.
+:db8:330f:a0d1::197;
-|-style="background:silver"
+:db8:330f:a0d2::197;
-| '''REPLY'''
+ 		};
-|| 7
+ 	};
-|| Serveur
+ //
-|| Répondre à un message SOLICIT, REQUEST, REBIND, RELEASE reçu d'un client.
+ // 2001:db8:330f:a0d2::/64
-|-
+ //
-| '''RELEASE'''
+ zone "2.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa." {
-|| 8
+ 	type master;
-|| Client
+  	file "/etc/bind/db.132.tpt.example.com.rev";
-|| Indiquer au serveur que le client n'utilise plus des adresses IPv6.
+ 	allow-transfer {
-|-style="background:silver"
+:db8:330f:a0d1::197;
-| '''DECLINE'''
+:db8:330f:a0d2::197;
-|| 9
+ 		};
-|| Client
+ 	};
-|| Signaler au serveur qu'une ou des adresses allouées par le serveur sont déjà utilisées sur le lien du client.
+ //
-|-
+ // 2001:db8:330f:a0d3::/64
-| '''RECONFIGURE'''
+ //
-|| 10
+ zone "3.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa." {
-|| Serveur
+ 	type master;
-|| Signaler au client que le serveur a de nouveaux paramètres ou les a actualisés.
+ 	file "/etc/bind/db.132.tpt.example.com.rev";
-|-style="background:silver"
+ 	 allow-transfer {
-| '''INFORMATION-REQUEST'''
+:db8:330f:a0d1::197;
-|| 11
+:db8:330f:a0d2::197;
-|| Client
+ 		};
-|| Demander des paramètres de configuration au serveur, sans demander d'adresse.
+ 	};
-|-
+ //
-| '''RELAY-FORWARD'''
+ // Zones secondaires
-|| 12
+ //
-|| Relais
-|| Relayer des messages vers un serveur DHCPv6. Le message relayé (celui du client DHCPv6 ou du relais précédent ) est placé dans une option de ce message RELAY-FORW.
-|-style="background:silver"
-| '''RELAY-REPLY'''
-|| 13
-|| Serveur
-|| Envoyer, depuis un serveur, un message à un client via un relais . Le relais extrait le message destiné au client ou au relais suivant contenu dans l'option "message relayé" de ce message pour le lui remettre.
-|}
-=== Extension du protocole DHCPv6 [RFC 6422] ===
+====Contenu du fichier ''named.conf.default-zones''====
-Notez qu'un mécanisme d'option de relais spécifique permet qu'un relais DHCPv6 communique des paramètres de configuration susceptibles d'intéresser un client DHCPv6 et dont il a connaissance, au serveur DHCPv6.
-Le serveur DHCPv6 peut ensuite décider ou non, en fonction de la politique définie par l'administrateur du réseau, de communiquer au client tout ou partie des paramètres de configuration du réseau spécifiques issus du relais.
+ // 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";
+ };
-== Structure des messages DHCPv6 ==
+====Fichier de zone DNS pour la résolution directe (nom - adresse) ====
-Le document RFC 3315 décrit l'ensemble des éléments du protocole DHCPv6. A l'instar de nombreux protocoles de l'Internet, le protocole d'échange d'informations est découplé de l'information elle-même. La nature des informations échangées peut donc changer et évoluer rapidement, sans impacter les mécanismes de cet échange. Cette séparation assure la stabilité et l'extensibilité du protocole.
+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.
-La structure des unités de données du protocole reprend ce découpage : un en-tête de taille fixe pour les informations du protocole lui-même et une charge utile transportée dans des champs d'option pour les informations applicatives.
+ $TTL 3h
+ tpt.example.com. 	IN	SOA	s-13-v6.tpt.example.com.	 r-13-v6.tpt.example.com. (
+		; numéro de série
+		; refresh (1 heure)
+		; nouvel essai (15 minutes)
+ 		3600000		; expiration (5 semaines jours 16 heures)
+h)		; 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.
-Pour étendre le protocole, il suffit de définir de nouvelles options et de concevoir leur traitement, en émission et en réception. Les options utilisables par DHCPv6 sont référencées dans un registre maintenu par l'IANA<ref>IANA. Protocol Registries [http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml Dynamic Host Configuration Protocol for IPv6 (DHCPv6)]</ref>.
+===Fichier de zone DNS inverse en IPv6 ===
-Dans la terminologie DHCPv6, le terme message désigne une unité de données du protocole DHCPv6. Chaque type de message DHCPv6 (client-serveur ou relais-serveur) a un format d'en-tête identique. De ce point de vue, DHCPv6 reprend les principes de simplification du processus de développement du protocole qui ont guidé la conception du format du segment TCP : un seul format pour l'ensemble des fonctions de TCP.
-=== Structure des messages émis par les serveurs et clients DHCPv6 ===
+Voici les fichiers de zone pour la résolution DNS inverse correspondant au préfixe IPv6 d’un lien.
-La structure générale des messages échangés entre client et serveur DHCPv6 est la suivante : un champ <tt>type</tt> ''Type-msg'', un champ <tt>identificateur de transaction</tt> ''ID-transaction'', et une liste variable d’options, ''Option list'' (voir la figure 5).
-<center>
+====Fichier ''db.131.tpt.example.com.rev''====
-[[Image:MOOC_Act33_Fig1.png|400px|center|thumb|Figure 5 : Format des messages échangés entre clients et serveurs DHCPv6.]]
-</center>
-<tt>Type-msg</tt> : le champ <tt>type de message</tt> identifie la nature du message DHCPv6. Il est codé sur un octet.
-<tt>Id-transaction</tt> : l'identificateur de transaction identifie un échange (question/réponse). Il est spécifique aux messages participant à une transaction, et est globalement unique. Il permet d'associer les réponses aux requêtes correspondantes. En effet la couche transport UDP ne garantit pas le sequencement des réponses, lorsque plusieus requêtes successives ont été émises à destination d'un serveur. Il est codé sur 3 octets.
+ $TTL 3h
+ ;
+ @		IN	SOA	s-13-v6.tpt.example.com. root.s- 13-v6.tpt.example.com. (
+		; Numéro de série
+		; rafraîchissement (1 heure)
+		; Nouvelle tentative (15 minutes)
+ 		3600000		; Durée de vie maximale (5 semaines 6 jours et  16 heures)
+h )		; 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.
+.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0	IN	PTR	s-13-v6.tpt.example.com.
+.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0	IN	PTR	s-13-v6.tpt.example.com.
+.9.1.0.0.0.0.0.0.0.0.0.0.0.0.0	IN	PTR	r-13-v6.tpt.example.com.
-<tt>Option list</tt> : la liste des options du message est de taille variable. Elle correspond à une succession d'options rangées séquentiellement, selon la sémantique du message, et uniquement alignées sur des frontières d'octets. Il n'y a pas de bourrage entre deux options consécutives. Elles transportent, soit les adresses IPv6, soit les paramètres de configuration du réseau (hors adresse IPv6) nécessaires au fonctionnement du réseau.
+====Fichier ''db.132.tpt.example.com.rev''====
-Pour en savoir plus sur les options, reportez-vous à l’annexe 1 ''Options du protocole DHCPv6'' de cette activité.
+ $TTL 3h
+ ;
+ @		IN	SOA	s-13-v6.tpt.example.com. root.s-13-v6.tpt.example.com. (
+		; Numéro de série
+		; rafraîchissement (1 heure)
+		; Nouvelle tentative (15 minutes)
+ 		3600000		; Durée de vie maximale (5 semaines 6 jours
+ ;					et 16 heures)
+h )		; 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.
+.9.1.0.0.0.0.0.0.0.0.0.0.0.0.0	IN	PTR	r-13-v6.tpt.example.com.
-=== Structure des messages échangés entre relais et serveur DHCPv6 ===
+====Fichier ''db.133.tpt.example.com.rev''====
-La figure 6 présente la structure des messages échangés entre relais et serveur.
-<center>
+ $TTL 3h
-[[Image:MOOC_Act33_Fig2.png|400px|center|thumb|Figure 6 : Format des messages échangés entre relais et serveurs DHVPv6.]]
+ ;
-</center>
+ @		IN	SOA	s-13-v6.tpt.example.com. nobody.localhost. (
+		; Numéro de série
+		; rafraîchissement (1 heure)
+		; Nouvelle tentative (15 minutes)
+ 		3600000		; Durée de vie maximale (5 semaines 6 jours et  16 heures)
+h )		; 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.
+.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0	IN PTR	s-13-v6.tpt.example.com.
-Les messages utilisés pour la communication entre serveur et relais sont différents des messages utilisés pour la communication entre client et serveur. Un message RELAY-FORWARD transite d'un relais vers un serveur. Un message RELAY-REPLY transite du serveur vers le client.
+===Clients du service de nommage===
-<tt>Type-msg</tt> : le type du message identifie le type du message DHCPv6.
+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.
-<tt>Hop-count</tt> : le nombre de sauts identifie, soit le nombre de relais déjà traversés pour atteindre le serveur, soit le nombre de relais restant à traverser pour atteindre le client.
+====Exemple de fichier de configuration ''/etc/resolv.conf'' d’un serveur de noms====
-<!--
+ domain tpt.example.com
-<tt>Link-address</tt> : l'adresse locale au lien désigne l'interface du relais émettrice du message (RELAY-FORWARD) ou destinataire du message (RELAY-REPLY).
+ nameserver ::1
+ nameserver 2001:db8:330f:a0d1::53
+ nameserver 2001:db8:330f:a0d1::217
+ search tpt.example.com
-<tt>Peer-address</tt> : l'adresse du pair est une adresse globale ou locale au site. Elle identifie, pour chaque relais, l'interface du relais, côté client. Pour le dernier relais, dans le cas du transit d'un message du serveur vers le client, cette adresse identifie l'interface du relais derrière laquelle se trouve le client.
+====Exemple de fichier de configuration ''/etc/resolv.conf'' d’une machine====
--->
-<tt>Link-address</tt> : l'adresse de lien, est une adresse unicast (globale ou locale) qui sera utilisée par le serveur pour identifier le lien sur lequel est localisé le client. C'est l'adresse unicast (globale ou locale) du relais du coté du client.
-<tt>Peer-address</tt> : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le message à relayer a été reçu ''(elle est extraite de l'adresse source du paquet du message reçu)''. Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client, ''(elle sera utilisée comme adresse de destination du paquet contenant le message RELAY-REPLY)''.
+ 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
-Ainsi, même en présence de plusieurs relais DHCPv6, le serveur sait auquel des relais s'adresser pour répondre à un client donné. Chacun des relais, lorsqu'il faut en traverser plusieurs pour atteindre le client, sait à qui transmettre le message RELAY-REPLY reçu. Le champ <tt>Peer-address</tt> de ce message contient l'adresse locale au lien du relais suivant ou, pour le dernier relais, l'adresse locale au lien du client. Le dernier relais peut donc envoyer au client la réponse du serveur.
+===Outils de vérification de la configuration DNS===
-==== Message DHCPv6 RELAY-FORWARD ====
+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.
-<tt>Type-msg</tt> : le champ <tt>type</tt> de ce message vaut 12.
+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'''.
-<tt>Hop-count</tt> : le nombre de sauts indique le nombre de relais traversés par ce message pour atteindre le serveur.
-<!--
-<tt>Link-address</tt> : l’adresse locale au lien d’un message RELAY-FORWARD est une adresse globale ou une adresse locale au site que le serveur utilise pour identifier le lien où se trouve le client. C'est l'adresse du relais, du côté du client.
-<tt>Peer-address</tt> : l’adresse du pair est l’adresse IPv6 de l'interface depuis laquelle le relais a envoyé le message au serveur. C'est l'adresse du relais du côté du serveur.
+====Exemples d'interrogation d’un serveur DNS avec ''dig'' : résolution directe ====
--->
-<tt>Link-address</tt> : l'adresse de lien, est une adresse unicast (globale ou locale) qui sera utilisée par le serveur pour identifier le lien sur lequel est localisé le client. C'est l'adresse unicast (globale ou locale) du relais du coté du client.
+ 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
-<tt>Peer-address</tt> : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le message à relayer a été reçu ''(elle est extraite de l'adresse source du paquet du message reçu)''. Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client, ''(elle sera utilisée comme adresse de destination du paquet contenant le message RELAY-REPLY)''.
+====Exemple d’interrogation d’un serveur DNS avec la commande ''host'' : résolution directe====
-<tt>Option list</tt> : la liste d’options de ce message contient obligatoirement une option de message relayé (Relay Message Option) et éventuellement d’autres options ajoutées par le relais.
+ 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
-Notez qu'en aucun cas le relais ne modifie le message DHCPv6 du client.
+====Exemple d’interrogation d’un serveur DNS avec la commande ''dig'' : résolution inverse====
-==== Message DHCPv6 RELAY-REPLY ====
+ root@s-13-v6:/etc/bind# dig @::1 -x 2001:db8:330f:a0d1::217
-Le serveur envoie ce message au premier relais sur le chemin du retour vers le client demandeur.
+ ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @::1 -x 2001:db8:330f:a0d1::217
+ ; (1 server found)
-<tt>Type-msg</tt> : le champ <tt>type</tt> de ce message vaut 13.
+ ;; global options: +cmd
+ ;; Got answer:
-<tt>Hop-count</tt> : le nombre de sauts indique le nombre de relais que ce message traversera pour atteindre le client.
+ ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65205
+ ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 7
-<tt>Link-address</tt> et <tt>Peer-address</tt> : les adresses du lien et du pair sont recopiées à partir du message RELAY-FORWARD précédent.
+ ;; QUESTION SECTION:
-<tt>Option list</tt> : la liste d’options doit obligatoirement contenir une option de message relayé (''Relay Message option''). Cette option transporte la réponse du serveur DHCPv6 destinée au client DHCPv6.
+ ;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
-=== Types de DUID : DHCPv6 Unique IDentifier ===
+ ;; ANSWER SECTION:
+.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.
-Afin de connaître l'état des ressources gérées (représentées par les paramètres de configuration), le serveur DHCP gère une liste d'associations entre le paramètre attribué et le client. Comme l'adresse unicast du client est une ressource sous le contrôle du serveur, celle-ci ne peut pas être utilisée pour identifier un client. Le serveur référence donc le client par un identifiant unique à usage exclusif de DHCP : le DUID (''DHCP Unique Identifier'').
+ ;; AUTHORITY SECTION:
+.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.
+.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
-Chaque station génère son identifiant. Cet identifiant doit être permanent et avoir une grande durée de vie. Une station peut, par exemple, et à un instant donné, générer un DUID à partir de l'adresse MAC d'une de ses cartes réseau. Elle le conservera alors comme identifiant, même en cas de remplacement ultérieur de cette carte réseau.
+ ;; Query time: 0 msec
+ ;; SERVER: ::1#53(::1)
+ ;; WHEN: Tue Mar 17 11:31:56 2015
+ ;; MSG SIZE rcvd: 356
-Les clients utilisent les DUID pour identifier les serveurs quand ils en ont besoin ; par exemple, pour mémoriser l'identité du serveur qui leur a alloué des adresses IPv6 et/ou des paramètres de configuration du réseau.
+====Exemple d’interrogation d’un serveur DNS avec la commande ''host'' : résolution inverse====
-Le contenu des DUID n’est pas interprété, mais uniquement utilisé pour des comparaisons ou pour vérifier l'identité du correspondant. Le DUID concerne la machine (client ou serveur) et non une de ses interfaces.
-Le RFC 3315 définit 3 types d’identificateurs unique DHCPv6 (DUID). Les DUID peuvent, donc, être générés selon 3 méthodes, repérés par le champ  <tt>type de DUID</tt> dont les valeurs respectives sont :
+  root@r-13-v6:/var/bind# host -t aaaa s-13-v6
-* <tt>1</tt> : '''''DUID-LLT''''' ''(Link-Layer address plus Time)'' resultant de la combinaison d'une adresse physique et d'une horodate ;
+ s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d1::53
-* <tt>2</tt> : '''''DUID-EN''''' ''(Vendor-assigned unique ID based on Enterprise Number)'' dérivé d'un numéro de constructeur ou d'un numéro unique affecté par un constructeur ;
+ s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d1::217
-* <tt>3</tt> : '''''DUID-LL''''' ''(Link-Layer address)'' dérivé de l'adresse MAC d'une interface de réseau.
+ 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
+.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
+.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
+.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
+.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.
-Le type de DUID est codé sur 2 octets. Un nombre variable d’octets suit, et constitue l’identificateur. La longueur maximale d’un identificateur est 128 octets.
+==Recommandations opérationnelles pour l'intégration d'IPv6 ==
-Le DUID est lui-même une structure de données qui, selon le mode de construction, contient des types de valeurs différents ''(la structure détaillée des différents type de DUID est présentée en annexe 3 de cette sequence)''.
+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.
-=== Association d'identités ===
+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>.
-Une association d’identités IA (''Identity Association'') permet qu’un serveur ou un client identifie, groupe ou gère un ensemble d’adresses IPv6 associées. Chaque association se compose d’un identificateur d’association et des informations de configuration associées. Ces informations sont enregistrées dans des options de l'association.
+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 client associe au moins une association d’identités, IA, à chacune des interfaces de réseau pour laquelle il requiert une adresse IPv6.
+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.
-Cette IA reste affectée en permanence à l'interface. Elle simplifie le format des messages DHCPv6, la gestion de la durée de vie des adresses IPv6 ou encore la renumérotation du réseau IPv6.
+=== Deux impossibilités d’accéder au service de nommage et leurs remèdes ===
-Les informations de configuration correspondent à une ou plusieurs adresses IPv6 et à leurs temporisations associées, T1 et T2, où :
+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.
-* T1 représente la durée de vie de l‘adresse dans l’état préféré ;
-* T2 représente la durée de validité de l’adresse IPv6.
-Un serveur DHCPv6 peut allouer deux types d'adresses IPv6 :
+====Premier scénario : client IPv4 et serveur IPv6 ====
-* des adresses non temporaires ;
-* des adresses temporaires.
-==== Allocation des adresses non temporaires ====
+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.
-Le serveur choisit les adresses d’un client en fonction du lien du client, du DUID du client, des options fournies par le client, et des informations fournies par le relais DHCPv6.
+====Second scénario : client IPv6 et serveur IPv4 ====
-Les adresses allouées font l'objet d'une écriture dans le fichier des baux.
+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.
-==== Allocation des adresses temporaires ====
+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''.
-DHCPv6 gère les adresses temporaires comme les adresses non temporaires : une association d’identités pour adresse temporaire ne contient au plus qu’une seule adresse temporaire. Ici encore, l'allocation d'adresse fait l'objet d'une écriture dans le fichier des baux.
+===Taille limitée des messages DNS en UDP, extension EDNS.0 ===
-Le serveur DHCPv6, s'il est configuré pour cela, effectue des mises à jour dynamiques sécurisées du service de noms de domaines.
+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...).
-=== Options du protcole DHCPv6===
+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.
-Chaque option est codée en format TLV : type, longueur, valeur ; à savoir :
+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 type de l'option : Un champ <tt>type d'option</tt> identifie chaque option d'un paquet DHCPv6. Il permet l'interprétation des données transportées. Certaines options peuvent en contenir d'autres ou être structurées en plusieurs champs (voir Annexe 1 : options du protocole DHCPv6) ;
-* la longueur, en octets, du champ <tt>valeur du paramètre</tt> qui suit ;
-* le champ <tt>valeur du paramètre de configuration</tt>.
-Le champ <tt>type d'option</tt> est toujours codé sur 2 octets. Le champ <tt>longueur</tt> est codé sur 2 octets. Il est toujours présent, même en l'absence de valeur ou pour une information de longueur fixe. Il exclut le champ <tt>type</tt> 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''.
-Le tableau qui suit présente les options du protocole DHCPv6, leur code et leur définition. L’annexe 1 présente leur structure.
+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 : [[https://www.iana.org/domains/root/files]].
-|+'''Options de DHCPv6'''
-! Désignation || Code || Définition
-|-style="background:silver"
-|<tt>OPTION_CLIENTID</tt>
-||1
-||Identification du client
-|-
-|<tt>OPTION_SERVERID</tt>
-||2
-||Identification du serveur
-|-style="background:silver"
-|<tt>OPTION_IA_NA</tt>
-||3
-||Association d’identités pour les options d’adresse non temporaire
-|-
-|<tt>OPTION_IA_TA</tt>
-||4
-||Association d’identités pour les options d’adresse temporaire
-|-style="background:silver"
-|<tt>OPTION_IAADDR</tt>
-||5
-||Adresse associée à IA_NA ou IA_TA
-|-
-|<tt>OPTION_ORO</tt>
-||6
-||Identifie une liste d’options dans les messages échangés entre un client
-|-style="background:silver"
-|<tt>OPTION_PREFERENCE</tt>
-||7
-||Annonce au client la priorité du serveur DHCPv6 et comment gérer cette priorité.
-|-
-|<tt>OPTION_ELAPSED_TIME</tt>
-||8
-||Temps écoulé depuis le démarrage d'un échange pour la machine qui tente d’achever sa configuration.
-|-style="background:silver"
-|<tt>OPTION_RELAY_MSG</tt>
-||9
-||Transporte un message DHCPv6 relayé dans des messages ''relay-forw'' ou ''relay-repl''
-|-
-|<tt>OPTION_AUTH</tt>
-||11
-||Transporte les informations d’authentification de l’identité et du contenu des messages DHCPv6.
-|-style="background:silver"
-|<tt>OPTION_UNICAST</tt>
-||12
-||Permet au serveur d'indiquer au client qu’il peut utiliser l’adresse individuelle (unicast) du serveur pour échanger avec lui.
-|-
-|<tt>OPTION_STATUS_CODE</tt>
-||13
-||Indique le statut du message DHCPv6 qui transporte cette option.
-|-style="background:silver"
-|<tt>OPTION_RAPID_COMMIT</tt>
-||14
-||Permet, dans un message SOLICIT, à un client, de demander ce mode de fonctionnement pour réaliser des échanges en deux temps au lieu de quatre. Le serveur doit inclure cette option dans la réponse correspondante (''Solicit reply'').
-|-
-|<tt>OPTION_USER_CLASS</tt>
-||15
-||Définit la classe d’utilisateur associée à un utilisateur ou à une application.
-|-style="background:silver"
-|<tt>OPTION_VENDOR_CLASS</tt>
-||16
-||Identifie le constructeur du matériel utilisé par le client.
-|-
-|<tt>OPTION_VENDOR_OPTS</tt>
-||17
-||Permet que le client et le serveur échangent des informations spécifiques d’un constructeur.
-|-style="background:silver"
-|<tt>OPTION_INTERFACE_ID</tt>
-||18
-||Identifie l’interface de réception du message du client DHCPv6.
-|-
-|<tt>OPTION_RECONF_MSG</tt>
-||19
-||Indique, dans un message ''reconfiguration'', si le client doit répondre par un message ''renew'' ou ''information-request''.
-|-style="background:silver"
-|<tt>OPTION_RECONF_ACCEPT</tt>
-||20
-||Indique à un serveur si le client accepte ou refuse les messages ''reconfigure'' ou annonce à un client qu'il peut ou non accepter les messages ''reconfigure''.
-|}
-== Délégation de préfixe  à états ==
+<!-- PUTODO-->
-La délégation de préfixe à états fait intervenir deux routeurs : un routeur délégataire et un routeur demandeur. Le routeur délégataire alloue les préfixes. Le routeur demandeur demande un ou plusieurs préfixes au routeur délégataire.
-La délégation de préfixe à états utilise le protocole DHCPv6 pour déléguer les préfixes. Elle définit deux options : une association d'identités pour l'allocation de préfixes (IA_PD) et une option de préfixe d'association d'identités pour la délégation de préfixes (IA_PD Prefix).
+===Glue IPv6 ===
-Le routeur demandeur émet ses demandes sur l'interface qui donne accès au routeur délégataire.
-Le routeur délégataire répond sur l'interface qui donne accès au routeur demandeur. Lorsque ces deux routeurs ne se trouvent pas sur le même réseau, des relais DHCPv6 interviennent, comme dans le cas de l'allocation d'adresses. Leur fonctionnement est inchangé.
+La 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 délégation de préfixe à états se fait sans relais lorsque les routeurs délégataire et demandeur sont sur le même lien.
+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).
+<!-- PUTODO ici il ne s'agit pas des serveurs racines mais des serveurs qui gerent les 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…
-Les options de délégation de préfixe permettent au routeur délégataire de déléguer la gestion d'un ou plusieurs préfixes à un routeur demandeur.
+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.
-L'association d'identités pour l'allocation de préfixes associe notamment les DUID des routeurs demandeur et délégataire, et les préfixes alloués.
+===Publication des enregistrements AAAA dans le DNS ===
-L'option de préfixe d'association d'identités pour la délégation de préfixe transporte un préfixe qu'un routeur délégataire a délégué à un routeur demandeur. Cette option peut apparaître plusieurs fois dans une association d'identités (IA_PD).
-Notez que la délégation de préfixe à états est indépendante de l'allocation des adresses IPv6.
+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.
-=== Applications de 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.
-La délégation de préfixe convient pour des situations où le routeur délégataire ignore la topologie du réseau auquel le routeur demandeur donne accès et n'a pas d'autre information à connaître que l'identité du routeur demandeur pour allouer le préfixe. C'est, par exemple, le cas du routeur d'un FAI (Fournisseur d'Accès à Internet) qui alloue un préfixe au routeur d'accès d'un client (CPE : ''Customer Premise Equipment'', familièrement dénommé ''box'') reliant un réseau interne au réseau du FAI.  La figure 7 présente un exemple où la délégation de préfixe à états est possible.
+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.
-<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.
-[[Image:MOOC_Act33_Fig10.png|400px|center|thumb|Figure 7 : Exemple de délégation de préfixe à états.]]
-</center>
-La délégation de préfixe facilite également la renumérotation. Elle permet, par exemple,  d'allouer le préfixe qui servira à générer les nouvelles adresses IPv6.
+===Pour aller plus loin : mises à jour dynamiques du DNS===
-Les préfixes sont censés avoir une grande durée de vie. En cas de renumérotation, la cohabitation pendant un certain temps de l'ancien et du nouveau préfixe est fort probable. C'est, par exemple le cas pour la renumérotation passive présentée ci-dessous.
-==== Renumérotation des réseaux ====
+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).
-La renummérotation peut se faire de deux façons : passive ou active.
-===== Renumérotation passive =====
+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.
-Dans la renumérotation passive, chaque machine du réseau dispose de deux adresses IPv6 : une ancienne et une nouvelle. L'ancienne adresse est utilisée par les communications en cours. Ces communications sont préservées aussi longtemps que nécessaire (RENEW). Par contre, les nouvelles communications sont établies à l'aide de la nouvelle adresse. La renumérotation est terminée lorsque la dernière machine du réseau cesse d'utiliser son ancienne adresse.
-===== Renumérotation active =====
+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.
-Dans la renumérotation active, chaque machine, comme dans le cas précédent, dispose d'une ancienne adresse et d'une nouvelle.
-Le serveur DHCPv6 force les clients à cesser d'utiliser leur ancienne adresse à une date donnée. Le serveur réduit la durée de vie des anciennes adresses en fonction de la date d'échéance cible.
+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é.
-Lorsque la date d'échéance arrive, aucune utilisation d'ancienne adresse n'est possible. Toutes les communications utilisant les anciennes adresses sont coupées. Elles sont, en cas de besoin, rétablies en utilisant les nouvelles adresses.
+==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.
-Ici encore, la délégation de préfixe à états peut faciliter les choses en permettant que les machines auto-configurent leurs nouvelles adresses.
+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.
-Notez que l'utilisation du préfixe alloué sur le routeur demandeur est impossible sur le lien donnant accès au routeur délégataire. Ceci empêche par conséquent l'agrégation des routes d'accès au routeur demandeur et d'accès au réseau qu'il dessert.
+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.
-Deux autres options [RFC 6603], permettent d'exclure un seul préfixe pour l'affecter au lien qui, sur le routeur demandeur, donne accès au routeur délégataire.
+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''.
-Certains réseaux mobiles doivent pouvoir agréger les routes (vers le routeur demandeur et le réseau interne). Dans ce cas, le routeur demandeur doit utiliser le préfixe du réseau interne de l'interface qui le relie au routeur délégataire. Il utilise alors deux des options du RFC 6603.
-''(l'annexe 4 presente la structure de l'option d'association d'identités pour la délégation de préfixes (RFC 3633, RFC 7550)).''
-=== Principe de l'allocation ===
-Le routeur demandeur se comporte comme un client DHCPv6. Il émet un message SOLICIT contenant une association d'identités pour l'allocation de préfixes à états, IA_PD.
-Le routeur délégataire se comporte comme un serveur DHCPV6. Il alloue les préfixes en fonction de l'identité du routeur demandeur et des options de préfixe indiquées (voir la figure 8).
-<center>
-[[Image:MOOC_Act33_Fig13.png|400px|center|thumb|Figure 8 : Allocation de préfixe par un routeur délégataire.]]
-</center>
-=== Principe de l'allocation de préfixe à états avec relais ===
-Le relais encapsule le message SOLICIT du client dans l'option "message relayé" de son message RELAY-FORWARD. Il achemine ensuite ce message vers le serveur.
-Le serveur renvoie son message RELAY-REPLY au relais.
-Le relais  extrait le message ADVERTISE  de l'option "message relayé" du message RELAY-REPLY du serveur. Il le transmet ensuite au client. Il identifie l'interface d'accès au client grâce à l'adresse du lien incluse dans le champ Peer-Address de l'en-tête du message RELAY-REPLY (voir la figure 9).
-<center>
-[[Image:MOOC_Act33_Fig14.png|400px|center|thumb|Figure 9 : Allocation de préfixe par un routeur délégataire en présence d'un relais.]]
-</center>
-== Conclusion ==
+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.
-DHCPv6 est un protocole de niveau application. Il utilise le protocole de transport UDP et fonctionne en mode client-serveur. Les messages échangés transportent l'identité de l'émetteur (DUID), celle du récepteur, ou les deux, en fonction du sens de transmission du message et de l'avancement de l'échange.
-Ce protocole permet qu'un administrateur centralise et gère simplement les paramètres de configuration du réseau, répercute les changements de configuration à l'initiative du serveur DHCPv6 (renumérotation active), ou au contraire, laisse aux clients la possibilité de les prendre en compte lorsqu'ils le souhaitent (renumérotation passive).
+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é.
-Il fonctionne sans relais lorsque le client et le serveur se trouvent sur le même lien. Il fait intervenir des relais lorsque client et serveur sont sur des liens distincts.
+Les 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.
-Les relais utilisent des messages spécifiques pour communiquer avec les serveurs DHCPv6. Ils encapsulent les messages relayés dans une option de "message relayé". Ainsi, les messages des clients, ceux des serveurs, ou ceux des relais, ne sont jamais modifiés.
+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.
-Lorsque les relais disposent d’informations locales, des options spécifiques des messages RELAY-FORWARD leur permettent de les communiquer aux serveurs DHCPv6. Les serveurs DHCPv6, en fonction de leur configuration par l’administrateur du réseau, peuvent alors communiquer tout ou partie de ces informations à leurs clients.
+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.
-Tous les paramètres de configuration du réseau sont transportés dans des options des messages, ce qui fait de DHCPv6 un protocole extensible. Pour étendre le protocole, il suffit d’y ajouter de nouvelles options. Ainsi initialement, ni la délégation de préfixe, ni l'exclusion de préfixe n'existaient. Il a suffi de définir deux options supplémentaires et leur gestion en émission et en réception pour ajouter cette nouvelle fonctionnalité dans DHCPv6. Ceci a impliqué des modifications [RFC 7550] pour clarifier ou préciser la spécification RFC 3315 de DHCPv6 et entraînera prochainement la publication d'une nouvelle version de la spécification du protocole DHCPv6.
+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''.
-== Références bibliographiques ==
+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.
-<references />
-== Pour aller plus loin==
+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.
-RFC et leur analyse par S. Bortzmeyer :
-* RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3315.html Analyse]
-* RFC 3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 [http://www.bortzmeyer.org/3633.html Analyse]
-* RFC 5007 DHCPv6 Leasequery
-* RFC 6422 Relay-Supplied DHCP Options
-* RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation
-* RFC 7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options

Association G6