DNS governance: the four ways DNS estates fail

Most DNS estates aren't managed. They're accumulated. Records get created for good reasons, the projects behind them end, and nothing reconciles what's published against what's still true. Whoever inherits the estate inherits every decision made by people who have since moved on, usually with no documentation and no way to tell which records still matter.

That accumulation fails in four specific ways, each with a different cause, a different cost, and a different way of being found.

Every one of these starts the same way. Someone creates a record for a good reason, the project it supported ends, and nothing reconciles the record against reality afterward.

Most DNS estates work like a closet nobody opens. Everything's in there, the door shuts, and as long as mail flows and the website loads, nobody has a reason to look. Then someone needs one specific thing, opens the door, and finds out what's actually been accumulating.

For years that was tolerable, because nothing told you otherwise. The frameworks security teams measure against were built around outcomes rather than mechanisms. NIST CSF asks whether you manage assets. NCSC CAF asks whether you understand your systems. Neither names DNS records as an asset class with its own hygiene requirements, so DNS governance stayed an unwritten discipline that good teams did and everyone else deferred.

That changed across three years and four documents, most of them European. The EU wrote detailed technical requirements for the organizations that run DNS infrastructure, ENISA turned those requirements into implementable guidance with evidence examples, and NIST revised its DNS deployment guide for the first time since 2013. Between them they moved DNS hygiene from unwritten good practice to something you can be asked to evidence.

This guide covers what those documents actually require, who they bind, the four ways DNS estates fail in practice, and a five-stage framework for governing an estate you can't fully see. It's written for the teams who inherit large domain portfolios across multiple registrars and providers, where nobody built the estate they're now responsible for.

Two of the four failure modes have already been covered in depth, and this guide links to both rather than repeating them. Start with dangling DNS: how to find and fix it before takeover for what OWASP and AWS say about records left pointing at deleted cloud resources, and how open zone transfers expose your internal network for what two real zones handed over in a single query.

Two things about that sequence are worth pulling out. The first is the direction of travel. In 2022 the EU set an obligation. By 2024 it had specified the technical requirements. By 2025 ENISA had published what evidence of compliance looks like. Regulators moved from "manage your risk" to "here is the requirement and here is how you demonstrate you met it." DNS was named explicitly at every step.

The second is that NIST arrived independently and reached similar ground. SP 800-81r3 isn't a response to NIS2, it's a US standards body revising thirteen-year-old guidance. That two processes on different continents both landed on DNS hygiene in the same window says something about the problem rather than about either regulator.

This is where most coverage of NIS2 and DNS gets sloppy, and the distinction matters if you're deciding what your organization has to do.

NIS2 is a directive, not a regulation, so it takes effect through each Member State's own transposing law rather than binding companies directly and identically across Europe. Articles 2 and 3 set out the 18 sectors and the size thresholds for "essential" and "important" entities, but there are exceptions built into that test, and Member States can also designate specific entities as in scope regardless of size. Article 21's risk-management obligations are outcome-shaped, and DNS sits inside them as part of network security and asset management rather than as a named line item. What that means in practice depends on how your national law transposes it, so the sector-and-size rule of thumb is a starting point, not a final answer.

Implementing Regulation 2024/2690 binds a specific list. Its detailed technical requirements apply to DNS service providers, TLD name registries, cloud computing providers, data centre providers, CDN providers, managed service providers, managed security service providers, online marketplace, search engine and social network platforms, and trust service providers. Registrars aren't named as a standalone category in this Annex, they can still fall under NIS2 obligations through national transposition, but that's a separate legal basis, not this Regulation's Annex. If you're an enterprise running your own domains, this Regulation does not impose its Annex requirements on you directly. It very likely binds several of your suppliers. ENISA's technical implementation guidance is the practical companion, including mapping tables to European and international standards.

NIST SP 800-81r3 is voluntary guidance and speaks to everyone. No enforcement, no scope test. It's a useful technical benchmark alongside applicable law, contracts, and sector requirements, including the kind of document an auditor or a customer's security questionnaire is likely to reference when asking how you run DNS, precisely because it applies regardless of sector or geography. NIST posted potential updates and errata to the publication in July 2026, so check the live page rather than a cached copy before citing specifics. For a walkthrough of what the revision actually says, from protective DNS through to authoritative server hardening, read Ivan Ristic on NIST's secure DNS deployment guide rather than a summary here.

The practical read for most enterprises: you're not directly in scope for CIR 2024/2690's technical requirements, while NIS2 itself may or may not apply depending on how your country has transposed it. NIST SP 800-81r3 is the one document in this list you can act on today without waiting on a scope determination or a transposition deadline.

The most common failure and the least dramatic. DNS stops resolving correctly, and because it usually stops resolving correctly only sometimes, nobody catches it.

• Lame delegations happen when a parent zone's NS records point at a nameserver that isn't authoritative for the child zone, or doesn't answer for it at all. The delegation is written down. The server behind it isn't holding up its end. Resolution then depends on which nameserver a resolver happens to try, so the domain works for some people and returns SERVFAIL for others. Both outcomes are correct behavior. Only one is visible to whoever is testing.
• Orphaned records point at infrastructure that no longer exists. A server was decommissioned, a load balancer was replaced, a service was migrated, and the A or CNAME record stayed behind. Sometimes the record simply fails. Sometimes the address gets reallocated to a different tenant, and the record now points at somebody else's infrastructure.
• Partial resolution failures are the hardest to catch, because they defeat the way most monitoring works. A check that asks "does this domain resolve" from one vantage point, on one resolver, gets a clean answer. Meanwhile a subset of users hit a nameserver holding stale data, or a resolver that validates DNSSEC when yours doesn't, or a path where one of several NS records is dead. The failure is real and reproducible, just not from where anyone's looking.

The reason this category persists is that DNS is designed to be resilient. Redundancy means one broken nameserver out of four usually doesn't cause a visible outage. It causes a slightly slower, slightly less reliable service that degrades quietly and never generates a clear enough signal for anyone to investigate.

A zone transfer, or AXFR, is how a primary nameserver replicates a full zone file to a secondary. Necessary, normal, and dangerous when it isn't restricted, because a nameserver that hasn't been configured to limit transfers to trusted IP addresses will hand the entire zone to anyone who asks for it.

One query returns every hostname in the zone, with addresses. No scanning, no subdomain brute-forcing, no guesswork. In estates we've reviewed, that has meant internal naming conventions, voice infrastructure, development environments sitting inside production zones, and close to complete network maps returned in a single response.

The pattern worth knowing: parent zones are usually locked down, because that's the zone people remember to check. Delegated subdomains, handed to a different team or standing up a specific product, run their own configuration and get audited by nobody. We covered this in detail, including what two real zones actually returned, in how open zone transfers expose your internal network.

A dangling record points at a third-party service after the service has been decommissioned. If the name behind that record can be claimed again by someone else, the domain goes with it.

The mechanics are simple enough to be unglamorous. A team stands up a campaign site on a website builder, a storage bucket, or a cloud service, points a DNS record at it, and the project eventually ends. The service goes away. The record doesn't, because creating a record is a planned act and removing one is nobody's specific job.

What turns a dangling record into a takeover is the platform on the other end of it.

During a client engagement we ran DNS reporting across a domain estate, checking what the records actually pointed at against what anyone still working there believed they pointed at. One domain had been set up years earlier for a marketing campaign, with an A record resolving to a third-party website builder. The campaign had ended and the site was gone. The record was still there, still resolving, apparently untouched since the project wrapped.

We tested whether the platform would let someone else claim it. It did. No DNS TXT challenge to prove we controlled the zone, no file to place on the domain, no check that the domain had clearly been configured by somebody else first, and no notice to the original owner. The platform treated the DNS record itself as sufficient evidence of intent, which is the assumption the whole failure rests on. A record pointing at a service says nothing about who is allowed to claim what sits behind it.

Within the same afternoon the domain was bound to an account we controlled and serving a page we had written, at the client's real hostname, over their real domain, with no certificate warning and nothing visibly wrong. A visitor typing that address, or following a link from an old campaign email, would have had no reason to doubt it.

We reported it the same day. Once the finding was confirmed internally the DNS record came down that evening, and the exposure closed with it. The vulnerability had existed for as long as the record had, likely years. Finding it, proving it, and closing it fit inside a single afternoon. The hard part was never the fix.

That's what makes takeover more serious than the other failure modes. A leak gives an attacker information. A takeover gives them a working, trusted delivery channel. Content served from a domain a visitor already trusts doesn't trigger the instincts a lookalike domain does, which makes credential harvesting, malware distribution, and search traffic hijacking straightforward rather than difficult.

Cloud providers are candid that they don't close this gap for you. AWS documents that many services let a new customer claim a previously used resource name, that there's no universal domain-verification mechanism across services, and that its incident response teams see attackers actively scanning public DNS for records pointing at resources that no longer exist [5]. OWASP treats it as an operational problem and recommends inventory, removing records before the resources they depend on, and watching for the provider error strings a dead resource returns [6]. Both are right and both put the work on you. For the detail on finding and fixing these records, see dangling DNS: how to find and fix it before takeover.

The failure mode that survives audits, because everything reports green.

Broken DNSSEC is the clearest case, and the failure is asymmetric. A signed zone with expired signatures or a DS record that no longer matches the current key fails validation loudly, which is DNSSEC doing its job even though it presents to users as an unexplained outage. The quieter failure is a zone that looks signed in every review but where validation isn't actually happening anywhere in the path. You get the reporting posture of DNSSEC and none of the protection. Our guide on NIST's DNS deployment guidance covers deploying DNSSEC properly in the first place.

A published TLSA record is not, by itself, a DANE deployment; it is usable for DANE only when the DNSSEC chain validates securely. For SMTP, an insecure TLSA result is treated as pre-DANE opportunistic TLS, not authenticated DANE.

Inconsistent NS and SOA records mean your nameservers disagree about what your zone contains. If the NS set at the parent doesn't match the NS set inside the child zone, resolvers can reach servers you no longer consider authoritative. If SOA serial numbers differ across your nameservers, they might be serving different data, and which answer a user gets depends on which server they reach. Both conditions are invisible to a check that queries one nameserver and gets a valid response.

What unites this category is that the controls report success. You can hold a clean scan result, a signed zone, and a DANE record, and still have none of the protection any of those imply.

Two things worth pulling out of that mapping.

Lame delegation appears twice, in two different failure modes, and it's the clearest example of why the taxonomy is useful. Section 3.2.1 treats it as an availability problem, where a delegation pointing at a non-existent server makes a child zone unreachable or intermittently accessible. Section 3.6.2 treats the same misconfiguration as a hijacking route, where a subdomain delegated to a DNS-hosting provider whose contract has lapsed can be taken over by a threat actor contracting with that same provider. One misconfiguration, two entirely different outcomes, and most teams only look for the first.

Zone drift and zone thrash, in section 3.2.2, are the named forms of the inconsistency problem. Set the Refresh and Retry values in your SOA record too high on a frequently changing zone and your secondaries serve stale data. Set them too low and you generate needless transfer load on both primary and secondary. Both degrade service without producing an outage anyone can point at.

Everything downstream depends on this, and it's where most programs quietly fail. The goal is total coverage: every domain, zone, and record, across every registrar, DNS provider, cloud account, and certificate authority, whether or not the team that created it still exists. The trap is building the list from institutional memory, because the records that cause incidents are precisely the ones nobody remembers. Domains inherited in an acquisition and never migrated. Subdomains delegated to a team that has since reorganized. Campaign sites stood up by marketing without a ticket. A list assembled by asking people what they own will be confidently wrong, and it will be wrong in exactly the places that matter. Our blog on dangling DNS covers what happens to the records that never make it onto anyone's list.

Once you know what exists, define what good looks like so that deviation becomes visible. That means recording which registrars and DNS providers are sanctioned, which cloud address ranges and certificate authorities you expect to see, what your email authentication posture should be on each sending domain, and which zones are signed with DNSSEC. The point is comparison. An unauthorized nameserver change and a planned migration produce identical DNS events, and only a baseline tells you which one you're looking at. Estates without one aren't blind to change, they're blind to which changes mean anything.

Diff the live estate against the baseline continuously, then classify what comes back. Roughly 1% of names in a large estate change on any given day, which in a 37,500-record estate is around 375 events daily. Raw change feeds at that volume get ignored within a fortnight, which is worse than having no feed at all because it produces the appearance of monitoring. Classification is what makes it operable: separating routine provider-side churn from a record that has started pointing somewhere it shouldn't, and suppressing the expected so the unexpected has somewhere to surface.

Measure the estate against NIST SP 800-81r3, using the mapping above to turn each failure mode into a set of checks. Re-check daily rather than periodically, and track the pass rate over time rather than treating each scan as a discrete result. A single clean scan tells you about one moment. A pass rate trending downward over six weeks tells you the estate is drifting, which is the finding you actually want, and it arrives long before anything breaks.

Tier the estate so the model stays sustainable, and tier the changes as well as the assets. A nameserver change on a domain carrying customer authentication traffic is not the same event as the same change on a parked defensive registration, and treating them alike guarantees the important one gets lost. Cross-reference change against open issues, so a record that changes while already carrying an unresolved finding escalates rather than joining a queue. Programs that grade everything as equally critical collapse under their own alert volume within a quarter.

The jump that matters most is tier 2 to tier 3, because that's where detection stops depending on someone deciding to look.

Work through this against your own estate. Anything you can't answer confidently is a finding in itself.

• You can produce a list of every domain your organization owns, across every registrar
• That list includes domains acquired through mergers and acquisitions
• You know which DNS provider hosts each zone
• You can list every subdomain delegated to a nameserver you don't control
• Every zone has a named owner who still works at the organization

• Every NS record in every parent zone points at a nameserver that is authoritative for the child zone
• SOA serial numbers match across all nameservers for each zone
• The NS set at the parent matches the NS set published inside the child zone
• You test resolution from multiple resolvers and geographies, not one

• Zone transfers are restricted to named secondary IP addresses on every nameserver
• You have tested AXFR against every delegated subdomain, not just the parent
• No zone contains hostnames that reveal internal naming conventions or non-public infrastructure
• Development and staging environments do not sit inside production zones

• You can list every DNS record pointing at a third-party SaaS platform, cloud service, or storage bucket
• Removing the DNS record is a required step when decommissioning any third-party service
• You know which of those platforms verify domain ownership before allowing a domain to be bound
• Someone reviews these records on a schedule rather than on incident

• You know which zones are signed with DNSSEC and which are not
• Signature expiry is monitored, not assumed
• Any zone publishing TLSA records for DANE is DNSSEC signed
• DS records at the parent match the current keys in the child zone
• You have tested that validation actually fails when it should

• A baseline exists defining sanctioned registrars, providers, cloud ranges, and certificate authorities
• Changes to NS, MX, and TXT records generate an alert
• The estate is tiered by importance rather than treated uniformly
• Someone is accountable for DNS hygiene as a named responsibility, not as an implied one

The stage that stops most programs is the first one, because everything downstream depends on knowing what exists. Cloud-native configuration checks are useful and single-account by design. Open-source scanners cover more ground but only run when someone remembers to run them. Neither covers an estate spread across several registrars, multiple DNS providers, and cloud accounts belonging to teams who don't report to security.

Red Sift ASM builds that inventory by connecting directly to your registrars, DNS providers, and cloud accounts rather than relying on a list someone maintains. It monitors DNS and DNSSEC configuration across the estate continuously, flags dangling records and claimable resources as they appear, and validates DANE configuration, which means the failure modes in this guide surface as findings rather than as incidents.

• [1] Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union
• [2] Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024
• [3] NIS2 Technical Implementation Guidance
• [4] Secure Domain Name System (DNS) Deployment Guide, NIST SP 800-81r3
• [5] Threat Tactic Spotlight: Subdomain Takeover
• [6] Subdomain Takeover Prevention Cheat Sheet