Sudden DNS Errors in all virtual servers

Virtualmin GPL
CentOS Linux 7.5.1804

I’ve made no manual changes to my server except for the installation of the usual Virtualmin-notified updates. Suddenly all of my virtual servers have DNS record warnings/errors,

Picking out one of the virtual servers and viewing the DNS Records in Virtualmin I get:

Warning - errors were found in this domain’s DNS records : This domain has email enabled, but none of the MX records point to it. Either the MX records should be corrected, or the email feature disabled if mail is hosted externally.

I host emails on my server, from what I’ve read this warning can probably be ignored, but if I do a test by disabling Email on this virtual server I then get:

Warning - errors were found in this domain’s DNS records : NS record ns1.mydomain.com. cannot be resolved to an IP address

Externally checking my DNS and MX records shows no problems, all virtual server’s websites and email function correctly. The glue records at my registrars are correct (domains at different registrars exhibit the same warnings). I wondered whether the recent CentOS 7 update (or perhaps a Virtualmin update) could have been the cause of these warning messages ‘suddenly’ appearing.

I’ve re-enable BIND on this virtual server, read through similar posts and have checked for .rpmsave files (there are none related to DNS), and whether my named.conf was rewritten (it was not). I’m now stumped, does anyone have any ideas what could be causing these warning messages?

Restarting BIND I see /var/log/messages for this virtual server:

May 13 09:59:40 server1 named[19978]: zone myvirtualserver.co.uk/IN: myvirtualserver.co.uk/MXmail.myvirtualserver.co.uk’ has no address records (A or AAAA)

DNS Records are:

myvirtualserver.co.uk SOA - Start Of Domain ns1.mydomain.com. root.ns1.mydomain.com. 1526197154 10800 3600 604800 ... myvirtualserver.co.uk NS - Name Server ns1.mydomain.com. myvirtualserver.co.uk NS - Name Server ns2.mydomain.com. myvirtualserver.co.uk A - IPv4 Address xx.xxx.xxx.xx www A - IPv4 Address xx.xxx.xxx.xx ftp A - IPv4 Address xx.xxx.xxx.xx m A - IPv4 Address xx.xxx.xxx.xx localhost A - IPv4 Address 127.0.0.1 webmail A - IPv4 Address xx.xxx.xxx.xx admin A - IPv4 Address xx.xxx.xxx.xx myvirtualserver.co.uk MX - Mail Server 5 mail.myvirtualserver.co.uk. myvirtualserver.co.uk SPF - Sender Permitted From v=spf1 a mx a:myvirtualserver.co.uk ip4:xx.xxx.xxx.xx ?all autoconfig A - IPv4 Address xx.xxx.xxx.xx autodiscover A - IPv4 Address xx.xxx.xxx.xx default._domainkey TXT - Text v=DKIM1; k=rsa; t=s; p=xxxxxxxxxxxxxxxxxxxxxxxx ...

Using dig

dig @xx.xxx.xxx.xx myvirtualserver.co.uk mx

gives no errors

So why dont you add A record for mail.####.tld?

I created mail.myvirtualserver.co.uk. IN A xx.xxx.xxx.xx
which cleared the /var/log/messages error, thank you for that suggestion.

the other warning messages in DNS Records still remain.

Warning - errors were found in this domain’s DNS records : NS record ns1.mydomain.com. cannot be resolved to an IP address

Did you register your nameservers with the IP(s) at domain registrar and then add DNS records for each of your nameserver (ns1, ns2…)?

myvirtualserver.co.uk NS - Name Server ns1.mydomain.com.

Do you have NS and A records for ns1.mydomain.com in the mydomain.com zone file?

To the last two posts

I have registered IP’s and name servers at my registrars.

The zone files all have NS and A records

myvirtualserver.co.uk. 38400 IN NS ns1.mydomain.com.

These virtual servers have successfully been running for a number of years. Different domains registered with different registrars have started to exhibit the same issue. Nothing has been changed in the zone files for some time.

I wonder, is there a way to locate backed up copies of the zone files, so I can confirm they haven’t changed? I’ll look into that. I might attempt a snapshot restoration of the server.

The issue is now resolved.

After reverting to older server snapshots (before I installed the 198 no. updates) and back again, it seems to have cured itself.

A bit annoyed at not being able to figure out just what the issue was.