How EDNS Client Subnet Affects DNS and Privacy

EDNS Client Subnet, or ECS, is an optional DNS extension that lets a resolver include a client network prefix in a query to another DNS server. An authoritative DNS service can use that prefix to choose an answer, then indicate which address range the answer covers. A content delivery network (CDN) can use ECS to choose a server based on the client's network rather than the recursive resolver's network.
Sharing a client's network prefix can help DNS servers return a suitable address, but it also gives those servers more information about the client. A resolver may then need separate cached answers for different networks. An ECS prefix alone does not give an exact household location, and some resolvers do not send ECS at all.
What the Client Prefix Contains
ECS uses the EDNS mechanism for adding options to DNS messages. The ECS option includes an address family, a source prefix length, a scope prefix length, and address bytes. The family identifies IPv4 or IPv6, while the source prefix length specifies how many leading address bits are included. The option carries only the bytes needed for that prefix, with unused bits in the final byte set to zero.
For example, a recursive resolver handling a query from an IPv4 client might send a 24-bit prefix. The ECS address identifies that /24 network rather than carrying all 32 bits of the client's address. For IPv6, a resolver may send a partial prefix such as /56. These lengths are policy choices, not values that every resolver must use.
The source prefix length determines how much address information the query shares. A shorter prefix represents a larger group of addresses and reveals less specific network information. A source prefix length of zero tells the resolver not to add the client's address information to its queries. If a device's DNS client sets a prefix limit, a resolver forwarding the query must not add more client address bits than that limit allows.
Even a partial prefix can identify an access network, region, organization, or small subscriber group when combined with the query name and time. How much the prefix reveals depends on how addresses are assigned and routed. Removing the end of an address does not make the remaining network information anonymous.
How Response Scope Controls Cache Reuse
An ECS query sets the scope prefix length to zero and includes the source prefix information that the resolver is willing to share. The authoritative server copies the query's source prefix details into its response. It sets the response's scope prefix length to describe the network range for which the answer is suitable.
Suppose a resolver sends an IPv4 /24 source prefix. The authoritative service may return scope /24, indicating that the answer applies within that /24. It may return a shorter scope such as /20 if the same answer is suitable across a broader range. Scope /0 means the answer is suitable for all networks in the specified address family.
If an authoritative server leaves ECS out of its reply, an intermediate resolver should treat the answer as having scope /0 for caching. When a reply does contain ECS, the resolver checks its address family, source prefix length, and address bits against the query's nonzero fields. A mismatch requires rejecting the whole reply, so an answer for one network is not stored as an answer for another.
How ECS Changes DNS Cache Keys
A resolver normally looks for cached records using the query name, record type, and class. With ECS, the lookup also depends on the client's network. The cache can therefore hold different A or AAAA answers for the same name and query type, each suitable for a different network prefix.
An ECS-aware resolver uses longest-prefix matching to select the most specific valid cached entry that covers the address being checked. An answer with scope /24 applies only within that /24 network. An answer with scope /0 can be used for any network in the same address family, subject to its remaining TTL.
Storing separate answers for different networks uses more memory and can reduce how often a query is answered from cache. More queries may then need to be sent to authoritative servers. Resolver software should leave ECS disabled by default and limit the number of network variants it keeps when ECS is enabled.
Using a narrowly scoped answer for an unrelated network can send a client to an unsuitable server, while discarding a broadly usable answer can cause needless queries. Resolvers must also distinguish why an answer is cached as /0. An answer cached that way only because the query used source /0 is reserved for other source /0 queries. An answer marked globally usable by the authoritative server's scope /0 can be reused across networks in that address family.
Why CDN Answers Can Change
Without ECS, an authoritative DNS server normally sees the address of the recursive resolver that sent the query. A public resolver may be far from the client or serve clients on many different networks. If the authoritative service chooses answers by network location, the resolver's address may be a poor guide to where the client can connect fastest.
With ECS, the authoritative service can choose an answer using the client's network prefix. A CDN might return the address of a nearby server, a server reached through a better network connection, or a server assigned to the client's region. Two clients using the same recursive resolver can therefore receive different addresses.
A geographically nearby server can still be slow to reach. Routing, connections between networks, congestion, server capacity, and CDN policy all affect which server is preferable. ECS provides a hint rather than a guarantee of lower latency. Measuring only the DNS lookup time cannot show whether the selected server delivers content faster.
Answers can differ even without ECS. Authoritative servers may select answers using the recursive resolver's source address, and anycast resolvers may send queries from different sites. A domain's DNS servers can also ignore ECS and return the same answer for every prefix.
Privacy Effects of Sending ECS
Any DNS server that receives an ECS option can read the client prefix it contains. Network observers can also see the prefix if the DNS connection carrying it is unencrypted.
DNS over HTTPS, DNS over TLS, or DNS over QUIC can encrypt messages between a device and its resolver. The resolver can still add ECS when it sends queries to authoritative servers. An encrypted client connection therefore does not determine what client information the resolver shares onward.
A DNS privacy service should provide a way to resolve names without sending ECS. An ECS-enabled option should be offered as a separate service, so clients can choose whether to share a prefix. For the ECS service, operators should send as few address bits as practical, restrict sharing to selected authoritative servers where possible, and explain those choices in their privacy policy.
Before enabling ECS, operators should check whether better server selection actually improves performance for their clients. They should also limit how long query logs are kept and avoid treating an ECS prefix as proof of a client's identity. A client can put a false prefix in the option, so the prefix is a hint for selecting DNS answers, not an authentication credential.
How to Interpret an ECS-Aware DNS Test
Record the resolver address, query name and type, and the time of each test. Keep the returned answer and TTL together with the ECS address family, source prefix, and response scope. Compare a normal lookup with queries that use a chosen ECS prefix only in an authorized test environment. Results from one public resolver do not establish another resolver's policy.
A changed answer alone does not prove that ECS affected the result. Cache state, rotating answers, or changes at the authoritative service can also alter responses. A repeated answer does not prove ECS was ignored because several prefixes may legitimately map to the same set of servers.
Check whether the resolver sends ECS to every authoritative server or only selected ones. Its policy should also state the IPv4 and IPv6 prefix lengths it sends, whether it honors source /0, and how long it keeps query logs. Where testing is allowed, compare the observed queries with that policy.







