How Expired Name Servers Become Domain Hijacking Vectors

Here's a scenario most domain owners never consider: the name server their domain points to is itself a domain — and that domain can expire. When it does, every domain still delegating to it becomes hijackable. An attacker who re-registers the expired NS domain gains authoritative DNS control over every domain that was pointing to it. No hacking required. No vulnerabilities to exploit. Just a domain registration and a DNS server.

I found this pattern at scale when analyzing 240.3 million domains across 1,929 TLD zone files. Among the 1.55 million domains with lame delegations, 503,000 point to name server domains that have expired — and many of those expired NS domains are available for re-registration. The largest single cluster: 352,000 domains all delegating to variants of a single expired parking name server.

For the full lame delegation breakdown by category, see the lame delegations dashboard, which updates daily. This article focuses on why expired NS domains are an attack vector and what makes them worse than the subdomain takeovers the security community already worries about.

What Makes This an Attack, Not Just a Misconfiguration

A lame delegation by itself is a reliability problem — the domain doesn't resolve. But an expired NS domain creates something much worse: a hijacking opportunity at the delegation layer.

The attack is deceptively simple:

1. Domain example.shop has NS records pointing to ns1.old-hosting-provider.com and ns2.old-hosting-provider.com
2. The hosting provider shuts down and lets old-hosting-provider.com expire
3. An attacker registers old-hosting-provider.com for $10
4. The attacker runs a DNS server on ns1.old-hosting-provider.com and ns2.old-hosting-provider.com
5. DNS resolvers worldwide now query the attacker's server for example.shop — and it's a legitimate, authoritative delegation

There's no spoofing here. No race conditions. No BGP manipulation. The parent zone's NS records delegate authority to the attacker's server through the normal DNS hierarchy. Resolvers treat the responses as fully authoritative because, technically, they are.

Why This Is Worse Than Subdomain Takeover

The security community has spent years documenting subdomain takeover vulnerabilities — where a dangling CNAME to an unclaimed cloud service lets an attacker serve content on a subdomain. Subdomain takeover is well-understood, has multiple detection tools, and affects one subdomain at a time.

NS domain takeover is the same concept applied at the delegation layer, but with a dramatically larger blast radius:

A single expired NS domain re-registration can compromise more domains than thousands of individual subdomain takeovers combined.

The Concentration Problem: Registrar Parking NS Domains

The most alarming finding in the data isn't the total count — it's the concentration. A small number of expired NS domains account for the vast majority of affected domains:

The dns-expired.com family alone accounts for 352,000 lame delegations. These appear to be registrar-operated parking name servers — when a domain expires on certain registrar platforms, its NS records get redirected to nsN.dns-expired.com variants. The domains stay in the parent zone during the redemption grace period, pointing to these parking name servers.

The Japanese registrar Onamae.com follows the same pattern with onamae-expired.com variants, accounting for another 94,000 domains.

This creates an extraordinary concentration of risk. If dns-expired.com is itself available for registration — or if an attacker can social-engineer a transfer — they gain influence over 352,000 domains in a single transaction. Even if those domains are mostly expired and low-value, the sheer volume creates opportunities for credential phishing, email interception, and SEO manipulation at massive scale.

Decommissioned Provider Infrastructure

Beyond registrar parking domains, I found significant clusters of lame delegations from decommissioned hosting providers:

Rackspace Cloud DNS — When Rackspace decommissioned their Cloud DNS service, 12,800 domains were left pointing to dns1.stabletransit.com and related hostnames. These domains still exist and presumably have paying registrations — their owners may not realize their DNS is pointing to infrastructure that no longer serves their zones.

Dreamhost expired accounts — Roughly 8,200 domains point to Dreamhost name server variants where the hosting account has lapsed. The Dreamhost NS domains still exist (Dreamhost owns them), but the individual zones are no longer served.

The Rackspace case is particularly instructive. A company with sophisticated infrastructure decommissioned a DNS service and left thousands of customer domains stranded. This is a systemic risk in the DNS ecosystem: when DNS providers shut down, there's no protocol for safely migrating their customers' delegations.

Attack Scenario: Credential Phishing via Expired NS

Let me walk through how an attacker could exploit this:

Step 1: Identify high-value targets. The attacker analyzes the 503,000 domains pointing to expired NS domains. They filter for domains with active WHOIS records, valid registration dates, and recognizable brand names. Even among mostly-expired domains, they find hundreds with current registrations.

Step 2: Register the expired NS domain. For ~$10, the attacker registers the expired name server domain. They configure DNS server software (BIND, PowerDNS, or even a simple Go DNS handler) on the NS hostnames.

Step 3: Serve selective responses. The attacker doesn't need to serve DNS for all 352,000 domains. They target specific high-value domains, returning their own IP for A records while returning NXDOMAIN for the rest. This limits detection surface area.

Step 4: Issue TLS certificates. For each targeted domain, the attacker uses DNS-01 validation with Let's Encrypt to obtain a valid TLS certificate. Since they control the authoritative DNS, the ACME challenge succeeds.

Step 5: Phish or intercept. The attacker now has a valid HTTPS certificate for the victim domain and full control over where it resolves. They can serve credential phishing pages, intercept email (by setting MX records), or redirect API traffic.

The entire attack requires no exploitation of software vulnerabilities. It's purely an abuse of the DNS delegation model combined with the registrar ecosystem's failure to maintain NS domain registrations.

Why Detection Is Hard

Most DNS monitoring focuses on zone content — did someone change my A records? Did my MX records get modified? These tools query authoritative name servers and compare responses to expected values.

NS domain expiration is a different class of problem. The zone content hasn't changed — the NS records in the parent zone are the same as they were when the domain worked fine. What changed is the infrastructure behind those NS records. The name server hostname still exists in the parent zone delegation, but the server it points to is now controlled by someone else (or no one).

To detect this, you need to:

1. Resolve your NS hostnames to IP addresses
2. Query those IPs directly for your domain's SOA record
3. Verify the SOA response is authoritative and matches your expected configuration
4. Check that the NS domain itself hasn't changed ownership

Most domain monitoring services do step 1. Very few do steps 2-4. This means NS domain takeover can persist undetected for months or years.

The Root Cause: No Decommission Protocol

The DNS protocol has mechanisms for delegation (NS records, DS records, glue records) but no mechanism for safely removing a delegation. When a DNS provider shuts down:

• There's no way to signal "these delegations are no longer valid"
• The parent zone continues to serve the old NS records indefinitely
• Client resolvers continue to query the old NS hostnames
• If those hostnames resolve to new infrastructure, the delegation silently transfers

This is a protocol-level gap. ICANN has no requirement for registries to validate that NS records point to functioning name servers. Registrars have no requirement to notify domain owners when their NS domains approach expiration. DNS providers have no requirement to maintain NS domain registrations after service decommission.

Until this gap is addressed, expired NS domains will continue to accumulate, and each one is a potential mass-hijacking vector.

What You Can Do

Domain owners: Check your NS records right now. Use the DNS Inspector to query your domain's NS records, then independently verify that each NS hostname resolves and serves your zone. Set up monitoring that alerts if any NS hostname stops responding.

DNS providers: Treat your NS domains as critical infrastructure. Register them for the maximum term. Set up automated renewal alerts. If you're decommissioning a service, maintain the NS domains with SERVFAIL responses for at least 2 years — long enough for customers to discover and update their delegations.

Registries: Implement periodic NS liveness checks. If a delegated name server has been non-responsive for 90 days, notify the domain registrant. Consider removing chronically lame delegations from zone files rather than keeping them indefinitely.

Security researchers: Monitor expired NS domains for re-registration. A newly registered domain that was previously used as a name server hostname is a strong signal of potential exploitation. The lame delegations dashboard provides the current data on affected domains by category.