DNSSEC ou VPN : laquelle cache vos requêtes DNS ?

Deux mécanismes se voient attribuer la même tâche et aucun des deux ne l’accomplit. DNSSEC répond si les données que vous avez reçues proviennent réellement de la zone qui les publie, et un VPN décide du chemin que prennent vos paquets. Ni l’un ni l’autre ne cache dans tous les cas le nom que vous avez demandé, et les réglages qui semblent devoir le faire portent généralement sur le transport ou le routage plutôt que sur la validation. Nommer d’abord la couche transforme une question vague sur la confidentialité en une question précise.

Trois affirmations fusionnées en une

L’authenticité est l’affirmation que la réponse est celle que la zone a publiée et qu’elle n’a pas été modifiée en chemin. La confidentialité est l’affirmation que personne sur le chemin ne peut lire la requête ni la réponse. Le routage est l’affirmation que les paquets suivent un chemin que vous avez choisi, ce qui est exactement ce qu’offre un tunnel.

DNSSEC traite la première et ne dit rien des deux autres. DoT et DoH traitent la seconde pour le saut jusqu’au résolveur. Un VPN traite la troisième et peut aussi affecter la seconde, mais seulement comme effet secondaire de l’endroit où va le trafic.

Le trafic applicatif est un quatrième cas : HTTPS protège et authentifie l’échange web entre votre client et le site, et aucune couche DNS ne le remplace.

Ce que la validation de signature peut et ne peut pas faire

Un résolveur validant vérifie la chaîne de signatures depuis la zone jusqu’à une ancre de confiance configurée, puis renvoie une réponse avec l’indicateur de données authentifiées activé lorsque la vérification réussit. Cet indicateur est une preuve sur les données, pas sur la connexion ni sur les intentions de la destination.

Il ne peut pas empêcher un propriétaire légitime de zone de publier des enregistrements authentiques pour un service auquel vous ne devriez pas faire confiance. Une réponse correctement signée d’un domaine compromis reste correctement signée, et DNSSEC n’a pas d’avis sur la question de savoir si ce domaine mérite vos identifiants.

Il ne cache rien non plus. La requête et la réponse traversent le réseau sous une forme qu’un résolveur et tout observateur sur ce chemin peuvent lire, sauf si une autre couche protège le transport. Une réponse signée et une réponse privée sont des propriétés différentes, et un déploiement peut n’en avoir qu’une seule. Testez les deux si l’une ou l’autre vous importe.

D’où vient réellement la confidentialité

Le transport chiffré vers le résolveur enveloppe l’échange DNS dans TLS, si bien que le résolveur voit toujours la question mais que le chemin entre vous et lui ne la voit pas. Cela déplace la confiance plutôt que de la supprimer : vous faites davantage confiance au résolveur et moins au réseau local.

Un VPN peut transporter les requêtes vers un résolveur de l’autre côté, ce qui change à la fois le chemin et le résolveur qui les voit. C’est une décision de routage avec une conséquence sur la confidentialité, et sur un réseau géré le résolveur interne peut être le seul à pouvoir répondre aux noms internes.

La combinaison que les gens veulent réellement tient généralement en trois choses à la fois : la validation activée, un transport chiffré vers un résolveur qu’ils ont choisi et TLS applicatif sur la destination. Chacune est indépendante, et en omettre une laisse un trou différent.

Vérifiez la validation et le transport séparément

Deux tests règlent l’essentiel de la confusion. Le premier demande si le résolveur a validé la réponse ; le second demande si le transport était protégé. Ils échouent de manières différentes et aucun n’implique l’autre.

Ces commandes affichent les indicateurs d’une requête validante, répètent la requête avec la vérification désactivée et lancent la validation locale avec delv :

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Une réponse avec l’indicateur de données authentifiées et une signature présente montre la validation chez ce résolveur. Un échec de validation avec delv montre une chaîne rompue quelque part entre la zone et l’ancre de confiance, ce qui est un problème de publication et non un problème de tunnel. Un délai d’attente sans aucun indicateur est un problème de transport ou d’accessibilité, et le traiter comme un échec de signature vous envoie à la mauvaise couche.

Que faire quand un VPN casse les résolutions

Si les résolutions fonctionnaient avant le tunnel et s’arrêtent après, comparez le résolveur qu’utilise chaque chemin. Le tunnel divisé, un résolveur interne accessible uniquement par le tunnel et un client qui réécrit les réglages du résolveur changent tous la réponse sans toucher à DNSSEC.

Désactiver la validation globalement est le mauvais premier réflexe, car cela supprime le seul mécanisme qui signale une altération et ne répare pas un résolveur injoignable. Réduisez d’abord la panne : résolution, transport, validation, puis politique. Seule la troisième relève de DNSSEC, et seule la seconde relève du transport chiffré.