Gasless DNSSEC with Nick Johnson
Our attitude is that DNS is part of the global namespace.
Namefi: Sunny & Victor
ENS Foundation: Nick Johnson, Founder of Ethereum Name Service
“…Existing DNS systems will continue to exist and need to be integrated. "
— Nick Johnson, Founder of ENS
This piece is an archived conversation with Nick Johnson from a Twitter space we hosted together early this year when ENS launched gasless DNSSEC and partnered with GoDaddy in bringing the global namespace DNS into Web3.
As the conversation was quite long and dense, the archive is divided into 11 parts:
feedback for Namefi
what drove the creation of ENS?
ENS utility expansion and its community contribution
key difference between web2 and web3 naming
why building ENS on top of DNSSEC?
technically, how does gasless DNSSEC work with ENS?
non-technical explanation of gasless DNSSEC
how is gasless DNSSEC gasless?
challenge in gasless DNSSEC development
beyond GoDaddy, how can we get more clients and registrars alike to support gasless DNSSEC?
Audience Q&A
There are few internet terms that need definition to understand the conversation.
CCIP: "Cisco Certified Internetwork Professional." This certification focuses on advanced networking technologies and protocols, including routing, switching, and network infrastructure design, within Cisco networking environments.DNS: stands for Domain Name System. It is a decentralized naming system for computers, services, or other resources connected to the Internet or a private network. DNS translates domain names (like www.example.com) into IP addresses (like 192.0.2.1) that computers can understand and use to communicate with each other. It essentially acts as a directory service that helps users access websites and other online services using easy-to-remember domain names instead of numerical IP addresses.DNSSEC: stands for Domain Name System Security Extensions. It's a set of specifications designed to add security to the Domain Name System (DNS) protocol. DNSSEC aims to address vulnerabilities in the DNS infrastructure by providing authentication and data integrity mechanisms.ICANN: stands for Internet Corporation for Assigned Names and Numbers. It is a nonprofit organization responsible for coordinating the maintenance and operational procedures of the Internet's domain name system (DNS), IP address allocation, and other Internet protocol resources.Feel free to refer back when you read the conversation below.
Feedback for Namefi
Nick Johnson: Well, I haven't used the feature myself yet, but my general feedback is that it's outstanding to see it being adopted so quickly and to see you supporting it so thoroughly. My long-term feedback is that it thrives when others join the standardization effort and help us build and standardize more things. It would be really good to see you identifying shortcomings that affect your users and then helping us standardize solutions to those shortcomings.
What drove the creation of ENS?
Nick Johnson: I guess what I was saying is that I've always been interested in internet infrastructure ever since I started programming. When I joined the Ethereum community, my first thought was to identify the infrastructure needs that had been neglected and needed more attention. Naming, in particular, has always interested me. I realized that Ethereum didn't have any good built-in naming solutions, which seemed like a great shame. So, I started working on ENS almost immediately after joining the community because I saw that this need wasn't being met.
ENS Community Growth and ENS Utility Expansion
Nick Johnson: I think it's been an organic evolution, really. As we've expanded the usefulness of ENS, we've gone beyond the basic implementation and started to explore other potential uses. Its role as a Web3 profile, for instance, has become readily apparent, and we've focused more on that. This evolution has been driven by both our internal development and the emerging needs of the community
Defining Difference between Web2 and Web3 Naming
Nick Johnson: I think the defining characteristic of Web3 naming and Web3 in general is self-sovereignty and the ability to have control over ownership and use of names to a degree that simply isn't possible with traditional Web2 systems.
It's about building these systems as best we can while recognizing that the legacy internet doesn't stop existing just because we're working on this new thing.
We need to be prepared to embrace and extend existing technologies, as we have with DNSSEC, rather than taking the attitude that the internet started with Bitcoin. I think that's unproductive because all the foundational systems are built on top of existing ones. It's foolish to try and believe that we can do everything from scratch rather than, you know, I'm a big fan of incrementalism.
Why Building ENS on Top of DNSSEC?
Nick Johnson: Our attitude is that DNS is part of the global namespace. Existing DNS systems will continue to exist and need to be integrated.
How does gasless DNSSEC work with ENS names?
Nick Johnson: Gasless DNSSEC is the result of several technological development cycles in DNS.
The first was our original DNSSEC integration, which relied on proving results on-chain.
The second was CCIP Read, which enabled featuring data from off-chain.
Combining these two produced a system where you can fetch DNS records just the same, effectively making DNS an L2 to Ethereum.
At each stage of that process, we had standards written and received community feedback, which substantially improved the product. Additionally, security audits and the feedback from those audits have been invaluable. Victor I want to delve into that a bit more. As a builder, I'm personally very excited that Gasless DNSSEC has now been announced. Before this, if I remember correctly, a DNSSEC claim with gas would cost around $300 to $700, right? Nick Johnson: It depended a lot on your name because there are two main cipher suites used for DNSSEC.
One is RSA, which we support natively in Ethereum and is efficient to verify.
The other is ECDSA, which is not supported natively and has to be supported in EVM code, costing about 1 million gas to verify.
Most names these days use at least one hop with ECDSA, making it much more expensive in terms of gas. As a result, it could be very costly to import a name. Victor How early did you first think of including DNSSEC as a method to import DNS domain names? Nick Johnson: That idea originated less than a year after the launch of ENS. At the time, although the gas usage was substantial, gas was much cheaper, and so was ether. It seemed more practical then. As we developed it and prices went up, it became practical only for large integrations, such as with Coinbase. This emphasized the need for a better solution.
Non-technical Explanation for Gasless DNSSEC implementation on DNS
Nick Johnson: The structure is essentially the same, whether it be the original DNSSEC implementation or the new gasless implementation.
DNSSEC operates as a chain of trust.
Starting with the root, the top domain above all top-level domains, the key for that is publicly published and well-known. That key is used to sign records for each of the top-level domains with their own keys. Each of these keys is then used to sign records for the next domain down, and so on.
For any given DNSSEC-enabled domain, you can establish a chain of trust from the signature on the records you care about all the way up to the root, which is well-known. About a year after the ENS launch, we realized that all of this could be verified on-chain. We just needed to package the proofs correctly and send them in a transaction. A smart contract could then verify that those records are correct and determine the contents of the DNS record on-chain.
This would allow people to set a text record to claim a name. That's what we started working on and built not long after the ENS launch. The gasless implementation utilizes the same infrastructure but also integrates the advances of CCIP Read.
Previously, we verified the records when you claimed them on-chain, and anyone resolving a name relied on that previous verification.
Now, we verify it at the time of the read. Instead of fetching and submitting the records when they're set, when someone tries to resolve a name, their client or wallet consults a gateway that fetches the DNS records and returns a proof. This proof is then verified at resolution time. Victor In summary, DNSSEC provides users with a way to prove that they own certain domains. The text record is set by the rightful owner through the chain of trust established by DNSSEC. I have noticed that I would like to ask you a question about this technical direction as well. Nick, starting off with the gasless DNSSEC, users were able to not only claim a name on DNS using their DNS name, but they could also use it for their avatar if they wanted to.
They could resolve additional addresses like Bitcoin and other chains. Do you see the same functionality being supported in gasless DNSSEC down the road? I know there's a goal for ENS to support multiple chains. What’s the roadmap here? Or is it already supported? Nick Johnson: I mean, all of that is actually already supported now. The only distinction is that we haven't yet improved the user experience for it. Currently, you can use gasless DNSSEC to seek records other than your Ethereum address.
However, doing so relies on either setting a record on-chain or setting up your own custom resolver. Our current work in progress is to improve what we call the Extended DNS Resolver, which allows you to set those records directly in your text record.
At the moment, it only supports Ethereum addresses, but we're quickly working on extending that to all types of records. To be clear, this is purely a user-space innovation. Any user with sufficient technical know-how could do this. We're building it as a convenience to make it easier for people to use, rather than as core-level infrastructure that requires permission from the DAO, like the original gasless DNSSEC integration. Victor Yeah, that's very helpful because we are here to assist our users. If there is a gap on the ENS side, I know that you are developing the next version to support other chain addresses. We can help on our side to make it much easier for users to set those records correctly and would be happy to be the front-end again. We should be the first to support whatever you launch on our platform.
How is Gasless DNSSEC gasless? (One more time)
Nick Johnson: The key difference is that with the original version, you submit proof of your text records to the Ethereum chain at the time you want to prove them, and you have to pay gas for that verification, which then gets recorded on-chain. With the gasless version, whenever someone tries to resolve your name, their browser, client, or wallet consults DNS indirectly, fetches the record, and verifies it at runtime. So, no transaction is required, and therefore, no gas needs to be paid.
It's the DNS record and the DNS server that have to be fetched. There isn't a direct interaction with the registrar. However, what you said about interfacing with the Web2 world absolutely applies. The main challenge is communicating to users the tradeoffs involved. By doing this, they are reliant on the ownership of their DNS domain. They lose the guarantees that .eth provides in terms of guaranteed ownership and sovereignty over their name and instead rely on the guarantees provided by their registrar, which may be much weaker.
Challenge in Gasless DNSSEC Development
Nick Johnson: The original DNSSEC implementation was a significant technical challenge because we were trying to implement DNS record verification and DNSSEC in a way that had never been envisaged by the people who wrote it or by the developers of Ethereum. We were essentially gluing these two platforms together in a meaningful way that nobody had anticipated.
For the gasless version, it was largely an integration challenge. This time, we knew the two parts could work together; we just had to make some changes to ensure they integrated correctly and executed properly.
Beyond GoDaddy: Getting more clients and registrars to support Gasless DNSSEC
Victor Nick, we are very happy that gasless DNSSEC is now launched. You can use app.ens.domains to see your domain being resolved. Sean recently posted a tweet with a table showing how many different clients support resolving addresses using this new gasless DNSSEC from their DNS domains. Do you see any challenges or areas where the broader community could help support gasless DNSSEC in even more clients and registrars? What can we do together to achieve this? Nick Johnson:
I think this is an area where the community can be enormously helpful. We can reach out to wallet providers, apps, exchanges, and so forth to suggest they integrate ENS or improve their ENS integration to correctly support all the standards. However, there's a limit to our influence because, naturally, they'll see us as biased since we develop ENS.
When actual users from their community approach them and say the same thing, it tends to be taken more seriously. These are the people whose livelihoods depend on the products being built, and when they say, 'This is something we genuinely want, it carries more weight. Such feedback can be invaluable in ensuring that ENS gets deployed and supported as widely as possible.
Audience Q&As:
Page:
First, Nick, thank you for joining us. I've been focused on educating mostly Web2 domains, having been in the Web3 space for three to four years now. I wanted to ask you about gasless DNSSEC. I'm a fan and have been wanting to use my Web2 domains for some of these new Web3 purposes. What I can't figure out is how it fits into the three main reasons I might want to use 'Web3', a domain name: using it as a wallet address, resolving it to work with dApps in Web3 for that instant identity connection I control, and tokenizing for transfer—something I've been able to do with Namefile.
I'm trying to understand, Nick, where gasless DNSSEC helps with these three things and where it doesn’t, meaning I might still need to use a mainnet transfer. Does that make sense? In other words, is gasless DNSSEC applicable for everything, or just certain things?
Nick Johnson: Yeah, so essentially, the first two examples you provided can both be accomplished through genetic integration. However, tokenizing the domain will always depend on an integration like Namefi, which effectively takes custody of the domain as the registrar on behalf of and is responsible for transferring it when the token is transferred Page: Someone touched upon one drawback of transitioning a web 2 domain name to a web 3 domain name for content, which is that each time you modify your content, you might incur gas fees. I've always hoped that gasless DNSSEC would address this issue. Does it allow you to make your site more dynamic using web 3 builders and similar tools without constantly needing to pay gas for simple content updates? Nick Johnson: Yes, it absolutely can achieve that. It should be noted that our other Layer 2 solutions and off-chain integrations can also accomplish this. Effectively, this is something that CCIP Read enables independently, whether you're utilizing it through DNSSEC or through another Layer 2 or off-chain system. Victor Firstly, I'm glad you asked that question. I believe I asked Nick the same question earlier. If you didn't catch it a few minutes ago, I'll explain it in a less technical way. Imagine a billboard on the highway or anywhere else. Ownership custody determines who can write on it and what content can be displayed. This is akin to what's happening with gas units. Once ownership is established, anyone can be hired to create content for it. And doing so, without dealing with ownership, tends to be much cheaper