ACME Says SERVFAIL Looking Up CAA, but No CAA Record Exists

An absent CAA record is valid. A failed CAA lookup is not. When an ACME order reports SERVFAIL looking up CAA, the certificate authority did not receive a trustworthy empty answer; it received a DNS failure and therefore cannot know whether an unseen policy forbids issuance. Adding a CAA record blindly does not repair that transport or validation failure.

Preserve the exact ACME error, compare recursive and authoritative answers, and repair the DNS owner before requesting another production certificate. Operators using cPanel should first separate this narrow response-code problem from broader AutoSSL hostname and DCV routing failures, because a working challenge path does not make CAA authorization optional.

No record and no usable answer are different states

CAA tells public certificate authorities which issuers may create certificates for a DNS name. RFC 8659 defines the record and its processing rules; it does not require every domain to publish a policy. With no relevant CAA record, issuance is normally unrestricted.

The response code creates the boundary. NOERROR with an empty answer says the lookup completed and found no CAA data at that name. SERVFAIL says resolution could not produce a trustworthy result. A CA must not reinterpret the second state as the first because the missing answer could hide a restrictive policy.

Let’s Encrypt’s current CAA documentation also calls out NOTIMP, timeouts and malformed responses. An authoritative server does not need a special CAA feature; it must handle the DNS query type correctly and return a normal empty response when no record exists.

Freeze three views before changing the zone

Copy the failed identifier and timestamp from the ACME client or control-panel log. Do not begin with the browser’s hostname, because a multi-name order can fail on a service subdomain or wildcard that visitors rarely type.

Query two validating recursive resolvers first:

DOMAIN=example.com
dig @1.1.1.1 "$DOMAIN" CAA +dnssec +comments
dig @8.8.8.8 "$DOMAIN" CAA +dnssec +comments

Record the status, flags, answer section and resolver used. A local caching resolver can preserve an earlier failure or hide a public one, so one successful workstation lookup is not enough evidence.

Next, discover the closest enclosing delegated zone before asking authoritative servers directly. The failed ACME identifier may be mail.example.com or *.example.com, neither of which must publish its own NS records. This read-only loop strips a wildcard label, climbs until it finds an explicit delegation, and fails closed when no zone can be identified:

FAILED_NAME=mail.example.com
NAME=${FAILED_NAME#\*.}
ZONE=$NAME
NS_LIST=
while [ -n "$ZONE" ]; do
  NS_LIST=$(dig "$ZONE" NS +noall +answer |
    awk -v owner="$ZONE." 'tolower($1)==tolower(owner) && toupper($4)=="NS" {print $5}')
  [ -n "$NS_LIST" ] && break
  [ "$ZONE" = "${ZONE#*.}" ] && break
  ZONE=${ZONE#*.}
done
if [ -z "$NS_LIST" ]; then
  echo "No enclosing delegated zone found; inspect the parent delegation" >&2
  exit 1
fi
printf 'failed name=%s delegated zone=%s\n' "$NAME" "$ZONE"
for NS in $NS_LIST; do
  printf '\n== %s ==\n' "$NS"
  dig @"$NS" "$NAME" CAA +norecurse +dnssec +comments
done

If the recursive NS lookup itself fails, use the registrar’s published delegation and dig +trace "$NAME" NS to identify the parent referral; do not guess the zone or continue with an empty server list. All delegated servers must answer coherently. One stale secondary can make renewal intermittent because the CA is free to reach a different authority than the resolver used during your test. Keep the raw output; copying only +short results discards the response code that distinguishes empty from broken.

Finally, separate delegation evidence from CAA policy scope. +trace shows how the query reaches authority, but it does not prove which parent or alias supplied the relevant policy. Query the failed name, every applicable parent label, and any effective CNAME target explicitly:

FAILED_NAME=mail.example.com
NAME=${FAILED_NAME#\*.}
dig +trace "$NAME" CAA

walk_caa() {
  label=${1%.}
  while [ -n "$label" ]; do
    printf '\n== CAA at %s ==\n' "$label"
    dig "$label" CAA +noall +answer +authority +comments
    [ "$label" = "${label#*.}" ] && break
    label=${label#*.}
  done
}

walk_caa "$NAME"
CURRENT=$NAME
DEPTH=0
while [ "$DEPTH" -lt 8 ]; do
  ALIAS_TARGET=$(dig "$CURRENT" CNAME +short | tail -n 1)
  [ -z "$ALIAS_TARGET" ] && break
  printf '\n== exact CAA query at alias target %s ==\n' "$ALIAS_TARGET"
  dig "$ALIAS_TARGET" CAA +noall +answer +authority +comments
  CURRENT=${ALIAS_TARGET%.}
  DEPTH=$((DEPTH + 1))
done

RFC 8659 climbs the original FQDN toward parent labels when the leaf has no relevant records, while CNAME and DNAME handling is left to the CA’s recursive resolver. For that reason, walk_caa climbs only the original name. Alias targets are queried exactly, one hop at a time, without applying the original-name parent algorithm to them. Compare those diagnostic receipts with the recursive CAA answer and stop at the first applicable policy rather than assuming the zone apex is the only possible source.

Let the failing response name its owner

Several defects produce the same ACME sentence, but they do not share one repair. Make the smallest correction supported by the DNS receipts.

DNSSEC validation is bogus

When validating resolvers return SERVFAIL while authoritative servers return signed data, inspect the DS-to-DNSKEY-to-RRSIG chain. A stale registrar DS, expired signature, missing DNSKEY or inconsistent signed denial response can make an empty CAA answer unverifiable. Follow the separate DNSSEC SERVFAIL chain diagnosis rather than disabling validation or adding an unsigned record beside a broken chain.

The unsigned comparison flag +cdflag can help identify a validation problem, but it is diagnostic only. If dig +cdflag returns data while the normal validating query fails, that contrast points toward DNSSEC; it does not make the insecure answer acceptable to the CA.

The server rejects an unfamiliar query type

Without DNSSEC, SERVFAIL can still come from an authoritative implementation that returns NOTIMP or another error for type CAA. The Let’s Encrypt CAA guide states that unknown query types should receive NOERROR with an empty answer, not a rejection.

Upgrade or reconfigure the authoritative software, DNS appliance or provider. Publishing 0 issue "letsencrypt.org" on one server cannot help if a firewall or another delegated server still rejects the query before a usable response returns.

Queries time out or fragment on the path

A timeout is not proof that CAA is unsupported. Firewalls, DNS proxies and inspection appliances may drop unfamiliar types, oversized DNSSEC responses, UDP fragments or TCP fallback. Compare small unsigned queries with CAA +dnssec, then test TCP explicitly:

dig @ns1.example.net example.com CAA +norecurse +dnssec
dig @ns1.example.net example.com CAA +norecurse +dnssec +tcp

If TCP works while UDP fails, inspect path MTU, fragmentation and DNS firewall behavior. When neither transport reaches one delegated server, repair reachability or remove that server from delegation only through the authoritative DNS change process. Do not open a broad firewall range merely to make one test green.

Authoritative servers disagree

Mixed serials, partial deployments and hidden-primary transfer failures can leave one nameserver returning NOERROR while another returns SERVFAIL or an old restrictive CAA policy. Compare SOA serials and the CAA response from every delegated NS; then correct zone distribution and wait for recursive caches to age out.

Traffic-steered DNS can intentionally vary answers, but certificate authorization still needs a coherent policy. Teams using regional authority should document Anycast and GeoDNS failure boundaries and prove that every reachable authority returns a compatible CAA result.

Repair authorization only after DNS is healthy

Once every authoritative server and validating resolver returns a usable answer, inspect the policy itself:

DOMAIN=example.com
dig "$DOMAIN" CAA +noall +answer +authority

For Let’s Encrypt, the documented issuer identifier is letsencrypt.org. issue governs ordinary issuance, while issuewild can govern wildcard identifiers. Parameters such as accounturi or validationmethods narrow authorization further; copying them from another account or ACME method can deny an otherwise valid request.

Policy changes should match the certificate workflow, not a tutorial’s sample. Record the current values, intended CA, wildcard requirement, ACME account and validation method before editing. After a DNS migration, include CAA in the broader post-migration DNS and HTTPS acceptance so an old provider policy does not surface only at renewal time.

Do not delete restrictive CAA records merely to make issuance easy. If the policy is intentional, update the ACME client or issuer to comply with it. Security control and operational availability both matter; the repair is the smallest change that restores the intended authorization.

Prove the repair in staging before production

Let’s Encrypt recommends its staging environment for troubleshooting. Staging certificates are not publicly trusted, which is exactly why they are useful during repeated tests. Configure the client through its documented staging switch or directory URL, run the same identifier set, and verify that the CAA stage completes.

Retrying before DNS caches converge can produce alternating results. Wait at least the relevant negative and zone TTLs, then repeat the two recursive queries and every authoritative query. The acceptance condition is agreement, not one lucky response.

If the DNS provider owns the authority and you cannot change its DNSSEC, firewall or query behavior, send the full error, timestamps, delegated NS list, per-NS CAA output, SOA serials and recursive comparisons. Where server and DNS ownership belong together, managed DNS operations can work from that evidence packet.

After staging succeeds, submit one production order. Preserve the order identifiers, requested names, issuer, challenge type and final certificate dates. A production success proves issuance, not deployment.

Close with both DNS and live-certificate receipts

First receipt: every delegated authoritative server and at least two validating recursive resolvers return the intended CAA policy or a trustworthy NOERROR empty answer. No server returns SERVFAIL, NOTIMP or timeout, and DNSSEC validation is secure when enabled.

Second receipt: the ACME production order succeeds for the exact identifier set, the certificate contains the intended SANs, and the real endpoint serves the new serial and validity dates. If issuance completes but clients still see the previous certificate, follow the separate renewed-certificate deployment path instead of reopening DNS authorization.

Do not close on “Certbot exited zero” alone. CAA protects the issuance decision; the live TLS check proves that the service actually adopted the result. Keeping both receipts makes the next renewal failure attributable instead of mysterious.