mirror of
https://github.com/acme-dns/acme-dns.git
synced 2026-04-27 12:55:48 +03:00
[GH-ISSUE #195] acme-dns not listening to register api #86
Labels
No labels
Documentation
Documentation
bug
enhancement
feature request
feature request
help wanted
pull-request
question
security
security
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/acme-dns#86
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rhufsky on GitHub (Nov 1, 2019).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/195
I have installed acme-dns on Ubuntu 18.04 on a server that runs in a DMZ behind a firewall. Only port 53 is exposed to the outside. So far I have
When I start acme-dns I can verify that it acts as a DNS server from both inside the DMZ and from the internet.
When I try to call the register API I get no answer. acme-dns does not seem to listen on port 80 or port 443.
Watching syslog I find that acme-dns tries to get a certificate from letsencrypt. This does not work because the CNAME record is missing.
As I can not call the register API I cannot create the CNAME record. So I am a bit stuck. Did I miss something?
@joohoi commented on GitHub (Nov 2, 2019):
Hi! From your writeup it seems that you're missing the crucial NS record for the domain. The CNAME is not needed for acme-dns instance itself as it handles all that internally.
@rhufsky commented on GitHub (Nov 2, 2019):
Thanks for the quick answer.
A bit of forensic seems to tell me that yes, I have the crucial NS record, but no, our DNS provider does not forward the queries to acme-dns -> recursion requested but not available.
@pdavisfmnh commented on GitHub (Dec 1, 2019):
I'm having the same issue, I think. I can't start acme-dns as it fails to obtain its own certificate.
I never see it respond to DNS queries for TXT records on the main while attempting to get its certificate. So it should be responding to all *.acme.fieldmuseum.org requests, right?
If I use a DNS checking tool while it is starting up for _acme-challenge.acme.fieldmuseum.org I see DEBUG comments from the DNS server.
So I'm at a lost on where the breakdown is in my setup.
@joohoi commented on GitHub (Dec 2, 2019):
@pdavisfmnh is
acme-dnsserving the records forns1.acme.fieldmuseum.organdns2.acme.fieldmuseum.orgcorrectly? Currently it doesn't look like it does, onlyns2.acme.fieldmuseum.orgresolves:@pdavisfmnh commented on GitHub (Dec 2, 2019):
This is what I get for working on things when I'm supposed to be on vacation. Fixed the DNS issue and magically it's working right.
It's not DNS. It's DNS.
@joohoi commented on GitHub (Dec 4, 2019):
Great to hear that you got it fixed!
Is this a reference to the DNS haiku:
@bezaleel22 commented on GitHub (Jun 9, 2020):
Please am also facing thesame issue, how were you able to solve this problem thanks. Below is my
digoutput@webprofusion-chrisc commented on GitHub (Jun 9, 2020):
Check dig from outside your network (like on a cloud vm). Your port 53 is probably not open (for remote DNS queries), so your https/https port probably isn't open either.
@bezaleel22 commented on GitHub (Jun 10, 2020):
Thanks for the reply, i will comfirm this with dig and nmap and get back
@bezaleel22 commented on GitHub (Jun 10, 2020):
the following are the outputs i have recieved:
curfrom my local machinefirewall on my server...
digfrom my local machinenslookupfrom my local machinePlease how can i make scene of these output my firewall shows that port 53 is open but curl cant connect on that port,
@bezaleel22 commented on GitHub (Jun 10, 2020):
sorry this the actual output of
nmapon port 53