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)
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.
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.
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.
Well, I have this default setup, still, I get the error after first-time installation.
My Provider is onyxhosting.de, which seems to offer a little different Ubuntu 18.04 than, lets say, Digital Ocean.
But thanks for the Info about external DNS.
MiaB assumes Ubuntu Server 18.04. An ISP using something else, such as a modified OS, may present problems impossible for a development team to predict.
If you want to read more about it, you can read my PR