Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to EDNS Client Subnet.
Nothing was collected or created yet.
EDNS Client Subnet
View on Wikipediafrom Wikipedia
 | This article may be too technical for most readers to understand. (February 2024) |
EDNS Client Subnet (ECS) is an option in the Extension Mechanisms for DNS that allows a recursive DNS resolver to specify the subnetwork for the host or client on whose behalf it is making a DNS query. This is generally intended to help speed up the delivery of data from content delivery networks (CDNs), by allowing better use of DNS-based load balancing to select a service address near the client when the client computer is not necessarily near the recursive resolver.[1][2]
When an authoritative name server receives a DNS query, it takes advantage of ECS DNS extension to resolve the hostname to a CDN which is geolocated near to the client IP's subnet, hence the client makes further requests to a nearby CDN, thereby reducing latency. The EDNS client subnet mechanism is specified in RFC 7871.
Privacy and security implications
[edit]Because ECS provides client network information to the upstream authoritative DNS server, the extension reveals some information about the client's location that the authoritative DNS server would not otherwise be able to deduce. The same client network information also becomes available to transit networks between the client's recursive and the domain's authoritative server.[3] Security researchers have suggested that ECS could be used to conduct internet surveillance.[3] ECS may also be exploited to perform selective DNS cache poisoning attacks intended to only re-route specific clients to a poisoned DNS record.[3]
Controversy over lack of support
[edit]The owner of self-serve web archiving tool Archive.today has expressed concern over Cloudflare 1.1.1.1 not passing the contents of this field on to the authoritative DNS server for Archive.today, and has in response configured the site's authoritative DNS servers to consider Cloudflare DNS requests invalid—effectively blocking 1.1.1.1 from resolving the website DNS records.[4]
The owner of the site believes 1.1.1.1 too often routes recursive DNS requests in a non-geographically-optimal way, causing poorer connectivity than if the feature was available at all times.[4]
Cloudflare CEO Matthew Prince cited privacy concerns as reason for 1.1.1.1 to not support ECS.[5]
References
[edit]- ^ "How it works". A Faster Internet. Archived from the original on 2018-03-28. Retrieved 2018-03-27.
- ^ "EDNS Client Subnet (ECS) Guidelines | Public DNS | Google Developers". Google Developers. Retrieved 2018-04-02.
- ^ a b c Kintis P, Nadji Y, Dagon D, Farrell M, Antonakakis M (June 2016). "Understanding the Privacy Implications of ECS" (PDF). Detection of Intrusions and Malware, and Vulnerability Assessment. Lecture Notes in Computer Science. Vol. 9721. Springer. pp. 343–353. doi:10.1007/978-3-319-40667-1_17. ISBN 978-3-319-40667-1.
- ^ a b @archiveis (July 16, 2018). ""Having to do" is not so direct here" (Tweet) – via Twitter.
Absence of EDNS and massive mismatch (not only on AS/Country, but even on the continent level) of where DNS and related HTTP requests come from causes so many troubles so I consider EDNS-less requests from Cloudflare as invalid.
- ^ Matthew Prince (4 May 2019). "Comment by Matthew Prince on Hacker News". Hacker News. Retrieved 4 October 2021.
The archive.is owner has explained that he returns bad results to us because we don't pass along the EDNS subnet information. This information leaks information about a requester's IP and, in turn, sacrifices the privacy of users. This is especially problematic as we work to encrypt more DNS traffic since the request from Resolver to Authoritative DNS is typically unencrypted. We're aware of real world examples where nationstate actors have monitored EDNS subnet information to track individuals, which was part of the motivation for the privacy and security policies of 1.1.1.1.
 | This Internet-related article is a stub. You can help Wikipedia by adding missing information. |
EDNS Client Subnet
View on Grokipediafrom Grokipedia
Overview
Definition and Purpose
The EDNS Client Subnet (ECS), designated as EDNS(0) option code 8, is a DNS protocol extension that permits recursive resolvers to append subnet information representing the originating client's network address to upstream queries directed at authoritative name servers.[1] This option specifies the address family (IPv4 or IPv6), a source prefix length denoting the subnet's granularity (e.g., 24 bits for /24 IPv4 subnets), and the corresponding truncated address bits, thereby conveying an anonymized approximation of the client's location without exposing the full IP address.[1] The core purpose of ECS is to enhance the relevance and performance of DNS responses for topology-aware applications, such as content delivery networks (CDNs), by allowing authoritative servers to select endpoints (e.g., anycast nodes or cached content) closer to the client's actual network position rather than the resolver's.[1] Traditional DNS queries from centralized recursive resolvers can yield suboptimal results, as authoritative servers geolocate based on the resolver's IP, potentially directing users to distant servers and increasing latency; ECS mitigates this by providing client subnet data, enabling finer-grained load balancing and reduced round-trip times.[1] Responses from authoritative servers may reciprocate with a scope prefix length (e.g., 0 for global validity or higher for subnet-specific caching), instructing intermediate resolvers on the appropriate caching duration and scope to preserve response accuracy across similar client queries.[1] While ECS prioritizes performance gains, it introduces privacy trade-offs by revealing partial client location data, addressed through prefix truncation to limit precision (e.g., /56 for IPv6) and an opt-out via source prefix length of 0, though adoption of the latter remains inconsistent.[1] Standardized in RFC 7871 (published May 2016), ECS builds on earlier proposals from 2011 by DNS and CDN operators to resolve practical deployment challenges in global-scale resolution.[1][5]Core Mechanism
The EDNS Client Subnet (ECS) operates as an Extension Mechanisms for DNS (EDNS(0)) option with code 8, enabling recursive resolvers to append subnet information from the originating client to queries directed at authoritative name servers.[1] This allows authoritative servers to deliver location-aware responses, such as IP addresses for proximate content delivery network endpoints, while the mechanism remains opaque to stub resolvers.[1] The option is optional; servers lacking support ignore it without error.[1] In queries, recursive resolvers construct the ECS option by specifying the address family (1 for IPv4, 2 for IPv6), source prefix length (the number of significant leading bits from the client address, typically 24 for IPv4 and 56 for IPv6 to approximate location while limiting precision), scope prefix length (set to 0), and the corresponding truncated address padded with zeros to align with the family length.[1] Recursive resolvers may further restrict the source prefix length based on client preferences or policy, such as setting it to 0 to withhold subnet details entirely.[1] Authoritative servers receiving such a query evaluate the subnet against their data—often via probing or whitelisting to confirm support—and generate responses optimized for that network segment.[1] Responses from authoritative servers may include a reciprocal ECS option, echoing the query's family, source prefix length, and address fields while setting the scope prefix length to the coarsest prefix (e.g., /16 for IPv4) over which the response applies uniformly, ensuring broader cache validity.[1] Recursive resolvers cache these responses keyed to the scope prefix, applying longest-prefix matching for future queries from clients within matching subnets to reuse location-specific data efficiently.[1] Caches must handle prefix overlaps by prioritizing finer-grained entries and limit stored networks to prevent pollution.[1] The ECS option format comprises the following fields:| Field | Size (octets) | Description |
|---|---|---|
| OPTION-CODE | 2 | Fixed value 8 (0x0008).[1] |
| OPTION-LENGTH | 2 | Length of subsequent data excluding code and length.[1] |
| FAMILY | 2 | Address family number (1 for IPv4, 2 for IPv6).[1] |
| SOURCE PREFIX-LENGTH | 1 | Bits of ADDRESS considered significant for the query origin.[1] |
| SCOPE PREFIX-LENGTH | 1 | 0 in queries; in responses, the prefix length for response applicability (must not exceed source prefix length).[1] |
| ADDRESS | Variable | Truncated client subnet address, zero-padded to full family length if needed.[1] |
History
Initial Proposal and Development
The EDNS Client Subnet (ECS) option was initially proposed in January 2011 through an individual Internet-Draft titled "Client Subnet in DNS Requests" (draft-vandergaast-edns-client-subnet-00), developed collaboratively by engineers from Google, VeriSign, and Neustar to address limitations in DNS-based geolocation and anycast routing for content delivery networks (CDNs).[6] The primary motivation stemmed from the topological mismatch between clients and recursive resolvers: when end-user queries pass through centralized or third-party resolvers distant from the client, authoritative servers receive incomplete location data, leading to suboptimal IP address returns for services like CDNs, which rely on DNS for directing traffic to nearby edge servers.[7] Subsequent revisions, such as draft-vandergaast-edns-client-subnet-01 published on April 25, 2012, refined the mechanism, specifying an EDNS0 option format with fields for address family, source prefix length, scope prefix length, and the truncated client IP address to balance utility with privacy by anonymizing to subnet levels (e.g., /24 for IPv4).[7] Key contributors to the initial drafts included Carlo Contavalli and Wilmer van der Gaast from Google, alongside Sean Leach from VeriSign and Edward Lewis from Neustar, reflecting input from major DNS operators facing real-world deployment challenges with recursive resolution aggregating queries from diverse client subnets.[7] The proposal emphasized voluntary adoption by resolvers, with authoritative servers optionally using the subnet data to customize responses while adhering to caching rules tied to the scope prefix, ensuring cache consistency across similar client networks without exposing full client IPs. Early experimental implementations emerged shortly after the 2011 draft, with Google Public DNS enabling ECS support to forward partial client subnet information, demonstrating practical benefits for latency-sensitive applications before formal standards work.[1] Development progressed through iterative individual submissions, including draft-vandergaast-edns-client-subnet-02 in July 2013, amid growing adoption by CDNs and resolvers seeking empirical validation of geolocation improvements.[1] By 2014, the effort transitioned to the IETF's DNS Operations (dnsop) Working Group as draft-ietf-dnsop-edns-client-subnet-00 in May 2015, incorporating feedback on privacy, caching semantics, and interoperability from at least a dozen pre-RFC implementations in production environments.[8] This phase addressed edge cases like varying truncation behaviors and resolver policies, culminating in RFC 7871 published in May 2016, which documented the option (code 8) for carrying origin network details while noting ongoing refinements for production-scale use.[1] The process highlighted tensions between enhanced resolution accuracy and risks like reduced cache hit rates or privacy leakage, with the specification recommending configurable opt-in to mitigate authoritative server overload.[1]Standardization Process
The EDNS Client Subnet mechanism originated as an individual submission to the Internet Engineering Task Force (IETF) in the form of Internet-Draft draft-vandergaast-edns-client-subnet-00, authored primarily by Wilmer van der Gaast of Google and released on January 27, 2011.[9] This initial draft outlined an EDNS0 option to convey partial client IP subnet information from recursive resolvers to authoritative DNS servers, addressing limitations in anycast-based geolocation for content delivery. Revisions followed, with draft-01 published on April 25, 2012, and draft-02 on July 5, 2013, incorporating refinements to option encoding, scope handling, and privacy considerations based on early implementation feedback.[9] The draft gained traction through operational deployments by entities like Google Public DNS prior to formal IETF adoption, prompting its advancement within the DNS Operations (DNSOP) Working Group.[10] Adoption occurred after discussions on interoperability and risks, leading to the first working group version, draft-ietf-dnsop-edns-client-subnet-00, on May 19, 2015, under expanded authorship including Carlo Contavalli, David C. Lawrence, and Warren Kumari.[8] The working group process involved iterative reviews addressing concerns such as subnet truncation rules, response scoping, and compatibility with DNSSEC, resulting in eight versions through April 2016.[10] Following IESG approval, the specification was published as RFC 7871, "Client Subnet in DNS Queries," on May 20, 2016.[11] Authored by Contavalli, van der Gaast, Lawrence, and Kumari, the RFC holds Informational status rather than Standards Track, reflecting its documentation of a pre-existing, widely implemented extension rather than a protocol requiring consensus for interoperability.[12] This status acknowledges operational realities, including privacy implications from subnet leakage, while noting the mechanism's active use by recursive resolvers and authoritative servers.[1] No subsequent standards-track update has been issued as of 2025, though errata and implementation guidelines have been maintained.[13]Technical Specification
EDNS Option Structure
The EDNS Client Subnet (ECS) option is encoded within the Extension Mechanisms for DNS (EDNS(0)) OPT pseudo-resource record as a variable-length option, following the standard EDNS option format consisting of a 2-octet OPTION-CODE field set to 8 (indicating ECS) and a 2-octet OPTION-LENGTH field specifying the length of the subsequent data in octets.[14] This structure enables recursive resolvers to convey partial client IP address information to authoritative servers for improved geolocation-based responses, while limiting disclosure to subnet prefixes rather than full addresses.[14] The payload begins with a 2-octet FAMILY field, which identifies the address family of the subsequent ADDRESS field using values from the IANA Address Family Numbers registry: 1 for IPv4 (Internet Protocol version 4) and 2 for IPv6 (Internet Protocol version 6).[14] This is followed by two 1-octet fields: SOURCE PREFIX-LENGTH, representing the number of significant prefix bits from the client address provided for query routing (ranging from 0 to 32 for IPv4 or 0 to 128 for IPv6), and SCOPE PREFIX-LENGTH, which is set to 0 in queries but may be populated in responses by authoritative servers to indicate the prefix length of the address used for the response computation.[14] The ADDRESS field then contains the truncated IP address prefix matching the FAMILY and SOURCE PREFIX-LENGTH, with the full address length (4 octets for IPv4, 16 octets for IPv6) padded with zeros beyond the significant bits; any non-zero bits in the padded portion render the option invalid, prompting a FORMERR response.[14] All multi-octet fields use network byte order (big-endian). The wire format is as follows:+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | [FAMILY](/page/Family) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: | ADDRESS... /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | [FAMILY](/page/Family) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: | ADDRESS... /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Query Processing and Response Rules
Recursive resolvers process incoming client queries by optionally including an EDNS Client Subnet (ECS) option in forwarded queries to authoritative name servers, derived from the client's source IP address.[1] The option specifies the address family (FAMILY: 1 for IPv4, 2 for IPv6), the source prefix-length (SOURCE PREFIX-LENGTH: number of significant bits from the client's address, truncated to a maximum of 24 bits for IPv4 or 56 bits for IPv6 to balance privacy and utility), and the truncated address (ADDRESS: padded with zeros beyond the prefix).[16] If the client query itself contains an ECS option, the resolver uses the shorter of the client's SOURCE PREFIX-LENGTH or the maximum cacheable length; otherwise, it defaults to the client's full subnet approximation.[16] The SCOPE PREFIX-LENGTH in outgoing queries is set to 0, indicating no restriction on the response's applicability.[16] Authoritative servers receiving a query with an ECS option evaluate the provided subnet to generate location-specific responses, such as selecting anycast instances or content delivery networks closer to the indicated client location.[17] If supported, the response includes a matching ECS option with the same FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS from the query, but sets SCOPE PREFIX-LENGTH to the length of the network scope for which the response is valid (0 if applicable to any client, or longer if tied to a specific subnet).[17] Servers must avoid overlapping scopes by deaggregating records if necessary and are prohibited from increasing the SOURCE PREFIX-LENGTH beyond the query's value.[17] Unsupported servers may ignore the option or return FORMERR/REFUSED; upon REFUSED, resolvers retry without ECS to differentiate from query errors.[16] All authoritative servers for an ECS-enabled zone must consistently support the option to prevent inconsistent responses.[3] Caching rules ensure responses are stored and reused appropriately based on subnet specificity. Recursive resolvers cache responses keyed to the effective prefix: if SCOPE PREFIX-LENGTH exceeds the maximum cacheable length, cache using SCOPE PREFIX-LENGTH truncated to that limit with masked address bits; otherwise, use SOURCE PREFIX-LENGTH.[18] Mismatches in FAMILY, SOURCE PREFIX-LENGTH, or ADDRESS between query and response invalidate cached entries, preventing incorrect reuse across subnets.[18] Responses without ECS are cached universally, while those with ECS are subnet-specific, enhancing hit rates for localized content without overgeneralizing.[18]Adoption and Deployment
Support by Recursive Resolvers
PowerDNS Recursor has provided support for EDNS Client Subnet (ECS) since its early implementations, with significant enhancements introduced in version 4.2.0 on February 1, 2019, including configurable options likeecs-add-for to specify when and how client subnet information is added to outgoing queries.[19] This allows operators to forward partial client IP subnets to authoritative servers for improved geolocation in responses.[20]
Unbound, developed by NLnet Labs, supports ECS when compiled with the --enable-subnet flag, enabling the module to process and forward client subnet data in recursive queries as configured in unbound.conf.[21] Version 1.23.1, released on July 16, 2025, addressed vulnerabilities affecting ECS-supporting caching resolvers, confirming ongoing maintenance of the feature.[22]
BIND 9 from ISC offers ECS support for recursive resolvers exclusively in the BIND Supported Preview (-S) edition, introduced around October 26, 2023, and unavailable in public releases as of June 12, 2025, due to commercial licensing restrictions.[23] Standard BIND versions handle ECS primarily as an authoritative server or for receiving the option, but lack full forwarding capabilities in recursive mode without the preview edition.[24]
Among public recursive DNS services, Google Public DNS has supported ECS since its standardization in RFC 7871, using it to send partial client subnets while auto-detecting authoritative server compatibility via IP address.[3] Similarly, services like NextDNS and AdGuard DNS implement ECS with privacy mitigations, such as anonymizing subnets to /24 for IPv4 or larger prefixes to reduce leakage.[25] Adoption remains selective, as some operators like Quad9 emphasize privacy by avoiding or limiting ECS to prevent client IP exposure.[26] Overall, while open-source resolvers like PowerDNS and Unbound enable ECS through configuration, widespread deployment lags due to concerns over cache fragmentation and privacy risks.[25]