Reverse DNS not working on new install

I am hosting an Ubuntu 18.04 server myself in my own private cloud. I used Gandi and followed the directions to a T for configuring glue records and pointing DNS back to ns1.box.mydomain.com. Reverse dns is not working at all. It’s been 24 hours since I updated the glue records and dns. Any help would be greatly appreciated. About to give up!

root@box:~# nslookup x.x.x.x
** server can’t find x.x.x.x.in-addr.arpa: NXDOMAIN

All private info removed from below: (x.x.x.x, mydomain)

System
✖ SSH Login (ssh) is running but is not publicly accessible at x.x.x.x
✖ Public DNS (nsd4) is not running (port 53).
✖ Incoming Mail (SMTP/postfix) is running but is not publicly accessible at x.x.x.x
✖ Outgoing Mail (SMTP 465/postfix) is running but is not publicly accessible at x.x.x.x.
✖ Outgoing Mail (SMTP 587/postfix) is running but is not publicly accessible at x.x.x.x.
✖ IMAPS (dovecot) is running but is not publicly accessible at x.x.x.x:993.
✖ Mail Filters (Sieve/dovecot) is running but is not publicly accessible at x.x.x.x:4190.
✖ HTTP Web (nginx) is running but is not publicly accessible at x.x.x.x:80.

[show more](https://box.mydomain.com/admin#)
✖ HTTPS Web (nginx) is running but is not publicly accessible at x.x.x.x:443.

[show more](https://box.mydomain.com/admin#)
✖ The SSH server on this machine permits password-based login. A more secure way to log in is using a public key. Add your SSH public key to $HOME/.ssh/authorized_keys, check that you can log in without a password, set the option 'PasswordAuthentication no' in /etc/ssh/sshd_config, and then restart the openssh via 'sudo service ssh restart'.
✓ System software is up to date.
✓ Mail-in-a-Box is up to date. You are running version v0.54.
✓ System administrator address exists as a mail alias. [administrator@box.mydomain.com ↦ info@mydomain.com]
✓ The disk has 38.62 GB space remaining.
✓ System memory is 91% free.
Network
✓ Firewall is active.
✓ Outbound mail (SMTP port 25) is not blocked.
✓ IP address is not blacklisted by zen.spamhaus.org.
box.mydomain.com
✓ DNSSEC 'DS' record is set correctly at registrar.
✖ Nameserver glue records are incorrect. The ns1.box.mydomain.com and ns2.box.mydomain.com nameservers must be configured at your domain name registrar as having the IP address x.x.x.x. They currently report addresses of [Not Set]/[Not Set]. It may take several hours for public DNS to update after a change.
✖ This domain must resolve to your box's IP address (x.x.x.x) in public DNS but it currently resolves to [Not Set]. It may take several hours for public DNS to update after a change. This problem may result from other issues listed above.
✖ Your box's reverse DNS is currently [Not Set], but it should be box.mydomain.com. Your ISP or cloud provider will have instructions on setting up reverse DNS for your box.
? The DANE TLSA record for incoming mail is not set. This is optional.
✓ Hostmaster contact address exists as a mail alias. [hostmaster@box.mydomain.com ↦ administrator@box.mydomain.com]
✓ Domain's email is directed to this domain. [box.mydomain.com has no MX record, which is ok]
✓ Postmaster contact address exists as a mail alias. [postmaster@box.mydomain.com ↦ administrator@box.mydomain.com]
✓ Domain is not blacklisted by dbl.spamhaus.org.
✖ The TLS (SSL) certificate for this domain is currently self-signed. You will get a security warning when you check or send email and when visiting this domain in a web browser (for webmail or static site hosting).
mydomain.com
✓ DNSSEC 'DS' record is set correctly at registrar.
✖ The nameservers set on this domain are incorrect. They are currently [Not Set]. Use your domain name registrar's control panel to set the nameservers to ns1.box.mydomain.com; ns2.box.zcloudservices.com.
✖ This domain's DNS MX record is not set. It should be '10 box.mydomain.com'. Mail will not be delivered to this box. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.
✓ Postmaster contact address exists as a mail alias. [postmaster@mydomain.com ↦ administrator@box.mydomain.com]
✓ Domain is not blacklisted by dbl.spamhaus.org.
✖ This domain should resolve to your box's IP address (A x.x.x.x) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to [Not Set] in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.
✖ www.mydomain.com: This domain should resolve to your box's IP address (A x.x.x.x) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to [Not Set] in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.
✖ autoconfig.mydomain.com: This domain should resolve to your box's IP address (A x.x.x.x) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to [Not Set] in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.
✖ autodiscover.mydomain.com: This domain should resolve to your box's IP address (A x.x.x.x) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to [Not Set] in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.

Hi, a few thoughts re your install.

  • You say it’s on your “own private cloud” - what do you mean by that? Is it in-the-cloud at AWS or similar? Or is it on your own physical or virtual servers somewhere? Just what is your setup?

  • All those status lines starting :heavy_multiplication_x: indicate a problem. Some of those are drop-dead problems … all those port-not-accessible lines are problems. The rest of the world has to be able to contact your server at ports 22, 25, 53, 80, 443, 465, 587, 993, 995, 4190 - if you’re running behind a firewall, those ports have to be open through to your box. (You may need to contact your server provider to open those ports.)

  • Re reverse DNS. Your address belongs to whoever allocates your IP address, and the reverse-DNS entry is under their control (probably your ISP). Once you’ve got all those ports open, and those :heavy_multiplication_x:s become s, ask them to set the reverse DNS. (This doesn’t apply when you’re allocating IP addresses yourself - either you own an IPv4 block or have been allocated an IPv6 prefix - but if that’s the case, you’ll need more expertise.)

Open up those ports and you’ll be sorted (or mostly sorted).

This looks to me like it is set up on a private network behind a firewall, because MiaB will report a bunch of ports closed even through it functions as if they are opened, or at least that was the behavior I observed when it was on 14.04 and I had it set up on a residential ISP.

The issue with PTR record can only be resolved with the owner of the IP address.

The rest of the issues are impossible to troubleshoot effectively with the anonymized information.

The nameserver line needs to state that the record is supposed to be pointing that the same IP address as the public IP address.

I find it is better to check records outside of the box and from an external IP address, ideally with a tool that does not cache. A quick tool that MiaB should respond to and doesn’t cache is https://gwhois.org.

To clarify, I work at a data center and this VM is running in VMware Cloud Director which is a private cloud offering similar to AWS, Azure Etc., only private. Commercial ISP.

I have resolved the reverse DNS issue as we own the IP and I just needed to add the PTR record.

I have checked all the ports that are showing as inaccessible and they are indeed open.

server is box.zcloudservices.com 209.151.200.233.

Also, since I’m using our own DNS servers, I’m thinking that I may need to add a forward lookup zone for zcloudservices.com as well. The way the documentations is written, it appeared to me that the forward DNS would be handled by the box server itself. Is this correct?

MiaB will automatically configure A records for hosted domains.

Is the only issue you have the dashboard reporting the ports not open and the domain IP address as not correct? This is basically a known issue for servers behind a firewall. I don’t know if anyone has resolved it at least for themselves.

You should see if the server can provision LE certs and you can remove the DNSSEC warnings by adding the DS records at your registrar.

Of course, the best solution is to assign MiaB a public IP address, as that is what the project assumes the server to be used as.

The server does have a public IP. This setup should be no different than hosting it with Linode and I’m thinking adding the forward DNS zone to our DNS server should fix most of this. As you can see below, the server cannot resolve it’s own hostname forwards:

root@box:~# nslookup box.zcloudservices.com
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find box.zcloudservices.com: SERVFAIL

root@box:~# nslookup 209.151.200.233
233.200.151.209.in-addr.arpa    name = box.zcloudservices.com.

Authoritative answers can be found from:
200.151.209.in-addr.arpa        nameserver = ns02.zerolayer.net.
200.151.209.in-addr.arpa        nameserver = ns01.zerolayer.net.

root@box:~# wget -q -O - ipinfo.io/ip
209.151.200.233root@box:~# 

I will provide update after I add the forward zone but here’s where the system checks stand as of now. Also unable to use let’s encrypt because of the DNS issue. I am now determined to figure this out!

I am able to send and receive email using the initial account I created. Just FYI. The only functional issue I can see so far is the let’s encrypt DNS thing.

UPDATE:

I created a forward lookup zone on our public DNS servers for zcloudservices.com and added an entry for box. DNS is working everywhere except for on the machine itself using the self contained name server. If I change the name server to use google, it works fine. Still can’t use let’s encrypt because of this.

root@box:~# nslookup box.zcloudservices.com
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find box.zcloudservices.com: SERVFAIL

root@box:~# nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> box.zcloudservices.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   box.zcloudservices.com
Address: 209.151.200.233

I resolved the DNS issue by adding a conditional forwarder to /etc/bind/named.conf.options and the server is now able to resolve it’s own hostname and provision certs via LE.

There are still the below remaining issues which I may start a new topic to work on. This is a proof of concept for us as a cloud provider and it would be helpful to have someone work on this with us to figure out what the difference is between what we’re doing and the other cloud providers that you support. I’d be interested in looking at the details of the checks that are taking place here.

✖	
SSH Login (ssh) is running but is not publicly accessible at 209.151.200.233:22.

✖	
Public DNS (nsd4) is not running (port 53).

✖	
Incoming Mail (SMTP/postfix) is running but is not publicly accessible at 209.151.200.233:25.

✖	
Outgoing Mail (SMTP 465/postfix) is running but is not publicly accessible at 209.151.200.233:465.

✖	
Outgoing Mail (SMTP 587/postfix) is running but is not publicly accessible at 209.151.200.233:587.

✖	
IMAPS (dovecot) is running but is not publicly accessible at 209.151.200.233:993.

✖	
Mail Filters (Sieve/dovecot) is running but is not publicly accessible at 209.151.200.233:4190.

✖	
HTTP Web (nginx) is running but is not publicly accessible at 209.151.200.233:80.

✖	
HTTPS Web (nginx) is running but is not publicly accessible at 209.151.200.233:443.

✖	
MTA-STS policy is missing: STSFetchResult.FETCH_ERROR

Welcome to the MIAB community!

You made some progress, that’s great!
Indeed the ports look open from the Internet:

Nmap scan report for box.zcloudservices.com (209.151.200.233)
Host is up (0.16s latency).
Not shown: 991 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
53/tcp  open  domain
80/tcp  open  http
443/tcp open  https
465/tcp open  smtps
587/tcp open  submission
993/tcp open  imaps
995/tcp open  pop3s

If all works we can assume the issue is “cosmetic” related to the way you assign the public IP to the VM, how is your interface configured on VM?

You can look at the Python script that performs the checks:

mailinabox/management/status_checks.py

def check_service(i, service, env):
        if not service["port"]:
                # Skip check (no port, e.g. no sshd).
                return (i, None, None, None)

        output = BufferedOutput()
        running = False
        fatal = False

        # Helper function to make a connection to the service, since we try
        # up to three ways (localhost, IPv4 address, IPv6 address).
....

look further, what’s the logic that runs the public tests, something is failing there with regards to the variables and your VM ethernet intreface address?

There are multiple ways that you could configure the VM interfaces here is an example of my MIAB on Linode VM:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether f2:3c:92:ab:cd:ef brd ff:ff:ff:ff:ff:ff
    inet 139.x.x.x/24 brd 139.x.x.x scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.x.x/17 brd 192.168.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a01:x::x:x:x:x/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2592000sec preferred_lft 604800sec
    inet6 2a01:x:x:x::x/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::x:x:x:x/64 scope link 
       valid_lft forever preferred_lft forever

Cheers,
Martin

1 Like

@mveplus Yes thank you! I can see that your Linode VM does indeed have a public IP assigned directly to the interface as opposed to having a private IP and using NAT like mine does. That seems to be the difference maker here. I’m pretty sure I know what to do moving forward. As you stated, this is “cosmetic” as all functionality is indeed working.

Hi ztaylor10 and others in a similar situation. You might have discovered this yourself, but there is a config file (/etc/mailinabox.conf) which stores and sets the public and private IPv4 and IPv6 addresses. MIAB will try to establish those addresses (and asks you to confirm during the install) but I have seen it get confused. You can edit this file (it’s actually a shell script) and the install will run with whatever you specify.

For NAT sites, the machine will have public and private IPv4 addresses - public is the external facing that other computers will use to contact your server; private is the LAN address that your machine uses. For machines (like yours) which directly face the world, you would not have a private address.

For IPv6, the machine will almost normally use just it’s unique global address, so should not have a private IPv6 address. I suggest ignoring IPv6 initially. If you disable it with
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
before installing/updating MIAB, then you get an install that runs fine using only IPv4.

Thanks for the info @andrew. I think I’ve figured out what needs to happen when the VM is behind a NAT firewall. Most firewalls by default block traffic with the same origin and destination as would be the case here. I am going to add a firewall rule that allows a “hairpin” turn and then do a fresh install. That should clear up the status check issue and I should be able to avoid manually configuring the DNS forwarders. In the case where that still doesn’t work, I will eliminate the firewall completely and assign the public IP directly to the server.

I will provide an update on Monday.

@openletter @andrew @mveplus look what I can do

This is still with the box vm having a private IP and the firewall translating public to private using NAT. The only rules I had to add were to allow what is known as “hair-pinning” so that the box VM could reach itself using it’s public IP.

System

✓	
All system services are running.

✓	
SSH disallows password-based login.

✓	
System software is up to date.

✓	
Mail-in-a-Box is up to date. You are running version v0.54.

✓	
System administrator address exists as a mail alias. [administrator@box.zcloudservices.com ↦ info@zcloudservices.com]

✓	
The disk has 84.94 GB space remaining.

✓	
System memory is 89% free.

Network

✓	
Firewall is active.

✓	
Outbound mail (SMTP port 25) is not blocked.

✓	
IP address is not blacklisted by zen.spamhaus.org.

box.zcloudservices.com

✓	
DNSSEC 'DS' record is set correctly at registrar.

✓	
Nameserver glue records are correct at registrar. [ns1/ns2.box.zcloudservices.com ↦ 209.151.200.233]

✓	
Domain resolves to box's IP address. [box.zcloudservices.com ↦ 209.151.200.233]

✓	
Reverse DNS is set correctly at ISP. [209.151.200.233 ↦ box.zcloudservices.com]

✓	
The DANE TLSA record for incoming mail is correct (_25._tcp.box.zcloudservices.com).

✓	
Hostmaster contact address exists as a mail alias. [hostmaster@box.zcloudservices.com ↦ administrator@box.zcloudservices.com]

✓	
Domain's email is directed to this domain. [box.zcloudservices.com ↦ 10 box.zcloudservices.com]

✓	
MTA-STS policy is present.

✓	
Postmaster contact address exists as a mail alias. [postmaster@box.zcloudservices.com ↦ administrator@box.zcloudservices.com]

✓	
Domain is not blacklisted by dbl.spamhaus.org.

✓	
TLS (SSL) certificate is signed & valid. The certificate expires in 85 days on 2022-01-11.

zcloudservices.com

✓	
DNSSEC 'DS' record is set correctly at registrar.

✓	
Nameservers are set correctly at registrar. [ns1.box.zcloudservices.com; ns2.box.zcloudservices.com]

✓	
Domain's email is directed to this domain. [zcloudservices.com ↦ 10 box.zcloudservices.com]

✓	
MTA-STS policy is present.

✓	
Postmaster contact address exists as a mail alias. [postmaster@zcloudservices.com ↦ administrator@box.zcloudservices.com]

✓	
Domain is not blacklisted by dbl.spamhaus.org.

✓	
Domain resolves to this box's IP address. [zcloudservices.com ↦ 209.151.200.233]

✓	
TLS (SSL) certificate is signed & valid. The certificate expires in 85 days on 2022-01-11.

✓	
www.zcloudservices.com: Domain resolves to this box's IP address. [www.zcloudservices.com ↦ 209.151.200.233]

✓	
www.zcloudservices.com: TLS (SSL) certificate is signed & valid. The certificate expires in 85 days on 2022-01-11.

✓	
autoconfig.zcloudservices.com: Domain resolves to this box's IP address. [autoconfig.zcloudservices.com ↦ 209.151.200.233]

✓	
autoconfig.zcloudservices.com: TLS (SSL) certificate is signed & valid. The certificate expires in 85 days on 2022-01-11.

✓	
autodiscover.zcloudservices.com: Domain resolves to this box's IP address. [autodiscover.zcloudservices.com ↦ 209.151.200.233]

✓	
autodiscover.zcloudservices.com: TLS (SSL) certificate is signed & valid. The certificate expires in 85 days on 2022-01-11.


2 Likes

So apparently this is “NAT reflection”, and it seems notable that the pfSense docs recommend using split DNS, but I didn’t look closely enough to see if this would actually resolve the issue with MiaB.

https://docs.netgate.com/pfsense/en/latest/recipes/port-forwards-from-local-networks.html

1 Like