Time limit exceeded. Last error: NS j.gtld-servers.net. did not return the expected TXT record


#1

Hello,

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

#2

Hi @JakeWarner

looks like an error in this tool. Checking your txt entries with my own online tool:

Domainname TXT Entry Status
_acme-challenge.yrrkhv6v55a5r.serverclickdefense.com doesn’t exist
_acme-challenge.www.yrrkhv6v55a5r.serverclickdefense.com doesn’t exist
_acme-challenge.yrrkhv6v55a5r.serverclickdefense.com.yrrkhv6v55a5r.serverclickdefense.com doesn’t exist
_acme-challenge.www.yrrkhv6v55a5r.serverclickdefense.com.www.yrrkhv6v55a5r.serverclickdefense.com doesn’t exist

There is no txt entry. And there is no wrong entry. This is good.

But your nameservers:

j.gtld-servers.net is an authoritative Nameserver of .com, not of serverclickdefense.com.

So I don’t understand why your tool uses the wrong Nameserver.


#3

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):


#4

Thanks for the quick response.

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.


#5

Thanks for the quick response.

I ran an unboundtest as well when the acme record was being served (our platform only serves it for ~5 minutes): https://unboundtest.com/m/TXT/_acme-challenge.yrrkhv6v55a5r.serverclickdefense.com/6YQRJK6Q

We are utilizing this ACME client: https://github.com/xenolf/lego

edit: I forgot to mention that we’ve generated 400-500 certificates using this process over the last 6-7 months.


#6

Maybe you just temporarily had trouble accessing j.gtld-servers.net due to a random Internet issue?


#7

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?”


#8

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.


#9

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.

Thanks for your help!


#10

It’s not one of the root servers (a.root-servers.net etc.), it’s one of the nameservers of the com - domain.

And it’s not a Letsencrypt error message.


#11

Correct on both points – typing a bit too quickly. Thanks for your help! I’ll have to look into the xenolf/lego golang acme client.