IPFS + ENS Everywhere: Introducing EthDNS

With apologies to O’Reilly Media

Ethereum Name Service (ENS) and Protocol Labs (the original creators and stewards of IPFS) are proud to present the next step in ENS + IPFS integration: EthDNS. This builds on earlier work described in EIP-1577, which standardized references to IPFS resources from ENS records.

(Psst: If you’re not familiar with ENS names, or pointing them to IPFS content, go read about it right now, or just hop over to the Manager or a 3rd party registrar and register some names!)

EthDNS bridges the traditional web world to the new universe of ENS-named, IPFS-backed decentralized sites and dapps through the ancient, yet indispensable, 🧙‍♂️ Domain Name System 🧙‍♂️. The EthDNS project to date contains a few pieces:

• the coredns-ens plugin (official CoreDNS plugin listing), which you can enable for your organization if you run your own DNS (see the repo for more details)
• a nameserver running this plugin that makes all ENS .eth domains available via traditional DNS as *.eth.link
• a DNS-over-HTTPS endpoint at https://eth.link/dns-query that directly supports .eth as a TLD

TLDR: To try it now, load almonit.eth as https://almonit.eth.link ✨, or read on to see how to load it without the .link (!!)✨✨✨

ENS ❤ DNS (really!)

A few forward-thinking vendors are in various stages of implementing ENS/IPFS support (shouts to Brave and Opera!), but most “mainstream” browsers still require help from extensions like MetaMask and IPFS Companion — not something you can easily share with your dWeb-naive friends.

So, let’s load an ENS + IPFS site using our helper DNS zone at eth.link:

✨

It works! This is how:

• the eth.link nameserver is responsible for all *.eth.link subdomains, which correspond to .ethdomains in ENS
• this nameserver runs our coredns-ens plugin, which resolves these domains in the ENS contract via the Ethereum API
• if the ENS domain has a content value set to an IPFS CID, but noA record of its own, the A record is returned pointing to the EthDNS project IPFS gateway
• the content value itself is returned as a TXT record in the dnslink format
• the gateway loads the IPFS content associated with the ENS domain using the same mechanism we use for traditional domains, based on the TXT record above

What makes this different from proxy service approaches to the same problem is that the name and content layers are clearly separated, yet coordinated: the name and CID lookup happens at the DNS level, the IPFS content is served through a regular gateway, but both work seamlessly together from the user perspective.

(N.B.: If you don’t wish that your domain be served via the default EthDNS gateway, you can easily specify one of your choice via the A record in ENS —though be aware, they must be running recent go-ipfs)

Do’H!

This is pretty good, but what what if we could take it a bit further? What if you could switch one line of configuration in your unmodified browser and load ENS registered, IPFS hosted sites, as first class citizens, right now?

With the EthDNS DNS-over-HTTPS (DoH) service, you can do exactly that. Simply set your DoH resolver (Firefox instructions, Chrome Instructions) to https://eth.link/dns-query and load any IPFS-backed .eth site directly through the url bar:

✨✨✨

(We use DoH here instead of plain recursive DNS because the latter puts the server at risk of being recruited for DNS amplification attacks.)

You can try the resolution yourself with cURL (AAE... is a DNS wire format query to resolve matoken.eth):

The only caveat is that traditional SSL certificates can’t map to these domains (rightfully so, given that a 3rd party gateway is fulfilling the request), so you won’t have a green 🔐. A promising solution to this problem is the Signed Exchanges feature of the webpackage format, which decouples transport security and content authentication.

MOAR

Of course, these use cases are only a stepping stone in the transition to first class decentralized web content everywhere. The good news is that the design of EthDNS already supports a few more hops into the future:

• On local networks, CoreDNS is a fully featured DNS server, so your conference, meetup, or office can transparently gift ENS+IPNS dweb powers to all visitors by specifying a local EthDNS server in DHCP (we’re going to try setting this up at DevCon 😈).
• Because EthDNS returns EIP-1577 IPFS CIDs as TXT records in the widely supported DNSLink format, it’s transparently compatible with all existing IPFS tooling, so you can e.g. use it alongside go-ipfs to supplement decentralized naming in IPNS.
• Even if the user isn’t configured for DoH, Dapps can still make requests to the resolution endpoint (we’ve enabled CORS allow), so any app that doesn’t want to rely on MetaMask or need full Ethereum API can use a simple XHR call for ENS resolution.
• Any scenario where running an ethereum client is unavailable or undesirable can take advantage of ENS name resolution over either classic DNS or DoH.

And likely many more! We want you to send eth.link links to all your friends, grab the plugin, use the DoH in your browser, poke at it with DApps, and set it as the DNS in your IoT toaster. Come find us at DevCon and tell us what you’ve resolved!

This work was made possible by a grant from the IPFS team at Protocol Labs.

PLEASE NOTE: even though we worked very hard on this release and are very proud of it, DNS-over-HTTPS in general, and EthDNS in particular is still a relatively new technology, and should be used with some caution. eth.link is operated by ENS with support from Protocol Labs as an educational and experimental public service with no guarantees, and should not be used for mission-critical applications. Neither ENS or Protocol Labs reviews or retains query logs from this service. We recommend you set up your own EthDNS instance for use with production DApps.