DNS (Domain Name System) was born almost forty years ago to provide the ability to assign human-readable names to nodes in a network. Without names, such nodes would have had to be identified via IP addresses, which are very difficult to memorize, write, and read.
ENS (Ethereum Name Service) aims to solve the same problem in the Ethereum blockchain. It maps human-readable names (such as “name.eth”) to Ethereum addresses or content hashes, which would be extremely error-prone to write by hand.
The Replay is a weekly newsletter for dev and engineering leaders.
Delivered once a week, it's your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.
As per the official documentation, ENS is defined as “a distributed, open, extensible naming system.” Being a decentralized system, ENS is not controlled by any centralized entity or party. As such, there is no single point of failure. Additionally, ENS supports IPFS (InterPlanetary File System), a peer-to-peer protocol to store and share data in a distributed file system.
ENS is built on two fundamental components: the registry and the resolvers. The former is a smart contract that records all the domains registered on ENS, along with some metadata regarding each domain (owner, resolver, and the caching time for all the records under the domain). Resolvers are smart contracts, too. They turn human-readable names (i.e., the domain names) into hexadecimal addresses, and vice versa.
Hence, resolving a name in ENS requires two steps:
ENS supports Ethereum domains, .eth, as well as the most popular “DNS” domains, such as .com, .io, and .org.
This sounds all good, but, at the time of writing, most browsers are not able to resolve .eth domains without a little help. Some third-party extensions out there do the job, but they require extra steps to be set up. For this reason, two gateways have been created so far: eth.link and eth.limo.
In this blog post, we’re going to compare them.
eth.link is a centralized way to access information in the ENS from DNS, managed by Cloudflare, a company providing CDNs (Content Delivery Networks) and DDoS (Distributed Denial-of-Service) mitigation services.
Under the hood, eth.link uses a wildcard DNS record (*.eth.link) to capture requests for all ENS domains. In other words, eth.link leverages the resolution of .link domains to obtain information about a given .eth domain. For example, a DNS A record request for mydomain.eth.link would trigger the wildcarded *.eth.link record and return the A record in ENS for mydomain.eth.
eth.link runs entirely on Cloudflare Workers, which is essentially a runtime in execution on several servers (owned by Cloudflare) across the world. In the rest of the post, we’ll refer to “Workers” as the server themselves, for the sake of simplicity.
Whenever a user tries to access mydomain.eth.link, Workers query ENS (i.e., the Ethereum blockchain) for a CID (Content Identifier). CIDs are directly derived from the content of a resource, so they are often referred to as self-describing identifiers. They’re basically hashes describing the content of something, such as a webpage.
Once the CID for mydomain.eth.link is established, Workers query an IPFS Gateway with the CID in order to obtain the content of the webpage. The content is then forwarded to the user.
The main issue of eth.link is surely its centralization, which puts a lot of control in Cloudflare’s hands. It also makes it more prone to the following issues:
To solve the issues listed above, another gateway was born: eth.limo.
eth.limo is a decentralized alternative to eth.link. Similar to eth.link, eth.limo is based on a wildcarded DNS record, *.eth.limo. However, instead of being managed by a single organization, it is powered by a DAO (Decentralized Autonomous Organization), so its inner workings are defined in a smart contract and cannot be changed unilaterally.
The flow is the same as that described above. When a user tries to access mydomain.eth.limo, the LIMO service fetches the CID for the webpage from Ethereum’s main network and then returns the content of the requested webpage. The project is still in a very early phase, but the goal is to be able to let anyone deploy a personal LIMO service.
The developers are also considering letting anyone operate a node for the official network in order to build a community-run CDN. This is quite different from eth.link’s approach, where the nodes of the network are entirely under Cloudflare’s control.
Early tests showed that eth.limo is faster than eth.link, even though the load is still much different, being that eth.limo is still in alpha test:
Source: https://twitter.com/eth_limo/status/1433093424178253828?s=20
eth.limo is younger than eth.link. Hence, it is still being tested and developed. However, its roadmap is focused on user privacy and community governance and oversight.
In this post, we saw a brief comparison of two alternatives to resolve .eth domains using ENS. On the one hand, we have the experience and the infrastructural power of Cloudflare powering eth.link. On the other hand, we have a community-driven project built around decentralization and with a strong focus on user privacy, eth.limo.
Even if similar in how they work, the two projects are deeply different. eth.limo is surely less mature than eth.link and with a very ambitious program. As its core principles adhere much more to Ethereum’s and blockchain’s ones, I think it’ll become a very interesting project in the future. At the moment, however, it’s at the beginning of its life, and using only eth.limo could be a risky choice.
eth.link, on the other hand, is more “production-ready” because it’s been around for more time. Hence, if I were to start a personal project using a .eth domain, I’d probably want to use both of them, with the goal of migrating to using exclusively eth.limo as soon as it becomes more stable.
At the time of writing, those are the only two possibilities. As the ability to choose is an important part of the transition toward decentralized applications and the web, we’ll see if, in the future, new alternatives will come up.
Client-side issues that impact users’ ability to activate and transact in your apps can drastically affect your bottom line. If you’re interested in monitoring UX issues, automatically surfacing JavaScript errors, and tracking slow network requests and component load time, try LogRocket.
LogRocket lets you replay user sessions, eliminating guesswork around why bugs happen by showing exactly what users experienced. It captures console logs, errors, network requests, and pixel-perfect DOM recordings — compatible with all frameworks.
LogRocket's Galileo AI watches sessions for you, instantly identifying and explaining user struggles with automated monitoring of your entire product experience.
Modernize how you debug web and mobile apps — start monitoring for free.
Learn how to test Nuxt apps with Vitest, @nuxt/test-utils, runtime mocks, server route mocks, and Playwright e2e tests.
I had four weeks to build a complete app from scratch using AI tools like OpenCode and Claude Opus: here’s how it went.
Learn how to build a reusable Vue 3 table engine that powers tables, cards, and lists with shared sorting and pagination logic.
Compare the best React chart libraries for 2026, including Recharts, Nivo, visx, Apache ECharts, MUI X Charts, and more.
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn more →
