Update on gasless DNSSEC implementation

I’m pleased to announce that I’ve completed work on the first stage of the new resolver contracts for gasless DNSSEC integration. This will make it possible for anyone with a DNS name to ENS-enable it by setting DNS TXT records, with no onchain gas fees whatsoever.

The pull request, which is currently open for review, is here. More details on the format and capabilities are in the PR description.

Next steps:

  1. Get PR reviewed and merged
  2. Complete work on a generic DNSSEC gateway and get that reviewed and merged
  3. Deploy DNSSEC gateway to CloudFlare
  4. Deploy gasless resolver to Goerli and enable it for all DNS TLDs
  5. Invite public testing
  6. Deploy to mainnet

I anticipate the gateway being ready in the next couple of weeks, at which point we can proceed with a test on goerli.

Additionally, we will be working on developing a custom resolver implementation that permits record content to be resolved from DNS. Without such an implementation, the implementation above permits setting an ENS resolver for a DNS name without paying gas fees, but gas fees will still be required for setting records. After implementing a custom resolver, it will be possible to specify the contents of ENS records inside a DNS TXT record, making it possible to fully configure a DNS name for ENS integration with no gas fees whatsoever.


If this means what I think it means it could be a game changer! Hats off to those involved.

Why this is a big deal?

The use case here is to allow Wallets/Exchanges/Companies etc to give out ENS names that are not .eth but their DNS names.

When DNSSEC is integrated by supporting DApps, Wallet address can be resolved even if a user keys in a DNS name.

Basically making Coinbase’s cb.id custom work more standardised so more organisations can adopt and give away ENS names.

Do correct me if I am wrong. Cheers!

1 Like

DApps don’t need to explicitly support DNSSEC. They just need to:

  • Not have a list of TLDs that are acceptable (eg, just .eth)
  • If the domain uses this new gasless functionality, support CCIP-Read and wildcard resolution.

Can we use CCIP-Read to create gasless primary DNS names as well? The gateway could just search for all the names that point to an address, and if one of the names has a txt record with a signature set for the primary name, it could assign that name as the primary name.

Unfortunately there’s no way to search for all names that point to an address.

Ok, then it could just be a web app, wherein a signature is saved as a txt record in a DNS name and then the owner uses a feature of the app to alert the gateway. The gateway would then verify the signature, and ‘register’ the DNS name and the address for reverse resolution using ENSIP-10 and CCIP-Read.

1 Like

Coincidentally I recently experimented trying to import an emoji DNS into ENS.

If I understand correctly there is a ENS emoji/CF punycode data issue when confirming DNSSEC.

Any chance this update happens to include (or could include) a fix for this issue?

On a separate note, I own some DNS with a ccTLD that does not currently support DNSSEC. After a few months of hounding them they have informed me they will add DNSSEC support and made me part of the test group starting soon™ :rofl:.

The process makes me wonder, are there other viable solutions to DNS/ENS import that wouldn’t require DNSSEC that are being discussed?

1 Like

Adoption 1 – 0 Distraction

This would allow the service to censor your reverse resolution, and if you ever set more than one record, choose which to serve.

We’d need some kind of trustless, verifiable consensus mechanism that allows everyone to come to agreement on which entry is most recent. :thinking:

1 Like

The trust would be the trust that the DAO places in the gateway. I believe currently all CCIP-Read setups are required to trust the gateway. I heard that it might be possible with rollups to have a system where the CCIP-Read resolved records could be verified somehow on L1, but I am not sure how this would work.

It really is the same level of trust that we currently have with metadata. The DAO decides which server to trust, but the server still needs to be trusted.

I don’t think this is really a problem. The gateway would only have one primary name for each address, and it would require a request to change the record, including the DNS name to check for the txt record. If other txt records were set, then they would not be detected by the gateway at all.

1 Like

No; the point of CCIP read is that it lets you do things with no additional trust assumptions. So a CCIP-read gateway to Optimism allows verifying the optimism proofs on read; no additional trust assumptions over those Optimism makes. The DNSSEC gateway allows the caller to verify DNSSEC proofs; no additional trust assumptions over and above DNSSEC itself. In either case the most a gateway can do is deny service.

This would be quite different - a service could lie about a user’s current reverse record, returning any previous one, or claim there is none at all.

The gateway could choose to accept the request and then still selectively serve the old record, though.

Still, the proposed CCIP-Read based reverse resolution system does not offer a lower level of trust than the existing metadata service. Also, the client would verify the forward resolution of the name to ensure it matches the wallet address of the user, eliminating the risk of spoofing.

Currently there are two significant challenges associated with setting primary names at present:

  1. Only the recipient of the primary name can initiate the transaction to set the primary name.
  2. There are gas costs involved in setting the reverse resolution and primary name.

I believe, it is necessary to find a way to allow primary names to be set for free, not only by end users but also by other entities such as Coinbase in the case of cb.id.

1 Like

The metadata service is for just that - NFT metadata. Reverse resolution is not metadata, it’s an essential part of ENS and needs to remain trust-minimised.

When it comes to cb.id domains or other DNS domains that are controlled by a centralized authority, it doesn’t make sense to have a higher level of trust for reverse resolution than forward resolution. Reverse resolution domains are verified by the client as well, so they are all verified by default.

I am also interested in hearing the ideas about primary name resolution but I think it’s a bit off topic because the change in primary name requires changes on reverse resolution contracts, not just the DNSSEC resolver.

I created a topic Future of the Primary ENS Name so I suggest you continue the conversation there and focus this topic related to the gasless DNSSEC implementation


oh, so happy to see the news; looking forward to the test and deploy.

1 Like

Great work! I have several questions:

  1. Any update of testnet deployment?
  2. If it’s gasless for DNS domain, is it going to be gasless for DNS subname creation too?
  3. What’s the frontend plan for this? I am thinking about building the subname creation frontend for this if the answer for question 2 is true

I hope to have this ready for testnet by the start of next month.

Yes; those subnames will be created in DNS, not in ENS.

Since names will all be managed via DNS, any kind of UI will require operating a DNS server. While not out of the question, in the short term a tool that generates TXT records for you to set manually seems more viable.


I’ve been looking forward to gasless subdomains for sometime… first thing will be creating my wallet.james.com & vault.james.com — then use this with SIWE (and wordpress plugin) and mass adoption here we go!