Ruixuan, I've taken a quick look at your paper. You are pointing out vulnerabilities in methods of domain control validation used by some applications that don't rely on random/unique tokens, but merely on the presence of fixed, service specific records at the CNAME targets. Those methods are not secure and should be discouraged (thank you for analysing and publicising this).
Our draft does advocate the use of CNAMEs for delegated domain control, but in those cases the CNAME target embeds a unique token tied to the user/application (and additionally the TXT RR pointed to has a provider specific per-validation token). I'm open to your suggestion of adding a sentence/para in the security considerations section to address the scenario you describe and caution against it (maybe "Validation Using Non-Unique Records Reached via CNAME Redirection"). But I'll wait for my co-authors, or other working group members to chime in first. Shumon. On Wed, Sep 30, 2026 at 2:09 AM <lirx25= [email protected]> wrote: > 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]
