A few weeks ago, there was a feature request for wildcard certs from Let’s Encrypt. LE requires DNS validation in order to issue a wildcard cert, and with many DNS hosts not having an API (and of those who do, they’re all different), it seems like it’d be practically impossible to build this into Neth in a way that would work for any significant number of users. Unless…
acme-dns is a project that implements a simple DNS server, whose only purpose is to serve the TXT records that Let’s Encrypt uses for validation. It implements an API that’s supported by Certbot and other clients, and is intended to run on a server under your control. You’d set some static (i.e., they don’t need to be changed at any interval) DNS records at your DNS host, which would have the effect of pointing Let’s Encrypt to your own server. acme-dns will then serve the desired TXT records, validating domain control, so LE will issue you the cert.
So, if we can get acme-dns up and running on Neth, we could package a way to issue wildcard certs for the Neth server, no matter which DNS host is being used. So I’m trying to get it running on Neth, but I’m running into a problem, probably because dnsmasq is already running and listening on port 53.
The software installs without issue, and appears to start without error. netstat -an says there’s something listening on 0.0.0.0:53 (both TCP and UDP). I’ve done config set fw_acme-dns service status enabled UDPPort 53 TCPPort 53 access red followed by a firewall-adjust. But when I check open ports from the outside, port 53 isn’t open. I’m guessing this is because dnsmasq is already listing on port 53. How can I work around this? A port forward?
What IP does it bind port 53 to. It can’t be 0.0.0.0, as dnsmasq has already claimed that. You can check with ‘netstat -tupln’.
That should open port 53 to the outside world. However, I don’t know how that will interact with the NS rule that opens those ports to only the green interface.
Are you saying that the port is blocked. Or not responding correctly to acme-dns requests.
If I’m understanding correctly, you want acme-dns to be available from the internet on port 53, and dnsmasq available to your network, also on port 53.
This would entail having dnsmasq to only bind to the green interface IP (and maybe also 127.0.0.1) and acme-dns bind to the red interface IP. Plus setting the correct firewall rules.
It isn’t responding to DNS requests, and an external port scanner reports that port 53 isn’t open.
Correct. I’m not personally concerned about dnsmasq, as I’m not using my Neth box as a router (I have a pfSense box for that instead), but if I’m going to come up with a method that has a chance of being packaged for mainstream use, it’s going to need to play well with dnsmasq.
That’s a pretty obvious point that I hadn’t considered. It had been binding to “:53”, which I assume would try to bind to port 53 on any IP. I can change that to only bind to the external IP address and restart the service, but when I do, I still get this:
If I then adjust the firewall, acme-dns will respond to DNS queries from outside. Cool. But since dnsmasq wants to listen on all IPs, this can’t work. We’d need to either adjust the dnsmasq configuration so that it only listens on green, or do something else.
Since I’d want to do as little messing with the base system as possible, “do something else” sounds like the better idea. Can I do a port forward from outside port 53 to localhost:1053, for example?
Except that NS uses this to add to it’s current list of interface it ignores: Anything currently declared as a red interface. So, I’m guessing that this “ignore” is done inside the code, not at the “bind”.
It’s not a port forward you want, but a redirect. Try adding this to the shorewall template: /etc/e-smith/templates-custom/etc/shorewall/rules/95acme
…and as a side note, the tool I was using on my iPad to do the port scan, iNetTools, still shows port 53 as being closed even when it’s working properly. So there’s some kind of issue with that tool as well.