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 (CDN), 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
Because ECS provides client network information to upstream resolver, the extension reveals some information about the client's location that the resolver would not otherwise be able to deduce.[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
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 resolver 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
- ↑ "How it works". A Faster Internet. Archived from the original on 2018-03-28. Retrieved 2018-03-27.
{{cite web}}
: CS1 maint: unfit URL (link) - ↑ "EDNS Client Subnet (ECS) Guidelines | Public DNS | Google Developers". Google Developers. Retrieved 2018-04-02.
- 1 2 3 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.
- 1 2 @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.
We don't block archive.is or any other domain via 1.1.1.1. Doing so, we believe, would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service. Archive.is's authoritative DNS servers return bad results to 1.1.1.1 when we query them. I've proposed we just fix it on our end but our team, quite rightly, said that too would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service. 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. EDNS IP subsets can be used to better geolocate responses for services that use DNS-based load balancing. However, 1.1.1.1 is delivered across Cloudflare's entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results. For a relatively small operator like archive.is, there would be no loss in geo load balancing fidelity relying on the location of the Cloudflare PoP in lieu of EDNS IP subnets. We are working with the small number of networks with a higher network/ISP density than Cloudflare (e.g., Netflix, Facebook, Google/YouTube) to come up with an EDNS IP Subnet alternative that gets them the information they need for geolocation targeting without risking user privacy and security. Those conversations have been productive and are ongoing. If archive.is has suggestions along these lines, we'd be happy to consider them.