Suppose your DAO requires three of five signers to move treasury funds. Nobody gets to send the money somewhere new because they happened to be the first person awake.
Now look at the domain.
Can one contributor log-in to the registrar and change its nameservers? Can another edit DNS records with an API token? If so, you have approval rules for the treasury and a much looser arrangement for the website your users trust.
Your registrar doesn’t read your governance forum.
Where the Multi-sig Stops
A multisig enforces an approval threshold for the transactions it controls. It doesn’t automatically extend that threshold to a conventional domain registration, a DNS provider, or a hosting account. You see, your domain is already exposed through through multiple roles and entry points.
The registrar controls the domain’s nameserver delegation: which servers answer DNS queries for it. The DNS operator controls the records that point visitors toward your services. And these may be different providers, with different accounts and recovery procedures.
An attacker who gains sufficient authority at either layer may redirect visitors to a counterfeit application under your familiar domain. The fake interface can then ask users to sign malicious transactions or grant token approvals. And that means, your treasury multisig can remain intact throughout. The people losing money may be your users.
This is why “we use multisig” is an incomplete answer to a question about domain security. You need to know which action requires whose approval, and where that requirement is enforced.
Make the Approval Rule Operational
Start with the changes that can hand control to somebody else. Review each of these separately, because permission to make one change does not necessarily imply permission to make another:
- Nameserver changes: Who can replace the servers responsible for answering DNS queries for your domain? This can move DNS control to an entirely different provider.
- Critical DNS edits: Who can change the records that direct users to your application or deliver your email? Include access through both the control panel and API credentials.
- Domain transfers: Who can unlock the domain and authorize moving it to another registrar?
- Account recovery: Who can request a password reset, replace an authentication method, or ask support to restore access?
- Authorized contacts: Who can change the people or addresses the provider relies on to approve sensitive requests?
For each action, identify who can request it, who must approve it, and what actually prevents one person from proceeding alone. Ask the provider to explain how that requirement works in practice. A policy in a shared document will not stop a provider from accepting an otherwise valid login or API request.
Suppose your DAO requires two people to approve a nameserver change. If either administrator can log in and submit that change without the other, the account does not enforce your policy. You are relying on each administrator, and anyone who gains control of their account, to follow it voluntarily.
Separate named accounts and limited permissions help. They make it easier to restrict access and identify who performed an action. But several administrators do not necessarily constitute a quorum. Each may still have enough authority to act independently.
MFA addresses a different question: can the person signing in provide the required authentication factors? One person can hold both the password and the hardware key. That provides stronger authentication without requiring another person’s consent.
Check recovery as carefully as the normal workflow. If support can reset the account or release a lock on one person’s instructions, that route may defeat the approval requirement you thought you had. Ask specifically:
- Can one person replace the recovery address or remove an authentication factor?
- What evidence does support require before restoring access or releasing a lock?
- Do API requests face the same approval requirements as changes made through the control panel?
- If DNS runs at another provider, what prevents someone from changing records there independently?
There is an operational tradeoff. Requiring several people to approve an urgent repair can prolong an outage, particularly when the approvers are scattered across time zones.
Agree on the emergency procedure while everyone is available and the website is working. Define who can authorize which repairs, how the provider verifies those approvals, and who acts as a backup when a designated approver cannot be reached. Include a notification route that remains available if your domain or email stops working.
Then walk through the procedure with your team and provider. You want to discover an unreachable approver or an unsupported recovery step during the exercise, while you still have time to fix it.
Bring Domain Control Into Your Governance
DomainSure’s services give you several ways to strengthen control over your domains. Each addresses a different part of the problem:
- Multi-user role permissions: Give team members named access with permissions suited to their responsibilities. Review who actually needs authority to make critical changes.
- Hardware-key authentication: Strengthen account login security. A hardware key helps protect access, but one person holding that key can still act alone if their permissions allow it.
- DNS change notifications: Give your team visibility into changes that warrant investigation. Notifications help you respond; they do not substitute for approval before a change occurs.
- Account recovery and lock-release security: Address the procedures used to restore access or release protections. These deserve the same scrutiny as the normal login process.
None of these auThe next step is to establish which actions require multiple approvals and how those requirements will be enforced.
Our crypto and Web3 security paper describes working with DAOs to define a protocol for authorizing critical domain-account changes. That conversation should settle some practical questions:
- Which actions are covered? Specify whether the protocol covers nameserver changes, account resets, lock releases, changes to authorized contacts, or other sensitive operations.
- What counts as approval? Agree on who can approve a request, how many approvals are required, and how the provider verifies them.
- What happens during recovery? Define how the organization regains access when an authorized person or authentication device is unavailable.
- Where does the arrangement stop? If another provider operates your DNS, confirm its controls separately. A registrar-side approval requirement does not automatically govern changes made there.
The goal is to make your domain controls reflect the way your DAO intends to make decisions, and to know where that alignment still falls short.
Contact DomainSure’s service team to request a free Domain Threat Assessment and ask us to review who can change your domain. Bring your treasury approval policy along so we can discuss which requirements your domain providers can enforce, where one person can still act independently, and what needs to change.
Apply for a Domainsure Invite
Get a Free Domain Health Check
Due to high demand: allow up to 24 hours for report delivery.
