[Acme] DNS challenge spec doesn't support CNAME model

[Eric Mill <[e-mail]>]

Hi,

Both the IETF and LE versions of the ACME spec define a DNS validation
method[1] which requires the validating party to set a TXT record for a
prefixed version of the hostname the cert is being requested for.

The client constructs the validation domain name by prepending the label
"_acme-challenge" to the domain name being validated, then provisions a TXT
record with the digest value under that name. For example, if the domain
name being validated is "example.com", then the client would provision [_
acme-challenge.example.com.]


I can see some discussion last December about the rationale for this
approach[2], but this doesn't apply to at least one large class of users,
which are services which ask their users to CNAME their custom domain over
to their service.

For example, a CNAME is how WordPress[3], Tumblr[4], and GitHub Pages[5]
allow customers to point non-apex domains at their services. If I want
blog.ericmill.com to be hosted by Tumblr, I set a CNAME record for "
blog.ericmill.com" with the value "domains.tumblr.com". Many other CDNs and
web services operate the same way.

Since DNS specifies that a CNAME can be thought of as an alias[6], this
means that a service like Tumblr is capable of setting a TXT record for
domains.tumblr.com with the validation token for blog.ericmill.com. A
spec-compliant DNS resolver looking for a TXT record for blog.ericmill.com
should follow the CNAME alias first, and then correctly identify the TXT
record for domains.tumblr.com as applying to blog.ericmill.com.

However, the current ACME spec asks for the record to be set for a prefix,
not for the requested FQDN. And if I CNAME blog.ericmill.com over to
Tumblr, Tumblr does not have the ability to set any records for a prefix,
such as _acme-challenge.blog.ericmill.com. This means that services which
have users CNAME domains are not able to use DNS validation to obtain
certificates.

I think that ACME should revisit the DNS specification and avoid using a
prefix for the TXT validation, to enable this use case.

Also: I can't think of any changes offhand that would enable Let's Encrypt
to support a use case where users set an A record to point to a third party
service, such as for apex domains in the services mentioned above. But this
is another important use case, especially for service providers which don't
distinguish between apex and non-apex domains in their business
offerings.[7] It'd be great to hear ideas for how that might be achieved.

-- Eric

[1]
https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#dns
[2] https://mailarchive.ietf.org/arch/msg/acme/gN1NxR4kmB3c9RT4ZIvZo1SBHKo
[3] https://en.support.wordpress.com/map-subdomain/
[4] https://www.tumblr.com/docs/en/custom_domains
[5]
https://help.github.com/articles/setting-up-a-custom-domain-with-github-pages/
[6] https://tools.ietf.org/html/rfc1034#section-3.6.2
[7] Few services distinguish these. But Bitly is an interesting case where
its very nature (short links) mean that their custom domains are almost
exclusively SLDs that require an A record.
http://support.bitly.com/knowledgebase/articles/76741-how-do-i-set-up-a-custom-short-domain-

-- 
konklone.com | @konklone <https://twitter.com/konklone>