Dual-End Measurement Framework for Public Resolvers

Abstract

In recent years, the concentration risk of the Internet has intensified, with traffic being concentrated in the hands of a few service providers. However, existing research focuses on the client-side perspective and lacks a centralized measurement of the public resolver in terms of operation strategies and software functionality implementation. Therefore, we propose a dual-end measurement framework to measure the public resolver from both the client and authoritative perspectives, stably matching the active nodes of the public resolver pool with their providers, and using probes to evaluate the diversity of its functionality implementation and configuration schemes. The study analyzed the operation plans of different suppliers and revealed the regional nature of the public resolver service scope, enabling the localization of specific resolver instances, thereby achieving a concentration assessment for specific suppliers. In actual measurements from the perspectives of 5 countries and regions using 14 probes on 4 large public resolvers and 7 regional resolvers, we found that although anycast provides geographical redundancy, the software implementation logic of the public resolver cluster in a single region tends to be somewhat homogeneous. The characteristic entropy of Google in five regions was 1.435, while in the Silicon Valley region of the United States, there was only one software implementation.

1. Introduction

The Domain Name System (DNS) infrastructure is designed as a distributed structure and is an important infrastructure of the current Internet. DNS provides the mapping from domain names to IP addresses. When a client initiates a request to access a specific domain name, such as www.example.com, the domain name will be mapped through a series of DNS servers and converted into an IP address that can be directly accessed, so as to obtain the domain name information and complete the access to the corresponding WEB server.

Distributed systems, due to their multi-node deployment features, should inherently possess high resilience. The industry has accumulated a large number of distributed technologies to enhance the distributed nature, such as the use of ECS technology and anycast architecture. For example, for a resolver that adopts anycast, when we make a DNS resolution request to 8.8.8.8, the actual response is completed by the service nodes within its resolver pool. This creates a service model for the DNS system with regional diversity, providing a large amount of security redundancy for its services. Public resolver software can be developed by oneself or directly use open-source software. Super-large public resolvers act as super nodes for the resolution service, serving a huge number of users from all over the world. Their security has a significant impact on the normal network behavior globally and is an important issue of DNS security research, especially in terms of large-scale vulnerability exploitation. DNS traffic has long been under persistent threats from attack methods such as DDoS [1], cache poisoning [2], and domain name hijacking [3], and has also been used for malicious activities such as sending malicious files and conducting phishing attacks. On 20 October 2025, AWS us-east-1 experienced an internal DNS resolution service failure that lasted for 15 h, resulting in the disruption of cloud services for over a thousand customers worldwide [4]. The root cause was a failure in the underlying host management component of Route 53, causing the authoritative resolution to be unresponsive, which is a typical major cybersecurity incident caused by a single-point dependency.

The public resolver, as a form of resolver, generally refers to designing and updating its protocols and software functions based on RFC drafts [5]. It inevitably simultaneously adopts a specific software implementation logic, and during the actual deployment process, the rich configuration options can be utilized to customize its functional performance. Such function features caused by implementation and configuration can be measured and observed. However, previous measurements were limited to observing only the interaction behavior with the client side due to the observation perspective. This problem stems from the application of Anycast technology, which causes the service nodes to be randomized and makes it difficult to stably and completely collect the features of a single node [6]. Moreover, the academic community lacks a corresponding two-end measurement framework. If extended to the interaction behavior between the resolver and the authoritative end, we will be able to more comprehensively analyze the interaction behavior and functional logic of the current public resolvers provided by different service providers.

Meanwhile, from the perspective of service providers, they often need to manage and maintain hundreds or thousands of anycast nodes simultaneously. To maintain consistency and convenience in operations, it is worth exploring whether they deploy the same internal image, that is, whether a single software functional implementation and configuration was adopted, resulting in a single operation and maintenance strategy, ultimately resulting in a geographically distributed, but logically single point paradox. Previously, there have been a large number of centralization measurement studies on DNS, mainly focusing on the measurement of the degree of centralization at the authoritative hosting end [7], the measurement from the client perspective [8], and the measurement of the scope of public resolver services [9]. However, few people have paid attention to the software function implementation and configuration of the resolver, that is, the functional features and configuration diversity exhibited during the resolution process, especially the interaction behavior and response data between the resolver and upstream and downstream servers, both client and authoritative ends. It is clear that even if the provider adopts anycast and ECS technologies to distribute the service pressure and systemic risks to small service areas, once an attack targeting a specific software function implementation is encountered, attackers can still expand this risk to global nodes through a distributed attack system. Therefore, the systematic risks caused by using a single type of software functional implementation and configuration need to be paid attention to.

Therefore, based on the enumeration of resolver pool nodes, can we somehow conduct dual-end observations (both from the client side and the authoritative side) on each node within the common resolver pool, and associate the observed node behavior characteristics with the entry IP and node IP provided by the common resolver? This would enable us to depict the implementation logic of each node of the common resolver, observing how the common resolver vendor implements its software implementation or configuration scheme. Given that we already know that the common resolver employs load balancing and anycast measures, we can thereby analyze the specific implementation details of each node of the common resolver. This is the key issue that we are focusing on and trying to solve.

Our main contributions are as follows:

• We are the first to design a two-end measurement architecture specifically for open resolvers, which can enumerate the public resolver pool and simultaneously measure the interaction behaviors between the client and the authoritative end to depict the software functional implementation and configuration approach of the resolver, and specific records of the behavioral features exhibited by each node’s IP address.
• We used detectors and our own authoritative domain name servers to measure multiple functions and attributes derived from RFC for 14 public resolver entry points. We analyzed the software functional implementations and configuration used by public resolvers and found that the software function implementations or configuration of different public resolvers were significantly different.
• We conducted an analysis of the internal structure of the public resolver and the richness of its regionalized software function implementation or configuration, including the security-related functions. We verified the limitations of observing the public resolver from a single regional perspective and discovered that the public resolver vendors have set logical redundancy for their global range nodes. However, this phenomenon varies across different regions.

2. Preliminaries

2.1. DNS Infrastructure

The DNS resolver system is the core intermediary of the Internet domain name system [10]. Its resolution process can be abstracted as a distributed query chain that combines “recursive—iterative” coordination [11]. The classic recursive query logic is shown in Figure 1. The process can be roughly divided into: root query, request forwarding, and the recursive server acting as an agent for the user to conduct authoritative queries.

Figure 1. A Normal Resolving Process.

(1)

When the user process submits a domain name request, it is first resolved with zero-hop by the local cache (such as browser, operating system, and hosts file).

(2)

Process ① to ② represents how the request is transferred to the resolver. If not found, the request is forwarded to the local process or the configured online recursive resolver. It can also first send the query request to the forwarder, which then delivers it to the upstream resolver specified in its configuration for processing.

(3)

Process ③ to ⑧ represents the process by which the resolver executes recursion.The recursive resolver initiates iterative queries as a client: for example, for the domain name www.example.com, it first obtains the address of the top-level domain (TLD) server from the root server, which is the IP address where the TLD is located; the recursive resolver then obtains the authoritative server address from the TLD server, which is the IP address where the authoritative server of example.com is located; finally, the recursive resolver obtains the relevant resource records (A/AAAA, CNAME, etc.) of www.example.com from the authoritative server and caches the result before returning it to the user at process ⑨ to ⑩. This process is completed through UDP/TCP port 53, relying on the cache validity period (TTL) to achieve consistency in the time dimension, and relying on hierarchical authorization to achieve authority in the spatial dimension.

The main roles in the DNS can be classified into four categories. The first one is the recursive resolver, which acts as an agent for the client, responsible for completing the entire query chain requested by the client and caching the results. It is usually deployed by ISPs or enterprises locally, but can also be provided by public resolvers. Private resolvers generally do not offer public resolution services, while public resolvers refer to instances that are open to the public and accessible to anyone. The second category is the root server, with 13 logical instances globally, providing pointers to top-level domain servers and serving as the starting point for distributed navigation. The third category is the top-level domain server, responsible for authoritative pointers for country or generic top-level domains such as “.com” and “.org”. The fourth category is the authoritative server, which holds the final resource records and has the ability to sign (DNSSEC), and holds the ultimate authority for the interpretation of SLDs and FQDNs in the distributed database. It is generally operated and maintained by the domain holder, but currently, most domain holders choose to use the hosting services provided by large service providers. The four types of roles form an authorization chain through domain delegation and NS and Glue records, ensuring that the failure of any single role only affects a local subtree.

At the resolver level, Schomp et al. proposed a classification method for DNS infrastructure from the client perspective [8], including FDNS (forward resolver), RDNS (recursive resolver), iRDNS (indirect RDNS), and dRDNS (direct RDNS). Taking the public resolver as an example, the actual node IP that performs recursive queries in the public resolver is different from the IP of the public resolver that the user accesses. In most cases, the resolver is transparent to Internet end-users, and obtaining the ability to identify the structure of the resolution pool is a key challenge in measuring the centrality of the client DNS infrastructure.

2.2. DNS Anycast

The inherent distributed nature of DNS stems from the triple requirements of scalability, fault tolerance, and geographical affinity in the early Internet. Centralized databases would encounter three major bottlenecks in scenarios involving billions of domain names and global users: single-point failures, transoceanic delays, and traffic hotspots. Modern open resolvers, especially large public resolvers, implement the Anycast mechanism through BGP and build a public resolver pool, configuring multiple actual service nodes to maintain the distributed and highly available features of the resolution service globally. Their actual workflow is shown in Figure 2.

Figure 2. What is a public resolver entrance? How does a pool work?

Anycast combined with the geographic DNS mechanism enables users’ requests to be routed to the nearest access point and distributes the query requests to different management entities. Servers at each level achieve multi-replicas through zone transfer (AXFR/IXFR) and cache replication, tolerating node failures. Thus, the system can dynamically add resolution nodes at any location to achieve horizontal expansion while maintaining global consistency logic. Anycast networks allow multiple servers on the network to use the same IP address or a group of IP addresses [12]. For example, a request for a certain IP address in Cloudflare CDN can be responded to by any data center operated by Cloudflare, rather than a specific server. When using Anycast DNS, multiple physical nodes declare the same IP prefix, and DNS queries are redirected to the DNS resolver network rather than a specific resolver. BGP automatically routes the route to the nearest available resolver to reduce service RTT and naturally has anti-DDoS capabilities. To meet the access needs of a large number of Internet end users, public DNS providers generally deploy multiple resolution pools to achieve load balancing, and there is an implicit collaborative relationship between the resolvers within the same resolution pool, which is transparent to the requester [13].

Meanwhile, modern DNS employs ECS (EDNS Client Subnet) for local scheduling [14]. ECS is an application-layer extension. When recursive servers send queries to upstream authoritative servers, they split the terminal IP into a prefix (such as /24) and write it into the EDNS0 option; the authoritative server then returns different A/AAAA records based on “where the user seems to be”, helping CDN achieve local scheduling. However, this also leads to an expansion of the caching dimension and risks of privacy leakage.

The public resolver is the super node of the aforementioned DNS infrastructure. Deployed by operators such as Google (8.8.8.8) and Cloudflare (1.1.1.1), it provides recursive services to any network entity through global anycast entry points and large-scale caching clusters. Its role goes beyond merely reducing the load on local ISP resolvers and lowering resolution latency. It also enhances the overall hit rate by sharing cache, forming a “cross-domain shared memory”. Moreover, public resolvers often deploy security enhancements such as DNS-over-HTTPS/TLS and DNSSEC verification first, becoming a “trusted anchor” in the distributed system. They provide a centralized strategy upgrade window to deal with security threats such as DNS hijacking and amplification attacks, thus balancing the openness of the distributed architecture with the governance of public services.

In simple terms, the aforementioned technology has enabled modern DNS resolvers to adopt a structure consisting of an entry IP and a resolver pool. For users, 8.8.8.8 or 1.1.1.1 are merely “configuration addresses”. However, the actual process involves a separation of “entry–response”: The entry node selected by BGP provides the first-hop cache and handshake, while the actual iterative query may be completed by resolver node instances located in other countries or even continents. This approach effectively controls the resolver load and global risks.

In this article, for the configuration address that is directly used by the client, such as 8.8.8.8, we refer to it as the entry node IP of the public resolver pool; as for the numerous nodes within the resolver pool that are actually used for the DNS resolution service in the end, in this article, we collectively refer to them as the service nodes of the public resolver pool. In this paper, the service nodes merely represent the indirect resolvers within the resolver pool, that is, the resolver pool nodes that directly interact with the authoritative servers, and do not include the forwarding layer and the caching layer.

2.3. Resolver Behavior Feature: Function, Configuration, and RFC

The Internet Engineering Task Force (IETF) standardizes the Domain Name System (DNS) through the Request for Comments (RFC) series; the RFC cases and time nodes are shown in Table 1. Since RFC 1035 [15] established the message format and resolution process in 1987, DNS-related RFCs have formed a complete spectrum covering namespace structure, record types, transport protocols, and security extensions. RFC 2308 defines negative caching and NXDOMAIN semantics; RFC 4033-4035 systematically expounds the DNSSEC trust chain and signature lifecycle; RFC 7871 introduces EDNS0 Client-Subnet (ECS) for content routing; RFC 7858 and RFC 8484 respectively standardize DNS-over-TLS and DNS-over-HTTPS to enhance transmission confidentiality; RFC 8914 provides Extended DNS Error (EDE) [16] to improve diagnostic capabilities. These documents constrain implementation behavior through some levels of requirements [5], such as MUST, SHOULD, and OPTIONAL, providing a functional baseline and boundaries for resolver software while retaining optional parameters and algorithm details and allowing different codebases to have differentiation space under compliance, thereby laying the normative framework for the functional evolution of DNS software.

Table 1. The relevant RFCs regarding the Resolver function and historical vulnerabilities.

Function	RFC Number	Published Year	CVE Number	Affected Software
Basic query/compression	RFC 1035	1987	CVE-2020-8616	BIND 9
DNSSEC validation	RFC 4033-4035	2005	CVE-2023-50387	BIND 9, Unbound, Knot Resolver
EDNS0 extension	RFC 2671, RFC 6891	1999, 2013	CVE-2020-8617	BIND 9
ECS subnet	RFC 7871	2016	CVE-2020-8622	BIND 9
NSEC3 validation	RFC 5155	2008	CVE-2019-6475	BIND 9
DNS-over-TLS	RFC 7858	2016	CVE-2021-25219	NLnet Labs Unbound
DNS-over-HTTPS	RFC 8484	2018	CVE-2022-30626	NLnet Labs Unbound

Although RFCs provide unified semantics, DNS resolvers exhibit significant diversity at the implementation level: BIND 9 defaults to enabling DNSSEC validation [17] and attaching trust anchor telemetry, supporting full NSEC3 validation and automatic key rollover; Unbound advances QNAME minimization [18] to the single-label level and enforces DNS Cookies to resist source address forgery; PowerDNS-Recursor exposes policy hooks via Lua scripts, allowing dynamic modification of resolution logic at runtime. These differences stem from the open interpretation of OPTIONAL clauses in RFCs: for instance, parameters such as the source prefix length of ECS, the EDNS buffer size, and the lower limit of negative cache TTLs only provide recommended values, allowing implementers to set them according to their scenarios; meanwhile, RFCs do not specify internal data structures or scheduling algorithms, leading to polymorphism in performance, resource consumption, and security enhancement for the same functionality. This flexibility in software implementation promotes diversity in the ecosystem at a macro level but also provides differentiated attack surfaces for subsequent vulnerability exposure. Moreover, resolver software often grants users high customization permissions, allowing them to modify the resolver’s configuration based on their own needs and usage scenarios.

Historical vulnerabilities have shown that the OPTIONAL flexibility in RFCs can become a centralized attack vector: CVE-2020-8616 [19] exploited BIND’s recursive resolution path for compressed pointers to trigger an infinite loop; CVE-2023-50387 (KeyTrap) [20] exhausted CPU through NSEC3 hash collisions during DNSSEC validation, affecting the unified implementation logic of BIND, Unbound, and Knot Resolver; CVE-2020-8622 [21] constructed cache key pollution by leveraging ECS, taking advantage of the consistent handling of scope truncation by resolvers. If there are common internal flaws in the public resolver, they can be easily exploited by attackers, allowing for global attacks through a distributed system.

Different resolver nodes may have adopted different functional implementation schemes and configuration schemes, which can also be referred to as operation and maintenance schemes. However, both the functional implementation schemes and configuration schemes will exhibit certain features during their interaction with the client and the authoritative end. Specifically, this can include information such as specific data fields and latency. By using measurement probes targeting specific functions and configurations, the feature information of the target can be extracted.

3. Related Work

3.1. Public Resolver Enumeration

Cicalese et al. proposed iGreedy, which utilized time delay inconsistency to enumerate 19 instances of Google’s public DNS, achieving a recall rate of approximately 40%, but relying on thousands of distributed probes and unable to obtain specific node IP addresses. Schomp et al. discovered 317 indirect resolvers by leveraging CNAME chains, with a recall rate of only 4.5%, limited by the scale of the feature resolver. However, all of these works started from the “client side”: relying on forwarding paths or delay features, using the observed last-hop IP as an arbitrary broadcast node identifier. Due to the random generation of response packets by anycast entry, their IP often does not match the “internal node” actually performing the iteration, resulting in the enumeration results still being “entry pool” rather than “resolution pool”. Moreover, the forwarding relationship method requires multiple rounds of active probing, which is prone to being limited by the target operator’s speed limit or injected with forged responses, introducing observation bias. In contrast, Xu et al. designed the “forwarding relationship inference” method [9], which converts hundreds of thousands of open relays into observation points through TXT records, enabling the iterative discovery of 62.5% of the airport codes behind 8.8.8.8 on a single host, with a node scale that has increased by two orders of magnitude, becoming the current lightweight enumeration scheme with the highest recall rate.

The research generally regards the public resolver as a “black box”, inferring its anycast scale and internal structure through external probing. Our method is the first to simultaneously perform enumeration and node measurement on both ends: on the client side, we continue to use the TXT-embedded probe and utilize the forwarding relationship to quickly converge the candidate pool; on the authoritative side, we synchronously record the source IP of the query and the ECS subnet, and by means of bidirectional log association, bind the “packet-level” observation to the “node-level” identity. Experiments show that this mechanism can associate independent DNS messages to the internal nodes of the same resolver, and does not require additional probing traffic. In other words, the forwarding inference mechanism in this paper solves the problem of “how to discover candidate nodes at a low cost”, and we further answer “how to confirm that these nodes truly belong to the same resolver pool”, and provide end-to-end observability and fault location capabilities by fully measuring the node functions, attributes, and configuration features within the resolver pool.

Overall, the standout contribution of this research lies in its use of global relays to enumerate the service nodes of the public resolver pool, enabling an efficient and rapid enumeration of all the enabled public resolver nodes. However, since the issue it focuses on is not the logical implementation of the resolver nodes themselves, this research introduces the authoritative end perspective and the concept of logical implementation. Based on the ideas presented in this article, it explores whether there is any logical redundancy in the functional implementation and configuration of the resolver nodes.

3.2. DNS Centralization Measurement

Peng et al. focused on the authoritative side infrastructure and quantified the centralization of DNS from the perspective of hosting providers [7]: Through the similarity of NS domain co-hosting and text pattern clustering, it was found that the top 10 hosting providers controlled over 54% of the .com/.net/.org domain names, and the same hosting providers often use multiple NS base domains to conceal the centralization; for example, 152 base domains under NSone all point to the same infrastructure. This work revealed the upstream centralized risk of the “authoritative server—hosting provider—AS” chain, but did not explore the software homogeneity of the downstream recursive side, that is, the public resolver cluster that users actually access. In other words, it measured “who hosts the authoritative service”, rather than “what code executes the recursive service”.

Our research precisely fills this gap. We focused on the same public resolver, anycast entry IP, and utilized the enumeration-correlation mechanism to map independent DNS messages to specific nodes, thereby measuring the software functional implementation and configuration feature diversity. In contrast, Peng et al. emphasized the “multi-domain masking of a single service provider” risk, which belongs to an authoritative-side logical single point, while we exposed the software functional implementation and configuration single point on the recursive side, “a single code base masking geographical dispersion”. Both are upstream and downstream in the attack surface, jointly constituting the “double-tower” centralized danger of the DNS ecosystem.

Overall, the research of this article focuses on the centralized issue of authority hosting, and establishes a mapping of the relationship between the hosting servers and service providers, obtaining effective analytical samples. The main perspective is the centralized issue of the authority end. However, it is worth studying whether there are similar problems in the public resolver that can be directly accessed by the client. There is no authority hosting issue at the public resolver end, but there is an association between the public resolver entry and the actual service node. The public resolver is managed by the same manufacturer, and there is a certain inertia in its software implementation. This article intends to explore whether this management relationship will lead to the centralized problem.

4. Framework Design

The core objective of this study is to answer an important question: Do the global nodes of large-scale public resolvers all adopt the same software functional implementation and configuration? To achieve this goal, we need to overcome the features of the public server architecture in order to describe the software function implementation and configuration of the public resolver pool of a specific service provider. Therefore, the following main problems exist:

• We need to interact globally with as many resolver nodes as possible, that is, how can we enumerate the nodes within the service area in an anycast environment?
• From the resolution process, it can be seen that the interaction behavior of the resolver includes upstream and downstream interaction behaviors. How can we simultaneously observe the interaction data with the client and the authoritative server?
• After the client initiates a resolution request, the service node allocated by the public resolver is random. How can we associate the service IP, client observation data, and authoritative segment observation data to fully depict the software functional implementation and configuration features of the resolver?

To solve these problems, we designed a new dual-end measurement architecture to describe the software functional implementation and configuration of the resolver and analyzed it. We will provide a detailed introduction to this system in the following text.

4.1. Framework Overview

To detect and collect the resolver pools of public resolvers in order to study whether they have diverse software functional implementations and configurations, we designed a corresponding measurement framework, as shown in Figure 3 and Algorithm 1.

Algorithm 1 Pseudocode of the whole process.

1: Initialize entry IP set $\mathcal{E}$, service node database $\mathcal{D}$, and probe set $\mathcal{P}$ 2: Set maximum retry count for entry IP $max\_retry\_entry$, maximum probe count for service node $max\_probe\_node$, service node counter for each entry IP $prev\_node\_count$. 3: for each entry IP $e\in \mathcal{E}$ do 4:     Initialize retry counter $retry\_counter\_entry\left[e\right]$ to 0 5:     Initialize previous node count $prev\_node\_count\left[e\right]$ to 0 6: end for 7: while$\mathcal{E}\ne Ø$do 8:     for each entry IP $e\in \mathcal{E}$ do 9:        for each probe $p\in \mathcal{P}$ do 10:         Send probe p to entry IP e 11:         Collect response service node IP $sn$ and feature $feat$ 12:         if $retry\_counter\_entry\left[e\right]<max\_retry\_entry$ then 13:           if $sn\notin \mathcal{D}$ for entry IP e then 14:              Add $sn$ to $\mathcal{D}$ for entry IP e 15:              Initialize probe counter $probe\_counter\_node\left[e\right]\left[sn\right]$ to 0 16:           end if 17:         end if 18:         if $sn\in \mathcal{D}$ for entry IP e then 19:           Update features for $sn$ in $\mathcal{D}$ 20:           Increment $probe\_counter\_node\left[e\right]\left[sn\right]$ by 1 21:         end if 22:         if the number of nodes in $\mathcal{D}$ for e equals $prev\_node\_count\left[e\right]$ then 23:           Increment $retry\_counter\_entry\left[e\right]$ by 1 24:         else 25:           Reset $retry\_counter\_entry\left[e\right]$ to 0 26:           Update $prev\_node\_count\left[e\right]$ to the current number of nodes in $\mathcal{D}$ for e 27:         end if 28:         if $retry\_counter\_entry\left[e\right]\ge max\_retry\_entry$ then 29:           Check if all $probe\_counter\_node\left[e\right]\left[sn\right]$ for $sn\in \mathcal{D}$ have reached $max\_probe\_node$ 30:           if all $probe\_counter\_node\left[e\right]\left[sn\right]\ge max\_probe\_node$ then 31:              Remove entry IP e from $\mathcal{E}$ 32:           end if 33:         end if 34:      end for 35:    end for 36: end while

Figure 3. Process of Probing Overview. The blue dashed box indicates the nodes that we have deployed and are in control of.

The measurement framework in this paper can enumerate the service nodes within the public resolver to conduct functional and configuration probing, and complete stable node identification, that is, to associate the service node IP with the functional and configuration features detected through multiple probes, as well as the public resolver entry IP. It should be noted that during the probing process, this framework still sends requests to duplicate service nodes, which is due to the objective existence of the anycast distribution mechanism.

Our measurement system was designed as a dual-end synchronous architecture, including a client probe transmitter and a self-built authoritative server.

4.2. Client End

The client terminal component includes the probe transmission program and the feature database.

First, there is the probe sending program. The goal of this program is to send specific query requests pointing to the personal domain name we hold to the designated public resolver, so that the request is received by the child node of the public resolver and enters the recursive query process, allowing features to be collected from the specific location of the interaction process or response data packet. Specifically, this component can send DNS request payloads designed for the specific functionality of the resolver. The destination address of the payload is set to the entry address of the public resolver we are going to measure (for example, the entry IP address of Google’s public resolver is 8.8.8.8), and the domain name being queried is the one we have created. When actually sending, this domain name is specially encoded to indicate the probe name and entry IP. The probe sending program loads the probe and sends the DNS query request it generates to the entry address of the public resolver. The query request will be allocated by the allocation mechanism of the target public resolver to a node in its resolver pool and the recursive query process will be executed. During this process, the resolver pool will interact with our self-built authoritative server and the client, generating relevant interaction behaviors and interaction data. These interaction data are the original data for analyzing the software function implementation and configuration of the public resolver cluster, and by analyzing the interaction process through a predefined program or directly extracting features from the specific location of the response data packet. It should be noted that some public resolvers may not have a resolver pool. In such cases, we consider the size of the resolver pool to be 1.

Secondly, there is the feature database, whose goal is to, based on the relational database, associate the features collected from both ends with information such as the entry IP, and store them for analysis. We already know that through the probe sending program, we have collected a large number of features. It should be noted that since the features collected by different probes may be generated at the client side or at the authoritative end, the source of the collected interaction data can be either the client side or the authoritative end. These interaction data. By associating the data such as the pre-annotated entry IP, response IP, probe name, etc., carried in the domain name part of the response data with the features extracted from the interaction data, they are stored as analysis data.

4.3. Authoritative Server End

The self-built authoritative server includes self-built servers, self-hosted domain names, and log analysis programs.

First, it is the self-hosted domain name. To observe the interaction behavior between the public resolver node and the authoritative server, we need to register the domain name independently so that the resolver node can complete the interaction process with our self-built domain name authoritative server during the interaction. Taking domain name B.C as an example, the NS record of the B.C domain is stored on the gTLD. When the resolver node makes a recursive query, it will query the server IP pointed to the gTLD by B.C. The gTLD will reply with the NS record, informing it which IP is hosting the server pointed to by B.C. Finally, the resolver will directly interact with our self-built authoritative server to complete the resolution request process for the subdomain of B.C.

Secondly, it is about building our own authoritative server. The purpose of building our own authoritative server is to host our self-built domain names and, through unique configuration, observe the interaction behavior of the target public resolver cluster from the perspective of the authoritative end. Normally, when users interact with the public resolver, they can only observe a small number of direct responses and interaction behaviors of the target resolver. To comprehensively observe the behavior of the target node, we take advantage of the feature that during the recursive resolution process, the resolver interacts with the authoritative end, and build our own authoritative resolution node to obtain this part of the interaction data.

Finally, there is the log analysis program. To establish an association mapping between the response data from the authoritative end, the actual service nodes, the public resolver entry nodes, and the probe names, and to synchronize the data to the client in order to build a complete database, the implementation method involves conducting log analysis and data synchronization based on the authoritative end’s parsing logs. It should be noted that when the resolver interacts with the authoritative end, it will lose its entry node information, and this needs to be improved by using the encoding mechanism.

4.4. Work Process

The functions of each component have been introduced. The complete working process of our framework can be described as follows:

Take the example of a probe targeting a certain service node within a public resolver pool. The first step is to use the public resolver entry list as the input and execute multiple processes simultaneously to send probes to each public resolver entry. For example, for Google DNS, the client sends a probe to the IP 8.8.8.8 entry. The specific content of the query request is the predefined domain name query request, and the SLD of this domain name is hosted on our self-built server. The second step is that this query request will be assigned by the IP 8.8.8.8 entry to a certain service node. The third step is that the service node executes the resolution process, involving interaction with the root and TLD, and ultimately obtains the IP of the authoritative server where our self-built domain name is hosted. The fourth step is that the service node interacts with the authoritative server and finally responds the query result to the client probe sending program. At this time, the client can extract some of the features. The fifth step is that the self-built authoritative server extracts the target features from the interaction process and interaction data of the service node and stores them together with the actual IP and other data in the IP-Feature Log. The sixth step is sent simultaneously with the fifth step, but it will block and wait for the completion of the fifth step. After the client probe sending program receives the response from the service node, it interacts with the HTTP API of the authoritative end, using a special encoding as the credential, and obtains the features, service node IP and other data obtained from the probe for this detection from the IP-Feature Log. The seventh step is that the client combines the features obtained from the authoritative end with the locally obtained features and stores them in a relational database in a specific mapped format. After that, the probe sending program will repeat this process until the termination condition of the initiation process.

5. How to Measure the Public Resolver from Two Ends?

From the perspective of the measurement object, our measurement object is the software functional implementation and configuration of the resolver pool, namely the interaction behavior of the resolver nodes, and we also considered the dual-end interaction behavior between the resolver and the authoritative end as well as the user end. Therefore, the following issues arise:

• During the actual service process, the resolver pool randomly assigns the actual service nodes. Our aim is to measure the diversity of the resolver pool software functional implementation and configuration. How should we comprehensively measure the interaction behavior of the resolver pool?
• The client and the authoritative server are separate modules. During the interaction process of the resolver with the root and gTLD servers, it is impossible to track the data packet trajectory. How can the association between the client’s request and the response data received by the authoritative server be established?
• How can we collect and analyze the interaction behavior data between the resolver and the authoritative end?

For this purpose, we have specially designed some modules within the framework.

5.1. IP Pool Enumeration Design

Due to the fact that many modern recursive resolvers adopt the design of resolver pools, when we continuously issue requests to the entry IP of the same public resolver, the response nodes will be randomly hit according to the service distribution mechanism of the resolver pool, the specific situation is shown in Figure 2. If we merely collect single requests to the target public resolver, the impact of this nature is relatively limited. However, for our research needs, we need to measure the various and complete software function implementations or configurations of public resolver pools. To accomplish this measurement task, for the nodes within the same resolver pool, we need: first, to measure as many service-providing nodes within the resolver pool as possible; second, for each node within the resolver pool, we need to collect its interaction patterns and response data for all types of probes. Therefore, it is necessary for this research to overcome the feature of random service node allocation in resolver pools.

To this end, we have incorporated an enumeration mechanism within the measurement framework. For this article, the objects of enumeration include the responses of the probes and the server nodes. To clearly introduce the effect that the task aims to achieve, we will introduce it in two stages. First, for a node in the resolver pool, all the requests sent by the probe sending program hit this server and all the responses containing software function features from this server are collected. Hereinafter, a group of such responses is referred to as the software function implementation and configuration feature set. Then, we collect all the above-mentioned software functional implementation and configuration feature sets from all the nodes in the resolver pool. It should be noted that the execution process in the actual enumeration process is different from the above description, but the ultimate goal of the enumeration is consistent with the above description, that is, we have collected the software function implementation and configuration feature sets of all nodes in the resolver pool under a common resolver.

In terms of the specific implementation plan, we adopt an iterative enumeration mechanism. We have deployed a public resolver IP information pool composed of relational databases on the client side, which contains hierarchical structure information. Since the entry IP presents a one-to-many mapping to the actual response node IP under its resolver pool, and the actual service IP to each probe’s response is also a one-to-many mapping, we have established an associated mapping of public resolver entry IP - service node IP - probe response features. In terms of the storage structure, according to the official documentation of the 8.8.8.8 resolver pool disclosed by Google, its scale is at the hundred level, which is not large for modern relational databases. Therefore, the structure of a single data entry we store is designed as:

$$(entryIP,Region,nodeIP,probe1feature,probe2feature,\dots \dots ,probeNfeature,other)$$

In order to enable our enumeration iteration process to stop properly, we need to set a convergence criterion for measurement. Assuming that we only need to enumerate all the nodes, we only need to detect the change in the number of unique nodes. However, we also need to ensure the completeness of the collection of each node’s features, which is relatively strict. Therefore, our termination condition includes real-time monitoring of two indicators, the change in the number of IP addresses and the completeness of the features of independent IP addresses. Regarding this issue, since the probability of both indicators converging simultaneously is strict, we do not aim to enumerate all the nodes. Our goal is to ensure the completeness of the features of all collected nodes under the condition of pursuing the resolver pool of nodes as completely as possible, that is, to collect all the features of the IP response to all probes. We designed a two-stage condition stop process, with the change in the number of IP addresses and the completeness of the features of independent IP addresses being set as two independent terminators. The relevant implementation logic can be referred to as Algorithm 1.

(1)

First stage: Changes in IP quantity. A single probe sending process, from the perspective of the resolver pool, can be regarded as a random selection of service nodes. As the number of probes sent continuously increases, if the number of IPs collected from a certain public resolver pool does not change, it is considered that the collection of this public resolver pool has reached the convergence condition, and no new node IPs will be added to the resolver pool.

(2)

Second stage: At this point, the focus shifts to detecting the changes in the completeness of each node’s features. A counter is set for each node that has not yet collected complete features. Based on the number of nodes that have not yet collected complete features, using statistical probability, a tolerance of 1% for missed attempts is selected as the expectation, and the maximum retry count is calculated as the threshold. Each time a probe is sent, the counter value is incremented. When the counter reaches the threshold, collection of the node is abandoned. Only the entries of nodes that have collected complete features are retained in the final feature database.

Regarding the selection of the threshold, we first determine a target. Our target has two aspects: to enumerate all the direct resolver service nodes of each resolver pool as much as possible, and to ensure that all probes reach each service node. In fact, since the number of service nodes is fixed and the tool directly relied upon for enumerating the nodes is the probe, these two issues are actually the same. Therefore, this problem can be regarded as calculating how many probe actions need to be initiated for a certain probe to successfully reach all nodes. We calculate the upper limit of the normal distribution confidence interval at the 99% confidence level based on a tolerance of 1%, and the derivation process is as follows:

First, the formula for its mathematical expectation $\mathbb{E}\left[T\right]$ is as follows. A part of the formula is a harmonic series, and the harmonic series of n is denoted as $H_N$. We use the approximate formula of the harmonic series for approximate calculation, and introduce the Euler-Mascheroni constant $\gamma$. The mathematical expectation is expressed as

$$\mathbb{E}\left[T\right]=\sum _{k=1}^N\mathbb{E}\left[T_k\right]=\sum _{k=1}^N{\displaystyle \frac{1}{p_k}}=\sum _{k=1}^N{\displaystyle \frac{N}{N-k+1}}=N\sum _{i=1}^N{\displaystyle \frac{1}{i}}=N·H_N$$

By enumerating the number of nodes in a single area in the early stage, the total number of multi-class public resolver nodes in the measured area did not exceed 150. Therefore, we set N as a fixed value of 150. Before conducting the measurement work from the perspective of other regions, we also recommend performing a node enumeration in advance. Taking $\gamma$ as 0.5772, the calculation yields

$$\mathbb{E}[T]\approx \begin{array}{|c|}\hline 838.18\\ \hline\end{array}$$

Then, calculate the variance

$$\mathrm{Var}\left(T\right)=\sum _{k=1}^N\mathrm{Var}\left(T_k\right)=\sum _{k=1}^N{\displaystyle \frac{1-p_k}{p_k^2}}=\sum _{k=1}^N{\displaystyle \frac{N(k-1)}{{(N-k+1)}^2}}$$

$${\sigma }_T=\sqrt{\mathrm{Var}\left(T\right)}\approx 150\times {\displaystyle \frac{\pi }{\sqrt{6}}}\approx \begin{array}{|c|}\hline 192.1\\ \hline\end{array}$$

Given the overall variance, the $100(1-\alpha )\%$ confidence interval is expressed as

$$\mathbb{P}\left(\mathbb{E}\left[T\right]-z_{\alpha /2}·{\sigma }_T\le T\le \mathbb{E}\left[T\right]+z_{\alpha /2}·{\sigma }_T\right)\approx 1-\alpha$$

At the 99% confidence level, the value of $z_{\alpha /2}$ is approximately 2.576:

$${\mathrm{CI}}_{95\%}\approx 838.18\pm 2.576\times 192.1=[344,1333]$$

Based on the results, when at least 1333 probes are conducted, our requirements can be met. The maximum retry count for the first stage is set at 1333 times. Regarding the probe count threshold for the second stage, it is worth noting that multiple probes are sent sequentially in each round, and all probes under a certain service node share one counter. Therefore, the threshold is set to 1333 multiplied by the number of probes.

$${\displaystyle \frac{\partial \mathbb{E}\left[T\right]}{\partial N}}=H_N+N·{\displaystyle \frac{1}{N}}=H_N+1$$

$$S_N={\displaystyle \frac{\partial \mathbb{E}\left[T\right]}{\partial N}}·{\displaystyle \frac{N}{\mathbb{E}\left[T\right]}}={\displaystyle \frac{(H_N+1)·N}{N·H_N}}=1+{\displaystyle \frac{1}{H_N}}$$

$$S_N=1+{\displaystyle \frac{1}{5.591}}\approx \begin{array}{|c|}\hline 1.18\\ \hline\end{array}$$

When $S_N$ is greater than 1, there is an amplification effect, meaning that for every 1% increase in the number of nodes N, the expected number of probes $\mathbb{E}\left[T\right]$ increases by 1.18%.

5.2. Domain Encoding Method

Thanks to the mechanism of the public resolver pool, and to ensure the consistency of the source IP of the request with the destination IP of the response, when a user sends a query request to the public resolver entry IP, the received response is consistent with the entry IP rather than the node IP. This enables users to use the public resolver without any inconvenience. However, the existence of this mechanism makes it impossible for us to effectively distinguish which node IP the resolver response comes from when measuring the public resolver pool. This situation leads to the consequence that when we send a group of probes, we cannot distinguish whether their responses come from the same IP node, and thus, we cannot describe the software functional implementation and configuration feature of a specific resolver pool node.

Therefore, we utilized the domain name field of the resolution process and designed a unique encoding for it. This encoding was used to embed timestamps, entry IPs, and probe names, helping us establish a mapping relationship between a single measurement action and the public resolver pool as well as the measurement probes, as shown in Figure 4.

Figure 4. Examples of the structure of domain name encoding.

The SLD section is used to ensure that the resolver node eventually interacts with our authoritative server. The subdomain section is divided into three parts: timestamp, entry IP, and probe name:

(1)

Timestamp: During the measurement process, the probe sends programs concurrently to the same IP to send requests. To distinguish the sequence numbers of these requests, we set a unique millisecond-level timestamp for each individual sent data packet and record this timestamp in the cache. When the response arrives at the authoritative segment and is processed, it is synchronized to the client’s features. We can then distinguish which specific request it corresponds to, preventing interference in extreme cases.

At the same time, this field is also used to handle some special situations. For example, some public resolvers adopt a Qname minimization strategy to minimize the privacy leakage of the domain name queried by users. This is manifested as the intermediate authoritative server being unable to obtain the content of the lowest-level FQDN, resulting in the loss of encoded information. And coincidentally, since the domain name is randomly generated, our authoritative server does not actually set the A record for that FQDN, so our authoritative server will never know what the lowest-level FQDN is. Therefore, in this situation, we set the timestamp as an optional reference encoding information, protecting other encoding information from being eliminated. It should be noted that in the Qname minimization strategy scenario, due to the loss of the timestamp, we cannot guarantee the mapping of requests and responses. Therefore, we chose a synchronization mechanism, that is, for a specific entry IP, only one such probe is sent at a time until it is lost or a response is received. This part will reduce the probing rate, but for the sake of rigor, we first ensure that it will not have a decisive impact on the measurement results. At the same time, according to our probing duration, it also indicates that we can complete the measurement of a single public resolver pool from a single regional perspective within a day.

(2)

Entry IP: During the measurement, the probe sending program will send requests to multiple different entry IPs. To distinguish the source IP in the response received by the authoritative end, that is, to determine which resolver pool node belongs to which public resolver pool, we encode the entry IP as a string connected by short lines to determine which service provider’s public resolver the response node IP belongs to.

(3)

Probe Name: Similarly, during the measurement process, the probe sending program will send different probes to individual entry IPs to generate requests. To distinguish the specific measurement tasks that the authoritative end receives and responds to, we encode the probe name and store it as the unique identifier for identifying the probe in the cache, in order to establish the mapping relationship between the node IP and the feature name.

5.3. Scanner Design

We have also carried out other unique designs to adapt to the software function implementation and configuration features of the measurement task in the dual-end synchronization scenario, including probe design and synchronization mechanism.

For actual measurement, the observation perspectives of different probes vary, resulting in differences in their execution processes, as shown in Figure 5. Some probes can directly collect corresponding features from the client perspective, while others must observe the features from the authoritative end perspective. We refer to these two types of probes as: client end probes and authoritative end probes. However, both of them need to obtain the service IP and the corresponding entry IP information of the resolver pool through the authoritative end’s logs and rely on the encoding mechanism.

Figure 5. The differences between the two types of probes and how their features are synchronized into the measurement program. The red arrows indicate the direction of the features, while the blue arrows represent the flow of service IP and entrance IP information.

Under this framework, in general cases, probes do not need to set up blocking after sending, and these probes can concurrently send probing requests, map them through the encoding mechanism, and synchronize through the encoded information recorded in the cache to store the results in the correct database entry. The synchronization program relies on the authoritative end to send synchronization signals to the client, and the client accesses the lightweight HTTP API deployed on the authoritative server to perform data synchronization.

6. Measurement and Analysis

6.1. Measurement

6.1.1. Implementation Details

Due to the existence of mechanisms such as ECS and unicast, in order to avoid the limitations of a single regional perspective and to achieve cross-regional measurement, we have established detection nodes in 5 countries or regions, including Frankfurt in Germany, Tokyo in Japan, Silicon Valley in the United States, Singapore, and the Chinese mainland. Our experimental environment is equipped with a 10 Mbps network bandwidth. During the experiment, the network did not reach a bottleneck and was used as a client within the framework. It should be noted that in this study, our task objective is to enumerate the nodes of the public resolver and characterize their configuration and functional features. The requirement for enumeration speed is relatively low. The enumeration process indicates that we can complete this work within one day, and the changes in the public resolver over time have a limited impact on the error.

Additionally, we deployed an authoritative server on a cloud-based host with a publicly registered IP address, enabling the dynamic creation and removal of experimental subdomains. Lightweight HTTP APIs were also deployed to facilitate the collection of information from the authoritative server.

The measurement data set is the public resolver entry IP. The selection criteria include: large resolver service clusters, regional dedicated resolver servers, totaling 14 entry IPs. Among them, the regional dedicated resolver servers include: public resolvers provided by cloud service providers for cloud services, and regional public resolvers, in order to conduct a comprehensive evaluation of different types of public resolvers.

6.1.2. Dataset

At the same time, in order to cross-verify whether the node enumeration within the selected area is complete, as well as whether the service node IPs assigned by the primary Anycast address and the secondary Anycast address are consistent, we utilized the feature of randomly allocating resolver services to the nodes in the public resolver pool, and relied on the enumeration stop mechanism. Specifically, the auxiliary Anycast addresses of GoogleDNS, OpenDNS, and CloudflareDNS were also added to the dataset.

The dataset information is presented in Table 2.

Table 2. Public resolver entrance IP selected.

Type	Name	Entry IP	Detail	Service Provider
Large Public Resolver	GoogleDNS A	8.8.8.8	Global public DNS	Google
	GoogleDNS B	8.8.4.4	Global public DNS	Google
	OpenDNS A	208.67.220.220	Global public DNS	Cisco
	OpenDNS B	208.67.222.222	Global public DNS	Cisco
	CloudflareDNS A	1.0.0.1	Global public DNS	Cloudflare
	CloudflareDNS B	1.1.1.1	Global public DNS	Cloudflare
	Quad9	9.9.9.9	Global public DNS	IBM-PCH-GCA
Regional Public Resolver	OneDNS	112.124.47.27	China public DNS	Beijing Vei
	114 DNS	114.114.114.114	China public DNS	Nanjing Xinfeng
	360 DNS	101.226.4.6	China public DNS	Qihoo 360
	AliDNS	223.5.5.5	For cloud VMs	Alibaba Cloud
	Baidu DNS	180.76.76.76	For cloud VMs	Baidu Cloud
	DNSPod	119.29.29.29	DNSPod public DNS	Tencent Cloud
	Akamai Cache DNS	96.7.136.194	Operator cache node	Akamai (Edge DNS)

6.1.3. Probes Considered

Based on the functional design disclosed by open-source resolver software such as BIND9 and Unbound, most of the functions implemented by them do not exceed the scope advocated by RFC. These functions include many configuration-related and security-related features. In order to comprehensively evaluate the services provided by public resolver vendors and whether each public resolver vendor has provided diverse software functional implementation and configuration. Internally, we selected multiple types of probes from multiple dimensions for measurement. The specific probe information is shown in Table 3.

Table 3. Probe details.

Probe Item	RFC Name	Perspective	Detail	Risks
EDNS Buf Size	RFC 6891	Client End	UDP payload size	DDoS (UDP flood)
ECS Support	RFC 7871	Auth End	Geo targeting	Privacy breach
Additional Record	RFC 1035	Client End	Counter of extra RRs	DDoS (NXNSAttack)
SSHFP	RFC 4255	Client End	SSH host-key fingerprint	Middleman attack
Qname Minimization	RFC 7816	Auth End	Reduce info leakage	Privacy breach
0x20 Encoding	dnsext-dns0x20 [22]	Auth End	Increase randomness	Cache poisoning
EDE Code	RFC 8914	Client End	Extended Error code/text	Disorderly implementation
DNSSEC	RFC 4033-4035	Client End	Encrypted signature	DDoS (CVE-2023-50387)
Notify Query	RFC 1996	Client End	Zone change	Unauthorized area transmission

We basically followed the STRIDE threat modeling approach, which includes spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Considering the security threats faced by DNS, we selected the functions related to security or that had historical vulnerabilities, and constructed corresponding probes, covering issues such as DDos attacks, cache poisoning, and privacy leakage. The unreasonable design of Additional Record once led to the classic DDos attack known as NXNSAttack, and the defect in the DNSSEC verification mechanism allowed attackers to send malicious DNS packets, causing the vulnerable resolver to be in a prolonged denial-of-service (DoS) state.

Our probe design includes the following elements: the original request structure, observation points, and response patterns. Firstly, taking the client’s request for EDNS as an example, we construct a data packet carrying the EDNS0 request option, and observe whether the response data packet also carries the EDNS0 field as a response. Based on its response pattern, it can be divided into cases with and without the EDNS0 option being carried, and this is divided into two modes, corresponding to the different feature categories in Table A1. Secondly, for the authoritative server request, taking the Qname minimization strategy as an example, we send a request data packet to the target domain name. This data packet will be recursively queried when it reaches the recursive resolver. Depending on the different behavior patterns of the recursive resolver’s minimization strategy, for example, for the domain name a.b.c.example.com, we may observe from the authoritative server log the domain name requested by the resolver, including three situations: (1) a request with the complete domain name; (2) a domain name with the length of the SLD plus one length, such as c.example.com; and (3) two consecutive responses, where the lowest-level domain name being queried has an underline, such as _.c.example.com, and _.b.c.example.com. If the set timeout period is exceeded and the response result is not found in the log, it will be marked as lost. This result will not be accepted or saved by the database. Similarly, other probes have also been designed in a similar way.

6.1.4. Scan Implementation

The total test duration is 26 h. The transmission delay between data packets is 1 s. Due to the encoding mechanism, the FQDN for each request is randomly generated and is different each time. During the measurement process, for each service node within each resolver pool, only the earliest valid response and features are collected. We automatically determine which responses and features are valid through a predefined program data structure for error conditions.

6.2. Node Enumeration Analysis

We conducted measurements on 14 public resolver entry IP addresses located in five regions, and analyzed the resolver pool nodes. We also counted the number of unique resolver pool service nodes and obtained the statistical results from different regional perspectives, as shown in Table 4.

Table 4. The distribution of the number of nodes observed in each region.

Name	IP	Sole Node Count	China Mainland	Singapore	Germany	Japan	The U.S.
GoogleDNS	8.8.8.8	369	76	134	61	91	11
GoogleDNS	8.8.4.4	359	73	133	61	91	11
OpenDNS	208.67.220.220	63	23	15	19	22	9
OpenDNS	208.67.222.222	62	23	15	19	22	8
CloudflareDNS	1.0.0.1	92	35	32	32	19	9
CloudflareDNS	1.1.1.1	93	36	32	32	19	9
OneDNS	112.124.47.27	7	5	3	3	3	3
Quad9	9.9.9.9	49	21	15	15	10	6
114 DNS	114.114.114.114	7	3	3	3	3	3
360 DNS	101.226.4.6	17	9	8	9	9	5
AliDNS	223.5.5.5	17	5	6	5	5	3
Baidu DNS	180.76.76.76	49	3	47	47	47	8
DNSPod	119.29.29.29	48	10	10	13	12	8
Akamai Cache DNS	96.7.136.194	98	4	25	29	35	9

Firstly, each public resolver cluster possesses the feature of a resolver pool. Moreover, without considering the Anycast allocation strategy and assuming that the number of probes sent is evenly distributed and sufficient, based on statistical probability, Google DNS has the largest unique service node IP among all resolver pools, while the other resolver pools have relatively smaller scales. Official documents disclosing the size of the resolver pool are scarce. However, according to the official data of Google’s public DNS, Google has publicly disclosed 292 /24 to /26 segments for the use of resolver pools, covering 48 airport codes (GeoCode) [23]. Nevertheless, the nodes within these IP segments will not all be utilized.

To verify whether our enumeration level is acceptable and whether the collected node data is complete, we conducted pairwise set correlation statistics on six nodes from three public resolver clusters (GoogleDNS, OpenDNS, and CloudflareDNS) that have primary and secondary Anycast entry addresses. We found that the total number of common nodes in these three resolver clusters reached 288, 88, and 57, accounting for 65%, 91%, and 84% of the total number of nodes collected, respectively. The result is shown in the Figure 6. This result not only proves that the primary and secondary Anycast entry addresses share the resolver pool, which is consistent with the redundant backup role described by the official, but also reveals that the entry nodes have a single-point dependency on the resolver pool. On the other hand, the service nodes we collected are basically saturated, especially for the public resolver clusters such as OpenDNS and CloudflareDNS with relatively smaller resolver pools. Although Google DNS has a larger resolver pool, its enumeration completeness is lower than the other two, and this data is sufficient for our assessment of the richness of software function implementation and configuration features. To provide comparative data, based on the centralized measurement study of the on-premises DNS infrastructure by Xu et al. [13], enumerated GoogleDNS’s 2274 indirect resolvers through global relays, distributed within the 119/24 prefix, accounting for 75.8% of the data published by Google. It can be observed that the number of resolvers we collected is significantly less than that of its global relays. This is due to our limitation by the load balancing mechanism, which prevents us from crossing geographical barriers to access the services of relays that only serve other regions. However, the advantage of this study lies in not forcibly occupying TXT records for domain encoding, so that the request data packets can carry customized queries for detecting the functionality and configuration characteristics of the resolvers, achieving the characterization of the resolvers.

Figure 6. The Venn diagram depicting the inclusion relationship of node IP data of the public resolver with primary and secondary entry IP.

Meanwhile, the number of service nodes observable from each regional perspective varies. Almost all public resolver clusters have a significantly smaller number of detectable nodes in each region compared to the overall summary of public resolver pool service nodes that we observed. Moreover, the number of nodes where each public resolver provides services differs among the five countries. This indicates that there are service boundaries when public resolvers provide services to users, and users’ requests are limited to a small number of resolver service nodes, exhibiting a highly regionalized service feature. This phenomenon may be related to geographical spatial distances and the allocation measurement of public resolver vendors.

6.3. Different Public Resolvers Have Varying Features

Firstly, based on our statistical results, we analyzed whether there were significant differences in the functional implementation and configuration among different public resolver clusters. Meanwhile, for the purpose of providing specific references for local verification, we have also deployed three types of open-source resolver software, namely Bind9, PowerDNS Recursor, and unbound. We have summarized the functional characteristics and configuration features under their default configuration. We observed a wide range of features in 14 entry IPs. The differences in function options and configuration among different manufacturers were very significant, as shown in Table 5.

Table 5. Significant differences among various public resolvers.

Name	EDNS Buffer Size	ECS	DNSSEC	Glue Record	QnameMin	0x20
114 DNS	512	✗	✗, T1	✗, ✓	T2	✗
360 DNS	1232	✓	✗, T1, T2, T3	✓	T1	✗
AliDNS	1232	✓	✗, T1, T3	✗, ✓	T1, T3	✗
Baidu DNS	✗	✗	✗, T1	✗, ✓	T1	✗
CloudflareDNS|1.0.0.1	1232	✗	T1, T2	✓	T2	✗
CloudflareDNS|1.1.1.1	1232	✗	T1, T2	✓	T2	✗
DNSPod	1232	✓	✗	✓	T1, T2	✗
GoogleDNS|8.8.4.4	512	✓	✗, T1, T2	✗, ✓	T1	✓
GoogleDNS|8.8.8.8	512	✓	✗, T1, T2	✗, ✓	T1	✓
OneDNS	1232	✓	✗, T1, T2	✓	T1, T2	✗
OpenDNS|208.67.220.220	1410	✗	✗, T1, T2	✓	T2	✗
OpenDNS|208.67.222.222	1410	✗	✗, T1, T2	✓	T2	✗
Quad9	512, 1232	✗, ✓	✗, T1, T2	✗, ✓	T1, T2	✗
Akamai Cache DNS	512	✓	T1, T2	✗, ✓	T1	✗
PowerDNS Recursor 5.2.2	512	✗	T2	✗	T1	✗
Bind9 9.21.8	1232	✓	T2	✗	T1	✗
unbound 1.23.0	1232	✗	T2	✗	T1	✗

Public resolvers with the same name can have more than two kinds of features. T meaning for Type, for example, T1 means Type 1, the specific meaning can be found in the Table A1. ✓: The function has been enabled. ✗: The function has not been enabled.

Regarding the selection of the EDNS cache size [24], it generally conforms to the range suggested by the RFC, which is from 512 to 4096 bytes. Most vendors have set it to be below 1232 bytes, probably mainly to alleviate the risks of IP fragmentation and DoS amplification. However, they still follow the recommendation and set it above the lower limit of 512 bytes. Particularly, Baidu DNS ignored our requirements for the EDNS function. It might be because it does not support the related EDNS functions. Different vendors showed significant differences in the selection of this value.

We also measured the passive response logic of different vendors for DNSSEC records of domain names. We configured RRSIG, NSEC, and NSEC3 records and set the DNSSEC OK bit [17]. The features were divided into four modes, including the situation where DNSSEC verification is not supported. Excluding the data packets returned by DNSPod, no request was accepted, and no active response was given for any relevant resource records of the DNSSEC record chain. However, other nodes all had some degree of partial support for the passive response to DNSSEC records. Interestingly, different nodes of different vendors even exhibited different behavior patterns.

The collection of Qname minimization strategies [18] and 0x20 encoding [22] features is carried out at the authoritative end. Regarding 0x20 encoding, except for Google DNS, other vendors do not support 0x20 encoding. In terms of Qname minimization strategies, the core purpose of this strategy is to reduce the length of query information that recursive resolvers disclose to the authoritative server, thereby reducing user privacy exposure, mitigating the risk of log collection on the authoritative side, and suppressing side-channel analysis caused by the leakage of complete domain names. However, different public resolvers have obviously different implementation logics for this strategy, specifically manifested in the number of interactions and the degree of domain minimization.

In particular, we also paid attention to the potential privacy exposure issues that may arise from the adoption of ECS by the vendors. In the BIND9 logs, it records the actual IP subnet of the end users transmitted from the public resolver, and this information is passed through the ECS option. For example, 192.168.1.0/24/0 represents the actual original client subnet of the client, and it will expose the IP segment, region, etc., of the query source to the owner of the authoritative server. Google DNS and Dnspod will send the user’s original client subnet to the authoritative server side.

Furthermore, we conducted a cluster analysis on the similarity of feature values among different manufacturers. It is obvious that the primary and secondary entry nodes of GoogleDNS, CloudflareDNS, and OpenDNS exhibit a high degree of consistency. In fact, there are four different manufacturers with the highest similarity, including 360DNS, AliDNS, DNSPod, and OneDNS. Their common feature is that they mainly serve the Chinese mainland region. This is likely because they are subject to the same regulation and have jointly formulated relevant standards. Among them, Tencent’s Dnspod has the highest difference compared with the other three, mainly manifested in whether it responds to DNSSEC verification requests for non-existent domain names. It refuses to return DNSSEC supporting records for domains that do not exist. Secondly, the open-source software group also shows a high degree of similarity. The services provided by the remaining four DNS resolver manufacturers do not show significant similarity, presenting isolated nodes with unique software implementations and configuration strategies. Among them, quad9 adopted a hybrid solution, demonstrating logical redundancy in multiple functions. Interestingly, among these four clusters with the lowest similarity of public resolvers, all returned the Glue record, a feature that was mainly abandoned by major manufacturers and open-source software.

For the different public resolvers provided by various service providers, the core reason for their significant differences actually lies in the logical differences in their software function implementations or configuration. Fundamentally, it is due to the differences in how different manufacturers understand RFC and other draft proposals of a recommendation nature, as well as the loose implementation standards of these drafts. The richness of software logic provides different implementation and configuration solutions for the Internet infrastructure. As a form of logical redundancy, it can actually prevent the expansion of similar attacks. This difference plays a positive role in the logical centralization of the environment for Internet implementation.

6.4. Software Functional Implementation and Configuration Feature Diversity Is Significant

Although the public resolver services provided by different service providers are diverse, previous studies have analyzed the traffic collected from DNS root servers and two country code top-level domains (ccTLDs), and found that 30% of the global traffic comes from five major service providers, including Google DNS [25]. Other studies have also shown that the main public resolvers are involved in the vast majority of parsing activities on the Internet [26]. Moreover, the public resolver services provided by some service providers are mainly regional services, and their main service targets are concentrated within a certain region or a specific large local area network. Their security situation still cannot be underestimated. Therefore, studying the software functional implementation and configuration solution diversity within specific service providers is extremely significant.

We used probes to measure the features of the nodes within each public resolver pool, collecting and summarizing the number of types of each measurement indicator for all features of each public resolver, as shown in Table 6. First, by aggregating the data from different regions within the same public resolver into a whole, we found that the current resolver pools do not have a rich diversity in software function implementation patterns and configurations.

Table 6. Statistics of the types of features of each public resolver in the five regions after their merger.

Name	EDNSBuf	ECS	Glue	SSHFP	DNSSEC	NOTIFY	QnameMin	0x20	EDE Code
GoogleDNS|8.8.8.8	1	1	2	3	3	1	1	1	2
GoogleDNS|8.8.4.4	1	1	2	3	3	1	1	1	2
OpenDNS|208.67.220.220	1	1	1	3	3	2	1	1	8
OpenDNS|208.67.222.222	1	1	1	2	3	2	1	1	9
CloudflareDNS|1.0.0.1	1	1	1	1	2	1	1	1	2
CloudflareDNS|1.1.1.1	1	1	1	1	2	1	1	1	2
OneDNS	1	1	1	2	3	2	2	1	1
Quad9	2	2	2	4	3	2	2	1	2
114 DNS	1	1	2	1	2	1	1	1	1
360 DNS	1	1	1	1	4	1	1	1	1
AliDNS	1	1	2	2	3	2	2	1	1
Baidu DNS	1	1	2	1	2	2	1	1	1
DNSPod	1	1	1	1	1	1	2	1	1
Akamai Cache DNS	1	1	2	2	2	1	1	1	2

For EDE Code, there are a total of six types of probes for different projects. Here, only the type of interaction behavior with the highest IP richness for each probe is selected.

Therefore, we designed and tested two harmless DNS probes to test the relevant public resolvers, including queries for SSHFP resource records with partial erroneous data, as well as NOTIFY queries. The service nodes of various public resolvers exhibited differentiated response patterns, which partly reflected that service providers might have adopted multiple binary software images for public resolvers and had the ability to handle erroneous queries. There was a certain degree of logical redundancy. At the same time, we noticed that different public resolvers are accustomed to using some basic functional implementation logic, such as EDNS cache size, ECS support, 0x20 encoding, etc. For security-related functions, there was a certain amount of logical redundancy, such as DNSSEC, error requests, etc.

At the same time, we also noticed that the usage methods of public resolver vendors for EDE Code are very confusing. EDE (Extended DNS Error) Code [16] is defined by RFC 8914 and is used to carry machine-readable error categories and human-readable additional text in the EDNS0 OPT pseudo-record, thereby returning failure details that cannot be expressed by RCODE (4 bits) alone, such as DNSSEC verification failure, resolution blocked by policies, CNAME length exceeding limits, etc., to the client for debugging and automated handling. Previous studies have shown that different service providers and open resolver software have varying levels of support for EDE Code and that the returned EDE Code for the same error varies significantly. However, in the analysis of probe data related to EDE Code, we found that this phenomenon not only occurs between different public resolvers but also exists among different nodes of the same public resolver. For example, when measuring OpenDNS, one of our EDE Code probes returned as many as 9 EDE Codes when querying a domain without an authoritative server configured, involving EDE Codes 6, 12, 13, 14, 15, 18, 20, 24, and the “not supported” situation. Nosyk et al. [27] have conducted an analysis on related issues. The EDE Code is designed to return additional information about the reasons for DNS errors. The abuse of the same EDE Code by different manufacturers has reduced its comprehensibility, which may be detrimental to automated processing and cause collaboration problems among different manufacturers’ DNS infrastructures. This goes against the original design intention of the EDE Code and casts doubt on its practicality. We believe that in functions such as EDE Code that involve human-computer interaction and the collaboration of different systems, consistency in response should be maintained, and instead, we should seek logical redundancy in the implementation logic.

Finally, we paid special attention to several groups of public resolver pools that were equipped with primary and secondary entry IP addresses. The features exhibited by the service nodes in these pools were highly consistent, further verifying that the primary and secondary entries should be mapped to the same resolver pool and be applicable to the scenario from the perspective of regional measurement.

We calculated the entropy for each vendor (resolver), measuring the diversity/uncertainty of each resolver’s own features. For each resolver, we regarded its 9 feature values as a discrete distribution and calculated the Shannon entropy. The specific details are shown in Table 7. Among them, OpenDNS demonstrated the strongest richness, but this was mainly due to the abundance of its EDE Code. Overall, the feature redundancy of GoogleDNS was more dispersed, but only 4 functions or configurations showed multiple implementations. DNSPod and 360 DNS had the least feature redundancy.

Table 7. Per-public-resolver Shannon entropy and diversity metrics.

Rank	Resolver Name	Entropy H (Bits)	Unique Values	Value Distribution	Details
1	OpenDNS|208.67.220.220	1.657	4	$1^5,2^1,3^2,8^1$	Rich in EDE Code Types
2	OpenDNS|208.67.222.222	1.657	4	$1^5,2^2,3^1,9^1$	Rich in EDE Code Types
3	GoogleDNS|8.8.8.8	1.435	3	$1^5,2^2,3^2$	High
4	GoogleDNS|8.8.4.4	1.435	3	$1^5,2^2,3^2$	High
5	Quad9	1.446	4	$1^1,2^6,3^1,4^1$	-
6	AliDNS	1.392	3	$1^4,2^4,3^1$	-
7	OneDNS	1.351	3	$1^5,2^3,3^1$	-
8	Akamai Cache DNS	0.991	2	$1^5,2^4$	-
9	Baidu DNS	0.918	2	$1^6,2^3$	-
10	CloudflareDNS|1.0.0.1	0.764	2	$1^7,2^2$	-
11	CloudflareDNS|1.1.1.1	0.764	2	$1^7,2^2$	-
12	114 DNS	0.764	2	$1^7,2^2$	-
13	360 DNS	0.502	2	$1^8,4^1$	Lowest
14	DNSPod	0.502	2	$1^8,2^1$	Lowest
Statistics
Mean $\overline{H}$		1.099 bits
Standard Deviation ${\sigma }_H$		0.398
Coefficient of Variation		36.2%
Range		[0.502, 1.657]

Note: Value distribution notation $v^k$ indicates value v appears k times. Maximum possible entropy is $H_{max}={log}_{2}9\approx 3.170$ bits (all 9 features’ numbers are distinct).

6.5. Within and Across the Region Is Different

We also analyzed whether the software functional implementation and configuration redundancy existing in public resolver vendors might be influenced by factors such as different regional laws and regulations, which could prevent the diversity advantages of a global perspective and cross-regionalization from being reflected within specific regions. If public resolvers only exhibit logical redundancy from a global perspective but do not exist or are weakened within regional perspectives, their security still remains under scrutiny.

Therefore, we selected Google DNS, a widely used public resolver, as the analysis object. The analysis results are shown in Table 8. We found that the logical diversity of the service nodes of public resolvers decreases from a regional perspective. Google DNS has relatively rich logical redundancy in Germany and the Chinese mainland, especially in the Chinese mainland region. However, the logical redundancy in Singapore, Japan, and the United States is relatively scarce. The service nodes serving Singapore only have redundancy in whether they adopted glue records, while the United States, as the headquarters of Google’s parent company, only has one software functional implementation and configuration.

Table 8. Summary of Google DNS function features in each region.

Probe Name	Germany	Japan	China Mainland	Singapore	US
EDNS Buffer Size	512	512	512	512	512
ECS	True	True	True	True	True
Glue Record	✓, ✗	✓	✓, ✗	✓, ✗	✓
SSHFP	T1, T2, T3	T1, T2	T1, T2, T3	T1	T1
DNSSEC	T1	T1	✗, T1, T2	T1	T1
NOTIFY	T1	T1	T1	T1	T1
QnameMin	T1	T1	T1	T1	T1
0x20 Encoding	✓	✓	✓	✓	✓
EDE Code (No Auth Domain)	22	22	22	22	22
EDE Code (PROHIBITED)	✗, 22	✗	✗, 22	✗	✗
EDE Code (non-existing TLD)	✗	✗	✗	✗	✗
EDE Code (DNSKEY Missing)	9	9, 22	9	9	9
EDE Code (Unassigned Digest Algo)	✗	✗	✗	✗	✗
EDE Code (Unsupported DNSKEY)	✗	✗	✗	✗	✗

Public resolvers with the same name can have more than two kinds of features. T meaning for Type, for example, T1 means Type 1, the specific meaning can be found in the Table A1. ✓: The function has been enabled. ✗: The function has not been enabled.

This indicates that the various types of service nodes provided by Google DNS are not evenly distributed across all geographical regions globally, but rather are concentrated in certain areas. The service nodes within a region show a logical single-point status. Since accessing the nearby public resolver service nodes within a region is relatively easy, when attackers have a certain attack method targeting a specific software implementation, they do not need to use globally distributed attack nodes to attack the public resolver infrastructure within the region. The logical single-point is difficult to effectively resist this risk. Under ideal conditions, the advantages of logical redundancy in binary software images should be exploited. Different binary software images should be distributed relatively evenly across the globe to enhance the robustness of the public resolver from both global and regional perspectives.

7. Ethics

During the experiment, we used randomized FQDNs and conducted repeated queries. Regarding the ethical issues associated with this operation, first, from the perspective of the public resolver, during the experiment, we used a limited bandwidth for testing. The bandwidth of each measurement node was 10 Mbps, and a 1-s query interval was set for each load. At the same time, each was designed to avoid affecting the entry of the public resolver and its sub-nodes. Secondly, in terms of the impact on user access, the authoritative domain name we used was for personal deployment and was only used for experimental purposes. It would not affect the normal access behavior of the Internet, and the randomized FQDN requested was not in the form that daily users would use.

Regarding the ethical issues in the design of the probes, the main focus is on the SSHFP and NOTIFY probes. We will explain the specific design methods for these two types. The design of the SSHFP probe is structurally correct and not malformed packets. We used the RSA algorithm and SHA-1 fingerprint type, and set an invalid fingerprint as the content of the fingerprint field to verify the handling method when the client sends an incorrect SSH host key hash value. Since the transmission of incorrect key fingerprints is a common error in normal Internet behavior, and through local deployment tests on mainstream open-source resolvers such as Bind9, unbound, knot resolver, and pdns recursor, it was all due to software errors and responses such as REFUSE. The design of the NOTIFY probe is not a malformed packet either. In code, it is represented as a NOTIFY request for a certain record to an authoritative server. Since the client is not a real authoritative server, the resolver does not have the relevant functions involved in NOTIFY, and the server side will ignore NOTIFY requests from unknown authoritative servers, and the target server is our controlled experimental dedicated authoritative server. The main purpose of this design is to explore the handling methods of different public resolvers when they receive client NOTIFY requests and the responses from the authoritative end.

8. Limitations

Although the proposed fingerprint identification method can effectively reveal the differences in configuration and implementation among public resolvers, this assessment has two major limitations.

Firstly, the measurement activities only covered five countries or regions (four geographical areas, including North America, Europe, East Asia, and Southeast Asia). Although these observation points could capture the main any broadcast footprints, they failed to fully reflect the situations in Africa, South America, and the Middle East, as routing strategies and resolver deployments have unique features in these regions. Therefore, the global generalization estimates derived from the current dataset may be biased towards the regions under study. This study focuses on the proposal of the measurement framework, and partially reveals the possible functional features and configuration diversity as well as the centralization issues in the global DNS public resolver infrastructure. From the measurement results, this study has discovered diverse functional features and configuration diversity, proving the feasibility of the framework, and to a certain extent, has revealed the differences among public resolvers, as well as the differences among public resolvers in different regions. This provides a research perspective for further studies. Due to cost limitations, this study has attempted to select the geographical locations of major countries and regions from multiple continents as much as possible to measure these phenomena.

Secondly, the termination criteria used in the active probing process are relatively conservative, which may result in the omission of any anycast nodes with low access frequencies. Therefore, the inferred resolver pool may be incomplete, and those rare implementation variants that only occur in specific load balancing events may also be overlooked. To achieve comprehensive coverage, it is necessary to improve the termination rules and adopt longer-lived distributed probing.

Finally, the main objective of this study is to introduce dual-end measurement of both the client and the authoritative segment from the spatial dimension to enrich the observation perspective. At the same time, it aims to explore the possible functional implementation and configuration diversity within the DNS resolver cluster, in order to alert against the deficiency of logical redundancy in the functions. This study does not incorporate the time dimension as a perspective. The deployment strategy adjustment of service providers in linear time is also a task that needs to be explored.

9. Discussion

9.1. Logical Single-Point Denpendency

Overall, although resolver vendors have adopted the Anycast mechanism to announce the same service address to multiple nodes worldwide, and utilize BGP to automatically direct requests to the nearest instance, reducing RTT and naturally resisting DDoS, if their software functional implementation and configuration is single, there will still be logical single-point dependencies. Attackers launching general attacks from multiple geographical regions will still be difficult to defend against. We have noticed that the public resolvers we studied all have certain logical redundancies, which is an active behavior. By adopting multiple software functional implementations or configuration schemes to ensure the risk resistance of the public resolver, the logical redundancies of some public resolvers are not significant. At the same time, we have also observed that Google DNS has insufficient logical diversity in some regions. Therefore, public resolver service providers, especially large-scale global public resolver service providers, ideally, should adopt as many different software functional implementations or configuration schemes as possible, and make the nodes constructed by different images more evenly distributed to serve various regions around the world.

9.2. Future Work

We know that the public resolver is just one category of resolvers. There are also numerous self-built public resolvers on the Internet, some of which provide resolution services externally and are also part of the Internet infrastructure. Future research can consider including these resolvers in the scope of consideration. Additionally, one of the main focuses of our work is to utilize the two-way measurement framework to observe the interaction behavior between the resolver and the authoritative end. This enables us to observe more resolver software functional implementation and configuration features even when only conducting black-box testing, which is of positive significance for software security analysis and profile acquisition. At the same time, the deployment strategy adjustments made by the manufacturers over a continuous period also merit in-depth study. This framework is capable of completing the measurements within approximately one day and has already enabled continuous-time measurements.

10. Conclusions

We have designed and implemented a dual-ended measurement public resolver framework, which makes it possible to observe any public resolver node. At the same time, we analyzed for the first time the centralization degree of public resolvers from the software implementation logic perspective. Through the measurement of the software implementation and functional logic of 4 large public resolvers and 7 regional resolvers from the perspectives of 5 countries and regions, we found that the software implementation logic of different public resolvers is diverse and has the characteristics of regionalized call service nodes. At the same time, the same public resolver will provide configuration or software implementation redundancy. However, from the regional perspective, the diversity of software implementation logic within the same country or region will be significantly reduced. The characteristic entropy value of Google in five regions is 1.435, while in the Silicon Valley region of the United States, there is only one software implementation version, which will lead to security risks in regional infrastructure.