Dynamic DNS and failed journal
Brian Chadwick
brianchad at westnet.com.au
Tue Aug 1 10:44:43 UTC 2006
Brian Chadwick wrote:
> Brian Chadwick wrote:
>> Brian Chadwick wrote:
>>> Tim wrote:
>>>> On Tue, 2006-08-01 at 17:35 +1000, Brian Chadwick wrote:
>>>>
>>>>> Yes I did a recursive chmod.
>>>>>
>>>>> from /var i did chmod -R named.named var
>>>>>
>>>>> i cant give you a directory listing now, i have reset the
>>>>> permissions to original
>>>>>
>>>>
>>>> Okay, bare in mind the things mentioned elsewhere in the thread about
>>>> trying another sub-directory inside var/named for your dynamic
>>>> records.
>>>> But what you've got now is probably important. The "defaults"
>>>> sometimes
>>>> end up being different on different boxes. Perhaps due to whether
>>>> users
>>>> just install BIND itself, or the local caching package?
>>>>
>>> ok .... /var/named/chroot/var/named is owned by root.named (default
>>> FC5) .... i changeed (recursively) to named.named .... same message
>>> .jnl cant be created.
>>>
>>>>
>>>>> the output from messages after a named and dhcpd restart and an
>>>>> immeadiate lease request and ddns update is below.
>>>>>
>>>>> Aug 1 17:28:51 server named[23130]: zone 'bac.org.au' allows
>>>>> updates by IP address, which is insecure
>>>>> Aug 1 17:28:51 server named[23130]: zone
>>>>> '10.168.192.in-addr.arpa' allows updates by IP address, which is
>>>>> insecure
>>>>>
>>>>
>>>> As I've commented on below, I found allowing updates by IP address
>>>> hasn't worked for some time. I don't know if it works again in FC5.
>>>>
>>> changed control clause to be updated by localhost and server (my
>>> server name) .... same message again
>>>
>>>>
>>>>> Aug 1 17:29:06 server dhcpd: No hostname for 192.168.10.190
>>>>> Aug 1 17:29:06 server dhcpd: DHCPDISCOVER from 00:0c:29:b2:ac:3e
>>>>> (box) via eth1
>>>>> Aug 1 17:29:07 server dhcpd: DHCPOFFER on 192.168.10.190 to
>>>>> 00:0c:29:b2:ac:3e via eth1
>>>>> Aug 1 17:29:07 server dhcpd: No hostname for 192.168.10.190
>>>>> Aug 1 17:29:07 server dhcpd: DHCPDISCOVER from 00:0c:29:b2:ac:3e
>>>>> via eth1
>>>>> Aug 1 17:29:07 server dhcpd: DHCPOFFER on 192.168.10.190 to
>>>>> 00:0c:29:b2:ac:3e (box) via eth1
>>>>> Aug 1 17:29:07 server named[23130]: client 192.168.10.254#32843:
>>>>> updating zone 'bac.org.au/IN': adding an RR at 'box.bac.org.au' A
>>>>> Aug 1 17:29:07 server named[23130]: client 192.168.10.254#32843:
>>>>> updating zone 'bac.org.au/IN': adding an RR at 'box.bac.org.au' TXT
>>>>> Aug 1 17:29:07 server named[23130]: journal file
>>>>> /var/named/bac.org.au.hosts.jnl does not exist, creating it
>>>>> Aug 1 17:29:07 server named[23130]:
>>>>> /var/named/bac.org.au.hosts.jnl: create: permission denied
>>>>> Aug 1 17:29:07 server named[23130]: client 192.168.10.254#32843:
>>>>> updating zone 'bac.org.au/IN': error: journal open failed:
>>>>> unexpected error
>>>>> Aug 1 17:29:07 server dhcpd: Unable to add forward map from
>>>>> box.bac.org.au to 192.168.10.190: timed out
>>>>> Aug 1 17:29:07 server dhcpd: No hostname for 192.168.10.190
>>>>> Aug 1 17:29:07 server dhcpd: DHCPREQUEST for 192.168.10.190
>>>>> (192.168.10.254) from 00:0c:29:b2:ac:3e (box) via eth1
>>>>> Aug 1 17:29:07 server dhcpd: DHCPACK on 192.168.10.190 to
>>>>> 00:0c:29:b2:ac:3e (box) via eth1
>>>>>
>>>>> As you can see ... everything seems to work ok except being able
>>>>> to write the jnl file.
>>>>>
>>>>
>>>> Not sure if the "timed out" error is the same thing, or related. I've
>>>> gone through the same myself, but resolved it too long ago. Not
>>>> sure if
>>>> the denials are file writing denials, or configuration of name server
>>>> allowances.
>>>>
>>> the timeout error is a mystery to me ... its a DSL linux box asking
>>> for a new lease (stopping NIC and restarting NIC)
>>>
>>>> If the chrooted /var/named... (/var/named/chroot/var/named...) it's
>>>> trying to access now doesn't have the right permissions, it won't be
>>>> able to write those files. What are the current permissions?
>>>>
>>> as above .... Fedora guys set /var/named/chroot/var/named owned by
>>> root ... changed it to named ownership .. no joy..same message re .jnl
>>>
>>>>
>>>>> named.conf -
>>>>> //
>>>>> // named.conf for Red Hat caching-nameserver
>>>>> //
>>>>>
>>>>> acl "bac-net" { 192.168.10.0/24; 127.0.0.1; };
>>>>>
>>>>> options {
>>>>> directory "/var/named/";
>>>>> dump-file "/var/named/data/cache_dump.db";
>>>>> statistics-file "/var/named/data/named_stats.txt";
>>>>> listen-on { "bac-net"; };
>>>>> allow-query { "bac-net"; };
>>>>>
>>>>
>>>> Hmm, never seen the listen-on and allow-query statements refer to the
>>>> ACL before. Not sure if it's allowed, but my man file says it's port
>>>> and IP data inside listen-on. It does say that the allow-query is an
>>>> address match element, though.
>>>>
>>>
>>> the listen-on clause i use is straight from the DNS macro howto on
>>> ISC website ... i thought it was odd too....but in retrospect, it
>>> means to listen on 127.0.0.1 and any other NICS using
>>> 192.168.10.0/24 netowrk that may be in the box ... naturally there
>>> is only the one NIC on that network...it seems to work. ... i didnt
>>> change this though ... the point is ... named is listening and
>>> responsding.
>>>
>>> I would have thought allow-wuery would have been ok with an acl ...
>>> its allowing every NIC on that acl.
>>>>
>>>>
>>>>> //
>>>>> // bac zone
>>>>> //
>>>>>
>>>>> zone "bac.org.au" {
>>>>> type master;
>>>>> file "/var/named/bac.org.au.hosts";
>>>>> allow-update {
>>>>> 127.0.0.1;
>>>>> 192.168.10.254;
>>>>> key rndckey;
>>>>> };
>>>>> };
>>>>>
>>>>
>>>> I found that using addresses in the allow-update statement hadn't
>>>> worked
>>>> for me since about Red Hat 8.0 Linux. I had to use an ACL name in
>>>> there, and that's all I've used. Seeing as you've set up one, acl
>>>> "bac-net", it seems rather redundant to then not use it and go about
>>>> manually specifying the addresses in all the places you could have
>>>> just
>>>> put "bac-net", if you're also including addresses.
>>>>
>>> done .... removed IP addreses ... as per your named.conf further on
>>> ....... no change in message
>>>
>>>> Not that it should make any difference, you can omit that full file
>>>> path. You've set it, above, with the directory statement.
>>>>
>>>> For subdirectories, you can just prepend the subdirectory name.
>>>>
>>>> i.e. slaves/example.com.zone
>>>>
>>>> Mine would have been done just as:
>>>>
>>>> zone "bac.org.au" {
>>>> type master;
>>>> file "bac.org.au.hosts";
>>>> allow-update { key rndckey;};
>>>> };
>>>>
>>>>
>>>>
>>> agreed ... wasteful ... changed it but didnt expect any joy ....
>>> sure enough ... no joy
>>>
>>>>> dhcpd.conf --
>>>>>
>>>>> include "/etc/rndc.key";
>>>>>
>>>>
>>>> Are you using the same /etc/rndc.key between DNS and DHCP servers?
>>>> It'll need to be. That can be a /gotcha/ in chrooted servers.
>>>>
>>>
>>> yes same key file
>>>
>>>>
>>>>> subnet 192.168.10.0 netmask 255.255.255.0 {
>>>>> ddns-domainname "bac.org.au";
>>>>> ddns-rev-domainname "in-addr.arpa.";
>>>>> authoritative;
>>>>> ddns-updates on;
>>>>>
>>>>
>>>> Not sure if the above two statements (authoritative & ddns-updates on)
>>>> had to be done outside of the subnet clauses.
>>>>
>>>
>>> a subnet specific clause ? ... one may have several subnets and only
>>> want ddns-updates from slected subnets ... i think it can be used
>>> globally or per subnet ... once again this is from the macro howto
>>> on ISC.
>>>>
>>>>> host admin {
>>>>> hardware ethernet 00:0D:61:B4:AA:85;
>>>>> fixed-address 192.168.10.1;
>>>>> }
>>>>>
>>>>
>>>> Fixed addresses won't get updated in the DNS records, you'd have to
>>>> set
>>>> them in them manually.
>>>>
>>>>
>>>
>>> I dont expect these to update .... i am testing with dhcpd assigned
>>> IP's from the pool of the subnet. These addresses are already in the
>>> zone files.
>>>
>>> so there u go .... i am not a linux expert, but also not totally
>>> inept ... i have a good working knowledge in general and I did think
>>> i could try and get this going ... but the failure to create .jnl
>>> files persist ...
>>>
>>> i am at a loss ... i cant think of anything else .... the salient
>>> point seems to be that named cant write the .jnl file ... yet the
>>> directory (now that I have changed it) belongs to it ... and still
>>> it wont write ...
>>>
>>> Just in case I am going to check out the SElinux stuff ... i am
>>> fairly certain that SElinux is disabled, but I need to make
>>> absolutely certain ... there seems to be few other clues ... stay tuned
>>
>> SElinux is in ENFORCING mode .... i bet the issue is in there ....
>> LOL .... dont know its set up that way but it is .... he comes some
>> reading
>>
>>>
>>> Brian
>>>
>>
>
>
> SUCCESS !!!!! It was SElinux stopping named from writing master zones
> .... the command "setsebool named_write_master_zones true" did the
> trick.....
>
> I will reverse things to determine whether there was ONLY SELinux, or
> both SElinux and named effects.
>
> Thanks for your interest, especially u Tim.
>
> Cheers
>
For anyone interested ... the BIND mailing list archives have this
answer .... Its all to do with SElinux, which, (doh!) i thought was
disabled .... Tim was bang on .. sorry to send you (tim especially) on a
wild goose chase
here is the Q and A
*Q:*
I'm running BIND on Red Hat Enterprise Linux or Fedora Core -
Why can't named update slave zone database files?
Why can't named create DDNS journal files or update the master zones
from journals?
Why can't named create custom log files?
*A:*
Red Hat Security Enhanced Linux (SELinux) policy security protections :
Red Hat have adopted the National Security Agency's SELinux security
policy ( see http://www.nsa.gov/selinux ) and recommendations for BIND
security , which are more secure than running named in a chroot and make
use of the bind-chroot environment unecessary .
By default, named is not allowed by the SELinux policy to write, create
or delete any files EXCEPT in these directories:
$ROOTDIR/var/named/slaves
$ROOTDIR/var/named/data
$ROOTDIR/var/tmp
where $ROOTDIR may be set in /etc/sysconfig/named if bind-chroot is
installed.
The SELinux policy particularly does NOT allow named to modify the
$ROOTDIR/var/named directory, the default location for master zone
database files.
SELinux policy overrules file access permissions - so even if all the
files under /var/named have ownership named:named and mode rw-rw-r--,
named will still not be able to write or create files except in the
directories above, with SELinux in Enforcing mode.
So, to allow named to update slave or DDNS zone files, it is best to
locate them in $ROOTDIR/var/named/slaves, with named.conf zone
statements such as:
zone "slave.zone." IN {
type slave;
file "slaves/slave.zone.db";
...
};
zone "ddns.zone." IN {
type master;
allow-updates {...};
file "slaves/ddns.zone.db";
};
To allow named to create its cache dump and statistics files, for
example, you could use named.conf options statements such as:
options {
...
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
...
};
You can also tell SELinux to allow named to update any zone database
files, by setting the SELinux tunable boolean parameter
'named_write_master_zones=1', using the system-config-securitylevel GUI,
using the 'setsebool' command, or in /etc/selinux/targeted/booleans.
You can disable SELinux protection for named entirely by setting the
'named_disable_trans=1' SELinux tunable boolean parameter.
The SELinux named policy defines these SELinux contexts for named:
named_zone_t : for zone database files - $ROOTDIR/var/named/*
named_conf_t : for named configuration files - $ROOTDIR/etc/{named,rndc}.*
named_cache_t: for files modifiable by named - $ROOTDIR/var/{tmp,named/{slaves,data}}
If you want to retain use of the SELinux policy for named, and put named
files in different locations, you can do so by changing the context of
the custom file locations .
To create a custom configuration file location, eg. '/root/named.conf',
to use with the 'named -c' option, do:
# chcon system_u:object_r:named_conf_t /root/named.conf
To create a custom modifiable named data location, eg. '/var/log/named'
for a log file, do:
# chcon system_u:object_r:named_cache_t /var/log/named
To create a custom zone file location, eg. /root/zones/, do:
# chcon system_u:object_r:named_zone_t /root/zones/{.,*}
More information about the fedora-list
mailing list