Update on gasless DNSSEC implementation

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!


This is going to be awesome.


:saluting_face: Beta testers standing by


I would be happy to be one of the testers on a testnet.


Is there any docs/ENSIP for this?? :pray:


@nick.eth @gregskril Is the code for the DNSSec Oracle gateway (at https://dnssec-oracle.ens.domains/) open source? I can’t seem to find it.

1 Like

Yep! Here it is


I got a heap




Subdomains like australia.bilby.org/news should be gasless for sure

Maybe not though. They’re accounts created and the DAO is not responsible for gwei fractions imposed on transactions such as account creation

But tagging gwei - say colored coins - that’s a very cool concept too.

Excuse me, this was rushed and so forth

1 Like

how’s this going?

It’s coming along - a version is deployed to Sepolia testnet and the team is working through the last few bugs. I’ve written a quick doc on how it works and how you can test it here.


Is it finally compatible with IDNA domains?
@ENSPunks.eth was trying to import his short emoji domains for long time but current DNSSEC oracles/contracts & API used by UI couldn’t handle that…

@raffy saving us from extra hard work as always… :vulcan_salute: