EDNS Client Subnet (ECS) : comprendre comment le DNS adapte ses réponses à votre localisation

Par CaptainDNS
Publié le 20 octobre 2025

#DNS
#ECS
#Geolocation

Imaginez poster une carte postale sans retour d'adresse. Le serveur DNS, lui, voit surtout le résolveur (8.8.8.8, 1.1.1.1…), pas vous. EDNS Client Subnet (ECS) ajoute juste assez d'indices pour dire “ça vient de ce quartier” - un préfixe d'IP, pas l'IP entière.

Résumé rapide pour les plus pressés

ECS (RFC 7871) : option EDNS qui transporte un sous‑réseau client (ex. 203.0.113.0/24).
But : aider l'autoritaire/CDN à renvoyer l'IP la plus proche du client.
Effets : baisse de latence, mais cache plus fragmenté et vie privée à ménager.
Pratique : testez avec dig … +subnet=… et comparez les réponses entre deux sous‑réseaux.

Le problème que résout ECS

Sans ECS, un autoritaire voit ceci : “cette requête vient de 8.8.8.8”. Il n'a aucune idée d'où est l'utilisateur final. Résultat : il peut renvoyer l'IP d'un PoP (Point of Presence) lointain.

Avec ECS, la requête porte un indice : “client ≈ 203.0.113.0/24”. Le serveur choisit alors l'IP la plus pertinente pour ce voisinage.

🎯 Moins de kilomètres réseau → moins de latence → meilleure expérience.

Essayez‑le tout de suite (Try it #1)

Testez la variation par sous‑réseau (IPv4) :

dig cdn.example.com @8.8.8.8 +subnet=8.8.8.0/24  +noall +answer +comments
dig cdn.example.com @8.8.8.8 +subnet=1.1.1.0/24  +noall +answer +comments

Même chose en IPv6 :

dig cdn.example.com @8.8.8.8 +subnet=2001:db8::/56 +noall +answer +comments

Si l'IP change, c'est que l'autoritaire tient compte d'ECS pour ce nom.

Comment ça fonctionne ?

ECS n'est pas un nouveau protocole ; c'est une option dans le cadre EDNS(0). Le résolveur ajoute à la question DNS :

CLIENT-SUBNET: 203.0.113.0/24

L'autoritaire voit “voisinage ≈ /24” et renvoie l'IP du PoP le plus cohérent.

Que contient l'option ECS ?

0..1  FAMILY            (1 = IPv4, 2 = IPv6)
2     SOURCE PREFIX     (ex. 24 pour /24)
3     SCOPE  PREFIX     (ex. 24, 20…)
4..n  ADDRESS           (tronquée au préfixe)

SOURCE : précision transmise par le résolveur (souvent /24 en v4, /56 en v6).
SCOPE : “jusqu'où” la réponse peut être réutilisée côté cache.
ADDRESS : tronquée au préfixe (pas d'IP complète exposée).

Schéma du flux (SVG)

Schéma de flux (Le schéma est aussi fourni inline plus bas si votre moteur ne traite pas les images SVG externes.)

ASCII (fallback)

[Client] -> [Résolveur 8.8.8.8] ==(ECS: 203.0.113.0/24)==> [Autoritaire] -> [CDN PoP proche]

Côté serveur : décisions et scope

Réception d'une question avec ECS :

lire le préfixe (SOURCE),
sélectionner le PoP/ressource la plus proche,
renvoyer la réponse, éventuellement avec un SCOPE (conseil de réutilisation côté cache).

🪧 Pensez au SCOPE comme à un panneau “valable pour tout ce quartier”.

Cache et complexité : pourquoi certains hésitent

Sans ECS → une entrée par nom. Avec ECS → une entrée par nom et par sous‑réseau.

Conséquences :

cache plus volumineux (ex. variantes par /24),
politique à définir (préfixes max, domaines autorisés, TTL raisonnables),
certains résolveurs tronquent ou désactivent ECS pour contrôler l'empreinte cache et préserver la vie privée.

💡 Règle pragmatique souvent vue : /24 (IPv4) et /56 (IPv6). Plus précis = peu de gain, plus de risques.

Vie privée : flou utile, pas filature

ECS n'expose pas l'IP complète, seulement un préfixe. C'est déjà une info géographique - utile pour la perf, sensible pour certains contextes.

Bonnes pratiques :

n'envoyer que des préfixes courts (éviter /32, /128),
documenter quand et pour qui ECS s'applique,
côté autoritaire, fixer un SCOPE raisonnable pour limiter la fragmentation.

Atelier de tests (Try it #2 et #3)

🧪 Try it #2 - Voir l'option ECS elle‑même

dig google.com @8.8.8.8 +subnet=203.0.113.0/24 +noall +answer +comments

Dans la OPT PSEUDOSECTION, cherchez une ligne du type :

CLIENT-SUBNET: 203.0.113.0/24/0

Si elle n'apparaît pas, le résolveur ignore ou strippe ECS.

🧪 Try it #3 - Varier la zone et comparer

# Deux /24, même résolveur
dig cdn.example.com @8.8.8.8 +subnet=8.8.8.0/24 +short
dig cdn.example.com @8.8.8.8 +subnet=1.1.1.0/24 +short

Bonus : test en DoT/DoH avec kdig (TLS utile si TC/truncation en UDP) :

kdig +tls @1.1.1.1 example.com +subnet=203.0.113.0/24

(Comportements des résolveurs variables selon leurs politiques ; vérifiez leur documentation.)

Pièges fréquents & anti‑patterns

Cache qui vous trompe : utilisez des labels aléatoires (a1234.cdn.example.com) pour forcer un MISS.
Confusion DNSSEC : EDNS (et donc ECS) n'est pas signé ; ne mélangez pas le bit DO et l'option ECS.
UDP tronqué (TC) : retentez en TCP ou TLS (kdig +tls).
Précision excessive : bannissez /32 et /128 - bruit, risques, cache fragmenté, peu de bénéfice.
Mesures hâtives : comparez plusieurs /24 et /56 avant de conclure sur un CDN “mal configuré”.

FAQ

ECS me rend‑il traçable individuellement ?
Non. ECS expose un préfixe, pas l'IP exacte. Il reste toutefois une info de localisation.

Pourquoi mon autoritaire ne change rien malgré ECS ?
Parce qu'il n'implémente pas de logique géo, ou que les PoP visibles sont équivalents pour les sous‑réseaux testés.

Les résolveurs publics font‑ils tous pareil ?
Non. Certains ajoutent ECS (souvent en tronquant le préfixe), d'autres le suppriment par politique de vie privée. Référez‑vous à leur documentation - les politiques peuvent évoluer.

Références utiles

RFC 7871 - Client Subnet in DNS Queries
RFC 6891 - Extension Mechanisms for DNS (EDNS(0))
PoP - Nœud physique du réseau, un datacenter ou un serveur relais, où un fournisseur (CDN, DNS, opérateur, etc.) déploie ses machines pour être proche des utilisateurs finaux