3. Traitement des Requêtes de Résolution de Noms d'Hôtes (Hostname Resolution Query Handling)
Lorsqu'un client dispose à la fois d'une connectivité IPv4 et IPv6 et tente d'établir une connexion avec un hôte nommé, il doit envoyer à la fois des requêtes DNS AAAA et A. Les deux requêtes SHOULD être effectuées aussi rapidement que possible l'une après l'autre, la requête AAAA étant effectuée en premier et immédiatement suivie de la requête A.
Les implémentations SHOULD NOT attendre que les réponses des deux familles d'adresses soient retournées avant de tenter l'établissement de la connexion. Si une requête ne parvient pas à retourner ou prend beaucoup plus de temps à retourner, attendre la deuxième famille d'adresses peut retarder considérablement l'établissement de la connexion de la première. Par conséquent, le client SHOULD traiter la résolution DNS comme asynchrone. Notez que si la plateforme n'offre pas d'API DNS asynchrone, ce comportement peut être simulé en effectuant deux requêtes synchrones séparées sur des threads différents, une par famille d'adresses.
L'algorithme se déroule comme suit: si une réponse AAAA positive (une réponse avec au moins un enregistrement AAAA valide) est reçue en premier, la première tentative de connexion IPv6 est immédiatement démarrée. Si une réponse A positive est reçue en premier en raison d'une réorganisation, le client SHOULD attendre un court instant pour la réponse AAAA afin de s'assurer que la préférence est donnée à IPv6 (il est courant que la réponse AAAA suive la réponse A de quelques millisecondes). Ce délai sera appelé "Resolution Delay" (Délai de Résolution). La valeur recommandée pour le délai de résolution est de 50 millisecondes. Si une réponse AAAA positive est reçue dans la période du délai de résolution, le client démarre immédiatement la tentative de connexion IPv6. Si une réponse AAAA négative (aucune erreur, aucune donnée) est reçue dans la période du délai de résolution ou si la réponse AAAA n'a pas été reçue à la fin de la période du délai de résolution, le client SHOULD procéder au tri des adresses (voir Section 4) et aux tentatives de connexion échelonnées (voir Section 5) en utilisant toutes les adresses IPv4 retournées jusqu'à présent. Si la réponse AAAA arrive alors que ces tentatives de connexion sont en cours mais avant qu'une connexion n'ait été établie, alors les adresses IPv6 nouvellement reçues sont incorporées dans la liste des adresses candidates disponibles (voir Section 6) et le processus de tentatives de connexion se poursuivra avec les adresses IPv6 ajoutées, jusqu'à ce qu'une connexion soit établie.
3.1. Gestion de Plusieurs Adresses de Serveurs DNS (Handling Multiple DNS Server Addresses)
Si plusieurs adresses de serveurs DNS sont configurées pour le réseau actuel, le client peut avoir l'option d'envoyer ses requêtes DNS via IPv4 ou IPv6. Conformément à l'approche Happy Eyeballs, les requêtes SHOULD être envoyées d'abord via IPv6 (notez que cela ne fait pas référence à l'envoi de requêtes AAAA ou A, mais plutôt à l'adresse du serveur DNS lui-même et à la version IP utilisée pour transporter les messages DNS). Si les requêtes DNS envoyées à l'adresse IPv6 ne reçoivent pas de réponses, cette adresse peut être marquée comme pénalisée et les requêtes peuvent être envoyées à d'autres adresses de serveurs DNS.
À mesure que les déploiements IPv6 natifs deviennent plus répandus et que les adresses IPv4 sont épuisées, on s'attend à ce que la connectivité IPv6 bénéficie d'un traitement préférentiel au sein des réseaux. Si un serveur DNS est configuré pour être accessible via IPv6, IPv6 devrait être supposé être la famille d'adresses préférée.
Les systèmes clients SHOULD NOT avoir de limite explicite au nombre de serveurs DNS qui peuvent être configurés, que ce soit manuellement ou par le réseau. Si une telle limite est requise par des limitations matérielles, le client SHOULD utiliser au moins une adresse de chaque famille d'adresses de la liste disponible.