EDNS Client Subnet (ECS): capire come il DNS adatta le risposte alla tua posizione

Di CaptainDNS
Pubblicato il 20 ottobre 2025

#DNS
#ECS
#Geolocation

Immagina di spedire una cartolina senza mittente. Il server DNS vede soprattutto il resolver (8.8.8.8, 1.1.1.1…), non te. EDNS Client Subnet (ECS) aggiunge giusto gli indizi necessari per dire «arriva da quel quartiere»: un prefisso IP, non l'IP intero.

Riassunto veloce per chi ha fretta

ECS (RFC 7871): un'opzione EDNS che trasporta un sottorete del client (es. 203.0.113.0/24).
Obiettivo: aiutare l'autoritativo/CDN a restituire l'IP più vicino al client.
Effetti: latenza più bassa, ma cache più frammentata e privacy da gestire.
In pratica: prova con dig … +subnet=… e confronta le risposte tra due sottoreti.

Il problema che risolve ECS

Senza ECS, un autoritativo vede questo: «questa query proviene da 8.8.8.8». Non ha alcuna idea di dove sia l'utente finale. Risultato: può restituire l'IP di un PoP (Point of Presence) distante.

Con ECS, la query porta un indizio: «client ≈ 203.0.113.0/24». Il server sceglie quindi l'IP più pertinente per quel quartiere.

🎯 Meno chilometri di rete → meno latenza → esperienza migliore.

Provalo subito (Try it #1)

Testa la variazione per sottorete (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

Stessa idea in IPv6:

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

Se l'IP cambia, l'autoritativo sta tenendo conto di ECS per quel nome.

Come funziona?

ECS non è un nuovo protocollo; è un'opzione all'interno di EDNS(0). Il resolver aggiunge alla domanda DNS:

CLIENT-SUBNET: 203.0.113.0/24

L'autoritativo vede «quartiere ≈ /24» e restituisce l'IP del PoP più adeguato.

Cosa contiene l'opzione ECS?

0..1  FAMILY            (1 = IPv4, 2 = IPv6)
2     SOURCE PREFIX     (es. 24 per /24)
3     SCOPE  PREFIX     (es. 24, 20…)
4..n  ADDRESS           (troncato al prefisso)

SOURCE: la precisione inviata dal resolver (spesso /24 in v4, /56 in v6).
SCOPE: fino a dove la risposta può essere riutilizzata nel cache.
ADDRESS: troncato al prefisso (nessuna IP completa esposta).

Diagramma di flusso (SVG)

Diagramma di flusso (Il diagramma è riportato anche in linea qui sotto se il tuo motore non carica gli SVG esterni.)

ASCII (fallback)

[Client] -> [Resolver 8.8.8.8] ==(ECS: 203.0.113.0/24)==> [Autoritativo] -> [PoP CDN vicino]

Lato server: decisioni e scope

Quando riceve una domanda con ECS:

leggere il prefisso (SOURCE),
selezionare il PoP/risorsa più vicino,
restituire la risposta, eventualmente con un SCOPE (indicazione per il cache).

🪧 Pensa a SCOPE come a un cartello «valido per tutto il quartiere».

Cache e complessità: perché qualcuno esita

Senza ECS → una voce per nome. Con ECS → una voce per nome e per sottorete.

Conseguenze:

il cache cresce (es. varianti per /24),
serve definire una policy (prefissi massimi, domini consentiti, TTL ragionevoli),
alcuni resolver accorciano o disattivano ECS per controllare l'impatto sul cache e tutelare la privacy.

💡 Regola pragmatica: /24 (IPv4) e /56 (IPv6). Più precisione = poco guadagno, più rischio.

Privacy: sfocatura utile, non tracciamento

ECS non espone l'IP completo, solo un prefisso. È comunque un'informazione geografica: utile per la performance, sensibile in certi contesti.

Buone pratiche:

inviare solo prefissi corti (evita /32, /128),
documentare quando e per chi si applica ECS,
lato autoritativo, impostare uno SCOPE ragionevole per limitare la frammentazione.

Laboratorio di test (Try it #2 e #3)

🧪 Try it #2 – vedere l'opzione ECS

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

Nella OPT PSEUDOSECTION cerca una riga come:

CLIENT-SUBNET: 203.0.113.0/24/0

Se non appare, il resolver ignora o rimuove ECS.

🧪 Try it #3 – cambiare sottorete e confrontare

# Due prefissi /24, stesso resolver
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: prova DoT/DoH con kdig (TLS aiuta se in UDP vedi TC/truncation):

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

(I resolver si comportano in modo diverso in base alle policy; consulta la loro documentazione.)

Trappole comuni e anti-pattern

Cache ingannevole: usa etichette casuali (a1234.cdn.example.com) per forzare un MISS.
Confusione con DNSSEC: EDNS (e quindi ECS) non è firmato; non confondere il bit DO con l'opzione ECS.
UDP troncato (TC): riprova via TCP o TLS (kdig +tls).
Precisione eccessiva: bandisci /32 e /128: rumore, rischio, cache frammentato, poco beneficio.
Misurazioni affrettate: confronta diversi /24 e /56 prima di concludere che un CDN sia “mal configurato”.

FAQ

ECS mi rende tracciabile individualmente?
No. ECS espone un prefisso, non l'IP esatto. Rimane comunque un'informazione sulla posizione.

Perché il mio autoritativo non cambia nulla nonostante ECS?
Perché non implementa una logica geografica o perché i PoP visibili sono equivalenti per le sottoreti testate.

I resolver pubblici si comportano tutti allo stesso modo?
No. Alcuni aggiungono ECS (spesso accorciando il prefisso), altri lo rimuovono per motivi di privacy. Consulta la loro documentazione: le policy possono cambiare.

Riferimenti utili

RFC 7871 – Client Subnet in DNS Queries
RFC 6891 – Extension Mechanisms for DNS (EDNS(0))