Let's Encrypt DNS-01 Fails: "DNS Problem: NXDOMAIN Looking Up TXT"

The validation query for _acme-challenge.<domain> returned NXDOMAIN. Either the record was never created or — the sneaky one — you're requesting a name that doesn't exist in public DNS.

What you'll see

Root causes

Domain (or a SAN in the request) not in public DNS

certbot -d a.example.com -d b.other.com fails if either name has no delegation at all. The NXDOMAIN names the offending one: dig NS for it before blaming certbot.

Plugin didn't create/propagate the TXT record

Wrong API token scope (Cloudflare zone-limited vs account), wrong zone selected, or propagation delay — Let's Encrypt hits authoritative servers that haven't seen the new TXT yet. dig TXT _acme-challenge.<domain> +short from outside verifies.

CAA records forbidding issuance

A CAA record restricting which CA may issue (or issuewildcard) produces a different validation failure worth checking when 'config looks right'.

Fix it

  1. Confirm the domain actually exists in DNS
    dig NS <domain> +short ; dig TXT _acme-challenge.<domain> +short
  2. Check the API token/zone scope for the DNS plugin
    # cloudflare: token needs Zone:DNS:Edit on the specific zone (and Zone:Read to list it)
  3. Set dns_propagation_delay if the provider is slow
    # certbot-dns-cloudflare: dns_cloudflare_propagation_seconds = 60 (or use --dns-propagation-seconds)
  4. For private/wildcard names: fix the request, not DNS
    # *.internal.example.com requires the parent zone public delegation for dns-01; internal-only names can't pass Let's Encrypt — use a private CA or Origin CA for those

Field note

dig TXT from an external resolver (1.1.1.1) is the truth: if the record isn't visible there, Let's Encrypt can't see it either. NXDOMAIN vs SERVFAIL differs: NXDOMAIN = name doesn't exist (request/zone problem), SERVFAIL = resolver problem. Read which one the log says.

Common questions

Why does the wildcard fail when the base domain works?

*.example.com via dns-01 needs the TXT record to exist and propagate from the authoritative servers — and the challenge is placed at the zone apex. Check the record publicly with dig before re-running certbot.

How long should I wait for TXT propagation?

Most providers seconds-to-a-minute; slow ones need dns_propagation_seconds raised (60-120). Verify with dig @1.1.1.1 — visible there means nearly globally visible.

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.

Get new fixes by email

One short email when new fixes and production templates drop. No spam, unsubscribe anytime.

Partner pick — sponsored

Vultr — our performance pick for this stack

High-frequency cloud servers in 32 locations — deploy in 60 seconds, pay by the hour.

Get Vultr →
Also vetted

DigitalOcean — Predictable flat-bandwidth cloud — $200 credit for new accounts.

Get DigitalOcean →

We earn a commission if you buy through our links — it never costs you extra. More vetted tools on our picks hub · comparing clouds? DigitalOcean vs Vultr and vs AWS · full deals: DigitalOcean · Vultr · NordLayer · Semrush