starred/acme-dns

Fork 0

mirror of https://github.com/acme-dns/acme-dns.git synced 2026-04-27 04:45:48 +03:00

[GH-ISSUE #345] Please accept the PR for making registration endpoint configurable #190

New issue

Open

opened 2026-03-13 16:05:48 +03:00 by kerem · 8 comments

kerem commented

2026-03-13 16:05:48 +03:00

Owner

Originally created by @saudiqbal on GitHub (Sep 20, 2023).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/345

Please accept https://github.com/joohoi/acme-dns/pull/109 into acme-dns which accomplishes my request to allow whitelisted domains only https://github.com/joohoi/acme-dns/issues/263

Bots are attacking online services and abusing them all the time. It would be nice to have this function added to acme-dns. It is not a big change to the code but helps those who want limit the registration of domains.

Originally created by @saudiqbal on GitHub (Sep 20, 2023). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/345 Please accept https://github.com/joohoi/acme-dns/pull/109 into acme-dns which accomplishes my request to allow whitelisted domains only https://github.com/joohoi/acme-dns/issues/263 Bots are attacking online services and abusing them all the time. It would be nice to have this function added to acme-dns. It is not a big change to the code but helps those who want limit the registration of domains.

kerem commented

2026-03-13 16:05:54 +03:00

Author

Owner

@thde commented on GitHub (Oct 6, 2023):

You don't need to publicly expose the API. You could use basic auth or IP lists to only allow certain IPs to connect to the API.

@thde commented on GitHub (Oct 6, 2023): You don't need to publicly expose the API. You could use basic auth or IP lists to only allow certain IPs to connect to the API.

kerem commented

2026-03-13 16:05:59 +03:00

Author

Owner

@saudiqbal commented on GitHub (Oct 6, 2023):

The problem with basic auth is that it uses md5 which is outdated and there is no rate limiting with basic auth. It would be nice to have a private registration endpoint.

@saudiqbal commented on GitHub (Oct 6, 2023): The problem with basic auth is that it uses md5 which is outdated and there is no rate limiting with basic auth. It would be nice to have a private registration endpoint.

kerem commented

2026-03-13 16:06:04 +03:00

Author

Owner

@m00nwtchr commented on GitHub (May 14, 2024):

There are numerous other ways to keep the endpoint secure (which require 0 code changes to this project). You can put acme-dns on the same server as your let's encrypt client (e.g. traefik and acme-dns in 2 containers in docker), such that you don't need it to be exposed anywhere, or you can use a reverse proxy/firewall/etc. to whitelist IPs. (Not to mention vpns and so on)
tl;dr unauthorized people probably shouldn't be able to access this endpoint anyway

@m00nwtchr commented on GitHub (May 14, 2024): There are numerous other ways to keep the endpoint secure (which require 0 code changes to this project). You can put acme-dns on the same server as your let's encrypt client (e.g. traefik and acme-dns in 2 containers in docker), such that you don't need it to be exposed anywhere, or you can use a reverse proxy/firewall/etc. to whitelist IPs. (Not to mention vpns and so on) tl;dr unauthorized people probably shouldn't be able to access this endpoint anyway

kerem commented

2026-03-13 16:06:09 +03:00

Author

Owner

@lachesis commented on GitHub (Jun 21, 2024):

There's nothing wrong with using md5 in the context of basic auth. If you use a long, random password, none of the documented weaknesses of md5 will impact you. Additionally, it's easy enough to add rate limiting for basic auth (or indeed the entire service) in nginx.

@lachesis commented on GitHub (Jun 21, 2024): There's nothing wrong with using md5 in the context of basic auth. If you use a long, random password, none of the documented weaknesses of md5 will impact you. Additionally, it's easy enough to add rate limiting for basic auth (or indeed the entire service) in nginx.

kerem commented

2026-03-13 16:06:14 +03:00

Author

Owner

@Daniel15 commented on GitHub (Oct 29, 2024):

This is security through obscurity, which isn't really a security measure. You'd be better off completely blocking the register endpoint from public access and just curling to localhost whenever you want to registry a new account.

For rate limiting, just configure it in your reverse proxy.

@Daniel15 commented on GitHub (Oct 29, 2024): This is security through obscurity, which isn't really a security measure. You'd be better off completely blocking the register endpoint from public access and just `curl`ing to localhost whenever you want to registry a new account. For rate limiting, just configure it in your reverse proxy.

kerem commented

2026-03-13 16:06:19 +03:00

Author

Owner

@saudiqbal commented on GitHub (Oct 29, 2024):

This is security through obscurity, which isn't really a security measure. You'd be better off completely blocking the register endpoint from public access and just curling to localhost whenever you want to registry a new account.

For rate limiting, just configure it in your reverse proxy.

Security through obscurity is a security measure by adding an extra layer of security by combining existing protection.

@saudiqbal commented on GitHub (Oct 29, 2024): > This is security through obscurity, which isn't really a security measure. You'd be better off completely blocking the register endpoint from public access and just `curl`ing to localhost whenever you want to registry a new account. > > For rate limiting, just configure it in your reverse proxy. Security through obscurity is a security measure by adding an extra layer of security by combining existing protection.

kerem commented

2026-03-13 16:06:24 +03:00

Author

Owner

@webprofusion-chrisc commented on GitHub (Oct 29, 2024):

@saudiqbal if you don't want someone using the endpoint then block them or require authentication. Renaming it breaks existing clients for no good reason.

If you really want it to be called something else, proxy the endpoints through your own API (you can achieve that using caddy or nginx with reverse proxy rules, or it's simple to do using any scripted web server in python or node.).

@webprofusion-chrisc commented on GitHub (Oct 29, 2024): @saudiqbal if you don't want someone using the endpoint then block them or require authentication. Renaming it breaks existing clients for no good reason. If you really want it to be called something else, proxy the endpoints through your own API (you can achieve that using caddy or nginx with reverse proxy rules, or it's simple to do using any scripted web server in python or node.).

kerem commented

2026-03-13 16:06:29 +03:00

Author

Owner

@numo68 commented on GitHub (Jul 30, 2025):

This is security through obscurity, which isn't really a security measure.

That's only partially right. That obscurity would be encrypted on the network here, so it is functionally equivalent to a token. Unguessable strings are used for security-relevant functionality through https all the time. By the way, for example Lego seems to provide ACME_DNS_STORAGE_BASE_URL among Credentials (I did not test it yet though).

My use case is for example a homelab with some traefiks and other clients. I don't care what mechanism is used, but I don't want everyone in the network being able to hit a well-known endpoint, intentionally or in error, and create data on the server there is no way to remove. I don't want to disable the registration either, as it is annoying to toggle it every time I experiment with something. Surely, I can use a reverse proxy to do things and I'll take this route for now, but I still think that some rudimentary access control has its place in the server as well.

Perhaps some set of tokens might be defined to allow registration, in addition to the on/off switch. That would be clean way, and I am sure the clients would be happy to accept a PR related to that.

@numo68 commented on GitHub (Jul 30, 2025): > This is security through obscurity, which isn't really a security measure. That's only partially right. That obscurity would be encrypted on the network here, so it is functionally equivalent to a token. Unguessable strings are used for security-relevant functionality through https all the time. By the way, for example [Lego](https://go-acme.github.io/lego/dns/acme-dns/) seems to provide `ACME_DNS_STORAGE_BASE_URL` among _Credentials_ (I did not test it yet though). My use case is for example a homelab with some traefiks and other clients. I don't care what mechanism is used, but I don't want everyone in the network being able to hit a well-known endpoint, intentionally or in error, and create data on the server there is no way to remove. I don't want to disable the registration either, as it is annoying to toggle it every time I experiment with something. Surely, I can use a reverse proxy to do things and I'll take this route for now, but I still think that some rudimentary access control has its place in the server as well. Perhaps some set of tokens might be defined to allow registration, in addition to the on/off switch. That would be clean way, and I am sure the clients would be happy to accept a PR related to that.