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:
Get PR reviewed and merged
Complete work on a generic DNSSEC gateway and get that reviewed and merged
Deploy DNSSEC gateway to CloudFlare
Deploy gasless resolver to Goerli and enable it for all DNS TLDs
Invite public testing
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.
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.
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.
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™ .
The process makes me wonder, are there other viable solutions to DNS/ENS import that wouldn’t require DNSSEC that are being discussed?
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.
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:
Only the recipient of the primary name can initiate the transaction to set the primary name.
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.
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
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!
.