The topic of using L2 to make DNS domain claims cheaper has been discussed on several occasions, such as here and here.
A solution that seems doable would be to deploy to e.g. Optimism L2 a DNSRegistrar contract that inside claim invokes ens.setSubnodeOwner on the L1 contract via crossDomainMessenger.sendMessage.
Is there any active development on such a solution?
As a different approach to DNS imports, ENS Labs is working on an entirely gasless DNSSEC implementation that utilizes CCIP Read.
This means that any DNSSEC-enabled DNS name (most TLDs) will be able to function as a normal ENS name by simply setting a few TXT records. This is expected to be deployed to a testnet in Q3, so in the next few months.
Latest info here: ENS Town Hall Q2 2023 - YouTube (timestamp 11:35)
Thanks @gregskril, that’s great! Following your reply I did some research and discovered @nick.eth’s tweet and the ccip-read-dns-gateway repo. So if an off-chain service (e.g. Etherscan) wanted to query ENS to resolve a DNS name to an Ethereum address, the ENS contract would raise a OffchainLookup error which would then result in the HTTPS gateway being queried, which would query the DNS system using the same system used today by the DNS oracle during the claim process (thus resulting in the same level of trust.) But what if a contract wanted to resolve a DNS name to an Ethereum address, would that be covered?
Nice searching 
To my understanding, no – the contract wouldn’t be able to do anything after reverting with OffchainLookup. External HTTP requests are required to fetch data from a gateway.
The gasless DNSSEC implementation will look basically the same as an offchain name today. Take ensiscool.cb.id for example. I’m guessing that trying to resolve this name in a contract wouldn’t work because the ensiscool part doesn’t exist onchain at all, even though cb.id is imported via the DNSRegistrar.
Out of curiosity, what use case are you thinking about?
cc @taytems who has spent more time working with offchain names in smart contracts than most - please correct me if I’m wrong here
It’s possible to do write calls with CCIP read - the final step is a transaction instead of a call. But, you would incur the entire gas cost of verifying the result onchain, which may be substantial.
Thanks @gregskril. A use case could be to restrict a function to be callable only by the owner of example.com.
Thanks @nick.eth.
So the way it would work would be that for a DNS name that has never been imported on-chain, Resolver.addr would revert with a OffchainLookup encoding the URL of the gateway… but also encoding instructions to a client of how to (optionally) call proveAndClaim in order for similar calls to not revert with OffchainLookup in the future, correct?
That’s pretty neat, although it means that there is still scope for the original L2 suggestion, correct? Thanks.