Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: hellobetty.com
Type: dns
Detail: DNS problem: SERVFAIL looking up A for hellobetty.com - the domain's nameservers may be malfunctioning
Domain: www.hellobetty.com
Type: dns
Detail: DNS problem: SERVFAIL looking up A for www.hellobetty.com - the domain's nameservers may be malfunctioning
Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
Failed to renew certificate hellobetty.com with error: Some challenges have failed.
So i thought there were problems with the DNS but if i ran a nslookup or a dig on the domain i get no issue, i also went to "https://dnschecker.org" to see if they would report something different and there did no seem to be any issue with DNS.
Thank you,
but actually those errors are caused by me changing the DNS servers in an attempt at solving the issue, the new servers did no support DNSSEC.
I reverted to the old ones.
BTW, great tool the hellobetty.com | DNSViz I re-ran the test and now it reports an error UDP connection refused. The inyteresting thing is that it is looking up ns1.makeko.com and ns2.makeko.com but using the IP's that these two domain name servers had about a month ago, not the current ones...
You can see a hint about this issue when you hoover over the warning at the big fat delegation arrow between the .com and hellobetty.com zones: it hints about a mismatch between the glue records and the authorative records for the nameservers of your domain. A glue record is an extra A resource record for a nameserver provided by a nameserver. So if you'd ask the .com nameserver for the domain example.com it would answer with "You can find the answer at the nameservers for example.com at nameserver.example.org" and it would also provide the IP address (through an A record) for that nameserver.example.org. This is very useful as the DNS resolver can immediately connect to the IP address without making an extra lookup for the nameserver!
However, in your case the glue records provided by the .com nameservers is NOT the same as the A records from the authorative nameservers. Please appreciate the following output (asking the .com nameservers):
osiris@erazer ~ $ dig @a.gtld-servers.net hellobetty.com
; <<>> DiG 9.16.12 <<>> @a.gtld-servers.net hellobetty.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56038
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hellobetty.com. IN A
;; AUTHORITY SECTION:
hellobetty.com. 172800 IN NS ns1.makeko.com.
hellobetty.com. 172800 IN NS ns2.makeko.com.
;; ADDITIONAL SECTION:
ns1.makeko.com. 172800 IN A 67.221.179.3
ns2.makeko.com. 172800 IN A 67.221.179.5
;; Query time: 23 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Wed Nov 17 18:11:38 CET 2021
;; MSG SIZE rcvd: 118
osiris@erazer ~ $
An incorrect glue record is especially important when there's a catch22 when resolving an authorative nameserver. E.g., if the nameservers for example.com are ns1.example.com and ns2.example.com: the resolver would not know the IP addresses for ns1.example.com or ns2.example.com, annd it wouldn't be able to resolve those IP addresses, because it would need those IP addresses to do so! The only way to bypass this catch22 is to have a glue record. (By the way, this catch22 issue isn't present with your setup, but it signifies the importance of nameserver glue records.)
If you can't fix this yourself, your DNS service provider should be able to.