Dns-01 No TXT record found at _acme-challenge.domain.tld

Hi all, I'm banging my head since days to get done renewal of my domains. Sample:

My domain is: adopteunmanchot.com

I ran this command: certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/bind/rfc2136/ini --dns-rfc2136-propagation-seconds 360 -d adopteunmanchot.com

It produced this output:Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for adopteunmanchot.com
Encountered exception during recovery: certbot.errors.PluginError: Encountered error when making query: The DNS operation timed out.
Encountered error when making query: The DNS operation timed out.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):

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

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):yes

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

I got also the error if I use renew
root@keewi:~# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/adopteunmanchot.com.conf


Renewing an existing certificate for *.adopteunmanchot.com and adopteunmanchot.com

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: adopteunmanchot.com
Type: unauthorized
Detail: No TXT record found at _acme-challenge.adopteunmanchot.com

Domain: adopteunmanchot.com Type: unauthorized
Detail: No TXT record found at _acme-challenge.adopteunmanchot.com

Hint: The Certificate Authority failed to verify the DNS TXT records created by the --manual-auth-hook. Ensure that this hook is functioning correctly and tha
t it waits a sufficient duration of time for DNS propagation. Refer to "certbot --help manual" and the Certbot User Guide.

Failed to renew certificate adopteunmanchot.com with error: Some challenges have failed.

I use bind and manage myself the DNS servers. This setup was working like ages, DNS entries are OK as shown with https://unboundtest.com/m/TXT/_acme-challenge.adopteunmanchot.com or dig -t TXT _acme-challenge.adopteunmanchot.com

What could be the problem ?

Thanks for your support

Daniel

2 Likes

Let's Encrypt recently upgraded unbound from 1.16 to 1.18 and then promptly to 1.19

When you tried unboundtest, did you check each version? Right now I do not see a TXT record at that domain and your test result link has expired.

I see a number of issues testing with this EDNS Compliance checker. If I had to guess your problem is related to something in those results.

That said, while we saw just a few non-compliant DNS servers fail with 1.18 we haven't seen a pattern of failures with 1.19 (yet).

https://ednscomp.isc.org/ednscomp/0f16fd95cb

5 Likes

For unboundtest I tested against 1.19 & 1.18, both showing TXT records. No need to follow the link, enter _acme-challenge.adopteunmanchot.com, add for TXT and your done.

I also tested on https://www.nslookup.io => Authoritavive servers, TXT is shown as it is on Google DNS and OpenDNS. It fail on Cloudfare.

At https://ednscomp.isc.org, if you enter one of the authoritative servers you also get TXT records. This zone does only have SOA and TXT record.

In a terminal, run dig _acme-challenge.adopteunmanchot.com TXT and record-s are shown.

Really don´t understand why it fail and how to solve this.

I see now. I was only using unboundtest.com to test and it shows no result. I just tried my own test server and see all the TXT records (more than 80).

The large number of TXT records is likely the reason Let's Encrypt is rejecting it.

I don't know how you ever saw them with unboundtest. Even with 1.16 I don't see any TXT values (below pic from this result)

There was a change in 1.18 that affected some people but yours fails even on 1.16 so I think it is just because of this:

You can have multiple TXT records in place for the same name. For instance, this might happen if you are validating a challenge for a wildcard and a non-wildcard certificate at the same time. However, you should make sure to clean up old TXT records, because if the response size gets too big Let’s Encrypt will start rejecting it.

From here: Challenge Types - Let's Encrypt

4 Likes

Full log from Unbound

Extract

Okay. Your DNS servers are even messier than I saw earlier.

Each of your servers responds with different results. And, you can partly see this using unboundtest (but also snip below).

Using unboundtest.com and 1.16 I see a single TXT value response but only about 1 out of every 3 or 4 tries. The other tries get no value. This is likely the response from your dns2.tootai.net server.

With 1.19 I was not able to see any value responses. Not sure why.

From my own test server (snips)

##### ns1 returns no answers
dig TXT _acme-challenge.adopteunmanchot.com @ns1.tootai.net

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> TXT _acme-challenge.adopteunmanchot.com @ns1.tootai.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65531
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1

##### ns2 returns 1 answer (the value starting with "ozdH")
dig TXT _acme-challenge.adopteunmanchot.com @ns2.tootai.net

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> TXT _acme-challenge.adopteunmanchot.com @ns2.tootai.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38164
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
_acme-challenge.adopteunmanchot.com. 60 IN TXT  "ozdHPrc8CYSfxsB71dlbXi1km9Z-BWvJIoLuG-HIrus"

##### ns3 returns 86 answers
dig TXT _acme-challenge.adopteunmanchot.com @ns3.tootai.net
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> TXT _acme-challenge.adopteunmanchot.com @ns3.tootai.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25825
;; flags: qr aa rd; QUERY: 1, ANSWER: 86, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d9f0e19adc5dcffe0100000065a17348477d8759dda0847b (good)
;; QUESTION SECTION:
;_acme-challenge.adopteunmanchot.com. IN        TXT

;; ANSWER SECTION:
_acme-challenge.adopteunmanchot.com. 86400 IN TXT "eQXfde17PtcR810Bir0YfHRu9AJ-cSVUNy5jv7rBR4k"
_acme-challenge.adopteunmanchot.com. 86400 IN TXT "lXa1kKM64J7mpa08qn_DbbuHov8eRm5egP1qIiYysFs"
_acme-challenge.adopteunmanchot.com. 86400 IN TXT "WqLgobRCVNkamoMAJgR54qtYKeM4sXWf363zuWdmoZc"
(numerous other values omitted)
4 Likes

What I said above can be seen in graphic form at
https://dnsviz.net/d/_acme-challenge.adopteunmanchot.com/dnssec/

The dnsviz site tree looks nice for your root domain but not for _acme-challenge
https://dnsviz.net/d/adopteunmanchot.com/dnssec/

3 Likes

So, forget about domain adopteunmanchot.com, I have other domains to renew.

Reminder: 20 October 2023 renewal was done without any problem.

This the output of another renew for a domain with DNS in the same state that 3 monthes ago. If you want you can also test tootai.net tic.alsace terek.biz jaless-spices.eu, all of them setted up with dns01, renewal OK in october and failing today. All of them looking OK on dnsviz for subdomain _acme-challenge.

For alsace.eu.org:
root@keewi:~# certbot certonly -v --dns-rfc2136 --dns-rfc2136-credentials /etc/bind/rfc2136/ini --dns-rfc2136-propagation-seconds 60 -d alsace.eu.org -d *.alsace.eu.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-rfc2136, Installer None
Requesting a certificate for alsace.eu.org and *.alsace.eu.org
Performing the following challenges:
dns-01 challenge for alsace.eu.org
dns-01 challenge for alsace.eu.org
Cleaning up challenges
Encountered exception during recovery: certbot.errors.PluginError: Unable to determine base domain for _acme-challenge.alsace.eu.org using names: ['_acme-challenge.alsace.eu.org', 'alsace.eu.org', 'eu.org', 'org'].
Unable to determine base domain for _acme-challenge.alsace.eu.org using names: ['_acme-challenge.alsace.eu.org', 'alsace.eu.org', 'eu.org', 'org'].
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

For tootai.net
root@keewi:~# certbot certonly -v --dns-rfc2136 --dns-rfc2136-credentials /etc/bind/rfc2136/ini --dns-rfc2136-propagation-seconds 60 -d tootai.net -d *.tootai.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-rfc2136, Installer None
Requesting a certificate for tootai.net and *.tootai.net
Performing the following challenges:
dns-01 challenge for tootai.net
dns-01 challenge for tootai.net
Cleaning up challenges
Encountered exception during recovery: certbot.errors.PluginError: Received response from server: REFUSED
Received response from server: REFUSED
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

I don't understand the connection REFUSED as a simple dig tootai.net TXT from any server outputs the records. Same for alsace.eu.org

Why until october everything worked perfectly (I count a max of 79 records in _acme files) and now this mess.

Why does your _acme-challenge.tootai.net have so many TXT records?

You should (must) remove older unused records as I described earlier. You can see on https://unboundtest.com that no TXT records are being seen. I am not sure why you see REFUSED but you should start by cleaning up the TXT records

3 Likes

2 posts were split to a new topic: Problems with DNS TXT requests

I modified DNS records for adopteunmanchot.com and now I receive for certbot certonly

Incorrect TXT record "ozdHPrc8CYSfxsB71dlbXi1km9Z-BWvJIoLuG-HIrus" found at _acme-challenge.adopteunmanchot.com

despite the fact that unboundtest shows record with 1.19 and 1.16 version

For other domains "certbot renew" still gives No TXT record found. What to notice is that despite the fact that all TXT records where purged, they are still showned with
dig <_acme-challenge.domain.tld> TXT

Please give specific domain name example

Each new cert request will have a new TXT value that must appear in the DNS. That value is old as we saw it earlier in this thread. You need to find out why your TXT record is not being updated by your dns-rfc2136 plugin.

Further, your 3 nameservers don't respond the same way. Your ns2 does not show any TXT record so you will get inconsistent results until you get your nameservers in sync.

dig +noall +answer TXT _acme-challenge.adopteunmanchot.com @ns1.tootai.net
_acme-challenge.adopteunmanchot.com. 86400 IN TXT "ozdHPrc8CYSfxsB71dlbXi1km9Z-BWvJIoLuG-HIrus"

dig +noall +answer TXT _acme-challenge.adopteunmanchot.com @ns2.tootai.net

dig +noall +answer TXT _acme-challenge.adopteunmanchot.com @ns3.tootai.net
_acme-challenge.adopteunmanchot.com. 86400 IN TXT "ozdHPrc8CYSfxsB71dlbXi1km9Z-BWvJIoLuG-HIrus"

While resolving that problem you should also review the issues shown by dnsviz
https://dnsviz.net/d/_acme-challenge.adopteunmanchot.com/dnssec/

4 Likes

Is there some reason you need to use your own nameservers?

Because with all your DNS problems changing to a well-supported provider like Cloudflare might be easier.

3 Likes

Mike. My DNSs are messy at this time ONLY with TXT records and ONLY while trying to get Letsencrypt DNS renew working again ! Remember: was working like a charm since ages and would prefer to continue to use it insteed of http. Deadline is 18/01.

I was just about to post the info below the dashed line but I now see your DNS servers are responding SERVFAIL using 1.16 and 1.19. That is not acceptable. The test results from dnsviz are slightly different now too. I am not sure what more I could say anyway. I agree something has changed but I don't see that you have a stable DNS config. I wish you good luck.

unboundtest 1.16 and 1.19 both show:

Check out these results too. The LAME and Error message are probably caused by the same thing.
https://dnsviz.net/d/_acme-challenge.adopteunmanchot.com/dnssec/

=======================================

Have you sorted out why your plugin did not add the fresh record to your DNS as I described in post #12?

For testing, you could try this

sudo certbot certonly --dry-run --manual --preferred-challenge dns-01 -d adopteunmanchot.com

The --dry-run uses the LE Staging system and won't affect any existing production certs

When you run this command it will show you a value to place in your DNS. Use the 3 commands I showed in post #12 to check each of your nameservers.

The --manual method also cannot be automated. But, if this works you know to focus on your DNS plugin. Given you had so many TXT records initially it wasn't working fully as it should have for a long time.

If this doesn't work you can focus on your DNS servers themselves.

3 Likes

I restarted from 20/10/2023 DNS setup, removed certbot from Debian12 and install the one coming from snap, certbot 2.8.0

Now for adopteunmanchot.com I receive for certbot certonly

During secondary validation: Incorrect TXT record "7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE" found at _acme-challenge.adopteunmanchot.com

Checking on unbound this is the sole TXT record shown and dnsviz display the zone without error.

What does the above log mean ?

1 Like

Yes, tests look much better now.

Hmm. That's a little odd for that to say Incorrect TXT record from a secondary site.

Almost always we see a secondary failure only after the primary Let's Encrypt data center succeeds. LE tries from various global points.

It is odd the secondary sees an incorrect record if the primary worked.

I think the message may be a little misleading in this instance.

Are your DNS Servers in different locations? Is it possible they take more than 60 seconds to sync between them? If so, try increasing this to, say, 600, just for this test. You can try lower values later if this resolves it.

--dns-rfc2136-propagation-seconds DNS_RFC2136_PROPAGATION_SECONDS
The number of seconds to wait for DNS to propagate
before asking the ACME server to verify the DNS
record. (default: 60)

Or, do you have any firewall in front of your DNS Servers? Maybe even a firewall that blocks DDoS attacks? Because LE issues a lot of queries in a short time from different global spots. Some DDoS blocks that are set too sensitive can end up rejecting LE queries. Still, I would expect to see a timeout or comms failure rather than an "Incorrect TXT" if this was the problem.

3 Likes

This always means it failed to find the value it was looking for on one or more of your nameservers. Extend the default propagation seconds to 120 or higher and see if that helps. You can also see how your servers are responding by running :

dig -t TXT _acme-challenge.adopteunmanchot.com @ns1.tootai.net +short  
dig -t TXT _acme-challenge.adopteunmanchot.com @ns2.tootai.net +short  
dig -t TXT _acme-challenge.adopteunmanchot.com @ns3.tootai.net +short    

I note that ns2 is currently returning different results.

1 Like

On my side, from an external server, I receive the same TXT records from both 3 servers and unbound and dnsviz are still OK.

Servers are in 3 different locations: 2 in Germany, 1 in France. I will test with an increased time propagation.

1 Like