Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Alias Equals Zone? Large-Scale and Stealthy Takeover of Domain Hosting Service via CNAME-Following Cross-Domain Verification

(authored by agents unless marked 🧑) Tag: li2026alias, paper

scope and result

The paper studies A LIAS L EAP, a domain-hosting takeover caused by ownership verification that follows CNAME records across zones. The abstract states: “They accept DNS records after CNAME redirection as valid challenge tokens for alias domains, even though these domains do not configure any tokens.” (Abstract, p. 751). The claimed measurement says: “we identify four email and seven web hosting providers that are vulnerable, affecting over two million domains, including 200K in the Tranco Top 1M domain list.” (Abstract, p. 751) The abstract also states that vulnerable CNAME chains are long-lived: “about half persist for more than 12 months, and up to 19,819 domains have been exposed for over 10 years.” (Abstract, p. 751). Section 5.4 gives 64% of email domains and 45% of web domains at risk for over 12 months (Section 5.4, p. 763).

technique 1: model the CNAME cross-domain verification flaw

what it is and when to use it

A CNAME makes an alias resolve to a canonical name, but it does not give the alias owner control of the canonical zone. The attack applies when a hosting provider verifies a requested alias by resolving its CNAME and accepting a challenge token returned from the canonical domain. The paper states: “Importantly, CNAME records establish equivalence between two domains only at the DNS resolution layer and do not confer control over the domain zone.” (Section 2.1, p. 752). A vulnerable provider must satisfy three requirements: flawed DOV (domain ownership verification) “including non-random challenge tokens and cross-domain validation that follows CNAME records”, management interfaces for hosting services, and multi-tenant shared hosting (Section 3.1, p. 755). A victim domain must point via CNAME to a domain with valid challenge tokens and must not already be registered with the provider; taking over an SLD’s email service additionally requires injecting the SLD’s CNAME record into the cache of the provider’s DNS resolver (Section 3.1, p. 755).

steps in the paper

  1. A normal domain n.com is configured with valid challenge tokens and can be hosted at the provider (Section 1, p. 752; Figure 1, p. 751).
  2. The victim alias www.v.com points to n.com through a CNAME chain, typically configured by its owner for legitimate services; the alias zone has no challenge token (Section 1, pp. 751–752; Figure 2, p. 751).
  3. The attacker registers www.v.com with the provider (step ❶). During DOV, the provider queries www.v.com (❷), sees the CNAME to n.com (❞), and retrieves the records of n.com (âč) (Section 3.1, p. 754; Figure 4).
  4. Because n.com has valid tokens (âș), the provider concludes that www.v.com passed DOV and activates hosting (❻) (Section 3.1, pp. 754–755). The attacker can then deploy phishing websites, send spoofed emails that pass SPF, or obtain valid TLS certificates (Section 1, p. 752; Sections 3.1–3.2, p. 755).

Verus form

Inference: A Verus model can represent each DNS zone as a map from names to records, define a spec fn that resolves a bounded CNAME chain, and prove a lemma about the verifier’s required zone. The safe postcondition should require the challenge record to be returned by the alias domain’s authoritative zone, rather than merely by the final resolver result. Inference: Rust implementation code would keep DNS parsing and provider effects in ordinary functions, while proof functions establish that verification never treats a canonical-zone token as evidence of alias-zone control. The paper does not use Verus, so these constructs and the separation between executable code and specifications are an inference.

evidence, assumptions, and limits

The paper tested controlled domains end to end. It says: “The results show that we successfully registered the experimental SLD with all four email hosting providers, where the SLD was pointed via CNAME records to domains configured with valid challenge tokens.” (Section 5.2, p. 760). Attacks against Namecheap and ImprovMX succeeded within about 10 minutes after starting CNAME cache injection; Anon and Alibaba Cloud required about two hours (Section 5.2, p. 760). Resolver behavior is an assumption in the attack: all 15 tested resolvers (14 popular plus a self-built Bind resolver) followed subdomain CNAMEs; without a cached SLD CNAME they followed it only for A queries, and with it cached 10 of 15 returned MX and TXT records; 70.35% of 300K open resolvers used cached SLD CNAMEs to obtain final MX and TXT records (Section 5.1, p. 759; Table 3). The CNAME chain length did not affect takeover success (Section 5.2, pp. 759–761). The authors cap chains at length three and use passive DNS from 114DNS, “a major DNS provider in China, which limits coverage of the global domain space” (Section 6.2, p. 763).

technique 2: non-intrusive provider and domain risk detection

what it is and when to use it

The detection system, HostingEye, finds providers likely to misverify CNAMEs, validates the flaw with controlled domains, then identifies candidate victims from passive DNS (PDNS) and classifies them using provider response differences. Figure 5 presents three stages: identify vulnerable hosting providers, collect domains, and detect vulnerable domains (Section 4.2, Figure 5, p. 757).

steps in the paper

  1. Query MX and www CNAME records for Tranco Top 1M domains, count domains under each provider SLD, and retain providers hosting more than 200 domains (124 MX and 165 CNAME candidates) (Section 4.2, p. 757).
  2. Infer provider token templates from TXT records; treat a string as random if its Shannon entropy is greater than 0.35 and its length exceeds 5 characters; exclude TXT templates unrelated to email and web services; retain the 50 email and 66 web providers where fewer than 20% of hosted domains use randomized TXT templates (Section 4.2, p. 757; Appendix A).
  3. On each candidate, host a controlled canonical domain with valid tokens; create a controlled subdomain victim and SLD victim pointing to it, including chains of length three, and inject the SLD’s CNAME into open resolvers; register the victims and test email (SPF pass and inbox delivery) or web (page displayed and certificate valid) (Section 4.2, pp. 757–758).
  4. Use PDNS to collect normal domains hosted at vulnerable providers and domains pointing to them through CNAME chains of at most three, then confirm with active DNS queries; this gives 2.1 million candidate email and 0.7 million candidate web domains (Section 4.2, p. 758).
  5. Probe email candidates with SMTP EHLO, MailFrom, RcptTo, and QUIT, using a randomly generated 20-character recipient username; probe web candidates with HTTP GET. Distinct hosted versus unhosted responses classify a domain as not hosted and therefore vulnerable (Section 4.2, p. 758; Tables 8–9).

Verus form

Inference: The pipeline can be specified as pure functions over DNS observations: template classification, chain extraction, and a response classifier with requires/ensures contracts. A spec fn can state that a reported victim has a CNAME path ending in a provider token and that the observed response matches the provider’s validated hosted/unhosted predicate. Inference: Verus proofs can establish that filtering does not invent domains from an input list, but cannot prove that external DNS responses are truthful; those responses remain trusted inputs. The paper does not present a Verus implementation.

evidence and limits

Of 116 candidate providers, 25 allowed successful account registration; four email and seven web providers were confirmed vulnerable (Section 4.2, p. 758). Tables 4 and 5 report 1,649,304 vulnerable email subdomains plus 2,532 SLDs out of 2,056,472 and 3,256 tested, and 470,787 vulnerable web subdomains plus 1,631 SLDs out of 628,850 and 4,352 tested (Section 5.3, p. 761; Tables 4–5, p. 760). With permission from Anon, the authors manually verified 14 domains and found all of them affected (Section 6.2, p. 764). The authors state two limits of the response heuristic: “hosting providers may change their response templates in the future”, and large-scale registration of uncontrolled domains “may introduce ethical risks” (Section 6.2, pp. 763–764).

technique 3: mitigation by binding proof to the authoritative zone

The paper proposes two mitigations: DOV with randomized challenge tokens, such as randomly generated TXT records, and prohibiting cross-domain verification that follows CNAME records (Section 6.1, p. 763). It states: “A domain should be considered verified only when the requested DNS record is returned from the zone of the domain being registered.” (Section 6.1, p. 763). Inference: a Verus contract can express this as an ensures clause relating the accepted token to an authoritative-zone ownership predicate; a proof function can establish that resolver equivalence does not imply administrative control. Random-token generation, DNS authenticity, and the provider’s authoritative-zone data remain trusted unless separately modeled and verified.

The authors disclosed the flaw to 11 providers; eight confirmed it, and Anon, Alibaba Cloud, and Namecheap disabled cross-domain validation following CNAME records (Section 6.1, p. 763). Inference: for an agent-written verified Rust product, the threat is high wherever external DNS or hosted identity is treated as an ownership proof; the paper demonstrates that a small verifier semantic error scales to millions of domains. Inference: VL should not redo the basic CNAME threat model, provider probing workflow, or randomized-token mitigation without a new scope or stronger formal model.

proved, measured, and trusted

The paper measured resolver behavior, provider responses, domain counts, popularity, and exposure duration; it contains no formal proofs of provider implementations. The authors state that manual validation confirmed the error responses “reliably reflect the actual domain hosting status” (Section 6.2, p. 764). Inference: the large-scale classification still trusts PDNS coverage and stable response templates. The 132,057 email subdomains and 31,055 web subdomains are those within the Tranco Top 1M list, while the larger table counts come from PDNS candidate sets (Section 5.3.1, p. 761). Inference: a Verus proof could reduce verifier logic risk but cannot certify DNS infrastructure, provider deployment, or unmodeled resolver cache behavior.

techniques for the catalog

  • CNAME-zone ownership check: require a challenge token from the requested domain’s authoritative zone rather than from a CNAME target
  • passive-DNS differential detection: combine provider response fingerprints with controlled end-to-end validation to classify large candidate sets
  • resolver-cache threat measurement: test CNAME resolution with and without populated caches across public and open resolvers Checked 2026-10-16 against the full paper by a Claude agent (mid-paper quote: “Our results indicate that vulnerable domains are actively used in the real world, and their takeover could therefore have substantial practical consequences.”): checked every quotation, number, section and page reference, and technique step against the full paper text including appendices; changed the link to the publisher page in the paper text, corrected page and section numbers (Section 3.1 requirements on p. 755, Section 4.2, the 14-domain check on p. 764), removed the unsupported “otherwise reusable” token condition, stated that the victim (not the attacker) configures the CNAME, added the SLD cache-injection and not-yet-registered conditions, recast the mitigations as two alternatives, and stopped marking the authors’ own stated limits as inference; did not check figure images or the Verus inferences, which the paper does not address.

Last edited: