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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command:
sudo certbot certonly
--apache
--cert-name buzz.deome.net
-d buzz.deome.net
--key-type rsa
--dry-run
It produced this output: Detail: DNS problem: SERVFAIL looking up A for buzz.deome.net
I created a new subdomain and pointed that directly with an A record rather than CNAME, and it works perfectly.
udo certbot certonly --apache
-d letest.deome.net
--dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Simulating a certificate request for letest.deome.net
The dry run was successful.
CloudFlare, and Google, are both finding my A record by successfully traversing the CNAME. What's wrong with LE?
The CNAME on your DNS server works fine, but the tplinkdns.com domain that you're delegating to is pretty broken. It has servers that don't reply, it has servers that don't think they're authoritative, and it has servers that don't know the difference between "no such record for that name" and "the name doesn't exist at all". Here's a DNSViz report with some details: https://dnsviz.net/d/buzz.deome.net/dnssec/
Peter's diagnosis fits what you are seeing, and the intermittent part is worth calling out. FYI, a resolver that already has the answer cached, or one that happens to hit a working authoritative server, can succeed, while a validating resolver that hits a broken one returns SERVFAIL. That is why Cloudflare and Google can look fine in one check and Let's Encrypt still fails in another.
If you want to pin it down before you change anything, try these in order:
Run the same lookup against each authoritative server for tplinkdns.com seperately, not just a public resolver, and note which ones time out or answer non-authoritatively.
Check the DNSViz report Peter linked for the specific errors, especially any DNSSEC or inconsistent answers across servers.
Use Let's Debug for buzz.deome.net after a change, rather than repeating dry runs, so you do not burn through failed validation attempts if the problem occured again.
For a fix, the reliable options are the ones Peter mentioned: get the delegated DNS fixed, or stop delegating to it. In practice that usually means pointing buzz.deome.net directly at an A record you control, as you did for letest, or moving the dynamic name to a provider whose authoritative servers answer consistently. If the TP-Link name must stay, keep its TTL low while you test, then raise it once a dry run passes cleanly.
Yes but it is worth noting that Let's Encrypt resolver walks the authoritative DNS tree each time and does not cache. That makes it distinct from a resolver that caches or doesn't walk the full tree.
TP-Link is the operator so that advice best applies to them not the OP. Given the intermittent nature knowing a failure from one client perspective isn't that helpful to tp-link. They have significant issues with their infrastructure as Peter already noted.
You can safely repeat "dry runs" without worrying about rate limits from excess tries. The LE staging system that is used for that is very forgiving. Let's Debug itself uses "dry runs" and the Staging system so that is no different than one you'd run yourself.
@sarahreid This reads very much like an AI assistant giving very broad and at times misleading advice. If it is, please refrain from posting AI material unless you are sure it is correct.