Enable CNAME chasing for ACME DNS-01 challenges

[hslatman]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Currently the CA will only consider DNS TXT records using net.LookupTXT when validating DNS-01 challenges. This means that challenge validation doesn't work in cases where CNAME records are used.

Why is this needed?

In certain (network) configurations ACME DNS-01 is used with CNAME records. For example, when acme-dns is used to delegate ACME DNS record management to a DNS server specifically built for that purpose, the CNAME record points the acme-dns server, which serves the TXT record the ACME server needs to validate.

The ACME RFC doesn't mention CNAME records itself. LE's Boulder doesn't do CNAME chasing itself, but there are are few comments stating it delegates that function to the DNS resolvers it uses, so in practice it does resolve those to the actual TXT records. Enabling that in step-ca is thus in line with what LE does.

Also see #1120 for an earlier PR implementing the fix. At the time we decided to close it, but I don't remember why.

[numo68]

+1 for this. I am hunting it right now in a homelab network, where the internal zone is served by the pfSense's unbound, that does not chase CNAME-s (at least in the configuration pfSense uses and that is not that easy to change), and simply says there is no such TXT record. I did not find any workaround. I think that using a private certificate autority for zones that don't have a "big" DNS is not uncommon and this would help immensely.

A possible alternative would be to allow specifying a different resolver for DNS-01 exclusively. For example it seems to be possible to seed the dns_acmedns with the needed records - I tried and it worked - but of course I lost the HTTP-01 because that needs the real one. The advantage would be that in that case one does not need to touch the real DNS at all.