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, [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]
