Craig White wrote:

On Sun, 2007-08-05 at 18:07 -0400, Ray Leventhal wrote:

...

Hi folks,

I've put my new DNS server in place, told the primary that this IP would be pulling zones and restarted BIND on the primary.

<snip>

So the new BIND sees the conf file and recognizes that there are 169 zones (test group) to pull.

nothing comes over. I tailed the /var/log/messages and I see about 169 <g> of these:

Aug 5 14:10:08 sunspot named[5263]: dumping master file: /var/named/chroot/var/named/slaves/tmp-sTsIWElBLR: open: file not found

and these

Aug 5 14:10:08 sunspot named[5263]: transfer of 'jemsites.com/IN' from 64.135.16.10#53: failed while receiving responses: file not found

I think this must be a permissions issue. (btw, SELinux is in Permissive mode at the moment).

TIA for any comments or suggestions.

---

chgrp -R named /var/named/chroot/var/named chmod -R g+w /var/named/chroot/var/named

Craig

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Thanks, Craig. That sure made sense to do, but seemingly not the crux of the issue.

~Ray

Les Mikesell wrote:

Ray Leventhal wrote:

...

...

...

Aug 5 14:10:08 sunspot named[5263]: dumping master file: /var/named/chroot/var/named/slaves/tmp-sTsIWElBLR: open: file not found

Thanks, Craig. That sure made sense to do, but seemingly not the crux of the issue.

If named is running chroot, shouldn't the files be named from its perspective after the chroot - i.e. /var/named/slaves/* instead of /var/named/chroot/var/named/slaves/* like you see them? What does your "directory" entry say in named.conf?

[root@sunspot etc]# pwd /var/named/chroot/etc [root@sunspot etc]# more named.conf | grep swhi zone "swhi.net" { type slave; file "/var/named/chroot/var/named/slaves/db.swhi.net"; masters { 64.135.16.10; };}; zone "swhi.us" { type slave; file "/var/named/chroot/var/named/slaves/db.swhi.us"; masters { 64.135.16.10; };}; zone "swhi.ws" { type slave; file "/var/named/chroot/var/named/slaves/db.swhi.ws"; masters { 64.135.16.10; };}; [root@sunspot etc]#

Am I understanding that the zone transfer requests should read "/var/named/slaves/db.<domain>.net> {xxx.xxx.xxx.xxx;};};

Thanks, Lee...I appreciate your help

~Ray

Les Mikesell wrote:

centos@swhi.net wrote:

...

Les Mikesell wrote:

...

Ray Leventhal wrote:

...

...

...

Aug 5 14:10:08 sunspot named[5263]: dumping master file: /var/named/chroot/var/named/slaves/tmp-sTsIWElBLR: open: file not found

Thanks, Craig. That sure made sense to do, but seemingly not the crux of the issue.

If named is running chroot, shouldn't the files be named from its perspective after the chroot - i.e. /var/named/slaves/* instead of /var/named/chroot/var/named/slaves/* like you see them? What does your "directory" entry say in named.conf?

[root@sunspot etc]# pwd /var/named/chroot/etc [root@sunspot etc]# more named.conf | grep swhi zone "swhi.net" { type slave; file "/var/named/chroot/var/named/slaves/db.swhi.net"; masters { 64.135.16.10; };}; zone "swhi.us" { type slave; file "/var/named/chroot/var/named/slaves/db.swhi.us"; masters { 64.135.16.10; };}; zone "swhi.ws" { type slave; file "/var/named/chroot/var/named/slaves/db.swhi.ws"; masters { 64.135.16.10; };}; [root@sunspot etc]#

Am I understanding that the zone transfer requests should read "/var/named/slaves/db.<domain>.net> {xxx.xxx.xxx.xxx;};};

Thanks, Lee...I appreciate your help

Yes, the filename can be relative to the directory mentioned in the options section or absolute, but either way it has to take the chroot location into account, so omit the /var/named/chroot part.

That was absolutely the trick.

Thank you again, Lee

Stephen John Smoogen wrote:

<snip> > +++++++++++++++++++++++ > > So the new BIND sees the conf file and recognizes that there are 169 > zones (test group) to pull. > > nothing comes over. I tailed the /var/log/messages and I see about 169 > <g> of these: > > Aug 5 14:10:08 sunspot named[5263]: dumping master file: > /var/named/chroot/var/named/slaves/tmp-sTsIWElBLR: open: file not found > >

Can you transfer a file over from the server correctly or is the server denying it to the slaves. what does 'dig @<server-ip-address> <name-of-zone> axfr' give you on the slave server? Remember to change out the name-of-zone etc with real data fro your server.

Hi Stephen,

dig @64.135.16.15 swhi.net axfr

; <<>> DiG 9.3.3rc2 <<>> @64.135.16.15 swhi.net axfr ; (1 server found) ;; global options: printcmd ; Transfer failed. [root@sunspot etc]#

that's against the new dns server's IP. dig@ my other nameserver shows full output, as expected.

I'm guessing I need to be looking at the primary.

Thank you :) ~R