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

Les solutions expérimentales A6 et bitstring labels

Table des matières

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