Incorrect TXT Record

Help
1

Dear community,

I recently ran into an error trying to renew our (multi-domain) certificate. It threw various errors. So I tried to strip down the problem to a single domain, and the error persists.

The error is

Incorrect TXT record "PaFks-hMBo5RZdK1Em7AeGwmIjeie5vKLl692xE2WqQ" (and 1 more) found at _acme-challenge.goalify.link

The thing is, when I looked at out DNS providers dashboard (we use DNSimple as DNS provider) I cannot see this record. I see two other records that where created during the validation of the domain, with their correct values. If I delete the existing records and restart the verification process, I can see the value in the exception change ...

Also if I query the TXT records for _acme-challenge.goalify.link for instance through mxtoolbox.com I only receive the two records created during the validiation. But none of them has the value which is shown in the error message

I don't know how to proceed from here. The current certificate for those domains is of course still valid for about a month, but I would like to resolve this issue as fast as possible. Any help is appreciated ...

My domain is:

goalify.link, *.goalify.link

I ran this command:

I'm using the node acme-client with auto mode. All these tests are done against the staging environment of letsencrypt

It produced this output:

Incorrect TXT record "PaFks-hMBo5RZdK1Em7AeGwmIjeie5vKLl692xE2WqQ" (and 1 more) found at _acme-challenge.goalify.link

My web server is (include version):

No webserver as I'm using DNS validation only. Running the renewal as a node script

The operating system my web server runs on is (include version):

not applicatioin

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

2

I also tried the same process for a different set of domains (ie goalifyapp.com and *.goalifyapp.com) using certbot with the same results

I used certbot as follows

sudo certbot --test-cert -d goalifyapp.com -d *.goalifyapp.com --manual --preferred-challenges dns certonly

then created the two TXT records as asked by certbot and certbot gave me the same errors

Identifier: goalifyapp.com
Type: unauthorized
Detail: Incorrect TXT record "xF9qEdWqg1M8ugeA1cVEdmQDVMErk2rcj85sYTdhY30" (and 1 more) found at _acme-challenge.goalifyapp.com

I also checked before continuing as suggested with the googleapps dig as suggested by the certbot. Which is showing me the correct values

3

Hello @wiggisser,

Presently https://unboundtest.com/m/TXT/_acme-challenge.goalify.link/5FLYX3MG
is showing 2 TXT records for _acme-challenge.goalify.link

Query results for TXT _acme-challenge.goalify.link

Response:
;; opcode: QUERY, status: NOERROR, id: 63155
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: do; udp: 1232

;; QUESTION SECTION:
;_acme-challenge.goalify.link.	IN	 TXT

;; ANSWER SECTION:
_acme-challenge.goalify.link.	0	IN	TXT	"tVl0zw9ZPuIccdyloRUtBTcAWO8DuANTjViF9LCg2Bk"
_acme-challenge.goalify.link.	0	IN	TXT	"xxu55FlQKRb_2lQp_RULx_5rlnqG-vvd5Ok2yMkAFGg"

----- Unbound logs -----

Also using the online tool Let's Debug yields these results https://letsdebug.net/goalify.link/2825420?debug=y for your domain name goalify.link using the DNS-01 challenge

4

How long did you wait for DNS record change propagation?

5

Thanks for your answer. Yes these would be the records I created during the last run against that goalify.link domain ...

to be honest I didn't wait at all, but just let the node-acme-client do its work as always ...

Please see also my second post, where I tried this with certbot (for a different domain) and the --manual setting. There I created the dns entries by hand, and checkt with the google toolbox as suggested by certbot. this immediately returned the values I just created, but after I continued in certbot it threw the same error ...

6

In general ACME clients including Certbot do clean up after their work. Thus there shouldn't be any _acme-challenge.goalify.link TXT records after success or failure to get a certificate.

While not attempting to get a certificate and in an idle state, try removing all the _acme-challenge.goalify.link TXT records since there shouldn't be any at that point.

7

Is that true for all of the authoritative Name Servers?

Edit
I do see reports of DNS issues warnings:

8

Thanks again for your anwser.

Regarding those DNS warnings: You linked: That doesn't seem to be something I can fix, as it regards the configuration of the nameservers (if I understand that correctly)

No, I did not check all authoative name servers. Just openend the link certbot gave me and this provided the correct results for the records I just created.

But I will follow your advice and delete all records for _acme-challenges (I also used certbot in --manual mode so no cleanup there, but I always cleared them before rerunning the test). And then try again tomorrow, because one thing I noticed: I created those records with a rather long TTL of 3600 (which is the default at dnsimple). Maybe some caches where hit during my tests. For future tests I will reduce the ttl of these records to make it as short as possible.

Thanks again for your inputs ...

9

Also @wiggisser, keep an eye out for for more knowledgeable
Let's Encrypt community volunteers to assist. I could have easily missed something.

10

The TTL does not matter. Let's Encrypt looks at the authoritative DNS servers directly.

11

Thanks for your answer. But it seems the TTL was somehow connected to the issue. Because I waited for some time after the last test and I'm now creating the records with a TTL of 60s and everything works smoothly (also in repeated tests) at least in the staging environment. Not sure where the issue really was. Maybe it's also an issue with our dns-hoster, where the propagation was not fast enough to all 4 of their nameservers and at least one of them might have an old value cached ...

Won't do a run for production tonight anymore, as the issue isn't that urgent yet (our prodcution cert is still valid for > 25 days) and I don't want to break anything right now.

But again, thank you all for all your input ...

12

Perhaps that affected how rapidly the authoritative DNS servers sync'd between themselves. LE doesn't use a caching resolver so would not be affected.

Was the "wrong" TXT value always from the prior run? Or was it some apparently random value?

There is a problem with the delegations for goalifyapp.com but I don't see how it would affect this particular problem. Still, you might want to fix that. See: goalifyapp.com | DNSViz

com to goalifyapp.com The following NS name(s) were found in the authoritative NS RRset, but not in the delegation NS RRset (i.e., in the com zone): ns4.dnsimple.com, ns3.dnsimple.com See RFC 1034, Sec. 4.2.2.

Looks like DNSimple is making changes (or made changes) to their DNS Server names that isn't properly updated in this config.

13

Not sure about that. It wasn't a value that came up during my tests, but it could have been a value from the very first failed attempt ... Or maybe a value that was left over from a prior run that failed to delete (which could have made the first automatic run in production fail)

Thanks for the hint, will look into this.

14

Let's Encrypt won't get "stuck" on any particular wrong value. There often is 2 for wildcard certs and there may be leftovers from prior runs. LE scans all of them looking for the valid one for this request.

The error was "this was wrong" and "1 more". So, LE only saw two and shows just one of the values.

It sounds like, for some reason, the two from one request were being left behind and those were the two LE saw on the next request. Often there is a sleep period before a Certbot DNS plugin waits before LE checks but if too short LE will see the records before the DNS provider has sync'd its own servers. I say "sounds like" as that is the closest thing that explain at least some of it. It could be something else and it does not well explain why the two new ones eventually got written.