EDNS Client Subnet (ECS): understanding how DNS adapts responses to your location

By CaptainDNS
Published on October 20, 2025

#DNS
#ECS
#Geolocation

Imagine mailing a postcard without a return address. The DNS server mostly sees the resolver (8.8.8.8, 1.1.1.1…), not you. EDNS Client Subnet (ECS) adds just enough clues to say “this comes from that neighborhood”—an IP prefix, not the entire IP.

Quick recap for people in a hurry

ECS (RFC 7871): an EDNS option that carries a client subnet (e.g. 203.0.113.0/24).
Goal: help the authoritative/CDN return the IP closest to the client.
Effects: lower latency, but a cache that is more fragmented and privacy trade-offs to manage.
In practice: test with dig … +subnet=… and compare responses between two subnets.

The problem ECS solves

Without ECS, an authoritative sees this: “this query comes from 8.8.8.8”. It has no idea where the end user is. Result: it may return the IP of a PoP (Point of Presence) far away.

With ECS, the query carries a hint: “client ≈ 203.0.113.0/24”. The server then chooses the IP most relevant for that neighborhood.

🎯 Fewer network kilometers → lower latency → better experience.

Try it right now (Try it #1)

Test the per-subnet variation (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

Same idea in IPv6:

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

If the IP changes, the authoritative is taking ECS into account for that name.

How does it work?

ECS is not a new protocol; it is an option within EDNS(0). The resolver adds to the DNS question:

CLIENT-SUBNET: 203.0.113.0/24

The authoritative sees “neighborhood ≈ /24” and returns the IP of the most appropriate PoP.

What does the ECS option contain?

0..1  FAMILY            (1 = IPv4, 2 = IPv6)
2     SOURCE PREFIX     (e.g. 24 for /24)
3     SCOPE  PREFIX     (e.g. 24, 20…)
4..n  ADDRESS           (truncated to the prefix)

SOURCE: precision sent by the resolver (often /24 in v4, /56 in v6).
SCOPE: how far the answer can be reused in cache.
ADDRESS: truncated to the prefix (no full IP exposed).

Flow diagram (SVG)

Flow diagram (The diagram is also inlined below in case your engine does not load external SVG images.)

ASCII (fallback)

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

Server side: decisions and scope

Receiving a question with ECS:

read the prefix (SOURCE),
select the closest PoP/resource,
return the answer, possibly with a SCOPE (cache reuse hint).

🪧 Think of SCOPE as a sign saying “valid for this whole neighborhood”.

Cache and complexity: why some hesitate

Without ECS → one entry per name. With ECS → one entry per name and per subnet.

Consequences:

cache grows (e.g. variants per /24),
policy to define (max prefixes, allowed domains, reasonable TTLs),
some resolvers truncate or disable ECS to control cache footprint and preserve privacy.

💡 Pragmatic rule of thumb: /24 (IPv4) and /56 (IPv6). More precision = little gain, more risk.

Privacy: useful blur, not tracking

ECS does not expose the full IP, only a prefix. It is still geographic information—useful for performance, sensitive in some contexts.

Good practices:

only send short prefixes (avoid /32, /128),
document when and for whom ECS applies,
on the authoritative side, set a reasonable SCOPE to limit fragmentation.

Test lab (Try it #2 and #3)

🧪 Try it #2 – see the ECS option itself

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

In the OPT PSEUDOSECTION, look for a line like:

CLIENT-SUBNET: 203.0.113.0/24/0

If it does not appear, the resolver ignores or strips ECS.

🧪 Try it #3 – change the subnet and compare

# Two /24 prefixes, same 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: test DoT/DoH with kdig (TLS helps if you hit TC/truncation in UDP):

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

(Resolvers behave differently depending on policy; check their documentation.)

Common pitfalls & anti-patterns

Cache that lies to you: use random labels (a1234.cdn.example.com) to force a MISS.
DNSSEC confusion: EDNS (and therefore ECS) is not signed; do not mix the DO bit and the ECS option.
Truncated UDP (TC): retry over TCP or TLS (kdig +tls).
Excessive precision: ban /32 and /128—noise, risk, fragmented cache, little benefit.
Rushed measurements: compare several /24 and /56 networks before concluding a CDN is “misconfigured”.

FAQ

Does ECS make me individually trackable?
No. ECS exposes a prefix, not the exact IP. It is still location information, though.

Why does my authoritative not change anything despite ECS?
Because it does not implement geo logic, or because the visible PoPs are equivalent for the tested subnets.

Do public resolvers all behave the same?
No. Some add ECS (often truncating the prefix), others remove it for privacy policy reasons. Check their documentation—policies can change.

Helpful references

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