Dear Shivan, Shumon, Paul, Erik, and Tim, I am Ruixuan Li from Tsinghua University. I am writing to share a domain control validation risk identified in our USENIX Security 2026 paper, “Alias Equals Zone? Large-Scale and Stealthy Takeover of Domain Hosting Service via CNAME-Following Cross-Domain Verification.”
Since this issue is closely related to draft-ietf-dnsop-domain-verification-techniques, we hope it could be explicitly addressed in the draft. We found that some Application Service Providers (e.g., GitHub, NameCheap) follow ordinary CNAME records during domain control validation and treat records at the CNAME target as proof of control over the original alias domain. This may allow an attacker to validate a victim domain without placing any validation record in the victim domain's DNS zone. The core issue is that a CNAME relationship for DNS resolution is incorrectly interpreted as delegation of domain-control authority. We call this issue ALIASLEAP. Our measurements confirmed the vulnerability in four email hosting providers and seven web hosting providers, affecting more than two million domains. This differs from the intentional delegated validation described in Section 7 of the draft, where a purpose-specific CNAME and Unique Token are explicitly configured for validation. ALIASLEAP instead arises when an ordinary CNAME is implicitly treated as such a delegation. Would you consider adding an explicit security consideration, for example: “Application Service Providers MUST NOT treat records obtained only after following an ordinary CNAME as evidence of control over the original domain name. A CNAME relationship for DNS resolution does not by itself demonstrate delegation of domain-control authority.” We believe this clarification would help prevent insecure domain verification implementations. We would be happy to provide further details or suggested text if helpful. Thank you very much for considering this issue. Best regards, Ruixuan Li Tsinghua University
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
