What is EDNS Client Subnet (ECS)?
EDNS Client Subnet (ECS) is a DNS extension that lets a recursive resolver include part of the end user's IP address, such as the first 24 bits of an IPv4 address, when it forwards a query to an authoritative nameserver. The authoritative server can then tailor its answer to where the user actually is, rather than where the resolver is, and tells the resolver how widely that answer can be reused from its cache. It's defined in RFC 7871 and is mainly used by CDNs and location-aware DNS services to send people to a nearby server.
ECS exists because large public resolvers serve users across huge areas, and without it an authoritative server only ever sees the resolver's address. It improves routing accuracy but leaks some information about users, makes caching less efficient, and isn't supported by every resolver. In this article you'll learn the problem ECS solves, exactly what goes into the option, how scope and caching work, which resolvers send it, how to test it with dig, how to configure it in Unbound and PowerDNS, and the privacy trade-offs.
The Problem ECS Solves
When you look up a name, your device asks a recursive resolver, which then asks the authoritative nameservers for that domain. The authoritative server only sees the resolver's IP address, not yours.
That's fine when the resolver is close to you, such as your ISP's resolver in your city. It's a problem when:
- You use a public resolver whose nearest node is in a different country or region.
- Your company routes all DNS through a central resolver in another part of the world.
- Your ISP runs a few centralised resolvers for a large area.
Services that return location-dependent answers, such as CDNs and GeoDNS providers, then guess your location from the resolver's address. If they guess wrong, they send you to a distant server, and every subsequent request is slower than it needs to be.
ECS fixes this by letting the resolver pass along a truncated version of your address, enough to identify your network's rough location without identifying your exact device.
How ECS Works
ECS uses EDNS(0), the extension mechanism that lets DNS messages carry extra options in an OPT pseudo-record. ECS is one such option, with option code 8.
What the Option Contains
| Field | Meaning |
|---|---|
| FAMILY | 1 for IPv4, 2 for IPv6 |
| SOURCE PREFIX-LENGTH | How many leading bits of the client's address the resolver is sending, for example 24 |
| SCOPE PREFIX-LENGTH | Set to 0 in queries; in responses, how many bits the answer actually depends on |
| ADDRESS | The client's address, truncated to the source prefix length |
So for a user at 203.0.113.77, a resolver sending a /24 would include 203.0.113.0/24. The final octet is never sent.
The Exchange Step by Step
- The user's device asks the resolver for
www.example.com. The device itself normally doesn't send ECS. - The resolver adds an ECS option with the client's address truncated, say
203.0.113.0/24, and sends the query to the authoritative server. - The authoritative server uses the subnet to choose an answer, for example the nearest CDN edge.
- It replies with the same option, setting the scope prefix length to show how specific the answer is.
- The resolver caches the answer for that scope, and reuses it only for other clients inside the same scope.
Scope and Caching
The scope prefix length is the clever part. It tells the resolver which other clients can safely share the cached answer:
- Scope /24: The answer is valid only for clients in
203.0.113.0/24. Clients in other /24s need their own lookup. - Scope /16: The answer is valid for the whole
203.0.0.0/16, so the resolver can reuse it more widely. - Scope /0: The answer doesn't depend on location at all, and everyone can share it.
An authoritative server that doesn't vary answers by location should return scope 0, so resolvers can cache the result normally. A server that ignores ECS entirely doesn't include the option in its response, which the resolver treats as scope 0 too.
Recommended Prefix Lengths
RFC 7871 recommends that resolvers send no more than 24 bits for IPv4 and 56 bits for IPv6 by default. That's specific enough to locate a network, but not an individual household in most cases. Resolvers can choose to send less.
Which Resolvers Send ECS?
Support varies, and it changes over time, so check each provider's current documentation. Broadly:
| Resolver | ECS behaviour |
|---|---|
| Google Public DNS (8.8.8.8) | Sends ECS to authoritative servers that it has detected support it |
| Cloudflare (1.1.1.1) | Does not send ECS, citing privacy |
| Quad9 (9.9.9.9) | Main service doesn't send ECS; a separate ECS-enabled service is offered on 9.9.9.11 |
| OpenDNS | Sends ECS to selected authoritative servers |
| ISP resolvers | Varies; many don't need to, because they're already close to their users |
Resolvers generally only send ECS to authoritative servers that are known or detected to use it, rather than to every server on the internet. That limits unnecessary leakage and avoids breaking old servers that don't understand the option.
Testing ECS with dig
dig can add an ECS option to a query with +subnet. Send it directly to an authoritative nameserver that supports ECS to see how it responds:
dig @ns1.example.com www.example.com A +subnet=203.0.113.0/24
The relevant parts of the output look like this:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; CLIENT-SUBNET: 203.0.113.0/24/24
;; ANSWER SECTION:
www.example.com. 60 IN A 198.51.100.20
The CLIENT-SUBNET line shows address/source/scope. Here the server echoed the /24 source and returned a /24 scope, meaning the answer was chosen specifically for that subnet.
A server that supports ECS but doesn't vary this name by location returns a scope of 0:
; CLIENT-SUBNET: 203.0.113.0/24/0
And a server that doesn't support ECS at all simply omits the CLIENT-SUBNET line from its response.
Comparing Answers for Different Subnets
To see whether a domain's answers really vary by location, query the authoritative server with subnets from different parts of the world. Documentation ranges like 203.0.113.0/24 don't map to real locations, so substitute real public prefixes from the regions you want to test:
NS=$(dig example.com NS +short | head -n1)
for subnet in 203.0.113.0/24 198.51.100.0/24 192.0.2.0/24; do
printf '%-18s ' "$subnet"
dig @"$NS" www.example.com A +subnet="$subnet" +short | head -n1
done
Opting Out from the Client
You can also ask a resolver not to send your subnet upstream by including a /0 subnet in your own query. Resolvers that honour this will either forward no ECS option or a /0:
dig @8.8.8.8 www.example.com A +subnet=0.0.0.0/0
Configuring ECS on Your Own Servers
Unbound as a Resolver
Unbound supports sending ECS through its subnetcache module, which also handles caching answers by scope. It has to be listed before the validator and iterator modules:
server:
module-config: "subnetcache validator iterator"
# Only send ECS to these authoritative servers or zones
send-client-subnet: 192.0.2.53
client-subnet-zone: example.com
# Limit how much of the client's address is sent
max-client-subnet-ipv4: 24
max-client-subnet-ipv6: 56
send-client-subnet lists authoritative server addresses, and client-subnet-zone lists zones, that should receive ECS. Queries to anywhere else go out without it. Check and reload:
sudo unbound-checkconf
sudo unbound-control reload
If your users reach Unbound through a forwarder or load balancer, Unbound only sees that device's address. In that case, the front-end needs to add ECS itself, and Unbound can be configured to trust and pass on ECS options it receives from specific clients.
PowerDNS Authoritative Server
On the authoritative side, a server has to read the ECS option and use it when choosing an answer. In PowerDNS Authoritative, enable it in pdns.conf:
edns-subnet-processing=yes
The subnet is then used by backends that make location-based decisions, such as the GeoIP backend and LUA records, in place of the resolver's address. PowerDNS sets the scope in the response based on what the backend used.
PowerDNS Recursor and dnsdist
PowerDNS Recursor can send ECS to selected authoritative servers, and dnsdist, the PowerDNS load balancer, can add ECS to queries it forwards so that a resolver behind it sees the real client subnet. The relevant settings have been renamed in recent versions (for example from "whitelist" to "allow-list" terminology), so use the documentation for your exact version.
Managed DNS Providers
If your zone is on a managed DNS service that offers geographic or latency-based routing, ECS support is usually built in. Amazon Route 53, NS1 and most CDN-operated DNS platforms use ECS when resolvers provide it. There's typically nothing to configure on your side.
The Trade-Offs
Privacy
ECS sends part of the user's IP address to a third party: the operator of the authoritative nameserver. Even truncated to a /24, that's enough to place many users in a particular town and ISP. It also means that authoritative operators, and anyone watching traffic between resolvers and authoritative servers, learn more about who is looking up what.
This is the reason privacy-focused resolvers don't send ECS, and why RFC 7871 recommends conservative prefix lengths and sending ECS only where it's needed. Encrypted DNS between your device and your resolver doesn't change this, because ECS is added by the resolver on the next hop.
Cache Efficiency
Without ECS, a resolver caches one answer per name and type. With ECS, it may need a separate entry for every subnet scope, which means:
- More cache entries, and more memory.
- More cache misses, because a cached answer for one /24 can't be reused for another.
- More queries to authoritative servers, which increases their load and the latency for users whose answer isn't cached.
Authoritative servers can reduce this by returning the widest scope that's still accurate, for example /16 or /0 for names that don't depend on location.
Accuracy Isn't Guaranteed
ECS tells the server where the user's network is, not where the user is. VPN users, mobile networks that route traffic through central gateways, and corporate networks that exit to the internet far from their offices can all still produce poor routing decisions. ECS improves the odds; it doesn't make location perfect.
Compatibility
Very old authoritative servers or middleboxes occasionally mishandle unknown EDNS options. This is rare today, and resolvers usually only send ECS to servers that have shown they handle it, but it's a reason ECS isn't sent everywhere by default.
Do You Need to Care About ECS?
For most website owners, ECS is something that happens in the background. You'll notice it if:
- You use GeoDNS or latency-based routing and want users of large public resolvers to be routed accurately.
- You run a CDN or multi-region service and see users routed to distant locations.
- You operate a resolver for many users across a wide area and want to balance accuracy against privacy and cache efficiency.
- You're debugging why a user gets a different answer from the one you see.
If you just host a website with a single origin or behind an anycast CDN, ECS makes little difference to you.
FAQ: EDNS Client Subnet
No. Resolvers send a truncated prefix, typically 24 bits of an IPv4 address or 56 bits of an IPv6 address. The final part of the address, which would identify an individual connection more closely, isn't included.
Cloudflare has chosen not to send ECS on 1.1.1.1 for privacy reasons, because it shares part of the user's address with authoritative servers. It relies on its large anycast network to keep resolvers close to users instead.
It's set by the authoritative server in its response to show how many bits of the client address the answer depends on. The resolver reuses the cached answer only for other clients within that scope. A scope of 0 means the answer is the same for everyone.
Query it directly with dig and the +subnet option, for example dig @ns1.example.com www.example.com +subnet=203.0.113.0/24. If the response includes a CLIENT-SUBNET line, the server understands ECS.
Yes. Answers that depend on the client subnet must be cached separately for each scope, which increases cache size and reduces hit rates. Authoritative servers can help by returning the widest accurate scope.
You can choose a resolver that doesn't send ECS, or include a /0 subnet in your own queries, which many resolvers treat as a request not to forward your subnet.
Conclusion
EDNS Client Subnet lets a recursive resolver tell authoritative servers roughly where the user is, by including a truncated prefix of their IP address in the query. The authoritative server uses it to pick a better answer and returns a scope that tells the resolver how widely it can reuse that answer. It's what lets CDNs and GeoDNS route users of large public resolvers almost as accurately as users of nearby ISP resolvers.
The cost is privacy and cache efficiency, which is why not every resolver sends it and why those that do limit both the prefix length and the servers they send it to. If you operate location-aware DNS, test your servers with dig +subnet and return sensible scopes. If you run a resolver, send ECS only where it's genuinely needed.
