Allow DNS name owners to use their existing domains in the web3 ecosystem for free.
<aside> 🎉 Jan 24, 2024 update: Gasless DNSSEC is now live on mainnet!
</aside>
Enable DNSSEC on any eligible domain like gregskril.com
Set the following DNS record
| Type | Name | Value (this format might change) | |
|---|---|---|---|
| Format | TXT |
@ |
ENS1 <extended-resolver-address> <eth-address> |
| Example | TXT |
@ |
ENS1 dnsname.ens.eth 0x179A862703a4adfb29896552DF9e307980D19285 |
Done! Now anybody would be able to type gregskril.com into web3 applications that supports ENS, and it would resolve to the provided Ethereum address. Test it here
Note: the ExtendedDNSResolver is just one example of a resolver that can be used - and we recommend starting there for simplicity. Any compliant offchain resolver would also work.
Every name in the ENS registry (a smart contract on Ethereum) belongs to a TLD, either our native .eth or any DNSSEC-enabled ICANN TLD.
Each name in the registry specifies a resolver (another smart contract) which either stores the data for the name itself, or defers that responsibility elsewhere. This deferral process is powered by CCIP Read, an Ethereum ecosystem standard created by Nick from ENS Labs.
Historically, DNS names like example.com had to be imported into the ENS ecosystem by submitting a DNSSEC proof to Ethereum, which is expensive and inefficient. In this update, we’re implementing CCIP Read at the DNS TLD level within ENS so that a name’s data can be fetched directly from DNS TXT records at query time.
No fundamental changes to a DNS server are required. Crypto-enabling DNS domains with ENS is a matter of simply enabling DNSSEC and setting a TXT record in the format described above.
That being said, the TXT record format can be confusing for users (especially as we develop more advanced resolvers), so a separate UI element that abstracts this away is recommended.
Some food for thought on how that might be accomplished: