Difference between revisions of "MOOC:Annexe Compagnon Act34"
From Livre IPv6
(→ANNEXES Activité 34 : Faire correspondre adresse et nom de domaine) |
(→Act.34 Annexe 2 : Options DNS du protocole DHCPv6) |
||
| Line 36: | Line 36: | ||
Pour simplifier les choses, les noms de domaines ne sont pas compressés. Les bits excédentaires sont mis à 0. | 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== | + | ===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) : | 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) : | ||
| Line 48: | Line 48: | ||
</center> | </center> | ||
| − | ==Option liste de suffixes de nom de domaine== | + | ===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). | Le RFC 3315 prévoit également une option spécifiant la liste des suffixes de noms de domaines (cf. figure 13). | ||
Revision as of 11:42, 15 May 2018
ANNEXE 1 Activité 34 : 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).
- 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.
- 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.
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).
- 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.
Act.34 Annexe 3 :
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".
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 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
