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 #246] Is the listen config parameter supposed to listen to localhost? #122

New issue

Open

opened 2026-03-13 15:50:26 +03:00 by kerem · 6 comments

kerem commented

2026-03-13 15:50:26 +03:00

Owner

Originally created by @tal-zvon on GitHub (Oct 29, 2020).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/246

The sample config file says:

listen = "127.0.0.1:53"

Should that not be 0.0.0.0:53? Why does it only need to listen to requests on the local host? Am I missing something?
Or is that just an example, and you're meant to replace 127.0.0.1 with 0.0.0.0?

Originally created by @tal-zvon on GitHub (Oct 29, 2020). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/246 The sample config file says: listen = "127.0.0.1:53" Should that not be `0.0.0.0:53`? Why does it only need to listen to requests on the local host? Am I missing something? Or is that just an example, and you're meant to replace `127.0.0.1` with `0.0.0.0`?

kerem commented

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

Author

Owner

@HausnerR commented on GitHub (Dec 1, 2020):

IMHO it's a bug in README and example config.

I successfully configured acme-dns making DNS server listening on 0.0.0.0:53 and making API listen only in local subnet.

So only I have access to API to register new endpoints and Let's encrypt can reach DNS server to confirm domain owner.

@HausnerR commented on GitHub (Dec 1, 2020): IMHO it's a bug in README and example config. I successfully configured acme-dns making DNS server listening on `0.0.0.0:53` and making API listen only in local subnet. So only I have access to API to register new endpoints and Let's encrypt can reach DNS server to confirm domain owner.

kerem commented

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

Author

Owner

@tal-zvon commented on GitHub (Dec 1, 2020):

IMHO it's a bug in README and example config.

I successfully configured acme-dns making DNS server listening on 0.0.0.0:53 and making API listen only in local subnet.

So only I have access to API to register new endpoints and Let's encrypt can reach DNS server to confirm domain owner.

That makes sense. The README and example config do not. Sounds like a documentation bug to me (or whatever that would be called).

@tal-zvon commented on GitHub (Dec 1, 2020): > IMHO it's a bug in README and example config. > > I successfully configured acme-dns making DNS server listening on `0.0.0.0:53` and making API listen only in local subnet. > > So only I have access to API to register new endpoints and Let's encrypt can reach DNS server to confirm domain owner. That makes sense. The README and example config do not. Sounds like a documentation bug to me (or whatever that would be called).

kerem commented

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

Author

Owner

@joohoi commented on GitHub (Dec 1, 2020):

It’s actually intentional. On many configurations systemd resolved is
listening at 127.0.1.53:53 which makes acme-dns unable to bind to 0.0.0.0:53

On Tue 1. Dec 2020 at 21.02, terminator14 notifications@github.com wrote:

IMHO it's a bug in README and example config.

I successfully configured acme-dns making DNS server listening on
0.0.0.0:53 and making API listen only in local subnet.

So only I have access to API to register new endpoints and Let's encrypt
can reach DNS server to confirm domain owner.

That makes sense. The README and example config do not. Sounds like a
documentation bug to me (or whatever that would be called).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/joohoi/acme-dns/issues/246#issuecomment-736754799,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABH6DJMQNQ7IHPQ6PDZKBALSSU4WHANCNFSM4TEGS4QA
.

@joohoi commented on GitHub (Dec 1, 2020): It’s actually intentional. On many configurations systemd resolved is listening at 127.0.1.53:53 which makes acme-dns unable to bind to 0.0.0.0:53 On Tue 1. Dec 2020 at 21.02, terminator14 <notifications@github.com> wrote: > IMHO it's a bug in README and example config. > > I successfully configured acme-dns making DNS server listening on > 0.0.0.0:53 and making API listen only in local subnet. > > So only I have access to API to register new endpoints and Let's encrypt > can reach DNS server to confirm domain owner. > > That makes sense. The README and example config do not. Sounds like a > documentation bug to me (or whatever that would be called). > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/joohoi/acme-dns/issues/246#issuecomment-736754799>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABH6DJMQNQ7IHPQ6PDZKBALSSU4WHANCNFSM4TEGS4QA> > . >

kerem commented

2026-03-13 15:50:47 +03:00

Author

Owner

@tal-zvon commented on GitHub (Dec 1, 2020):

Would not binding to 127.0.0.1:53 (as the documentation suggests) be the equivalent to binding to any other random IP? Just like binding to 1.2.3.4:53, it would technically allow the program to start (since the binding would succeed), but wouldn't allow LetsEncrypt to reach it. As far as I can tell, there's no point in listening to 127.0.0.1:53 since LetsEncrypt requests will never come from localhost, and will never hit that. Am I wrong?

If that's true, you might as well say listen = "w.x.y.z:53", and just have a note to tell people to type in the IP of the interface they want to listen on. At least users would know that's something they need to figure out, rather than type in 127.0.0.1:53 as is and hope it works.

@tal-zvon commented on GitHub (Dec 1, 2020): Would not binding to 127.0.0.1:53 (as the documentation suggests) be the equivalent to binding to any other random IP? Just like binding to 1.2.3.4:53, it would technically allow the program to start (since the binding would succeed), but wouldn't allow LetsEncrypt to reach it. As far as I can tell, there's no point in listening to 127.0.0.1:53 since LetsEncrypt requests will never come from localhost, and will never hit that. Am I wrong? If that's true, you might as well say `listen = "w.x.y.z:53"`, and just have a note to tell people to type in the IP of the interface they want to listen on. At least users would know that's something they need to figure out, rather than type in 127.0.0.1:53 as is and hope it works.

kerem commented

2026-03-13 15:50:52 +03:00

Author

Owner

@joohoi commented on GitHub (Dec 1, 2020):

Yeah, you are right. It would probably serve the users better as far as the documentation goes. Do you want to create a PR to fix it or should I do it?

@joohoi commented on GitHub (Dec 1, 2020): Yeah, you are right. It would probably serve the users better as far as the documentation goes. Do you want to create a PR to fix it or should I do it?

kerem commented

2026-03-13 15:50:57 +03:00

Author

Owner

@tal-zvon commented on GitHub (Dec 1, 2020):

If you've got the time, go ahead.

Thanks

@tal-zvon commented on GitHub (Dec 1, 2020): If you've got the time, go ahead. Thanks