EDNS Client Subnet (ECS) & Geo-Profiling: How RFC 7871 Leaks Your Location

For decades, the Domain Name System (DNS) provided an accidental layer of privacy abstraction. When a client queried an authoritative nameserver, the request was routed through an intermediate recursive resolver—typically managed by an internet service provider (ISP) or an open public resolver. Because the authoritative nameserver only observed the IP address of the recursive resolver, the client’s origin IP address remained concealed behind the resolver’s caching infrastructure.

The rapid rise of global Content Delivery Networks (CDNs) broke this operational model. Modern hyperscale web infrastructure relies on Anycast routing and GeoDNS to direct users to the topologically nearest edge cluster. However, when users configure centralized recursive resolvers operating in remote data centers (such as an overseas public DNS pool), authoritative GeoDNS engines often direct the client to an edge server thousands of miles away, degrading page load latency and streaming throughput.

To reconcile recursive caching with geographic steering, the Internet Engineering Task Force (IETF) standardized RFC 7871 in May 2016: "Client Subnet in DNS Queries," widely referred to as EDNS Client Subnet (ECS). While ECS resolved CDN routing inefficiencies, it created a severe structural privacy leak. Under RFC 7871, recursive resolvers append the client’s network subnet directly into upstream DNS packets, exposing residential location data to authoritative nameservers across the globe—even when traffic is wrapped in encrypted transport protocols like DNS over HTTPS (DoH) or DNS over TLS (DoT).

[Traditional Recursive DNS Architecture: IP Masked]
Client (203.0.113.88) ───> Recursive Resolver (198.51.100.1) ───> Authoritative Nameserver
                                [Sees Resolver IP only: 198.51.100.1]

────────────────────────────────────────────────────────────────────────────────────────

[RFC 7871 EDNS Client Subnet (ECS): Origin Subnet Exposed]
Client (203.0.113.88) ───> Recursive Resolver (198.51.100.1)
                                │
                                ├─ Appends EDNS0 Option 8: Subnet 203.0.113.0/24
                                ▼
                           Authoritative Nameserver (CDN / Ad Tracker)
                                [Logs Target Domain + Residential Subnet 203.0.113.0/24]

The Protocol Anatomy of RFC 7871: EDNS0 Option Code 8

To understand how ECS leaks geographic metadata, we must examine the binary structure defined in RFC 6891 (EDNS0) and RFC 7871.

Standard DNS messages over UDP are historically restricted to 512 bytes. RFC 6891 established Extension Mechanisms for DNS (EDNS0), introducing a pseudo-record known as the OPT resource record. This record allows clients and recursive resolvers to advertise buffer sizes up to 4096 bytes and attach arbitrary variable-length options inside the additional records section.

RFC 7871 assigns Option Code 8 to the client-subnet field. When a recursive resolver handles a lookup for an ECS-supporting authoritative zone, it constructs an OPT record containing four key fields:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-------------------------------+-------------------------------+
 |          OPTION-CODE          |         OPTION-LENGTH         |
 |            (0x0008)           |           (Variable)          |
 +-------------------------------+-------------------------------+
 |            FAMILY             |SOURCE-NETMASK | SCOPE-NETMASK |
 +-------------------------------+---------------+---------------+
 |                           ADDRESS                             |
 |                     (Variable Length octets)                  |
 +---------------------------------------------------------------+

• FAMILY (16 bits): Defines the IP address family (typically 1 for IPv4 or 2 for IPv6).
• SOURCE-NETMASK (8 bits): The subnet mask length forwarded by the resolver. For IPv4, RFC 7871 recommends a /24 prefix (masking the last 8 bits). For IPv6, it recommends a /56 prefix.
• SCOPE-NETMASK (8 bits): Set by the authoritative server in its response to indicate the subnet granularity across which the answer is valid and can be cached.
• ADDRESS (Variable): The actual truncated binary representation of the client's network address (e.g., three octets for a /24 prefix).

While the /24 truncation was intended as a privacy compromise, limiting identification to a block of 256 addresses, empirical network measurement reveals that residential /24 blocks in broadband and fiber deployments are often mapped directly to specific geographic postal codes, municipal neighborhoods, or corporate subnets.

The Surveillance Vector: Cross-Domain Tracking and Passive DNS Profiling

The persistence and breadth of ECS transmission transform routine name resolution into an intrusive tracking surface:

1. Circumventing Transport Encryption: Millions of privacy-conscious users enable DNS over HTTPS (DoH) or DNS over TLS (DoT) on their operating systems, believing their queries are protected from prying eyes. While DoH and DoT encrypt the hop between the client and the recursive resolver, RFC 7871 instructs the recursive resolver to decrypt the query and forward the unencrypted ECS payload to third-party authoritative nameservers over raw UDP port 53. Transport-layer encryption on the first hop offers zero protection against upstream metadata leakage.
2. Authoritative Network Telemetry: Authoritative nameservers operated by advertising networks, analytics platforms, and content conglomerates collect queries across millions of domains. By logging the incoming ECS prefix, these entities establish correlated behavioral timelines, tracking which websites a specific residential neighborhood or corporate campus accesses throughout the day.
3. Passive DNS (pDNS) Database Enrichment: Security researchers, commercial threat intelligence providers, and state actors maintain passive DNS sensors that log live DNS transactions. When recursive resolvers broadcast ECS records, these databases capture both the queried domain and the originating subnet, enabling retrospective profiling of specific network ranges.

The Industry Divergence: Anonymity vs Latency Optimization

Because RFC 7871 pits operational performance against user privacy, major DNS infrastructure operators have taken radically divergent paths:

• Google Public DNS (8.8.8.8): Actively sends ECS information to participating authoritative nameservers to maintain high CDN routing fidelity, though it honors client requests with a zero source prefix (0.0.0.0/0).
• OpenDNS / Cisco Umbrella: Historically pioneered client subnet forwarding and continues to broadcast ECS metadata to maximize regional content steering.
• Cloudflare (1.1.1.1): Firmly rejects ECS. Cloudflare’s privacy commitment mandates that it never forwards client subnets in upstream queries, accepting occasional sub-optimal CDN routing in exchange for eliminating user profiling.
• Quad9 (9.9.9.9): Operates on a strict privacy model and deliberately strips ECS from all upstream queries to prevent geographic correlation.

Defeating ECS Profiling with Layer-3 Encapsulation and Private Anycast Resolvers

Disabling ECS at the application layer is rarely sufficient because client applications cannot force an arbitrary recursive resolver to drop Option Code 8. The definitive privacy safeguard requires a dual-stage architecture:

[Local Workstation / Mobile Device]
                │
                ├─ DNS Query to Internal Gateway (e.g., 10.8.0.1)
                ▼
[Virtual Network Interface: wg0 / tun0]
   Layer-3 Cryptographic Encapsulation via WireGuard / RiceGuard
   Payload sealed in ChaCha20-Poly1305 (256-bit Key)
                │
                ▼
[Physical ISP / Wi-Fi Interface]
   Transmits unreadable UDP packets; ISP sees NO queries, NO subnets
                │
                ▼
[VPNRice Anycast Gateway & Private Recursive Resolver]
   1. Strips any inbound EDNS Client Subnet metadata (FAMILY=0, SOURCE=0)
   2. Resolves queries recursively through local unbound/root instances
   3. Authoritative nameserver sees ONLY the VPN Egress Data Center IP

When connecting through VPNRice:

• Strict In-Tunnel DNS Redirection: All port 53, 853, and DoH traffic is intercepted and routed into dedicated in-tunnel recursive resolvers. The user’s ISP interface never touches raw DNS datagrams.
• Complete ECS Stripping: VPNRice recursive resolvers drop RFC 7871 subnet options. If an upstream authoritative nameserver queries for ECS parameters, the resolver responds with FAMILY=0 and SOURCE-NETMASK=0, concealing the user’s physical network identity.
• Egress IP Normalization: Authoritative nameservers observe only the data center Anycast IP of the VPN egress point. GeoDNS queries naturally resolve to edge nodes closest to the VPN gateway, delivering optimal throughput without compromising the user's geographic privacy.

Practical Diagnostics: Detecting and Mitigating ECS Leaks

System administrators and privacy engineers can audit their network's ECS exposure using command-line diagnostic utilities:

# 1. Audit whether your current resolver sends ECS to authoritative servers
dig +subnet=0.0.0.0/0 TXT o-o.myaddr.l.google.com @8.8.8.8 +short

# 2. Inspect EDNS Option Code 8 in live query packets using Wireshark / tshark
# Wireshark Display Filter: dns.edns0.opt.code == 8

# 3. For custom Unbound local resolvers, enforce ECS stripping in unbound.conf:
# server:
#     send-client-subnet: no
#     max-udp-size: 1232

# 4. In BIND 9 named.conf, disable ECS globally across all views:
# options {
#     ecs-server no;
#     ecs-client no;
# };

• Avoid Public Resolvers that Forward ECS: If operating without a VPN, configure system resolvers to use providers that explicitly forbid ECS transmission, such as Quad9 or Cloudflare.
• Enforce Always-On VPN Routing: Route all system traffic through a hardened Layer-3 WireGuard tunnel to ensure recursive DNS resolution occurs strictly within a controlled, zero-log Anycast enclave.
• Audit Dual-Stack Interfaces: Ensure IPv6 network interfaces do not route outside your VPN tunnel and expose /56 or /64 SLAAC prefixes through unmanaged IPv6 DNS lookups.