[GH-ISSUE #412] [Feature request] Event (socket, queue webhook, something else?) that triggers on new registrations #230

New issue

Open

opened 2026-03-13 16:12:36 +03:00 by kerem · 0 comments

kerem commented

2026-03-13 16:12:36 +03:00

Owner

Originally created by @TRPB on GitHub (Mar 3, 2026).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/412

Thanks for this great tool!

The one part that annoys me is for each registration I have to manually add the DNS record (or set something up on the client to handle it)

Essentially I am trying to automate these steps from the manual

Get credentials and unique subdomain (simple POST request to eg. https://auth.acme-dns.io/register)
Create a (ACME magic) CNAME record to your existing zone, pointing to the subdomain you got from the registration. (eg. _acme-challenge.domainiwantcertfor.tld. CNAME a097455b-52cc-4569-90c8-7a4b97c6eba8.auth.example.org )

I want:

Registration comes in (from a whitelisted ip)
An event is dispatched from the acme-dns server in some way I can pick up externally that says "Hey, a new DNS record needs adding with this key and this value"
I can listen to that event on the server and trigger the DNS update
Any time a new request comes in (from a whitelisted ip) the DNS record is added automatically. This step is implemented by me, I only need to know what to add an when it needs to be added.

Since:
A. I control all the domains I am allowing to register
B. I manage the DNS for them all in the same place

If I can automate that step it makes like a lot easier than manually adding the DNS record.

This simplifies the flow significantly because currently the cname token is sent to the client requesting the cert, then each client has to be able to update the DNS.

I don't really mind how that event is dispatched but here's a few ideas

Webhook: Probably easiest but requires a web server to listen for the requests, better for distributed dns/acme-dns installations though
sysv message queue. Very simple: I can then run something on the same machine that listens for the message and then implement a webhook on top of it if I like.
unix socket. Same as above but would be a little harder for clients to implement since the client would need to understand whatever the protocol decided was

I think my preferred approach is if I can just msg_recieve(queue) and then anyone can listen to messages added to the queue and decide what to do with them. No HTTP infrastructure, no external calls, just a way to listen to registration events

Originally created by @TRPB on GitHub (Mar 3, 2026). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/412 Thanks for this great tool! The one part that annoys me is for each registration I have to manually add the DNS record (or set something up on the client to handle it) Essentially I am trying to automate these steps from the manual > Get credentials and unique subdomain (simple POST request to eg. https://auth.acme-dns.io/register) > Create a (ACME magic) CNAME record to your existing zone, pointing to the subdomain you got from the registration. (eg. _acme-challenge.domainiwantcertfor.tld. CNAME a097455b-52cc-4569-90c8-7a4b97c6eba8.auth.example.org ) I want: 1. Registration comes in (from a whitelisted ip) 2. An event is dispatched from the acme-dns server in some way I can pick up externally that says "Hey, a new DNS record needs adding with this key and this value" 3. I can listen to that event on the server and trigger the DNS update 4. Any time a new request comes in (from a whitelisted ip) the DNS record is added automatically. This step is implemented by me, I only need to know what to add an when it needs to be added. Since: A. I control all the domains I am allowing to register B. I manage the DNS for them all in the same place If I can automate that step it makes like a lot easier than manually adding the DNS record. This simplifies the flow significantly because currently the cname token is sent to the client requesting the cert, then each client has to be able to update the DNS. I don't really mind how that event is dispatched but here's a few ideas - Webhook: Probably easiest but requires a web server to listen for the requests, better for distributed dns/acme-dns installations though - sysv message queue. Very simple: I can then run something on the same machine that listens for the message and then implement a webhook on top of it if I like. - unix socket. Same as above but would be a little harder for clients to implement since the client would need to understand whatever the protocol decided was I think my preferred approach is if I can just `msg_recieve(queue)` and then anyone can listen to messages added to the queue and decide what to do with them. No HTTP infrastructure, no external calls, just a way to listen to registration events