Weâre excited to announce that we have begun work on limo-web3-dns, an experimental
domain specific implementation of the DNS protocol for direct resolution of ENS records.
The limo-web3-dns nameserver will extend traditional DNS functionality to on-chain
ENS domain records, allowing native and seamless resolution via most network
capable clients. The ultimate goal of limo-web3-dns is to provide trustless, auditable,
and cryptographically signed ENS over DNS to bring ENS to parity with DNS.
Why
The Ethereum Name Service provides a best-in-class decentralized alternative to
traditional Web2 DNS services, however, client accessibility remains a challenge and
many legacy systems are still unable to perform resolution against this next generation
name protocol. Further complicating matters is the impending inclusion of the .eth TLD
into the ICANN namespace. In order to better mitigate the risks of centralization posed
by registrar operated nameserver infrastructure, we are proactively building the tools
that will enable the ENS community to host and manage their own DNS implementation of
the ENS protocol.
Project outline and goals
Extends native ENS resolution to home networks, cloud environments, and
server-side applications (regardless of ICANN inclusion).
Community operated - DAOs/projects/teams can self host and custody their
own nameservers, further federating the DNS namespace and providing end users
with connectivity that can be managed and governed by their respective communities.
Designed from the ground up with ENS in mind. All record types can be resolved
through their native verbs without any additional configuration.
Gateway optimized - seamlessly handle contenthash record resolution via the gateway
or gateway(s) of your choice - deploy once, resolve anywhere.
Cryptographic verification - the nameserver implementation is designed to reply with
a second, unsolicited response, containing signature and verification data as well as DNSSEC
support for zone signing. Clients may then (optionally) verify the response prior to taking further action.
Mitigate and reduce the risks of centralization imposed by including the .eth TLD into a
global, Web2 namespace. We believe that ENS domain holders should have the right and the ability to control how their domains are resolved over the traditional DNS protocol.
Open source and community contributions - The ENS protocol is a living and constantly evolving technical organism. Standards, RFCs, and security considerations should be handled by stakeholders, not registrars.
Encourage further federation of the nameserver infrastructure.
CCIP-Read compatibility. No L2 left behind.
The eth.limo team will be operating a set of public nameservers for the .eth TLD.
ICANN-o-worms (translation: itâs complicated)
.eth as a gTLD, what are the challenges?
Web2 DNS records arenât compatible with existing ENS content fields A, AAAA, CNAME, ALIAS records donât make sense without gateway support. DNS should wildcard read and automatically resolve records for a given
ENS domain name (i.e. com.txt)
DNSLink is a bandaid. Client specific implementations (not universally understood, particularly OS resolvers) No RFC Requires local application handlers
Greater centralization over name resolution. Registrars will dominate the majority of DNS request handling, since by default they will become authoritative nameservers.
Split-horizon problem. The DNS protocol itself should not be able to override or otherwise mutate query responses that differ from their on-chain representations.
Call to action
We believe that ENS works best when itâs governed and managed by the stakeholders that depend upon it. We understand that solving Web2 adjacent problems in Web3 isnât necessarily âsexyâ, however itâs imperative for us as a community to anticipate and address implementation risks, wherever they might arise. The eth.limo team will continue project development and defining standards, however we need your help! Please get involved in any way you can. This is an open project that welcomes contributors regardless of skill level.
@ (9) / (3) / (5)
For @NameSys weâre testing web2 domains in ENS to store their ENS records in https://domain.tld/.well-known/tld/domain/....json format with owner/approved signature verification for ccip callback and using domain.tld itself as web2/ccip-read gateway. So I think itâs possible to use that format in future web2+3 .eth TLD to store all ENS records in contenthash, *except contenthash as itâll all dependent on contenthash⊠weâve have to find some loophole like our recordhash setup or update ENS specs for that to work properly.
@ (1) / (10)
As youâre aware of our old experiment with local proxy auto configs to handle domain.eth/ on desktop/mobile using simple pac file. Obviously doesnât work out of box in example below as dweb.link/eth.limo are not open to handle such proxy requests⊠thereâs some issue without ssl for .eth, itâs displayed as insecure http on browser even if proxy is forwarded with port 443⊠& users must enter domain.eth/ with / to trigger browser to resolve that as domain until itâs certified by ICANN.
2.pac file https://namesys-eth.github.io/2.pac users have to manually add pac file URL in network/auto proxy settings for their desktop/mobile.
function FindProxyForURL(url, host) {
if (!shExpMatch(host, "*.eth")) return "DIRECT";
let ipns = host.split(".").join("-") +".ipns.dweb.link:443";
return "HTTPS "+ipns+"; HTTPS "+host+".limo:443";
}
? if itâs possible to add temp proxy server with eth.limo/nameserver setup so we can use eth.limo NS as proxy or run everything locally?
Web2 compatibility as .eth TLD is old dream but weâve to make sure ENS users donât get rekt by middleman from web2 & their geopolitical rulebooks. /always happy to explore & experiment more on Discord
Itâs great to see some experimentation and progress here. I hope it can work out, but if I understand this correctly the NS still relies on an ICANN domain eth.limo to resolve the .eth domains?
In terms of use-cases, weâve pursuing the following high level goals:
Extend ENS integrations into commonly used protocols (i.e. DNS/HTTP)
Make ENS as accessible and as widely supported as possible in order to better foster the adoption of dWeb technologies.
With that in mind, we foresee several interesting applications of an ENS/DNS implementation:
Allow users to self-host nameservers for private/home/work/conference networks, enabling native client name resolution. Couple this with an IPFS gateway (local or network provided) and it becomes possible to type .eth into your address bar (Chrome/Safari/Edge/Firefox, etcâŠ).
When and if the .eth TLD becomes fully released by ICANN, users will have a nameserver solution available. We see this as an opportunity to preemptively build out these new standards in a community oriented way, not leaving it to registrars and other establishment entities.
Server-side ENS resolution, allow traditional operating system libraries and tools to work with the protocols theyâre already built to support.
There are probably a dozen other novel use-cases that will be discovered as time passes, weâll leave that up to the builders in the ENS community, as they always push the limits and encourage us to grow and develop in new ways.
In regard to proofs, weâre approaching them as a second, unsolicited response that would contain something like âsignature=$signature + $timestampâ. This is an area weâre actively researching right now.
Isnât this possible today, using IPFS and wildcard DNS?
- it would be good to expand on what these capabilities might be, though.
Can you expand on this? Are we talking about hosting DNS records in ENS, or are we talking about âtraditional toolsâ resolving ENS-native records like addr? If the latter, why not just use an existing API?
So this would ultimately rely on trusting the DNS server?
Yeah but it only works for contenthash resolution. You canât fetch TXT records unfortunately. Even when using IPFS directly it requires an ENS-compatible DoH endpoint to call for resolution.
For us, weâre more focused on using the DNS protocol to retrieve âweb-relatedâ ENS records such as TXT and contenthash from the protocol. DNS is just an ask/response mechanism for certain ENS record types that have a congruent mapping to their DNS counterpart (TXT, A, CNAME). Ideally existing system libraries like getnameinfo and systemd-resolved would be able to fetch these records for things like using curl against a .eth domain in a script, for example. Another interesting use case could be service discovery for apps in cloud VPCs/kubernetes using CICP-read and a wildcard resolver.
Unfortunately thatâs a limitation with the DNS protocol in general. There are things that can be done to mitigate some of the risks associated with trust but itâs probably not possible to fully eliminate. We look at it as an opportunity cost: provide users with software they can self-host (likely in an environment they do trust) or let someone else provide the service for them. Ironically though, this pattern can help preserve end user privacy with CCIP-read (assuming everything is properly configured) since the nameserver will be performing the calls.
What else did you have in mind besides contenthash resolution?
I understand the use-case in the abstract; what Iâm not sure about is the actual practical use-cases. Why would someone choose to develop against DNS as an ENS API, rather than using a node connection, or a restful HTTP-based API?
If the DNS server is assumed to be trustworthy, can you simply use DNSSEC to sign responses, then?
Arbitrary TXT records for things like TLSA and ACME challenges, GitHub pages hosting, etcâŠ
We think thatâs kind of the beautiful thing about it - no one really âneeds toâ develop against it. Any library or OS that works with DNS should be able to consume ENS records natively. Thereâs also the relatively large elephant-in-the-room that is .eth TLD inclusion into the DNS namespace - we want to make sure that users have infrastructure tools to perform that type of resolution since it will invariably be required anyway in order for it to function.
Yes! DNSSEC support is absolutely going to eventually be supported as well. Weâre working through exactly how that will be implemented as there are a few things to take into consideration since those zone-keys will still need to be signed by the root registrar.
A, AAAA, CNAME, ALIAS records donât make sense without gateway support.
users have to manually add pac file URL in network/auto proxy settings for their desktop/mobile.
- it would be good to expand on what these capabilities might be, though.