deSEC anycast propagation timing out DNS challenge

[oouiy]

I'm currently experiencing this issue when using a domain hosted with deSEC. Issuing a certificate fails despite the relevant DNS entries being present. My server waits until the DNS entries are present and then attempts the DNS challenge. At this point, however, Lets Encrypt resolution cannot yet find these entries. Interestingly, on the following attempt cycles, I can see the "proofs" of the previous DNS challenge showing up in the Lets Encrypt API responses of the current challenge in the logs.

Is there anyway to increase the timeout to min 2 minutes as the forum post suggests?

Or maybe just a 60 second timeout between the propagation test succeeds and when the DNS challenge is started?

[girish]

By default, it already waits lot more than 2mins for the propagation. From the logs, where do you see it failing? Can you post some of th elogs?

[oouiy]

Jan 11 15:32:44 box:dns/waitfordns waitForDns: _acme-challenge.DOMAIN.TLD at ns ns2.desec.org: done
Jan 11 15:32:44 box:dns/waitfordns isChangeSynced: _acme-challenge.DOMAIN.TLD (TXT) was resolved to 3fMwPROOF1 at NS ns1.desec.io (45.54.76.1). Expecting 3fMwPROOF1. Match true
Jan 11 15:32:44 box:dns/waitfordns isChangeSynced: NS ns1.desec.io (2607:f740:e633:deec::2) not resolving _acme-challenge.DOMAIN.TLD (TXT): Error: queryTxt ECONNREFUSED _acme-challenge.DOMAIN.TLD. Ignoring
Jan 11 15:32:44 box:dns/waitfordns waitForDns: _acme-challenge.DOMAIN.TLD at ns ns1.desec.io: done
Jan 11 15:32:44 box:dns/waitfordns waitForDns: _acme-challenge.DOMAIN.TLD has propagated
Jan 11 15:32:44 box:cert/acme2 notifyChallengeReady: https://acme-v02.api.letsencrypt.org/acme/chall/999999999/999999999/z99999 was met
Jan 11 15:32:44 box:shell acme2: openssl rsa -modulus -noout
Jan 11 15:32:44 box:cert/acme2 sendSignedRequest: using nonce yoRvt02QdRYOJ3f3RG8lRt7w1vP1puMtQ-23m1Ft7KNT_lgifKQ for url https://acme-v02.api.letsencrypt.org/acme/chall/999999999/999999999/z99999
Jan 11 15:32:45 box:cert/acme2 waitingForChallenge: {"type":"dns-01","url":"https://acme-v02.api.letsencrypt.org/acme/chall/999999999/999999999/z99999","status":"pending","token":"REDACTED"}
Jan 11 15:32:45 box:cert/acme2 waitingForChallenge: getting status
Jan 11 15:32:45 box:cert/acme2 sendSignedRequest: using nonce yoRvt02QdMUP6-ljQHBPKYdBsopJcuppLJbX6rfUZtbsXrxSO0A for url https://acme-v02.api.letsencrypt.org/acme/chall/999999999/999999999/z99999
Jan 11 15:32:46 box:cert/acme2 waitForChallenge: status is "invalid" "{"type":"dns-01","url":"https://acme-v02.api.letsencrypt.org/acme/chall/999999999/999999999/z99999","status":"invalid","validated":"2025-01-11T15:32:45Z","error":{"type":"urn:ietf:params:acme:error:unauthorized","detail":"Incorrect TXT record \"hdcgPROOF2\" found at _acme-challenge.DOMAIN.TLD","status":403},"token":"REDACTED"}"
Jan 11 15:32:46 box:cert/acme2 Attempt 1 failed. Will retry: Unexpected status when waiting for challenge: invalid

[oouiy]

It essentially cycles like this until the whole task fails. The incorrect value returned in the detail field is always the challenge from the previous challenge cycle despite waiting for DNS propagation. The article I linked mentioned that you might have to wait longer after the your own server notices the propagation, as when Lets Encrypt performs the lookup, it may not have propagated fully yet due to anycast. I think if you just put in a 2 min timer after waitForDns: _acme-challenge.DOMAIN.TLD has propagated, the problem would probably resolve itself.

[girish]

@oouiy I can reproduce this for one my domains. deSEC only allows min ttl of 3600 seconds (1 hour). This makes it quite unlikely for DNS based automation to work. I have to see if we can figure some workaround . But immediately, I think you have to use some other DNS provider.

[oouiy]

Thank you for taking the time to investigate. It seems like there are several tools that have successfully implemented DNS-based Let's Encrypt challenges and DNS-based automation for deSEC.

If the higher TTLs really are a problem, could it be possible to just restrict the usage of deSEC to wildcard DNS + Certificate usage (wildcard A/AAAA record + DNS challenge for Let's Encrypt)? These records only need to be updated very infrequently if at all. I personally run my cloudron instance behind a VPN, which is why I am unable to use the HTTP based verification.

deSEC is a very special provider that I think is worth putting the effort into supporting. AFAIK It's the only donation-run/free, European provider with DNSSEC support currently included in Cloudron. Hetzner doesn't support DNSSEC. It's also (likely) one of the most privacy respecting providers available.

I have also made a post on their forum. Maybe some creative ideas will come about.