Names and Addresses on the Distributed Web
The DNS system maps human-friendly names such as blog.cloudflare.com to machine addresses like 104.18.26.46. Distributed systems need a comparable layer of indirection, but their naming infrastructure must satisfy a different set of constraints. A resolver for the distributed Web should return data that can be verified locally, keep a record of history, and operate without a single root of trust.
Cloudflare Research has been examining how the Ethereum Name Service (ENS) and IPFS can together provide such a system. The result is a new resolver that translates ENS domains into IPFS content, accessible from an ordinary browser.
How IPFS Names Content
IPFS is a peer-to-peer network of nodes that share content using Content Identifiers (CIDs). A CID is self-describing because it is derived from the content itself, not from a location. The CID QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco, for instance, is a CIDv0 for the wikipedia-on-ipfs homepage. That identifier, when inspected in binary form, reveals the hash algorithm used, the length of the encoded content, and the content hash itself:
A multicodec table then tells a client how the content is encoded:
Name | Code (in hexadecimal) |
|---|---|
identity | 0x00 |
sha1 | 0x11 |
sha2-256 | 0x12 = 00010010 |
keccak-256 | 0x1b |
Because the encoding is explicit and content-addressed, CIDs are unique and can be upgraded across protocols.
A CID alone does not tell a client where a file lives; it only says what the file is. Fetching it requires a query against the IPFS network. An ipfs:// URL is accurate but unwieldy to type from memory, and addresses are easy to mistype.
DNSLink was introduced to bridge that gap. A domain can carry a DNS TXT record pointing to a CID, and its A record can direct browsers to an IPFS gateway. The gateway then reads the TXT record, retrieves the content over IPFS, and serves it. This works, but it shifts the integrity burden. A browser that neither speaks IPFS nor validates DNSSEC has no way to check the content it receives matches what was requested.
A Name Index on a Blockchain
Ethereum addresses suffer from the same readability problem as CIDs. An address like 0xf10326c1c6884b094e03d616cc8c7b920e3f73e0 is not something a person can reliably type or recall. Checksum schemes that capitalise letters based on the address's hash only catch typos; they do not make an address memorable.
ENS tackles this with two smart contract components. A registry stores each domain along with its owner and the address of its resolver. Resolvers keep the actual records, mapping a domain name to a blockchain address or to an IPFS content identifier. The Public Resolver contract handles both cases.
For a client with direct access to the Ethereum state, looking up a domain works as follows. The client asks the ENS registry for the resolver associated with the domain, then queries that resolver for the specific record:
Retrieving an IPFS CID from the same domain follows the same lookup path, differing only in the method called on the resolver contract:
Bringing the Lookup to a Browser
Using ENS to resolve IPFS content from a browser requires access to both the Ethereum state and the IPFS network. Neither is natively available to a plain web page. Cloudflare operates Ethereum and IPFS gateways at cloudflare-eth.com and cloudflare-ipfs.com respectively, and those became the core of the resolver.
The first EthLink implementation, written by Jim McDonald and run by True Name LTD at eth.link, is now being replaced with a version built on Cloudflare Workers. From next week, eth.link will serve the new resolver.
The service proxies ENS-registered domains once a .link suffix is appended. A request to https://privacy-pass.eth.link should therefore render the Privacy Pass homepage. A wildcard DNS record sends all *.eth.link traffic through a Cloudflare Worker, which runs at the edge. For a requested domain, the worker first queries the Ethereum gateway for the CID recorded in the ENS resolver, then asks the IPFS gateway for that content and returns it to the user:
Every component can be run locally. The worker follows the Service Workers API and can execute inside a service worker environment, while the Ethereum gateway can point to a local node and the IPFS side can be handled by IPFS Companion. Cloudflare offers resolution-as-a-service, but none of the parts require trust in Cloudflare itself.
The distributed web is not fully built yet, but services like this one connect emerging infrastructure to existing web protocols. Moving resolution to the edge adds speed and security while keeping the underlying protocols open to independent verification. ENS has operated the initial service, and will switch https://eth.link to the Cloudflare resolver on January 18th.
