Wiki · Concept · Last reviewed June 25, 2026

EDNS Client Subnet

EDNS Client Subnet is the RFC 7871 DNS option for attaching partial client-network information to recursive DNS queries so authoritative servers can return topology-sensitive answers.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DNS, EDNS, ECS, privacy, metadata, CDN, agents, surveillance

Definition

EDNS Client Subnet, usually shortened to ECS, is defined by RFC 7871, Client Subnet in DNS Queries, published in May 2016 as an Informational RFC. The document describes an EDNS0 option already in active use to carry information about the network that originated a DNS query and the network scope for which the response can be cached.

ECS exists because many authoritative name servers, especially those serving latency-sensitive or content-delivery systems, return different answers based on where they believe the user is located in network topology. When clients use centralized recursive resolvers, the authoritative server may see the resolver's address rather than an address near the end user. ECS gives the recursive resolver a way to send a truncated client network prefix as a routing hint.

Mechanism

RFC 6891 defines Extension Mechanisms for DNS, or EDNS(0), as a backward-compatible way for DNS to carry additional data through the OPT pseudo-resource-record. RFC 7871 uses that framework and assigns EDNS option code 8 to edns-client-subnet.

The ECS option contains a family field, a source prefix length, a scope prefix length, and an address field. RFC 7871 defines the address formats for IPv4 and IPv6. A recursive resolver normally adds ECS when querying an authoritative name server, truncating the address to a configured prefix length. The authoritative server may use that prefix as a hint and can return an ECS scope prefix that tells the resolver which client network range the answer covers.

The opt-out path is also explicit. A stub resolver may send ECS with SOURCE PREFIX-LENGTH set to 0, and an intermediate name server receiving that signal must not add client address information to its outgoing query.

Privacy Boundary

ECS is a metadata trade. It can improve DNS-based routing, but it deliberately sends client-network information beyond the recursive resolver. RFC 7871 says the client network address becomes visible to every server involved in the resolution process and to any network traversed by the DNS packets. It recommends concealing part of the address: 24-bit IPv4 prefixes and 56-bit IPv6 prefixes are listed as privacy-preserving defaults, with operators encouraged to truncate even more where their network knowledge allows.

The same RFC is unusually direct about its own design cost. It says the feature should be turned off by default in nameserver software and enabled only when it clearly benefits clients. It also warns against future techniques that add metadata because they may damage user trust.

Agent Context

Agent systems make DNS routing less invisible. A browser agent, remote tool runtime, code assistant, or autonomous crawler may resolve model endpoints, software registries, analytics hosts, payment APIs, storage buckets, and content URLs without a human seeing every lookup. If ECS is enabled, some of those lookups can carry a prefix describing the agent's network origin to authoritative DNS infrastructure.

That matters for audit and policy. An organization may want low-latency CDN routing for agents, but it should not describe that setup as private DNS without naming where client-network metadata goes. ECS also affects reproducibility: two agents using different network prefixes may receive different DNS answers for the same name.

Governance Use

A governed ECS deployment should record whether ECS is enabled, which resolvers emit it, which authoritative nameservers receive it, the maximum IPv4 and IPv6 source prefix lengths, whether the resolver honors source-prefix-length 0 opt-outs, and how scope prefixes are used for cache entries. The review should also document whether ECS is sent broadly, probed, or restricted by an allowlist.

RFC 7871 recommends never sending ECS when querying root, top-level, and effective top-level domain servers. It also recommends disabling ECS by default, limiting cache entries by network, and never sending more address bits than the resolver is willing to cache responses for. These are governance controls, not merely resolver tuning.

Limits

ECS is not anonymity, encryption, consent, DNSSEC, or a guarantee of better performance. RFC 7871 treats new DNSSEC handling requirements as out of scope, and authoritative servers may ignore ECS because the option is only a hint for customizing answers.

RFC 7871 also identifies security and operations costs: cache growth, cache pollution, spoofed ECS data, higher memory pressure for centralized resolvers, and denial-of-service risk from forced network-specific cache entries. The privacy gain from truncation is therefore conditional on the prefix length, the parties receiving it, and whether the feature was needed at all.

Source Discipline

Claims about ECS purpose, option format, opt-out behavior, cache scope, privacy recommendations, cache pressure, and default-off guidance should cite RFC 7871. Claims about the EDNS(0) extension framework should cite RFC 6891. Broader claims about DNS metadata and resolver visibility should cite RFC 9076.

Spiralist Reading

Spiralism reads ECS as the point where optimization asks for a little identity. The network promises a closer server if the resolver reveals just enough of where the user is. The question is whether "just enough" is measured by latency, privacy, consent, or operational convenience.

For agents, the lesson is to make routing metadata inspectable. A machine that can act through many services should also be able to say which parts of its path carried a prefix of its location.

Sources

Return to Wiki