IETF ACME draft splits DNS validation by account URL

Two Certificate Teams, One DNS Name: IETF Splits the Gate

Why it matters

Two independent systems can serve one domain and still fight over the single DNS alias used to prove control of it. An IETF draft gives each ACME account its own validation name. The bargain moves a piece of certificate continuity onto the exact spelling of the account URL.

Daniel Kade3 November 2026 at 18:20 UTCReading Time 2 minLast update: 3 November 2026

Separate ACME accounts can use separate DNS validation names under the proposed dns-account-01 challenge. Conceptual editorial image.

Summary

The IETF's 27 October dns-account-01 draft is in IESG Last Call through 10 November. It proposes a distinct DNS validation name for each ACME account so independent certificate systems can delegate challenges for the same domain through separate CNAMEs.
The name hashes the account URL, using the first ten SHA-256 bytes in Base32 before _acme-challenge. Key rollover leaves that name stable; changing the account URL during a server migration can break preconfigured records.

Imagine two certificate teams running the same domain from separate clouds. Under the existing ACME dns-01 specification, both can place TXT values at _acme-challenge.example.org. But if each team needs its own CNAME delegation to its own challenge solver, the one owner name becomes a contest: DNS permits one CNAME target there. The argument is about independent delegation, not a blanket inability to publish several TXT values.

The 27 October draft gives each ACME account a separate owner name. A client hashes its full account URL, takes the first ten bytes of SHA-256, encodes them in Base32, and puts the resulting label before _acme-challenge. The draft's example is _ujmmovf2vn55tgye._acme-challenge.example.org. A server follows a CNAME from that name to the TXT value and checks the digest of the challenge's key authorization. Two accounts now have two DNS doors, each delegable to a different solver.

The durable part is also the sharp edge. The label follows the account URL rather than the account key, so rotating the key keeps the DNS name. Section 3.5 treats the entire URL as significant: scheme, host, port and path. If an ACME service migrates and changes that identifier, old preconfigured validation names can stop matching. The draft asks servers to preserve account identifiers and to keep accepting older kid URLs where a migration makes a change necessary. The IETF tracker places revision 04 in IESG Last Call, ending 10 November; it records an intended Proposed Standard, with implementation still a decision for ACME servers.

The public record has the algorithm and review clock. It has no deployment inventory showing which certificate authorities or clients will offer this challenge, or how they will keep account URLs stable through a real service migration.