EDNS Client Subnet in Practice: Evaluating Public Resolver Behaviors

When you query DNS, your resolver might be influencing geographic routing decisions behind the scenes using a technique called EDNS Client Subnet (ECS). But how do major DNS resolvers actually implement this technique? I decided to find out by testing public DNS resolvers, and the results revealed several distinct approaches to handling geographic intelligence. This article explains those behaviors and the test methodology.

What started as a weekend experiment exploring ECS behavior evolved into a deeper investigation that spanned several months. The testing uncovered unexpected variations in how resolvers handle ECS, from domain-specific behavior to private address handling quirks. While this analysis provides insights into public resolver implementations, it represents a snapshot of specific test scenarios rather than an exhaustive evaluation. The findings reflect observed behavior during testing and may not capture all edge cases or production configurations.

Summary

#

Testing 10 public DNS resolvers revealed that ECS implementation is more complex than a simple on/off feature. Half (50%) of tested resolvers use ECS when querying authoritative servers (forwarding ECS to authoritative nameservers), while only 20% include meaningful ECS information in responses back to clients. Several distinct behavior patterns emerged: 2 resolvers echo meaningful ECS information (Google mirrors authoritative responses, AdGuard mirrors input), 3 return scope/0 without forwarding (signaling no optimization), 3 forward ECS without echoing, and 2 provide no ECS support. Each pattern represents different privacy and transparency trade-offs. Google DNS zeros the host bits before echoing, while AdGuard echoes the exact address provided by clients.

Resolver behavior varies not only by implementation, but also by queried domains. Google does not forward ECS to Akamai test domains while forwarding to others, though this may reflect Akamai’s allowlist system for ECS rather than a general policy. Subnet size matters too: Google requires /24 or broader for IPv4 and /56 or broader for IPv6, rejecting more specific subnets entirely, while Quad9 ECS (9.9.9.11) accepts all subnet sizes but normalizes them to /24 for IPv4 and /56 for IPv6. Both Quad9 ECS and AdGuard forward to all tested authoritative servers, though they differ in what they forward: Quad9 forwards the explicit ECS option provided by clients, while AdGuard ignores explicit options and forwards the client’s actual subnet instead.

Testing methodology is very important. Simple echo tests (checking stub-to-resolver responses) miss resolvers that forward ECS to authoritative servers without echoing back to clients. Subnet size restrictions can appear as complete blocking. Domain-specific behavior means testing against a single authoritative server provides an incomplete picture.

Note: All the tests were performed between September and October 2025 and reflect the behavior of these resolvers during that time period.

What is EDNS Client Subnet (ECS)?

#

EDNS Client Subnet is defined in RFC 7871. An important note about this RFC is that, due to privacy implications of ECS, the workgroup has decided to mark it as an Informational RFC, meaning that it does not necessarily represent community consensus or recommendation.

The RFC describes it in Section 5 as: “an EDNS0 option to allow Recursive Resolvers, if they are willing, to forward details about the origin network from which a query is coming when talking to other nameservers.”

Without ECS, a CDN sees only the resolver’s IP address. If I’m in Tokyo using Quad9 Resolver (9.9.9.9), the CDN might direct me to a server near Quad9’s resolver infrastructure (for example in Singapore) rather than near my actual location in Tokyo, resulting in suboptimal performance.

According to RFC 7871, Section 5: “an Authoritative Nameserver could use ECS as a hint to the end user’s network location and provide a better answer. Its response would also contain an ECS option, clearly indicating that the server made use of this information, and that the answer is tied to the client’s network.”

It also explains that ECS “is meant to be added in queries sent by Intermediate Nameservers in a way that is transparent to Stub Resolvers and end users.”

An important distinction is the relationship between stub-to-resolver and resolver-to-authoritative. In a typical scenario, when a user sends a regular query to an ECS-enabled resolver, the resolver adds the ECS option when forwarding the request to an authoritative DNS server. The authoritative server decides how to process ECS and returns its decision back to the resolver. RFC 7871, Section 7.2.2 specifies that resolvers MUST NOT include an ECS option in responses to clients that did not originally send one, as “a client that did not use an ECS option might not be able to understand it.”

In this context, two ECS parameters are important:

• Source Prefix Length: The subnet mask sent in the ECS option (e.g, /24 for IPv4 or /56 for IPv6)
• Scope Prefix Length: The subnet mask returned by the resolver, indicating the specificity of the cached answer.

When an authoritative server returns ECS response to resolver, or when resolver echoes ECS back to the client, it includes both the source prefix it used and the scope prefix indicating how specific the answer is for caching purposes.

In dig or dnsping output, this appears as “address/source/scope” (e.g., 203.0.113.0/24/24 or 203.0.113.0/24/0).

According to section 7.3.1, a scope of /0 indicates “an answer suitable for all client addresses.”, meaning the answer it’s providing is not location-specific and can be cached for any client address, not just the subnet that was queried.

While most users rely on their resolver’s automatic ECS implementation, RFC 7871, Section 7.1.2 allows stubs to send ECS options: “A Stub Resolver MAY generate DNS queries with an ECS option that sets SOURCE PREFIX-LENGTH to limit how network information should be revealed.” Tools like dig, kdig or dnsping allow manual specification of ECS options with custom subnet masks for testing.

Different resolvers implement ECS differently, so choosing a resolver affects how geographic information is forwarded to authoritative servers. Enterprise users can configure recursive resolvers with specific ECS policies, while VPNs or proxies change the source IP that resolvers use for ECS calculations.

RFC 7871 acknowledges this flexibility, noting in Section 5 that “operators of Intermediate Nameservers with ECS enabled are allowed to choose how many bits of the address of received queries to forward or to reduce the number of bits forwarded for queries already including an ECS option.”

ECS Behavior Patterns

#

Analysis of ECS echo behavior in stub-to-recursive queries across major DNS resolvers uncovered distinct behavior patterns.

Google Public DNS (gpdns)

#

Google DNS enforces strict privacy boundaries by rejecting IPv4 subnets more specific than /24 and IPv6 subnets more specific than /56 with EDE error code 49152. For all domains, Google mirrors the scope responses it receives from authoritative nameservers, whether that is a specific scope value or scope/0 when the authoritative nameserver does not support ECS.

An interesting observation here is that Google’s behavior varies by transport protocol. When clients provide ECS prefixes more specific than /24 for IPv4, the unencrypted Do53 service rejects queries with a REFUSED status and error message, while the encrypted DoH and DoH3 services accept the queries but truncate the prefix to /24.

For example, testing with a /32 prefix against Google’s test server:

# Do53 (unencrypted) - REFUSED with EDE error
$ kdig @8.8.8.8 +subnet=185.199.109.1/32 TXT o-o.myaddr.l.google.com
; status: REFUSED
; EDE: 49152: 'Provided ECS includes 32 bits, but no more than 24 are allowed.'

# DoH (encrypted) - Accepted, truncated to /24
$ kdig @8.8.8.8 +https +subnet=185.199.109.1/32 TXT o-o.myaddr.l.google.com
; status: NOERROR
"edns0-client-subnet 185.199.109.0/24"

RFC 8932 Section 5.1.6 states that “A DNS privacy service should deliver the same level of service as offered on unencrypted channels in terms of options such as filtering (or lack thereof), DNSSEC validation, etc.” This difference in handling between encrypted and unencrypted channels represents an implementation choice that may not align with this recommendation.

Testing across multiple domains confirms consistent mirroring behavior. Domains with ECS-enabled authoritative nameservers (such as google.com, netflix.com, cloudflare.com) show scope values echoed through Google DNS that match the authoritative responses. Domains without ECS support at the authoritative level (such as apple.com, amazon.com) consistently return scope/0 from both the authoritative nameserver and Google DNS. This demonstrates that Google acts as a transparent proxy for ECS scope information, faithfully mirroring what authoritative nameservers return regardless of the domain.

AdGuard DNS

#

AdGuard DNS mirrors the input scope exactly in responses back to clients, but forwards the client’s actual subnet to authoritative servers (ignoring any explicit ECS options). For example, when querying with a /32 prefix, AdGuard echoes back scope/32 to the client, but authoritative server testing reveals it forwards the client’s actual /24 subnet:

$ dig @94.140.14.14 +subnet=203.0.113.100/32 TXT whoami-ecs.lua.powerdns.org
; CLIENT-SUBNET: 203.0.113.100/32/32
"ip: 79.127.211.213, netmask: 213.124.12.0/24"

Control D, Verisign, Neustar

#

These resolvers return scope /0 in responses back to clients and do not forward ECS information to authoritative servers. For example, querying Control D against an authoritative test server shows scope/0 echoed back while the authoritative server confirms no ECS was received:

$ dig @76.76.2.11 +subnet=203.0.113.0/24 TXT whoami-ecs.lua.powerdns.org
; CLIENT-SUBNET: 203.0.113.0/24/0
"ip: 2a00:dd80:3c::b01, netmask: no ECS"

While RFC 7871 defines scope/0 as indicating an answer suitable for all client addresses, in this case it effectively signals that no geographic optimization is being performed.

Cloudflare, Quad9, OpenDNS

#

Forward-only ECS behavior that provides no feedback to clients. These resolvers forward ECS information to authoritative servers for geographic optimization but don’t include ECS options in responses back to clients. Authoritative server testing confirms these resolvers actively send ECS information when querying authoritative servers.

DNS.SB, NextDNS

#

No ECS support. These resolvers neither forward nor echo ECS information. Queries with ECS options receive responses identical to queries without ECS, and authoritative server testing confirms no ECS information is forwarded.

Verifying ECS Behavior with Authoritative Testing

#

To verify whether “silent” resolvers actually forward ECS information to authoritative servers, I tested against multiple authoritative whoami services: Akamai’s whoami service (whoami.ds.akahelp.net), Google MyAddr (o-o.myaddr.l.google.com), and PowerDNS whoami service (whoami-ecs.lua.powerdns.org). These services return TXT records showing what information authoritative servers actually receive from recursive resolvers. This testing is also useful to verify whether the information echoed back to clients is actually forwarded to authoritative servers intact, modified, or discarded.

Authoritative Server Test Results

#

Testing revealed that resolver behavior varies significantly by authoritative domain:

• Quad9 ECS (9.9.9.11): Consistently forwards the explicit ECS subnet provided by the client to all tested authoritative servers. When SOURCE PREFIX-LENGTH is 0, forwards the resolver’s own outbound IP address instead of the client’s subnet.
• Google (8.8.8.8): Blocks ECS forwarding to Akamai test domains but forwards to Google MyAddr and PowerDNS.
• AdGuard (94.140.14.14): Ignores explicit ECS options and always forwards the client’s actual subnet to all authoritative servers (normalized to /24 for IPv4 and /56 for IPv6).
• Cloudflare (1.1.1.1): Forwards client’s actual subnet to Akamai but strips ECS entirely for Google MyAddr and PowerDNS.
• OpenDNS (208.67.220.220): Forwards client’s actual subnet to Akamai, forwards scope/0 to Google MyAddr, and no ECS to PowerDNS.

The following table summarizes what each resolver actually forwards to different authoritative test services when the client sends an explicit ECS option (test configuration: 185.199.109.0/24). Note that Akamai column reflects behavior against whoami.ds.akahelp.net, which may differ from production Akamai CDN domains due to allowlist configurations:

Table legend:

• Forwarded: Resolver normalized and forwarded the explicit ECS option provided by the client to the authoritative server
• Client subnet: Resolver ignored the explicit ECS option and instead normalized and forwarded the client’s actual subnet to the authoritative server
• Blocked: Resolver sent no ECS information to the authoritative server (but may echo back to client)
• Stripped: Resolver removed ECS entirely from both the query to authoritative server and the response to client
• Scope/0: Forwarded ECS with scope prefix length 0 to the authoritative server
• No ECS: Authoritative server received no ECS information

Google’s Domain-Specific Filtering

#

Google implements domain-based ECS filtering. Testing shows:

• Akamai test domains (whoami.ds.akahelp.net): Blocks all explicit ECS
• Other domains (Google MyAddr, PowerDNS, Cloudflare): Forwards ECS when subnet size requirements are met

According to research (A Look at the ECS Behavior of DNS Resolvers), Akamai appears to use an allowlist system for ECS support based on business agreements between resolver operators and the CDN. Public resolvers like Google and OpenDNS are observed to maintain their own lists of approved domains to which they forward ECS information. The absence of ECS forwarding observed in testing may reflect that the test domains are not part of these established relationships, rather than representing a blanket policy against Akamai domains.

Testing Commands:

# Test what authoritative servers receive from Quad9
dig +short @9.9.9.11 +subnet=185.199.109.0/24 TXT whoami.ds.akahelp.net

# Test Google with Akamai test service (no ECS forwarded)
dig +short @8.8.8.8 +subnet=185.199.109.0/24 TXT whoami.ds.akahelp.net  # No response

# Test Google forwarding to other domains
dig +short @8.8.8.8 +subnet=185.199.109.0/24 TXT o-o.myaddr.l.google.com  # Forwarded

# Test with insufficient subnet size (will be blocked)
dig +short @8.8.8.8 +subnet=185.199.109.1/32 TXT o-o.myaddr.l.google.com  # No response

Testing Methodology

#

I used the dnsping tool with ECS testing across multiple subnet sizes.

Running the examples:

The examples below use dnsping.py which requires installing dnsdiag (pip install dnsdiag or uv tool install dnsdiag). Alternatively, you can run the examples without installation by replacing dnsping.py with uvx --from dnsdiag dnsping in any command.

Test Parameters:

• Primary Test: 203.0.113.0/24 (RFC 5737 documentation range)
• Authoritative Testing: 185.199.109.0/24 for IPv4, 2001:420:1101:1::/56 for IPv6 (neutral public addresses)
• Extended Testing: Multiple subnet masks (/16, /24, /26, /32 for IPv4; /48, /56, /64, /128 for IPv6)
• Query Target: google.com A record (plus comparative runs against third-party names like nlnog.net to spot domain-dependent scope policies)
• Tool: dnsping with --ecs option

Example Test Commands:

# Test basic ECS echo behavior
dnsping.py -c 1 -s 8.8.8.8 --ecs 203.0.113.0/24 google.com

# Compare with AdGuard's mirroring
dnsping.py -c 1 -s 94.140.14.14 --ecs 203.0.113.100/32 google.com

# Test IPv6 ECS behavior (use real addresses with /56 or broader)
dnsping.py -c 1 -s 8.8.8.8 --ecs 2001:420:1101:1::/56 google.com

Extended Subnet Mask Testing Results

#

IPv4 Subnet Size Analysis

#

Google mirrors authoritative nameserver scope responses rather than normalizing. Quad9 ECS normalizes to /24 minimum.

IPv6 Subnet Size Analysis

#

Quad9 ECS normalizes to /56 minimum.

Private Address Handling

#

While testing, I was curious about how resolvers handle private IP addresses in ECS requests - a simple test that revealed some interesting behavioral differences.

Private IPv4 Results (RFC 1918, RFC 6598)

#

Private IPv6 Results (RFC 4193, RFC 4291)

#

Observations

#

Google DNS consistently rejects private addresses (RFC 1918 IPv4, RFC 6598 CGNAT, and RFC 4193/4291 IPv6), providing the strongest privacy protection by refusing to process queries with private subnets. Control D, Verisign, and Neustar return scope/0 and do not forward any ECS information to authoritative servers, effectively providing privacy by not participating in ECS at all.

Quad9 ECS returns scope/0 to clients but forwards private addresses to authoritative servers after normalization. Organizations using Quad9 ECS (9.9.9.11) with private IP ranges should understand that their private addressing information is forwarded to authoritative nameservers. Those requiring complete privacy for private addresses should consider using Quad9’s non-ECS resolver (9.9.9.9) or other resolvers that don’t forward ECS.

AdGuard exhibits dual behavior by echoing the private address prefix in client responses while forwarding the actual client subnet to authoritative servers.

Practical Guidance

#

Testing ECS Behavior

#

Testing ECS requires careful methodology to account for resolver variations. Use multiple subnet sizes ranging from broad prefixes like /16 to specific ones like /32 for IPv4, and similarly varied ranges for IPv6. Test against multiple authoritative whoami services rather than a single domain, as resolver behavior varies by authoritative domain. Business agreements and allowlist systems affect which resolvers forward ECS to which authoritative servers, meaning test results against whoami services may not reflect production CDN behavior. Use real public IP addresses rather than RFC 5737 documentation ranges or private addresses, since some resolvers filter these specially.

For Network Administrators

#

When selecting public DNS resolvers for enterprise environments, balance CDN performance needs against privacy requirements. Quad9 ECS (9.9.9.11) consistently forwards ECS across all tested authoritative servers, while Google DNS does not forward ECS to some domains. Organizations should verify ECS behavior with their specific CDN providers rather than relying on general testing. For privacy-sensitive environments, Google DNS rejects private addresses entirely, while Quad9 ECS forwards them after normalization. Organizations concerned about exposing internal network structure should consider Quad9’s non-ECS resolver (9.9.9.9) or resolvers like Control D, Verisign, and Neustar that don’t forward ECS at all. The fundamental trade-off is that resolvers without ECS support maximize privacy but may result in suboptimal CDN performance.

For CDN Operators

#

ECS support among public resolvers is fragmented. Quad9 ECS, AdGuard, and Google DNS forward to all or most authoritative servers, though their implementations differ: Quad9 forwards explicit ECS options, AdGuard forwards client subnets regardless of explicit options, and Google does not forward to all domains. The research cited earlier indicates that some CDN providers use allowlist systems requiring business agreements with resolver operators. When implementing ECS support, CDN operators benefit the broader internet ecosystem by supporting ECS universally rather than limiting it to specific resolver operators through business agreements. Transparent documentation of ECS support helps network administrators make informed decisions.

When implementing ECS on authoritative servers, scope prefix length in responses indicates geographic decision granularity. Returning scope /24 for IPv4 or /56 for IPv6 tells resolvers the answer applies to that entire subnet, affecting cache efficiency. Some resolvers like AdGuard ignore explicit ECS options and send the client’s actual subnet instead, so implementations should handle both explicit ECS options and resolver-derived subnets appropriately.

For Privacy-Conscious Users

#

Understanding the distinction between echo behavior and forwarding behavior is essential. Resolvers that don’t echo ECS back to clients may still forward it to authoritative servers. Conversely, seeing scope/0 in responses does not guarantee privacy protection since some resolvers return scope/0 while still forwarding ECS information to authoritative servers. Users prioritizing privacy should choose resolvers that neither echo nor forward ECS, understanding this trades CDN optimization for privacy. Quad9 offers both ECS-enabled (9.9.9.11) and non-ECS (9.9.9.9) addresses for informed choice.

For Resolver Operators

#

When deploying or operating DNS resolvers, respect user-expressed preferences in ECS options. RFC 7871 Section 7.1.2 allows stub resolvers to set SOURCE PREFIX-LENGTH to 0 to indicate they don’t want network information revealed. Resolver implementations should honor these privacy signals rather than overriding them. Note that even when SOURCE PREFIX-LENGTH is 0, some resolvers still send geographic information to authoritative servers by forwarding the resolver’s own IP address rather than the client’s subnet. While this provides some privacy protection by not revealing the client’s network location, it may not fully honor the privacy signal as some users might expect, since authoritative servers still receive location information based on the resolver’s geographic position.

Conclusions

#

This analysis reveals that ECS implementation is far more nuanced than a simple “supported” or “not supported” binary. The combination of ECS echo testing and authoritative server verification shows several distinct behavior patterns representing different approaches to balancing geographic optimization, transparency, and privacy. The internet’s DNS infrastructure shows different approaches to geographic intelligence. Understanding these differences helps network operators make informed decisions about resolver selection and CDN optimization strategies.

As internet infrastructure evolves, ECS implementation differences will continue to be important for performance optimization and privacy considerations. This analysis demonstrates the value of comprehensive, multi-dimensional testing in understanding real-world DNS behavior.

RFC 7871 acknowledges the complexity inherent in ECS implementations, noting that “the expectation, however, is that this option will primarily be used between Recursive Resolvers and Authoritative Nameservers that are sensitive to network location issues. Most Recursive Resolvers, Authoritative Nameservers, and Stub Resolvers will never need to know about this option and will continue working as they had been.”

However this assumption may no longer be true. Given the dominance of resolvers like Google (8.8.8.8), Quad9 (9.9.9.9) and Cloudflare (1.1.1.1), combined with widespread CDN usage, a substantial portion of global DNS queries likely involve ECS. As encrypted DNS protocols (DoH, DoT and hopefully soon DoQ) become more prevalent for stub-to-resolver communication, the privacy implications of ECS become increasingly relevant. While encryption between stubs and resolvers addresses one privacy concern, the resolver-to-authoritative path remains largely unencrypted, meaning ECS information is still transmitted in clear text. Encrypting resolver-to-authoritative communication could mitigate some of these privacy concerns, though deployment challenges remain.

Acknowledgements

#

I am grateful to Sara Dickinson and Stephen Strowes for taking the time to review drafts of this article and providing valuable feedback and corrections. Their insights significantly improved the accuracy and clarity of this analysis. Any remaining errors or inaccuracies are entirely my own.