DNS created but doenst reply.

SeLLeRoNe

SeLLeRoNe

Super Moderator
Joined
Oct 9, 2004
Messages
6,516
Location
A Coruña, Spain
Hi,

ive facing a strange issue.

When creating a new user with a new domain the DNS deny the reply for the new created domain, but, in named.conf the include for the db and the same db file exist.

If i restart named and/or firewall nothing happend, but, if i delete just the zone from da panel and re-create the zone always from da panel, the named start working without issue.

No error in directadmin logs and neither in bind logs.

Any hint?

Thanks
 
Re-downloaded named in /etc/init.d/ and now after user creation still doenst work, but restart named solve the issue (reload too).

Debug mode output is:

Code: 
Accepting Connections on port 2222
Sockets::handshake - begin
Sockets::handshake - end
/CMD_ACCOUNT_USER
 0: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
 1: Accept-Encoding: gzip, deflate
 2: Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
 3: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 4: Connection: keep-alive
 5: Content-Length: 171
 6: Content-Type: application/x-www-form-urlencoded
 7: Cookie: session=j68Kj6go7UCMC6Zg0P817Ni4fEzIV7oCBwXt2Dh7ftRpx0VxPcxUxfYasWsLbgXm
 8: Host: orange01.crazynetwork.it:2222
 9: Referer: http://orange01.crazynetwork.it:2222/HTM_ACCOUNT_USER_CREATE
10: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Post string: action=create&username=prova&email=support%40crazynetwork.it&passwd=jJO32%2Ba9&passwd2=jJO32%2Ba9&domain=andreaandrea.it&package=Black&ip=93.63.209.93&notify=yes&add=Invia
Command::doCommand(/CMD_ACCOUNT_USER)
User::create(password, 0) user=prova
/usr/sbin/groupadd -g 750 prova
/usr/sbin/useradd -m -p '$1$4yuCcZZU$647Ad/Ae54mCYGu/hk.rj.' -s /bin/false -g prova -u 748 prova
User prova created successfully
stat(/home/prova) returned 0, just after user creation
stat info:
mode: 16832
uid:748 (prova)
gid:750 (prova)
size:4096
atime:1326911286
mtime:1326911286
ctime:1326911286
User::setQuota(0) user=prova
quota command: /usr/sbin/setquota prova 0 0 0 0 /
Quotas set
MimeTypes::readFile(): Unable to open /usr/local/directadmin/data/users/prova/domains/andreaandrea.it.mime.types for reading
MimeTypes::readFile(): Unable to open /usr/local/directadmin/data/users/prova/domains/andreaandrea.it.handlers for reading
File /var/named/andreaandrea.it.db.temp appears ok to named-checkzone
File /var/named/andreaandrea.it.db.temp appears ok to named-checkzone
Sockets::handshake - begin
Sockets::handshake - end
 
Is pretty huge:


Code: 
>cat bind.log | grep andrea
18-Jan-2012 19:21:14.485 general: info: zone andreaandrea.it/IN: loaded serial 2012011801
18-Jan-2012 19:21:14.486 notify: info: zone andreaandrea.it/IN: sending notifies (serial 2012011801)
18-Jan-2012 19:24:29.097 general: info: zone andreaandrea.it/IN: loaded serial 2012011801
18-Jan-2012 19:24:29.149 notify: info: zone andreaandrea.it/IN: sending notifies (serial 2012011801)
18-Jan-2012 19:26:51.535 general: info: zone andreaandrea.it/IN: loaded serial 2012011801
18-Jan-2012 19:26:51.565 notify: info: zone andreaandrea.it/IN: sending notifies (serial 2012011801)

During the user creation and in the +1 minute later doenst come anything in bind.log new

Where else i should check?

Regards
 
Seems that DA doenst restart/reload named, dunno why... replaced the named as suggested on help.directadmin.com but nothing happen, the curios part is that remote server (linked with multi server option) aswell have no named restart after the zone creation.

Regards
 
Maybe ive found something...

in messages ive found this line

Jan 18 19:36:32 Orange01 named[25865]: the working directory is not writable


Actually, is 3 years ago error, but should be related, what directory should be related to?

Thanks
 
Ok, no is not related, putting /var/named to 770 doenst resolve the issue, just the write permission error, but, all server have 750 and are working.. i dont get why this doesnt... like da is unable to reload/restart named but no error appear...
 
Found something new,

db file are owned by named:named in /var/named/*.db while on other server are root:root

If i put root:root on all .db files the bind debug log give permission denied on master loading...

but all server i manage use to have root:root on db files...

Any hint?

Thanks
 
Hello,

It it works from:
Admin Level -> Services Monitor

But it does not work from background dataskq calls... then could be a few things:

1) Ensure the task.queue is working:
http://help.directadmin.com/item.php?id=107

2) Note that the dataskq calls a "reload" and not a restart.
The reload requires that the PID file exist and have the correct number in it.
Check the /etc/init.d/named to see what file is being used, and the see if that file exists, check the contents, and see if name is running with that PID number. (ps ax | grep named)
The full restart likely just uses "killproc named", so the PID file doesn't matter... it just nukes all named processes.

3) If a cause cannot be found (would be best to find the cause), try changing the /etc/init.d/named script such that a reload call simply does a full restart, instead of the HUP to the pid.

John
 
Found the issue, a recent edit in /etc/cron.d/directadmin_conf

I made sleep 5; before root.. so, that cron was never running, thanks John for pointing me to right direction, issue is solved now.

I thot that named was reload by DA not using tasks queue but i didnt think abotu that just for a second. If i did, i had already solved by myself :)

Thanks everyone
 
You must log in or register to reply here.
Back
Top