I just applied the BIND updates.
Then I fixed the one file that had a second include of named.ca (remembered that from last time) and did a 'service named restart', and it failed. In messages I found:
Jan 10 21:31:17 z9m9z named[31001]: loading configuration from '/etc/named.conf' Jan 10 21:31:17 z9m9z named[31001]: /etc/named.conf:11: open: /etc/named.acl: permission denied Jan 10 21:31:17 z9m9z named[31001]: loading configuration: permission denied Jan 10 21:31:17 z9m9z named[31001]: exiting (due to fatal error)
Oh, I remember this from the last update... So off to /var/named/chroot/etc and do a 'chown named:named *' then named started.
This apparent changing of file ownership in installing a new set of bind updates so that named cannot access the files seems like something is broken somewhere.
Robert Moskowitz wrote:
I just applied the BIND updates.
Then I fixed the one file that had a second include of named.ca (remembered that from last time) and did a 'service named restart', and it failed.
Never heard about someone having to apply that fix - do you have a bug entry from bugs.centos.org or bugzilla.redhat.com handy?
In messages I found:
Jan 10 21:31:17 z9m9z named[31001]: loading configuration from '/etc/named.conf' Jan 10 21:31:17 z9m9z named[31001]: /etc/named.conf:11: open: /etc/named.acl: permission denied Jan 10 21:31:17 z9m9z named[31001]: loading configuration: permission denied Jan 10 21:31:17 z9m9z named[31001]: exiting (due to fatal error)
named.acl isn't shipped by CentOS.
Oh, I remember this from the last update... So off to /var/named/chroot/etc and do a 'chown named:named *' then named started.
The files under there belong to root:named and are 644 (except rndc.conf which is 640). No file there belongs to named:named. named.acl isn't shipped with bind.
This apparent changing of file ownership in installing a new set of bind updates so that named cannot access the files seems like something is broken somewhere.
[root@shutdown etc]# rpm -q --scripts bind|grep -E "chown|chmod" [ -e /etc/rndc.key ] && chown root:named /etc/rndc.key [ -e /etc/rndc.key ] && chmod 0640 /etc/rndc.key [root@shutdown etc]#
So where are other files ownerships changed after a bind update? If you think you fond a bug, then please file it, but make sure that others can recreate it.
Ralph
Ralph Angenendt wrote on Sun, 11 Jan 2009 11:10:54 +0100:
The files under there belong to root:named and are 644 (except rndc.conf which is 640). No file there belongs to named:named. named.acl isn't shipped with bind.
I had named.conf with root.root (and it was working). That got changed by the update to root.named. Which apparently is the correct ownership according to you and it still works. When I installed bind just a few weeks ago I had to create all the files manually as there were none. So, that's why that file was root.root.
I didn't notice that before but I see that there are a lot of errors already before the update:
Jan 11 16:38:00 chacha named[11307]: client 192.168.1.228#1994: view internal: update 'bolera.lan/IN' denied
I don't need updates (and I think clients are not configured to try to update). Can you tell me how I can fix this? (If I wanted to allow updates and if I wanted to have this functionality not available at all.)
Kai
Kai Schaetzl wrote:
I had named.conf with root.root (and it was working). That got changed by the update to root.named. Which apparently is the correct ownership according to you and it still works. When I installed bind just a few weeks ago I had to create all the files manually as there were none. So, that's why that file was root.root.
I didn't notice that before but I see that there are a lot of errors already before the update:
Jan 11 16:38:00 chacha named[11307]: client 192.168.1.228#1994: view internal: update 'bolera.lan/IN' denied
I don't need updates (and I think clients are not configured to try to update). Can you tell me how I can fix this? (If I wanted to allow updates and if I wanted to have this functionality not available at all.)
You are not making any sense at all. Are you asking a question? If so I missed it.
Regards, Vandaman.
Kai Schaetzl wrote:
I didn't notice that before but I see that there are a lot of errors already before the update:
Jan 11 16:38:00 chacha named[11307]: client 192.168.1.228#1994: view internal: update 'bolera.lan/IN' denied
You have a windows machine on the network and it gets its address by dhcp? If so it now tries to tell the name server that it has a new fancy shiny address!
Ralph
Ralph Angenendt wrote on Sun, 11 Jan 2009 18:59:37 +0100:
You have a windows machine on the network and it gets its address by dhcp?
Yeah, I knew that ;-)
If so it now tries to tell the name server that it has a new fancy shiny address!
I thought I had configured the client not to do this. But looking now I don't see such an option. On the other hand, I can't see an option in named.conf that would allow that. Isn't there a way to tell named to just ignore/not accept these updates? From the error messages it looks like it accepts them, but they fail afterwards either because of missing permissions to the file or rndc or so. Or is there an dhcp option that would tell the client to stop this? I have "ignore client-updates;" but that obviously is an option for dhcpd only.
Kai
On Mon, 2009-01-12 at 14:19 +0100, Kai Schaetzl wrote:
Ralph Angenendt wrote on Sun, 11 Jan 2009 18:59:37 +0100:
You have a windows machine on the network and it gets its address by dhcp?
Yeah, I knew that ;-)
If so it now tries to tell the name server that it has a new fancy shiny address!
I thought I had configured the client not to do this. But looking now I don't see such an option. On the other hand, I can't see an option in named.conf that would allow that. Isn't there a way to tell named to just ignore/not accept these updates? From the error messages it looks like it accepts them, but they fail afterwards either because of missing permissions to the file or rndc or so. Or is there an dhcp option that would tell the client to stop this? I have "ignore client-updates;" but that obviously is an option for dhcpd only.
---- by default, BIND will ignore attempts by clients to register dynamic dns after getting an ip address from dhcp - that is what is being logged.
You would have to 'allow-update' within a specific zone definition to change default behavior.
FWIW - I think that DHCP/BIND and having clients update DNS makes a lot of sense for an office intranet but hey, that's just me.
Craig
Craig White wrote:
by default, BIND will ignore attempts by clients to register dynamic dns after getting an ip address from dhcp - that is what is being logged.
You would have to 'allow-update' within a specific zone definition to change default behavior.
FWIW - I think that DHCP/BIND and having clients update DNS makes a lot of sense for an office intranet but hey, that's just me.
I thought when this was first implemented it was possible for client updates to override static assignments, so if someone named their windows box 'mail' it would become mail.yourdomain in DNS even if it wasn't supposed to be. If that was true, is it fixed now?
On Mon, 2009-01-12 at 10:05 -0600, Les Mikesell wrote:
Craig White wrote:
by default, BIND will ignore attempts by clients to register dynamic dns after getting an ip address from dhcp - that is what is being logged.
You would have to 'allow-update' within a specific zone definition to change default behavior.
FWIW - I think that DHCP/BIND and having clients update DNS makes a lot of sense for an office intranet but hey, that's just me.
I thought when this was first implemented it was possible for client updates to override static assignments, so if someone named their windows box 'mail' it would become mail.yourdomain in DNS even if it wasn't supposed to be. If that was true, is it fixed now?
---- don't know for sure...possibly could happen. The static entries have the same format as dynamic entries and probably the only difference is their TTL.
It wouldn't be too hard to figure out if that happened though.
Craig
On Mon, 2009-01-12 at 09:35 -0700, Craig White wrote:
On Mon, 2009-01-12 at 10:05 -0600, Les Mikesell wrote:
Craig White wrote:
by default, BIND will ignore attempts by clients to register dynamic dns after getting an ip address from dhcp - that is what is being logged.
You would have to 'allow-update' within a specific zone definition to change default behavior.
FWIW - I think that DHCP/BIND and having clients update DNS makes a lot of sense for an office intranet but hey, that's just me.
I thought when this was first implemented it was possible for client updates to override static assignments, so if someone named their windows box 'mail' it would become mail.yourdomain in DNS even if it wasn't supposed to be. If that was true, is it fixed now?
don't know for sure...possibly could happen. The static entries have the same format as dynamic entries and probably the only difference is their TTL.
It wouldn't be too hard to figure out if that happened though.
---- I should also add that you could create a dynamic zone to prevent this from happening.
Craig
Craig White wrote on Mon, 12 Jan 2009 07:45:22 -0700:
by default, BIND will ignore attempts by clients to register dynamic dns after getting an ip address from dhcp - that is what is being logged.
so, the Jan 11 16:38:00 chacha named[11307]: client 192.168.1.228#1994: view internal: update 'bolera.lan/IN' denied
is just normal logging that I can't avoid?
You would have to 'allow-update' within a specific zone definition to change default behavior.
good.
FWIW - I think that DHCP/BIND and having clients update DNS makes a lot of sense for an office intranet but hey, that's just me.
not in my case. Most clients do get fixed addresses and hostnames applied from dhcp, anyway.
Kai
Ralph Angenendt wrote:
Robert Moskowitz wrote:
I just applied the BIND updates.
Then I fixed the one file that had a second include of named.ca (remembered that from last time) and did a 'service named restart', and it failed.
Never heard about someone having to apply that fix - do you have a bug entry from bugs.centos.org or bugzilla.redhat.com handy?
In messages I found:
Jan 10 21:31:17 z9m9z named[31001]: loading configuration from '/etc/named.conf' Jan 10 21:31:17 z9m9z named[31001]: /etc/named.conf:11: open: /etc/named.acl: permission denied Jan 10 21:31:17 z9m9z named[31001]: loading configuration: permission denied Jan 10 21:31:17 z9m9z named[31001]: exiting (due to fatal error)
named.acl isn't shipped by CentOS.
Oh course it is not. But if you are doing an internal view, you want (need?) an .acl.
Oh, I remember this from the last update... So off to /var/named/chroot/etc and do a 'chown named:named *' then named started.
The files under there belong to root:named and are 644 (except rndc.conf which is 640). No file there belongs to named:named. named.acl isn't shipped with bind.
And therein hangs my snafu. named.acl only had 600 for permissions so when the group was changed to root by the update, the named process could no longer access the file even with the owner being named. Go figure. So I just need to fix my permissions to 644 and I will be OK for the next update....
This apparent changing of file ownership in installing a new set of bind updates so that named cannot access the files seems like something is broken somewhere.
[root@shutdown etc]# rpm -q --scripts bind|grep -E "chown|chmod" [ -e /etc/rndc.key ] && chown root:named /etc/rndc.key [ -e /etc/rndc.key ] && chmod 0640 /etc/rndc.key [root@shutdown etc]#
So where are other files ownerships changed after a bind update? If you think you fond a bug, then please file it, but make sure that others can recreate it.
Robert Moskowitz wrote:
And therein hangs my snafu. named.acl only had 600 for permissions so when the group was changed to root by the update, the named process could no longer access the file even with the owner being named. Go figure. So I just need to fix my permissions to 644 and I will be OK for the next update....
As said (and see below): No script in one of the bind packages changes ownership and/or modes on any of the files in there.
| [angenenr@shutdown ~]$for rpm in $(rpm -qa bind*); do rpm -q --scripts $rpm| \ | grep -E "chown|chmod"; done | [ -e /etc/rndc.key ] && chown root:named /etc/rndc.key | [ -e /etc/rndc.key ] && chmod 0640 /etc/rndc.key | [angenenr@shutdown ~]$
And as *none* of the bind packages claims ownership for any of the files you have there, I don't understand why you are seeing this error:
| [angenenr@shutdown ~]$for rpm in $(rpm -qa bind*); do rpm -ql $rpm | \ | grep etc/; done | /etc/dbus-1/system.d/named.conf | /etc/logrotate.d/named | /etc/rc.d/init.d/named | /etc/sysconfig/named | /usr/share/doc/bind-9.3.4/sample/etc/named.conf | /usr/share/doc/bind-9.3.4/sample/etc/named.rfc1912.zones | /usr/share/doc/bind-9.3.4/sample/etc/named.root.hints | /usr/share/doc/bind-9.3.4/sample/etc/rndc.conf | [angenenr@shutdown ~]$
As said: If you can tell me/us how to recreate this problem, please file a bug.
But I cannot see how this possibly is a problem with the bind update.
Ralph
Ralph Angenendt wrote:
Robert Moskowitz wrote:
And therein hangs my snafu. named.acl only had 600 for permissions so when the group was changed to root by the update, the named process could no longer access the file even with the owner being named. Go figure. So I just need to fix my permissions to 644 and I will be OK for the next update....
As said (and see below): No script in one of the bind packages changes ownership and/or modes on any of the files in there.
Okay, as has been pointed out: /usr/sbin/bind-chroot-admin does all this. You could report that as a bug upstream, but I doubt it will get fixed. My fault, I didn't see that.
Cheers,
Ralph
Ralph Angenendt wrote:
Ralph Angenendt wrote:
Robert Moskowitz wrote:
And therein hangs my snafu. named.acl only had 600 for permissions so when the group was changed to root by the update, the named process could no longer access the file even with the owner being named. Go figure. So I just need to fix my permissions to 644 and I will be OK for the next update....
As said (and see below): No script in one of the bind packages changes ownership and/or modes on any of the files in there.
Okay, as has been pointed out: /usr/sbin/bind-chroot-admin does all this. You could report that as a bug upstream, but I doubt it will get fixed. My fault, I didn't see that.
I figure the best is to learn what it is doing and make sure you have permissions and the like so that most of the time an update does not kill you....
On Saturday 10 January 2009 9:37:43 pm Robert Moskowitz wrote:
I just applied the BIND updates.
Then I fixed the one file that had a second include of named.ca (remembered that from last time) and did a 'service named restart', and it failed. In messages I found:
Jan 10 21:31:17 z9m9z named[31001]: loading configuration from '/etc/named.conf' Jan 10 21:31:17 z9m9z named[31001]: /etc/named.conf:11: open: /etc/named.acl: permission denied Jan 10 21:31:17 z9m9z named[31001]: loading configuration: permission denied Jan 10 21:31:17 z9m9z named[31001]: exiting (due to fatal error)
Oh, I remember this from the last update... So off to /var/named/chroot/etc and do a 'chown named:named *' then named started.
This apparent changing of file ownership in installing a new set of bind updates so that named cannot access the files seems like something is broken somewhere.
Hi!
This is really strange, I run two different servers with Centos 5.2 and the bind provided by centos, and after aplying the latest bind updates, the service restarted with no issues at all, so it seems the updates are not broken for everybody.
Cordialmente,
GERMAN ANDRES PULIDO F. Ingeniero de Proyectos GLOBAL TECHNOLOGY SERVICES - GTS S.A. ------------------------------------- Tel: (571) 658 34 10 ext 110 Carrera 7b No. 123-46 Bogotá-Colombia Sitio Web: www.gtscolombia.com
Robert Moskowitz wrote: ...
Oh, I remember this from the last update... So off to /var/named/chroot/etc and do a 'chown named:named *' then named started.
I see the same problem every time bind is updated.
My /var/named/chroot/var/named files are writable by named because I have a DDNS setup. After every bind update, the files are no longer writable by named.
Mogens
Mogens Kjaer wrote:
Robert Moskowitz wrote: ...
Oh, I remember this from the last update... So off to /var/named/chroot/etc and do a 'chown named:named *' then named started.
I see the same problem every time bind is updated.
My /var/named/chroot/var/named files are writable by named because I have a DDNS setup. After every bind update, the files are no longer writable by named.
Which really is strange, as only rndc.key gets "chowned" by the scripts in the bind package.
Not even the caching-nameserver package changes the owner. And none of the config files are owned by any of the bind packages.
Ralph
Ralph Angenendt wrote: ...
Which really is strange, as only rndc.key gets "chowned" by the scripts in the bind package.
Maybe it's because I have bind-chroot installed?
The script calls:
/usr/sbin/bind-chroot-admin --enable > /dev/null 2>&1;
as part of postinstall, and /usr/sbin/bind-chroot-admin contains a lot of chown/chmod stuff.
Mogens
On Mon, 2009-01-12 at 15:16 +0100, Mogens Kjaer wrote:
Ralph Angenendt wrote: ...
Which really is strange, as only rndc.key gets "chowned" by the scripts in the bind package.
Maybe it's because I have bind-chroot installed?
The script calls:
/usr/sbin/bind-chroot-admin --enable > /dev/null 2>&1;
as part of postinstall, and /usr/sbin/bind-chroot-admin contains a lot of chown/chmod stuff.
---- I have seen that myself...
On the bind master zones, I now put them in /var/named/chroot/var/named/dynamic, chown the directory to named:named, chmod g+w (the 'dynamic' directory) and seem to be good.
I also now use the following to restart bind (because of journal files)...
rndc freeze && rndc flush && service named restart && rndc unfreeze
YMMV
Craig
Mogens Kjaer wrote:
Ralph Angenendt wrote: ...
Which really is strange, as only rndc.key gets "chowned" by the scripts in the bind package.
Maybe it's because I have bind-chroot installed?
The script calls:
/usr/sbin/bind-chroot-admin --enable > /dev/null 2>&1;
as part of postinstall, and /usr/sbin/bind-chroot-admin contains a lot of chown/chmod stuff.
Ugh. Haven't seen that. That's ugly. Breaking bind via updates seems to become a habit. In my opinion this would qualify for an upstream bug report, but I doubt that this will get "fixed".
Cheers,
Ralph
-
Craig White -
German Andres Pulido -
Kai Schaetzl -
Les Mikesell -
Mogens Kjaer -
Ralph Angenendt -
Robert Moskowitz -
Vandaman