ECSeptional DNS Data: Evaluating Nameserver ECS Deployments with Response-Aware Scanning

TL;DR

This work tackles the challenge of measuring how EDNS0 Client Subnet (ECS) deployments influence DNS-based load balancing by introducing a novel, response-aware ECS scanner that supports both IPv4 and IPv6. By maintaining state across responses and pruning the address space via a Patricia trie, the approach achieves up to $97\%$ fewer queries than traditional full-space scans and enables detailed analysis of load-balancing behavior across major providers. The study finds that about $53\%$ of nameservers support prefix-based ECS responses, with roughly $40\%$ tailoring responses to subnets, while Cloudflare dominates ECS-enabled domains and Google’s own NS sometimes violates its resolver guidelines. The authors publish the scanner and data publicly, highlighting practical implications for researchers, operators, and developers aiming to understand ECS deployments and their effects on performance and privacy.

Abstract

DNS is one of the cornerstones of the Internet. Nowadays, a substantial fraction of DNS queries are handled by public resolvers (e.g., Google Public DNS and Cisco's OpenDNS) rather than ISP nameservers. This behavior makes it difficult for authoritative nameservers to provide answers based on the requesting resolver. The impact is especially important for entities that make client origin inferences to perform DNS-based load balancing (e.g., CDNS). The EDNS0 Client Subnet (ECS) option adds the client's IP prefix to DNS queries, which allows authoritative nameservers to provide prefix-based responses. In this study, we introduce a new method for conducting ECS scans, which provides insights into ECS behavior and significantly reduces the required number of queries by up to 97% compared to state-of-the-art techniques. Our approach is also the first to facilitate ECS scans for IPv6. We conduct a comprehensive evaluation of the ECS landscape, examining the usage and implementation of ECS across various services. Overall, 53% of all nameservers support prefix-based responses. Furthermore, we find that Google nameservers do not comply with the Google Public DNS guidelines. Lastly, we plan to make our tool, and data publicly available to foster further research in the area.

Figures (7)

• Figure 1: Example ECS flow: The client C1 is topologically close to the server S1 but uses the resolver topologically close to S2. With the client subnet information in the query (IP address 10.0.0.0 with source prefix length 24), the nameserver can select the correct response and send it back with the original source prefix length 24 and the scope prefix length of 20. The resolver can thus cache the response for all clients within 10.0.0.0/20.
• Figure 2: Scope prefix lengths from our IPv4 response-aware scans. AWS always uses /24. See \ref{['fig:scopesv6']} for IPv6.
• Figure 3: ECDF for the number of observed rrset in the country prefix list scan.
• Figure 4: Scope prefix changes observed in 96 h. Positive values are changes to more specific responses and negative ones to less specific. The scan started on Friday, May 10, 2024, at 15:45 UTC, at our vantage point in Germany. See \ref{['fig:scopechanges6']} for IPv6 plots.
• Figure 5: Scope prefix lengths observed at our IPv6 response-aware scans. AWS Route53 always uses /48. More information can be found in \ref{['ssec:resp-aware-v6']}. For comparison, \ref{['fig:scopes']} shows results for IPv4.