Dear all,
Thank you for your prompt and thoughtful responses! I agree with the draft's recommendation to use unique validation tokens, as this is an effective mitigation against the AliasLeap attack. I do not think the current recommendations are incorrect, but they may overlook some security risks. Therefore, I believe it would be reasonable to discuss the risks highlighted by AliasLeap in the Threat Model, Security Considerations, or the CNAME usage section. I would like to emphasize that the fundamental issue revealed by AliasLeap is that many applications mistakenly treat validation tokens belonging to another domain as proof of control over the domain being validated. This conflicts with the fundamental goal of Domain Control Validation (DCV), which is to verify that an applicant actually controls the domain in question. In my view, such control should be established through a validation token configured within the domain being validated. A CNAME record merely provides an alias mapping for DNS resolution; it does not inherently delegate domain ownership or control. Furthermore, based on our previous discussions with several popular service providers, they all preferred disabling CNAME following during DCV rather than introducing random validation tokens. This may reflect considerations related to user experience and the complexity of modifying existing services. We also observed that many popular providers using random validation tokens still follow CNAME records during DCV. This behavior may introduce additional security risks. For example, if an attacker can control the CNAME target and obtain the required validation token, they may be able to take over the original domain. For these reasons, I believe that prohibiting CNAME following during DCV is a necessary security measure. This is not only consistent with the fundamental purpose of DCV but also helps prevent unexpected security risks. These are my perspectives on AliasLeap and DCV, which I hope will be helpful to the discussion. I appreciate your consideration and would be happy to address any further questions or concerns. Best regards, Ruixuan -----原始邮件----- 发件人:"Erik Nygren" <[email protected]> 发送时间:2026-10-13 03:25:37 (星期二) 收件人: "Shivan Kaul Sahib" <[email protected]> 抄送: "Shumon Huque" <[email protected]>, [email protected], [email protected], [email protected] 主题: Re: Security consideration for draft-ietf-dnsop-domain-verification-techniques Agreed -- I think this current draft covers this well. Is there anything in our current recommendations which are vulnerable? In my readings there is nothing vulnerable if one follows the recommendations in the draft. This is explicitly why we recommend: 1) When using CNAMEs (for delegated DCV) pointing to a unique target that includes a token (eg, to tie to a specific account) 2) Using labels dedicated for DCV rather than ordinary CNAMEs. (eg, you validate with _foo-challenge.www.example.com not with www.example.com) If there are vulnerabilities in the current recommendations that would be great to know about, but none come to mind. It might be worth including an informational reference to the paper in the "Common Pitfalls" section of the Appendix? or maybe in "Service Confusion" in the security considerations? Alternatively, this might be an example for another case in the threat model for: > H6. The owner name of the Validation Record is meaningful in other contexts, > enabling cross-protocol, privilege escalation, and/or confused deputy > attacks. For example, if a Validation Record is a CNAME and has an owner name > that is a valid hostname, the Application Service Provider could provide > services on the Validation Record name within the domain. which I think is exactly the case covered in the paper. Erik On Mon, Oct 12, 2026 at 2:37 PM Shivan Kaul Sahib <[email protected]> wrote: 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 section that: All Domain Control Validation mechanisms are implemented by a DNS resource record with at least the following information: A record name related to the domain name being validated, usually constructed by prepending an application specific label. 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 <[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]
