Le DNS chiffré cache-t-il les sites que je visite ?

Il cache la résolution, pas la connexion. Une fois le nom résolu, votre appareil se connecte quand même à l'adresse IP du serveur, et le nom du serveur est le plus souvent visible dans la négociation TLS : un observateur du réseau peut donc souvent identifier le site malgré tout.

Pourquoi les pages de test de fuite donnent-elles des réponses différentes ?

Parce qu'elles ne mesurent pas la même chose. Certaines indiquent le résolveur qui les a contactées, d'autres tous les résolveurs d'une rotation, et le DNS chiffré du navigateur peut donner un résultat différent d'un test en ligne de commande sur la même machine.

Voir plusieurs résolveurs listés, est-ce automatiquement une fuite ?

Non. Plusieurs entrées sont normales sur une machine multi-connectée. Cela devient une fuite quand l'une d'elles appartient à un réseau que vous vouliez exclure, parce que les requêtes partent en général vers celui qui répond le premier.

Fuites DNS : ce que c'est et comment les vérifier

Une fuite DNS se produit quand votre appareil envoie ses résolutions de noms de domaine à un résolveur que vous n'aviez pas choisi, en général celui de votre fournisseur d'accès, révélant chaque site que vous vous apprêtez à visiter. Vérifier, c'est confirmer quel résolveur répond réellement à vos requêtes, au niveau du système, du navigateur et du réseau.

Chaque fois que vous ouvrez un site, votre appareil demande à un résolveur de transformer le nom de domaine en adresse IP. Cette question est un relevé en clair de l'endroit où vous allez, et par défaut elle part vers le résolveur que votre réseau vous a attribué — normalement celui de votre fournisseur d'accès.

Une fuite DNS, c'est quand ces requêtes partent quelque part où vous ne les vouliez pas. Le cas habituel : un appareil configuré pour utiliser un résolveur privé ou chiffré qui, pour l'une de plusieurs raisons structurelles, continue d'envoyer tout ou partie des résolutions au FAI. Rien ne casse visiblement, et c'est pour ça que des fuites durent des années sans être remarquées.

Qu'est-ce que le DNS expose vraiment ?

Le domaine, l'horodatage et la source — de quoi reconstituer une session de navigation.

Le DNS classique circule en clair sur le port 53. Quiconque se trouve entre vous et le résolveur peut lire la requête, et le résolveur lui-même les voit toutes, attribuées à votre connexion. Il ne voit pas la page précise, mais c'est généralement le domaine qui est la partie sensible.

Le chiffrement change qui détient ce relevé, pas le fait qu'il existe :

Transport	Chiffré ?	Qui voit la requête
DNS en clair (port 53)	Non	Votre réseau, votre FAI, le résolveur
DNS over TLS (DoT, port 853)	Oui	Le résolveur que vous avez choisi
DNS over HTTPS (DoH, port 443)	Oui	Le résolveur que vous avez choisi ; plus difficile à distinguer du trafic web pour le réseau
DNSSEC	Non — il authentifie	Comme le DNS en clair ; il prouve que les réponses sont authentiques, il ne les cache pas

DNSSEC est l'entrée la plus souvent mal comprise. Il signe les réponses pour qu'elles ne puissent pas être falsifiées. Il n'apporte strictement aucune confidentialité.

Comment les fuites se produisent-elles concrètement ?

Six causes structurelles couvrent la quasi-totalité des cas.

Cause	Mécanisme
Routage partagé	Une partie du trafic passe par un tunnel, le DNS emprunte l'interface par défaut
IPv6 non pris en charge	Le tunnel ne gère que l'IPv4, les résolutions IPv6 passent donc par le FAI
Résolution parallèle de l'OS	Windows peut interroger toutes les interfaces à la fois et retenir la première réponse
DoH au niveau du navigateur	Le navigateur résout indépendamment du réglage système, dans un sens comme dans l'autre
Réglage imposé par la box	La box impose son propre résolveur via DHCP ou intercepte le port 53
Portail captif	Les réseaux d'hôtel ou d'aéroport détournent le DNS pour imposer leur page de connexion

Le cas du navigateur mérite d'être détaillé, parce qu'il joue dans les deux sens. Un navigateur avec son propre réglage DoH peut contourner un résolveur système soigneusement configuré ; et à l'inverse, un navigateur bien configuré peut masquer le fait que tout ce qui se passe en dehors de lui fuit toujours. Tester l'un et supposer l'autre est l'erreur de test la plus courante.

Comment vérifier ?

Testez chaque couche séparément, parce qu'elles peuvent se contredire.

Système d'exploitation — quels résolveurs sont configurés :

Système	Commande
macOS	`scutil --dns \| grep nameserver`
Windows	`Get-DnsClientServerAddress`
Linux (systemd-resolved)	`resolvectl status`
Linux (générique)	`cat /etc/resolv.conf`

Quel résolveur a réellement répondu — la configuration et le comportement ne coïncident pas toujours :

dig +short whoami.akamai.net renvoie l'adresse IP du résolveur qui a effectué la résolution pour vous. Comparez-la au résolveur que vous attendiez.

Au niveau du navigateur : ouvrez le réglage de DNS sécurisé du navigateur et notez s'il est activé et quel fournisseur est sélectionné. Chargez ensuite une page de test de fuite DNS dans ce navigateur. Si elle annonce un résolveur différent de celui de votre test en ligne de commande, c'est que le navigateur résout de son côté.

IPv6 : refaites le test avec une requête uniquement en IPv6. Un tunnel qui ne transporte que l'IPv4 est de loin la cause la plus fréquente de fuite partielle.

Comment lire le résultat ?

Comparez le propriétaire du résolveur à ce que vous attendiez, pas à une liste de « bonnes » adresses.

Observation	Interprétation
Le résolveur appartient à votre FAI alors que vous en aviez configuré un autre	Fuite
Plusieurs résolveurs, dont celui de votre FAI	Fuite partielle — les requêtes sont réparties
L'IPv4 montre le résolveur attendu, l'IPv6 montre le FAI	Fuite IPv6
Le navigateur et le système annoncent des résolveurs différents	Pas forcément une fuite, mais deux chemins indépendants à vérifier
Le résolveur est dans un pays inattendu	Souvent normal — les résolveurs anycast répondent depuis le site le plus proche
Le résolveur est l'adresse privée de la box	Non concluant ; la box relaie en amont, vérifiez donc son propre réglage

C'est la dernière ligne qui piège les gens sur un réseau domestique. Un résultat à 192.168.1.1 vous dit seulement que votre box a répondu. Vers qui elle relaie est une autre question, à laquelle répondent ses réglages WAN ou DNS.

Quelles sont les limites d'une correction ?

Corriger une fuite DNS change qui apprend quels domaines vous avez consultés. Cela ne rend pas la visite privée, et exagérer ce point est la principale façon dont le sujet est déformé.

Une fois le nom résolu, votre appareil ouvre une connexion vers cette adresse IP. N'importe quel observateur sur le trajet voit l'adresse de destination et, dans la plupart des connexions TLS, le nom du serveur transite en clair dans la négociation, sauf si Encrypted Client Hello est actif des deux côtés. Les deux signaux identifient le site indépendamment du DNS.

Le résumé honnête est donc étroit mais réel : un DNS chiffré vers un résolveur de votre choix retire de votre réseau local et des journaux de votre FAI la liste en clair de tous les domaines que vous visitez, et transfère cette liste à l'opérateur du résolveur. Il déplace la confiance au lieu de la supprimer — ce qui fait de l'identité de celui qui exploite le résolveur, et de ce qu'il journalise, la seule question qui compte vraiment.