Revision as of 20:09, 6 June 2015

Le système de nommage en IPv6

Introduction

Lorsqu'une application souhaite communiquer avec une autre s'exécutant sur un équipement distant dont elle ne connaît que le nom, elle a besoin d'en trouver l'adresse, sans quoi la communication ne peut en général avoir lieu. Aux débuts de l'Internet, les adresses IP en usage n'étaient pas très nombreuses et il était donc relativement facile de les stocker dans un fichier centralisé, le fichier hosts.txt (RFC 608). Ce fichier pouvait alors être téléchargé (via ftp) par les utilisateurs souhaitant rafraîchir leurs informations stockées sous forme de fichier local (en l'occurrence /etc/hosts pour les systèmes Unix).

Dès le début des années 80, la croissance du nombre d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu de plus en plus difficiles la mise à jour et la mémorisation de ces adresses.

Paul Mockapetris, de l'Université de Californie, a conçu le système des noms de domaine (DNS) en 1983, et a écrit la première mise en œuvre à la demande de Jon Postel. Le DNS permet de résoudre un nom de domaine, un mécanisme qui consiste à trouver l'adresse IP qui lui est associée.

Petit à petit, le DNS s'est imposé comme étant une infrastructure pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système a l'avantage d'être :

• hiérarchique : sa structure d'arbre est analogue à celle d'un système de fichiers Unix. Cette structure d'arbre rend le système extensible (« scalable ») ;
• réparti : au niveau de chaque nœud, un ensemble de serveurs fait autorité sur les données contenues dans la zone décrivant ce nœud. Cet ensemble de serveurs représente la source officielle des données de la zone,
• et redondant : deux serveurs ou plus sont nécessaires pour chaque zone DNS afin d'assurer une meilleure disponibilité et un équilibrage de charge.

Spécifications

Le DNS avait initialement comme objectif premier d'offrir un service de résolution de noms de domaines Internet complètement qualifié (FQDN : Fully Qualified Domain Name) garantissant l'unicité du nom (exemple : ns3.nic.fr) en adresses IP et vice-versa.

En pratique, le service de résolution DNS consiste plus généralement à stocker et à retourner, sous forme d'enregistrements DNS (RR : Resource Records) et à la demande des applications, des informations associées à des noms de domaines, comme les adresses IP, les relais de messagerie (enregistrement de type MX) ou les serveurs de noms (enregistrement de type NS).

Rappelons au passage que pour ces applications, la communication est précédée par une phase lors de laquelle le client DNS local, appelé « stub resolver », interroge son serveur DNS récursif (ou cache) qui se charge d'effectuer les requêtes itératives nécessaires, en partant de la racine de l'arbre DNS s'il le faut, et de retourner les ressources recherchées. Pour les machines Unix, le fichier /etc/resolv.conf fournit l'adresse IP du (ou des) serveur(s) à interroger par défaut.

Le service de résolution DNS se trouvant au niveau de la couche application de la pile TCP/IP, il s'applique aux réseaux IPv6 de manière analogue aux réseaux IPv4. Le fait que les adresses IPv6 soient quatre fois plus longues que les adresses IPv4, qu'elles puissent être attribuées automatiquement et qu'elles soient représentées de surcroît en notation hexadécimale, a considérablement réduit les chances pour ces adresses IPv6 d'être mémorisées par un être humain. Ainsi, avec l'arrivée d'IPv6, le DNS devient plus que jamais un service critique pour le fonctionnement des applications TCP/IP classiques.

Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) :

• l'enregistrement AAAA (prononcé « quad A »), pour le nommage direct (correspondance : nom vers adresse). Ce nouveau type a pour code-valeur 28.
• le nouveau sous-arbre DNS inverse ip6.arpa pour le nommage inverse (correspondance : adresse vers nom)

Nommage direct : enregistrement AAAA

La correspondance entre un nom de domaine et son (ou ses) adresse(s) IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque enregistrement contient une valeur qui est une adresse IPv4.

De manière analogue à l'enregistrement A, le nouveau type d'enregistrement AAAA défini pour IPv6, permet d'établir la correspondance entre un nom de domaine et son (ou une de ses) adresse(s) IPv6. Une machine ayant plusieurs adresses IPv6 globales a en principe autant d'enregistrements AAAA publiés dans le DNS. Une requête DNS de type AAAA concernant une machine particulière retourne dans ce cas tous les enregistrements AAAA publiés dans le DNS et correspondant à cette machine. Toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au paragraphe Publication des enregistrements AAAA dans le DNS.

Le format textuel d'un enregistrement AAAA tel qu'il apparaît dans le fichier de zone DNS est le suivant :

<nom> [ttl] IN AAAA <adresse>

L'adresse est écrite suivant la représentation classique des adresses IPv6 (RFC 4291). Par exemple, l'adresse IPv6 de la machine ns3.nic.fr est publiée dans le fichier de zone nic.fr comme suit :

ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1

Il est important de noter que toutes les adresses IPv4 et/ou IPv6 correspondant à un équipement donné (c'est le cas d'un réseau configuré en dual-stack), doivent cohabiter dans le même fichier de zone renseignant le nom de l'équipement en question. Ainsi, les adresses de ns3.nic.fr sont publiées dans le fichier de zone nic.fr comme suit :

$ORIGIN nic.fr.
ns3 IN A    192.134.0.49
    IN AAAA 2001:660:3006:1::1:1

Nommage inverse : enregistrement PTR

L'enregistrement de type PTR, stocké sous l'arbre DNS inverse in-addr.arpa, permet d'établir la correspondance entre une adresse IPv4 et un (ou plusieurs) nom(s). C'est ce même type d'enregistrement PTR, qui, stocké sous l'arbre DNS inverse ip6.arpa, permet de mettre en correspondance une adresse IPv6 avec un ou plusieurs noms de domaines.

Notons au passage qu'auparavant, le RFC 1886, rendu obsolète par le RFC 3596, spécifiait une autre arborescence : ip6.int. Cette dernière a été arrêtée en 2006.

Une adresse IPv6 est transformée en un nom de domaine publié sous l'arborescence inverse ip6.arpa de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère `.' et concaténés dans l'ordre inverse au suffixe ip6.arpa.

Par exemple l'adresse 2001:660:3006:1::1:1 (adresse de ns3.nic.fr) est transformée en le nom de domaine inverse suivant :

1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.

On publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut `ns3.nic.fr.'

En pratique, on procède par délégation de zones inverses afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS. Soulignons que la délégation DNS inverse suit le schéma classique d'attribution des adresses IP (le même pour IPv4 et IPv6) :

• 1) L'IANA délègue (en terme de provision) de larges blocs d'adresses IPv6 aux registres Internet régionaux (RIR : Regional Internet Registry ), typiquement des préfixes de longueur 12 selon la politique actuelle
• 2) Les RIR allouent (en terme de provision) des blocs d'adresses IPv6 plus petits aux registres Internet locaux (LIR : Local Internet Registry), c'est-à-dire aux fournisseurs d'accès Internet de la région, typiquement des préfixes de longueur 32 (ou plus courts selon le besoin). À noter que dans les régions APNIC et LACNIC, il existe des Registres nationaux (NIR) comme registres intermédiaires entre le RIR et les LIR présents dans le pays en question.
• 3) Les LIR attribuent (pour un usage direct) des préfixes IPv6 aux clients finaux, typiquement des préfixes de longueur variable entre un /64 et un /48 (selon le besoin et selon la politique en vigueur).

Figure 6-1 Exemple de délégation de zones inverse

À chaque nœud présent dans l'arborescence DNS inverse, illustrée par la figure Exemple de délégation de zones inverse, est associée une liste de serveurs DNS qui héberge la zone inverse décrivant ce nœud. Une telle liste comprend généralement un serveur primaire et un ou plusieurs serveurs secondaires, tous considérés comme faisant autorité sur la zone DNS inverse en question. C'est au client final, de publier dans ses propres zones DNS inverse les enregistrements PTR correspondant aux adresses IPv6 qu'il utilise.

Par exemple, Renater a reçu le préfixe 2001:660::/32 et la délégation de la zone DNS inverse 0.6.6.0.1.0.0.2.ip6.arpa de la part du RIPE-NCC. Renater a affecté à l'AFNIC le préfixe 2001:660:3006::/48 et lui a délégué la zone DNS inverse correspondante :

6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.

L'AFNIC publie alors dans sa zone DNS inverse les enregistrements PTR correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS :

$ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.

Mises en oeuvre

Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)

Logiciels DNS supportant IPv6

Il existe aujourd'hui de nombreux logiciels DNS mais la présente 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 page suivante : http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software

Dans leurs versions récentes, la plupart de ces logiciels DNS supportent IPv6 complètement, c'est-à-dire à la fois au niveau de la base de données (enregistrements AAAA et PTR) et au niveau transport IPv6 des messages DNS.

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

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 celle du serveur. Par exemple, la distribution BIND 9 développée par l'ISC (Internet Systems Consortium) 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...). Les distributions BIND 9 ont l'avantage d'être disponibles en code source et en format 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 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, récursif ou faisant autorité uniquement. Ainsi, de plus en plus d'opérateurs DNS tournent aujourd'hui le serveur récursif NSD comme serveur DNS faisant autorité (sans récursion) et Unbound comme serveur récursif pour l'une et/ou l'autre de ces deux raisons :

• pour leur performance reconnue (des tests de performance d'un côté entre NSD et BIND et de l'autre entre Unbound et BIND montrent la supériorité du premier sur le second) ;
• pour la diversification de leur plates-formes logicielles (on parle souvent de diversité génétique).

Enfin, des comparaisons multicritères entre les différentes implémentations sont présentées ici : http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software

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 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 ou au travers d'une interface graphique pour MS Windows et Mac OS) 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 décrit un fichier resolv.conf sous Unix :

search nic.fr                    # domaine de recherche par défaut
nameserver     ::1               # prefer localhost-v6
nameserver     192.134.4.162     # backup v4

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.3.3 <<>> ns3.nic.fr aaaa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3032
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;ns3.nic.fr.                    IN      AAAA

;; ANSWER SECTION:
ns3.nic.fr.             172800  IN      AAAA    2001:660:3006:1::1:1

;; AUTHORITY SECTION:
nic.fr.                 78032   IN      NS      ns1.nic.fr.
nic.fr.                 78032   IN      NS      ns2.nic.fr.
nic.fr.                 78032   IN      NS      ns3.nic.fr.
nic.fr.                 78032   IN      NS      ns-sec.ripe.net.
[...]

;; ADDITIONAL SECTION:
ns1.nic.fr.             78032   IN      A       192.93.0.1
ns1.nic.fr.             17168   IN      AAAA    2001:660:3005:1::1:1
ns2.nic.fr.             25737   IN      A       192.93.0.4
ns2.nic.fr.             25737   IN      AAAA    2001:660:3005:1::1:2
ns-sec.ripe.net.        96368   IN      A       193.0.0.196
ns-sec.ripe.net.        96368   IN      AAAA    2001:610:240:0:53::4

;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Oct 25 19:13:54 2007
;; MSG SIZE  rcvd: 350

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

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa @ns-sec.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::4#53(ns-sec.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-sec.ripe.net
Using domain server:
Name: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#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 -secripe.net
Server: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#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-sec.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, ZoneCheck 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).

Configuration de serveur/zone DNS

Même si les logiciels DNS utilisés sont interopérables, leur syntaxe et règles de configuration peuvent être très différentes d'une implémentation à l'autre. Dans ce chapitre, nous avons choisi de fournir des exemples suivant la syntaxe et les règles de BIND 9, logiciel considéré aujourd'hui comme l'implémentation de référence.

Fichier de configuration d'un serveur BIND9

Pour un serveur de nom 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";
   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";
}; 

// Zone inverse (sous ipv6.arpa) 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 "nic.fr" {
   type slave;
   file "zone/nic.fr";
   masters {
    2001:660:3005:1::1:1; 192.93.0.1;
    2001:660:3005:1::1:2; 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 {
    2001:660:3005:1::1:1; 192.93.0.1;
    2001:660:3005:1::1:2; 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:53::3;
    193.0.0.195;
   };
};
 
[...]
 
// 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 {
    2001:660:3005:1::1:1; 192.93.0.1;
    2001:660:3005:1::1:2; 192.93.0.4;
   };
};
 
[...]

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

• any : dans ce cas-là, le serveur écoutera sur toutes ces adresses IPv4 opérationnelles ;
• une liste explicite comprenant une ou plusieurs adresses IPv4 données : le serveur écoutera uniquement sur ses adresses pour ce qui est du transport IPv4 des requêtes et réponses ;
• none : pas de support d'IPv4 (cette valeur n'est pas utilisée aujourd'hui).

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

• any : dans ce cas-là, le serveur écoutera sur toutes ses adresses IPv6 opérationnelles ;
• une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoutera uniquement sur ces adresses pour ce qui est du transport IPv6 des requêtes et réponses ;
• none : pas de support d'IPv6 (valeur par défaut).

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 auto-configuration dépendent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

$TTL 172800
$ORIGIN nic.fr.
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
    2007102200 ;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 10   mx1.nic.fr.
            IN  MX 20   mx2.nic.fr.
[...]

 ns1        IN  A       192.93.0.1
            IN  AAAA    2001:660:3005:1::1:1
 ns2        IN  A       192.93.0.4
            IN  AAAA    2001:660:3005:1::1:2
 ns3        IN  A       192.134.0.49
            IN  AAAA    2001:660:3006:1::1:1

[...]

 www        IN  CNAME   rigolo
 rigolo     IN  A       192.134.4.20
            IN  AAAA    2001:660:3003:2::4:20

 kerkenna   IN  A 192.134.4.98
            IN  AAAA 2001:660:3003:8::4:98
 
[...]

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

$ORIGIN 3.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
$TTL 172800
@       IN      SOA     maya.nic.fr.    hostmaster.nic.fr. (
                       2007031200      ;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.
[...]
0.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0         IN      PTR     rigolo.nic.fr.
7.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0         IN      PTR     funk.nic.fr.
1.3.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0         IN      PTR     wood.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.
[...]

Recommandations opérationnelles pour l'intégration d'IPv6

Comme cela a été décrit dans l'introduction de ce chapitre, le DNS a la particularité d'être à la fois une application TCP/IP et une infrastructure critique (en tant que base de données) pour le fonctionnement des autres applications TCP/IP classiques (web, mail, ftp, ...). Avec l'intégration progressive d'IPv6, de nouveaux problèmes opérationnels liés au DNS se posent ou risquent de se poser et il convient donc de les éviter ou de trouver tout au moins les solutions adéquates afin d'y remédier. À cet effet, RFC 3901 et RFC 4472 identifient les principaux problèmes et formulent une série de recommandations pratiques pour y faire face. Les sections qui suivent tentent de résumer ces recommandations.

Les deux aspects du DNS

En tant que base de données, le DNS supporte les enregistrements A et AAAA et ce, indépendamment de la version d'IP qui est 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 supporte le transport IPv4 ou le transport IPv6 ou les deux à la fois. Dans tous les cas, il doit retourner ce qu'il a dans sa base de données pour répondre à une requête donnée, indépendamment de la version d'IP sur laquelle il a reçu cette requête. En effet, un serveur DNS ne peut a priori pas savoir si le client initiateur de la requête a transmis celle-ci en IPv4 ou en IPv6 à son serveur récursif (cache) : des serveurs intermédiaires appelés cache forwarders et n'utilisant pas la même version d'IP que le client, peuvent intervenir dans la chaîne des serveurs interrogés durant le processus de résolution DNS. En outre, en admettant même que le serveur DNS puisse connaître la version d'IP utilisée par le client qui a initié la requête, il faut souligner que le serveur n'a pas à faire d'hypothèse sur l'usage que fera le client de la réponse DNS retournée.

Continuité du service DNS

Avant l'arrivée d'IPv6, le processus de résolution DNS ne faisait intervenir que la version 4 d'IP et le service était donc garanti pour tous les clients DNS. Avec IPv6, on risque de se trouver dans des configurations où l'espace de nommage devient fragmenté en des partitions accessibles uniquement au-dessus d'IPv4 et d'autres accessibles uniquement au-dessus d'IPv6. Voici par exemple deux scénarios illustrant ce problème de fragmentation ainsi que la solution recommandée dans chaque scénario :

• premier scénario : un client ne supportant qu'IPv4 souhaite résoudre une requête relative à une zone DNS hébergée sur des serveurs ne supportant qu'IPv6. Dans ces cas-là, le processus de résolution se termine par un échec dû à l'impossibilité d'accéder aux serveurs qui font autorité sur cette zone. Pour y remédier, il faudra faire en sorte que toute zone DNS soit servie par au moins un serveur supportant IPv4.
• second scénario : un client DNS dans un réseau ne supportant qu'IPv6 souhaite résoudre une requête donnée. Si le serveur récursif interrogé ne supporte pas non plus IPv4, le processus de résolution risque d'échouer plus tard avant de joindre les serveurs faisant autorité sur l'information recherchée. En effet, lors de son parcours de la chaîne de délégations dans l'arborescence DNS, le serveur récursif risque de tomber sur un serveur ne supportant pas IPv6. Afin d'y remédier, il est recommandé dans ce cas, de configurer le serveur récursif en le faisant pointer vers un serveur forwarder en double pile IPv4/IPv6.

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option :

forwarders {<liste des adresses de serveurs forwarders> ;}

sous la rubrique « options » dans le fichier named.conf.

Taille limitée des messages DNS en UDP

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, ...). En tant qu'application TCP/IP, le DNS doit supporter les deux modes de transport UDP et TCP (RFC 1035), le port associé étant le même : 53.

Le mode UDP est généralement utilisé pour les requêtes/réponses DNS et le mode TCP est généralement utilisé pour les transferts de zones. Cependant, compte tenu de la taille limitée à 512 octets des messages DNS en mode UDP, certaines requêtes peuvent provoquer le passage en mode TCP si la taille de la réponse dépasse cette limite.

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) est positionné, ce qui signifie implicitement que le client est invité à réinterroger le serveur en mode TCP. Au passage, ce scénario constitue un argument justifiant le fait que le port 53 en TCP ne doit pas être ouvert exclusivement pour les transferts de zones.

Notons qu'un basculement trop fréquent en mode TCP risque de consommer davantage de ressources et dégrader par conséquent les performances du serveur DNS. Certains nouveaux types d'enregistrements (tels que le type AAAA) risquent d'augmenter la taille des réponses DNS de manière significative, ce qui risque de faire basculer plus souvent les requêtes/réponses DNS en mode TCP. Aujourd'hui, ce dépassement n'arrive que rarement car la plupart des réponses DNS ne dépasse guère les 400 octets. En effet, les sections answer, authority et additional, qui constituent la majeure partie de la réponse DNS, ne contiennent qu'un nombre limité d'enregistrements si cette réponse ne concerne pas directement une zone de haut niveau telle que .com, .net, .fr, .de...

Face à ce risque, l'extension EDNS.0 (RFC 2671) a été proposée et est déjà déployée dans les versions récentes des logiciels DNS. Cette extension, permet à un client DNS d'informer le serveur interrogé qu'il est capable de supporter des réponses de taille supérieure à la limite des 512 octets (4096 octets par exemple). Ainsi, en présence d'IPv6, le support d'EDNS.0 devient fortement recommandé. À noter que le support d'EDNS.0 devient également indispensable en présence des extensions DNSSEC.

Le faible taux de pénétration d'EDNS.0 dans les logiciels DNS (surtout les clients) est resté pendant plusieurs années l'un des principaux motifs du refus de l'IANA/ICANN de publier de nouvelles adresses (IPv4 ou IPv6) pour des serveurs de la racine. À partir du 4 février 2008, l'IANA publie dans la zone racine l'adresse IPv6 (enregistrement AAAA) des serveurs racine supportant le transport IPv6 et la nouvelle version du fichier de de démarrage (typiquement named.root pour BIND 9) contient également ces adresses.

Notons 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 : http://www.root-servers.org/ .

Glue IPv6

La zone racine publie également les adresses des différents serveurs DNS pour chacun des domaines de haut niveau (TLD : Top Level Domain). Ces adresses, appelées « glues » sont nécessaires pour que le processus de résolution DNS puisse démarrer. En effet, rappelons que les serveurs DNS de la racine ne sont pas censés résoudre eux-mêmes les requêtes. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs de haut niveau (TLD). L'information d'aiguillage comprend la liste des serveurs du TLD sous l'arborescence duquel se trouve la ressource ainsi que les adresses (glues) associées à ces serveurs. Sans ces glues, le processus de résolution risque de tourner en rond.

En attendant que les serveurs de la racine puissent recevoir des requêtes DNS et y répondre en IPv6, les TLD avaient œuvré pendant des années à l'introduction dans la zone racine des « glues » IPv6 qui lui sont associées. L'IANA/ICANN ont enfin été convaincus que la publication des glues IPv6 des serveurs DNS de TLD supportant IPv6 peut se faire sans risque pour la stabilité du DNS. L'ICANN/IANA a démarré en juillet 2004 la publication des glues IPv6 des TLD dans la zone racine. Les trois TLD .fr, .jp et .kr ont vu les premiers leur glue IPv6 publiée.

Publication des enregistrements AAAA dans le DNS

On choisit généralement de publier dans le DNS le (ou les) enregistrement(s) AAAA associé(s) à un équipement donné lorsque l'on souhaite que les applications initiant des communications à destination de cet équipement découvrent le support du transport IPv6. Par exemple, un navigateur supportant IPv6, découvre via le DNS qu'il est possible de se connecter 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, certaines applications s'exécutant sur l'équipement dont l'adresse IPv6 est publiée dans le DNS peuvent ne pas supporter IPv6. Ainsi, l'on risque de se trouver par exemple dans la situation suivante :

• l'équipement foo.example.com héberge plusieurs services : web, ftp, mail, dns ;
• les serveurs web et dns s'exécutant sur foo.example.com supportent IPv6 mais pas les serveurs ftp et mail ;
• une adresse IPv6 est publiée dans le DNS pour foo.example.com ;
• un client ftp supportant IPv6 tente de se connecter au serveur s'exécutant sur foo.example.com. Le client sélectionne alors l'adresse IPv6 de foo.example.com comme adresse destination ;
• la tentative de communication en IPv6 échoue. Selon les implémentations, certains clients réessaient (ou non) d'autres adresses IPv6 s'il y en a ou passent (ou non) en IPv4 en dernier recours.

Afin de pallier ce problème, il est recommandé 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.example.com et ns.example.com avec adresses IPv6 (et IPv4 éventuellement) et d'autre part, les noms ftp.example.com et mail.example.com avec des adresses IPv4 uniquement. L'enregistrement AAAA pour foo.example.com n'est alors publié que lorsque l'on a 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/elle fait !) d'y publier des adresses IPv6 non joignables de l'extérieur, soit à cause d'une portée faible (adresses lien-local par exemple), soit parce que toutes les communications provenant de l'extérieur du réseau et allant vers ces adresses sont filtrées. Notons 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). Avec ce système de vues, la réponse à une requête DNS dépend de l'origine du client. Par exemple un client appartenant au réseau interne pourra voir les adresses privées des équipements. Les clients externes, quant à eux, ne verront que les adresses globales et joignables de l'extérieur.