CNAMEs. I do this for everything. Example:

1. Your main domain is important.example.com with provider A. No DNS API token for security.

2. Your throwaway domain in a dedicated account with DNS API is example.net with provider B and a DNS API token in your ACME client

3. You create _acme-challenge.important.example.com not as TXT via API but permanent as CNAME to _acme-challenge.example.net or _acme-challenge.important.example.com.example.net

4. Your ACME client writes the challenge responses for important.example.com into a TXT at the unimportant _acme-challenge.example.net and has only API access to provider B. If this gets hacked and example.net lost you change the CNAMES and use a new domain whatever.tld as CNAME target.

acme.sh supports this (see https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... this also works for wildcards as described there), most ACME clients do.

I also wrote an acme.sh Ansible role supporting this: https://github.com/foundata/ansible-collection-acmesh/tree/m.... Example values:

  [...]
  # certificate: "foo.example.com" with an additional "bar.example.com" SAN
  - domains:
    - name: "foo.example.com"
      challenge:  # parameters depend on type
        type: "dns"
        dns_provider: "dns_hetzner"
        # CNAME _acme-challenge.foo.example.com => _acme-challenge.foo.example.com.example.net
        challenge_alias: "foo.example.com.example.net"
    - name: "bar.example.com"
      challenge:
        type: "dns"
        dns_provider: "dns_inwx"
        # CNAME _acme-challenge.bar.example.com => _acme-challenge.example.net
        challenge_alias: "example.net"
  [...]

I used the acme-dns server (https://github.com/joohoi/acme-dns) for this. It's basically a mini DNS server with a very basic API backed with sqlite. All of my acme.sh instances talk to it to publish TXT records, and accepts queries from the internet for those TXT records.

There's a NS record so *.acme-dns.example.com delegates requests to it, so each of my hosts that need a cert have a public CNAME like _acme-challenge.www.example.com CNAME asdfasf.acme-dns.example.com which points back to the acme-dns server.

When setting up a new hostname/certificate, a REST request is sent to acme-dns to register a new username/password/subdomain which is fed to acme.sh. Then every time acme.sh needs to issue/renew the certificate it sends the TXT info to the internal acme-dns server, which in turn makes it available to the world.

Usually you just CNAME it.

You can cname _acme-challenge.foo.com to foo.bar.com.

Now, if when you do the DNS challenge, you make a TXT at foo.bar.com with the challenge response, through CNAME redirection, the TXT record is picked up as if it were directly at _acme-challenge.foo.com. You can now issue wildcard certs for anything for foo.com.

I have it on my backlog to build an automated solution to this later this year to handle this for hundreds of individual domains and then put the resulting certificates in AWS secrets manager.

I'm going to also see if I can make some sort of ACME proxy, so internal clients authenticate to me, but they cant control dns, so I make the requests on their behalf. We need to get prepared for ACME everywhere. In May 2026, its 200 day certs, it only goes down from there.

In my case I have a very small nameserver at ns.example.com. So I set the NS record for _acme-challenge.example.com to ns.example.com.

An A-record lookup for ns.example.com resolves to the IP of my server.

This server listens on port 53. It is a custom, small Python server using `dnslib`, which also listens on port let's say 8053 for incoming HTTPS connections.

In certbot I have a custom handler, which, when it is passed the challenge for the domain verification, sends the challenge information via HTTPS to ns.example.com:8053/certbot/cache. The small DNS-server then stores it and waits for a DNS query on port 53 for that challenge to come in, and if it does, it serves it that challenge's TXT record.

  elif qtype == 'TXT':
    if qname.lower().startswith('_acme-challenge.'):
      domain = qname[len('_acme-challenge.'):].strip('.').lower()
      if domain in storage['domains']:
        for verification_code in storage['domains'][domain.lower()]:
          a.add_answer(*dnslib.RR.fromZone(qname + " 30 IN TXT " + verification_code))

   #!/usr/bin/env python3
   
   import ...

   r = requests.get('https://ns.example.com:8053/certbot/cache?domain='+urllib.parse.quote(os.environ['CERTBOT_DOMAIN'])+'&validation-code='+urllib.parse.quote(os.environ['CERTBOT_VALIDATION']))

And since it already is a nameserver, it might as well serve the A records for dev1.testing.other-example.com, if you've set the NS record for testing.other-example.com to ns.example.com.

https://cert-manager.io/docs/configuration/acme/dns01/#deleg...

Digital Ocean DNS is free (it’s the only reason I have an account there)

Yeah, but then you can just as well use http-01 with like same effort.

Hurricane Electric support a hidden primary as part of their free DNS nameserver service (do you actually want to expose your primary when someone else can handle the traffic?)

https://dns.he.net

Do most of them let you add an NS record?

Give a try to DNSMadeEasy or RcodeZero

Caddy is in use here in production. 14M requests an hour.

We use Caddy across hundreds of apps with 10s of millions of requests per day in production.

A tools value is in the eye of the beholder. Nginx has ceased being valuable to me when they decided to change licenses, go private equity, not adapt to orchestration needs, ignore http standards, and not release meaningful updates in a decade.

Maybe inversely proportional to how much the ecosystem moves around it.

Yup. I can’t wait for the day I can kill my caddy8s service.

The best thing about caddy is the fact you can reload config, add sites, routes, without ever having to shutdown. Writing a service to keep your orchestration platform and your ingress in sync is meh. K8s has the events, DNS service has the src mesh records, you just need a way to tell caddy to send it to your backend.

The feature should be done soon but they need to ensure it works across K8s flavors.

Traefik seems to be ok for us

Oh I totally misread the comment.

Nevermind, I agree!

And this is different from DNS how exactly? The key and resulting cert still needs to be distributed among your servers no matter which method is used.

Not really, just forward .well-known/acme-challenge/* requests to a single server or otherwise make sure that the challenge responses are served from all instances.

Now you want me to rent or install at least two name servers, and then configure them, and then teach my web server how to send them rules?

That's so much more work than either of the options in my first comment. Aliasing a directory takes about one minute.

Perhaps I have poor imagination, but I fail to see why why it would matter?

I mean, you just repeated my explanation why supporting dns-01 in nginx isn't straightforward has http-01. I've explained why dns-01 challenge is still useful and might be required for some users.

Certbot has a "standalone" mode that occupies port 80 and serves /.well-known/ by itself.

Whoever first recommended using that mode in anything other than some sort of emergency situation needs to be given a firm kick in the butt.

Certbot also has a mode that mangles your apache or nginx config files in an attempt to wire up certificates to your virtual hosts. Whoever wrote the nginx integration also needs a butt kick, it's terrible. I've helped a number of people fix their broken servers after certbot mangled their config files. Just because you're on a crusade to encrypt the web doesn't give you a right to mess with other programs' config files, that's not how Unix works!