Dynamic DNS and failed journal
Brian Chadwick
brianchad at westnet.com.au
Tue Aug 1 10:16:17 UTC 2006
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
More information about the fedora-list
mailing list