Public DNS (nsd4) is not running ( port 53). whereas this service is running status

Hi
I have v57 MiaB
in status_check.py i get following error
:heavy_multiplication_x: Public DNS (nsd4) is not running (port 53).
:heavy_multiplication_x: Incoming Mail (SMTP/postfix) is running but is not publicly accessible at publicIP:25.
:heavy_multiplication_x: Outgoing Mail (SMTP 465/postfix) is running but is not publicly accessible at publicIP:465.
:heavy_multiplication_x: Outgoing Mail (SMTP 587/postfix) is running but is not publicly accessible at publicIP:587.
:heavy_multiplication_x: IMAPS (dovecot) is running but is not publicly accessible at publicIP:993.
:heavy_multiplication_x: Mail Filters (Sieve/dovecot) is running but is not publicly accessible at publicIP:4190.
:heavy_multiplication_x: HTTP Web (nginx) is running but is not publicly accessible at publicIP:80.

publicIP is my public ip address.
I confused, Public DNS (nsd4) is not running (port 53) whereas this service is running status.

 systemctl status nsd.service
● nsd.service - Name Server Daemon
   Loaded: loaded (/lib/systemd/system/nsd.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2022-10-21 01:07:54 +0330; 20min ago
 Main PID: 5195 (nsd)
    Tasks: 3 (limit: 4265)
   CGroup: /system.slice/nsd.service
           ├─5195 /usr/sbin/nsd -d
           ├─5203 /usr/sbin/nsd -d
           └─5211 /usr/sbin/nsd -d

Please guide me.

are you self hosting this and port forwarding though a router?

Try sudo service nsd restart on the command line to fix the NSD issue.

For the other issues, check ufw status to insure that those ports are open at your server level and if they are confirm with your VPS provider that they do not have a firewall blocking your VPS.

or

If Chris’s suspicions are true, you are mostly on your own. Search this forum for posts from others who have been successful with such a set up, but we cannot offer support for this set up, sorry.

Like alento says … if your box is behind your router, it will be up to you to open up the relevant ports. It’s certainly doable but every router is slightly different and calls things by different names, so it will be a learning experience.

From the docs and my experience, you must open ports 22, 25, 53, 80, 443, 465, 587, 993, 995, 4190 through to your box.

I also found it helpful to add the router’s LAN address to the ignoreip = line in /etc/fail2ban/jail.d/mailinabox.conf - to prevent fail2ban locking your box out from itself when it’s doing status checks etc. Do ip route show default | awk '{print $3}' to get your router’s local address. (Packets sent out to the external address of a domestic router will be returned as if they were coming from the router itself - hairpin routing.)

(Any changes you make to config, will probably have to be repeated after any upgrades/reinstalls, so keep notes and keep changes to a minimum.)

Many routers that are commercial/enterprise do not support hair-pinning like Cisco

What on earth is hair-pinning? Been in networking for 20 years and not heard of that

The status report is misleading. It basically tries to connect to the service on the public IP address. If that fails (which it most likely will if you’re behind a router/NAT) that’s the report you get.

But if it works I shouldn’t worry about it.

I wrote some mods for the Power Mail-in-a-box branch for container deployments which modifies the report a bit but doesn’t really fix it.

"Hairpinning goes by several names, including U-Turn NAT and NAT loopback. But none of these illustrate the concept (and its shortcomings, which we’ll discuss shortly) as effectively as the term hairpinning.

Hairpinning is a network process that occurs when two devices live on the same internal IP network, such as behind an office firewall or VPN, but communicate with each other using their external IP addresses.

In such instances, data would travel from the user’s device to the network’s NAT (natural address translator) or firewall. These data packets are then redirected back to the second device, instead of proceeding out to the public internet."

See: Hairpinning and Traffic Backhauling Guide

Did this get addressed? I am in the middle of upgrading from v57a to v61.1 and got bitten by this. The VPS does NOT (and will not) have IPv6. No issues with v57a. I tried forcing ip4 in nsd but that didn’t resolve the issue. Yes, the traffic for all ports flows fine to the system; not a firewall issue.

I believe that MiaB 61.1 requires ipv6 to work correctly. People that had it disabled all ran into issues.

I’ve wasted massive amounts of time with this one. In the process I was able to clean up the installation considerably. I have some feedback - unsure the best way to get this to anyone who cares.

  1. Some VPS installations are sensitive to logging issues. The MIAB configuration never worked on my VPS. The simplest workaround is to change nsd.conf to use log-only-syslog: yes, and I would suggest that this should be the default configuration (that will work in most cases). If someone wants to log to a file, they can do their system-specific configurations to enable that.

  2. I found that a cleaner setup included adding port: 53 to the configuration file. The startup log was very clear and helped me through troubleshooting the underlying issue in my situation. So, it would have been helpful if this had been a default setting; also recommend making it a default.

  3. And THE change that would have saved me HOURS of troubleshooting would have been if the “Public DNS (nsd4) is not running ( port 53).” status message were changed to “Public DNS (nsd4) is not running (IP port 53).” - include the IP address that was tested. This turned out to be the issue in my situation, and that one additional piece of information would have made a big difference.

In case anyone can benefit from my experience … the status checks uses PUBLIC_IP to do its tests. What happened in my case was that the PUBLIC_IP was not responding to the DNS request, but the PRIVATE_IP was. For whatever reason, my ISP was not handing the port 53 request to the server.

I had the simiar issue: where ystem Status Checks shows.:
|✖|Public DNS (nsd4) is not running (port 53).|

I found out that my server has also ipv6 enabled and nsd4 is not bale to run with ipv6.
So I disabled the ipv6 and started the nsd4 without any problem.
sysctl -w net.ipv6.conf.all.disable_ipv6=0
and
sysctl -w net.ipv6.conf.default.disable_ipv6=0
then
service nsd start
service nsd status

See also:

1 Like

I recently setup a new mail server on a new VPS, using miab the first time.
Everything went well, but the IP address of that new server had a bad reputation and was on the blocked list of proofpoint, preventing the delivery to certain mail systems. It turned out, that 3 out of 4 of Hetzner’s IP addresses I tried had a bad reputation (which is difficult to clear), but finally I found a clean IP.

To cut it short, I had to change the IPv4 address of my running miab.
After assigning the new IP to the server (they use DHCP, so just a restart after the change) I executed the installation script again and everything seems to work. The only thing is that the Status Checks returns “Public DNS (nsd4) is not running (port 53).”.

I digged my records @ns1.box.mydomain.net and all queries return correctly the new IP.

Then I searched for files containing the old IP and got 4 zone files (plus the 4 signed versions) with the old IP:

/etc/nsd/zones/box.mydomain.net.txt: IN A 116.xxx.xxx.170
/etc/nsd/zones/box.mydomain.net.txt:ns1 IN A 116.xxx.xxx.170
/etc/nsd/zones/box.mydomain.net.txt:ns2 IN A 116.xxx.xxx.170
/etc/nsd/zones/box.mydomain.net.txt:www IN A 116.xxx.xxx.170

I wonder how I can get the correct dig responses with the new IP for those record while the zone files contain the old IP. Anyway, probably this is the reason for the Status Checks error.
I want to correct this, but am not sure, if I should edit this zone file as they are created by a script and the root cause should be corrected. Especially the signed versions need certainly to be treated somehow.

Besides the main domain shown above, my miab takes care of another email domain. Those zone files have been correctly updated to the new IPv4.

Any idea how I can correct the above?

Please do not edit the zones file. Both UDP and TCP port 53 must be open on Hetzner. Did you make sure both these ports are open in the firewall? Do a fresh install. MIAB is meant to be run vanilla. Try restarting your instance and reinstalling. Try telnetting to port 53 from another instance or your local machine to check if port 53 is open. telnet yourinstanceIP 53 Sometimes the status check is wrong.

Thanks, vele, for those tips!

I restarted the server this morning and just checked again. The error disappeared!
Maybe the IP-change was too fresh and some DNS-records somewhere needed to be updated. I thought I understand the process, but it seems there are some things I still don’t comprehend… :slightly_smiling_face:

Anyway those old IPs are still in files I mentioned in my initial post. They seem to have no meaning. To understand the situation I searched through config files in /etc and found the following for the A record of “box . mydomain . net”:

/etc/nsd/zones/box.mydomain.net.txt OLD IPv4
/etc/nsd/zones/box.mydomain.net.txt.signed OLD IPv4

/etc/nsd/zones/mydomain.net.txt contains domain plus all subdomains with new IP
/etc/nsd/zones/mydomain.net.txt.signed contains domain plus all subdomains with new IP

So it seems like this:

  1. The error has nothing to do with the inconsistent zone files I found. It disappeared for unknown reasons
  2. The subdomain zone files for box. … are not updated after a change of the IP address, which has no effect on the DNS server. Instead all the subdomains are part of the zone for the main domain. This zone file is relevant and was updated correctly after the IP change.

Maybe the subdomain zone files are only needed after the initial installation and not maintained later on.

I am not really familiar with the code and how MIAB or NDS4 updates those files after an IP change but I am glad the error disappeared :smile: .