Hi, i built a thing: a service to do dns-01 for domains whose dns you don't want to hand over

hi all,

i built acmealias (https://www.acmealias.com) and figured this might be place to show it.

the itch: dns-01 is the only way to get a wildcard, and getting one means putting a dns provider api token into your load balancer's config. that token doesn't just prove control of one name โ€” it can rewrite every record you own, and now it's in the config, and in the backup of the config. i kept deciding not to think about that.

so, the usual cname trick, but as a service you don't have to run:

  • you publish one cname, by hand, once: _acme-challenge.example.com -> <alias>.acmealias.com
  • we're authoritative for that zone, so let's encrypt follows the cname into ours
  • your acme client tells us the challenge value over http when it's issuing or renewing, we serve it as a txt record for the duration, then drop it
  • that's it. every renewal after the first is invisible to you, and your dns credentials never leave your dns provider, because we never ask for them

on the client side it speaks two things: lego's httpreq provider (so traefik, and anything else built on lego, is a couple of env vars), and the acme-dns /update protocol, so acme.sh, certify the web, cert-manager and the certbot plugin work without anything new being written.

credit where it's due: this is acme-dns's design (GitHub - acme-dns/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely. ยท GitHub), straight up. what i added is the part i kept building by hand around it โ€” a console, domains grouped into projects, an api key per load balancer instead of a credential file per domain, wildcard and apex sharing one alias and one cname (they validate at the same challenge name anyway), and a view of which certs actually got issued and when they expire.

honest state of it: it runs and it issues real certificates. there's pricing on the site โ€” free personal accounts, 39 ct per challenge answered for team accounts, capped at 199 eur a month โ€” but no payment processor wired up behind it and no self-signup, so nothing can be bought today. the numbers are there to cover the nameservers and the database rather than to make anyone rich. if it looks useful, tell me what would break for you and i'll take that over guessing.

happy to answer anything about the mechanics.

toodles

.rm

One general note (especially to folks who are interested in this or similar services): if you don't use CAA Account Binding, you allow the operator of the DNS alias service to obtain certificates for your domain (in particular wildcard certificates) and use them to perform person-in-the-middle attacks on your users. Once you use CAA Account Binding, though, you're safe*.

(*When using CAA account binding, make sure to use a CA that enforces it - for example, Let's Encrypt. From March 2027 on, all CAs will be required to support it.)

hi felix,

yes, great point. i have a CAA check - but i will add some documentation on how to actually do it.

my initial version of this was going to be open source, t oself-host - do you think this would be interesting? currently, i think it would mostly benefit bigger players that can set this up. for a smaller situation ... i think it might be a bit too fiddly to set up all the small pieces to run this - hence the SaaS approach ...

either way, your input is appreciated

.rm

So... you reinvented acme-dns?

yes. that's more or less what the post says.

acmealias is the acme-dns pattern, hosted. it isn't a better (or very differnet) idea than acme-dns, it's the same idea with somebody else holding the nameserver. it speaks acme-dns's /update,
so acme.sh, cert-manager's solver, certify the web and the certbot plugin work against.

what's different is the operational half, for a lot of people that's a bigger commitment than the api token they were trying to get out of their proxy config in the first place. this is that box, run by someone else. that's the entire pitch. you're probably right - i should have said this more clearly.

there ARE a few differences, downstream of that one:

  • POST /register is not open. in acme-dns anyone who can reach the endpoint mints an
    account and a subdomain; here the account exists first and registration is
    authenticated. that's a genuine incompatibility with clients that self-register.
  • alias labels are 80 bits of random base32 by default rather than derived from the
    domain. our nameservers are public, and a derivable label would turn the zone into a
    membership oracle โ€” ask whether shop.example.com is a customer, get a free answer.
  • a wildcard and its apex share one alias and one cname, since the *. label is stripped
    before the challenge name is formed. one action, not two, and no collision discovered
    at renewal.
  • there's a console on top: domains grouped into projects, one key per load balancer
    instead of a credentials file per domain, and a view of what was issued and when it
    expires.

but if you're already running acme-dns and it's up, i have nothing for you - genuinely,
don't switch. but this probably isn't for everyone.

toodles

.rm