Why DNS Changes Deserve Team Approval
One wrong DNS record can take a site down or become a security risk. Learn why teams should review DNS changes, and how Namefi Proposals work.
- dns
- domain-security
- team-workflows
One wrong DNS record can take your whole site down, or worse, become a real cybersecurity risk for your entire team and your entire customer base. A DNS change is a small edit with a wide effect, so a second person should check it before it goes live.
Namefi Proposals add that check. One member proposes a change, two teammates review the exact diff, and Namefi applies the change after the second approval. The short demo below shows the full flow with sample data.
Watch the Proposed DNS Changes demo
A small DNS edit can stop a whole service
DNS sits in front of almost everything a domain does. Web traffic, email, and many login flows start with a DNS answer. When that answer is wrong, a healthy application can look completely broken.
Two well-documented incidents show the scale:
- AWS, October 2025. AWS traced a major disruption to a race condition in the DynamoDB DNS management system. The fault produced an incorrect empty DNS record for the regional endpoint.
- Slack, September 2021. Slack reported a 24-hour outage that came from its attempt to enable DNSSEC. Slack said that the outage affected less than 1% of its online users.
Neither incident came from a simple typo, and a review step would not automatically have stopped them. Both incidents show the same thing: DNS failures spread quickly, and they are hard to contain. Read our analysis of the AWS outage for the full story.
A wrong record can also become a security risk
An outage is visible. A security problem can stay quiet for a long time, and it can reach people outside your company.
Microsoft describes one common case. A record that points to a deleted cloud resource is a "dangling DNS" entry. In the Azure case that Microsoft documents, an attacker may claim that target and control what your subdomain serves. Microsoft lists these consequences:
| Risk | Who it can reach |
|---|---|
| Session cookie harvesting from visitors | Your customers and your staff |
| Phishing pages on a trusted subdomain | Your customers and your partners |
| Email received through MX records | Anyone who writes to that subdomain |
| A valid SSL certificate for the hijacked subdomain | Everyone who trusts the padlock |
Attackers also change records on purpose after they steal an account. In January 2019, CISA issued Emergency Directive 19-01 about DNS infrastructure tampering. Reporting on the directive quoted a warning that attackers had "redirected and intercepted web and mail traffic". See how DNSpionage worked and how domain hijacking actually happens.
So the cost of a bad record is not limited to the person who made it. The cost can reach your whole team and your whole customer base.
Important changes usually get a second reviewer
Software teams solved a similar problem long ago. GitHub lets administrators require a specific number of approving reviews before code reaches a protected branch.
Security frameworks use the same idea. NIST control AC-5 covers separation of duties, which addresses the potential for abuse of authorized privileges.
Review gives you three practical benefits:
- A second person catches mistakes. A fresh reader can spot a wrong address before it reaches users.
- One stolen account can do less through a proposal. A proposal needs approvals from other members before it applies. An account with direct edit access can still change records directly.
- The team keeps a record. You can later see who proposed a change, who approved it, and what changed.
Namefi Proposals add review to DNS
Proposals work inside a Namefi organization. Members whose role includes DNS access, such as Admin and Developer, can propose and review changes.
The rules are simple:
| Step | What happens |
|---|---|
| Propose | A member adds, edits, or removes one or more records, and nothing changes in DNS yet |
| Review | Other members see the exact diff and choose Approve or Reject |
| Self-review | The server refuses a vote from the proposer, and the proposer sees no vote buttons |
| Apply | Namefi applies the change after two approvals |
| Reject | One rejection ends the proposal |
| Expire | A pending proposal expires after seven days |
| History | Applied, rejected, expired, and failed proposals stay visible with their diffs |
Proposals have clear limits today
Team review reduces risk, but it does not remove risk. Plan around these limits:
- Direct edits still work. Proposals are a review workflow, and they do not block direct DNS edits. Agree as a team when to use each path.
- The approval count is fixed. Every proposal needs two approvals today, so your organization needs at least three members with DNS access.
- Reviewers get no notification yet. Tell your teammates when a proposal needs their attention.
- Review does not secure an account. Keep strong sign-in protection on every account that can reach your domains.
- A reviewer can miss a problem. Two people can approve a wrong value, so keep reviewing what your records point to.
Start with the records that carry the most risk
You do not need to route every edit through review on the first day. Start with the records where a mistake costs the most:
- A, AAAA, and CNAME records on your main domain and on your login subdomains.
- MX records, because they decide where your email goes.
- TXT records that control email authentication or prove domain ownership.
Then remove records that point to services you no longer use. Microsoft recommends adding "Remove DNS entry" to your decommissioning checks.
Sources and further reading
- Amazon Web Services — Summary of the Amazon DynamoDB service disruption
- Slack Engineering — What happened during Slack's DNSSEC rollout
- Microsoft Learn — Prevent dangling DNS entries and avoid subdomain takeover
- CISA — Emergency Directive 19-01: Mitigate DNS Infrastructure Tampering
- BleepingComputer — DHS issues emergency directive to prevent DNS hijacking attacks
- GitHub Docs — About protected branches
- CSF Tools — NIST SP 800-53 Revision 5, AC-5: Separation of Duties
About the author(s)
Fenwei Bian is a software developer in her thirties who spends her working hours in pull requests and her weekends with her hands in soil or sawdust. Years of open source on GitHub taught her that names are interfaces: a good one is clear, honest about what it does, and kind to whoever has to use it next.
She gardens because it rewards patience and punishes wishful thinking, and she does woodwork because a joint either fits or it doesn't. Both habits show up in how she writes about naming — measure twice, check the source, and don't sand over a rough spot and hope no one notices.
For Namefi she writes about how domain markets actually move, the practical trade-offs of tokenizing and flipping names, and picking a domain you'll still be glad you own in twenty years.