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

[Eric Mill <[e-mail]>]

On Thu, Dec 17, 2015 at 11:19 AM, Andrew Ayer <[e-mail]> wrote:

> On Thu, 17 Dec 2015 02:23:20 -0500
> Eric Mill <[e-mail]> wrote:
>
> > I think that ACME should revisit the DNS specification and avoid
> > using a prefix for the TXT validation, to enable this use case.
>
> I disagree, because of a major restriction that DNS places on CNAMEs:
> CNAMEs cannot coexist with other record types.  If ACME didn't use
> prefixes, and you CNAME'd blog.ericmill.com over to Tumblr, you would
> lose the ability to yourself complete a DNS challenge for
> blog.ericmill.com, since no other record type could coexist with that
> CNAME.  This would pose a major problem for users of third-party
> services which do support TLS with user-provided certs but don't
> implement ACME.
>
> Meanwhile, there is a simple solution that does enable your use case:
> Tumblr can ask you to also CNAME _acme-challenge.blog.ericmill.com over
> to them.  It's slightly inconvenient to have to provision two CNAMEs
> instead of one, but this seems preferable to forcing some users
> to choose between CNAMEing to a third-party service and being able to
> use ACME themselves.
>

Yes, but this forces users to do the work of adding a second CNAME that
points to the third party service, and prevents the service from doing it
themselves.

The user base that would *benefit* from keeping the prefix consists of
users who want to CNAME their domain to a service (instead of full DNS
delegation) but who wish to obtain a cert themselves and then upload that
certificate to the service they've CNAMEd their domain to. That user base
sounds relatively small to me -- certainly smaller than the number of users
who currently use (or would use) custom domain support on third party
services.

To me, it seems like we'll get more widespread use of ACME (and HTTPS
adoption) by allowing large services to just "flip the switch" for
everyone, rather than involving the user in this decision.

The ideal would be to allow both use cases! So perhaps there's a way I'm
not thinking of, or perhaps we could split this into two separate DNS-based
validation methods, to support both kinds of uses.


>
> > 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.
>
> Again, just CNAME _acme-challenge over to the third-party service :-)
>

The prefix does neatly solve the issue of delegating via A records - that's
a good point.

-- Eric


>
> Regards,
> Andrew
>



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