Hacker News Reader

Comment by kragniz | Hacker News Reader

You can also set up a CNAME record to delegate the challenges to a provider with a supported API.

Doing it this way is also more secure, since it means you don't have to give your web server unrestricted write access to every DNS record under your domain.

acme-dns is specifically designed for this purpose: https://github.com/joohoi/acme-dns

If you use BIND you can set an UPDATE ACL that allows your web server access to change acme challenges only: https://fanf.dreamwidth.org/123294.html

BIND looks fantastic but I really like the restricted nature of acme-dns -- I don't know much about DNS and I don't want to inherit a huge amount of functionality that I don't know how to properly administer -- I really only want to manage a nameserver for acme challenges.

By "UPDATE ACL" I believe that you are referring to the DNS UPDATE RFC[0] -- it looks like cert-manager doesn't support generic UPDATEs yet[1].

[0]: https://tools.ietf.org/html/rfc2136

[1]: https://github.com/jetstack/cert-manager/issues/468

It’s pretty easy to make `dehydrated` use `nsupdate` for DNS challenges: https://github.com/fanf2/doh101/blob/master/roles/doh101/fil...

This is huge, thanks! It looks like there's also a PR into to cert-manager to support it:

https://github.com/jetstack/cert-manager/pull/787

Thanks for the tip -- that sounds like a great way forward. I can't find any documentation on it however after checking the community page (https://community.letsencrypt.org/t/acme-v2-production-envir...)... Do you have a pointer to the documentation on this feature?

Thinking about it again I'm not sure that I fully understand what you were suggesting -- are you suggesting adding a CNAME for x.example.com that redirects to yyyy.different-provider.com, and letting let's encrypt follow and work it out?

I also wanted to know how everyone was trusting with their DNS requirements/how people were making the decision (cost, trust, privacy, country of origin, whatever else).

_acme-challenge.yourdomain.example CNAME whatever.name.your.txt.record.lives.at.invalid

Probably the easiest way forward if you have any infrastructure yourself is to simply delegate some subzone of one of your domains to a nameserver you run yourself (like, delegate letsencrypt.yourdomain.example to your own nameserver), then point your CNAME to a name beneath that, and configure that nameserver for dynamic updates so your LE client can change the TXT record(s) on that server as needed.

Not sure why this is downvoted, this works and is supported.

Alternatively, you can delegate the _acme-challenge zone to a nameserver under your control, although you then have to configure each of the zones on the nameserver too.

One more thing that I'm not sure I understand.

Since I'll need an _acme-challenge.* PER-DOMAIN, doesn't this just move the goalpost to setting up the CNAME records (instead of TXT records directly), assuming my current registrar doesn't support wildcard CNAME entries?

If I'm understanding DNS 01 ACME challenges correctly, to register two subdomains first.one.example.com and second.one.example.com, I need to set up TWO TXT records, _acme-challenge.first.one.example.com and _acme-challenge.second.one.example.com. This means I need two CNAME records (or one if wildcards were enabled)...

I do thank you for your input, thinking about this has lead me to the possibility of just running my own nameserver all-together, I'm going to evaluate all these approaches and see how they pan out, and write a blog post to share.

I haven't used wildcard LE certs yet, but from what I know those only need a TXT record under one name. What you describe applies when you want a certificate that lists multiple explicit names, then each name gets validated individually, and so you need one TXT record per name to be validated (though you can still point all the CNAMEs to the same TXT record name, as long as they aren't used for concurrent validation).

Have you tried it?

According my reading of the challenge specification [1] it shouldn't work. Notice that it says:

> 2. Query for TXT records for the validation domain name Verify that the contents of one of the TXT records match the digest value

To me, this means that it should issue a query for TXT records only (not for ANY) and hence the server shouldn't even see your CNAME "redirector" record.

Thus, if your method works, either the server is wrongly implemented, there's a flaw in my reading comprehension, or the specification should be amended...

[1] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm...

CNAME records are dereferenced by the recursive resolver, not the client software, so querying for TXT records will work

You might want to read the DNS specification to find out what "query for TXT records" means :-)

Reply on news.ycombinator.com