Full DNS API Token or Delegated Challenge Zone for Your ACME Client?

Once you move certificate renewals to DNS-01, your ACME client needs to create TXT records on its own. The quickest route is to generate an API token at your DNS provider, paste it into the client's config, and move on. It works. But on many providers that token can edit every record in the zone, not just the one record the client actually needs. So the real question is whether that is acceptable, or whether you should point _acme-challenge at a separate zone and give the client access to only that.

Why this comes up more often now

Certificate lifetimes are shrinking on a fixed schedule set by the CA/Browser Forum. The old maximum of 398 days ended on March 15, 2026. Until March 14, 2027 the maximum is 200 days, then it drops to 100 days, with the plan continuing down toward 47 days by 2029. If you are still tracking any of this by hand, manual renewal tracking falls behind quickly at those intervals. The practical effect is that renewal stops being a yearly chore and becomes an unattended job that runs on its own every few weeks. For DNS-01, that means a DNS credential sits permanently on a server, a CI runner, or a config file. DNS-01 is often the only option too: wildcard certificates require it, and so do servers that are not reachable on port 80 from the internet. A credential that lives on a machine forever eventually ends up in places you did not plan for: a backup archive, a copied config, a Git repository, or the memory of a compromised web app running on the same box. So it is worth asking what that credential can do if it leaks.

What a full zone token actually exposes

Picture a normal zone for example.com. It has A records for the website, MX records for mail, an SPF TXT record, a DKIM key, maybe a verification record for some third-party service. The ACME client only ever needs to add and remove one TXT record at _acme-challenge.example.com. A token with full edit rights on that zone does not know about that intent. Whoever holds it can point the website's A record somewhere else, swap the MX records so mail flows to their server, publish their own DKIM key and send convincing mail as your domain, or delete the zone entirely. They can also issue certificates for your domain, which pairs nicely with the redirected A record. In other words, the token's real power is "control of this domain," while the job it was created for is "answer one challenge." That gap is the risk.

How CNAME delegation narrows it

The idea is to move the one record the client needs into a zone that contains nothing else of value, and give the client a token for that zone only. The setup looks like this:

Create a separate zone used only for challenges, for example acme-challenges.example.net. It can live at a different DNS provider or in a separate account.
In your main zone, add one CNAME by hand, once: _acme-challenge.example.com pointing to something like example.com.acme-challenges.example.net.
Give the ACME client an API token that can only edit acme-challenges.example.net, and configure the client to write its TXT records there instead of in the main zone.
At renewal time, the CA looks up the TXT record for _acme-challenge.example.com. Normal DNS resolution follows the CNAME and returns the TXT value from the challenge zone.

After step 2, the main zone never needs to change for renewals again. The CA does not need anything special for this to work, because following a CNAME is just ordinary DNS resolution. That said, CA behavior is worth confirming in your CA's documentation rather than assuming. You can check the chain yourself. Both commands are read-only:

BASH

# Should return the delegated target name
dig +short CNAME _acme-challenge.example.com

# Follows the CNAME; during a renewal this shows the target name and then the TXT value
dig +short TXT _acme-challenge.example.com

Now if the token leaks, the attacker can edit TXT records in a zone that holds nothing but challenge answers. They cannot touch your A, MX, SPF, or DKIM records. The remaining risk is narrower but not zero. Whoever controls the challenge zone can still pass DNS-01 validation for example.com and get a certificate issued. Delegation does not remove that, it limits the damage to certificate misissuance instead of a full domain takeover. If you want to close that gap further, CAA records can restrict issuance to a specific ACME account and validation method (the accounturi and validationmethods parameters from RFC 8657), provided your CA supports them. Watching Certificate Transparency logs for certificates you did not request is the other common safety net.

Questions that decide whether it is worth the setup

Delegation adds a second zone, a second set of nameservers, and one more thing to understand when renewals fail. Whether that is worth it depends on a few things. Can your DNS provider scope a token tightly already? Some providers let you limit a token to one zone, one record name, or one record type. If yours can restrict the token to TXT records at _acme-challenge only, you get most of the benefit without a second zone. If the best it can do is "this whole zone" or, worse, "every zone in the account," delegation buys a lot more. Where will the token live? A token on a single locked-down admin host is a different risk from one sitting on a shared web server that also runs a CMS with plugins. The more exposed the machine, the more it matters what the token can do. How many domains are involved? With one domain, a carefully scoped token may be fine. With dozens, a single challenge zone and one narrow token is often simpler than managing a full-access credential for every zone. Who controls the main DNS? This is where delegation shines in hosting. When a customer's DNS sits at their registrar or a provider you have no access to, the usual alternative is asking them for an API token to their entire zone, which most should not hand over. With delegation, they add one CNAME once and the host renews certificates indefinitely without ever holding their DNS credentials. In support, this is also the step that most often needs explaining, because customers expect to add a TXT record, not a CNAME. Who maintains the challenge zone? It needs working nameservers, sane security on its own account, and someone who remembers why it exists. A forgotten challenge zone becomes a problem of its own.

Mistakes that break delegation or quietly undo it

The most common setup failure is a leftover TXT record at _acme-challenge.example.com from an earlier manual validation. A CNAME cannot coexist with other records at the same name, so the provider either rejects the CNAME or the zone ends up inconsistent. Clean those names first; stale challenge records cause validation errors even without delegation. Another is putting the challenge zone in the same DNS account and then using an account-wide token. That looks like delegation on paper, but the token can still edit the main zone, so nothing is actually isolated. The separation only counts if the credential cannot reach the main zone. Wildcard plus apex certificates trip people up too. A certificate for both example.com and *.example.com validates both names through the same _acme-challenge.example.com record, so the challenge zone may need two TXT values at the same name at the same time. Scripts that overwrite instead of append will make one of the two checks fail. Propagation checks can point at the wrong place. Some clients wait until the TXT record is visible before asking the CA to validate. If the client checks the main zone's nameservers instead of the challenge zone's, it waits for a record that will never appear there. How this is configured depends on the client. If the challenge zone is DNSSEC-signed and the signatures or DS record break, validation can fail even though the TXT value looks correct, since CAs commonly validate DNSSEC where it is present. Finally, watch out for dangling CNAMEs. If you retire the challenge zone, or let example.net expire, while customer zones still contain CNAMEs pointing to it, whoever later controls that name can answer challenges for those domains. Remove the CNAMEs as part of decommissioning, not afterwards. As a rule of thumb: if your provider can scope a token to exactly the challenge record and the token lives somewhere well protected, a scoped token is usually enough. If the token would be zone-wide, sit on an exposed server, or require access to DNS you do not own, CNAME delegation is the more proportionate choice. Either way, pair it with a CAA record and some form of certificate monitoring, because the challenge credential still decides who can get a certificate for your name.