Bind restart failure: zone example.com/IN: has no NS records

Anytime I add or remove a zone, my ISPConfig log is flooded with the following error messages:

Code:

WARNING - Reason for Bind restart failure: zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.

The zone works fine after and no more errors are reported.
And

Code:

WARNING - Writing BIND domain file failed: /etc/bind/pri.example.com zone example.com/IN: has no NS records zone example.com/IN: not loaded due to errors.

I was wondering if anyone else saw this problem on their system - otherwise, I'll do some more digging.

HTF Common issues script, to comply with my self written read before posting:

Code:

##### SERVER #####
IP-address (as per hostname): ***.***.***.***
[WARN] could not determine server's ip address by ifconfig
[INFO] OS version is Debian GNU/Linux 10 (buster)
[INFO] uptime:  19:59:38 up 12 days,  9:41,  1 user,  load average: 0.04, 0.03, 0.00
[INFO] memory:
              total        used        free      shared  buff/cache   available
Mem:          3.9Gi       238Mi       3.0Gi        42Mi       675Mi       3.4Gi
Swap:            0B          0B          0B
[INFO] systemd failed services status:
0 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

[INFO] ISPConfig is installed.

##### ISPCONFIG #####
ISPConfig version is 3.2.2


##### VERSION CHECK #####

[INFO] php (cli) version is 7.3.19-1~deb10u1

##### PORT CHECK #####

[WARN] Port 8080 (ISPConfig) seems NOT to be listening
[WARN] Port 8081 (ISPConfig Apps) seems NOT to be listening
[WARN] Port 80 (Webserver) seems NOT to be listening
[WARN] Port 443 (Webserver SSL) seems NOT to be listening
[WARN] Port 143 (IMAP server) seems NOT to be listening
[WARN] Port 993 (IMAP server SSL) seems NOT to be listening
[WARN] Port 110 (POP3 server) seems NOT to be listening
[WARN] Port 995 (POP3 server SSL) seems NOT to be listening
[WARN] Port 465 (SMTP server SSL) seems NOT to be listening
[WARN] Port 21 (FTP server) seems NOT to be listening
[WARN] Port 22 (SSH server) seems NOT to be listening

##### MAIL SERVER CHECK #####

[WARN] I found no "smtp" entry in your postfix master.cf
[WARN] I found no "submission" entry in your postfix master.cf
[INFO] this is not critical, but if you want to offer port 587 for smtp connections you have to enable this.
[WARN] I found no "smtps" entry in your postfix master.cf
[INFO] this is not critical, but if you want to offer SSL for smtp (not TLS) connections you have to enable this.

##### RUNNING SERVER PROCESSES #####

[WARN] I could not determine which web server is running.
[INFO] I found the following mail server(s):
   Unknown process (sendmail:) (PID 817)
[WARN] I could not determine which pop3 server is running.
[WARN] I could not determine which imap server is running.
[WARN] I could not determine which ftp server is running.

##### LISTENING PORTS #####
(only       ()
Local       (Address)
[anywhere]:16       (660/sshd)
***.***.***.***:53       (651/named)
[localhost]:53       (651/named)
[localhost]:25       (817/sendmail:)
[localhost]:953       (651/named)
[localhost]:587       (817/sendmail:)
[localhost]:11211       (635/memcached)
[localhost]6       (660/sshd)
*:*:*:*::*:53       (651/named)
*:*:*:*::*:953       (651/named)
*:*:*:*::*:3306       (737/mysqld)

EDIT:
This is the DNS Wizard template that's used:

Code:

[ZONE]
origin={DOMAIN}.
ns=ns1.amsterdamtech.net.
mbox=hostmaster.amsterdamtech.nl.
refresh=14400
retry=3600
expire=1209600
minimum=300
ttl=3600
xfer=X.X.X.X
also_notify=X.X.X.X
dnssec_wanted=Y

[DNS_RECORDS]
A|{DOMAIN}.|{IP}|0|3600
AAAA|{DOMAIN}.|{IPV6}|0|3600
CNAME|www|{DOMAIN}.|0|3600
CNAME|ftp|{DOMAIN}.|0|3600
CNAME|autoconfig|autoconfig.example.com.|0|86400
CNAME|autodiscover|autodiscover.example.com.|0|86400
SRV|_autodiscover._tcp|0 443 autodiscover.example.com.|0|86400
MX|{DOMAIN}.|mx1.example.com.|10|86400
MX|{DOMAIN}.|mx2.example.com.|10|86400
NS|{DOMAIN}.|ns1.example.com.|0|86400
NS|{DOMAIN}.|ns2.example.com.|0|86400
NS|{DOMAIN}.|ns3.example.com.|0|86400
TXT|{DOMAIN}.|v=spf1 a include:_spf.example.com -all|0|3600
TXT|_dmarc|v=DMARC1;p=quarantine;adkim=r;aspf=s;|0|3600

 

That's normal and there is no easy way to avoid it, changes get applied in order, which means the zone gets added first and then the records get added. The script can't look into the future, so it can't know if and when a record might get added in future that might be missing at this time, therefore the zone reload might fail if some important records are missing.

 

These errors come from ISPConfig, and I have not seen them so far on any other ISPConfig system. You would say creating a zone from the UI with the wizard, when the template has all necessary records, no errors should be thrown, right?

 

These messages always show up, at least on multiserver systems, changes always are applied in order and the script can't look into the future, so it can't know if a new record will get added after the zone was added. It does not matter for this if you use the wizard or not, the wizard does the same thing as if you would enter the records one by one.

 

Alright, that explains why I have not seen it before, usually panel and master DNS were on the same server. Maybe we should do something about these warnings then? Disable them when the DNS server is not the master server?

 

The problem is that no warnings will be shown then. What we might try is that we suppress them unless the zone has at least two NS records, but this might need to be checked in the generated zone file and not the database, as the database might contain already the records while they have not been processed yet by the jobqueue. So it#s a bit tricky and that's why it's like this at the moment, especially as these are just warnings and not errors.

 

Alright. For now, I have changed the loglevel to errors.

 

Every zone needs NS records, otherwise BIND will not load it. So if you see this error, there are no NS records and they are mandatory.

 

My bad, I misread it.

The error should go away immediately, it's weird that it did not in your case. Propagation is not necessary. Did the server.sh script run fine on the node?

 

I suspect it was a fluke, but there are things to improve for the DNS module in the future. I'll keep it in mind.

 

As said above, change the log level to errors for your nameserver(s).