Certbox shows a different TXT from dig

I am trying to use certbot with a duckdns domain and I am using --manual because I am facing issues with different TXT records in certbot and Dig (DNS lookup)

My domain is: domain.duckdns.org

I ran this command: sudo certbot certonly --manual --preferred-challenges=dns -d domain.duckdns.org -v

It produced this output:

Please deploy a DNS TXT record under the name: _acme-challenge.domain.duckdns.org with the following value: sx3p-flneNANXWkq8iv8FcjVUizoE2Kutd__i54Z9lo. So I use the duckdns API to add this value and everithing seems to be fine since dig in my pc and in /toolbox.googleapps.com show the correct value but cerbot shows "" or an old value even after I clean it from duckdns.

My web server is (include version): nginx 1.22.1

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

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): no, just API

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

Hello @jaum20, welcome to the Let's Encrypt community. :slightly_smiling_face:

Using the DNS-01 challenge of the Challenge Types - Let's Encrypt and having an issue with _acme-challenge.<YOUR_DOMAIN> DNS TXT record without suppling the domain name makes it difficult to provide assistance.

However I suggest that you can use these two online tools to assist.

Please consider using the Staging Environment - Let's Encrypt until you've debugged the error; as the limits are much higher.

Also see:

2 Likes

How long do you wait after placing the TXT record and submitting the cert request to Let's Encrypt? Or, how long do you wait until after your manual changes and trying Certbot?

Because this is likely that the duckdns authoritative servers are taking longer to sync amongst themselves than whatever time you wait. This won't always be apparent testing from your local system or even that google toolbox. https://unboundtest.com is a much better way to check the TXT record as it uses a technique similar to Let's Encrypt (which walks the authoritative tree).

All of the authoritative DNS servers must reply properly to ensure good result. Right now I get repeated failures just querying the apex name duckdns.org. Try using https://unboundtest.com for an A record to that. Try it a few times in a row to see if it succeeds. It repeatedly fails for me. The output at the top will look like dig result. Unless it times out in which case the timeout message is at the bottom of very long output.

You are not the only one suffering duckdns issues. We have been seeing these more frequently in recent weeks.

2 Likes

https://dnsspy.io/scan/duckdns.org shows :frowning:

1 Like

Thanks to you all. Looks like the problem was with duckdns itself. I swiched to ipv64.net and everything worked as expected

4 Likes

Please note that DuckDNS as wel as IPv64 have third party DNS plugins for Certbot. For IPv64 I've found GitHub - XonaTheProtogen/certbot-dns-ipv64: certbot plugin for ipv64.net (might not be the only one, but it probably is; unfortunately it's not available using PyPi, but it does have some instructions on how to install it [although I wouldn't recommend that method]).

Automation using a plugin is preferred over the manual plugin.

2 Likes