Recommandations opérationnelles pour l'intégration d'IPv6 - Revision history

Mohsen Souissi: /* Publication des enregistrements AAAA dans le DNS */

2008-07-04T15:04:28Z

‎Publication des enregistrements AAAA dans le DNS

Mohsen Souissi: /* Taille limitée des messages DNS en UDP */

2008-07-04T14:55:19Z

‎Taille limitée des messages DNS en UDP

Mohsen Souissi: /* Glue IPv6 */

2008-07-04T14:53:44Z

‎Glue IPv6

Mohsen Souissi: /* Taille limitée des messages DNS en UDP */

2008-07-04T14:42:28Z

‎Taille limitée des messages DNS en UDP

Mohsen Souissi: /* Continuité du service DNS */

2008-07-04T14:13:44Z

‎Continuité du service DNS

Mohsen Souissi: /* Les deux aspects du DNS */

2008-07-04T13:22:38Z

‎Les deux aspects du DNS

Mohsen Souissi at 22:33, 25 October 2007

2007-10-25T22:33:15Z

Bruno Stévant at 22:54, 7 February 2006

2006-02-07T22:54:45Z

Bruno Stévant at 22:39, 30 January 2006

2006-01-30T22:39:35Z

Laurent Toutain: /* Publication des enregistrements AAAA dans le DNS */

2005-11-21T17:12:51Z

‎Publication des enregistrements AAAA dans le DNS

@@ Line 51: / Line 51: @@
 * une adresse IPv6 est publiée dans le DNS pour <tt>foo.example.com</tt> ;
 * un client ftp supportant IPv6 tente de se connecter au serveur s'exécutant sur <tt>foo.example.com</tt>. Le client sélectionne alors l'adresse IPv6 de <tt>foo.example.com</tt> 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.
+* 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 <tt>www.example.com</tt> et <tt>ns.example.com</tt> avec adresses IPv6 (et IPv4 éventuellement) et d'autre part, les noms <tt>ftp.example.com</tt> et <tt>mail.example.com</tt> avec des adresses IPv4 uniquement. L'enregistrement <tt>AAAA</tt> pour <tt>foo.example.com</tt> 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|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.
+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|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.
 {{suivi|Les solutions expérimentales A6 et bitstring labels|Les solutions expérimentales A6 et bitstring labels|Découverte de la liste de serveurs DNS récursifs|Découverte de la liste de serveurs DNS récursifs}}

@@ Line 32: / Line 32: @@
 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'[http://www.iana.org IANA] publie dans la zone racine l'adresse IPv6 (glue AAAA) des serveurs racine supportant le transport IPv6 et la nouvelle version du fichier de de démarrage (typiquement <tt>named.root</tt> pour BIND 9) contient également ces adresses.
+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'[http://www.iana.org 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 <tt>named.root</tt> 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/ .

@@ Line 38: / Line 38: @@
 == 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.
+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 yy répondre en IPv6, les TLD ont oeuvré 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. On peut se référer à cet effet aux [http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf 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 <tt>.fr</tt>, <tt>.jp</tt> et <tt>.kr</tt> ont vu les premiers leur glue IPv6 publiée.
+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 <tt>.fr</tt>, <tt>.jp</tt> et <tt>.kr</tt> ont vu les premiers leur glue IPv6 publiée.
 == Publication des enregistrements AAAA dans le DNS ==

@@ Line 28: / Line 28: @@
 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 <tt>TC</tt> (''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 <tt>AAAA</tt>) 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 <tt>.com</tt>, <tt>.net</tt>, <tt>.fr</tt>, <tt>.de</tt>, ...
+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 <tt>AAAA</tt>) 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 <tt>answer</tt>, <tt>authority</tt> et <tt>additional</tt>, 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 <tt>.com</tt>, <tt>.net</tt>, <tt>.fr</tt>, <tt>.de</tt>...
-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.
+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. En effet, en attendant que EDNS.0 soit largement déployé, l'IANA ne publie aujourd'hui dans le fichier de zone racine (<tt>named.root</tt> 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.
+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'[http://www.iana.org IANA] publie dans la zone racine l'adresse IPv6 (glue AAAA) des serveurs racine supportant le transport IPv6 et la nouvelle version du fichier de de démarrage (typiquement <tt>named.root</tt> pour BIND 9) contient également ces adresses.
-Notons que certains serveurs de la racine (<tt>B</tt>, <tt>F</tt>, <tt>H</tt> et <tt>M</tt> 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, ces informations sont accessibles sur le site web : http://www.root-servers.org/ .
+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 ==

@@ Line 12: / Line 12: @@
 * 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-là 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 <tt>forwarder</tt> en double pile IPv4/IPv6.
+* 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 <tt>forwarder</tt> en double pile IPv4/IPv6.
 Par exemple, pour une distribution BIND, il suffit d'ajouter l'option :

@@ Line 5: / Line 5: @@
 ==Les deux aspects du DNS==
-En tant que base de données, le DNS supporte les enregistrements <tt>A</tt> et <tt>AAAA</tt> 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.
+En tant que base de données, le DNS supporte les enregistrements <tt>A</tt> et <tt>AAAA</tt> 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==

← Older revision		Revision as of 22:54, 7 February 2006
Line 1:		Line 1:
	{{suivi\|Les solutions expérimentales A6 et bitstring labels\|Les solutions expérimentales A6 et bitstring labels\|Découverte de la liste de serveurs DNS récursifs\|Découverte de la liste de serveurs DNS récursifs}}		{{suivi\|Les solutions expérimentales A6 et bitstring labels\|Les solutions expérimentales A6 et bitstring labels\|Découverte de la liste de serveurs DNS récursifs\|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 [[Bibliographie#DIS-id\|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.		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 [[Bibliographie#DIS-id\|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.

← Older revision		Revision as of 22:39, 30 January 2006
Line 1:		Line 1:
		+	{{suivi\|Les solutions expérimentales A6 et bitstring labels\|Les solutions expérimentales A6 et bitstring labels\|Découverte de la liste de serveurs DNS récursifs\|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 [[Bibliographie#DIS-id\|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.		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 [[Bibliographie#DIS-id\|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.

Line 57:		Line 58:

	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\|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.		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\|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.
		+	{{suivi\|Les solutions expérimentales A6 et bitstring labels\|Les solutions expérimentales A6 et bitstring labels\|Découverte de la liste de serveurs DNS récursifs\|Découverte de la liste de serveurs DNS récursifs}}

@@ Line 46: / Line 46: @@
 == Publication des enregistrements AAAA dans le DNS ==
-On choisit généralement de publier dans le DNS le (ou les) enregistrement(s) <tt>AAAA</tt> 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 <tt><nowiki>http://www.kame.net/</nowiki><tt>. 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 :
+On choisit généralement de publier dans le DNS le (ou les) enregistrement(s) <tt>AAAA</tt> 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 <tt><nowiki>http://www.kame.net/</nowiki></tt>. 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 <tt>foo.example.com</tt> héberge plusieurs services : web, ftp, mail, dns ;