There’s an old thread about the same issue does not appear to be resolved yet. I’ve been seeing this (specifically the (timeout) flavour of it), i.e.
This (via email)
================================
✓ Reverse DNS is set correctly at ISP. [nn.nn.nn.nn ↦ box.xxxxx.com]
box.xxxxx.com -- Currently:
===============================
✖ This box's reverse DNS is currently [timeout], but it should be box.xxxxx.com. Your ISP or cloud provider will have instructions on setting up reverse DN
Followed (often the next day) with
box.xxxxx.com -- Previously:
==============================
✖ This box's reverse DNS is currently [timeout], but it should be box.xxxxx.com. Your ISP or cloud provider will have instructions on setting up reverse DNS for this box.
box.xxxxx.com -- Currently:
=============================
✓ Reverse DNS is set correctly at ISP. [nn.nn.nn.nn ↦ box.xxxxx.com]
It’s been happening forever, but a) for most of the time there were other things getting reported on, most often packages that can be upgraded, which have thankfully gone more quiet of late leaving b) it happening more and more often that the Reverse DNS false alarm is the only thing in the email.
I juggle a large number of balls, some of which are systems like the MiaB servers, so I try to arrange it that they look after themselves as much as possible so it’s important in my life that when they do squeal that I can trust it’s a real issue. All along I suspected that it was caused by my ISP or its upstream provider doing maintenance in the dead of night when MiaB also does its checks and was preparing to tackle troubleshooting the problem with them when for the sake of due diligence I wanted to rule out that it wasn’t a MiaB problem. That’s when I found the old post and saw that it was never closed as done.
From the old post, how frequently I’ve seen the false reports, and the amount of network changes I have brought in including full redundant links and failover, it seems most unlikely that the problem is caused by an actual network level timeout of any DNS server other than the one on the box host itself. Could it be going through a routine restart sequence at the time, perhaps even triggered by the same script that checks it or another cron job?
Either way my sanity and I would really appreciate if we could finally get to the bottom of this and eliminate the false reporting. I need the assurance that if something does go wrong I will bet an alarm so I won’t disable it. If you point me towards the code that does the check I will have a look at it myself, but it’s not my territory and i’ve gathered that Josh is kinda protective about his.
By the history of posts, there have been other issues posted with Reverse DNS being wrong, but after scanning those they seem to mostly be about genuine issues with how MiaB and the PTR records have been configured. This is exclusively about the self-correcting timeout every so often getting reported as a misconfiguration alarm.
Also, I run two independent MiaB servers, and I do not recall ever seeing both of them reporting the timeout on the same day. On consecutive days yes, with one recovering on the same day the other reports a timeout, yes, but there has been no correlation between them as to when they will time out. That said, the two boxes were assigned different minutes into the maintenance hour to run their jobs, which is why I misread the symptoms as possibly network related. Until I found out that it’s an old problem in MiaB, that is.