High-Risk "DNS Lame Delegation" Attack Exposed: Numerous Corporate Domains at Risk of Hijacking

In March 2026, NIST released SP 800-81 Rev. 3—the first major update to its DNS security guidelines since 2013. This document elevates an issue long dismissed by IT and operations staff as a "minor configuration error" to the status of a high-risk, enterprise-level attack vector: "Lame Delegation" (also known as "dangling delegation" or the "Sitting Ducks" scenario).

Around the same time, Infoblox uncovered a large-scale malicious campaign exploiting this configuration flaw. In just two to three weeks, the research team intercepted over 57 million log entries from more than 120 domains in a state of Lame Delegation—with data collection peaking at 30 MB per second—affecting victims across regions spanning more than 60 languages. At the heart of this incident was not a sophisticated zero-day vulnerability, but rather a fundamental and highly prevalent DNS configuration oversight.

What exactly is Lame Delegation?

To understand Lame Delegation, one must first grasp the DNS "delegation" mechanism. When an organization delegates a subdomain (e.g., `shop.example.com`) to an external DNS provider, the NS (Name Server) records for the parent domain (`example.com`) point to the authoritative name servers managed by that provider. Under normal circumstances, these authoritative servers should hold the complete DNS resolution data for the subdomain.

Lame Delegation occurs when the delegation record remains in the parent domain, but the designated name server no longer holds—or is unable to provide—authoritative data for that subdomain. When a DNS resolver queries this server, it does not receive a valid answer; instead, it receives a response indicating that the server is not responsible for the domain—effectively breaking the delegation chain.

Documentation from FIRS summarizes the attack logic: when a domain name used for a delegated name server expires, an attacker can register that expired domain, thereby seizing control over the resolution of the original (delegated) domain. It is as if your "address plate" remains on display at the registry, but the "security guard" tasked with watching the door has been replaced by a stranger. Why is this "minor oversight" potentially fatal?

The danger of "Lame Delegation" lies in the fact that it neither disrupts existing DNS records nor triggers any alerts. From the perspective of a management console, the NS (Name Server) records appear perfectly intact; from the user's end, DNS resolution might function normally in some regions while failing in others—or, worse, it might return a result that appears legitimate but is, in fact, incorrect.

Infoblox’s "Sitting Ducks" research illustrates the complete attack chain: when a domain controlled by an attacker is abandoned, its NS delegation records are often left behind. By simply re-registering this expired domain with the original DNS provider, an attacker can legitimately take control of all traffic directed to it—without needing to touch the victim’s devices or compromise the attacker’s own servers. Once control is seized, all requests destined for that domain are routed directly into the attacker’s infrastructure, allowing for the full capture of data such as device information, regional settings, and user click behavior.

For enterprises, this presents risks at three distinct levels:

Level 1: Subdomain Takeover. Once an attacker gains control over a delegated subdomain, they can host arbitrary content—such as phishing pages, fake login portals, or links for distributing malware. Because the domain itself belongs to the enterprise, it is extremely difficult for both browsers and users to visually distinguish the malicious content from the real thing.

Level 2: Email Spoofing and Impersonation. NIST guidelines explicitly identify Lame Delegation—much like "dangling" CNAME records—as a high-risk vector for email impersonation. Email authentication mechanisms such as SPF, DKIM, and DMARC all rely on the DNS infrastructure. If an attacker controls the DNS resolution for a subdomain, they can forge sender identities that appear to originate from the enterprise’s official systems, potentially bypassing certain email security gateways.

Level 3: Resolution Disruption and Denial of Service (DoS). When a DNS resolver encounters a Lame Delegation, it typically attempts to query other NS records associated with the domain. If none of the delegated servers can return valid data, the resolution process for the entire subdomain fails. DNS resolvers like BIND can rapidly exhaust their recursion budget for a single query when encountering a large number of "lame delegations," which further exacerbates resolution latency.

How can you detect if your domain is affected by a "lame delegation"?

You don’t need complex tools to detect a lame delegation; the `dig` command is sufficient for the core assessment.

Step 1: Trace the delegation chain. Run `dig +trace shop.example.com` to observe the full delegation path—from the root zone to the TLD, and finally to your own nameserver. If an NS record at any point in the chain points to a server that cannot provide authoritative data for the subdomain, or if the chain is broken, the issue is revealed.

Step 2: Query the delegated authoritative server directly. After obtaining the NS records from the parent zone, perform a non-recursive query against the delegated server using `dig @ns1.provider.net shop.example.com A +norecurse`. The `+norecurse` flag bypasses any caches, allowing you to verify whether the server actually holds authoritative data for the subdomain. If the response is `REFUSED`, `SERVFAIL`, or lacks an answer section, a lame delegation is confirmed.

Step 3: Cross-reference the NS lists between the parent and child zones. Use `dig NS example.com @a.gtld-servers.net` to retrieve the NS records as seen by the parent zone (the TLD registry) and compare them against the NS records in your own zone file. Discrepancies—such as the parent zone pointing to an old, decommissioned nameserver—are among the most common causes of lame delegations.

For scenarios requiring bulk checks, Google’s open-source tool `broken-dns` can be used to detect lame delegations at scale.

Remediation and Long-term Defense: From "Cleanup" to "Prevention"

Once a lame delegation is identified, fixing it is straightforward: update the NS records in the parent zone to point to the nameservers that currently hold the authoritative data for the subdomain. If a delegated server has been permanently decommissioned, remove it from the delegation chain entirely rather than leaving it in the NS list pointing to nowhere.

However, such fixes are merely a stopgap measure. To prevent the recurrence of such issues, three normalized mechanisms should be established.

First, incorporate DNS delegation into your asset inventory. The root cause of "lame delegation" is often that a subdomain was created for a project or contract, but after the project ended or the contract expired, the associated NS (nameserver) records were never cleaned up. Every addition, migration, or decommissioning of a subdomain must be reflected in the DNS configuration, ensuring that abandoned delegation records do not remain "orphaned" indefinitely within the registry.

Second, deploy DNSSEC. As noted by FIRS, DNSSEC is an effective tool for preventing rogue nameservers from hijacking lame delegations. By using digital signatures, DNSSEC ensures the authenticity and integrity of DNS resolution results. Even if an attacker were to take over an NS record by re-registering an expired domain, they would lack the legitimate signing keys; consequently, any DNSSEC-validating resolver would reject their forged responses. It is worth noting, however, that the effectiveness of DNSSEC depends on the reach of validating resolvers, as not all recursive DNS servers perform such validation.

Third, implement continuous monitoring of delegation integrity. Static checks only capture the state of a system at a single point in time. The real risk lies in delegation relationships quietly failing without anyone noticing. By leveraging a network of probing nodes across multiple operators and geographic regions, you can regularly compare actual DNS resolution results against the expected values ​​from the authoritative DNS. If an NS record becomes unreachable, returns anomalous responses, or yields unexpected results, an alert can be triggered immediately—transforming "lame delegation" from a configuration mishap discovered after the fact into a security incident that can be intercepted proactively.

DNS.COM offers a comprehensive suite of infrastructure services, ranging from domain registration and intelligent DNS resolution to security monitoring. The platform’s continuous monitoring capabilities include anomaly detection for DNS resolution states; it can promptly identify and alert you to early warning signs of lame delegation, such as broken delegation chains or unreachable nameservers. If your organization has not yet conducted a systematic review of its subdomain delegations, now is the ideal time to start—the cost of remediating lame delegation is minimal, yet the potential price of it being exploited is extremely high.