DNS Cache Snooping : sondage de cache, analyse temporelle et résolveurs isolés

Même lorsque les flux applicatifs transitent par des protocoles chiffrés récents tels que TLS 1.3 et HTTPS, la phase de résolution de noms expose fréquemment les activités numériques des utilisateurs. Les entreprises et les réseaux domestiques s'appuient régulièrement sur des résolveurs DNS récursifs partagés fournis par les fournisseurs d'accès à Internet (FAI), des prestataires publics ou les routeurs locaux. Si ce mécanisme accélère le chargement des pages en conservant en mémoire vive les adresses IP déjà résolues, l'état de ce cache partagé ouvre un canal auxiliaire de surveillance redoutable : le DNS Cache Snooping (espionnage du cache DNS).

En transmettant des requêtes non récursives ciblées à un résolveur partagé ou en observant les infimes variations du temps d'aller-retour (RTT), un tiers externe ou un attaquant local peut déterminer avec précision quels noms de domaine ont été récemment consultés par les autres utilisateurs connectés au même résolveur. Cette technique ne requiert aucun positionnement d'interception de type Man-in-the-Middle, aucun logiciel malveillant sur les postes cibles et aucun déchiffrement des communications protégées.

Comprendre les rouages du DNS Cache Snooping est indispensable pour les administrateurs réseau veillant à la sécurité de leur infrastructure et pour les utilisateurs exigeant une étanchéité absolue de leurs données. L'association d'un résolveur récursif dédié et d'un tunnel VPN de niveau 3 doté d'une authentification cryptographique supprime définitivement ce risque.

Le paradoxe de la confidentialité DNS : pourquoi le chiffrement du transit laisse les résolveurs vulnérables

Les standards contemporains de sécurité se concentrent principalement sur le chiffrement des données en transit. HTTPS protège les en-têtes et les contenus applicatifs, tandis que le DNS sur HTTPS (DoH, RFC 8484) et le DNS sur TLS (DoT, RFC 7858) chiffrent les échanges entre le client local et le résolveur. Cependant, le chiffrement du canal de communication ne modifie en rien la façon dont les résolveurs récursifs conservent les enregistrements dans leur mémoire vive.

Un résolveur récursif maintient un cache en mémoire vive pour les enregistrements (A, AAAA, CNAME, TXT) afin d'alléger la sollicitation des serveurs d'autorité mondiaux et de réduire le temps de réponse pour les requêtes futures. Lorsqu'un utilisateur demande la résolution de portal.example.org, le résolveur interroge les serveurs faisant autorité, délivre la réponse au client et conserve la trace de l'enregistrement jusqu'à l'expiration du compteur de durée de vie (TTL) :

[ Poste client ] --------> Requête : example.org ---------> [ Résolveur partagé ]
                                                                  |
                                                     (Défaut de cache : Appel amont)
                                                                  |
                                                                  v
                                                      [ Serveur d'autorité DNS ]
                                                                  |
[ Poste client ] <-------- Réponse (TTL = 300 s) <--------- [ Résolveur partagé ]
                                                       (Présent en RAM : 300 s)

Si un observateur malveillant dispose également d'un accès à ce résolveur partagé, il lui suffit d'émettre une requête pour ce même domaine quelques instants plus tard. Si le résolveur renvoie immédiatement une réponse affichant une valeur TTL décrémentée (par exemple 242 secondes), l'observateur en déduit avec une certitude mathématique qu'un utilisateur du réseau a consulté example.org environ 58 secondes plus tôt.

Vous pouvez vérifier mon adresse IP et mes fuites réseau afin de mesurer l'exposition de votre passerelle publique et d'identifier vos serveurs DNS actuels.

Anatomie du DNS Cache Snooping : sondage non récursif et décompte TTL

L'espionnage de cache DNS s'appuie sur deux méthodes principales : l'interrogation directe par requête non récursive et l'analyse différentielle du temps de réponse. Ces deux techniques exploitent la mémoire volatile du résolveur.

Mécanique des requêtes non récursives : le bit RD et l'interrogation du cache

L'en-tête du protocole DNS intègre un indicateur crucial nommé Recursion Desired (RD), spécifié dans les RFC 1034 et RFC 1035. Lorsque ce bit vaut 1, le client demande au serveur de mener une résolution complète si la donnée est absente de sa mémoire locale. En revanche, lorsque le bit RD est positionné à 0, le client intime l'ordre au résolveur de ne retourner que les informations déjà stockées dans son cache interne :

+-------------------------------------------------------------------------+
|                                En-tête DNS                              |
+------------------+------------------+-----------------+-----------------+
|      ID (16)     | QR | Opcode (4)  | AA | TC | RD(0) | RA | Z | RCODE(4)|
+------------------+------------------+-----------------+-----------------+

Lorsqu'un attaquant soumet une requête avec le drapeau RD = 0 :

1. Présence en mémoire (Cache Hit) : Si un utilisateur légitime a consulté le domaine récemment, le résolveur retourne immédiatement la section Answer contenant l'enregistrement avec son TTL résiduel.
2. Absence en mémoire (Cache Miss) : Si le domaine n'a pas été sollicité, le résolveur ne déclenche aucune recherche amont et renvoie soit une section Answer vide, soit la liste des serveurs racines dans la section Authority, soit un code d'erreur SERVFAIL ou REFUSED.

Ce comportement binaire confirme sans ambiguïté les visites préalables vers la ressource ciblée.

Analyse temporelle : mesure des variations RTT pour identifier les domaines en mémoire

Certains administrateurs configurent leurs résolveurs pour rejeter systématiquement les requêtes ayant le bit RD = 0 provenant de réseaux non autorisés. Pour déjouer cette restriction, les attaquants émettent des requêtes récursives ordinaires (RD = 1) en chronométrant le délai aller-retour (RTT) :

+-----------------------+------------------------+------------------------+
| État de l'enregistrement | Temps RTT typique   | Cause physique         |
+-----------------------+------------------------+------------------------+
| En mémoire vive (Hit) | 1 ms - 5 ms            | Extraction mémoire RAM |
| Absent du cache (Miss)| 45 ms - 250 ms         | Requête amont Internet |
+-----------------------+------------------------+------------------------+

Comme l'interrogation d'un nouveau domaine requiert une traversée multi-sauts auprès des serveurs racines, des serveurs de premier niveau (TLD) et des serveurs d'autorité finaux, le différentiel de latence représente un écart d'un ordre de grandeur. L'envoi automatisé d'une liste de domaines cibles permet ainsi de reconstituer le profil d'activité du réseau analysé.

Surveillance et reconnaissance réseau : ce que révèle l'espionnage de cache

Le sondage de cache DNS livre des données sensibles aux observateurs hostiles :

1. Reconnaissance ciblée pour l'ingénierie sociale (Spear-Phishing) : Les attaquants interrogent le résolveur pour détecter l'usage d'outils professionnels internes (comme Jira, Workday, des consoles cloud ou des plateformes bancaires). Connaître les services effectivement déployés permet de forger des leurres convaincants aux couleurs de ces applications.
2. Détection des enquêtes de sécurité : Lors de l'investigation sur un logiciel malveillant, les analystes de sécurité effectuent des requêtes vers les domaines de commande et contrôle (C2). Un adversaire qui surveille le résolveur d'entreprise voit ses domaines émerger dans le cache, ce qui l'avertit de la détection de son opération et lui permet d'effacer ses traces prématurément.
3. Profilage comportemental des utilisateurs : Sur un point d'accès Wi-Fi ouvert ou un réseau partagé, l'inspection des domaines liés à la santé, aux conseils juridiques ou aux investissements permet d'établir les habitudes personnelles des personnes connectées.
4. Calcul précis de l'horodatage via le TTL : Les enregistrements DNS disposant d'un TTL nominal défini par l'autorité d'origine (par exemple 3600 secondes), soustraire le TTL restant du TTL d'origine révèle le nombre exact de secondes écoulées depuis la consultation initiale :

$$ ext{Temps écoulé} = ext{TTL initial} - ext{TTL retourné}$$

Comparaison des vecteurs d'attaque : Cache Snooping, écoute passive et empoisonnement Kaminsky

Les menaces ciblant le système DNS interviennent à différents niveaux de la pile protocolaire :

Contrairement aux agressions actives examinées dans notre dossier sur l'empoisonnement de cache DNS et les attaques Kaminsky, le Cache Snooping ne corrompt aucune donnée : il détourne une fonctionnalité légitime du serveur à des fins d'espionnage passif.

Risques de configuration : récursion ouverte et faiblesses des listes de contrôle d'accès

Le principal facteur favorisant l'espionnage de cache à grande échelle réside dans la présence de résolveurs ouverts (Open Resolvers). Ces équipements acceptent et traitent les requêtes émanant de n'importe quelle adresse IP sur Internet sans filtrage d'origine.

Les observations mondiales révèlent que des millions de passerelles grand public et de résolveurs d'entreprise laissent le port 53 exposé sur leur interface WAN. Associé aux réglages par défaut autorisant les requêtes non récursives, cet état permet à un tiers distant d'auditer l'historique des machines situées derrière ce périmètre.

Même lorsque la récursion externe est désactivée, l'ensemble des équipements d'un réseau local d'entreprise ou d'une borne Wi-Fi partagent la même mémoire de cache, permettant à des appareils non fiables d'espionner leurs voisins.

Durcissement du résolveur : stratégies de segmentation du cache sur BIND et Unbound

Pour neutraliser le DNS Cache Snooping, l'administrateur doit restreindre les autorisations de requêtes, refuser les sondes non récursives extérieures et isoler les espaces de cache.

1. Contrôle d'accès et séparation des vues sur BIND 9 : Sous BIND 9, la récursion et l'accès au cache doivent être strictement réservés aux sous-réseaux internes légitimes :

acl "trusted_lan" {
    127.0.0.1;
    10.0.0.0/8;
    192.168.1.0/24;
};

options {
    recursion yes;
    allow-recursion { trusted_lan; };
    allow-query { trusted_lan; };
    allow-query-cache { trusted_lan; };
    version none;
    hostname none;
};

La directive allow-query-cache assure qu'aucun client extérieur non autorisé ne peut extraire d'enregistrements du cache.

2. Sécurisation et minimisation des requêtes sur Unbound : Le logiciel Unbound propose des paramètres efficaces pour verrouiller cette fuite d'information :

server:
    access-control: 127.0.0.1/32 allow
    access-control: 10.200.0.0/16 allow
    access-control: 0.0.0.0/0 refuse
    hide-identity: yes
    hide-version: yes
    qname-minimisation: yes
    minimal-responses: yes

L'activation de qname-minimisation (RFC 7816) limite la divulgation des noms complets auprès des serveurs intermédiaires, tandis qu'access-control rejette les paquets de sonde provenant d'adresses IP non autorisées.

Résolveurs isolés RiceGuard : élimination des risques de cache partagé via tunnel VPN

Si le durcissement de serveurs internes protège les bureaux fixes, les collaborateurs nomades se connectent fréquemment via des réseaux Wi-Fi tiers et des résolveurs mutualisés non fiables. VPNRice élimine cette vulnérabilité structurelle grâce à l'architecture de son protocole RiceGuard :

[ Application client ]
            |
            v
[ Résolveur local sur interface de boucle (127.0.0.1:53) ]
            | (Interception logicielle sécurisée)
            v
+-------------------------------------------------------+
| Tunnel L3 authentifié RiceGuard (Pilote WireGuard)    |
+-------------------------------------------------------+
            |
            | (Datagrammes UDP chiffrés sur le réseau public)
            v
+-------------------------------------------------------+
| Résolveurs récursifs cloisonnés par session           |
+-------------------------------------------------------+
            |
            v (Résolution itérative avec QNAME minimal)
[ Serveurs DNS d'autorité sur Internet ]

1. Cloisonnement des mémoires de cache par session : Plutôt que de fusionner les données de l'ensemble des clients dans une mémoire unique, RiceGuard alloue des espaces de cache étanches pour chaque tunnel chiffré. L'état mémoire d'un utilisateur demeure physiquement isolé de celui des autres.
2. Acheminement chiffré obligatoire : L'intégralité des requêtes DNS est encapsulée dans le tunnel de niveau 3 vers des infrastructures sécurisées. Les observateurs situés sur le même réseau local ne perçoivent que des trames chiffrées indéchiffrables.
3. Résolution sans corrélation d'identité : En appliquant les principes exposés dans notre étude sur l'architecture Oblivious DNS over HTTPS, le composant effectuant la résolution récursive n'a pas connaissance de l'adresse IP source du client.

Pour prémunir vos appareils contre le profilage issu des résolveurs mutualisés, vous pouvez Télécharger VPNRice.

Banc d'essai expérimental : latence de réponse, détection de cache et fuite de vie privée

Une série de mesures a été réalisée pour évaluer l'efficacité des attaques de sondage de cache selon les profils de serveurs :

Ces données prouvent qu'interdire le drapeau RD = 0 demeure insuffisant lorsque le différentiel temporel subsiste. La véritable confidentialité exige l'isolation physique du cache par session.

Déploiement pratique : sécurisation des résolveurs récursifs et audit du cache local

Les administrateurs peuvent évaluer la sécurité de leurs serveurs récursifs à l'aide des outils en ligne de commande usuels.

Configuration du contrôle d'accès et minimisation QNAME sur Unbound

Exemple de bloc de configuration pour unbound.conf destiné à bloquer le sondage non sollicité :

server:
    interface: 10.200.0.1
    port: 53
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # Contrôle d'accès : réservé aux clients du tunnel
    access-control: 10.200.0.0/24 allow
    access-control: 0.0.0.0/0 refuse

    # Paramètres de confidentialité
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    qname-minimisation: yes

Audit de la vulnérabilité au DNS Cache Snooping à l'aide de l'outil Dig

Vérifiez si un serveur répond aux interrogations non récursives :

# Test 1 : Envoi d'une requête non récursive pour un domaine spécifique
dig +norecurse @10.200.0.1 example.org A

# Analyse du résultat :
# - Présence d'une section Answer avec TTL : le résolveur est VULNÉRABLE
# - Statut REFUSED ou section Answer vide : les sondes non récursives sont bloquées

# Test 2 : Mesure de l'écart RTT entre domaines connus et aléatoires
dig +noall +stats @10.200.0.1 example.org
dig +noall +stats @10.200.0.1 domaine-aleatoire-non-consulte-48291.org

La réalisation régulière de ces vérifications permet de s'assurer que vos équipements de résolution ne trahissent pas l'historique de consultation des utilisateurs.