Hey Ruixuan, thanks for the email. Just FYI the authors are reviewing the paper.
On Tue, Sep 29, 2026 at 11:09 PM <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]
