Orphaned NS Delegation Leaves a DNS Subdomain Open to Takeover

Symptom

A subdomain that was working normally begins resolving to unexpected content, or a security scan flags a live nameserver delegation pointing at infrastructure the owning team no longer recognises. In the case examined here, an internal marketing subdomain (referred to generically as app.example.com) was delegated via NS records to a third-party managed DNS platform to support a now-retired microsite. Months after the microsite and its hosted DNS zone were decommissioned, the subdomain still resolved — but to content nobody on the team had published.

False Assumption

The team that ran the original DNS Subdomain Security validation assumed that “delegation resolves correctly” is equivalent to “delegation is safe.” Their audit checked that app.example.com returned an A record and a healthy response at the time of the check, and treated a clean result as proof the configuration was sound. It did not check who currently held authority over the delegated zone, only that something answered.

A second, related assumption was that decommissioning the destination service — deleting the hosted zone or shutting down the microsite — automatically retired the delegation itself. In practice, the parent zone’s NS records are a separate configuration object from the hosted zone they point to, and nothing forces the two to be removed together.

Root Cause

The root cause is a stale NS delegation left in the parent zone after the delegated destination was deleted, combined with a third-party DNS/hosting provider that allocates zone names to any account on a first-come basis.

NS records in a parent zone assert delegated authority, not ownership of content. When the destination zone at the third-party provider is deleted, that provider’s namespace for the zone name typically becomes available again. Because the parent zone still points at that provider’s nameservers, the first party able to create a matching zone name there inherits full authoritative control over the subdomain, without touching the parent zone at all. The validation process never re-checked delegation ownership after initial setup, so the gap stayed invisible until something used it.

This exposure applies specifically to delegations pointing at multi-tenant DNS or hosting platforms where zone names are allocated per customer account, rather than a single dedicated authoritative service the organisation exclusively controls. The exact reclaim behaviour — how quickly a deleted zone name becomes available to other accounts, and whether a provider offers any reservation window — varies by provider and account tier, and should be confirmed against the specific provider’s current documentation before this is treated as a complete detection control on its own.

Impact

An unclaimed but still-delegated subdomain can be silently repurposed by anyone able to register a matching zone at the third-party provider. Consequences include hosting of phishing or malicious content under a trusted parent domain, issuance of valid domain-validated TLS certificates for the subdomain, and abuse of the subdomain to undermine assumptions embedded in cookie scoping, referrer checks, CORS allow-lists or mail-authentication alignment that trust the parent domain’s namespace. General cloud security guidance typically assumes DNS authority reflects organisational ownership as a baseline for identity, network and logging controls; a dangling delegation breaks that assumption at the DNS layer itself, upstream of most access-control and logging controls that operate at the application or network layer. Because the exploit requires no change to the parent zone, standard change-management alerts on the parent zone will not detect it.

Diagnosis

Confirm the problem with read-only queries before making any change.

• Query the current authoritative nameservers for the subdomain and compare them against an inventory of DNS providers the organisation actively controls.
• Trace the delegation chain from the root to confirm which zone is currently answering.
• Check the third-party provider account directly for whether a zone matching the subdomain name exists under the organisation’s own account, not merely whether the subdomain resolves.

dig NS app.example.com +short
dig +trace app.example.com
whois example.com

A subdomain that resolves cleanly but has no corresponding zone in the organisation’s own provider account is the definitive signal: the delegation is dangling, and the entity currently answering for it is not under organisational control.

Correction

The correction removes or repoints the stale delegation so authority reverts to infrastructure the organisation controls, rather than relying on the destination remaining unclaimed.

• If the subdomain is no longer needed, remove the NS delegation records from the parent zone entirely so nothing resolves for that name.
• If the subdomain must remain in service, first create and verify a new zone for that name under an account the organisation controls at the intended provider, confirm it answers correctly in isolation, and only then update the parent zone’s NS records to point at the new, owned zone.
• Do not leave a window where the parent zone points at a provider zone that does not yet exist under organisational control; that window is exactly the exposure being closed.

Validation

Validation confirms that every nameserver currently authoritative for the subdomain is one the organisation owns or has an active, verifiable contract for.

• Re-query the subdomain’s NS records from an external resolver and confirm each returned nameserver matches the organisation’s current DNS provider inventory.
• Confirm, inside the provider’s own console or API, that the corresponding zone exists under the organisation’s account rather than being absent or unclaimed.
• Run a subdomain takeover detection scan across the wider domain estate to confirm no other dangling delegations exist alongside the one just corrected.

Rollback

Rollback restores service without ever reinstating the vulnerable delegation.

• Export and timestamp the parent zone’s NS record set before making any change, so the prior state is documented.
• If removing or repointing the delegation breaks a legitimate dependent service, restore resolution using a temporary A or CNAME record under organisational control while the correct, owned delegation target is established; do not restore the original third-party delegation, since that recreates the exposure.
• Treat the change as complete only once NS queries confirm the expected owned nameservers and the dependent service is confirmed healthy; keep the pre-change export attached to the change record for audit.

Prevention

Maintain a live inventory of every NS delegation in every zone the organisation controls, mapped to the team and provider account responsible for the destination zone. Add DNS delegation removal as an explicit, checked step in every service decommissioning runbook, not an optional cleanup task. Schedule a recurring automated scan for dangling delegations across the full domain and subdomain estate, and treat any subdomain that resolves without a matching, organisation-owned destination zone as a standing finding requiring the same correction and validation sequence described above.