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

Discussion in 'Installation/Configuration' started by Th0m, Feb 14, 2021.

  1. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    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
     
    Last edited: Feb 14, 2021
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
  3. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    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?
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
  5. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    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?
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
  7. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

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

    TonyG Active Member

    I just created a new client, logged in as that client, then added a zone.
    Zone Settings continues to report:
    Of course there are two NS records, and all background tasks have been processed. Do we need to wait for DNS to propagate and resolve?

    With regard to the other notes in this thread, I was thinking the message could be softened to something like "NS records are not yet active", since the records are apparently there after the queue has been processed. And if this is a resolution issue, perhaps when there are 2+ NS records present it could say "might require time for new domain propagation".

    My ultimate thought here is that if we have some idea of the actual state after creating a new zone, then perhaps that information can be conveyed - and if we don't, then of course "unknown status" or "possibly in BIND restart" or similar text can convey that we know the record is there but that we aren't sure where the processing is after that.

    HTH & TY
     
  9. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    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.
     
  10. TonyG

    TonyG Active Member

    I said
    Th0m responded
    Perhaps I should have posted a screenshot. This seems to be a propagation issue. I was able to browse to the site, and add a LE cert using the Site maintenance. The "no NS records" issued cleared sometime after that.
     
  11. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    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?
     
  12. TonyG

    TonyG Active Member

    The queue was cleared, or at least the indicator cleared, with the number of queue items in red. To my understanding, when that indicator clears, the task is done. I don't go to logs to double check between operations. If that indicator is removed when an operation was still in progress, then the warning makes sense - except that the zone was apparently updated with NS records. Sooo... :eek:
     
  13. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    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.
     

Share This Page