[GH-ISSUE #97] Clarification of a Few Points

kerem commented

2026-03-13 15:28:11 +03:00

Owner

Originally created by @Queuecumber on GitHub (Aug 2, 2018).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/97

I'm using acme-dns for my wildcard domain and I was hoping to get a few points clarified for using it

In my config I added the following extra records (changed here for anonymity):

records = [
    # default A
    "auth.example.org. A 192.168.1.100",
    # A
    "ns.auth.example.org. A 192.168.1.100",
    # NS
    "auth.example.org. NS ns.auth.example.org.",
]

Are all these records necessary? Following the readme, I also added the same NS record and A record for ns.auth to my primary DNS, so at least the bottom two seem potentially redundant to me but I may be misunderstanding something about how DNS resolves the names.

Since I use this in a home setup, I am at my ISPs mercy for an IP address. For my primary DNS provider I use dynamic dns records to keep the records updated. Is there any advice for updating acme-dns configuration automatically when the external IPs change?
I'm going to try to add support for acme-dns to cert-manager as part of a larger system, and I won't be able to forward port 53 during development to make the challenges work, is there a recommended way to develop under such circumstances?
Finally, I think this has come up before, but is this safe to keep exposed outside my LAN? I suspect that disabling the registration endpoint solves most security concerns, but just to make sure I am understanding the process: lets say I set up my primary DNS to point to acme-dns as described in the readme, and the register an account to update it. Assuming I left the registration endpoint turned on, couldnt anyone overwrite the/add a registration for my domain and create a certificate for it?

Originally created by @Queuecumber on GitHub (Aug 2, 2018). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/97 I'm using acme-dns for my wildcard domain and I was hoping to get a few points clarified for using it 1. In my config I added the following extra records (changed here for anonymity): ``` records = [ # default A "auth.example.org. A 192.168.1.100", # A "ns.auth.example.org. A 192.168.1.100", # NS "auth.example.org. NS ns.auth.example.org.", ] ``` Are all these records necessary? Following the readme, I also added the same NS record and A record for ns.auth to my primary DNS, so at least the bottom two seem potentially redundant to me but I may be misunderstanding something about how DNS resolves the names. 2. Since I use this in a home setup, I am at my ISPs mercy for an IP address. For my primary DNS provider I use dynamic dns records to keep the records updated. Is there any advice for updating acme-dns configuration automatically when the external IPs change? 3. I'm going to try to add support for acme-dns to [cert-manager](https://github.com/jetstack/cert-manager) as part of a larger system, and I won't be able to forward port 53 during development to make the challenges work, is there a recommended way to develop under such circumstances? 4. Finally, I think this has come up before, but is this safe to keep exposed outside my LAN? I suspect that disabling the registration endpoint solves most security concerns, but just to make sure I am understanding the process: lets say I set up my primary DNS to point to acme-dns as described in the readme, and the register an account to update it. Assuming I left the registration endpoint turned on, couldnt anyone overwrite the/add a registration for my domain and create a certificate for it?

kerem closed this issue

2026-03-13 15:28:16 +03:00

kerem commented

2026-03-13 15:28:22 +03:00

Author

Owner

@Ajedi32 commented on GitHub (Aug 2, 2018):

For #1 I'd need to consult my notes to be sure, but as I understand it setting an NS record for auth.example.org means that your DNS provider is delegating that entire subdomain to your ACME-DNS server. So even if you have a record (of any type) for auth.example.org set with your DNS provider that entry is not canonical (since your DNS provider is not the authoritative source for *.auth.example.org anymore).

You still need the A record for ns.auth.example.org to be set via your DNS provider though, because otherwise DNS clients will have no way of knowing how to contact ns.auth.example.org when they see that name in the NS record set by your DNS provider. That "extra" A record is called a "glue record". Since it's not canonical though, you also need to have your ACME-DNS server serve the same record.

#2: Personally, I solved this by installing acme-dns on a VPS with a static IP outside my firewall. That also has the benefit of not requiring you to expose a server inside your LAN to the public internet. But I suppose alternatively you could have a script that regularly rewrites the config file and reloads ACME-DNS. Or you could set the NS record's value to a domain controlled by a dynamic DNS provider (rather than a domain controlled by your ACME-DNS server itself).

#3 I don't know. Maybe test the DNS changes with dig? Is it an issue if Let's Encrypt can't access the DNS server during development?

#4 I believe you can configure the API to only accept requests from certain IP ranges. In the absence of that, anyone can register an account on your DNS server. That doesn't automatically let them get certs for your domain though; you'd need to point a CNAME record for the DNS challenge at the domain their account controls first. The biggest concern I think to leaving registration open is that it's a potential DOS vector. Someone could register millions of accounts on your DNS instance and use up all your disk space, or something like that.

@Ajedi32 commented on GitHub (Aug 2, 2018): For #1 I'd need to consult my notes to be sure, but as I understand it setting an NS record for `auth.example.org` means that your DNS provider is delegating that entire subdomain to your ACME-DNS server. So even if you have a record (of any type) for `auth.example.org` set with your DNS provider that entry is not canonical (since your DNS provider is not the authoritative source for `*.auth.example.org` anymore). You still need the A record for `ns.auth.example.org` to be set via your DNS provider though, because otherwise DNS clients will have no way of knowing how to contact `ns.auth.example.org` when they see that name in the NS record set by your DNS provider. That "extra" A record is called a "glue record". Since it's not canonical though, you also need to have your ACME-DNS server serve the same record. #2: Personally, I solved this by installing acme-dns on a VPS with a static IP outside my firewall. That also has the benefit of not requiring you to expose a server inside your LAN to the public internet. But I suppose alternatively you could have a script that regularly rewrites the config file and reloads ACME-DNS. Or you could set the NS record's value to a domain controlled by a dynamic DNS provider (rather than a domain controlled by your ACME-DNS server itself). #3 I don't know. Maybe test the DNS changes with `dig`? Is it an issue if Let's Encrypt can't access the DNS server during development? #4 I believe you can configure the API to only accept requests from certain IP ranges. In the absence of that, anyone can register an account on your DNS server. That doesn't automatically let them get certs for your domain though; you'd need to point a CNAME record for the DNS challenge at the domain their account controls first. The biggest concern I think to leaving registration open is that it's a potential DOS vector. Someone could register millions of accounts on your DNS instance and use up all your disk space, or something like that.

kerem commented

2026-03-13 15:28:27 +03:00

Author

Owner

@Queuecumber commented on GitHub (Aug 3, 2018):

Probably not actually, I assume the challenge process works in general so it would just be a matter of getting the registation/update process to work which should be fine without public port 53 until the final testing
One thing that concerns me is what happens if someone re-registers the same endpoint e.g. I had previous registered example.com and have been using acme-dns to obtain certificates. Then Mallory also registers example.com on the same acme-dns instance. She can't update the CNAME record and so cant use the registration to obtain certificates, but does acme-dns overwrite my registration with hers making me unable to renew until I re-register? Or does it keep both registrations? Or does it not allow the second registration since someone already registered that domain? Or something else?

@Queuecumber commented on GitHub (Aug 3, 2018): 3. Probably not actually, I assume the challenge process works in general so it would just be a matter of getting the registation/update process to work which should be fine without public port 53 until the final testing 4. One thing that concerns me is what happens if someone re-registers the same endpoint e.g. I had previous registered example.com and have been using acme-dns to obtain certificates. Then Mallory also registers example.com on the same acme-dns instance. She can't update the CNAME record and so cant use the registration to obtain certificates, but does acme-dns overwrite my registration with hers making me unable to renew until I re-register? Or does it keep both registrations? Or does it not allow the second registration since someone already registered that domain? Or something else?

kerem commented

2026-03-13 15:28:32 +03:00

Author

Owner

@Ajedi32 commented on GitHub (Aug 3, 2018):

You can't register any specific domain on ACME-DNS. You just POST to http://acme-dns.example/register and it gives you a randomly-generated domain name to point your CNAME record at, plus a randomly-generated username and password you can use to update the TXT record for that randomly-generated domain. See https://github.com/joohoi/acme-dns#testing-it-out

@Ajedi32 commented on GitHub (Aug 3, 2018): 4. You can't register any specific domain on ACME-DNS. You just POST to `http://acme-dns.example/register` and it gives you a randomly-generated domain name to point your CNAME record at, plus a randomly-generated username and password you can use to update the TXT record for that randomly-generated domain. See https://github.com/joohoi/acme-dns#testing-it-out

kerem commented

2026-03-13 15:28:37 +03:00

Author

Owner

@Queuecumber commented on GitHub (Aug 3, 2018):

Ah good point, it's the client side that associates that with the domain you are trying to get a cert for. OK I think that covers everything then, thanks for your help

@Queuecumber commented on GitHub (Aug 3, 2018): Ah good point, it's the client side that associates that with the domain you are trying to get a cert for. OK I think that covers everything then, thanks for your help

kerem commented

2026-03-13 15:28:42 +03:00

Author

Owner

@Queuecumber commented on GitHub (Aug 14, 2018):

@Ajedi32 Just for the record, #48 was the trick to making the dynamic DNS work. Instead of an A record acme-dns serves a cname record:

acme.example.org CNAME dyn.example.org

and then dyn.example.org is on my main zone and updated w/ a dynamic DNS client. Seems to work so far

@Queuecumber commented on GitHub (Aug 14, 2018): @Ajedi32 Just for the record, #48 was the trick to making the dynamic DNS work. Instead of an A record acme-dns serves a cname record: ``` acme.example.org CNAME dyn.example.org ``` and then dyn.example.org is on my main zone and updated w/ a dynamic DNS client. Seems to work so far

kerem referenced this issue

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

[PR #39] [MERGED] install ca-certificates package #261

Rows
Columns

[GH-ISSUE #97] Clarification of a Few Points #39