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 geolocationally 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
  1. ^ "How it works". A Faster Internet. Archived from the original on 2018-03-28. Retrieved 2018-03-27.
  2. ^ "EDNS Client Subnet (ECS) Guidelines | Public DNS | Google Developers". Google Developers. Retrieved 2018-04-02.
  3. ^ 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.
  4. ^ 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.
  5. ^ 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.