EDNS Client Subnet (ECS)
A DNS authority normally sees the recursive resolver asking a question, not the device that caused it. That protects the device's address, but it can also make a CDN choose an endpoint near the resolver instead of near the user. EDNS Client Subnet lets a resolver attach part of the client network to a DNS query so that the answer can be tailored by location.
Why ECS Exists
A normal recursive DNS lookup has at least three parties:
Without ECS, the authoritative service sees only the resolver's source address. If a user in Hamburg uses a resolver whose query leaves the network in Frankfurt, a CDN may return a Frankfurt endpoint. That may be acceptable. With a more distant public resolver, a central enterprise resolver or an SSE gateway resolving on behalf of users in several countries, the difference can become significant.
RFC 7871 defines ECS as EDNS option 8. The resolver can include a truncated network prefix associated with the client. An ECS-aware authoritative service may then use that prefix when choosing an A, AAAA or HTTPS answer.
What the ECS Option Contains
| Field | Meaning |
|---|---|
FAMILY | IPv4 or IPv6. |
SOURCE PREFIX-LENGTH | How many leading address bits the query discloses. |
SCOPE PREFIX-LENGTH | In a response, the network range for which the tailored answer may be reused. Queries MUST set this field to zero. |
ADDRESS | Only the bytes required for the source prefix, with the remaining address bits omitted. |
Suppose the client's address is 198.51.100.37 and the resolver applies the
commonly recommended IPv4 limit of 24 bits. It sends:
family: IPv4 source prefix: 24 address: 198.51.100.0 scope in query: 0
The authority learns the 198.51.100.0/24 network, not the final
.37 host address. RFC 7871 strongly encourages truncating IPv4 to no more
than /24 and recommends /56 for IPv6. A resolver may choose
shorter prefixes for more privacy, send a zero-length prefix to disclose no network, or
omit ECS entirely.
Source Prefix and Response Scope Are Different
The source prefix says what approximate client network was used to select the answer. The response scope says how broadly that answer is valid for caching.
If an authority receives 198.51.100.0/24 but returns a scope of
/20, it is saying that the same answer can be reused for clients throughout
the wider containing /20. A scope of /0 means the answer is
global and independent of client location.
Correct scope handling matters. A recursive resolver must not serve an endpoint selected for one client network to an unrelated network when the authoritative response gave it a narrower scope. Conversely, storing a separate answer for every source prefix when the scope is global wastes cache capacity.
What ECS Can Improve
ECS affects only decisions made from DNS. The web server still sees the transport source address that connected to it. If an SSE gateway opens the upstream connection, the origin sees the gateway's address, not the user's, unless a separate trusted application-layer mechanism conveys client information. ECS cannot make fraud detection, storefront selection or legal controls based on the HTTP connection behave as if the user connected directly.
Privacy and Operational Costs
ECS intentionally crosses a privacy boundary. Without it, an authoritative DNS operator normally sees the resolver. With it, that operator sees an approximate client network. The prefix can still reveal a city, access provider, enterprise site or other useful location information.
More specific prefixes also fragment recursive caches. Clients in different prefixes may need separate lookups and separate cached answers, increasing authoritative query volume and reducing cache efficiency. For those reasons, more detail is not automatically better. A deployment should send the coarsest trusted location context that produces a useful routing improvement, and only through resolvers whose ECS behavior is understood.
ECS is not proof of identity or location. A resolver can insert a prefix unrelated to its transport address, and an authoritative server generally cannot authenticate the person or device behind it. Treat ECS as routing context, not as a security credential.
What Changes with an SSE Gateway
An SSE design may involve two DNS stages. First, the client's resolver asks where the browser should connect. Later, after accepting an inspected connection, the gateway resolves the real origin for its own upstream connection.
If the first answer directs every client to the gateway, it may be identical everywhere. The second lookup is the one that selects the CDN endpoint the gateway will actually use. Without client context, all users may receive answers selected for the gateway or its resolver. With a bounded ECS policy, the gateway can preserve enough of the client network to obtain the appropriate regional answer while still limiting disclosure.
This requires more than adding an option to the outgoing packet. DNS caches and concurrent lookups must also be separated by the effective client prefix, then shared according to the scope returned by the authority. An address, HTTPS record and ECH configuration chosen for one CDN or region must not be combined with records from another client context.
How to Read the SSE TestCenter Result
The DNS and Web Visibility test records the ECS option exactly as it arrives at the TestCenter's authoritative DNS service. It then compares the advertised prefix with the source address of the web connection that reaches the TestCenter.
The TestCenter cannot determine where the ECS value originated. It may have come from the device, a recursive resolver, an enterprise DNS service or an SSE gateway. It also cannot prove that a CDN used the option. The result shows what the authoritative service received, which is the evidence needed before drawing any broader conclusion.
Further Reading