EDNS Client Subnet (ECS): entenda como o DNS adapta as respostas à sua localização

Por CaptainDNS
Publicado em 20 de outubro de 2025

#DNS
#ECS
#Geolocation

Imagine enviar um cartão-postal sem remetente. O servidor DNS enxerga principalmente o resolvedor (8.8.8.8, 1.1.1.1…), não você. EDNS Client Subnet (ECS) adiciona pistas suficientes para dizer «isso vem deste bairro»: um prefixo de IP, não o endereço completo.

Resumo rápido para quem está com pressa

ECS (RFC 7871): uma opção EDNS que carrega um sub-rede do cliente (ex.: 203.0.113.0/24).
Objetivo: ajudar o autoritativo/CDN a retornar o IP mais próximo do cliente.
Efeitos: menor latência, mas um cache mais fragmentado e privacidade a ser equilibrada.
Na prática: teste com dig … +subnet=… e compare respostas entre duas sub-redes.

O problema que o ECS resolve

Sem ECS, um autoritativo vê o seguinte: «esta consulta vem de 8.8.8.8». Ele não tem ideia de onde está o usuário final. Resultado: pode devolver o IP de um PoP (Point of Presence) distante.

Com ECS, a consulta carrega uma pista: «cliente ≈ 203.0.113.0/24». O servidor escolhe então o IP mais relevante para aquele bairro.

🎯 Menos quilômetros de rede → menos latência → melhor experiência.

Teste agora mesmo (Try it #1)

Teste a variação por sub-rede (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

A mesma ideia em IPv6:

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

Se o IP mudar, o autoritativo está levando o ECS em conta para esse nome.

Como funciona?

ECS não é um protocolo novo; é uma opção dentro do EDNS(0). O resolvedor adiciona à consulta DNS:

CLIENT-SUBNET: 203.0.113.0/24

O autoritativo enxerga «bairro ≈ /24» e devolve o IP do PoP mais adequado.

O que a opção ECS contém?

0..1  FAMILY            (1 = IPv4, 2 = IPv6)
2     SOURCE PREFIX     (ex.: 24 para /24)
3     SCOPE  PREFIX     (ex.: 24, 20…)
4..n  ADDRESS           (truncado ao prefixo)

SOURCE: precisão enviada pelo resolvedor (geralmente /24 em v4, /56 em v6).
SCOPE: até onde a resposta pode ser reutilizada no cache.
ADDRESS: truncado ao prefixo (nenhum IP completo exposto).

Diagrama de fluxo (SVG)

Diagrama de fluxo (O diagrama também aparece inline abaixo caso seu renderizador não carregue SVG externos.)

ASCII (fallback)

[Cliente] -> [Resolvedor 8.8.8.8] ==(ECS: 203.0.113.0/24)==> [Autoritativo] -> [PoP de CDN próximo]

Lado do servidor: decisões e scope

Ao receber uma consulta com ECS:

ler o prefixo (SOURCE),
selecionar o PoP/recurso mais próximo,
devolver a resposta, talvez com um SCOPE (dica de reutilização em cache).

🪧 Pense em SCOPE como uma placa dizendo «válido para todo este bairro».

Cache e complexidade: por que alguns hesitam

Sem ECS → uma entrada por nome. Com ECS → uma entrada por nome e por sub-rede.

Consequências:

o cache cresce (ex.: variações por /24),
é preciso definir uma política (prefixos máximos, domínios permitidos, TTL razoáveis),
alguns resolvedores encurtam ou desativam o ECS para controlar o tamanho do cache e preservar a privacidade.

💡 Regra pragmática: /24 (IPv4) e /56 (IPv6). Mais precisão = pouco ganho, mais risco.

Privacidade: desfoque útil, não rastreamento

ECS não expõe o IP completo, apenas um prefixo. Ainda é informação geográfica—útil para desempenho, sensível em certos contextos.

Boas práticas:

enviar apenas prefixos curtos (evite /32, /128),
documentar quando e para quem o ECS se aplica,
no autoritativo, definir um SCOPE adequado para limitar a fragmentação.

Laboratório de testes (Try it #2 e #3)

🧪 Try it #2 – ver a própria opção ECS

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

Na OPT PSEUDOSECTION, procure uma linha como:

CLIENT-SUBNET: 203.0.113.0/24/0

Se ela não aparecer, o resolvedor ignora ou remove o ECS.

🧪 Try it #3 – mudar a sub-rede e comparar

# Dois prefixos /24, mesmo 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

Bônus: teste DoT/DoH com kdig (TLS ajuda se você topar com TC/truncation em UDP):

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

(Os resolvedores variam conforme a política; consulte a documentação deles.)

Armadilhas comuns e anti-patterns

Cache enganoso: use labels aleatórias (a1234.cdn.example.com) para forçar um MISS.
Confusão com DNSSEC: EDNS (e portanto ECS) não é assinado; não misture o bit DO com a opção ECS.
UDP truncado (TC): tente novamente via TCP ou TLS (kdig +tls).
Precisão excessiva: evite /32 e /128 — ruído, risco, cache fragmentado, pouco benefício.
Medições apressadas: compare vários /24 e /56 antes de concluir que um CDN está “mal configurado”.

FAQ

O ECS me torna rastreável individualmente?
Não. ECS expõe um prefixo, não o IP exato. Ainda assim é informação de localização.

Por que meu autoritativo não muda nada apesar do ECS?
Porque ele não implementa lógica geográfica ou porque os PoPs visíveis são equivalentes para as sub-redes testadas.

Todos os resolvedores públicos se comportam da mesma forma?
Não. Alguns adicionam ECS (muitas vezes encurtando o prefixo), outros o removem por política de privacidade. Consulte a documentação — as políticas podem mudar.

Referências úteis

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