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

> Let's Encrypt's resolvers got SERVFAIL when checking your CAA records. Usually broken DNSSEC, a nameserver that mishandles CAA queries, or an outage.

Source: https://ssl.sh/errors/certbot-dns-problem-servfail-caa/
Last updated: 2026-11-10

**"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:

```text
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:

```bash
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](https://dnsviz.net/), 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:

```bash
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](https://ssl.sh/errors/lets-encrypt-rate-limit/) with repeated failed attempts.

Once lookups work, review what your CAA policy allows with the [CAA checker](https://ssl.sh/tools/caa-checker/) and build records with the [CAA generator](https://ssl.sh/tools/caa-generator/). Background is in [CAA records explained](https://ssl.sh/learn/caa-records/).

## How to verify the fix

1. `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.
2. DNSViz shows no errors for the zone.
3. `sudo certbot renew --dry-run` (or `certonly --dry-run`) completes against the staging environment.