The Domain Name System (DNS) is the backbone of the Internet, but remains highly centralised, creating risks related to censorship, surveillance, and single points of failure. While much of the focus has been on securing and decentralising DNS as a whole, recursive resolvers continue to rely on central infrastructure. This paper proposes a decentralised DNS resolver architecture that replaces traditional recursive resolvers with a decentralised alternative. The system uses the Chord protocol and distributed ledger technology (DLT) to distribute DNS resolution across a network of cooperating nodes, without altering existing zone authority structures. We present the key components of the architecture, including peer discovery, query routing, caching, updating and trust handling, and we analyse how this architecture overcomes the previously mentioned limitations.
The DNS is a distributed, hierarchical system responsible for mapping domain names to IP
addresses on the Internet. Despite its distributed design, much of its infrastructure relies on
centralised components, especially recursive resolvers. These resolvers handle most DNS trafic
by acting as intermediaries between clients and authoritative servers. NS1’s 2023 Global DNS
Trafic Report [
This centralisation introduces critical vulnerabilities, including single points of failure,
exposure of user queries to potential surveillance, and censorship through manipulated resolver
responses [
To address these issues, this paper proposes a decentralised DNS resolver architecture. Unlike traditional DNS resolvers that rely on centralised authorities, the proposed architecture uses a Chord DHT and distributed ledger technology (DLT) to decentralise both DNS query resolution and record updates across a network of nodes. The DHT assigns DNS records to nodes, and it handles lookup, routing, and replication, while a permissioned blockchain-based DLT ensures consistency during updates, even if some nodes are malicious. The primary objectives of this architecture are to improve availability, reduce reliance on trusted third parties, strengthen resistance to censorship and tampering and address security threats related to the DNS resolver itself. Threats originating from or targeting the DNS Root, TLD, and Authoritative Name Servers are considered out of scope. This paper outlines the system’s architecture and the mechanisms enabling secure cooperation between nodes.
The rest of the paper is structured in four sections. The background section provides the foundational context, followed by related work that highlights existing solutions. The architecture section provides a high-level overview of the proposed system, and describes the design principles and processes. Finally, the discussion section reflects on the implications of the traditional DNS architecture and explains how the proposed design overcomes those limitations.
DNS operates on a client-server model with a hierarchical and distributed protocol [
If the information is not in the cache or has expired, the resolver queries root DNS servers
[
Chord is a structured peer-to-peer (P2P) protocol for scalable, decentralized key-based lookup
in distributed systems [
A DHT is a decentralized storage system that maps keys to values and distributes this mapping across a network of nodes without requiring central coordination. In Chord, the DHT is implemented by storing key-value pairs at the node responsible for each key, as determined by the consistent hashing scheme. This enables eficient insertion, lookup, and replication of data in a fully decentralized manner.
Several studies have explored decentralised DNS approaches and their potential benefits and
limitations. Blockchain-based DNS (BDNS) is one of the most popular ones, with Namecoin [
Liu et al. [
Contrary to existing decentralised DNS solutions, that focus on modifying the traditional DNS infrastructure, this paper proposes a distinct approach by introducing an alternative architecture at the recursive resolver level. While prior systems aim to replace the root and the authoritative name servers, this architecture shifts the focus to replacing the recursive resolver with a decentralised network. By distributing resolver functionality through this network in combination with consensus-based updates, the system improves availability, censorship resistance, and trust without interfering with existing DNS hierarchies.
Our decentralised DNS resolver is designed to address the limitations of traditional centralised DNS resolution systems. The goal is to eliminate reliance on centralised recursive resolvers, which introduce privacy risks, single points of failure, and potential censorship, by distributing the resolution process across independent nodes.
As shown in Figure 2, in our model each node ∈ is placed on a Chord ring and stores a
subset ⊂ called a chunk, where is the initial global dataset of DNS records. The peers
responsible for handling the same chunk form a permissioned blockchain [
DNS records are time sensitive, meaning that entries expire based on time-to-live (TTL) values, and new records are frequently added or updated. As a result, many queries may fail if the necessary data is unavailable locally or in the relevant peer set. In this situation, when a node cannot resolve a query from local or peer stored data, it initiates the resolution process from the root servers, traversing the DNS hierarchy as needed (root → TLD → authoritative servers). This approach removes the dependency on any external recursive resolver, retains decentralisation, and guarantees completeness in query resolution.
The global dataset of DNS records is partitioned into chunks and distributed using the Chordbased DHT. Each chunk contains a subset of domain name to IP mappings (DNS records), corresponds to the -th partition where ∈ {1, 2, . . . , }, and is stored by a set of peers. A unique key = () is assigned to each chunk by applying a cryptographic hash function (e.g., SHA-1) to its content. These keys are mapped onto the Chord identifier ring. Each chunk is assigned to the first node in the ring whose identifier is equal to or greater than , known as the successor node. To improve consistency (as explained in Section 4.2), replicas of each chunk are also stored at the next successors in the ring, where 1 ≤ ≪ . This assignment ensures uniform distribution of chunks across the network, supports eficient query routing with (log ) hops, and maintains resilience to node joins and leaves. The DHT manages both the placement and retrieval of chunks in , enabling dynamic membership and reliable access to DNS data.
To join the network, a node connects to one or more known bootstrap peers [
To resolve a domain , the node applies the function ℳ, which hashes using a cryptographic hash function (e.g., SHA-1), producing the key for the corresponding chunk , so ℳ() = () = . If the node does not store the relevant , it uses the Chord DHT to locate the set of peers responsible for that chunk (lookup). The DHT enables eficient routing to the correct nodes based on the chunk’s key. The node queries these peers and collects their responses. Each response is checked for structural validity, ensuring it contains required DNS fields such as name, type, TTL, and value. Invalid or abnormal responses are discarded. From the valid responses, the node evaluates majority agreement. If a majority return matching records, the result is accepted; otherwise is rejected.
Let = {1, 2, . . . , } be the set of replies.
If ∃ such that |{ ∈ | = }| > 2
Otherwise, reject the response.
, then accept .
If the requested DNS record is not found within any chunk ( ∈/ ) stored in the network, the node initiates a fallback procedure, performing recursive resolution via the standard DNS hierarchy as explained in Section 2.1. Once the record is retrieved, the node completes the DNS request and shares the new record to be added to the network, as explained in Section 4.3.
If the record is not returned by the traditional DNS, the protocol responds with an NXDOMAIN message, indicating the non existence of the requested domain. This process ensures that any domain resolution can be traced back through the authoritative DNS chain, providing a fallback mechanism while maintaining the decentralised nature of the system.
Updating the network involves two main scenarios: updating an existing DNS record due to expiration, and adding a new DNS record that comes from the fallback request to the traditional DNS. Records in the network are updated based on their TTL values, as is the case with traditional DNS resolvers. When a record expires, it is automatically updated by querying the traditional DNS and going through the consensus process as will be explained further below. In both cases, the network must ensure that the records remain consistent, accurate, and available across more nodes (expired or modified records need to be replaced, while new records must be introduced into the network). To achieve consistency and tolerate malicious nodes, a permissioned blockchain is used to manage DNS record updates. A permissioned blockchain is chosen over a permissionless one to avoid transaction fees and reduce overhead (e.g., computational and storage). This blockchain operates at the chunk level, meaning that peers managing the same chunk of DNS records act as a permissioned blockchain to validate and record updates. When serving DNS requests, however, these peers operate as part of the Chord DHT for eficient lookups.
DNS Record Update When a record expires (based on its TTL value), the nodes storing it are responsible for fetching an updated copy from the traditional DNS and updating their local version. When the record old is updated, the responsible nodes submit a transaction update(old, new) to their blockchain. The consensus mechanism of the blockchain ensures that only valid updates are accepted based on rules such as record format and TTL validity. All peers storing the chunk containing old participate in the consensus process cons, which validates the update: cons(update) = {︃valid,
Once the update is validated, the updated record new is stored locally by all nodes responsible for chunk .
Update(IP, new()) ∀ IP ∈
This process guarantees that all nodes storing the chunk agree on the update, ensuring the integrity and consistency of the record across the network.
Adding a New Record When a requested record is not stored in a chunk, the nodes managing that chunk are responsible for retrieving and storing the record. The nodes perform a fallback to the traditional DNS to retrieve it and insert it into their chunk. The requesting node uses the DHT to determine which chunk the retrieved record belongs to as explained in Section 4.2. If the node stores the relevant chunk, it notifies the other nodes on its blockchain about the new record insertion. All nodes are responsible for falling back to the traditional DNS to retrieve the record. They then submit a transaction new(new()) to the blockchain, following the DNS record update process described above. The same consensus process cons is used for validation. cons(new) = {︃valid,
if consensus is reached invalid, if consensus fails
Once validated, the new record new() is added to the corresponding chunk and stored by the responsible peers.
Add(IP, new())
If the requested record is in a chunk managed by other nodes, the node uses the DHT to identify them and forwards the request. Those nodes then retrieve the record via fallback to traditional DNS, submit the transaction to the blockchain, and follow the record insertion process.
In this section, we analyse the strengths of the proposed architecture compared to traditional DNS, highlighting its advantages in terms of decentralisation, security, and transparency. By addressing key weaknesses in the traditional DNS architecture, the system ensures greater resilience against failures, tampering, and censorship, and shows how the proposed design overcomes those limitations. Below, we explore these improvements in detail. Centralisation and Single Points of Failure As discussed in Section 2, traditional DNS resolvers depend on centralised infrastructure, making them vulnerable to outages, misconifgurations, and targeted attacks. The proposed model distributes DNS records across a P2P network with each chunk replicated across multiple nodes for availability and balance. If a node fails or a partition occurs, the DHT-based routing layer redirects queries to other replicas. This decentralised design removes single points of failure and improves resilience against denial-of-service (DoS) attacks. By replacing static trust in centralised resolvers with verifiable, distributed replication, the system ensures reliable resolution even under adverse conditions. Censorship and Tampering Traditional DNS queries are vulnerable to censorship and tampering, as shown in real-world cases in Section 1. The proposed resolver mitigates these threats by decentralising resolution and validating responses from multiple independent peers. A query is only accepted if more than 2 out of responses agree, making isolated manipulation inefective and coordinated tampering detectable unless most peers in a chunk are compromised. Since nodes are independently operated without central oversight, large-scale manipulation is significantly harder. Inconsistencies trigger retries or conflict resolution, preserving response integrity.
Security Considerations Traditional DNS is vulnerable to threats like cache poisoning and forged responses due to its reliance on individual resolvers and limited validation. The proposed system counters this by decentralising trust and requiring consensus for every DNS record update. Whether from record changes or fallback to traditional DNS, each update must pass a consensus protocol cons among the responsible blockchain peers. An update is only accepted if enough peers validate it; otherwise, it is discarded. This prevents a single compromised node from corrupting data and protects against injection or replay attacks. By requiring agreement before any change, the system secures DNS integrity and reduces attack surfaces. Lack of Transparency and Control. Traditional DNS lacks transparency, leaving clients unaware of the resolution path or the DNS servers involved, which can lead to vulnerabilities like incorrect or outdated responses due to misconfigurations or compromised servers. Clients also cannot verify server liveness, making it dificult to detect unresponsive or compromised resolvers. In contrast, our model ensures full transparency. Each node independently handles resolution, selects peers, and verifies the data they return using consensus. This reduces the risk of outdated or incorrect responses, as nodes do not rely on potentially compromised third-party resolvers.
In this paper, we proposed a decentralised DNS resolution system architecture that addresses the vulnerabilities and limitations of traditional DNS, including centralisation, single points of failure, and lack of transparency. By distributing query resolution and using consensus for updates, the system improves availability, security, and resilience. It defends against cache poisoning and forged responses by validating updates and responses through multiple peers. Nodes maintain full control over resolution, making tampering detectable. The replication mechanism improves fault tolerance and resists censorship. This approach ofers a secure, censorship-resistant alternative to traditional resolvers. Future work includes evaluating the system’s performance and security through real-world simulations.
This work was partially supported by the UK Research and Innovation (DTP Scholarship under grant EP/T517859/1); and the Academic Centre of Excellence in Cyber Security Research University of Southampton (EP/R007268/1).
During the preparation of this work, the author(s) used ChatGPT and LanguageTool in order to: Grammar and spelling check, Paraphrase and reword. After using this tool/service, the author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content.