Les solutions expérimentales A6 et bitstring labels

Table des matières

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

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, les documents IETF DIS-id et RFC 3901 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. Autrement dit, un client IPv4 et un client IPv6 doivent recevoir la même réponse à la même requête s'il est possible de transporter les requêtes/réponses aussi bien en IPv6 qu'en IPv4. Par ailleurs, en tant qu'application TCP/IP, un serveur DNS 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.

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 immédiatement. En effet, en supposant que le serveur récursif interrogé par le client vient de démarrer, celui-la commence par tenter de transmettre la requête aux seuls serveurs dont il dispose de l'adresse, c'est-à-dire, à ceux de la racine généralement stockée dans le fichier named.root. Sachant qu'aujourd'hui, les adresses des serveurs racine publiées dans le DNS sont toutes en IPv4, la communication avec la racine s'avère impossible. 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é. A noter que le support d'EDNS.0 devient également indispensable en présence des extensions DNSSEC.

L'extension EDNS.0 n'est malheureusement déployée aujourd'hui que dans 20% des plates-formes DNS environ. Même si le support d'EDNS.0 dépasse largement ce pourcentage de 20% dans les logiciels serveurs installés, ce sont les logiciels clients (resolvers) qui sont plutôt en retard. La mise à jour de tous les resolvers DNS installés pour supporter EDNS.0 risque de durer encore de nombreuses années.

Ce faible taux de pénétration est 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. En effet, en attendant que EDNS.0 soit largement déployé, l'IANA ne publie aujourd'hui dans le fichier de zone racine (named.root dans les distributions BIND) que 13 adresses IPv4 de la racine et aucune adresse IPv6 et ce, afin de ne pas dépasser la limite des 512 octets susmentionnée.

Notons que certains serveurs de la racine (B, F, H et M par exemple) supportent déjà le transport IPv6. Même si leurs adresses IPv6 ne sont pas publiées dans le fichier de zone racine, pour les raisons que nous venons d'évoquer, ces informations sont accessibles sur le site web : http://www.root-servers.org/ .

Glue IPv6

La zone racine publie également les adresses (IPv4 seulement) 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 lequel 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.

Afin de favoriser le plus possible le support d'IPv6 dans le processus de résolution DNS et à défaut de pouvoir atteindre la racine en IPv6 (première phase), la communauté DNS (TLD, RIR, et d'autres experts) a souhaité favoriser le support d'IPv6, là où cela serait possible, dans toutes les phases ultérieures.

Pour commencer, la présence de la glue IPv6 des TLD administrant des serveurs DNS avec support d'IPv6 s'est avérée nécessaire. Là encore, l'argument de la limite des 512 octets a été invoqué pour justifier le fait que seules les adresses IPv4 pouvaient être publiées dans la zone racine. Toutefois, suite aux longs débats qui ont eu lieu durant des années entre la communauté DNS et l'IANA/ICANN, ces derniers ont été enfin convaincus que la publication des glues IPv6 des serveurs DNS de TLD supportant IPv6 peut se faire sans risque pour la stabilité du DNS. On peut se référer à cet effet aux documents en ligne. 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.kame.net/. 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 supporterIPv6. 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émentation, certains clients réessaient d'autres adresses IPv6 s'il y en a ou passer 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é 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 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.

Les solutions expérimentales A6 et bitstring labels

Table des matières

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