A Cross-Chain Solution to Connect Multiple DNS Blockchains in Consensus Roots System

Abstract

The Domain Name System (DNS) is a key part of the Internet, and it is used for global domain name resolution. However, it has security risks due to its centralized or semi-centralized design and reliance on a few root servers. To improve DNS security and long-term stability, this study proposes the consensus roots system, a blockchain-based distributed domain architecture. The system uses a 1 + N master-subchain structure to solve the problem of trust and data synchronization across blockchains. The master chain acts as a relay and uses Hyperledger Fabric, a consortium blockchain platform, to support semi-centralized cross-chain communication. Subchains are local blockchains that need to connect with the master chain. To ensure safe and reliable transactions, the system uses a staged-proposal atomic swap method on the master chain. Compared to prior approaches, this work introduces a cross-chain architecture that enables more efficient trust synchronization, reducing latency and improving scalability without compromising security.

1. Introduction

With the Internet’s widespread adoption, it has become integral to people’s lives, serving as the primary platform for information exchange, entertainment, and business. In this digital era, the Domain Name System (DNS) has emerged as the primary means of connecting to the network [1], simplifying access. DNS facilitates the conversion of domain names to corresponding IP addresses, a crucial element in internet communication. However, traditional DNS resolution relies on a centralized system, where a single governing authority manages operations [2]. This centralized approach presents security risks, as a breach could disrupt the entire network, posing significant societal threats. Hence, recent efforts have explored decentralized DNS resolution methods to enhance network security and reliability. On 1 October 2016, the National Telecommunications and Information Administration (NTIA), a subsidiary of the US Department of Commerce, decided to transfer the management authority of the domain name resolution system DNS to the non-profit organization ICANN (Internet Corporation for Assigned Names and Numbers) [3]. This decision is an important milestone in the history of Internet development, marking that the Internet had officially entered the era of global governance, which means paying more attention to DNS security and sharing issues. In the past, the management authority of DNS was always owned by the US government, but this centralized management mode posed risks. For example, the US government may interfere with the Internet improperly for its own interests or the DNS system may be attacked, resulting in abnormal operation of the entire Internet. Therefore, transferring the management authority of DNS to ICANN can reduce the risks of a single management authority, and it can also protect the security and fairness of the global Internet.

Blockchain, known for its secure distributed storage, addresses the centralized authority issues in DNS [4,5]. Recent years have witnessed increased blockchain-based DNS proposals, aimed at either augmenting or replacing the centralized DNS while enhancing efficiency [6]. For instance, researchers from the City University of Macau and Guangzhou University introduced a decentralized consensus roots system, comprising global domain name root servers [7]. Using blockchain, this system ensures decentralized governance, and each region maintains an open “local consensus system”. This forms a “Federated roots” system, enabling synchronous external domain name resolution among regions, even during Top-Level Domain (TLD) service interruptions, thus mitigating centralized internet risks.

As shown in Figure 1, the consensus roots system based on blockchain faces many challenges. Different regions may use different types and versions of blockchains, which makes data exchange and interoperability difficult. Also, using one blockchain for domain name information sharing can affect system efficiency due to the slow transaction processing and the need for verification and recording by multiple nodes. Regions with sensitive or private domain name information may not want to store all data publicly on the same blockchain. A blockchain-based consensus roots system across multiple regions needs solutions for improving interoperability, for ensuring equal governance among different blockchains, and for optimizing system efficiency and performance. These goals are hard to achieve.

To address the interconnection challenge in the consensus roots system, this study proposes a 1 + N cross-chain architecture that enables interoperability and synchronization among heterogeneous blockchains across different regions. The proposed scheme establishes a decentralized, tamper-resistant DNS resolution mechanism using cross-chain technology, ensuring fairness and security in domain name data sharing. By synchronizing only essential cross-chain information rather than all data, the approach enhances system scalability and mitigates the performance limitations of single-chain solutions. The main contributions of this work are summarized as follows:

1.

A 1 + N structure cross-chain scheme for efficient and trustworthy synchronization of the domain name information in the consensus roots system.

2.

A simple atomic swap transaction mechanism to support autonomous participation in the cross-chain system and to protect sensitive participant data.

This paper is organized as follows: Section 2 introduces blockchain-based DNS and cross-chain technologies; Section 3 outlines the cross-chain system scheme, including the principle and phase transactions method; Section 4 builds the cross-chain system and details the related algorithms; Section 5 analyses the security of the framework; Section 6 evaluates the system performance and security through experiments; Section 7 discusses existing works and challenges; and Section 8 concludes and details future prospects.

2. Related Work

2.1. Blockchain-Based DNS

Blockchain technology is a distributed ledger technology that has features such as decentralization, immutability, distributed storage, anonymity, transparency, and smart contracts [8,9]. Blockchain technology has many applications in fields like finance, electronic contracts, intellectual property, etc. The most popular application of blockchain is cryptocurrency, and Bitcoin and Ethereum are the most famous cryptocurrency applications. Bitcoin is a decentralized cryptocurrency that uses proof-of-work as its consensus mechanism, it has a limited supply, and it delivers anonymity and stability [10]. Ethereum is an open-source blockchain platform that also uses proof-of-work as its consensus mechanism, but it is changing it to a proof-of-stake mechanism instead. Ethereum introduces smart contract technology that allows developers to create and run distributed applications [11].

Blockchain technology has features like decentralization, immutability, distributed storage, anonymity, transparency, and automation, and it has applications in fields like cryptocurrency, supply chain management, smart contracts, identity verification, healthcare, and energy trading. DNS blockchain technology, a notable application, stores domain name resolution records on the blockchain for decentralized management, improving domain name resolution’s speed and security. Some projects in this domain are Namecoin [12] and Blockstack [13]. Namecoin, a blockchain-based cryptocurrency, uses distributed technology to manage domain name information, achieving DNS decentralization. Blockstack, a decentralized naming and storage system on the Bitcoin blockchain, enables global unique name registration for applications, data, and identities. It also offers decentralized identity authentication and file storage, aiming for a decentralized ecosystem to replace the Internet. Cross-chain technology solves interoperability challenges between different blockchains, enabling data exchange and asset transfer, including in the DNS blockchain sector, where it synchronizes and coordinates DNS domain names across various blockchains.

Recent studies have further advanced the integration of blockchain into DNS. Li et al. proposed the DiSAuth framework, which combines DNS and blockchain to enforce access control in data-decoupled scenarios, offering verifiability, tamper resistance, and privacy protection [14]. Compared to traditional solutions, it improves verification efficiency by approximately three orders of magnitude. Divakarla and Chandrasekaran developed the D-DNS system, introducing a domain index and a PoS consensus mechanism to enhance query efficiency and significantly reduce attack success rates [15]. Additionally, Samonte et al. explored the feasibility of integrating blockchain with AI and honeypot technologies to enhance DNS security, concluding that blockchain can significantly improve both the security and privacy of DNS systems [16].

2.2. Cross-Chain

Cross-chain technology enables interactions between different blockchain systems, solving interoperability challenges and creating opportunities for development [17]. It has applications in sectors like finance, IoT, and supply chain management. In finance, it enhances asset liquidity and innovation, while, in IoT, it improves system efficiency and security. In supply chain management, it boosts logistics and traceability. This technology allows for smooth digital asset transfer between blockchains, increasing convenience and efficiency. Cross-chain establishes trusted communication and information sharing, solving “data silos”. Notable methods include notary mechanisms, sidechains, and hash time locks. The traditional notary mechanism uses a trusted third party between blockchains, like Ripple’s Interledger Protocol [18], but it also raises centralization concerns. Sidechains increase Bitcoin’s throughput, supporting bidirectional pegged sidechains. They often use Simplified Payment Verification (SPV) for transaction confirmation, reducing data transfer burdens [19]. Relay chains combine sidechain and notary mechanisms. Cosmos, for example, uses Tendermint and IBC for cross-chain transactions. It connects various blockchains for trusted data transfer. Hash Time Locked Contracts (HTLCs) enable asset swaps between blockchains using hash locks and time locks [20]. They secure transactions and ensure timely completion. In short, cross-chain technology solves blockchain interoperability challenges, offering various solutions through notary mechanisms, sidechains, relay mechanisms, and HTLC. It can revolutionize finance, IoT, and supply chain management by improving efficiency, security, and interoperability. Recent works have proposed a cross-and-off-blockchain micropayment channel, a trust-model-based consensus committee method, and a modular token transfer framework [21,22,23], collectively focusing on reducing on-chain transactions, strengthening security coordination, and improving the interoperability and latency in cross-chain blockchain networks.

2.3. Atomic Swap

Atomic swaps, enabled by smart contracts, allow peer-to-peer cryptocurrency exchanges without centralized exchanges [24,25]. This innovation eliminates intermediaries, enhancing cryptocurrency usage. In atomic swaps, smart contracts ensure proper cryptocurrency distribution upon transaction fulfillment. The atomic swap protocol, conceived in 2013 by Tier Nolan, uses hash functions for secure, keyless transactions. The hash time lock method, which requires one implementation, creates a hash lock by hashing a random string with users’ cryptocurrency addresses. Transactions remain unsigned and the blockchain unrecognized until one party validates the hash lock through the hash function and then signs and broadcasts the transaction. While the atomic swap protocol leverages smart contracts and hash functions for decentralized cryptocurrency transactions, ongoing development efforts seek to enhance security, resilience, and adaptability to various scenarios.

3. System Model

This study aims to find a solution for the cross-chain interaction between heterogeneous DNS blockchain systems. Suppose Region A and Region B have different DNS blockchain systems. This paper proposes a scheme to build a relay platform between them, as well as a consensus roots system for Region A and Region B to support cross-chain interaction. This way, different regional DNS blockchain systems can communicate and coordinate, achieving more efficient and secure domain name resolution.

Our proposed scheme uses a master-subchain 1 + N structure design. As shown in Figure 2, it consists of a master chain, subchains, and an atomic swap transaction. The master chain is a decentralized consortium blockchain based on relay chain technology, which acts as a relay platform, supports homogeneous and heterogeneous chain access, and verifies cross-chain transaction data. The subchains are DNS blockchains that need cross-chain interaction, and they form an efficient and secure cross-chain structure with the master chain. The atomic swap transaction ensures the atomicity of cross-chain data transmission. The master chain design can improve the system efficiency and security. The scheme can also provide the technical support for building a consensus roots system for Region A and Region B. The specific parts are as follows.

3.1. Master Chain

The master chain uses consortium blockchain, which is a blockchain technology for data and value sharing and exchange among limited organizations or participants. Consortium blockchain is decentralized, but only authorized participants can join the network, verify transactions, and maintain the ledger, ensuring legitimacy and security. The main reason for using consortium blockchain on the master chain is to achieve decentralized cross-chain data interaction so that multiple blockchains can exchange data and value without relying on centralized third-party institutions. Consortium blockchain can provide an efficient, controllable, and secure solution for cross-chain interaction, achieving more flexible and convenient value transfer. Consortium blockchain can also make specific rules and policies according to different needs in order to meet various interaction requirements in different scenarios. Using consortium blockchain on the master chain provides a secure, efficient, and controllable solution for cross-chain data interaction. This technology can improve the interaction efficiency, enhance the interaction security, and provide customized solutions for different needs.

3.2. Subchain

Subchain is a blockchain structure that needs cross-chain interaction, which can include similar or different blockchains. Subchain can access the master chain to achieve trustworthy cross-chain interaction. The smart contracts on the master chain can communicate with the subchain through the cross-chain protocol to enable the data and value interoperability between them. Using a subchain structure can connect and interoperate different blockchains, and it can also expand the blockchain applications and functions. In cross-chain interaction, security and reliability are very important, so subchain access must be secure and authorized. Subchain can connect and interoperate different blockchains, and it can promote the blockchain application and development. Subchain can improve the interoperability and applicability of blockchain technology, and it can create more blockchain application scenarios.

3.3. Atomic Deal

The cross-chain system heavily relies on atomic swap transactions for secure cross-chain data interactions on the master chain. This process simplifies the asset transactions between different blockchains. It involves an atomic data interaction process to cater to various subchain needs, requiring participants to meet specific cross-chain requirements for successful interactions.

Unlike traditional hash time lock technology, we employed a two-phase transaction approach for the atomic swap protocol. This method guarantees that all resource operations are either successfully committed or rolled back, preventing system-disrupting transaction failures. The two phases are as follows.

1.

Preparation Phase: Participants initiate transactions and await coordinator responses.

2.

Commit/Rollback Phase: Coordinators request commit or rollback from participants and await their responses. Successful responses result in final commits, while failures trigger rollbacks.

In our system, we implement part of the atomic swap protocol on the master chain, breaking down the process into four phases. This follows the two-phase transaction model, ensuring reliable and secure cross-chain transactions.

1.

Negotiation phase: The parties find each other through the relay platform and draft an exchange agreement. The agreement confirms the transaction content. Each party decides whether to join and finish the transaction by its own will.

2.

Transaction phase: The parties entrust their transaction content to the relay platform according to the agreement. The platform verifies and records the transaction content on the master chain.

3.

Verification phase: The parties check whether the entrusted transaction content matches the agreement. They decide whether to continue or stop the transaction by their own will.

4.

Commitment phase: The parties confirm that the transaction is completed and send confirmation to the relay platform. The platform records this cross-chain transaction as a security endorsement.

These four phases are the basic atomic swap process designed by this cross-chain system. But, under application scenario limitations, the transaction phase and verification phase may need some changes. Since the application scenario here is DNS domain name data cross-chain sharing, the parties in the consensus roots system are assumed to be mutually trusted. As such, the atomic swap process here needs to consider situations where parties may have sensitive domain name information and domain names that cannot be exchanged. To meet these limitations, the transaction phase and verification phase need some adjustments. For example, in the negotiation phase, cross-chain content can be prepared in advance, and parties can see the content and then decide whether to join the cross-chain interaction or not. In general, to fit different application scenarios, the atomic swap protocol can be customized to some extent to make sure it can better adapt to specific needs.

4. Construction of Our System

4.1. Proposed System

This system uses a 1 + N main-subchain cross-chain architecture. The relay platform is the core component of the system. It connects blockchains with cross-chain needs as subchains, and it handles multiple tasks in the cross-chain process. The system also uses a staged transaction atomic exchange protocol, which is deployed on the relay chain. In this model, smart contracts implement the process of staged transaction atomic exchange. This architecture can enable multiple heterogeneous blockchains to cooperate and realize cross-chain transactions, while the relay platform acts as a reliable intermediary, which can improve the security and reliability of transactions. This allows different regional DNS blockchains to interoperate and connect. The cross-chain solution designed in this paper has many details, such as blockchain node identity authentication, cross-chain message transmission and processing, smart contract execution, etc. These details form a complete cross-chain solution. Figure 3 and Figure 4 show the cross-chain solution’s overall architecture and the atomic exchange transaction in the cross-chain interaction process, respectively.

Assuming that the DNS blockchain of Region A wants to synchronize a domain name information with the DNS blockchain of Region B, then this example illustrates the more detailed cross-chain synchronization domain name process of the cross-chain system. The complete cross-chain process of this scheme is as follows.

1.

The A subchain submits a cross-chain request to the main chain, asking to synchronize DNS records with the B subchain. It includes its own identity, the B subchain’s identity, and the target domain name, and it then forwards this information to the A verification node. The A verification node first confirms that the A subchain is registered in the consensus root system.

2.

Upon successful validation, the A verification node relays the cross-chain request to the B verification node on the main chain, carrying the same identity and domain name data.

3.

The B verification node authenticates the request origin via the relay platform and then forwards it to the B subchain for processing.

4.

The B subchain evaluates the request and decides whether to assist with DNS resolution. If it agrees, it returns the resolved record along with its identity to the B verification node; if not, it sends a rejection message, which the B verification node relays back to the A subchain. This exchange constitutes the negotiation phase of a simple atomic-swap protocol.

5.

The B verification node verifies that the response originates from the B subchain and forwards the result to the A verification node on the main chain.

6.

The A verification node authenticates the response source and delivers it to the A subchain.

7.

The A subchain checks that the response matches its original request and the intended transaction parameters, thereby completing both the transaction and verification phases of the atomic-swap protocol. It then sends a completion confirmation to the A verification node.

8.

The main chain generates a cross-chain transaction proof, recording the two blockchain identifiers, the synchronized DNS data, and the timestamp of completion. This proof is immutably stored on-chain, marking the end of the DNS synchronization process.

To ensure valid cross-chain information, the verification nodes utilize consortium blockchain identity authentication. In domain name cross-chain synchronization, the main chain employs Hyperledger Fabric’s channel mechanism [26] for secure communication and faster verification, enhancing efficiency. This approach integrates cross-chain processes into the consortium blockchain, improving security and reliability. It also introduces phased atomic exchange transactions for DNS domain name synchronization, offering a flexible and secure choice for the consensus roots system. Compared to mainstream relay platform cross-chain schemes, this approach streamlines identity authentication and verification, leveraging consortium blockchain features for improved efficiency, security, and reliability in the consensus roots system.

4.2. Contract Detail

This system aims to achieve cross-chain synchronization of the domain name information between the A blockchain and B blockchain. This involves multiple factors, such as cross-chain achievement, cross-chain intention, cross-chain verification, and cross-chain preservation. The details of this system are as follows, where

Table 1. Notation.

Notation	Description
A	Represents Chain A in the blockchain network
B	Represents Chain B in the blockchain network
domain	The domain name to be synchronized between chains
res	The resolved state of the domain after processing
$req$	The request sent from Chain A to Chain B or vice versa
$fb$	Feedback sent from Chain B to Chain A or vice versa
$tx$	Transaction object that holds domain-related data
$result$	The result of the transaction
time	The timestamp when the transaction occurs

shows the introductions of various factors of the contract details.

4.3. Cross-Chain Domain Name Synchronization

We propose Algorithm 1, which is designed to facilitate the cross-chain domain name synchronization between the two distinct blockchains (referred to as the source chain (chainA) and the target chain (chainB)). The algorithm aims to streamline the transfer and updating of the domain name information across these chains, involving a sequence of meticulously structured steps:

1.

Initiation by Source Chain: chainA starts the process by sending a synchronization request to chainB. The request contains the IDs of both chains and the domain name information (domain.info).

2.

Initial Request Validation by Relay Node: A relay node obtains the request and validates its legitimacy. If it is valid, the process continues; otherwise, the request is rejected, and chainA is notified.

3.

Request Forwarding and Validation by Target Chain: If the validation is successful, the relay node sends the request to chainB. Then, chainB validates the request according to its own rules and protocols.

4.

Processing and Feedback by Target Chain: After validation, chainB performs the operations related to the domain name information. Then, chainB sends feedback, with its ID and either the result of the domain name operation (domain.result) or the rejection reason, to chainA.

5.

Feedback Forwarding and Validation by Source Chain: The relay node forwards the feedback to chainA, which also validates the feedback to check its authenticity.

6.

Confirmation by Source Chain: If the feedback is valid, chainA sends a confirmation message, with its ID and marking the synchronization status as either “completed” or “failed” based on the feedback, to chainB.

7.

Proof Generation by Relay Node: The relay node generates a proof message (proof) that contains the IDs of both chains and the results of the domain name operation. This proof is an immutable record, providing evidence for the process and its outcome.

Algorithm 1 Cross-chain domain name synchronization

1: procedure Sync($A.ID,B.ID,domain.info$) 2:     $A.send.req(A.ID,B.ID,domain.info)$ 3:     $relay.verify.req(A.ID,B.ID,domain.info)$ 4:     if $req.valid$ then 5:         $relay.forward.req(A.ID,B.ID,domain.info)$ 6:         $B.receive.req(A.ID,B.ID,domain.info)$ 7:         $B.verify.req(A.ID,B.ID,domain.info)$ 8:         if $req.valid$ then 9:            $B.send.fb(B.ID,domain.result)$ 10:         else 11:            $B.send.fb(B.ID,“rejected”)$ 12:         end if 13:         $relay.forward.fb(B.ID,domain.result)$ 14:         $A.receive.fb(B.ID,domain.result)$ 15:         $A.verify.fb(B.ID,domain.result)$ 16:         if $fb.valid$ then 17:            $A.send.confirm(A.ID,“completed”)$ 18:         else 19:            $A.send.confirm(A.ID,“failed”)$ 20:         end if 21:         $relay.generate.proof(A.ID,B.ID,domain.result)$ 22:     else 23:         $relay.reject.req(A.ID,B.ID,domain.info)$ 24:     end if 25: end procedure

4.4. Atomic Deal

In the realm of cross-chain transactions, the “Atomic Deal” algorithm, denoted as Algorithm 2, elucidates a robust four-phase methodology for executing atomic swaps between two distinct blockchains: chainA and chainB. This algorithm serves as an augmentation to the preliminary algorithm, focusing on domain name synchronization (Algorithm 1).

Algorithm 2 Atomic deal

1: procedure Deal($A.ID,B.ID,domain.info$) 2:     $tx\leftarrow create.tx(A.ID,B.ID,domain.info)$ 3:     $relay.send.tx\left(tx\right)$ 4:     if is.valid(domain.info) then 5:         $target.ID\leftarrow B.ID$ 6:     else 7:         $result\leftarrow$ “failed” 8:         end 9:     end if 10:     $relay.forward.tx(tx,target.ID)$ 11:     if is.valid(domain.info) then 12:         $domain.res\leftarrow resolve(domain.info)$ 13:         $tx\leftarrow create.tx(domain.res,B.ID,A.ID)$ 14:         $relay.send.tx\left(tx\right)$ 15:         $relay.forward.tx(tx,A.ID)$ 16:         if is.valid.response(tx, domain.res, B.ID) then 17:            $result\leftarrow$ “successful” 18:         else 19:            $result\leftarrow$ “failed” 20:         end if 21:     else 22:         $result\leftarrow$ “failed” 23:     end if 24:     if $result$ = “$successful$” then 25:         info =    “A”: A,    “B”: B,    “domain”: domain,    “res”: res,    “tx”: tx,    “time”: time() 26:         storage.save(info) 27:     end if 28: end procedure

4.4.1. Negotiation Phase

At the start of the negotiation phase, chainA (the initiator) sends a transaction packet, $tx$, to the relay platform. The packet has chainA’s identifier ($A.ID$), chainB’s identifier ($B.ID$), and the domain name data (domain.info). The relay platform checks the validity of domain.info to find chainB as the recipient. It forwards the packet to chainB using $\mathrm{relay}.\mathrm{forward}.\mathrm{tx}(tx,\mathrm{target}.\mathrm{ID})$.

The establishment of this preliminary phase augments the security infrastructure while offering flexibility, thereby contributing to the holistic trustworthiness of the cross-chain interaction.

4.4.2. Transaction and Verification Phase

After successful negotiation, the transaction and verification phases begin. Then, chainB uses $\mathrm{resolve}\left(\mathrm{domain}.\mathrm{info}\right)$ to convert the domain name information into its IP address. It creates and sends a transaction packet, with this IP address (domain.res), to the Relay Platform.

The relay platform receives the transaction and forwards it to chainA. Then, chainA verifies its authenticity using $\mathrm{is}.\mathrm{valid}.\mathrm{response}(tx,\mathrm{domain}.\mathrm{res},B.ID)$. This dual-phase approach ensures the atomicity of the transaction, requiring a successful negotiation phase before further action.

4.4.3. Submission Phase

When the transaction status is flagged as “successful,” chainA assembles a data packet that includes key transactional metadata and submits it to a secure storage using $\mathrm{storage}.\mathrm{save}\left(info\right)$. This metadata comprises the following:

• Identifiers for chainA and chainB ($A.ID$, $B.ID$).
• Initial domain name (domain).
• Resolved IP address (res).
• Transaction packet (tx).
• Completion timestamp (time()).

4.4.4. Security Endorsement

The relay platform creates a security backup with all the relevant transactional data. This backup is an immutable audit trail, offering traceability and security. Participants can access the transactional information using a backup information number ID. It serves as an example framework for secure and atomic cross-chain deals between different blockchains.

5. Security Analysis

The consensus roots system is designed to foster global Internet sharing, DNS domain name resolution, and the resolution of authority issues. It operates on the assumption that all participants are partially trusted, meaning they will not falsify the shared domain name resolution information. The system’s cross-chain platform ensures all cross-chain participants are authorized, thus eliminating the need to consider security threats from malicious nodes or cross-chain participants.

Incorporating the Hyperledger Fabric-permissioned consortium blockchain, the system’s main chain relay platform verifies the trustworthiness of cross-chain nodes using the CA certificate mechanism. Given the system’s consortium chain features, it can bypass more verification processes in the cross-chain interaction than conventional cross-chain systems. However, the access and information transmission of the sub-chains still require stringent verification.

One key aspect of this system is the implementation of privacy domain name protection through staged atomic exchange in the DNS domain name synchronization process. This is conducted prior to the cross-chain interaction on the main chain relay platform, where the system executes a negotiation phase. During this stage, the cross-chain sub-chains decide whether to continue with cross-chain domain name synchronization based on the negotiation content. This staged cross-chain process not only ensures the autonomous choice interaction of multiple parties, but it also avoids transactions that do not align with the participants’ wishes, thereby enhancing the system’s security. The data involved in the cross-chain process are safeguarded by blockchain, making them tamper-proof. The transaction detail information is endorsed and stored on the main chain relay platform, allowing system participants to query and verify as required.

5.1. Security Proof

5.1.1. Security Properties and Proofs

Definition 1

(Immutability Game). Let $\mathcal{A}$ be a probabilistic polynomial-time (PPT) adversary against the main chain’s immutability. The game proceeds as follows:

1.

The challenger $\mathcal{C}$ initializes the main chain relay platform.

2.

$\mathcal{A}$ submits a transaction $T_x$ to $\mathcal{C}$.

3.

$\mathcal{C}$ generates block $B_i=(H_{i-1},$ 𝘛𝘟𝘴, ${\sigma }_{\mathit{consensus}})$.

4.

$\mathcal{A}$ outputs an altered block $B_i^{\prime }\ne B_i$ such that $H\left(B_i^{\prime }\right)=H\left(B_i\right)$.

$\mathcal{A}$ wins if $B_i^{\prime }$ is accepted by honest nodes.

Theorem 1

(Data Immutability). The main chain provides immutable storage for DNS resolution data under cryptographic hardness assumptions.

Proof. 

The adversary’s advantage is bounded by the following:

$$\underset{\mathcal{A}}{\overset{\mathrm{immut}}{Adv}}\left(\lambda \right)=Pr\left[\mathcal{A}\mathrm{wins}\right]\le \mathsf{negl}\left(\lambda \right).$$

(1)

This holds because $\mathcal{A}$ must either

• Forge the consensus signature ${\sigma }_{\mathrm{consensus}}$, violating the EU-CMA security of the signature scheme; or
• Find a hash collision $H\left(B_i^{\prime }\right)=H\left(B_i\right)$, violating the collision resistance of the hash function.

□

5.1.2. Privacy-Preserving Negotiation

Definition 2

(Atomic Exchange Ideal Functionality). The ideal functionality ${\mathcal{F}}_{\mathrm{atomic}}$ receives encrypted inputs $\left(𝘦𝘯𝘤\left(D_A\right),𝘦𝘯𝘤\left(D_B\right)\right)$ and reveals $(D_A,D_B)$ only upon receiving mutual agreement signatures from both parties.

Theorem 2

(UC-Secure Atomic Exchange). The staged atomic exchange protocol ${\mathsf{\Pi }}_{\mathrm{atomic}}$ UC realizes the ideal functionality ${\mathcal{F}}_{\mathrm{atomic}}$ against semi-honest adversaries.

Proof. 

Construct a simulator $\mathcal{S}$ such that for all PPT environments $\mathcal{E}$, we have the following:

$$\left|Pr\left[\mathcal{E}\mathrm{outputs}1\mathrm{in}{\mathsf{IDEAL}}_{{\mathcal{F}}_{\mathrm{atomic}},\mathcal{S}}\right]-Pr\left[\mathcal{E}\mathrm{outputs}1\mathrm{in}{\mathsf{HYBRID}}_{{\mathsf{\Pi }}_{\mathrm{atomic}}}\right]\right|\le \mathsf{negl}\left(\lambda \right).$$

The simulator $\mathcal{S}$ achieves this by performing the following:

• Simulating commitments as $\mathrm{Com}(0^{\lambda };r)$ to preserve the hiding property.
• Extracting inputs only after receiving valid $\mathtt{agree}$ signatures, ensuring the binding property.

□

5.1.3. Node Authorization

Definition 3

(Authorization Game). An adversary $\mathcal{A}$ without CA credentials attempts to inject a transaction $T_{\mathrm{mal}}$ with a forged certificate ${\mathrm{cert}}_{\mathrm{mal}}$.

Theorem 3

(CA Authorization Security). Let ${\mathcal{N}}_{\mathrm{CA}}$ denote the set of CA-authorized nodes. Then, only nodes $n\in {\mathcal{N}}_{\mathrm{CA}}$ can influence cross-chain transactions.

Proof. 

The adversary $\mathcal{A}$ succeeds only if

$$\mathrm{Verify}({\mathsf{pk}}_{\mathrm{node}},T_{\mathrm{mal}},{\sigma }_{\mathrm{node}})=1\wedge \mathrm{Verify}({\mathsf{pk}}_{\mathrm{CA}},{\mathrm{cert}}_{\mathrm{mal}},{\sigma }_{\mathrm{CA}})=1.$$

(2)

Since $\mathcal{A}$ lacks ${\mathsf{sk}}_{\mathrm{CA}}$ and ${\mathsf{sk}}_{\mathrm{node}}$, we have

$$Pr\left[\mathcal{A}\mathrm{wins}\right]=\mathsf{negl}\left(\lambda \right)$$

(3)

by the EU-CMA security of the signature scheme. □

6. Experimental Evaluation

6.1. Experiment Environment

To simulate different regions of the consensus roots system, the sub-chains and the main chain relay platform of the cross-chain experimental platform are built on different virtual machines. The physical machines had a 64-bit win10 system, 11th Gen Intel^® Core™ i7-11800H @ 2.30 GHz CPU, 48G RAM, and a 1 TB hard disk. The virtual machines had an Ubuntu 20.04.3 LTS system, 4 GB RAM, two processors, and a 20 GB hard disk. The cross-chain experimental platform also had another sub-chain, which was built on a remote server. The simulation environment we used was Hyperledger Fabric 2.0, and the smart contract programming language was go language.

6.2. Evaluation

Transaction delay and transaction throughput are two key indicators in blockchain systems, so these two aspects need special attention when evaluating experimental performance. Transaction delay refers to the time interval from initiating a transaction on the blockchain to confirming the transaction as valid, which directly affects the confirmation speed of the transaction and the time efficiency of the entire cross-chain process. Transaction throughput refers to the total number of transactions that the blockchain system can handle in each unit of time, which is the total load of the blockchain system. To evaluate the performance of this cross-chain system, the system tests and evaluates indicators, such as the transaction delay, throughput, memory, and CPU consumption of the blockchain system on Hyperledger Caliper.

Figure 5a,b show the relationship between the CPU usage and memory consumption and the transaction arrival rate (TPS) for different numbers of verification nodes (2, 4, and 6) in the relay platform of the system. As can be seen from Figure 5a, the CPU usage increased with the increase in the transaction arrival rate (TPS), which indicates that the system load also increases. Figure 5b also shows that the memory consumption (MB) increases with the increase in the transaction arrival rate (TPS), which indicates that the system resource consumption also increases. For the same TPS, the greater the verification nodes, the higher the CPU usage and memory consumption, which indicates that the number of verification nodes has an impact on the system performance, but not in a linear relationship. When the number of verification nodes increases to a certain extent, the system performance and resource consumption tend to stabilize or decline.

Due to the involvement of multi-chain interaction and complex protocols, a cross-chain solution exhibits higher CPU and memory usage than existing DNS methods, making it more suitable for scenarios with strong cross-chain interoperability requirements—particularly in addressing the risk of non-top-level domain (non-TLD) resolution nodes being blocked due to the centralized architecture of traditional DNS. Existing DNS methods demonstrate lower resource consumption in single-chain or single-network environments, making them ideal for scenarios prioritizing stability and lightweight operation, such as enterprise intranets and Kubernetes clusters. In the future, with the standardization of cross-chain technologies and improvements in hardware performance, the resource efficiency of cross-chain DNS solution is expected to gradually approach that of existing solutions.

We tested the relay chain network with different numbers of nodes and TPS. The results are shown in Figure 6a,b. Figure 6a shows that the average delay was not affected by the number of nodes when the TPS was low, but it increased for six nodes when the TPS was high. This means that more nodes cause more congestion when there are many transactions. Figure 6b shows that the average throughput increased with the TPS, but it was lower for six nodes than for two or four nodes. This means that more nodes cause more overhead and inefficiency in data transmission and verification. Therefore, we conclude that the relay platform was stable in delay performance but not in throughput performance. We suggest to reduce the number of verification nodes in cross-chain applications to optimize the network efficiency.

6.3. Rationale Behind the DNS Simulation Design

To evaluate the core functionalities and performance of the proposed consensus roots system, our current experimental setup models a single DNS domain with one node per sub-chain. This simplified configuration allows us to focus on key aspects, such as cross-chain synchronization, relay coordination, and transaction efficiency, without introducing extraneous network complexity. Such an approach is consistent with prior research on DNS security frameworks, including DNSSEC [27], HARD-DNS [28], and DepenDNS [29], which also adopt simplified testbeds or emulated zones to isolate and evaluate protocol-level behaviors before scaling to full DNS hierarchies. Furthermore, studies such as [30] use a representative subset of DNS zones and nodes to evaluate latency and resilience, acknowledging that full-scale global DNS replication is impractical for prototype validation. Several studies have demonstrated the rationale for using a single DNS domain setup. The D³NS scheme emphasizes that verifying DHT routing efficiency within a single domain is essential before optimizing distributed DNS structures [31]. FI-DNS limits its initial experiments to replica differences within a single domain to simplify the scenario and validate its core mechanism [32]. The master–slave chain scheme also treats single-domain resolution as the foundation for multi-domain expansion [33]. These works show that configuring a single DNS domain is a necessary prerequisite for more complex system designs.

7. Discussion

7.1. Comparative Benchmarks Against Existing DNS Solutions

Prior studies have addressed DNS security and availability from various perspectives. DNSSEC enhances data authenticity via cryptographic signing [27], while HARD-DNS improves fault tolerance through redundant distribution [28]. DepenDNS focuses on reliability by modeling server dependencies [29], and an adaptive scheme has been proposed to defend against cache poisoning attacks [34]. While these approaches improve specific aspects, they often face trade-offs in scalability, efficiency, or coordination—issues our cross-chain synchronization scheme is designed to overcome. The benchmark reference from TI-DNS [30] was used to approximate performance ranges under similar conditions. As shown in

Table 2. Comparison of the DNS resolution latency (ms) under varying query sending rates.

Query Sending Rate (TPS)	ODD	DNSSEC	HARD-DNS	DepenDNS	Our Solution
40	535	530	570	620	460
80	540	555	615	715	516
120	555	605	645	890	572
160	560	600	790	950	628

, our proposed solution achieves consistently lower DNS resolution latency across all tested query sending rates when compared with existing approaches, such as ODD, DNSSEC, HARD-DNS, and DepenDNS. At 40 TPS, our solution demonstrated a latency of only 460 ms, which was 13.1% lower than the best baseline (DNSSEC, 530 ms). As the load increased, our approach maintained a steady performance advantage: at 160 TPS, it recorded 628 ms compared to the 950 ms for DepenDNS and 790 ms for HARD-DNS—improvements of 33.9% and 20.4%, respectively.

This efficiency stems from our cross-chain architecture, which optimizes trust synchronization between regional root servers via a master–subchain model, reducing inter-domain communication delays. The staged atomic swap mechanism enables efficient and secure transaction coordination without introducing the heavy cryptographic overhead observed in DNSSEC or the resource duplication in HARD-DNS.

7.2. Compliance Challenges of Cross-Chain DNS in Multi-Jurisdictional Environments

Deploying cross-chain DNS systems across jurisdictions introduces major challenges related to data sovereignty and privacy compliance. Regulations differ widely in how countries control internet infrastructure and handle cross-border data flows. For example, the EU’s GDPR requires lawful grounds for data processing and restricts international data transfers. In some regions, outbound DNS data are completely banned, making decentralized designs harder to implement. Privacy laws also vary, requiring flexible methods for query anonymization and secure data handling. In addition, differences in blockchain regulation may affect where nodes can be deployed and whether smart contracts are legally recognized.

7.3. Decentralization Challenges in Consortium-Based Blockchain DNS

While the proposed architecture aims to enhance decentralization, the introduction of a main chain for coordination raises potential centralization concerns. This mirrors observations from systems like Ethereum Name Service, where significant portions of the infrastructure are hosted by a few dominant cloud providers. To mitigate such risks, our consortium blockchain design leverages distributed governance across multiple trusted stakeholders, each maintaining independent control over their Fabric peers and chaincode. Unlike public chains, where economic incentives may concentrate influence, our approach ensures policy diversity through governance voting mechanisms, cross-organizational endorsement policies, and geographically distributed node deployment. Nonetheless, we acknowledge that consortium blockchains may still centralize decision making at the governance layer. Future work will explore integrating decentralized governance protocols and dynamic membership models to further reduce reliance on any single coordinating entity.

8. Conclusions

This study proposes a cross-chain DNS root synchronization scheme. The goal was to solve trust and interoperability problems among heterogeneous blockchains in the consensus roots system. The system adopts a 1 + N master-subchain architecture. The master chain works as a relay. Each subchain corresponds to a regional root server. This design improves flexibility, scalability, and security. A staged atomic swap mechanism guarantees secure and independent participation. It also enables collaborative governance among root nodes. The system provides a practical blockchain-based solution for DNS infrastructure. It helps decentralize and strengthen global Internet governance. The current design assumes that root servers cooperate, but this assumption may not hold in adversarial or conflicting policy environments. Future work will aim to enhance fault tolerance in such cases. It will also explore privacy-preserving cross-chain protocols and support for hierarchical DNS models. Another key direction is to improve compatibility with existing Internet infrastructure.