[DNSOP] Re: Security consideration for draft-ietf-dnsop-domain-verification-techniques

[Max Hearnden <[e-mail]>]

Well done highlighting the risks of static authentication tokens and 
CNAME records.

I noticed that the paper appears to omit another mitigation strategy, 
namely using an application specific underscored domain e.g. 
_acme-challenge.example.com. Since subdomains aren't affected by CNAME's 
in parent domains, this could mitigate against ALEASLEAP while still 
allowing for DCV delegation and DCV validation on domains covered by a 
DNAME record.

Two potential issues with using underscored subdomains include having to 
change old records and that the underscored subdomain would still be 
covered by a wildcard (e.g. *.example.com) so this could be an issue if 
the CNAME target still contains the DCV token (which should be at an 
underscored domain, something not likely to be a CNAME target).

On 30/09/2026 07:04, [e-mail] 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
>
>