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