Have to Reset DNS Manually After Changes

TTT_Travis

Verified User
Joined
Mar 10, 2010
Messages
10
I manage a VPS running Debian with DirectAdmin. Everything works great except when a user (or admin/reseller) changes DNS settings or add a domain etc. it doesn't take effect until I connect to the system shell and run the commands below to kill named and start.

killall named
named


Or just restart named somehow. The server has always done this and I have just never got around to fixing it. It seems like DirectAdmin should be automatically restarting named after changes but it's not.

Any ideas would be much appreciated!
 
check permission of /etc/init.d/named and/or /etc/init.d/bind and check directadmin logs in /var/log/directadmin/error_log
 
Also make sure you wait at least one minute; that's the maximum time DA will need to execute any system routine, because they are run by cron.
 
Permissions look normal on named/bind9?

lrwxrwxrwx 1 root root 5 Dec 16 00:21 named -> bind9

-rwxr-xr-x 1 root root 1621 Jul 6 2008 bind9


I checked the error log and didn't see anything related to named/bind. How do I assume the DirectAdmin cron must be running properly because all other tasks seem to be working fine.

Would it be a bad idea to just make another cron to have named restart/reload every minute?
 
Would it be a bad idea to just make another cron to have named restart/reload every minute?
Yes it would, because it may restart while DA or you are doing (and haven't yet finished) a modification/config rewrite.

Find this in your system logs (/var/log/messages or syslog):
[...] /USR/SBIN/CRON[12345]: (root) CMD (/usr/local/directadmin/dataskq)
You should have something like that each minute. Try "grep dataskq /var/log/*" as root.
 
I used the grep command to search the logs and I does run that dataskq command every minute like it's supposed to.

Does that dataskq somehow reset named to? I assume not every minute but when changes are made maybe?
 
I suggest you change some DNS settings, then after one minute run "ls -lrt" within the zones directory ("/etc/named" or "/etc/bind" depending on your system). The last file should be the zone you modified, and if you run "cat <filename>" you can check if it has been correctly modified.
Then you can check the system logfile and you should find something like this:
Code:
[...] named[12345]: received SIGHUP signal to reload zones
Afterwards there will be some more messages about the zones it had to reload and any error it may have encoutered. If there is an error the zone will remain as it was before.
 
Ok I made some changes to my domain (Added an A record). I did ls -lrt on /etc/bind and the last file listed was the domain changed. I opened the file and it added the A record properly.

While I changed I was tail -f 'ing /var/log/syslog and /var/log/directadmin/system.log

Syslog has the following output:

Mar 11 15:24:01 server /USR/SBIN/CRON[13410]: (root) CMD (/usr/local/directadmin/dataskq)

and the directadmin system.log had the following:

2010:03:11-15:24:02: named reloaded


So it appears directadmin thinks its reloading named but it's not. I also tried stopping/restarting/reloading through the Service Monitor in Directadmin and it had no effect.

I think I also figured out the root of the problems. I have always restarted by killing named and starting instead of /etc/init.d/bind9 or named -- when I try this is what I get:


server:/# /etc/init.d/named reload
Reloading domain name service...: bindrndc: connect failed: 127.0.0.1#953: connection refused
failed!
server:/#


server:/# /etc/init.d/named restart
Stopping domain name service...: bindrndc: connect failed: 127.0.0.1#953: connection refused
failed!
Starting domain name service...: bind failed!
server:/#


server:/# /etc/init.d/named start
Starting domain name service...: bind failed!
server:/#


Seems like this is my problem, any ideas how to fix!

Thanks for putting up with me...
 
/etc/init.d/bind9 restart is the same as using named instead of bind9, named is a symbolic link to bind9

IF I do a killall named and then do a start/restart command it will work. So basically that tells me that the script isn't stopping named for some reason.
 
yes cause he dont kill he check if is online trying to connect

bindrndc: connect failed: 127.0.0.1#953: connection refused
failed!

try do bindrndc manually what u get? and when bind started try telnet localhost 953
 
FIXED IT!!

I wish I would have used my Google skillz better before.

The error turned out to be ownership of /etc/bin/rndc.key file was bind:bind instead of root:bind. I chowned the file back to root:bind, and restarted daemon and all seems well now!

Thanks for the help!
 
thanks to you for share the solution with us.

Someone gonna need those information in the future :)

No problem, always avaible to try to help
 
Sorry for re-opening an old thread - but the described problem is back...

CentOS 6.2 (64 bit) custominstall

rndc reload is not working.

Solution:

chgrp named /etc/rndc.key
chmod 0640 /etc/rndc.key
service named restart
 
Back
Top