Latest revision as of 15:45, 5 July 2010

1. Introduction

Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.

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. 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. Afin de remédier à ce problème, un nouveau système, le DNS (Domain Name System), a été conçu et mis en œuvre. 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.

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

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

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

2.3. Découverte de la liste de serveurs DNS récursifs

L'autoconfiguration IPv6 sans état, telle que spécifiée dans le RFC 4862, n'a pas prévu de mécanisme de découverte automatique de la liste des serveurs DNS récursifs (cache). En revanche, il était prévu que ces informations complémentaires soient fournies par l'autoconfiguration avec état. Les spécifications du protocole d'autoconfiguration avec état, DHCPv6, ont mis longtemps (six ans environ) à passer en RFC (RFC 3315) et le besoin de découverte des serveurs DNS récursifs s'est accentué davantage. En effet, afin de renforcer le déploiement d'IPv6, la communauté IPv6 s'était vite trouvée dans l'urgence de mettre en oeuvre un mécanisme de découverte automatique du DNS avec ou sans DHCPv6 (qui était justement près de sortir).

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop ». C'est le groupe dnsop qui a pris en charge les débats sur ces propositions. Les co-auteurs de ces trois propositions ont conjointement rédigé un document synthétique (RFC 4339) décrivant pour chaque technique le fonctionnement ainsi que les scénarios d'utilisation. Ce document donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

Voici maintenant un résumé des trois propositions :

• Proposition 1, mécanisme à base de DHCP : deux solutions légèrement différentes ont été proposées. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646 :
  • découverte via un serveur DHCPv6 complet (RFC 3315 : c'est-à-dire qui alloue dynamiquement les adresses IPv6 ;
  • découverte du DNS via un serveur DHCPv6-lite (RFC 3736) : celui-ci n'alloue pas d'adresses IPv6 mais il est simplement chargé d'informer les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression, ...) ;
  • Dans les deux cas, si l'équipement est en double pile et s'il est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), il faut définir une politique d'arbitrage entre les deux listes de serveurs DNS récursifs obtenues si celles-ci sont incohérentes ;
• Proposition 2, RFC 5006, mécanisme à base d'annonce de routeur (RA): cette proposition apporte un complément à l'autoconfiguration sans état (RFC 4862) et consiste à surcharger l'annonce du routeur, en tant que message de la découverte des voisins (RFC 4861) par l'information DNS nécessaire. Une telle extension n'a pas été standardisée à ce jour, le RFC étant dans un état EXPERIMENTAL ;
• Proposition 3, mécanisme à base d'adresses anycast bien connues (Well-known anycast addresses) : des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée.

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

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

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

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

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

3.3.1. 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é.

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

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

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

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

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

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

3.4.3. 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/ .

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

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

4. Questions ouvertes

Faire le point sur les aspects controversés

4.1. Propagation et mise à jour dynamique du DNS

La résolution DNS classique est optimisée grâce à l'introduction, d'entités intermédiaires : les serveurs récursifs ou caches. En effet, lorsqu'un client DNS soumet une requête à un serveur récursif, ce dernier se charge de la relayer à une chaîne de serveurs mieux renseignés que lui et de rechercher, de proche en proche, la réponse à la requête en question.Cette chaîne commence généralement par un serveur racine et se termine par un serveur autoritaire (primaire ou secondaire) sur la zone contenant le nom de domaine objet de la requête en question.

Le serveur maintient alors cette réponse dans son cache, pendant une durée de vie donnée (TTL : Time To Live). Le TTL est configurable selon la fréquence de changement des informations dans la zone concernée et il est généralement compris entre quelques dizaines de minutes et quelques jours. Si un client envoie une requête pour laquelle la réponse est encore dans le cache avant l'expiration de sa durée de vie, le serveur cache restitue alors cette réponse au client sans avoir à refaire l'interrogation de toute la chaîne de serveurs qui l'y a conduit. Par conséquent, le client prend le risque que la ressource qu'il vient tout juste de récupérer soit, dans le même temps, déjà modifiée sur les serveurs autoritaires sur la zone DNS contenant la ressource en question. Autrement dit, le TTL est une source potentielle d'incohérence des ressources DNS entre les serveurs autoritaires et les serveurs cache.

Ce risque d'incohérence existe également entre les serveurs autoritaires eux-mêmes. En effet, pour une zone DNS donnée, chaque serveur secondaire se sert du paramètre refresh figurant dans l'enregistrement SOA de la zone en question. Il spécifie le délai entre deux synchronisations et vaut souvent plusieurs heures de cette zone.

En cas de mise à jour récente sur le serveur primaire, le rafraîchissement de la zone en question, sur les serveurs secondaires, s'impose. Par conséquent, un serveur récursif n'est en fait jamais sûr de la pertinence de l'information qu'il récupère car celle-ci risque de provenir d'un serveur secondaire mal synchronisé. Afin de pallier ce dernier problème d'incohérence entre serveurs autoritaires, deux extensions DNS ont été spécifiées :

• Notification (RFC 1996) (NOTIFY) et
• Transfert incrémental (RFC 1995) (IXFR).

Ces deux protocoles permettent de faciliter et d'accélérer la synchronisation des zones DNS hébergées par les serveurs secondaires. Le protocole de notification est utilisé par un serveur DNS primaire pour informer ses serveurs secondaires qu'une zone a été modifiée. Les serveurs secondaires peuvent alors récupérer la nouvelle zone immédiatement, sans attendre le délai normal de synchronisation (donné par le paramètre « refresh »). Le protocole de transfert incrémental est utilisé pour optimiser le volume de l'échange entre serveur primaire et secondaire : si les modifications d'une zone sont faibles, on transfère seulement ces modifications et non la zone complète.

En dépit des palliatifs NOTIFY et IXFR, le mécanisme classique de résolution DNS reste inadapté aux réseaux dans lesquels les équipements sont susceptibles de changer d'adresse(s) très fréquemment et s'attendent de surcroît à être immédiatement contactés sur leur(s) nouvelle(s) adresse(s). Ainsi, il est devenu nécessaire, il y a quelques années, d'étendre les fonctionnalités du DNS afin qu'il puisse suivre et restituer en temps réel l'évolution des adresses des équipements dans les environnements dynamiques. De telles fonctionnalités sont, bien entendu, indépendantes de la version d'IP même si l'autoconfiguration dans IPv6 ne fait qu'accentuer ce besoin.

L'IETF a proposé une solution au problème de mise à jour dynamique du DNS dans le (RFC 2136) (DNS Dynamic Update). Ce mécanisme permet à un client de soumettre aux serveurs DNS autoritaires sur un nom de domaine donné, une requête de mise à jour DNS concernant ce nom de domaine. Les seules opérations possibles de mise à jour sont celles de l'ajout d'enregistrements DNS (RRs) ou de suppressions de RRs ou de RRsets (ensemble de RRs de même nom, classe et type). Dans ces cas-là, le TTL est relativement très court (de 0 secondes à quelques minutes). Les requêtes les plus fréquentes sont celles de l'ajout ou de la suppression de l'adresse IP d'un équipement dans le DNS direct (correspondance du nom vers l'adresse) ou de son nom dans le DNS inverse (correspondance de l'adresse vers le nom).

Dans le cas de l'auto-configuration IPv6 sans état (RFC 4862) (cf. Configuration automatique), le client de mise à jour dynamique du DNS (nsupdate par exemple) peut s'exécuter sur l'équipement-même concerné par la mise à jour. Dans le cas de l'autoconfiguration avec état (DHCP) (cf. Configuration avec état :DHCPv6), le client de mise à jour peut soit s'exécuter sur l'équipement concerné soit être couplé au serveur DHCP.

Le protocole de mise à jour dynamique du DNS See (RFC 2136) n'a pas été sécurisé à la base, c'est-à-dire, il n'a pas prévu l'authentification des seuls clients autorisés à modifier des enregistrements DNS. Le RFC 3007 propose donc de sécuriser les transactions de mise à jour du DNS, notamment en utilisant les techniques TSIG (RFC 2845), TKEY (RFC 2930) ou SIG(0) (RFC 2931) :

• La première technique, TSIG (Secret Key Transaction Signatures for DNS) permet l'authentification des parties de la transaction et de signer les messages DNS à l'aide d'une clé secrète symétrique. Soulignons que TSIG ne décrit pas le mécansime par lequel la clé secrète est mise en place (cette clé est donc configurée par défaut manuellement).
• La deuxième technique, TKEY (Secret Key Establishment for DNS), vient compléter la première : elle permet d'automatiser la construction et la mise en place de la clé secrète à utiliser par TSIG.
• Enfin, la troisième technique, SIG(0) (DNS Request and Transaction Signatures), permet d'authentifier les parties de la transaction et de signer les messages DNS à l'aide d'une paire de clés (Clé publique/Clé privée) dont la partie publique est stockée dans le DNS grâce à des enregistrements de type KEY.

Malheureusement, la mise à jour dynamique sécurisée du DNS n'est toujours pas déployée à grande échelle. En effet, d'un côté, même si la technique TSIG est largement implémentée, elle n'est pas extensible (« scalable ») et de l'autre, la technique SIG(0) n'est que partiellement implémentée aujourd'hui. Ainsi SIG(0) est partiellement implémentée dans la distribution BIND 9.3.0 et supérieures.

En outre, la mise à jour dynamique du DNS devient problématique si celle-ci résulte de la configuration automatique d'un équipement IPv6 dans un réseau étranger (par exemple dans le cadre de la mobilité). En effet, si cet équipement peut théoriquement soumettre une requête de mise à jour de son (ou de ses) enregistrement(s) AAAA dans sa zone DNS direct, il n'est généralement pas autorisé à soumettre des requêtes de mise à jour de son (ou de ses) enregistrement(s) PTR dans la zone DNS inverse car celle-ci est sous l'autorité de serveurs DNS dans le réseau visité.

5. Sujets de recherche

Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.

5.1. Les solutions expérimentales A6 et bitstring labels

Vers la fin des années 90, on pensait qu'on allait bientôt avoir besoin de renuméroter les réseaux IPv6 de plus en plus souvent, notamment suite aux changements potentiellement fréquents des préfixes de sites IPv6 . Une telle renumérotation nécessiterait une mise à jour aussi fréquente du DNS pour assurer l'accessibilité des nouvelles adresses. On s'était vite rendu compte que l'enregistrement AAAA n'était pas adapté à ce besoin, notamment à cause du faible déploiement du mécanisme de mise à jour dynamique du DNS . Il a fallu alors spécifier une nouvelle extension et en même temps un nouveau type d'enregistrement, l'enregistrement A6 (RFC 2874), dont la structure reflète deux parties distinctes d'une adresse IPv6 :

• une partie variable : le préfixe du lien auquel l'interface est attachée. Ce préfixe (les 64 bits de poids fort) est dérivé du préfixe de site et supporte plusieurs niveaux d'agrégation, chaque niveau d'agrégation étant renseigné dans un enregistrement A6 faisant partie d'une chaîne ;
• une partie fixe (les 64 bits de poids faible) obtenue à partir de l'identificateur d'interface de l'équipement en question.

Malgré l'intérêt que présentait cette proposition, les groupes de travail de l'IETF dnsext et ngtrans ont décidé, après de longs débats, d'écarter l'extension A6 de la voie de standardisation (Standard Track) en faisant passer le RFC 2874 à l'état « experimental » (RFC 3363) pour les raisons suivantes :

• on ne voyait toujours pas de besoin concret de renumérotation fréquente de réseaux IPv6 ;
• l'implémentation de l'extension A6 et surtout son déploiement se sont avérés complexes. En effet, le fait qu'une requête de résolution DNS du type A6 puisse faire appel récursivement à d'autres requêtes A6 afin de reconstituer l'adresse IPv6 complète recherchée, peut provoquer des temps d'attente trop longs faisant ainsi échouer la requête de résolution initiale ;
• il serait dangereux de mettre en oeuvre la nouvelle extension A6 sans s'assurer par avance que cette extension n'aura aucun impact négatif sur les performances du DNS en production.

Soulignons que le groupe de travail dnsext a d'un côté recommandé de continuer à expérimenter l'extension A6 et de l'autre, il a décidé de faire avancer l'extension AAAA initialement publié dans le RFC 1886 et par la même occasion l'extension ip6.arpa, initialement publiée dans le RFC 3152, sur la voie de standardisation. En effet, suite à des tests d'interopérabilité réussis, les RFC originels (1886 et 3152) qui spécifiaient ces extensions et qui étaient en Proposed Standard (PS), ont été recyclés en un document IETF (Internet Draft) qui a donné naissance par la suite au RFC 3596 (avec le statut de Draft Standard, DS).

Par ailleurs, une autre extension a été proposée pour améliorer la gestion des zones DNS inverse IPv6 : les bitstring labels (RFC 2673). Cette extension, qui était censée s'appliquer uniquement sur l'arbre inverse ip6.arpa, consistait à utiliser des étiquettes binaires pour nommer les enregistrements PTR plutôt que les étiquettes en notation hexadécimale. Le but était de permettre de déléguer les blocs d'adresses selon une longueur quelconque de préfixe et de lever ainsi la contrainte de délégation des zones DNS inverse sur la frontière du demi-octet. Cette extension a été écartée de la voie de standardisation en même temps que l'extension A6 (RFC 3363) à cause de la complexité de sa mise en oeuvre et du manque de retour d'expérience sur son utilisation.

6. Références

Reprise des normes et draft cité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.

7. Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...