[GH-ISSUE #338] Register endpoint with configurable subdomain #186

New issue

Closed

opened 2026-03-13 16:04:40 +03:00 by kerem · 3 comments

kerem commented

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

Owner

Originally created by @datafoo on GitHub (Apr 24, 2023).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/338

I am interested in using acme-dns but I am wondering something. What are reasons for acme-dns to choose the subdomain itself?

I see an opportunity to automate things even more if I could choose the subdomain myself, in advance.

That would allow me to create the CNAME record early on.
The first certificate issuance could therefore be fully automated.

Originally created by @datafoo on GitHub (Apr 24, 2023). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/338 I am interested in using `acme-dns` but I am wondering something. What are reasons for `acme-dns` to choose the subdomain itself? I see an opportunity to automate things even more if I could choose the subdomain myself, in advance. - That would allow me to create the CNAME record early on. - The first certificate issuance could therefore be fully automated.

kerem closed this issue

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

kerem commented

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

Author

Owner

@aduzsardi commented on GitHub (Apr 25, 2023):

depending on where you host your DNS zone , you can already do that with some tooling
when you request an acme-dns record , that record will be echoed out ... which you can then parse and further use in your tooling with API calls to your DNS hosting provider and Let's Encrypt or other acme CA

i think having the subdomain be defined manually by human intervention is just asking for trouble

@aduzsardi commented on GitHub (Apr 25, 2023): depending on where you host your DNS zone , you can already do that with some tooling when you request an acme-dns record , that record will be echoed out ... which you can then parse and further use in your tooling with API calls to your DNS hosting provider and Let's Encrypt or other acme CA i think having the subdomain be defined manually by human intervention is just asking for trouble

kerem commented

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

Author

Owner

@datafoo commented on GitHub (Apr 25, 2023):

depending on where you host your DNS zone , you can already do that with some tooling
when you request an acme-dns record , that record will be echoed out ... which you can then parse and further use in your tooling with API calls to your DNS hosting provider and Let's Encrypt or other acme CA

The point of ACME-DNS is to be able to automate renewal of TLS certificates with DNS-01 challenges securely: without storing a high-privilege API token on the server that needs the TLS certificates (see article from EFF: https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation).

If the DNS hosting provider is already providing a API token with restricted-permission (update of a given TXT record only), then I do not need ACME-DNS.

If the DNS hosting provider is providing me with a high-privilege API token, then I am back with the problem that ACME-DNS was trying to solve initially.

So I do not understand how the solution you propose brings any value.

i think having the subdomain be defined manually by human intervention is just asking for trouble

What would those trouble be?

@datafoo commented on GitHub (Apr 25, 2023): > depending on where you host your DNS zone , you can already do that with some tooling > when you request an acme-dns record , that record will be echoed out ... which you can then parse and further use in your tooling with API calls to your DNS hosting provider and Let's Encrypt or other acme CA The point of ACME-DNS is to be able to automate renewal of TLS certificates with DNS-01 challenges **securely**: without storing a high-privilege API token on the server that needs the TLS certificates (see article from EFF: https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation). If the DNS hosting provider is already providing a API token with restricted-permission (update of a given TXT record only), then I do not need ACME-DNS. If the DNS hosting provider is providing me with a high-privilege API token, then I am back with the problem that ACME-DNS was trying to solve initially. So I do not understand how the solution you propose brings any value. > i think having the subdomain be defined manually by human intervention is just asking for trouble What would those trouble be?

kerem commented

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

Author

Owner

@robalexdev commented on GitHub (May 23, 2023):

Certificate issuance and subdomain registration are already separate. When and how you perform those steps depends on the ACME client. Is there a particular ACME client you're using?

On the first run, LEGO's acme-dns provider will call /register to get a subdomain and will save the credentials to a file (see ACME_DNS_STORAGE_PATH). Then it prompts you to manually set the CNAME. You could instead call /register yourself (using curl, for example), set up the CNAME, and create that file manually. This causes LEGO to skip the registration process, since you're providing an existing subdomain, and issue a certificate right away. I'm doing this in one of my projects to pre-register subdomains.

acme-dns doesn't need any changes to support this, although your ACME client may. I may be able to point you in the right direction.

having the subdomain be defined manually by human intervention is just asking for trouble

What would those trouble be?

Presumably name collisions and ownership issues. If you're picking a subdomain name without checking if it's already been assigned then someone else may already own it. If you set up the CNAME then someone else can issue certificates for your domain. Even if you try to use an unguessable UUID, an attacker can look at your DNS records to see the dangling CNAME, then try to register the subdomain before you can.

The only way to do this safely is to register the subdomain with acme-dns before you set the CNAME. This way you know that no one else has credentials for the subdomain. Since you need to call /register first, you may as well let acme-dns pick the subdomain name for you. Then it's just a matter of configuring your ACME client.

@robalexdev commented on GitHub (May 23, 2023): Certificate issuance and subdomain registration are already separate. When and how you perform those steps depends on the ACME client. Is there a particular ACME client you're using? On the first run, LEGO's acme-dns provider will call `/register` to get a subdomain and will save the credentials to a file (see `ACME_DNS_STORAGE_PATH`). Then it prompts you to manually set the CNAME. You could instead call `/register` yourself (using curl, for example), set up the CNAME, and create that file manually. This causes LEGO to skip the registration process, since you're providing an existing subdomain, and issue a certificate right away. I'm doing this in one of my projects to pre-register subdomains. acme-dns doesn't need any changes to support this, although your ACME client may. I may be able to point you in the right direction. >> having the subdomain be defined manually by human intervention is just asking for trouble > What would those trouble be? Presumably name collisions and ownership issues. If you're picking a subdomain name without checking if it's already been assigned then someone else may already own it. If you set up the CNAME then someone else can issue certificates for your domain. Even if you try to use an unguessable UUID, an attacker can look at your DNS records to see the dangling CNAME, then try to register the subdomain before you can. The only way to do this safely is to register the subdomain with acme-dns before you set the CNAME. This way you know that no one else has credentials for the subdomain. Since you need to call `/register` first, you may as well let acme-dns pick the subdomain name for you. Then it's just a matter of configuring your ACME client.