Votre secours DNS VPN : où va vraiment la requête

Un réglage de résolveur bascule de l'adresse privée vers une adresse publique, et la conclusion tombe aussitôt : le tunnel fuit. Parfois c'est vrai. Souvent, la requête de secours a quand même voyagé à l'intérieur du tunnel vers un résolveur choisi par l'administrateur, ce qui en fait une décision de politique et non un défaut. Distinguer ces cas demande trois faits plutôt qu'un, et le premier est de savoir qui a répondu. Déterminez qui a reçu la requête, quelle route l'a portée et quels noms ont été demandés.

Le secours est une politique, pas un comportement unique

Chaque client doit décider quoi faire lorsque le résolveur préféré cesse de répondre. Il peut bloquer la résolution, réessayer, utiliser une alternative configurée ou s'en remettre au système d'exploitation, et du point de vue de la vie privée ce sont quatre produits différents. Lire l'écran de réglages indique quel comportement est configuré ; cela n'indique pas lequel s'est produit. Un écran qui propose un seul interrupteur ne décrit pas quatre possibilités.

Les navigateurs ajoutent leur propre couche. Un navigateur avec le DNS sécurisé activé peut résoudre un nom via le fournisseur qu'il a lui-même choisi même lorsque le système d'exploitation pointe ailleurs, ce qui signifie que la politique du client tunnel peut n'être jamais consultée pour les requêtes qui vous importent vraiment. Vérifiez l'application qui a fait la requête, pas seulement le réglage du système.

L'identité du résolveur de remplacement est le premier fait qu'il vaut la peine d'établir. Un résolveur public appartenant à un fournisseur auquel vous faites déjà confiance est une situation différente d'une adresse fournie par le réseau sur lequel vous vous trouvez. L'adresse elle-même dit rarement auquel des deux vous avez affaire.

Qui reçoit la requête après le basculement

Le destinataire et la route sont indépendants, et seule leur combinaison décrit l'exposition. Un résolveur public atteint par le tunnel ne voit jamais l'adresse de votre réseau d'accès, tandis que le même résolveur atteint directement la voit. Les deux cas produisent une réponse, et un test de fuite qui ne rapporte que l'adresse du résolveur les décrira de façon identique. Demandez l'interface en plus de l'adresse lorsque vous lisez le résultat.

Les noms internes rendent la distinction concrète. Un résolveur public ne peut généralement pas répondre à un nom en split-horizon, si bien que la requête échoue alors que le nom a tout de même été divulgué à une partie qui n'avait aucune raison de le voir. Disponibilité et confidentialité vont donc ici de pair au lieu de s'arbitrer.

Un tunnel peut aussi porter la requête vers un résolveur qui n'est pas exploité par le fournisseur VPN, car le tunnel transmet au lieu de résoudre. L'hôte qui transmet voit la requête en clair puis ouvre sa propre connexion plus loin, ce qui protège le saut suivant sans protéger le premier.

Vérifiez la route et le destinataire ensemble

Observez les paquets plutôt que la configuration. Demandez au système quel résolveur serait utilisé, puis confirmez que la requête est bien partie de l'interface attendue vers l'adresse attendue.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Si la capture montre la requête quittant l'interface physique alors que le tunnel est actif, le secours a contourné le tunnel quoi qu'en dise la liste des résolveurs. S'il apparaît sur l'interface du tunnel, la question devient de savoir qui exploite l'extrémité distante et ce qu'elle conserve.

Répétez le contrôle pour un nom interne et un nom public. La requête interne est là où une configuration de secours se révèle généralement, car un résolveur qui ne peut pas répondre reçoit quand même la question.

Décidez si le secours doit être autorisé

Si l'exigence est que la résolution s'arrête lorsque le résolveur préféré est indisponible, configurez une politique d'application qui échoue en mode fermé et acceptez la conséquence : les noms ne seront pas résolus pendant une panne. C'est un arbitrage délibéré de disponibilité et non un dysfonctionnement, et la conception devrait le dire avant que la panne ne survienne.

Si l'exigence est seulement que les requêtes ne sortent pas du tunnel, un résolveur public atteint par le tunnel peut être acceptable à condition que l'opérateur et sa politique de conservation soient compris. Cette acceptation est un jugement sur un tiers et non une affirmation sur la cryptographie, et elle appartient à celui qui porte l'allégation de confidentialité. Si les noms internes doivent continuer de fonctionner, le secours doit être un résolveur qui détient les zones internes, ce qui signifie généralement que la cible de secours est un autre serveur et non une autre famille d'adresses.

Documentez le résultat sous forme d'une phrase sur le comportement : quel résolveur reçoit les requêtes en fonctionnement normal, lequel les reçoit après une panne, et si les noms internes se résolvent dans le second cas. Un test de fuite qui finit par charger une page prouve moins que cette phrase, car une page peut se charger via un résolveur qui n'aurait jamais dû être consulté.