-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
acme-dns challenge: timeouts? #707
Comments
Hi @lf-, Here are some initial thoughts from reading your issue (thanks for all the detail!):
Lego is trying to figure out the authoritative nameservers for your domain as described here: https://github.com/xenolf/lego/blob/4d21f8eec18d57cd029cc287ae75b1b20f49c885/acme/dns_challenge.go#L264-L265 It needs to know the authoritative nameservers in order to directly query them to check the TXT records are correct before expending your Let's Encrypt rate limits trying and failing. The problem here is that one of the recursive nameservers Lego was using (in the text above, one of
The SOA lookup code in Lego considers any response other than NXDOMAIN or NOERROR to be an unexpected error, so your issuance fails: I'm able to reproduce the
Interestingly the query returns
I suspect there's a misconfiguration of some sort in your DNS zone that explains this but unfortunately I don't have any more time to dig into the details this morning and can't spot anything super obvious. You might find using Ultimately I don't think this is a bug with Lego or the acme-dns provider. If you need more help debugging your DNS zone I'd recommend opening an issue with Joohoi's acme-dns repo or contacting Cloudflare support. Good luck! Apologies for not having a complete solution for you! |
Indeed, that seems to fix it, but now I'm curious as to what the heck is happening with the DNS. Comparing Google DNS to Cloudflare, I find that the program while using Cloudflare DNS seems to be asking for a SOA on <guid>.acme.lfcode.ca and then not following up with a SOA question for acme.lfcode.ca. Edit: reword: the client software getting an answer it can deal with when using the Google DNS resolver and continuing on its normal codepath. The upstream DNS zone has only the following:
I have some more logs:
|
🎉 Great! Glad to hear it :-)
I see that you opened a thread on the Cloudflare forum for this issue (great idea) and @mnordhoff (he's a true Internet support hero, have I mentioned how much I appreciate him?) flagged a handful of issues with your DNS zone. I suspect one or more of these is the culprit here.
Indeed, Lego doesn't follow-up with another query because the first query to Cloudflare's recursive resolver returns a SERVFAIL response. I think we can conclusively say that this isn't a bug with Lego or Lego's acme-dns provider. @lf- would you be willing to close the issue? I'm not a maintainer and can't :-) |
joohoi/acme-dns#127 filed. acme-dns is kind of broken. I've fixed the NS issue. |
I'm running a version I compiled this evening from
lego-git
on the AUR with the commandACME_DNS_API_BASE=http://127.0.0.1:2500 ACME_DNS_STORAGE_PATH=/var/lib/lego/acme-dns-accounts.json lego --email <spambotsgoaway> -a --dns acme-dns --domains '*.lfcode.ca' --path /var/lib/lego run
, and I'm observing a timeout.Output:
acme-dns logs (don't worry about the timestamps, these are the same lines as were observed the first run):
Why is lego looking for SOA records? I've checked the domain listed there with dig for TXT records manually and found that there is indeed a record there. I've also tried running with
--dns-resolvers 127.0.0.1
to eliminate any caching misbehaviour.So, in summary:
_GMM.....
The text was updated successfully, but these errors were encountered: