Research on the Construction of High-Trust Root Zone File Based on Multi-Source Data Verification

Abstract

The root zone is located at the top level of the DNS system’s hierarchical structure and serves as the entry point for all domain name resolutions. The accuracy of the root zone file determines whether domain names can be resolved correctly. To solve the problems of single-source distrust and inaccurate data in the use of root zone files, this paper utilizes multi-source root zone files to build an accurate, real-time, and highly trustworthy root zone file through the validation of data accuracy and integrity. First, we propose a weighted voting statistical verification method. We select top-level domain name records with the highest confidence from the multi-source root zone data, thereby improving data accuracy. Second, through a dynamic cyclic construction process, we achieve dynamic monitoring of root zone file version changes, effectively ensuring the real-time nature of root zone data. Finally, we adopt a DNSSEC verification mechanism to address the issue of unreliable transmission paths for actively probed root zone data, ensuring data integrity by verifying the signed top-level domain name records and their ZSK, KSK keys. In addition, through the analysis of experimental data, we find that the main reason for the inaccuracy and unreliability of the root zone file is the delay in updating and synchronizing the file. We also discover the presence of redundant KSK keys in some of the source root zone data, which led to failure in the DNSSEC validation chain. The high-trust root zone file constructed in this paper provides data support for research on the root-side resolution anomaly detection and localization application of root zone files and has wide-ranging practical value.

1. Introduction

The root servers are at the top level of the DNS system hierarchy and are the starting point for all domain name queries. Whether its resolution is normal determines whether the subsequent iterative process of a domain name resolution is normal. As is known to all, the root server is mainly subjected to DDoS attacks [1]. To mitigate such attacks and possible infrastructure failure or disruption, a large number of root instances have been deployed worldwide using anycast technology. As of 7 March 2023, there are 1643 root instances belonging to 13 root servers labeled A-M deployed worldwide [2]. Anycast technology routes user query requests to the nearest mirror node using BGP routing [3,4,5], reducing the delay in domain name resolution and limiting the impact of DDoS attacks if they occur [6]. In addition to DDoS attacks, the root zone file is also an important factor affecting root service performance. For instance, when a root server fails to update the root zone file in a timely manner, it may use outdated root zone data, resulting in resolution errors and thus, impacting the resolution performance of the root server. The root zone file contains NS records and their corresponding A/AAAA records for all top-level domain names. It serves as the basis of root server resolution function. If the root zone file is forged or tampered with, the harm is far greater than attacks on other hierarchical domain names. As global top-level domain name registrations increase, the required delay and overhead for synchronizing updates to the root zone file also gradually increase [7]. If a root server instance fails to timely update to the latest version of the root zone file, it will also affect the normal resolution of user domain names within its service scope [3]. In addition, to improve the root resolution performance and security, the trend of localizing root services based on the international root service localization standard RFC8806 [8] is gradually rising. Statistically, as of November 2022, at least 283 root zone replica nodes have been built in China, serving 527 recursive nodes [9]. The key to local root construction is ensuring the root zone file is the latest version and that the root zone data are high-trust.

Based on the above issues, building an accurate and high-trust root zone file has important research significance and practical value. Currently, the way to obtain the root zone file is often quite limited, which is solely through DNS requests or zone transfer requests to get a single-source root zone file. It is difficult to determine whether the obtained file is the latest version or has been tampered with or forged. Therefore, how to build an accurate, real-time, and highly trustworthy root zone file is the focus of this paper. First, we obtained multi-source root zone files through various means and proposed a weighted voting statistical verification method. We used this method to calculate the confidence of each top-level record and then select the highest confidence record value to improve the accuracy of the root zone file. Additionally, we use the DNSSEC verification mechanism to verify the signed data of top-level domain name records, ensuring the integrity of the root zone file data. Finally, through a dynamic cycle construction process, we continuously monitored the version changes of the root zone file in real time, ensuring the timeliness of the root zone data.

The main contributions of this paper are summarized as follows:

(1)

We have constructed an accurate, real-time, highly trusted root zone file. The file has a wide range of uses for building local root resolution services, root-side resolution anomaly discovery, and research into monitoring root zone data change characteristics and patterns;

(2)

A weighted voting statistical verification method is proposed. This method can determine the accurate and reliable weight of different root zone files from different sources, and the most credible record data can be selected. Additionally, this method can dynamically monitor updates and changes in root zone files, improving root zone data’s accuracy and real-time nature;

(3)

Using the DNSSEC verification mechanism, signature verification was performed on the root zone top-level domain records and their ZSK, KSK keys, ensuring the integrity of root zone data;

(4)

Full coverage dynamic monitoring of the resolution data of the 13 root servers, including NS and SOA records of all top-level domains, is achieved using different geographic probing points. These active probing data contribute to the construction of highly trusted root zone files and provide real-time feedback on the root server resolution status, which can be widely used for root-side resolution quality assessment and anomaly detection.

2. Related Works

2.1. Root Zone Data Management

Many studies have given solutions to better distributing and managing the root zone file. One of the critical points of the current study is the issue of decentralized management, and blockchain technology is often used to do so. Through blockchain technology, the multi-party participation, transparency, and automation of root zone management can be improved, as well as protecting the national top-level domain autonomy [10,11,12]. In addition, the blockchain-based distributed network allows nodes in the root zone to join and exit at any time, which can effectively solve the problem of a single point of failure in root zone data transmission [13,14]. The root server deploys the root instance through anycast technology, and each root server instance maintains a root zone file. The deployment of root mirrors can not only effectively resist DDoS attacks, but also improve the resilience and robustness of the DNS system [15,16,17]. In addition, the localization of the root zone file is realized on the recursive side. By using the copy of the root zone file, the network failure can be limited to the local area, the domain name resolution delay will be reduced, and the root-side resolution performance can be improved as well. At the same time, to strengthen the security of DNS root zone files, the combination of keys and signatures can be used to effectively mitigate the risk of being attacked [18,19]. These studies are all aimed at analyzing the importance of the root zone file and putting forward different solutions to some possible problems, but most tend to use decentralized technical methods. Although it can improve the system’s security, this method does not conform to the current DNS system framework and needs to be modified, so it has yet to be widely used. At the same time, there is a lack of research on root-side resolution anomaly detection and root zone file credibility issues due to inaccurate root zone files.

2.2. Root-Side Resolution Anomaly Detection

The root server is the entrance of DNS resolution. If the root-side resolution occurs abnormally, it will lead to large-scale domain name resolution failure, and users cannot access the Internet. The study of root-side resolution anomalies has been a key research direction for researchers. To improve the security of the DNS system, Wang W et al. [20] realized decentralized DNS root-side data storage and analysis through blockchain technology and verified the resolved data, effectively eliminating the lack of verification. Utilizing XDP for a deep packet inspection of DNS and implementing a data plane Naive Bayes classifier inference can mitigate NIC driver-level DDoS attacks toward DNS servers and improve the throughput of effective DNS responses [21,22]. Many researchers have also effectively mitigated DDoS attacks by using methods such as restricting attack traffic to specific regions and BGP Flowspec rules [6,23]. The root server can effectively reduce the DDOS attack by deploying the root server instances, but it also brings new security and performance problems. Through active measurement, the study found that the service performance of the root instance is often affected by factors such as BGP policies and deployment types [24,25]. In addition, root instance resolution also has cross-border access problems [3,5]. Jones B et al. [26] identified the presence of unauthorized root servers and root server proxies in the Internet by analyzing root resolution BGP routes and response latency TTL based on the measurement platform ripe atlas. Currently, root-side resolution anomaly detection mainly focuses on DDoS attacks, and most detection methods use blockchain technology, machine learning, or deep learning algorithms [12,27]. However, none of these detection methods takes into account the root zone file anomaly. For example, suppose a root server instance does not update the root zone file to the latest version in time. In that case, users in its service range may query the outdated NS records of some TLDs, which will also lead to domain name resolution failure. They may even direct the user query request to the attacker-controlled authoritative server, resulting in a hijacking event for all domains under the top-level [28].

Most current research on root servers focuses on DDoS attack detection and root instance quality of service assessment or its influencing factors. Recent research on root servers focuses mainly on detecting DDoS attacks and evaluating the service quality of root server instances or their influencing factors. This paper, however, focuses on the reliability of a root zone file. The high-trust root zone file construction model proposed in this article can detect and exclude anomalous data only through voting statistics and signature verification mechanisms. Compared to machine learning and deep learning, the abnormal data detection process is simpler and more efficient than the complex sample training process.

3. Building High-Trust Root Zone File

The process of building a high-trust root zone file mainly included two parts: a data acquisition part and data verification part. As shown in Figure 1, to improve the accuracy of the data, we first obtained the data of multi-source root zone files. Then, we used the SOA serial to initially filter out outdated root zone files by screening the multi-source data. Subsequently, we verified the accuracy and integrity of each TLD record in the root zone by utilizing a weighted voting statistical verification method (WVSV method for short) and DNSSEC verification mechanism, thus building a highly available root zone file.

3.1. Multi-Source Root Zone Files Acquisition

Building a high-trust root zone file cannot rely solely on a single source. Obtaining root zone data through only one channel cannot ensure that the data is the latest version and accurate. Therefore, we needed to first get multi-source root zone files through various methods, and the specific acquisition process is shown in Figure 2.

There are two ways to obtain the multi-source root zone files. The first is to obtain the entire root zone file at once through ftp/https or AXFR (based on TCP protocol), and the second is to obtain top-level domain name resolution records (including NS records and their A/AAAA records) from different root server instances through active domain name resolution, which together form the root zone file. The reason for using DNSSEC verification for the second data is that domain name resolution is mostly based on the connectionless UDP protocol, lacking a state verification mechanism, and data is susceptible to being forged or tampered with during transmission.

• Complete root zone file download. We could obtain the complete root zone file by https or ftp request to the root zone file download address [29] provided by IANA.
• AXFR transfer acquisition. Through the verification of the 13 root servers, it was found that 7 servers (B/C/D/E/F/G/K) had a complete zone transfer function (AXFR). In addition, ICCAN provided two servers with root zone AXFR transfer function: “lax.xfr.dns.icann.org” and “iad.xfr.dns.icann.org”. We obtained 9 different source root zone files by sending AXFR transfer requests to these 9 servers.
• Acquisition of root zone file maintained by root server instances. To obtain the root zone data currently held by different root server instances, we utilized the different geographic probing points to actively request the NS records and their associated A/AAAA records of all 1481 TLDs from the 13 root servers to form complete root zone data. At the same time, in order to implement source filtering and accuracy verification in subsequent steps, we also obtained the signature data of SOA records and NS records. The specific verification process is described in detail in Section 3.2.1.

3.2. High-Trust Root Zone File Verification Model

3.2.1. Weighted Voting Statistical Verification Method

For the obtained multiple root zone files, we first filtered them by comparing their SOA serial numbers. The largest serial number was determined, and any root zone files with a serial number smaller than the largest one were discarded since they were outdated data. For the filtered root zone files, we proposed a Weighted Voting Statistical Verification method (WVSV method) to improve the accuracy of these files. This method focused on inconsistencies in root zone file versions and top-level domain records among multi-source root zone files. First, we transformed the n top-level domain records of the m sources’ root zone files into a resource matrix R_mn:

$$\mathit{R}=\left[\begin{array}{cccc}{\mathit{r}}_{11}& {\mathit{r}}_{12}& \cdots & {\mathit{r}}_{1\mathit{n}}\\ {\mathit{r}}_{21}& {\mathit{r}}_{22}& \cdots & {\mathit{r}}_{2\mathit{n}}\\ ⋮& ⋮& \ddots & ⋮\\ {\mathit{r}}_{\mathit{m}1}& {\mathit{r}}_{\mathit{m}2}& \cdots & {\mathit{r}}_{\mathit{m}\mathit{n}}\end{array}\right]$$

(1)

the r_ij represented the content of the j-th top-level domain record of the i-th data source. Since there were m data sources, a top record might have had m different types, so we numbered each top-level domain record by different types (1, 2, 3, …, m) and constructed the data matrix D corresponding to the resource matrix R_mn. The d_ij represented the type number of the j-th top-level domain record content of the i-th data source.

$$\mathit{D}=\left[\begin{array}{cccc}{\mathit{d}}_{11}& {\mathit{d}}_{12}& \cdots & {\mathit{d}}_{1\mathit{n}}\\ {\mathit{d}}_{21}& {\mathit{d}}_{22}& \cdots & {\mathit{d}}_{2\mathit{n}}\\ ⋮& ⋮& \ddots & ⋮\\ {\mathit{d}}_{m1}& {\mathit{d}}_{m2}& \cdots & {\mathit{d}}_{mn}\end{array}\right]$$

(2)

Considering that the j-th column D(j) of the data matrix D was an m-dimensional column vector, we constructed the corresponding matrix H^(j)_mn for the different records in D(j) so that for each j = 1, 2, 3, …, n, there was:

$${\mathit{H}}^{(\mathit{j})}=\left[\begin{array}{cccc}{\mathit{h}}_{11}^{(\mathit{j})}& {\mathit{h}}_{12}^{(\mathit{j})}& \cdots & {\mathit{h}}_{1\mathit{m}}^{(\mathit{j})}\\ {\mathit{h}}_{21}^{(\mathit{j})}& {\mathit{h}}_{22}^{(\mathit{j})}& \cdots & {\mathit{h}}_{2\mathit{m}}^{(\mathit{j})}\\ ⋮& ⋮& \ddots & ⋮\\ {\mathit{h}}_{\mathit{z}1}^{(\mathit{j})}& {\mathit{h}}_{\mathit{z}2}^{(\mathit{j})}& \cdots & {\mathit{h}}_{\mathit{z}\mathit{m}}^{(\mathit{j})}\end{array}\right]$$

(3)

where z∈ [1, m] and h^(j)_ki represented whether the type of j-th top-level domain record content of the i-th data source equaled the k-th type. If the answer was YES, which meant D_ij = k, then h^(j)_ki = 1; otherwise, the h^(j)_ki = 0.

To reflect the accuracy of each source, we set the weight w_i for the i-th source, which formed a vector of weights W = [w₁, w₂, …, w_n]. Initially, w_i was set to 1.

The weight was the proportion of correct votes voted by the source to the total count of votes. Once we had the weight vector, we could implement the weighted voting statistical process. The output matrix of the process was A_mn:

$$\mathit{A}=\left[\begin{array}{cccc}{\mathit{a}}_{11}& {\mathit{a}}_{12}& \cdots & {\mathit{a}}_{1\mathit{n}}\\ {\mathit{a}}_{21}& {\mathit{a}}_{22}& \cdots & {\mathit{a}}_{2\mathit{n}}\\ ⋮& ⋮& \ddots & ⋮\\ {\mathit{a}}_{\mathit{m}1}& {\mathit{a}}_{\mathit{m}2}& \cdots & {\mathit{a}}_{\mathit{m}\mathit{n}}\end{array}\right]$$

(4)

the a_ij represented the trust level of the j-th top-level domain record to be the i-th type, which was the sum weight of the votes voted by all sources with this type of record. The higher the trust level was, the more trustworthy the record was. We built the high-trust root zone file by filtering out the record content with the highest trust level from each column of the output matrix A, denoted as max(A(j)). The formula of the matrix A’s j-th column A(j) was:

$$\mathit{A}\left(\mathit{j}\right)={\mathit{H}}^{(\mathit{j})}\times {\mathit{W}}^{\mathit{T}}$$

(5)

which was calculated with matrix multiplication of the matrix H(j) and the transpose of the vector W; the element a^(j)_k in A(j) was calculated by the formula below:

$${\mathit{a}}_{\mathit{k}}^{(\mathit{j})}={\displaystyle \sum _{\mathit{i}=1}^{\mathit{m}}{\mathit{h}}_{\mathit{k}\mathit{i}}^{(\mathit{j})}}{w}_i^T$$

(6)

The building process had to be carried out in a dynamic loop to ensure the root zone file was in real-time. In addition, after each round of the WVSV process, the weight vector needed to be corrected to improve accuracy. The formula of correction was:

$$w_{i^{\prime }}=\frac{w_i\ast (rou\mathit{n}d-1)+p_i}{rou\mathit{n}d}$$

(7)

where p_i was the proportion of the records given by the i-th data source that was the same as the corresponding records in the high-trust root zone file in the current round. In particular, if the SOA serial of a data source was below the latest version in the current round, the p_i equaled 0. The algorithm of the WVSV process is Algorithm 1.

Algorithm 1. The Weighted Voting Statistical Verification Algorithm

Initialization: W = {1, 1, 1……1, 1, 1}; round = 0;

Input:  R(i,j) (i ∈ [1, m], j ∈ [1, n]);

Output: A high-confidence root file for each round;

While True do

round += 1;

Build the data matrix D basing on the resource matrix R;

for i in range m do

if SOA serial of ith data source equals to the latest SOA serial then

for j in range n do

Build corresponding matrix H(j);

Get voting column vector: A(j) = H(j) × WT;

Select the highest confidence type of record: max(A(j));

end for

Calculate pi and w;

Update vector W;

else then

Update vector W where the pi = 0;

end for

Output the high-confidence root file: [max(A(1), max(A(2)), …, max(A(m))].

end while

3.2.2. DNSSEC Verification

In the multi-source root zone files we acquired, some of the source data was obtained through active measurement of root server instances. While querying and responding, as UDP protocol without authentication mechanism is used, the data may be maliciously forged and tampered with, making this portion of data unreliable during transmission. To address the issue of data credibility, we utilized the DNSSEC mechanism to verify the integrity of that particular data set. The crux of DNSSEC was to sign resource records via the data owner. Leveraging the hierarchical structure of DNS, we employed a bottom-up chain signature verification method to ensure the reliability of the transmission process. DNSSEC verification process involved data in addition to NS records, but it also required three other types of resource records: one DNSKEY record, which contained the KSK (key signing key) and ZSK (zone signing key) of the region; the second was the DS record, which was the digest information of the KSK; and the third was the RRSIG record, which was the signature data of the top NS resource record.

The reliable data of high-trust root zone file constructed in this article focused on the NS records of each top-level domain and their corresponding A and AAAA records. The A and AAAA records served as glue records and were configured in the additional section of the response message. As the top-level zone had no authority to sign the additional section records, we performed trustworthy validation only for NS records through DNSSEC signature chains.

Figure 3 gives the DNSEC validation chain process for top-level domain NS records. Since the DNSSEC validation process is chained, the root zone part (left part of Figure 3) is always validated for different TLDs, so there is no need to validate each TLD once. In addition, considering the reliability of the root zone validation part, there was almost no possibility of tampering, so we defaulted the root zone validation part as trusted, and only the top-level domain zone (the right part of Figure 3) was validated for integrity.

The specific steps of DNSSEC verification were as follows:

• First, the ZSK key (included in ZSK RR) was used to sign the NS records of each source TLD to obtain the signature data RRSIG_{ns_probe}. Then, it was compared with the RRSIG_ns that came with each NS record in the source. If the values were inconsistent, the source TLD record was discarded. If they were consistent, the next verification session was carried out.
• The KSK key (included in KSK RR) was used to sign the ZSK key (included in the TLD DNSKEY record), and the signature data RRSIG_{zsk_probe} was compared with the RRSIG_zsk in the source. If the values were inconsistent, the source TLD record was discarded; if they were consistent, the next verification session was carried out.
• The encrypted digest information of the KSK key (included in KSK RR) was obtained through the SHA-1 algorithm, and it was compared with the DS RR set from root zone. If the digest information was inconsistent, the TLD record in the source root zone file was discarded, and if they were consistent, the next verification session was carried out.

The weighted voting statistical verification method effectively solved the problem of inconsistency in the root zone data of different sources and improved the accuracy of the data. Through the DNSSEC verification mechanism, forged and tampered data in the transmission path was filtered out, effectively ensuring the integrity of the root zone file. The two methods complemented each other to ensure the high trustworthiness of the root zone file.

3.2.3. Dynamic Cycle Construction

To achieve the dynamic monitoring of changes to the root file version in order to ensure the timely updating of the constructed high-trust root file, the building process of the root zone file shown in Figure 1 was a dynamic cycle process. After a round of construction was completed, new data was obtained, and the next round of building would start.

4. Experimental Analysis

4.1. Root Zone File Version Update Cycle

Figure 4 shows a statistical graph of the update cycles between the 41 root zone file versions over two weeks. The figure shows that the update cycles between two root zone file versions are mainly concentrated in the 600–800 min range (37%) and the 400–600 min range (24%). Although the statistics can determine that the root zone file version update cycles are at the hourly level, the specific update time cannot be determined, and there is no regular pattern to follow. The cycle period of our high-trust root zone file construction process cannot be at the hour level. To monitor the version changes of the root zone file as much as possible and update the root zone file in time, we choose the second level (30 s) for the cycle period.

4.2. Root Zone File Source Weight Analysis

With Equation (7), we ensure that sources with a high voting accuracy will receive increasingly larger weight values. In comparison, sources with a low accuracy will have increasingly smaller voting weight values, thus effectively determining the credibility of each source. Figure 5 shows the weight variation of four different root instance sources. It can be seen that the weight variations of each source are large in the first 60 rounds. Still, as the number of subsequent cycle rounds increases (every 30 s per round), the weight values of the four sources gradually stabilize. The weight stability values (approximately 0.94) of the “b2-iad” from root B and “c01.SJC.eroot” from root I are significantly higher than those of the E and J root instance sources (approximately 0.8), indicating that the accuracy of the root zone files maintained by different root instances is inconsistent. This is related to the convergence delay of each root server instance when updating and synchronizing the root zone file. If the delay is too long, it may result in us requesting outdated data during the data acquisition process, which reduces the accuracy of the source. Different sources have different update and synchronization times, which results in an inconsistent accuracy.

4.3. Invalid Votes of TLD Records Analysis

When building a high-trust root zone file using the WVSV method, we counted the invalid votes of each top-level domain record, as shown in

Table 1. Invalid votes of top-level domain records data.

SOA Serial	TLD	RR Type	Invalid Records	Records in the High-Trust Root Zone File
2023030902	.HELP	NS	ns1.uniregistry.net; ns2.uniregistry.info; ns3.uniregistry.net; ns4.uniregistry.info	a.nic.help; b.nic.help; c.nic.help; d.nic.help; ns1.uniregistry.net; ns2.uniregistry.info; ns3.uniregistry.net; ns4.uniregistry.info
	.NG	NS	ns2.nic.net.ng; ns5.nic.net.ng; nsa.nic.net.ng	ns2.nic.net.ng; ns3.nic.net.ng; ns4.nic.net.ng; ns5.nic.net.ng; nsa.nic.net.ng
2023031303	.LB	NS	fork.sth.dnsnode.net; nn.uninett.no; ns-jp.lbdr.org.lb; ns3.seacomnet.com; ns4.seacomnet.com; rip.psg.com	fork.sth.dnsnode.net; nabil.beirutix.net; nn.uninett.no; ns-jp.lbdr.org.lb; ns3.seacomnet.com; ns4.seacomnet.com; rip.psg.com
	.MM	NS	a.nic.net.mm; b.nic.net.mm; c.nic.net.mm; d.nic.net.mm	a.nic.net.mm; b.nic.net.mm; c.nic.net.mm; d.nic.net.mm; ptd.net.mm
	.NG	AAAA	2a00:fea0:dead::beef; 2001:43f8:120::41	2001:500:14:6040:ad::1; 2a00:fea0:dead::beef; 2001:43f8:120::41
2023031402	.FI	A	193.166.4.1; 194.146.106.26; 194.0.11.104; 77.72.229.253; 194.0.1.14; 204.61.216.98; 87.239.120.11; 194.0.25.30; 185.159.199.190	193.166.4.1; 194.146.106.26; 194.0.11.104; 77.72.229.253; 194.0.1.14; 204.61.216.98; 87.239.120.11; 194.0.25.30; 185.159.199.190; 213.186.229.226
	.HELP	NS	a.nic.help; b.nic.help; c.nic.help; d.nic.help; ns1.uniregistry.net; ns2.uniregistry.info; ns3.uniregistry.net; ns4.uniregistry.info	a.nic.help; b.nic.help; c.nic.help; d.nic.help
	.SN	AAAA	91.203.32.147; 13.39.116.127; 213.154.64.11; 193.0.9.111; 194.0.9.1; 196.1.95.1;	13.39.116.127; 194.0.9.1; 196.1.95.1; 213.154.64.11; 193.0.9.111

. According to this table, the invalid votes of top-level domain records contain not only NS records, but also corresponding A or AAAA records. The invalid votes’ corresponding invalid records of top-level domain NG, LB, and MN have some top-level domain server records missing compared with the high-trust root zone file. The case of top-level domain HELP is more complicated. It has some top-level domain server records missing in some versions of the root zone file (e.g., SOA serial: 2023030902), and the removal of some top-level domain server records was forgotten in some versions of the root zone file (e.g., SOA serial: 2023031402).

If a top-level domain server record is missing, it may cause the loads to not be distributed evenly to each top-level domain instance, and it is more harmful if a top-level domain server record is forgotten. Hackers can use a malicious top-level domain instance to hijack all customers using this record; visiting subdomains associated with the hijacked top-level domain could lead to security risks or compromises.

4.4. DNSSEC Verification Analysis

In the process of DNSSEC verification of different root instance source data obtained from active measurements, there are several cases of TLD records DNSSEC verification failures, and the verification failure links are found to occur in the process of KSK verification after an analysis. Based on the analysis of the data obtained in nearly one month, we find 7 TLDs (out of 1481, accounting for about 0.47%) with KSK redundancy in the process of doing DNSSEC verification. Furthermore, it appears to be a relatively stable phenomenon that the signing records have not returned to normality (i.e., single KSK per TLD) yet. As shown in

Table 2. Example of TLD records that failed DNSSEC verification.

TLD	Failure Session	Key Records in the Root Zone File	Actual Valid Records
.HK	KSK Verification	257 3 8 AwEAAbLy…Tf6fsjk=; 257 3 8 AwEAAeEa…iuxG7lM=	257 3 8 AwEAAbLy…Tf6fsjk=
.GD	KSK Verification	257 3 8 xdwIxVEH…RjLsWQ==; 257 3 8 AwEAAct6…v0cTAlM=	257 3 8 xdwIxVEH…RjLsWQ==
.GDN	KSK Verification	257 3 8 AwEAAcEB…OZk2NgJF; 257 3 8 AwEAAcyA…3b2or4FH	257 3 8 AwEAAcEB…OZk2NgJF
.SK	KSK Verification	257 3 13 RYBmurcP…dUyD9w==; 257 3 13 0daAK0XI…CDwJmQ==	257 3 13 RYBmurcP…dUyD9w==
.XN--4DBRK0CE (.ישראל)	KSK Verification	257 3 13 lIESvLTk…SydupQ==; 257 3 13 BLa649ww…xwu32w==	257 3 13 lIESvLTk…SydupQ==
.XN--80ADXHKS (.мoсква)	KSK Verification	257 3 8 AwEAAeXh…FgQADt8=; 257 3 8 AwEAAdbk…HGAAFzs=	257 3 8 AwEAAdbk…HGAAFzs=
.XN--J6W193G (.香港)	KSK Verification	257 3 8 AwEAAcBL…qXcCCPM=; 257 3 8 AwEAAdRp…Aduqnjc=	257 3 8 AwEAAcBL…qXcCCPM=

, the number of key records in the root zone file to be verified and the actual key records used for the signing process are not equal, which means there is redundancy in the top-level key records in some source root zone files. Specifically, as shown in the first row of the table, when verifying the “HK” record from root D, there are two KSK key messages in the KSK verifying the ZSK signature data session, and the session verification fails because it is not possible to determine which KSK is selected for the signature operation. To determine which of the two keys is correct, we sign the ZSK with both KSK keys, then compare the resulting signature data with HK’s RRSIG_zsk. It is found that one of the keys (“257 3 8 AwEAAbLy…Tf6fsjk=”) has signature data that could be verified.

Our analysis suggests that such cases may be caused by TLD administrators not removing outdated KSK records when updating them because the proportion of this redundancy occurrence is pretty tiny (more likely a personal misconfiguration). This redundancy in DNSKEY records may hinder the general DNSSEC verification process and can reduce the efficiency of its validation and the usability of root zone data, even though some resolvers may be able to identify the right KSK, which is now actually being used, and make use of it. It is possible that the phenomenon of redundancy in DNSSEC records is not confined to KSK; however, such redundancy will ultimately lead to a negative effect on resolution efficiency. During the construction of the high-trust root zone file, we will filter the TLD records that fail in this process to ensure a high usability of the root zone file. In Table 2, the last three rows of the first column display the punycode encoding and original form of three internationalized top-level domain names.

5. Discussion

Reduce the synchronization delay of root zone file updates. The main reason for the abnormality of root zone data is the failure to timely update and synchronize the root zone file to the latest version. With the increasing number of top-level domains in the root zone, the root zone file is getting larger, and the time required for updates is also increasing. Therefore, it is recommended that each root server instance should use an incremental zone transfer query (IXFR) to obtain the record information of root zone changes as much as possible when updating the root zone file and use the full zone transfer (AXFR) as little as possible in order to reduce the update time and reduce the possibility of users requesting outdated data. Another factor that affects the update delay of the root zone data is the transmission distance between the instance node and root server. As the distance increases, the update time of the root zone file will increase linearly. Therefore, when introducing and deploying root server instances, administrators need to consider various factors, including the update delay of the root zone file, and determine the appropriate deployment location for the root mirrors through a comprehensive analysis. In practice, it is a challenge for a large distributed system, such as the DNS system, to quickly achieve the synchronization of updated root zone data across all instance nodes. While a DNS system can reduce the risk of transmission latency and data inconsistency through IXFR and active notification mechanisms, it cannot completely avoid the issue of synchronization delays. From the perspective of DNS resolvers, maintaining a local, highly trusted root zone file can avoid synchronization delay issues and reduce domain name resolution latency. The key to building a local root zone file is how to obtain a highly trusted root zone file, which is the problem addressed in this paper.

Enhance root zone file trustworthiness verification. The root zone is the starting point for DNS queries, and the accuracy of the root zone data determines whether a domain name resolution and the various applications that rely on DNS can be appropriately performed. Therefore, when using the root zone file, it is necessary to strengthen the verification of its trustworthiness to ensure the accuracy of the root zone data. It is also necessary to dynamically monitor changes in the version of the root zone file and update the latest version of data in a timely manner to prevent the use of outdated data. The high-trust root zone file constructed in this paper using the weighted voting statistical verification method and DNSSEC mechanism effectively improves the accuracy of the root zone data, ensures data integrity and real-time performance, and can provide data support for users to build root zone file applications. The best mechanism for a secure resolution of top-level domain names based on root zone data is DNSSEC, which can effectively prevent the integrity of resolution data through its signature encryption mechanism. However, unfortunately, its deployment rate is still relatively low, especially on the DNS resolver side.

6. Conclusions

Based on multi-source root zone files, this paper builds an accurate, real-time, and high-trust root zone file by verifying the accuracy and integrity of the root zone data. During construction, we utilize the weighted voting method to accurately validate the root zone data. By employing a dynamic and iterative construction process, we ensured the real-time nature of the root zone data. Furthermore, we used DNSSEC verification mechanisms to address the untrusted transmission paths for root zone data obtained through active probing, thereby ensuring the integrity of the root zone data. Based on a data analysis of the construction process, it is found that the main reason for the root zone file needing to be more accurate and trustworthy is the failure to update and synchronize it to the latest version in time. Additionally, it is found that there are redundancy KSK keys in the root zone data of some sources, which led to DNSSEC validation chain failures. The analysis results show that the high-trust root zone file construction model proposed in this paper can effectively filter out untrustworthy data, which verifies the model’s effectiveness.

In this paper, in the process of validation with weighted voting, the weight value of each source needs to be calculated based on the results of the previous round. It brings the problem that if a source with a large weight value is continuously compromised in the subsequent rounds, then its weight value will not immediately decrease down, but gradually decrease as the number of construction rounds increases. This can affect the accuracy of our constructed data. This is a problem we need to solve later. In addition, when obtaining root zone files maintained by different root server instances through active probing, the spatial range and quantity of measurement points are limited, which results in the inability to reflect the current status of all root-maintained root zone files. This is an important area for further research that we need to supplement in the future.