Handshake, ENS and Decentralized Naming Services Explained

The Domain Name System has been in operation for decades and is the infrastructure that handles billions of queries over the internet. As a user, you rely on your operating system and browser to help navigate the internet. However, whats humming quietly is the back-end infrastructure that helps your device find the right website. The DNS is part of the internet infrastructure which is a distributed network that handles queries from billions of people. The query is sent to a resolving server and its only task is to find the IP address behind the website you requested.

Recently many blockchain based solutions are starting to rise and they offer a compelling value proposition. Imagine being in Turkey the day they disabled the resolving server from seeking the Twitter IP address. How would you react? You would probably be upset that the government is restricting access to your social network. So blockchain based solutions could be a formidable competitor to Domain Name Systems but that could come with some sacrifices. In the next few paragraphs, I will dive deeper into the DNS architecture and compare it to its blockchain based equivalent such as Ethereum Naming Service and Handshake.

The history and architecture of Domain Name Systems

In order to understand Domain Name Servers and the birth of its existence lets go back to the establishment of ARPANET. ARPANET was built so that information between research centers could be accessed quickly. Throughout the years, more computers started connecting to ARPANET which made it harder for any one person to manage all of the IP addresses. From a scalability standpoint, it was difficult for workers to maintain a centralized naming server (due to load) and then having to remember the actual IP addresses that they wanted to connect to. So Paul Mockoapetris a researcher at the time proposed that hosts should include a name and category that would be linked to an IP address.

So in a nutshell, DNS converts machine-readable IP addresses like http://74.123.225.72. to human readable words such as “Google.com”. Sounds simple, but this new system introduced a distributed way of storing naming systems. Primarily, the host names reside in a database that is distributed between multiple servers, this helps decrease the dependence of any one server at a given time. Further, it allows the naming file system to be distributed to all of the servers that are within the DNS topology. Which means that servers throughout the world can resolve queries without trusting one centralized server.

DNS Hierarchy

A fully qualified domain name is the complete domain name for a host on the internet. For example, if we take a look at mail.google.com, the hostname is mail, and the host is located within the domain “google.com”. Also, .com is the top-level domain (TLD). Now think of this hierarchy as similar to a root directory on a computer with sub-folders. The .com would be a TLD, Google has been assigned the Google.com domain, and has authority to create sub-domains like mail.google.com

DNS Governance

Now that we have an understanding of the DNS hierarchy lets dive deeper into the way its governed. Every domain name needs to be unique and controlled properly so that we do not have duplicate domains owned by different entities. That’s where the registrar (e.g. Go daddy) comes in, Go Daddy can register domain names and top-level domains with the ICANN (Internet Corporation for Assigned Names and Numbers), which enforces the registration globally. ICANN is a nonprofit organization that is tasked with managing and updating namespaces globally while making sure that the network is operational. Now that the domain is registered it then becomes part of a central domain registration database (e.g WhoIS) and propagated throughout the network.

How does DNS actually work?

When you type in Google.com into your browser, your browser sends a DNS query to a recursive server (e.g. local ISP). If the recursive server has the IP address in its cache then it can provide the proper information back to the requesting host. However, if the IP address is not found with the recursive server, it would then contact the root server. Typically, the root server would then redirect the recursive server to the proper top-level domain servers (e.g .Com or .Gov servers). The top-level domain servers would then point the recursive server to the proper authoritative naming server which would have the IP address for Google.com. That information would be sent back to the host and cached into the recursive server for future use.

To simplify:

  1. User types in website address “Google.com”
  2. Browser sends request to recursive server to find IP address
  3. Recursive server will then contact root server -> tld name server -> authoritative name server
  4. IP address is located and recursive server will send information back to user

Security concerns with DNS

Domain Name Servers are distributed in nature but all have to rely on servers to get the right information. This convoluted process could allow a query to be hijacked.

There are several ways for your query to be hijacked:

  1. The first is when a hijacker takes control of one or more of the authoritative DNS servers for a domain.
  2. A second way is called cache poisoning attack, which essentially injects malicious data to the recursive server.
  3. A third way is to take over the registration of the domain itself and reroutes users.
  4. A fourth way is Distributed Denial of Service (DDoS) which can turn small queries into much larger ones, taking down the user’s server.

The attacks above could essentially reroute a user to a site that the hijacker controls. For example, back in December of 2017, Etherdelta was hacked and the hacker was able to run away with $250K in ETH. The attacker took over the DNS name server for Etherdelta and replaced it with a site that looked identical. Users logged on to see the site unchanged and as users began to transact, they found funds to be depleted.

Why on the blockchain?

The DNS database is large but the distributed nature of the blockchain could store information on millions of devices globally. With the information being stored and with the right consensus mechanism, we can avoid the reason to trust back-end servers to resolve queries. From a security perspective, we could mitigate most attacks by resolving to the immutable blockchain. This would ensure the viability of the domain addresses and protect users from being phished or scammed. Also Domain Name Systems are more amenable to DDoS attacks in comparison to blockchain-based solutions. Finally, Turkey decided to turn off Twitter.com by not allowing the recursive server to find the Twitter domain address. A solution on the blockchain would circumvent any decisions that the government made and can keep sites censorship resistant.

I have listed a few projects below that are working to build Domain Name Servers on the blockchain.

ENS Overview

“The ENS registry is deliberately straightforward, and exists only to map from a name to the resolver responsible for it.” — ENS Project

DNS is similar to ENS which converts machine-readable address to human-readable address. IP addresses would be replaced by Ethereum addresses, IPFS/Swarm hashes. The architecture between both DNS and ENS are different due to the nature of the Ethereum blockchain. As you can see below, ENS significantly reduces its architecture by allowing the smart contract to be the registrar instead of Go daddy. By reducing this function to a smart contract anyone can create a subdomain based on the rules of the registrar. Finally, the resolver acts as a translator that converts names to hashes and addresses. You can read more about it here: Ethereum Name Service

Handshake Overview

“Handshake is a decentralized, permissionless naming protocol compatible with DNS where every peer is validating and in charge of managing the root zone with the goal of creating an alternative to existing Certificate Authorities.” — Handshake.org

Handshake is a UTXO (Unspent Transaction Output) based blockchain which uses Bcoin which is an alternative full node software to Bitcoin Core. The consensus protocol within Handshake would replace the ICANN root server. As explained above, ICANN is a nonprofit organization that is tasked with managing and updating namespaces globally, while making sure that the network is operational. Traditionally, the recursive server would point to the root zone file to locate the IP address. With Handshake, “The recursive resolvers would point to an authoritative name server which would be committed to the blockchain rather than ICANN’s root zone file.” Further Handshake takes it a step above by making the owner of the name a cryptographic key. This gives the owner the ability to create signatures signed by the owner’s key. This process would essentially replace the Certificate Authority entities that we have today. Currently we have to trust organizations like Verisign to maintain TLD servers that would keep it secure. You can find the 13 named authorities that manage root servers here.

Steven McKie published a detailed overview.
Chjango Unchained published a technical overview.
Handshake whitepaper click here.

What’s the difference between Handshake and ENS?

Handshake and ENS are approaching the DNS space with unique strategies. Handshake is focused on becoming the root server for the entire infrastructure. Traditionally, root zones aggregate all of the top level domains into a root zone file. The root zone file is literally a 2MB text-based document that has the website names with IP addresses. This file is managed and distributed by ICANN (Gatekeeper). The goal for Handshake is to become ICANN but in a decentralized fashion. All of the full node peers within handshake would essentially be a root server which would serve the root zone file. Finally, Namebase is integrating with Handshake, which would allow anyone to purchase a Top-Level Domain. To purchase a Top-Level Domain today you would need to fill out an application and pay a $200,000 fee to ICANN (may or may not get approved).

Diagram of where Handshake, Namebase and ENS would fall

Ethereum Naming Service is operating as a Second-Level Domain provider for .ETH and .LUXE extensions. Today a user could purchase a domain name and manage the day to day activities. The ENS registry is a single smart contract that holds information on the owner, resolver and time to live. Currently, .ETH and .LUXE is owned by smart contracts that govern the allocation of subdomains. However, the team is working on being able to integrate any DNS domain on ENS. Currently, on test net, the process is a bit manual but offering a TLD service would make them a possible competitor to Namebase. Finally, ENS will be focused on building dApp integrations so that developers that are building on the Ethereum ecosystem could integrate seamlessly. To summarize, Handshake domains are resolved through simplified payment verification and is blockchain native while ENS uses the Ethereum blockchain to manage two centralized TLDs.

Domain Name Servers handle billions of requests a day from devices all across the world. If the Domain Name Servers were to ever go down, we would not be able to access the world wide web. The infrastructure itself is distributed but rely on servers to answer queries. Relying on servers could be an attack vector for potential hijackers and it can also give governments more power to censor content delivered to a user.

Blockchain-based solutions offer a solid solution around security and scalability but I am still not convinced around latency. I am excited about projects that are building on the blockchain such as Blockstack, Handshake, and Ethereum Naming Services. When these systems are ready to scale, they have the opportunity to take on billions of queries a day. I will be closely watching its developments and will be participating when the services are ready.

Special Thanks: Nathaniel Whittemore, Mohammed ElSeidy and Mohamed Fouda

Sources: Microsoft, DNS Works, Verisign, Wikipedia, Web Hosting Geeks, ICANN, Dynn, Blockstack, Handshake, and ENS