• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

DNS failures due to bad zone file created by plesk

tkalfaoglu

Silver Pleskian
Once in a while I find the named service to be down on the server. Attempting "service named start" shows
a long list of domains loaded, along with one that shows something like this:

zone abc.com/IN: loaded serial 1349082568
zone abc.com/IN: has no NS records
zone abc.com/IN: not loaded due to errors.
_default/abc.com/IN: bad zone

If I go into PLESK at this point, to abc.com's control panel, and disable/enable DNS service for this domain,
the new abc.com file is re-created correctly and named starts.

Since this gives no prior warning, named stays down until I notice the problem - usually in the mail logs because spamassassin complains about it.
I'm sorry I did not record what abc.com looked like before doing disable/enable - that would have provided more clues to your programmers.

Which reminds me: I'm still awaiting something on pop-before-smtp problem (that 3 month old issue) - I'm just telling customers to use smtp-auth now.

PS: This problem appears different than the http://kb.parallels.com/en/113119 since new domains are created fine and I have two custom DNS's defined in the template, and the SELECT command mentioned there returns an empty set.

-turgut
 
Last edited:
Today I've got a message that article 115002 had been published and I want to share my opinion on this.
I've noticed that Plesk allows creating zones without NS records, for example, and passes such zone to named, on next restart you will see that named fails to start.
It seems to be a critical issue since any customer who has access to editing zones in Plesk may brake DNS on the server. Solution provided in article 115002 will not fix such issues so we need Plesk to filter bad user input instead of having administrators resolve the issue after they notice named is down.
Also, resetting zone to default is not always a good idea since it may destroy important customer records for their domain like custom MXes and A records.
 
That's almost exactly what I'm observing. Indeed, some pre-check is needed, perhaps using "named" itself, to verify that the domain zone file is correct, before committing to it.. Thanks for sharing that article. -t
 
I also found one more bad input example: customer may supply a different NS record for subdomain entry like:

domain.tld IN NS ns.someprovider.com
www.domain.tld IN NS ns.otherprovider.com

In that case named will stop working with the same error. I know it's a stupid thing but some customers do not read RFCs :)
 
tkalfaoglu, this isn't a resolution to your problem, but have you ever considered running a monitoring system such as Nagios? If you hook up a modem to a phone line, and use a TAP service like tapgateway.com, when named (or any other service you're monitoring) crashes, you will receive a text message on your cell phone letting you know there is a problem. That way, you don't need to wait until you happen to notice the problem some time later. Since TAP uses a phone line, you will even be notified if you're entire network has fallen apart.
 
Back
Top