Association G6

Mécanisme de découverte du PMTU

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 une base de données centralisée, le fichier hosts.txt. Cette base de données pouvait alors être téléchargée (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. Afin de remédier à ce problème, un nouveau système, le DNS (Domain Name System), a été conçu et mis en oeuvre. 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 noeud, un ensemble de serveurs fait autorité sur les données contenues dans la zone décrivant ce noeud. 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.

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

1 L'enregistrement AAAA
- 1.1 Format
2 Clients et outils de vérification de configurations DNS

L'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.

Format

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é, 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

Logiciels DNS supportant IPv6 et configurations

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.

Logiciels DNS supportant IPv6 et configurations

Les solutions expérimentales A6 et bitstring labels

Il existe aujourd'hui de nombreux logiciels DNS mais la présente section ne les liste pas 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é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.

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

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.
[...]