Every couple of years a research report lands that gets DNS security mostly right, and then points everybody at the wrong fix.
The latest is Enterprise Management Associates’ DDI Directions 2026. On the diagnosis, it’s hard to argue. DNS is under-secured, most of the people running it know it, and the attacks are getting nastier. All true. we’ve been saying versions of this since before “DDI” was an acronym anybody put on a slide.
Then comes the prescription: Put your network engineering team in charge of DNS security, because they own the DDI stack and understand it better than the cybersecurity folks do.
And that’s where we get off the bus.
You cannot reorganize your way to DNS security. Moving the box on the org chart from one team to another does precisely nothing about the layer that neither team controls:
The domain registrar.
That is where the catastrophic failures actually happen. EMA’s report does not mention it once.
How the Report Frames DNS Ownership
Let me lay out their case in their own framing, because we want to argue against the strong version, not a strawman.
DDI Directions 2026 finds that only 28% of DDI experts believe their DNS is completely secure, that 86% have seen evidence of AI-enhanced DNS attacks, and that enterprises trust generalist security vendors (55%) over DNS specialists (33%) to protect it. The headline number: 40% of enterprises suffered a breach in the last two years that traced back to mismanagement of DDI technology. In EMA’s words, “it wasn’t the security measures that failed.” It was the design and day-to-day management of DNS. Their recommendation is to hand DNS security to the network engineering team that runs DDI.
DNS is a Control Plane
Most of it is correct, and I’ll say so plainly.
DNS is a control plane. Generalist security vendors are usually the wrong call (We will happily endorse anything that says “go to the specialists”). And yes, far more damage comes from how DNS is managed than from some exotic zero-day nobody saw coming.
But notice what never appears in any of those findings: Registrar.
EMA is running an argument about who should drive the car. We’re telling you the title to the car is sitting in a filing cabinet at a company you don’t work for, and the lock on that cabinet is a support rep having a bad day.
The Control Plane is Higher than the Report Admits
Walk it from the top. The registrar account authorizes the nameserver delegation. The nameserver delegation points at a DNS operator. The operator serves the zone. The zone is the records your users actually resolve.
Whoever controls the registrar account controls every layer beneath it. That includes the work of whichever internal team you just put in charge. The best-run DDI shop on the planet is still downstream of that account, and if the account goes, their firewalls and their IPAM integration and their lovingly automated zone management go with it.
This is the part the “who owns DNS” debate keeps skating past. You can give network engineering full ownership of everything inside the house and it changes nothing about the front door, because the front door is keyed by a third party.
Both Teams are Arguing Inside a Fence. The Threat Walks Around
So, the report frames network engineering on one side, cybersecurity on the other, tugging over who gets DNS. Fine. Now draw the enterprise perimeter around them, because that is where both of those teams live.
The registrar sits outside that perimeter.
No RACI chart you draw reaches a vendor you don’t manage. You cannot assign an internal owner to a registrar that can be socially engineered by someone who emails their support queue a convincing-looking court order on a long weekend (I have watched this happen, to domains that were never named in the order). You cannot org-chart your way around a registrar that decides your crypto project violates some nebulous “community standard” and parks your domain. You cannot reorganize your way out of a vendor that simply has an outage.
About that 40%
Here’s the sleight of hand in the headline stat. “Mismanagement of DDI technology” reads like an internal process failure, the kind you fix with better runbooks and a clearer owner.
In the real world, the DNS disasters that make the news are registrar account takeover, nameserver hijacking, and domain slamming (transferring the domain out from under you entirely). MyEtherWallet. ETH.limo. ETH.link. The list of Web3 projects that got teleported to a phishing front-end through the naming layer is long and it keeps growing.
Look at how those attacks actually run, step by step, and ask the question EMA never asks: which of these steps can the internal DDI team even see?
Credential theft against the registrar account: no.
Account takeover: no.
Nameserver re-delegation: no.
By the time malicious DNS is being served and wallets are draining, the breach is already over. The team you empowered was watching a layer the attacker never had to touch.
It wasn’t the security measures that failed, EMA says. On that we agree. It was the layer they declined to talk about.
“Go to the experts” is right. Now define expert.
The one recommendation we’ll take from the report is that specialists beat generalists. Of course they do.
But EMA’s idea of a DNS specialist still stops at DNS firewalls, DDoS scrubbing, and IPAM integration. Useful, all of it. None of it touches the control plane.
Real control-plane security lives at the registrar and the delegation: registry lock (the kind enforced by the registry itself, with out-of-band human verification, not the one-click transfer lock in your control panel), DNSSEC so responses can’t be silently forged, the ability to fail over nameserver delegations in real time when a provider falls over, out-of-band governance on who can authorize critical account changes, and proactive credential monitoring so you find out your team’s password is in a dump before the attacker does.
That is the expertise that matters, and it is not the expertise EMA is measuring.
What to Do Instead
Put the right team in charge. I’m not against that. It’s necessary. It is nowhere close to sufficient.
Security that stops at your perimeter stops short of the one thing that can erase you from the internet on a Friday night. Before you spend another planning cycle deciding which internal team holds the DNS keys, find out who holds the registrar keys, and whether that vendor is built to resist a determined attacker or just to close the support ticket as cheaply as possible.
Harden the control plane first. Then argue about the org chart.
Mark Jeftovic wrote a whole book about this in 2018. The naming-layer weaknesses haven’t changed since. The only thing that went up is the amount of money sitting behind the front door.
Not sure who holds your registrar keys, or how hard they’d be to take? Start with a free Domain Threat Assessment and find your blind spots before someone else does.
Download the free white paper: Domain & DNS Security for Crypto, DeFi and Web3 Platforms.
Apply for a Domainsure Invite
Get a Free Domain Health Check
Due to high demand: allow up to 24 hours for report delivery.
