Pendant des décennies, l'architecture du système de noms de domaine (Domain Name System - DNS) a fourni une barrière de confidentialité inattendue mais protectrice. Lorsqu'une machine cliente interrogeait un serveur faisant autorité, la requête transitait par un résolveur récursif intermédiaire (Recursive Resolver) géré par un fournisseur d'accès à Internet (FAI) ou un service DNS public. Le serveur faisant autorité n'observait que l'adresse IP du résolveur récursif, masquant ainsi l'adresse IP publique d'origine de l'utilisateur derrière une infrastructure de mise en cache mutualisée.

L'avènement massif des réseaux de diffusion de contenu (Content Delivery Networks - CDNs) a profondément modifié cette dynamique. Les infrastructures modernes s'appuient sur le routage Anycast et le GeoDNS pour orienter les utilisateurs vers le cluster périphérique le plus proche sur le plan topologique. Toutefois, lorsque les internautes configurent des résolveurs récursifs centralisés situés dans des centres de données distants, les algorithmes GeoDNS orientent fréquemment le client vers des nœuds périphériques situés à des milliers de kilomètres. Il en résulte une élévation de la latence réseau (RTT) et une chute du débit utile.

Afin de concilier la précision de l'aiguillage CDN et la performance du cache récursif, l'Internet Engineering Task Force (IETF) a standardisé en mai 2016 le RFC 7871, intitulé « Client Subnet in DNS Queries », universellement désigné sous le nom d'EDNS Client Subnet (ECS). Si le RFC 7871 a optimisé l'acheminement des flux CDN, il a ouvert une faille majeure dans la confidentialité des échanges réseau. En vertu de ce protocole, les résolveurs récursifs intègrent directement le sous-réseau IP de l'utilisateur au sein des paquets DNS transmis aux serveurs faisant autorité, exposant ainsi la localisation géographique des abonnés même lorsque le trafic emprunte des protocoles chiffrés comme DNS over HTTPS (DoH) ou DNS over TLS (DoT).

[Architecture DNS Récursive Traditionnelle : Adresse IP Masquée]
Client (203.0.113.88) ───> Résolveur Récursif (198.51.100.1) ───> Serveur Autorité
                                [Seule l'IP du résolveur est visible : 198.51.100.1]

────────────────────────────────────────────────────────────────────────────────────────

[Architecture RFC 7871 EDNS Client Subnet (ECS) : Sous-réseau Exposé]
Client (203.0.113.88) ───> Résolveur Récursif (198.51.100.1)
                                │
                                ├─ Ajoute EDNS0 Option 8 : Sous-réseau 203.0.113.0/24
                                ▼
                           Serveur Faisant Autorité (CDN / Traceur)
                                [Enregistre Domaine + Préfixe Résidentiel 203.0.113.0/24]

Structure Protocolaire du RFC 7871 : Option Code 8 d'EDNS0

Pour mesurer l'ampleur de la divulgation géographique provoquée par ECS, il convient d'analyser la structure binaire définie par les RFC 6891 (EDNS0) et RFC 7871.

Les messages DNS classiques transmis via UDP sont limités historiquement à une charge utile de 512 octets. Le RFC 6891 a instauré les mécanismes d'extension pour DNS (EDNS0) en définissant un pseudo-enregistrement appelé OPT Resource Record. Cette structure autorise les clients et les résolveurs à négocier des tampons de réception pouvant atteindre 4096 octets et à insérer des options de taille variable dans la section des enregistrements additionnels.

Le RFC 7871 réserve le code d'option 8 (Option Code 8) pour le champ client-subnet. Lorsqu'un résolveur récursif traite une résolution vers une zone gérant l'extension ECS, il construit un enregistrement OPT composé de quatre champs essentiels :

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-------------------------------+-------------------------------+
 |          OPTION-CODE          |         OPTION-LENGTH         |
 |            (0x0008)           |           (Variable)          |
 +-------------------------------+-------------------------------+
 |            FAMILY             |SOURCE-NETMASK | SCOPE-NETMASK |
 +-------------------------------+---------------+---------------+
 |                           ADDRESS                             |
 |                     (Octets d'adresse réseau)                 |
 +---------------------------------------------------------------+
  • FAMILY (16 bits) : Désigne la famille de protocole réseau (1 pour IPv4 ou 2 pour IPv6).
  • SOURCE-NETMASK (8 bits) : Longueur du masque de sous-réseau client transmise par le résolveur. Pour IPv4, le RFC 7871 préconise un préfixe /24 (masquant les 8 derniers bits). Pour IPv6, il recommande un préfixe /56.
  • SCOPE-NETMASK (8 bits) : Fixé par le serveur faisant autorité dans sa réponse pour spécifier la granularité du sous-réseau sur laquelle la réponse demeure valide et peut être mise en cache.
  • ADDRESS (Longueur variable) : Représentation binaire tronquée de l'adresse du sous-réseau client (par exemple 3 octets pour un préfixe /24).

Bien que la troncature à un préfixe /24 ait été conçue pour préserver la vie privée en regroupant 256 adresses IP distinctes, les mesures topologiques démontrent que les plages résidentielles /24 des fournisseurs d'accès correspondent directement à des zones postales ou des quartiers municipaux très précis.

Vecteur de Surveillance : Profilage Géographique et Bases de Données pDNS

La transmission récurrente des préfixes via l'option ECS transforme le protocole de résolution de noms en un outil d'identification persistant :

  1. Inopérance du Chiffrement de Transport : De nombreux utilisateurs activent le protocole DoH ou DoT en pensant protéger l'intégralité de leur trafic DNS. Cependant, DoH et DoT ne protègent que le premier saut réseau entre le client et le résolveur récursif. Dès que le résolveur prend en charge la requête, il la déchiffre puis transmet le bloc ECS en clair via UDP sur le port 53 aux serveurs faisant autorité tiers. Le chiffrement de premier niveau ne neutralise aucunement cette fuite de métadonnées en amont.
  2. Collecte de Télémétrie par les Serveurs Autoritaires : Les serveurs de noms opérés par les régies publicitaires, les courtiers en données et les conglomérats numériques traitent des milliards de requêtes quotidiennes. En consignant systématiquement le préfixe ECS associé à chaque domaine demandé, ces acteurs dressent des profils comportementaux temporels sur l'activité des réseaux domestiques et professionnels.
  3. Alimentation des Bases Passive DNS (pDNS) : Les spécialistes du renseignement cybernétique déploient des capteurs Passive DNS sur les dorsales Internet. La présence des données ECS dans les flux de résolution permet de corréler rétroactivement chaque nom de domaine avec des blocs d'adresses résidentielles spécifiques.
Configuration Réseau Chiffrement Premier Saut Confidentialité Résolveur Récursif Données Reçues Serveur Autorité Efficacité Routage CDN
DNS Traditionnel (FAI) Aucun (UDP port 53) Faible (traçabilité intégrale FAI) IP Résolveur (Sans ECS) Moyenne
DoH Public (ECS Activé) Fort (TLS 1.3 / HTTP/2) Variable selon la charte Sous-réseau Client (/24 ou /56) Maximale
DoH Public (ECS Désactivé) Fort (TLS 1.3 / HTTP/2) Élevée IP Résolveur Uniquement Moyenne
DNS Dédié VPNRice Tunnel Cryptographique Couche 3 Infrastructure Anycast Sans Journal IP de Sortie VPN (Sans ECS) Optimale et Privée

Scission Technologique : Anonymat contre Optimisation de Latence

En raison du compromis imposé par le RFC 7871 entre performance de routage et confidentialité, les opérateurs mondiaux de services DNS ont adopté des approches divergentes :

  • Google Public DNS (8.8.8.8) : Transmet activement les données ECS aux serveurs partenaires afin de maximiser la précision d'aiguillage CDN, tout en respectant les requêtes des clients configurées avec un préfixe source nul (0.0.0.0/0).
  • OpenDNS / Cisco Umbrella : Précurseur dans la diffusion des sous-réseaux clients, l'opérateur maintient l'envoi des métadonnées ECS pour calibrer la distribution géographique des contenus.
  • Cloudflare (1.1.1.1) : Rejette formellement le protocole RFC 7871. La charte de Cloudflare proscrit l'adjonction de préfixes clients aux requêtes amont, privilégiant la protection absolue des utilisateurs face aux risques de profilage.
  • Quad9 (9.9.9.9) : Fonctionne selon une politique de confidentialité stricte et purge systématiquement les options ECS de l'ensemble de ses requêtes vers les serveurs faisant autorité.

Élimination des Fuites ECS par Encapsulation Couche 3 et Résolveur Dédié

Désactiver l'option ECS au niveau des applications locales ne garantit pas la sécurité, car un client logiciel ne peut contraindre un résolveur distant à abandonner le code d'option 8. La réponse technique appropriée repose sur une architecture d'isolation à deux niveaux :

[Poste de Travail / Appareil Mobile]
                 │
                 ├─ Requête DNS vers la Passerelle Interne (ex: 10.8.0.1)
                 ▼
[Interface Réseau Virtuelle : wg0 / tun0]
   Encapsulation Cryptographique Couche 3 via WireGuard / RiceGuard
   Chiffrement Authentifié : ChaCha20-Poly1305 (Clé de 256 bits)
                 │
                 ▼
[Interface Physique Wi-Fi / FAI Local]
   Transporte des paquets UDP opaques ; le FAI ne distingue aucune requête DNS
                 │
                 ▼
[Passerelle Anycast et Résolveur Récursif VPNRice]
   1. Suppression absolue des métadonnées EDNS Client Subnet (FAMILY=0, SOURCE=0)
   2. Résolution récursive autonome via des instances racines locales
   3. Le serveur distant observe uniquement l'IP du centre de données VPN

Lors de l'utilisation du protocole RiceGuard développé par VPNRice :

  • Interception Systématique des Flux DNS : Toutes les requêtes dirigées vers les ports 53, 853 et DoH sont redirigées vers des résolveurs récursifs intégrés au tunnel chiffré. Le FAI local ne peut intercepter aucune trame DNS en clair.
  • Suppression Intégrale de l'Option ECS : Les résolveurs récursifs de VPNRice rejettent systématiquement les options RFC 7871. Si un serveur faisant autorité sollicite des paramètres ECS, le résolveur renvoie FAMILY=0 et SOURCE-NETMASK=0.
  • Harmonisation de l'Adresse IP de Sortie : Les serveurs faisant autorité n'observent que l'adresse Anycast du centre de données de sortie du VPN. Les réponses GeoDNS orientent alors naturellement le trafic vers les clusters optimaux sans compromettre la géolocalisation réelle de l'utilisateur.

Procédures Pratiques de Diagnostic et d'Atténuation des Fuites ECS

Les administrateurs réseau et les ingénieurs système peuvent auditer la présence de l'option ECS sur leurs liaisons réseau grâce à des commandes de diagnostic :

# 1. Tester si le résolveur actuel transmet un préfixe ECS aux serveurs Google
dig +subnet=0.0.0.0/0 TXT o-o.myaddr.l.google.com @8.8.8.8 +short

# 2. Inspecter la présence de l'Option Code 8 via Wireshark / tshark
# Filtre d'affichage Wireshark : dns.edns0.opt.code == 8

# 3. Pour un résolveur local Unbound, interdire l'émission d'ECS dans unbound.conf :
# server:
#     send-client-subnet: no
#     max-udp-size: 1232

# 4. Pour un serveur BIND 9, neutraliser ECS globalement dans named.conf :
# options {
#     ecs-server no;
#     ecs-client no;
# };
  • Sélectionner des Résolveurs Ignorant ECS : En l'absence de tunnel VPN actif, configurez vos appareils sur des services DNS garantissant l'absence de retransmission ECS (comme Quad9 ou Cloudflare).
  • Activer un Tunnel VPN Permanent : Maintenez une connexion Couche 3 active via WireGuard ou RiceGuard afin de confiner l'ensemble des échanges de noms au sein d'un environnement Anycast sans journalisation.
  • Contrôler les Liaisons Dual-Stack : Veillez à ce que les interfaces IPv6 soient strictement filtrées pour empêcher la fuite de préfixes /56 ou /64 SLAAC en dehors du tunnel chiffré.