I have no CAA records at all. Why does a CAA lookup fail?

Let's Encrypt must still ask. A correct nameserver answers NOERROR with an empty answer, which means no restrictions. SERVFAIL means the question could not be answered, which the CA cannot treat as "no CAA".

Will adding a CAA record fix it?

Only if the nameserver's problem is specifically with empty CAA answers, which is uncommon. If DNSSEC is broken or the server rejects the CAA type, adding a record changes nothing. Diagnose the lookup with dig CAA first.

It worked an hour ago with the same domain. Why does it fail now?

SERVFAIL is often intermittent: one of several nameservers is broken, DNSSEC signatures expired, or an anti-DDoS system dropped queries. Let's Encrypt queries from multiple network perspectives, so one bad server can be enough. Query every nameserver directly.

What is the difference from "CAA record for example.com prevents issuance"?

That error means the lookup worked and a CAA record names other CAs. See CAA record prevents issuance. SERVFAIL means the lookup itself failed.

Certbot "DNS problem: SERVFAIL looking up CAA": causes and fix

"DNS problem: SERVFAIL looking up CAA" means Let's Encrypt could not get an answer to its CAA query for your domain, so it refused to issue. The resolver got SERVFAIL, a DNS server failure, instead of records or an empty reply. Let's Encrypt's documentation names broken DNSSEC as the most common cause, followed by nameservers that mishandle CAA queries.

The message and its variants

Certbot prints the CA's error, which names the domain and blames its nameservers:

Detail: While processing CAA for example.com: DNS problem: SERVFAIL looking up CAA for
example.com - the domain's nameservers may be malfunctioning

The name after "for" may be a parent domain (for www.example.com the CA also checks example.com) or a CNAME target. When the resolver supplies an Extended DNS Error, Boulder words it differently, for example DNS problem: looking up CAA for example.com: DNSSEC: Bogus, which points straight at DNSSEC. Some failures inside the resolver itself are reported as DNS problem: server failure at resolver looking up CAA for example.com. The same message can come from Certbot, acme.sh, win-acme or any other ACME client, because the text is produced by Let's Encrypt's server and only passed through by the client.

How CAA lookup works

RFC 8659 says the search for a CAA record set "climbs the DNS name tree" from the requested name toward the root until it finds one. For shop.www.example.com, the CA queries shop.www.example.com, then www.example.com, then example.com. Let's Encrypt notes that CAA checking follows CNAME redirects like any other DNS query. Any SERVFAIL along that path stops issuance.

Let's Encrypt also rechecks CAA when you finalize an order if the domain was validated more than 7 hours before, so a cached authorization does not protect you.

Common causes, most frequent first

1. Broken DNSSEC

A DS record at the registrar that no longer matches the zone's keys, typically after moving DNS to a new provider without updating or removing DS; expired signatures; or a signing bug with empty answers. RFC 8659 notes that at least two live-signing servers had bugs returning signed empty CAA answers. Check:

dig CAA example.com +dnssec @1.1.1.1
dig CAA example.com +cd @1.1.1.1

SERVFAIL without +cd but an answer with +cd (checking disabled) means DNSSEC validation fails. Visualise the chain at DNSViz, which Let's Encrypt recommends as the first step.

2. The nameserver rejects CAA queries

Some authoritative servers answer NOTIMP or REFUSED for record types they do not know. Let's Encrypt calls this an RFC 1035 violation: the correct reply is NOERROR with an empty answer. Ask each authoritative server directly:

dig NS example.com +short
dig CAA example.com @ns1.example-dns.net +norecurse

3. Firewalls or anti-DDoS systems dropping queries

RFC 8659 describes middleboxes that drop DNS packets of unknown types, especially when they think they are under attack. The result is a timeout or SERVFAIL, often intermittent.

4. Subdomain delegated to a private or broken nameserver

A subdomain whose NS records point to an internal IP, or to servers that no longer host the zone (lame delegation). RFC 8659 says CAs receive SERVFAIL in that case. Check dig NS sub.example.com and query each listed server.

5. A CNAME target with failing DNS

www.example.com is a CNAME to a CDN or SaaS hostname whose nameservers fail the CAA query. The fix belongs to the target's operator, or you remove the CNAME.

6. A temporary outage

Authoritative servers that are down or overloaded. Retry later and check your DNS provider's status page.

How to fix it

Fix the DNS failure itself; adding or changing CAA records rarely helps.

DNSSEC: make the DS record at the registrar match the current DNSKEY, or remove DS entirely if the zone is no longer signed. Wait for the old DS TTL to expire before retrying.
NOTIMP or REFUSED: ask the DNS provider to fix CAA handling, or move the zone to a provider that supports CAA.
Delegations: remove or fix NS records that point to private or decommissioned servers.
CNAME targets: report it to the provider, or point the name elsewhere.
Outages: retry with backoff; avoid hitting rate limits with repeated failed attempts.

Once lookups work, review what your CAA policy allows with the CAA checker and build records with the CAA generator. Background is in CAA records explained.

How to verify the fix

dig CAA example.com @1.1.1.1 and dig CAA example.com @8.8.8.8 return status: NOERROR, with or without records, for the name and each parent and CNAME target.
DNSViz shows no errors for the zone.
sudo certbot renew --dry-run (or certonly --dry-run) completes against the staging environment.