DNS Challenge Time Limit Exceeded

Help
1

Hi,

I am using Traefik with Let’s Encrypy DNS Challenge using Cloudflare as a Provider. I have had this work countless times, however for some strange reason, I can’t get this domain to work.

Domain: duplicati.cyclops.99bits.net

While the challenge is happening, I can see the TXT Record added in my Cloudflare account, furthermore if I verify the TXT Record on various resolvers, they report it correctly:

image
image1442×712 39.3 KB

However it doesn’t look like the ACME server is seeing this key, since I get this error message:
time="2020-04-08T23:13:05Z" level=error msg="Unable to obtain ACME certificate for domains \"duplicati.cyclops.99bits.net\": unable to generate a certificate for the domains [duplicati.cyclops.99bits.net]: acme: Error -> One or more domains had a problem:\n[duplicati.cyclops.99bits.net] time limit exceeded: last error: NS hank.ns.cloudflare.com. did not return the expected TXT record [fqdn: cyclops.99bits.net., value: Tsh73GU7FVvBSqHcjiJcCB9EXBPXzRLL9xzbtXTB-u8]: v=spf1 include:spf.mailjet.com ?all\n" providerName=le.acme routerName=duplicati@docker rule="Host('duplicati.cyclops.99bits.net')"

After I get the error, the record disappears from Cloudflare DNS server, but I assume this is the expected behaviour of the certificate bot

2

This is a preflight check performed by Traefik’s ACME library, lego. It’s not an error from the Let’s Encrypt CA.

The problem here appears to be that the preflight query is seeing the TXT records for cyclops.99bits.net, rather than for _acme-challenge.duplicati.cyclops.99bits.net.

I think it is happening because you’ve put a wildcard CNAME in your zone:

$ dig +noall +answer _acme-challenge.cyclops.99bits.net txt
_acme-challenge.cyclops.99bits.net. 599 IN CNAME cyclops.99bits.net.
cyclops.99bits.net.     599     IN      CNAME   unifi.99bits.net.
unifi.99bits.net.       599     IN      TXT     "v=spf1 include:spf.mailjet.com ?all"

The wildcard CNAME might be clobbering the record being created on the _acme-challenge label, which is why you end up seeing the SPF record in the error instead.

Wildcard CNAMEs are pretty much always a mistake and lead to weird problems like these.

1 Like
3

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.