tl;dr: If you go to docs.ens.domains, your DNS query was served by the Ethereum blockchain! It’s DNS, hosted on Ethereum, and you can use it for any DNS domain.
Today we’re releasing experimental support for hosting DNS domains on the Ethereum blockchain. This builds on previous work on ENS, the Ethereum Name Service, adding a DNS gateway and support for storing DNS zones inside ENS.
For those who want to try it out, a brief howto on hosting your own domain on the blockchain is here. This post aims to explain, not how to set it up, but how the system works at a technical level — gluing two different naming systems together.
Background
First, a bit of background. DNS, as you may already know, operates on the basis of ‘zones’. A zone represents a division of authority, and a nameserver is responsible for returning authoritative answers to queries in one or more zones that it hosts, while providing references to other nameservers that host zones further down the hierarchy.
For instance, when you resolve ‘docs.ens.domains’, your resolver first consults one of the DNS root servers, who respond to the effect that they don’t know the answer, but here’s someone who might — and listing the nameservers for ‘.domains’. Your resolver then asks them the same question, and they respond with a referral to the nameservers for ‘ens.domains’. Finally, your resolver asks those nameservers, and they respond with an authoritative answer: ‘docs.ens.domains CNAME readthedocs.io’.
ENS operates in a somewhat different fashion. Unlike DNS, it has a central database — the ENS registry — mapping from domain names to resolvers. In addition, each domain has an owner, who can update the resolver address, and create and delegate subdomains. To look up information on a domain, callers first consult the registry to get the resolver address, then query that resolver to get the answer to their question. Just like DNS, it permits diversity of implementations for resolvers, and delegation of authority within the name hierarchy, but unlike DNS, it has no concept of ‘zones’.
How the DNS->ENS gateway works
The naive way to store DNS data on the blockchain would be to deploy a single ENS resolver for the existing DNS hierarchy, and expect resolvers pointed to by this registry to support returning zone information for their domains. A gateway could then look up the ENS registry for the domain being queried for, fetch the zone data, and satisfy any queries from that.
This works, but has a critical problem: who do you allow to update the registry? You only want the owner of a domain to be able to update their DNS entries, but there’s no obvious way to prove ownership of a DNS domain on the blockchain — especially since you can’t use the usual route for checking name ownership, requiring someone to set a specific DNS entry!
Instead, we take a slightly different approach. We allow anyone to deploy their own ENS registry and resolver, and host whatever set of domains they like on it. Then, they include the address of their ENS registry in the DNS nameserver record for their domain. Since everyone has their own registry, we no longer need to be concerned about proving you have the right to update a name — nobody will ever consult your registry unless it’s referenced by the existing DNS infrastructure.
For instance, suppose you deployed an ENS registry for your domain, ‘myawesomedomain.com’ at the address 0x1234ABCD, and configured it appropriately. To finish the process, you would go to your registrar, and tell it to set the nameservers for your myawesomedomain.com to ‘1234ABCD.ns1.ens.domains’.
Now, when someone wants to resolve ‘www.myawesomedomain.com’, the following steps happen:
- The user’s resolver does the usual recursive resolution, eventually being told ‘myawesomedomain.com NS 1234ABCD.ns1.ens.domains’. They send a query to that address, asking ‘A www.myawesomedomain.com’.
- The gateway server at ‘ns1.ens.domains’ receives the query. Before it can answer it, it needs to know if ‘www.myawesomedomain.com’ is actually hosted on ENS, and if so, which resolver is responsible for it — so it does the same query the client did, looking for nameserver entries for ‘www.myawesomedomain.com’. Eventually it gets back the same response the client did, ‘myawesomedomain.com NS 1234ABCD.ns1.ens.domains’. It recognises this, and treats the first part as an Ethereum blockchain address for an ENS registry.
- Now the gateway server knows where to look, it queries the ENS registry at that address, asking it for the resolver responsible for ‘myawesomedomain.com’.
- Next, the gateway server asks the resolver for the zonefile for ‘myawesomedomain.com’. It gets back the DNS zonefile data in compact binary form, and unpacks it into memory.
- Finally, the gateway server uses the unpacked zonefile data to answer the original question it was given, ‘A www.myawesomedomain.com’, and returns the answer to the client.
If you’d like to see how all of this is implemented in practice, the — still very much a work in progress — code is available on GitHub.
What this means
First off, this isn’t automatically more censorship resistant than regular DNS servers. The zone itself becomes very difficult to censor, but for your users to find that, they still have to get referred to it via NS records in the parent zone, so it’s still vulnerable to being taken down or blocked in that manner. Moving the DNS root onto Ethereum would solve this by making every lookup backed by the blockchain, but obviously that’s not something I can hack up for a tech demo. Doing so would also raise issues around DNS zone enumeration: many people don’t want arbitrary strangers to be able to list all their DNS records, and the present solution would make that possible.
Likewise, it’s not automatically more secure; you still have to trust that referral from the parent zone, and if you’re using a public gateway (instead of running your own DNS gateway), you have to trust that it’s responding accurately. DNSSEC can be used here just as on regular DNS to secure things better. Again, a system with the root in Ethereum would solve this problem and obviate the need for DNSSEC entirely!
What this is is a really convenient way to distribute nameserver data to nameservers in a fashion that they know that insofar as they can trust their own DNS resolution, they know they can trust the validity of the data they’re fetching, and that it was written by someone authorized to do so. And it permits this in a fashion that means anyone can utilize the public DNS gateways without having to directly interact with or configure them. It’s also a neat tech demo of ENS.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!