EDNS Client Subnet (ECS): comprende cómo el DNS adapta las respuestas a tu ubicación

Imagina enviar una postal sin remitente. El servidor DNS ve sobre todo al resolvedor (8.8.8.8, 1.1.1.1…), no a ti. EDNS Client Subnet (ECS) añade las pistas justas para decir «esto viene de este vecindario»: un prefijo de IP, no la IP completa.

Resumen rápido para los que tienen prisa

• ECS (RFC 7871): una opción EDNS que transporta un subred de cliente (p. ej. 203.0.113.0/24).
• Objetivo: ayudar al autoritativo/CDN a devolver la IP más cercana al cliente.
• Efectos: menor latencia, pero un cache más fragmentado y privacidad a cuidar.
• En la práctica: prueba con dig … +subnet=… y compara respuestas entre dos subredes.

El problema que resuelve ECS

Sin ECS, un autoritativo ve esto: «esta consulta viene de 8.8.8.8». No tiene ni idea de dónde está el usuario final. Resultado: puede responder con la IP de un PoP (Point of Presence) lejano.

Con ECS, la consulta lleva una pista: «cliente ≈ 203.0.113.0/24». El servidor elige entonces la IP más pertinente para ese vecindario.

🎯 Menos kilómetros de red → menos latencia → mejor experiencia.

Pruébalo ahora mismo (Try it #1)

Prueba la variación por subred (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

Lo mismo en IPv6:

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

Si la IP cambia, el autoritativo está teniendo en cuenta ECS para ese nombre.

¿Cómo funciona?

ECS no es un protocolo nuevo; es una opción dentro de EDNS(0). El resolvedor añade a la consulta DNS:

CLIENT-SUBNET: 203.0.113.0/24

El autoritativo ve «vecindario ≈ /24» y devuelve la IP del PoP más coherente.

¿Qué contiene la opción ECS?

0..1  FAMILY            (1 = IPv4, 2 = IPv6)
2     SOURCE PREFIX     (p. ej. 24 para /24)
3     SCOPE  PREFIX     (p. ej. 24, 20…)
4..n  ADDRESS           (truncada al prefijo)

• SOURCE: precisión que envía el resolvedor (a menudo /24 en v4, /56 en v6).
• SCOPE: hasta dónde se puede reutilizar la respuesta en el cache.
• ADDRESS: truncada al prefijo (no se expone la IP completa).

Diagrama de flujo (SVG)

(El diagrama también se incluye más abajo por si tu motor no carga SVG externos.)

ASCII (alternativa)

[Cliente] -> [Resolver 8.8.8.8] ==(ECS: 203.0.113.0/24)==> [Autoritativo] -> [PoP de CDN cercano]

Lado del servidor: decisiones y alcance

Al recibir una consulta con ECS:

1. leer el prefijo (SOURCE),
2. seleccionar el PoP/recurso más cercano,
3. devolver la respuesta, quizá con un SCOPE (pista de reutilización en cache).

🪧 Piensa en SCOPE como un cartel que dice «válido para todo este vecindario».

Cache y complejidad: por qué algunos dudan

Sin ECS → una entrada por nombre. Con ECS → una entrada por nombre y por subred.

Consecuencias:

• el cache crece (p. ej. variantes por /24),
• hay que definir una política (prefijos máximos, dominios permitidos, TTL razonables),
• algunos resolvedores recortan o desactivan ECS para controlar el tamaño del cache y preservar la privacidad.

💡 Regla pragmática: /24 (IPv4) y /56 (IPv6). Más precisión = poco beneficio, más riesgo.

Privacidad: desenfoque útil, no rastreo

ECS no expone la IP completa, solo un prefijo. Sigue siendo información geográfica: útil para el rendimiento, sensible en ciertos contextos.

Buenas prácticas:

• enviar solo prefijos cortos (evita /32, /128),
• documenta cuándo y para quién aplica ECS,
• en el autoritativo, fija un SCOPE razonable para limitar la fragmentación.

Laboratorio de pruebas (Try it #2 y #3)

🧪 Try it #2 – ver la opción ECS en sí

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

Busca en la OPT PSEUDOSECTION una línea como:

CLIENT-SUBNET: 203.0.113.0/24/0

Si no aparece, el resolvedor ignora o elimina ECS.

🧪 Try it #3 – cambia de subred y compara

# Dos prefijos /24, mismo resolvedor
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: prueba DoT/DoH con kdig (TLS ayuda si UDP marca TC/truncation):

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

(Los resolvedores varían según su política; revisa su documentación.)

Errores habituales y anti-patrones

• Cache que engaña: usa etiquetas aleatorias (a1234.cdn.example.com) para forzar un MISS.
• Confusión con DNSSEC: EDNS (y por extensión ECS) no está firmado; no mezcles el bit DO con la opción ECS.
• UDP truncado (TC): vuelve a intentarlo con TCP o TLS (kdig +tls).
• Precisión excesiva: evita /32 y /128: ruido, riesgo, cache fragmentado, poco beneficio.
• Mediciones apresuradas: compara varios /24 y /56 antes de concluir que un CDN está “mal configurado”.

FAQ

¿Me hace ECS rastreable individualmente?
No. ECS expone un prefijo, no la IP exacta. Aun así es información de ubicación.

¿Por qué mi autoritativo no cambia nada a pesar de ECS?
Porque no implementa lógica geográfica o porque los PoP visibles son equivalentes para las subredes probadas.

¿Todos los resolvedores públicos se comportan igual?
No. Algunos añaden ECS (a menudo recortando el prefijo), otros lo eliminan por política de privacidad. Consulta su documentación: las políticas pueden cambiar.

Referencias útiles

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