We have a client that’s currently encountering an issue generating certificates for one of their domains. Although everything seems to be resolving, including the ‘_acme-challenge’ TXT response (dns challenge), the user still receives the following error:
Time limit exceeded. Last error: NS j.gtld-servers.net. did not return the expected TXT record
Does anyone have any ideas what may cause this? Thanks in advance!
Below is a dig against the challenge on our direct nameserver:
dig _acme-challenge.www.yrrkhv6v55a5r.serverclickdefense.com @ns1.cycle.io TXT
; <<>> DiG 9.10.6 <<>> _acme-challenge.www.yrrkhv6v55a5r.serverclickdefense.com @ns1.cycle.io TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59900
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;_acme-challenge.www.yrrkhv6v55a5r.serverclickdefense.com. IN TXT
;; ANSWER SECTION:
_acme-challenge.www.yrrkhv6v55a5r.serverclickdefense.com. 600 IN TXT "xxxxxxxx_xxxxxxxxx"
;; Query time: 18 msec
;; SERVER: 147.75.90.47#53(147.75.90.47)
;; WHEN: Fri Dec 07 09:43:12 PST 2018
;; MSG SIZE rcvd: 186
For what it’s worth, even if it did exist, _acme-challenge.www.yrrkhv6v55a5r.serverclickdefense.com would be difficult for Let’s Encrypt to resolve because the authoritative nameservers don’t support random capitalization and don’t reliably work well with the resolver’s fallback mode.
What ACME client are you using? What version is it?
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
Our platform stops resolving the _acme-challenge 5 minutes after a certificate generation request is made. So in this case, not having the record resolve at this time is correct.
I’m just so confused why it defaults back to the root nameservers even when the acme challenge is resolving and I can see our DNS servers answering the questions from LE.
The original error I posted is our response from LetsEncrypt’s API.
At the end of the day, I guess the question i’m asking is: “why, when the domain is fully resolving (and can be verified via a DIG / Unboundtest, etc) is LetsEncrypt resolving against the root nameservers for the TXT record?”
That error isn’t from Let’s Encrypt. I’d guess that lego is trying to check that the record works (though it’s not necessary) using a resolver of its own with no permanent cache.
For what it’s worth, Let’s Encrypt’s own recursive DNS servers disable caching, so they also make a lot of queries to the root and TLDs.
That actually makes a lot more sense. Thanks for the suggestion – I’ll dive into lego’s code and see if I can at least see why the resolver is taking this action.