Every couple of days, my box alternates between: Your box’s reverse DNS is currently [Not Set], but it should be mail.acedb.co. Your ISP or cloud provider will have instructions on setting up reverse DNS for your box.
and:
✓ Reverse DNS is set correctly at ISP. [146.229.97.10 ↦ mail.acedb.co]
Every time I check it, the reverse DNS is working fine. The owner of my IPs is not making any changes. Any ideas what could be causing this? I have NOT altered the address or host name in case anyone would like to look at how my DNS is set up.
I ran into the system check warning about my reverse dns on VULTR hosting being wrong about a week after everything was perfect on initial setup. I added the instance IP on the rDNS field x.x.x.x.box.domain.com and then saw my mail deliverability score drop due to IP mismatch to PTR with the IP. VULTR saw no issue in a ticket I sent them so I put the VULTR rDNS field back to box.domain.com (domain=my actual domain) and tested again using mail-tester.com and got back up to 10/10 good deliverability.
The rDNS requirement is just to have one. I have webserver that sends transactional email for ~12 domains. Never have anything declared as spam from that server despite the fact that the rDNS doesn’t doesn’t match.
That said, not having the record is almost guaranteed to result in spam.
I saw this issue corrected later today and advised VULTR in case they knew of something that had changed. While testing earlier with them their test of
dig -x x.x.x.x @1.1.1.1 (x.x.x.x = my instance IP) resulted in a Answer record for PTR while mine didn’t.
They reply to my update saying they had been made aware of an issue with their DNS earlier today (I assume me) and corrected it. So I guess it’s worth contacting the host (as the MaiB message advises) just in case there’s something a miss on their end. Just wanted to update this topic for other to see this outcome.
I’ve been investigating this error and I think that I found the reason for this. It would be nice if you could try out the following (just once, don’t do it more than once!):
Sign in via SSH to your box
Run the following command sed -i "s/^}/\n\tmax-recursion-queries 100;\n}/" /etc/bind/named.conf.options
Run service bind9 restart
Then have a close look whether the status keeps changing or if it stays stable.
I would appreciate feedback.
I’ve mentioned in another thread that, I made the change hija suggested, e.g. added “max-recursion-queries 100;” to /etc/bind/named.conf.options and restarted bind on 2020-12-08 04:45.
My latest “Not Set” was sent on 2020-12-08, the patch was made on the same day. Next day I got the “set” in that days Status Checks Change Notice email. All five of status checks after this fix was installed, have been successful e.g. I haven’t received any “Not Set” notifications after I added “max-recursion-queries 100;” to /etc/bind/named.conf.options.
If people have to use external systems because our internal status checks we need to work on the status checks. That’s why I did the PR – I want MIAB to have good internal status checks rather than forcing users to use external tools.
From my side the bug is gone since more than 2 weeks now, how is it going for you @ge8Hooe?
I haven’t had single “reverse DNS is currently [Not Set]” notification since I applied the patch.
The default value of max-recursion-queries is 50, and I suspect that in my case the default value was almost enough, because I’d get somewhat regularly “Not Set” and “Set” notifications, some times there could be a few days apart, but lately I got “Not Set” notification every other day, and the next day I’d get the “Set” notification.
If that fix does not get applied to the MIAB source, I’ll have to keep a separate patch for it myself.
Yup. I proposed a solution on Github and Josh asked me if there are others who can test the solution and this is why i posted the fix here. @ge8Hooe tried the fix out as well and so we have two people who are happy with the fix and don’t experience any side effects. I will notify Josh soon that I think the fix is ready to be merged
I’ve been seeing this issue more in the past month so I’m wondering if the above recommend RETRY and @ge8Hooe fix have been looked into?
Your box’s reverse DNS is currently [timeout]
If ignored it shows corrected for Not Set or Timeout in the next days update but certainly seems to be a false positive that may send others down a path of thinking there’s a problem.
Perhaps a disclaimer for both error types would be instructions to the user to self verify with a dig command before they end up contacting their host or try any type of reinstall.
FWIW, I’ve never seen [timeout] message in my “Status Checks Change Notice” emails.
What I’ve seen, even when running latest MIAB version 0.52, which by default has “max-recursion-queries 100;” in “/etc/bind/named.conf.options”, is that I receive emails from a valid domain but in the short period, when the status check is running, at least the IP to name resolution is broken.
For example, on March 13th between 03:09:47 and 03:28:48 localtime, there are number of of “connect from unknown” errors in the mail.log.
The IP to name resolution was valid at Mar 13 until 03:09:25 and it was also valid 03:31:56 onward.
I’ve experienced this so many times that I’ve made a script that removes those specific IP addresses from fail2ban automatically, if those spesific IP addresses are banned.
Your box’s reverse DNS is currently [Not Set], but it should be mail.acedb.co. Your ISP or cloud provider will have instructions on setting up reverse DNS for your box.
That’s why I did the PR – I want MIAB to have good internal status checks rather than forcing users to use external tools.