I raised https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/227 to capture this. But I don't think we need text addressing this in the draft (though I could be persuaded). We are already very clear in the Recommendations <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-13#name-recommendations> section that:
*All Domain Control Validation mechanisms are implemented by a DNS resource record with at least the following information: 1. A record name related to the domain name being validated, usually constructed by prepending an application specific label.2. One or more Unique Tokens. * If an application ignores this advice by not including a unique token anywhere, then bad things could happen. There are many, many ways in which applications could mess this up: I don't think we need to outline every single one. Maybe we could just add a line in the delegated domain control section saying that you still need the unique token even if you're using CNAMEs. On Sun, Oct 11, 2026 at 10:14 AM Shumon Huque <[email protected]> wrote: > 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]
