DNS-Persist-01: A New Model for DNS-Based Challenge Validation

Operational benefits and use cases

• Many commenters see DNS-Persist-01 as solving real pain: fragile scripts, custom DNS servers, or CNAME/NS delegation hacks just to support DNS-01.
• Especially attractive for:
  • Wildcard certificates.
  • Internal / non–internet-facing services where HTTP-01/TLS-ALPN-01 aren’t possible.
  • Large fleets where manual or periodic DNS changes are a bottleneck.
• Some say this finally makes publicly‑trusted certs for LAN/internal services easier than pre-ACME, and could replace complex DIY setups.

Account identifier exposure and privacy

• A major thread criticizes exposing the ACME account URI in DNS:
  • It enables correlating multiple domains under the same account (Shodan-style lookups, infrastructure mapping).
  • Acts as an extra data point in breach/scope expansion.
• Mitigations discussed:
  • Use one ACME account per domain or per load balancer.
  • Note that CAA accounturi and CT logs already leak some account/domain linkage.
  • Some argue the account URI is effectively a random opaque ID anyway.

Design choice: account URI vs keys or random tokens

• Several suggest embedding a public key or random per-domain token instead of an account URI to avoid account correlation.
• Draft authors’ rationale (as relayed in-thread):
  • Key rotation without DNS changes is core to the design; pinning a key in DNS defeats that.
  • Reuse the same identifier as CAA accounturi, simplifying policy and tooling.
  • Keep crypto binding inside ACME; DNS record matching is just string comparison.

Security model, DNS, and DNSSEC

• Consensus that DNS control has always been a single point of failure for ACME; DNS-Persist-01 doesn’t change that, just streamlines the mechanism.
• Threats discussed:
  • Compromised registrars and DNS providers dominate; extra crypto on top of DNS doesn’t help there.
  • On‑path tampering between CA and authoritative DNS is mitigated by multi‑perspective DNS checks (MPIC) and optionally DNSSEC.
• Debate over DNSSEC:
  • Some call it “dangerous” operationally since misconfigurations can drop a domain off the Internet; others say it’s just clumsy but security‑beneficial.
  • The draft only “SHOULD” use DNSSEC; mandatory DNSSEC is seen as blocking adoption, though some wish TXT‑based trust signals would require it.

Reuse windows, revocation, and CAA

• Concern about how to revoke/expire authorizations:
  • Removing the TXT record invalidates authorization once CAs refresh (ballot caps reuse at 10 days; Let’s Encrypt says they’re moving to ~7 hours).
• CAA can already restrict:
  • Which accounts may issue for a domain.
  • Which validation methods (e.g., limiting to dns-persist-01).

Impact on existing setups and tooling

• Existing ACME challenge types remain; users relying on HTTP-01 or traditional DNS-01 don’t need to change anything.
• DNS-Persist-01 is optional, mainly a convenience / automation improvement for those who adopt it.
• Tooling:
  • Support exists in Pebble; lego integration is in progress.
  • Certbot and others are tracking feature support.

Operational patterns and DNS APIs

• Many share approaches using:
  • Granular DNS APIs (Route53 conditions, PowerDNS API, BIND RFC2136, acme-dns).
  • Per-host or per-record keys to limit blast radius if a single machine is compromised.
• Discussion around DNS providers:
  • Some hosts allow very fine-grained API scoping; others only at zone level.
  • Suggestions include using a dedicated _acme-challenge subdomain delegated to an automation-friendly DNS service.

Alternatives and broader PKI/DANE debate

• Some argue internal services might be better served by a private CA with name-constrained roots, avoiding internet dependency.
• Others see this as a step towards tighter DNS–TLS integration and “True DANE,” but note DNSSEC’s rough deployment history and browser ecosystem realities.
• There’s side discussion on short-lived certs, rate limits, and name-constrained intermediates, but those are seen as orthogonal to DNS-Persist-01.