Key rotation doesn't change the account URI — ACME key rollover (RFC 8555 §7.3.5) replaces the key pair but keeps the same account URL, which is one of the reasons the draft uses account URI rather than a public key. Your DNS record stays unchanged through key rotations.
The only case that requires a DNS update is creating an entirely new account, and that's deliberate — the record binds a specific account to the domain so a stolen record can't be used by someone else.
For your setup with CNAME delegation to a custom DNS server, this should actually be simpler than dns-01. You would point _validation-persist instead of _acme-challenge, and the target record is static. No per-issuance dynamic updates at all.
An open PR on the draft (#35) adds exactly this language: if a CA performs DNSSEC validation and it fails (expired signatures, broken chain of trust), the CA MUST treat it as a challenge failure and MUST NOT use the record. The rationale is that dns-persist-01 records are long-lived, so a DNSSEC failure has more severe consequences than it would for a transient challenge.
The ACME account URI does not appear in issued certificates. X.509 certs contain the subject, issuer, SANs, validity period, SCTs, etc., but no ACME account identifier. You can verify this by inspecting any Let's Encrypt certificate. What CT logs do reveal is which CA issued certs for which domain(s), and multi-domain certs group SANs together, so some correlation is possible. But the account URI itself is not exposed — dns-persist-01 records in DNS would be a new exposure surface for that identifier. That's a real tradeoff, which is why the draft supports using separate accounts per domain if isolation matters to you.
I'm one of the draft authors. Several questions here touch real design tradeoffs — addressing the main threads:
Why account URI instead of a public key in the record? (micw, 9dev, csense)
Three reasons:
1. Key rotation without DNS changes. dns-persist-01 exists because DNS updates are expensive. Embedding a public key forces a DNS update on every key rotation — the exact problem this method solves. The account URI survives key rotation (RFC 8555 §7.3.5).
2. CAA alignment. The accounturi parameter matches CAA record syntax (RFC 8657 §3). Domain owners use the same identifier in validation and policy records.
3. Simplicity. Matching uses simple string comparison — no key encoding, no signature verification, no algorithm negotiation. The cryptographic binding between account URI and key pair happens inside ACME, where it belongs.
The account URI is opaque — a URL containing a database key, like https://acme-v02.api.letsencrypt.org/acme/acct/123456789. No email, no name. The privacy exposure is modest: it reveals which CA account controls the domain, similar to what CT logs already show about CA-domain relationships, but with explicit account-level grouping. If you want isolation between domains, use separate accounts.
The accounturi binds validation to a specific account so a stolen DNS record can't be used by a different subscriber. An open PR (#35) adds accounturi to the challenge object so clients can verify it before provisioning.
10-day reuse limit (agwa)
The 10-day maximum comes from the CA/Browser Forum ballot (SC-088), not the IETF draft. The draft defers reuse period to CA policy and caps it at the DNS TTL (see "Validation Data Reuse and TTL Handling" in the Security Considerations). Let's Encrypt is migrating to 7 hours. The TTL cap lets domain owners enforce shorter windows directly.
Mandatory DNSSEC (rmoriz)
Requiring DNSSEC would exclude most domains and block adoption. The current draft specifies DNSSEC validation as SHOULD. An open PR (#35) tightens this: if a CA performs DNSSEC validation and it fails — expired signatures, broken chain of trust — the CA MUST reject the record. This is stricter than general ACME guidance because dns-persist-01 records are long-lived. MPIC (multi-perspective validation) provides the primary defense against on-path attacks regardless of DNSSEC.
Unencrypted DNS queries (1vuio0pswjnm7)
Yes, standard DNS queries are unencrypted. The threat model relies on MPIC — querying from multiple vantage points — not transport encryption. DNSSEC adds an integrity layer where available.
CAA interaction (Ayesh)
Yes. A CAA record with validationmethods=dns-persist-01 combined with accounturi restricts who can validate using this method.
Name-constrained intermediate CAs (infogulch)
Separate problem. dns-persist-01 reduces operational cost of leaf cert issuance by eliminating per-issuance DNS interaction. Delegated intermediates shift the trust model. Both could coexist.
Thank you, this draft is literally perfect and I wish we had this years ago. Most people don't know about acmev2 account rekeying either. It is great you decided to use account uri instead of public key thumbprint.
Recently I wrote a simple acmev2 tool specifically for manual upfront acmev2 account creation, rekeying and getting TXT records on stout for dns-persist-01:
> Requiring DNSSEC would exclude most domains and block adoption.
I think this is a good call. For the web, the CAB sets CA requirements and they could choose to require DNSSEC at a later date. It would be a breaking change, but the CAB can, and has, made breaking changes to the BR. The IETF draft seems flexible enough that we could end up with a DNSSEC MUST for the web, in practice, based on the CAB's discretion.
The only case that requires a DNS update is creating an entirely new account, and that's deliberate — the record binds a specific account to the domain so a stolen record can't be used by someone else.
For your setup with CNAME delegation to a custom DNS server, this should actually be simpler than dns-01. You would point _validation-persist instead of _acme-challenge, and the target record is static. No per-issuance dynamic updates at all.
reply