System Status Check claims reverse DNS is not correct

If it’s intermittent and you’re not seeing other problems, then it’s likely safe to ignore. This has been a long-standing issue that seems to be just about the status checks and no one has been able to track down yet what exactly is happening.

This reverse DNS issue is still happening by the way. I’m on DO for a week now, and I’ve seen it happen a few times.

A year from the original post, I can confirm the issue is still open (MIAB latest version, DO).

Now something different…
I have a little PHP status monitor which regularly “pings” (not really ICMP packet) SMTP port of MIAB instance.
Very hacky way to make sure the service is up. The interesting piece is that whenever I get a message from MIAB about “reverse DNS not set properly”, same moment I get the message “service down” from the monitor.

The service wakes up the next tick, so nothing dangerous here, but I am wondering what would happen if someone sends me an email right the moment this “failure” happens?

I am no email expert but, wouldn’t the sending mail agent try again by definition?

Possibly unrelated, but I got this alert a couple day ago, also a one-off that solved itself by next day.

*****.org -- Previously:
===========================
✓  Nameservers are set correctly at registrar. [ns1.box.*****.org; ns2.box.*****.org]

*****.org -- Currently:
==========================
?  The nameservers set on this domain at your domain name registrar should be ns1.box.*****.org; ns2.box.*****.org. They are currently NS2.BOX.*****.ORG; ns1.BOX.*****.ORG. If you are using External DNS, this may be OK.

Domain name was also in uppercase in "They are currently NS2.BOX.*****.ORG; ns1.BOX.*****.ORG. "

No idea what may have triggered this, domain name are in lowercase at registar.
There was no problem accessing the box, so it look like a status check problem.

Registar is joker.com
MIAB is hosted on a french OVH dedicated server (inside a VM).

Hope this can help somehow ?

2 years have passed. It’s 2017, MIAB is working, and I still receive this notorious message, along with other notifications, on a daily basis. Well, at least I know that my box is working :slight_smile:

I’m on Digital Ocean, btw

Again 2 years passed - 2019 - and i´m getting same notifications up to 3 times per week. I´m on netcup so i don´t think it´s a hoster problem.

VULTR hosting here and I see this too every now and then (like today) and it resolves itself apparently. Although the last time it happened I submitted a ticket and should have ask for more details as they indicated something may have been adjusted.

And a day later- all is good- I took no action.

[…] – Previously: ============================== :heavy_multiplication_x: Your box’s reverse DNS is currently [Not Set], but it should be […]. Your ISP or cloud provider will have instructions on setting up reverse DNS for your box. […]-- Currently: ============================= ✓ Reverse DNS is set correctly at ISP. IP ↦ […]

I had the same experience on Vultr.

MiaB status email on August 14 indicated no rDNS for my IPv6 address - I actually didn’t notice this part of the message when it arrived because it was buried under 21 new package updates available on the same day.

The next day, August 15, the IPv6 rDNS was set correctly. I hadn’t even logged into the Vultr dashboard for at least a week, so something completely on their end.

At this point, I don’t find it a serious concern as most email servers are still using IPv4 and I don’t know how long the issue persisted. A few hours of no rDNS every now and then isn’t really very serious.

I’m experiencing this also.
After June 4th the MIAB status check has not changed from [Not Set] to the set values.
I made a shell script, which is pasted below, that checks A and PTR records, which is ran from root users crontab every 15 minutes.
I’ve yet to receive any emails from the shell script, and I’ve setup my MIAB box so that I get all emails that are set to root user as well…

#!/bin/sh
set -u
send_email=0
host_output=""
reverse_output=""

#
# Query what IP addresses resolve to hostname
#
host_output=$(host $(uname -n))
send_email=$(( send_email + $?))

#
# Loop through all PTR records
#
for i in $(echo "$host_output"|awk '/\ has.*address\ / {print $NF}')
do
	tmp_out=$(host $i)
	reverse_output="$reverse_output
$tmp_out"
	send_email=$(( send_email + $?))
done
if [ "${send_email}" -gt "0" ] ; then
	echo "Something went wrong

$host_output

$reverse_output"
fi
exit 0

I got bitten by this, because the sender.domain IP addresses were banned by fail2ban, due to the errors below, when my box was connected by external MTA when “status_checks.py” was running in the background, in order to receive valid email from a valid domain:

Aug 21 03:40:47 box postfix/smtpd[PID]: NOQUEUE: reject: RCPT from unknown[IPv6 address]: 450 4.1.8 <mailinglist@sender.domain>: Sender address rejected: Domain not found; from=<owner-mailinglist@sender.domain> to=<localuser@box.recipient.domain> proto=ESMTP helo=<mx.domain>
Aug 21 03:40:49 box postfix/smtpd[PID]: NOQUEUE: reject: RCPT from unknown[IPv4 address]: 450 4.1.8 <mailinglist@sender.domain>: Sender address rejected: Domain not found; from=<owner-mailinglist@sender.domain> to=<localuser@box.recipient.domain> proto=ESMTP helo=<mx.domain>

So IMHO there is a small time window where reverse DNS does not work, some of the time.
I’m not sure, but is this really necessary to flush local DNS resolvers cache in status_check.py?

# clear bind9's DNS cache so our DNS checks are up to date
# (ignore errors; if bind9/rndc isn't running we'd already report
# that in run_services checks.)
shell('check_call', ["/usr/sbin/rndc", "flush"], trap=True)

Dear all,

please have a look here.

Best
hija

Hi,

Below are four latest “flip flops” from my MIAB.

2020-12-05 03:09 changed from “Not Set” to “set correctly”
2020-12-06 03:07 changed from “set correctly” to “Not Set”
2020-12-07 03:08 changed from “Not Set” to “set correctly”
2020-12-08 03:08 changed from “set correctly” to “Not Set”

I made the change hija mentioned, e.g. added “max-recursion-queries 100;” to /etc/bind/named.conf.options and restarted bind on 2020-12-08 04:45.

Quick googling suggested that this might be the explanation Recursive Client Rate limiting in BIND 9.9.8, 9.10.3 and 9.11.0 why rDNS fails occasionally.

1 Like

Yes :slight_smile: If you want to read more about it, you can read my PR here in which I talk a bit about the bug :slight_smile:

1 Like

Hi everyone! Sorry to dredge this issue back up but I’ve continued to receive intermittent rDNS failures after the last suggested fix.

For some background, I’m a DO support agent and have had a MiaB test Droplet up since November 2020 to better understand this intermittent problem. I made a simple script that will dig the IP and run a host lookup to compare those results against the DNS status checks that MiaB performs. It doesn’t seem like the rDNS record was unavailable or having propagation issues around the time that MiaB status check reported the rDNS record failure.

Anything else you recommend checking? I’m happy to peer behind any curtains as needed so we can come to a clear understanding of the cause for this behavior.

3 Likes

If it helps any, Vultr has the exact same issue on my MiaB instance.

Yep, we are still having the same issue on a couple of VPS from UpCloud, so it’s not provider specific.

1 Like

I had the Issue of wrong DNS Status Checks after reinstalling Ubuntu 18.04 and MIAB (because i didn’t really understand what was going on and it “just worked” - that’s bad if one time it doesn’t work).

The reason for my case was a still present DNSSEC Record at namecheap. I updated it, and suddenly only the MTA-STS (and SSL) errors are left, which I know how to remove (Provision certificates, restart bind9, sudo mailinabox).

For MTA-STS on MiaB, it should just work for domains using MiaB as a name server, but for domains using external DNS servers you just need to add the required A records and then the text record.