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