Aaron, I appreciate your explanation, but I look forward to more confirmation from others.
Thanks! Ara On Sunday, November 23, 2025 at 12:19:08 AM UTC+8 Aaron Gable wrote: > Suppose example.com has a CNAME to example.org, and you want to validate > control of example.com. This sentence means that you cannot look up _ > validation-persist.example.org (i.e. cannot follow a CNAME for the > purposes of determining the ADN). But when you look up _ > validation-persist.example.com, you will of course follow CNAMEs from > there, because that is simply how DNS works. > > Aaron > > On Sat, Nov 22, 2025, 05:38 Arabella Barks <[email protected]> wrote: > >> Hi all, >> >> I have someting confusion regarding SC-088v3. >> >> Regarding >> https://github.com/cabforum/servercert/pull/608/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1041 >> : >> ``` >> >> *Confirming the Applicant's control over a FQDN by verifying the presence >> of a Persistent DCV TXT Record identifying the Applicant. The record MUST >> be placed at the "`_validation-persist`" label prepended to the >> Authorization Domain Name being validated (i.e., >> "`_validation-persist.[Authorization Domain Name]`"). For this method, the >> CA MUST NOT use the FQDN returned from a DNS CNAME lookup as the FQDN for >> the purposes of domain validation. This prohibition overrides the >> Authorization Domain Name definition. CNAME records MAY be followed when >> resolving the Persistent DCV TXT Record.*``` >> >> Defines: *the CA MUST NOT use the FQDN returned from a DNS CNAME lookup >> as the FQDN for the purposes of domain validation. **CNAME records MAY >> be followed when resolving the Persistent DCV TXT Record.* >> >> This appears to be contradictory. Is CNAME delegation allowed or >> prohibited in this context? >> >> For example: >> ➜ ~ dig txt _validation-persist.domain.example >> ; <<>> DiG 7.6.5 <<>> _validation-persist.domain.example txt >> ;; global options: +cmd >> >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49009 >> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;_validation-persist.domain.example. IN TXT >> >> ;; ANSWER SECTION: >> _validation-persist.domain.example. 86400 IN CNAME >> [random-token].cname.example. >> [random-token].cname.example. 3600 IN TXT "authority1.example; accounturi= >> https://authority1.example/acct/123; persistUntil=1782424856" >> [random-token].cname.example. 3600 IN TXT "authority2.example; accounturi= >> https://authority2.example/acct/abc; persistUntil=1782424856" >> >> ;; Query time: 142 msec >> ;; SERVER: 8.8.8.8#53(8.8.8.8) >> ;; WHEN: Sat Nov 22 21:28:35 CST 2025 >> ;; MSG SIZE rcvd: 80 >> >> >> I would like to ask: >> - Are those CAs compliant in issuing certificates for >> domain.example(authority for account 123, authority2 for account abc)? >> >> - Additionally, is the issuance of a certificate for >> subdomain.domain.example permitted in this scenario? >> >> >> Thanks. >> >> >> - (https://github.com/cabforum/servercert/pull/608)[Pull request of >> Balloc SC-088v3] >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0462d0a4-4caf-434d-a00d-48148f700354n%40mozilla.org >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0462d0a4-4caf-434d-a00d-48148f700354n%40mozilla.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/99f69805-d03e-42e3-9e23-b99ebfca4076n%40mozilla.org.
