Understanding Domain and Subdomain Takeover Findings for Domains Hosted on UltraDNS

Overview

Security scanners and vulnerability assessment tools may generate findings related to domain takeover or subdomain takeover conditions for domains hosted on UltraDNS.

These findings can cause concern because they may suggest that a third party can gain control of a domain or subdomain. In many cases, the finding is based on automated detection logic and does not confirm that a takeover vulnerability exists.

This article explains what these reports usually mean, how automated tools commonly generate these findings, and what information should be reviewed before concluding that a domain or subdomain is vulnerable.

What This Means

A domain or subdomain takeover occurs when a third party successfully gains control of DNS or hosting resources associated with a domain that they do not own.

Examples may include:

• A DNS record that points to a cloud service that has been deleted and can be claimed by another party.
• A CNAME record that points to a decommissioned service.
• Delegation to infrastructure that no longer belongs to the domain owner.
• Unclaimed cloud resources associated with active DNS records.

A confirmed takeover requires evidence that a third party can actually gain control of the affected resource.

Why Automated Scanners May Flag UltraDNS Hosted Domains

Many automated security tools use fingerprint-based detection methods to identify possible takeover conditions.

These tools commonly review externally observable DNS behavior, such as:

• Nameserver delegation.
• DNS response codes.
• Known provider fingerprints.
• Historical takeover patterns.

The scanner compares the observed behavior against known signatures and generates a finding when a match is detected.

Because automated scanners evaluate externally observable DNS behavior, a reported finding does not by itself confirm that a takeover vulnerability exists.

Understanding REFUSED Responses

One common finding involves authoritative nameservers returning a REFUSED response.

Some scanners may interpret a REFUSED response as evidence that a domain may be unclaimed or available for registration within a DNS provider platform.

A REFUSED response by itself does not indicate that:

• The domain is unowned.
• The zone has been deleted.
• Another customer can claim the domain.
• A takeover has occurred.

A REFUSED response only indicates that the nameserver declined to answer the query under the conditions presented.

Additional validation is required before any takeover conclusion can be made.

Common False Positive Conditions

The following conditions may generate takeover findings that are not confirmed vulnerabilities.

Authoritative Nameservers Returning REFUSED

Automated scanners may classify REFUSED responses as takeover candidates even when the response alone does not prove that the domain can be claimed by another party.

DNS Provider Fingerprint Matches

Security tools may identify a DNS provider and associate the result with a known takeover pattern without proving that the reported domain is actually vulnerable.

Proof of Concept Performed on Another Domain

Some reports demonstrate a takeover scenario using a separate test domain controlled by the researcher.

A proof of concept on another domain may demonstrate how a takeover could work in theory. It does not prove that the reported domain can be taken over.

Automated Takeover Scanner Results

Takeover scanners and DNS fingerprinting tools can help identify possible issues, but scanner output should not be treated as proof of compromise without supporting evidence.

What Constitutes a Valid Takeover Report

A valid takeover report should demonstrate one or more of the following:

• Successful claim of the affected resource.
• Successful creation of DNS records for the reported domain.
• Successful control of the reported hostname.
• Ability to serve content from the affected domain.
• Evidence that ownership protections can be bypassed.

Without this evidence, the finding may represent only a theoretical or unverified condition.

What Information to Provide to Support

If your security team reports a possible domain or subdomain takeover, collect the following information before contacting Support:

• The full vulnerability report.
• DNS query results.
• Screenshots or proof of concept details.
• Hostnames or domains identified as vulnerable.
• Steps used to reproduce the finding.
• Any evidence demonstrating actual control of the reported resource.

Providing this information allows Support to review whether the report reflects a confirmed risk or an unverified scanner-generated finding.

Important Notes

• A domain should not be considered vulnerable solely because a scanner reports a takeover condition.
• A REFUSED response does not confirm that a domain or zone is unowned, deleted, or claimable by another party.
• A DNS provider fingerprint match does not confirm that a takeover can occur.
• A proof of concept performed against a different domain does not prove that the reported domain is vulnerable.
• A valid takeover finding requires evidence that a third party can actually obtain control of the affected domain, subdomain, or associated service.