[EP6.12] [Executable] Set resolver for .ceo TLD

DAO-Wide Active Proposal
1

description: Set the resolver record for the .ceo TLD

[Executable] Set resolver for .ceo TLD

Status Active
Voting Tally

Abstract

EP6.7 reconfigured the .ceo TLD, setting the owner record to the DNSSEC registrar contract. This allowed onchain claiming of .ceo 2LDs to resume, reclaiming control from a custom registrar that had been set by a previous owner of .ceo.

Unfortunately, this neglected to consider the necessary infrastructure for offchain claiming, which requires also setting the resolver record. As a result, a follow-up executable EP is required to set the resolver also.

To prove ownership of .ceo and their intention that we action this request, they have set a TXT record on _ens.nic.ceo to the address of the DNSSEC registrar, 0xB32cB5677a7C971689228EC835800432B339bA2B. This can be verified with the following command:

dig TXT _ens.nic.ceo

Specification

  1. Call setSubnodeOwner on the ENS Root contract at 0xaB528d626EC275E3faD363fF1393A41F581c5897, passing in the keccak256 hash of ceo and the address of the ENS timelock, 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7.
  2. Call setResolver on the ENS registry contract at 0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e, passing in the namehash of ceo and the address of the OffchainDNSResolver, 0xF142B308cF687d4358410a4cB885513b30A42025.
  3. Call setOwner on the ENS registry contract at 0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e, passing in the namehash of ceo and the address of the DNSSEC reistrar at 0xB32cB5677a7C971689228EC835800432B339bA2B.

Transactions

Address Value Function Argument Value
0xaB528d626EC275E3faD363fF1393A41F581c5897 0 setSubnodeOwner label 0xa695017707ee0c04095f723270b3c315654d16e337ad54039175a4b000894676
owner 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7
0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e 0 setResolver node 0x6871d4785070006a666d91b45c606e933e44f42b06ef5bda56431e78ce28553f
resolver 0xF142B308cF687d4358410a4cB885513b30A42025
0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e 0 setOwner node 0x6871d4785070006a666d91b45c606e933e44f42b06ef5bda56431e78ce28553f
owner 0xB32cB5677a7C971689228EC835800432B339bA2B
4 Likes
2

Apologies for the oversight that caused the need for this redundant proposal - entirely my own omission.

2 Likes
3

Of the proposed transactions, are transactions 1 and 3 not superfluous?

The owner of ceo in the ENS Registry is already the DNSSEC registrar.

If it were not, Transaction 1 calls through to setSubnodeOwner on the Registry anyway.

I think the call to setResolver is all that is needed here?

I don’t think this was your omission. Temp Checks provide an opportunity for DAO participants to debate and discuss proposed executables. No-one else noticed the oversight :expressionless:

4

Only the owner can call setResolver, and the DNSSEC registrar doesn’t do that outside specific circumstances (taking over a new name) that we can’t presently trigger. So we have to transfer it to the timelock, set the resolver, then transfer it back. This all happens atomically, so there’s no risk of any other transactions failing while it happens.

I did rather rush the last one through without much opportunity for comment.

2 Likes
5

Ah yes, makes sense. Thanks for the clarification.

6

This is now live for voting on Tally.

7

The simulation and tests of EP 6.12 can be found here. The proposal was simulated passing, executing, and asserting the difference between owners and resolvers.

This can be checked by cloning the repo and running:
forge test --match-path src/ens/proposals/ep-6-12/* -vvvv

1 Like