Skip to content

← Blog

ACME DNS Challenge: Verify TXT Propagation as DNS-PERSIST-01 Emerges

By Nick Phillips, Founder

ACME DNS Challenge: Verify TXT Propagation as DNS-PERSIST-01 Emerges

DNS and certificate sketches frame the title

DNS-01 proves domain control by asking you to publish a TXT record at _acme-challenge and is required when you need wildcard certificates or when HTTP and TLS checks cannot reach the host. It is slower to set up than HTTP-01, since it needs DNS write access, but it is the only validation path that works for wildcards and for servers that cannot be reached over HTTP or TLS.

TL;DR:

  • For a publicly reachable server without a wildcard requirement, the simpler HTTP challenge usually works; private hosts and wildcard certificates require DNS validation.
  • Automate renewals through your DNS provider’s API, and delegate the challenge name to a validation only zone so leaked credentials cannot alter production DNS.
  • Check the TXT value through multiple public resolvers before CA validation, allow time for caching delays, and automatically remove challenge records afterward.
  • The persistent challenge can eliminate DNS writes at each renewal, but it remains a draft; confirm client and certificate authority support in staging before production.
Otterwatch
Keep Certificate Renewals on Your Radar
Otterwatch watches your SSL certificates and gives you a friendly heads up before they expire, while quietly checking that your sites are up.
Visit Otterwatch

Table of Contents

How DNS-01 validation works: tokens, TXT values, and the CA check

When your ACME client requests a certificate, the certificate authority issues a token tied to an authorization for that domain. Your client combines the token with your account key to produce a value, then publishes it as a TXT record. The CA looks up that record and, if the value matches what it expects, marks the domain authorized.

The record always lives at a predictable spot: _acme-challenge.<your_domain>. For example.com, that is _acme-challenge.example.com. The CA queries this name directly, which is why the record has to be visible from the public internet, not just your internal resolver.

This mechanism is what makes wildcard issuance possible at all, and it is the reason DNS-01 works even when ports 80 and 443 are closed or the host is not publicly reachable. According to Let’s Encrypt’s challenge documentation, DNS-01 is the only challenge type that supports wildcard certificates and the only one that does not require the host to answer HTTP or TLS traffic.

  • The TXT value is derived from the token and your account key, not something you choose yourself.
  • The record name is fixed at _acme-challenge.<domain>, regardless of which ACME client you use.
  • Wildcard certificates (*.example.com) can only be validated this way.

When to pick DNS-01: use cases and tradeoffs

DNS-01 earns its keep in a few specific situations: wildcard certificates, hosts that sit behind a VPN or private network, multi-server setups where no single machine owns port 80, and internal services that never touch the public web on HTTP or TLS. If any of those describe your setup, DNS-01 is not optional, it is the only route in.

The tradeoff is operational weight. Every renewal normally means another DNS write, unless you are using a delegated zone or a persistent method like DNS-PERSIST-01 (more on that below). That means you need either a DNS provider with a decent API or a delegation pattern that keeps credentials out of your main zone.

  • Pick DNS-01 for wildcards, private hosts, or any server that cannot be reached over HTTP or TLS.
  • Expect a DNS write (and a brief propagation wait) at every renewal unless you delegate or adopt a persistent challenge method.
  • Pair your renewal automation with certificate monitoring, since a quiet DNS failure can let a cert expire without anyone noticing until it is too late.

Publishing the TXT record: manual edits, DNS provider APIs, and CNAME delegation

The target name never changes: _acme-challenge.example.com. The content is a short, opaque string your ACME client computes from the authorization token, and it is only valid while that specific validation attempt is pending.

  1. For a one-off certificate, you can log into your DNS provider’s dashboard and add the TXT record by hand, which is fine for a single domain you rarely touch.
  2. For anything you plan to renew automatically, use your DNS provider’s API so your ACME client (Certbot, acme.sh, Lego, and similar tools all support this) can publish and remove the record without a human involved.
  3. For better credential hygiene, set up CNAME delegation: point _acme-challenge.example.com to a separate, validation-only zone, so your ACME client only ever touches that zone instead of your production DNS. Let’s Encrypt describes this as DNS alias mode, where _acme-challenge.yourdomain.com is a CNAME to something like validationdomain.com, and multiple domains can share the same alias target.

Once you set up the CNAME delegation, leave it in place. Removing it after the first successful issuance breaks every future renewal, since your automation will keep writing to a zone the CA no longer checks.

Pro Tip: If you manage several domains, point them all at the same validation zone through CNAME delegation so one small, scoped DNS zone handles every renewal instead of your production DNS.

Automation and propagation: verify before you trigger validation

DNS propagation is not instant and not uniform. Anycast routing and resolver caching mean a record can be visible from one resolver and missing from another for a stretch of time, which is exactly the kind of thing that fails a renewal for no obvious reason.

The fix is to verify before you tell the CA to check. Query the TXT record from a couple of public resolvers (or through your DNS provider’s own API, which usually confirms to write immediately) and only trigger CA validation once the value shows up consistently. Propagation delays tied to anycast distribution and caching are a recognized source of DNS-01 failures, and well-built clients build in a wait, sometimes up to an hour, rather than assuming the first check will succeed.

Cleanup matters just as much as publishing. Leaving old TXT records in place after a successful renewal bloats the DNS response for that name, and enough accumulated records can eventually cause validation failures on their own.

  • Verify the TXT value from an external resolver or your provider’s API before triggering the CA check.
  • Build in a wait and retry window rather than failing on the first lookup.
  • Remove the per-challenge TXT record automatically once validation succeeds.
  • Use scoped API credentials, or delegate to a validation-only zone, so a leaked key cannot touch your production DNS.

DNS-PERSIST-01: what it is and why it is still early

DNS-PERSIST-01 is a newer validation model that lets you set up a long-lived authorization record once, instead of writing a fresh TXT value at every renewal. According to Let’s Encrypt’s 2026 announcement, the goal is to remove the per-renewal DNS write entirely once the persistent record is in place, which is a meaningful win for IoT fleets, multi-tenant platforms, and anyone batching issuance across many domains.

The catch is that it is still a draft, and support is inconsistent across CAs and ACME clients, with staging environments sometimes ahead of production. Community reports on the Let’s Encrypt forum describe client behavior varying by which draft version a tool implements, and a related thread notes that dns-persist-01 may show up alongside dns-01 in the authorization object, so clients need to expose unknown challenge types rather than silently ignoring them.

  • Set up once, skip the per-renewal DNS write, which is the core benefit.
  • Useful for IoT, multi-tenant, and high-volume batch issuance.
  • Still draft status: test in staging first and confirm your client and CA both support it before relying on it in production.
  • Protect your account key carefully, since a persistent authorization raises the stakes if it leaks.

Troubleshooting checklist: quick checks when validation fails

  1. Query _acme-challenge.<domain> from two or three public resolvers to confirm the TXT value actually matches what your client published.
  2. Check for a stray CNAME, a leftover TXT record from a previous attempt, or a response that has grown too large.
  3. Give it more time. Propagation delays are common, so wait and re-check before assuming something is broken.
  4. Confirm your client is writing to the correct zone, especially if you are using CNAME delegation, and that your cleanup step is not deleting the wrong record.

Small-team rules of thumb

If you cannot hand out full DNS credentials to every tool that needs to renew a cert, delegate. A CNAME to a validation-only zone keeps the blast radius small. Verify propagation programmatically rather than trusting a single lookup, and automate cleanup so old TXT records do not pile up. None of that replaces a second set of eyes watching for renewals that quietly never finished.

Small-team rules of thumb — overview diagram

Where Otterwatch fits after your DNS automation runs

Automating DNS-01 removes a lot of manual work, but it also means a failure can happen quietly, somewhere in a script or a cron job, with nobody watching until a visitor hits a certificate warning. We built Otterwatch to sit alongside that automation as a calm, low-noise backstop: we watch certificate expiry and site reachability and send a plain heads up well before anything lapses, no dashboards, no alarm language.

Otterwatch

Monitoring is free for a limited number of sites with no credit card required, and our Pro plan extends that coverage with deeper certificate monitoring for teams managing more domains. Current prices are on our pricing page. If you just want a quick sanity check right now, run your domain through our Free SSL Certificate Checker and see exactly what is currently issued.

FAQ

Can I delete the _acme-challenge record?

Yes, and you generally should once validation succeeds. Per-challenge TXT values are only needed during the validation window, and leaving old ones in place can bloat DNS responses and contribute to future validation failures.

Is ACME DNS validation safe?

It is safe when you scope credentials carefully. Using a delegated, validation-only zone through CNAME delegation, rather than handing your ACME client full access to your production DNS, keeps a leaked key from affecting anything beyond certificate validation.

Should I use DNS-01 instead of other challenge types?

Use DNS-01 when you need a wildcard certificate or when your host cannot be reached over HTTP or TLS, since it is the only challenge type built for those cases according to Let’s Encrypt. For a single publicly reachable server without wildcard needs, HTTP-01 is usually simpler to automate.

How do I set up ACME DNS validation?

Point your ACME client at your DNS provider’s API so it can publish a TXT record at _acme-challenge.<domain> and remove it after validation. For better credential hygiene, delegate that name to a separate validation zone with a CNAME before you start issuing certificates.

Sources

Start with Let’s Encrypt’s challenge types documentation for the full protocol breakdown, and the DNS-PERSIST-01 announcement for where that draft stands. For DNS fundamentals behind delegation, this primer on DNS management is a useful companion, and our own post on fixing ACME HTTP-01 failures covers the other major challenge type.

  • Challenge Types - Let’s Encrypt

Catch the next cert expiry before your users do.

Otterwatch checks your SSL certificates daily and emails you 30 days before they expire. Five sites free.

Start watching →