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

#1

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.

#2

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

#3

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.

#4

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

#5

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

#6

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

#7

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.

#8

"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

#9

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.

#10

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

#11

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.