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!
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…
Beta testers standing by
