Pourquoi les réponses DNS64 changent-elles dès que le VPN se connecte ?

Les réponses DNS64 décrivent un agencement réseau et non une propriété du serveur. Le résolveur synthétise une adresse IPv6 à partir d'une adresse IPv4, et le résultat ne fonctionne que là où un traducteur se trouve au bout de ce préfixe. Faites entrer un VPN dans le chemin et cet agencement peut tenir, changer ou cesser d'être vrai selon trois conditions.

Ces conditions sont le résolveur qui a répondu, la route que votre appareil possède vers le préfixe synthétisé et le fait que quelque chose sur cette route effectue la traduction. Chacune est observable, et c'est ce qui rend la panne diagnosticable.

Sur quoi pointe réellement un enregistrement AAAA synthétisé

Un résolveur DNS64 répond à une requête AAAA pour un nom purement IPv4 en intégrant l'adresse IPv4 dans un préfixe qu'il est configuré à utiliser, et le préfixe bien connu pour cette tâche est 64:ff9b::/96 comme décrit dans RFC 6147. L'enregistrement apparaît à l'application comme n'importe quel autre enregistrement AAAA, et c'est bien le but : un client purement IPv6 peut tenter une connexion sans savoir que la destination n'a jamais eu d'IPv6. Cette connexion dépend ensuite d'une fonction NAT64 qui traduit entre les deux familles quelque part sur le chemin. Sans ce traducteur, l'adresse synthétisée est une destination d'apparence plausible qui ne mène nulle part.

L'enregistrement encode donc deux choses à la fois : l'adresse IPv4 d'origine et l'hypothèse qu'un traducteur est joignable. Seule la première est visible dans la réponse elle-même.

Trois conditions décident si cela fonctionne encore

La première condition est le résolveur qui a produit l'enregistrement, car celui sans DNS64 configuré ne renvoie rien pour ce nom et l'application échoue autrement. La deuxième est de savoir si votre appareil a une route vers le préfixe synthétisé, car une réponse peut être valide alors que le chemin vers elle manque. La troisième est de savoir si le traducteur qui possède ce préfixe se trouve sur le chemin que vous utiliseriez, car un tunnel transportant 64:ff9b::/96 ailleurs atteint une autre fonction ou rien du tout. Les trois peuvent tenir avant le tunnel et échouer après, et c'est pourquoi le symptôme ressemble à une régression soudaine.

Vérifiez-les dans cet ordre. Une réponse absente et une route absente se ressemblent dans un navigateur et diffèrent totalement dans un journal de résolveur.

Quand le résolveur change, la réponse change

Un client VPN impose souvent son propre résolveur ou prend en charge tout le chemin de la requête, et ce résolveur peut ne rien synthétiser. Les requêtes pour des noms purement IPv4 ne renvoient alors aucun enregistrement AAAA, ce qu'un client purement IPv6 vit comme un nom qu'il ne peut pas atteindre. L'inverse se produit aussi : un résolveur qui synthétise vraiment peut vous fournir un préfixe que votre chemin tunnelisé ne transporte pas.

La mise en cache rend cela plus difficile à voir. Un enregistrement synthétisé obtenu sur le réseau du bureau peut survivre au contexte qui l'a produit, si bien que le client continue de se connecter à une adresse dont le traducteur n'est plus joignable. Regardez le résolveur qui répond maintenant plutôt que celui qui a répondu au moment où l'entrée a été enregistrée. Vider le cache sans noter l'ancienne et la nouvelle réponse détruit la preuve dont vous avez besoin.

Testez la requête et le chemin séparément

Interrogez le nom directement avant d'impliquer l'application, et notez quel serveur a répondu. Les commandes ci-dessous montrent l'enregistrement AAAA, le résolveur utilisé et l'existence d'une route vers le préfixe synthétisé. Exécutez-les avec le tunnel coupé puis de nouveau avec le tunnel monté.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Lisez les résultats comme une chaîne. Un enregistrement AAAA absent signifie que le résolveur devant vous ne synthétise pas, donc un chemin purement IPv6 ne fonctionnera pas pour ce nom quoi que fasse le client. Un enregistrement présent sans route signifie que le préfixe n'est pas transporté par le chemin actuel, et c'est une décision de routage et non une panne du résolveur. Une route présente alors que la requête échoue encore désigne le traducteur lui-même, et cela appartient à un autre propriétaire.

Notez le résolveur, le contexte réseau et la famille d'adresses à côté de chaque résultat. C'est cette note qui permet à la comparaison suivante de séparer un changement de résolveur d'un changement de routage.