External DNS server?

NethServer Version: 7.4
Module: n/a

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?

2 Likes

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.

Cheers.

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:

[root@neth acme-dns]# netstat -tupln | grep :53
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      26892/dnsmasq       
tcp6       0      0 :::53                   :::*                    LISTEN      26892/dnsmasq       
udp        0      0 0.0.0.0:53              0.0.0.0:*                           26892/dnsmasq       
udp6       0      0 :::53                   :::*                                26892/dnsmasq       

If I stop the dnsmasq service and again restart acme-dns, then I get this:

[root@neth acme-dns]# netstat -tupln | grep :53
udp        0      0 (my IP):53       0.0.0.0:*                           4099/acme-dns       

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?

I found that there is a db prop for the except-interfaces option of dnsmasq, didn’t test it but maybe it’s useful here:

http://docs.nethserver.org/projects/nethserver-devel/en/v7/dns.html#dns-server

Interesting, but it doesn’t seem to be having the desired effect:

[root@neth ~]# config setprop dnsmasq except-interface eth0
[root@neth events]# signal-event nethserver-dnsmasq-save
[root@neth events]# config show dnsmasq
dnsmasq=service
    CacheSize=4000
    TCPPort=53
    UDPPorts=53,67,69
    access=green
    dhcp-boot=
    except-interface=eth0
    status=enabled
    tftp-status=enabled
[root@neth events]# service acme-dns start
Redirecting to /bin/systemctl start acme-dns.service
[root@neth events]# netstat -tupln | grep :53
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      7232/dnsmasq        
tcp6       0      0 :::53                   :::*                    LISTEN      7232/dnsmasq        
udp        0      0 0.0.0.0:53              0.0.0.0:*                           7232/dnsmasq        
udp6       0      0 :::53                   :::*                                7232/dnsmasq   

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

REDIRECT  net  1053  tcp  53
REDIRECT  net  1053  udp  53

Then adjust and run acme-dns listening on 1053.

Cheers.

2 Likes

Yep, that seems to have done the trick.

…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.