Revision as of 18:22, 21 November 2005

Il existe aujourd'hui de nombreux logiciels DNS mais la présente section ne permet pas de les lister de manière exhaustive. La plupart de ces logiciels DNS supportent IPv6 dans leurs versions récentes. Ce support peut être soit complet (enregistrements AAAA, enregistrements PTR sous l'arborescence ip6.arpa et transport IPv6 des messages DNS) soit partiel (uniquement les enregistrements AAAA et PTR) selon le logiciel.

En outre, certaines distributions logicielles comportent l'implémentation du client et du serveur, d'autres n'incluent que l'implémentation du client ou celle du serveur. Par exemple, la distribution BIND 9 développé par l'ISC (Internet Systems Consortium http://www.isc.org) représente la référence de fait dans le domaine. En effet, il s'agit d'un logiciel complet (client, serveur et outils) intégrant toutes les extensions DNS récentes (IPv6, DNSSEC, ...). Par ailleurs, bien que l'ISC ait annoncé il y a plusieurs années l'arrêt des développements pour la distribution BIND 8, elle continue aujourd'hui à la mettre à jour grâce aux nouveautés implémentées dans BIND 9 (hors extensions DNSSEC). Les distributions BIND 8 et BIND 9 ont l'avantage d'être disponibles en code source et/ou binaire pour la quasi-totalité des plates-formes (Unix, MS Windows *, ...). Ainsi, la distribution BIND 9 a été choisie comme base pour les exemples de fichiers de configuration. Notons que ces fichiers de configuration sont également compatibles avec les versions récentes de la distribution BIND 8.

Clients et outils de vérification de configurations DNS

Un client DNS se présente souvent sous forme d'une bibliothèque de résolution appelée « libresolv », le client est alors appelé « resolver » ou encore « stub resolver ». Rappelons que ce resolver est sollicité par les applications TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes. Outre le resolver, il existe des outils et commandes selon le système d'exploitation, qui permettent d'interroger un serveur DNS dans un but de débogage et/ou de diagnostic. C'est le cas par exemple des outils dig, host et nslookup qui font partie des distributions BIND (8 et 9) et pour lesquels des exemples sont donnés ci-après.

Notons que lorsque le serveur à interroger n'est pas explicitement renseigné, c'est le (ou les) serveurs par défaut qui est (sont) interrogé(s). Il s'agit de la liste des serveurs récursifs qui est configurée automatiquement (via DHCP par exemple) ou manuellement (dans le fichier /etc/resolv.conf pour les systèmes Unix par exemple) sur l'équipement. Les mécanismes de découverte de la liste des serveurs DNS récursifs seront décrits plus loin dans la section découverte de la liste de serveurs DNS récursifs, See Découverte de la liste de serveurs DNS récursifs. L'exemple suivant liste un fichier resolv.conf sous Unix :

search nic.fr # domaine sous lequel la recherche est effectuée par défaut
nameserver 2001:660:3003:2::1:1 # serveur à interroger en premier
nameserver 192.134.4.160 # serveur à interroger en second si le premier ne répond pas

Exemples d'interrogation

Les six exemples suivants illustrent l'utilisation des outils dig, host et nslookup pour la même requête de résolution du nom `ns3.nic.fr' en adresse(s) IPv6.

>dig ns3.nic.fr aaaa

; <<>> DiG 9.2.3 <<>> ns3.nic.fr aaaa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46128
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 6
 
;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA
 
;; ANSWER SECTION:
ns3.nic.fr. 344922 IN AAAA 2001:660:3006:1::1:1
 
;; AUTHORITY SECTION:
nic.fr. 37280 IN NS ns1.nic.fr.
nic.fr. 37280 IN NS ns3.nic.fr.
nic.fr. 37280 IN NS ns.ripe.net.
 
[...]
 
;; Query time: 6 msec
;; SERVER: 2001:660:3003:2::1:1#53(2001:660:3003:2::1:1)
;; WHEN: Wed Jul 7 16:39:53 2004
;; MSG SIZE rcvd: 306

>dig ns3.nic.fr aaaa @ns.ripe.net

; <<>> DiG 9.2.3 <<>> ns3.nic.fr aaaa @ns.ripe.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16927
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 5
 
;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA
 
;; ANSWER SECTION:
ns3.nic.fr. 345600 IN AAAA 2001:660:3006:1::1:1
 
;; AUTHORITY SECTION:
 
[...]
 
;; SERVER: 2001:610:240:0:53::193#53(ns.ripe.net)

>host -t aaaa ns3.nic.fr
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>host -t aaaa ns3.nic.fr ns.ripe.net
Using domain server:
Name: ns.ripe.net
Address: 2001:610:240:0:53::193#53
Aliases:
 
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>nslookup -type=aaaa ns3.nic.fr
Server: 2001:660:3003:2::1:1
Address: 2001:660:3003:2::1:1#53
 
Non-authoritative answer:
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1
 
[...]

>nslookup -type=aaaa ns3.nic.fr ns.ripe.net
Server: ns.ripe.net
Address: 2001:610:240:0:53::193#53

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

Dans les exemples 1, 3 et 5, la requête est envoyée au serveur récursif par défaut (2001:660:3003:2::1:1). Dans les exemples 2, 4 et 6, la requête est envoyée au serveur ns.ripe.net (qui est secondaire pour la zone nic.fr).

Notons que l'outil nslookup n'est plus maintenu par l'ISC et qu'il est amené à disparaître. L'usage de l'outil dig ou de host pour toutes sortes de requêtes est en revanche recommandé.

La deuxième version de ZoneCheck, l'outil utilisé par l'AFNIC pour vérifier la configuration et valider la délégation de zones DNS sous .fr et .re, supporte IPv6 complètement. En effet, pour une zone DNS quelconque , ZoneCheck2 permet d'interroger la liste des serveurs faisant autorité sur cette zone afin de vérifier leur bon fonctionnement (en termes de transport UDP et TCP au-dessus d'IPv4 et d'IPv6 si IPv6 est supporté) et la bonne configuration de la zone DNS en question (en termes de base de données, notamment concernant la cohérence des enregistrements DNS entre serveurs différents).

Fichier de configuration d'un serveur BIND9

Pour un serveur de nom BIND 8 ou BIND 9, le fichier de configuration named.conf contient une succession de parties déclaratives. La partie options par exemple, indique au serveur les différentes options de configuration telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif ou le chemin d'accès aux données (option directory ).

Les zones DNS sur lesquelles le serveur fait autorité (primaire ou secondaire) sont ensuite déclarées successivement grâce à des rubriques de type zone. Pour chaque zone, le nom du fichier contenant les enregistrements de cette zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, on indique (à l'aide de la sous-rubrique masters ) la liste des adresses IPv4 et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici maintenant un extrait du fichier named.conf du serveur DNS ns3.nic.fr :

options {
   directory "/usr/local/bind";
   pid-file "/usr/local/bind/run/named.pid";
   recursion no;
   listen-on { any;};
   listen-on-v6 {any; };
   [...]
};
 
[...]
 
zone "." {
   type hint;
   file "named.root";
};
 
zone "localhost" {
   type master;
   file "localhost";
};
 
// Zone contenant l'enregistrement inverse pour l'adresse loopback en IPv4
 
zone "0.0.127.in-addr.arpa" {
   type master;
   file "localhost.rev";
}; 

// Zones (sous ipv6.arpa et ip6.int) contenant l'enregistrement inverse pour // l'adresse loopback  en IPv6
 

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
   type master;
   file "localhost.rev";
};
 
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {
   type master;
   file "localhost.rev";
};
 
[...]
 
zone "nic.fr" {
   type slave;
   file "zone/afnic.fr";
   masters {
    192.93.0.1;
    192.93.0.4;
   };
};
 
[...]
 
// Zone inverse IPv4 pour la réseau AFNIC-SFINX en 192.134.0/24
 
zone "0.134.192.in-addr.arpa" {
   type slave;
   file "rev/nic.fr.192.134.0";
   masters {
    192.93.0.1;
    192.93.0.4;
   };
};
 
[...]
 
// Blocs Ripe sous ip6.arpa.
 
zone "6.0.1.0.0.2.ip6.arpa" {
   type slave;
   file "rev/6.0.1.0.0.2.ip6.arpa";
   masters {
    2001:610:240:0:193::193;
    193.0.0.193;
   };
};
 
[...]
 
// Zone inverse IPv6 pour le reseau AFNIC-SFINX en 2001:660:3006::/48
 
zone "6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa" {
   type slave;
   file "rev/6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa";
   masters {
    192.93.0.1;
    192.93.0.4;
   };
};
 
[...]

Les options « listen-on » et « listen-on-v6 » permettent au serveur d'accepter des requêtes DNS respectivement en IPv4 et en IPv6 indiquant que les messages DNS contenus dans ces requêtes sont transportés en IPv4 ou en IPv6.

La valeur « any » indique au serveur qu'il faut écouter sur toutes les interfaces supportant la version d'IP en question. Pour IPv4, l'option « listen-on » peut avoir comme valeur « none » ou une liste sélective d'adresses IPv4. Quant à l'option « listen-on-v6 », elle ne peut pour le moment prendre que l'une des deux valeurs possibles : « any » (toutes les interfaces supportant IPv6) ou « none » (ce qui est la valeur par défaut).

A partir de la version 9.3.0 de BIND (actuellement en 9.3.0.rc2) l'écoute sélective en IPv6 est supportée comme c'est le cas en IPv4, c'est-à-dire que l'option « listen-on-v6 » peut prendre comme valeur une liste d'adresses IPv6.

Les cinq premières zones déclarées font partie de la configuration d'un serveur BIND de base. Les quatre zones restantes sont données à titre d'exemple parmi les nombreuses zones sur lesquelles le serveur ns3.nic.fr fait autorité.

Fichier de zone DNS direct

Voici à titre d'exemple, un extrait du fichier de zone DNS direct `nic.fr', faisant apparaître en même temps des adresses IPv4 et IPv6. On remarquera 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 autoconfiguration dépendent généralement de l'adresse physique de la carte réseau utilisée (RFC 3513).

$TTL 172800
$ORIGIN nic.fr.
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2004061402 ;serial
21600 ;refresh (6 h)
3600 ;retry (1 h)
3600000 ;expire
86400 ) ;minimum (2 j)
 
IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
 
IN MX 50 relay3.nic.fr.
IN MX 100 relay2.nic.fr.
IN MX 200 relay4.nic.fr.
;
ns1 IN A 192.93.0.1
ns2 IN A 192.93.0.4
ns3 IN A 192.134.0.49
IN AAAA 2001:660:3006:1::1:1 

[...]

cyclope IN A 192.134.4.5
IN AAAA 2001:660:3003:2::4:5
borabora IN A 192.134.4.6
IN AAAA 2001:660:3003:2::1:1
nscachev6 IN AAAA 2001:660:3003:2::1:1
 
kerkenna IN A 192.134.4.98
IN AAAA 2001:660:3003:8::4:98
 
ulysse IN A 192.134.7.131
IN AAAA 2001:660:3003:1d5a::1:3
 
[...]

Fichier de zone DNS inverse en IPv6

Voici un extrait de fichier de zone DNS inverse correspondant au préfixe IPv6 2001:660:3003::/48 (réseau AFNIC-Saint-Quentin-en-Yvelines) et représentant quelques enregistrements de type PTR d'équipements supportant IPv6.

Il est à noter que la directive `$ORIGIN' a délibérément été omise dans ce fichier afin que celui-ci serve simultanément aux deux zones DNS inverse 3.0.0.3.0.6.6. 0.1.0.0.2.ip6.arpa et 3.0.0.3.0.6.6.0.1.0.0.2.ip6.int :

$TTL 172800
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2004061400 ;serial
43200 ;refresh (12 h)
14400 ;retry (4 h)
3600000 ;expire
3600 ) ;

IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.

[...]

1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR borabora.nic.fr.
IN PTR nscachev6.nic.fr.
5.0.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR cyclope.nic.fr.

[...]

;
8.9.0.0.4.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0 IN PTR kerkenna.nic.fr.
;
1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.a.5.d.1 IN PTR ns1.afnic.idsa.prd.fr.
2.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.a.5.d.1 IN PTR ns2.afnic.idsa.prd.fr.
3.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.a.5.d.1 IN PTR ulysse.nic.fr.

[...]