GoDaddy DNS failure

Help
1

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. crt.sh | 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: cps-parts.com

I ran this command: certbot certonly -d cps-parts.com

It produced this output:Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: cps-parts.com
Type: dns
Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.cps-parts.com - check that a DNS record exists for this domain

My web server is (include version): apache 2.4

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

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

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

I can see the TXT record being added to the GoDaddy DNS manager and I can find the record with dig -t TXT, but still failing authentication. Is this a problem with GoDaddy?

1 Like
2

Welcome @tmarracci

Is there a TXT record there right now? Because I don't see one. And Let's Encrypt Servers did not see one for that cert request.

Could you create one with a test value so we can check. There must be some difference between the panel you use to update it and the results in the public DNS system. If you place a TXT record we will check this.

2 Likes
3

I'm trying right now with a 5 minute propagation period. There is a TXT record there right now.

4

[root@50-0-0-21 ~]# dig -t TXT _acme-challenge.cps-parts.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.15 <<>> -t TXT _acme-challenge.cps-parts.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28823
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1410
;; QUESTION SECTION:
;_acme-challenge.cps-parts.com. IN TXT

;; ANSWER SECTION:
_acme-challenge.cps-parts.com. 3600 IN TXT "m9KW3sqrX9hlmu5cDpGdx5fQmOpf6MzhoeJqbnoBMow"

;; Query time: 6 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed May 22 13:47:37 PDT 2024
;; MSG SIZE rcvd: 114

5

I guess 5 minutes is the ticket. It finally got a positive responsive and renewed my certificate.

How do I change my config file so future unattended renewals will wait that long?

6

If you're manually adding/removing the TXT RR, there's nothing unattended regarding renewals. That's only possible if the adding/removing of the TXT RR is done automatically.

1 Like
7

The Let's Encrypt servers query the authoritive DNS servers directly. So, whatever delay is needed is only for your auth servers to sync your change. There is no "propagation" delay like with resolvers.

With --manual you just have to wait as Osiris already noted. You could use the below site to query the auth servers and watch for the TXT record you placed to show up.
https://unboundtest.com

You could do it with a dig command too. But, query the auth server(s) directly and don't rely on your resolver.

6 Likes
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.