CNAME delegation broken with DuckDNS provider
Welcome
- [X] Yes, I'm using a binary release within 2 latest releases.
- [X] Yes, I've searched similar issues on GitHub and didn't find any.
- [X] Yes, I've included all information below (version, config, etc).
What did you expect to see?
I would like to use DuckDNS (example.duckdns.org) for the DNS challenge of another domain (example.tk). I just want (wildcard) certificates for example.tk (and nothing for the DuckDNS domain).
What did you see instead?
lego fails to create a TXT record with the challenge at DuckDNS so validation fails.
How do you use lego?
Binary
Reproduction steps
This should be possible though CNAME delegation by setting up a CNAME record pointing from:
_acme-challenge.example.tk to _acme-challenge.example.duckdns.org
I believe the following should work:
export DUCKDNS_TOKEN=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
export LEGO_EXPERIMENTAL_CNAME_SUPPORT=true
lego --server="https://acme-staging-v02.api.letsencrypt.org/directory" --email="[email protected]" --domains="example.tk" --domains="*.example.tk" --dns duckdns run
This results in an error from DuckDNS however, because lego tries to set the TXT record of the wrong domain at DuckDNS. I attached the log below.
The log shows lego tries to create a TXT record at tk.duckdns.org (it's always using the TLD of domain as far as I can tell) instead of example.duckdns.org. Note that DuckDNS only allows a single TXT record for your subdomain and all sub-subdomains hold the same content. So setting the challenge at example.duckdns.org will automatically set it at _acme-challenge.example.duckdns.org too.
I changed my CNAME so it points to another domain hosted on Cloudflare instead of DuckDNS and tested the same thing and that is working great:
lego --server="https://acme-staging-v02.api.letsencrypt.org/directory" --email="[email protected]" --domains="example.tk" --domains="*.example.tk" --dns cloudflare run
So I believe this issue is specific to the DuckDNS provider.
Version of lego
lego version v4.5.3 linux/amd64
Logs
[WARN] [example.tk] acme: cleaning up failed: request to change TXT record for DuckDNS returned the following result (KO) this does not match expectation (OK) used url [https://www.duckdns.org/update?clear=true&domains=tk&token=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee&txt=]
Could not obtain certificates:
error: one or more domains had a problem:
[example.tk] [example.tk] acme: error presenting token: request to change TXT record for DuckDNS returned the following result (KO) this does not match expectation (OK) used url [https://www.duckdns.org/update?clear=false&domains=tk&token=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee&txt=XXXXXXXXXXXX]
Go environment (if applicable)
$ go version && go env
# paste output here
Hi, i am seeing the same kind of issue with Route53. Using CNAME will result in a Route53 Error: cleaning up failed: failed to determine Route 53 hosted zone ID: zone "original.domain.com . not found for domain _acme-challenge.original.domain.com. Original.domain.com has a _acme-challenge as CNAME to point to Route53.
Is there any solution for that? Trying to set that up using traefik with a similar domain scenario