The zone is only dumped *if it changes*. Just looking at the
modification time will not tell you if the master file is
up to date when there is a journal. The journal's modification
time is the time of the last change / refresh query and is
what is used to determine if the zone has expired while named
was not running.
The reason for this is that the master file dump is delayed
and as such does *not* reflect the last refesh query time.
The journal gets updated at refresh time if it exists
otherwise the master file's modification time gets updated.
You will see from below that isc.org has not changed in the
last 13 days. The other zones were not updated via a incremental
update so they don't have a journal.
If this bothers too many people we may also set the
modification time of the master file at refresh time when
there is a journal.
Mark
Fri Nov 12 03:21:20 EST 2004
/var/named/slave:
-rw------- 1 root wheel 455 Nov 12 02:47 192.168.191
-rw------- 1 bind wheel 580 Nov 12 02:48 2001:0470:1f00:0820
-rw------- 1 bind wheel 373 Nov 12 02:46 2001:0470:1f00:0820.int
-rw-r--r-- 1 root wheel 532 Nov 12 01:09 andrews.wattle.id.au
-rw-r--r-- 1 root wheel 14884 Nov 12 03:00 dv.isc.org
-rw-r--r-- 1 root wheel 10584 Oct 30 10:29 isc.org
-rw-r--r-- 1 root wheel 4496 Nov 12 01:32 isc.org.jnl
; <<>> DiG 8.3 <<>> soa isc.org
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36373
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
;; QUERY SECTION:
;; isc.org, type = SOA, class = IN
;; ANSWER SECTION:
isc.org. 1H IN SOA ns-int.isc.org. hostmaster.isc.org. (
2004102900 ; serial
2H ; refresh
1H ; retry
41W ; expiry
1H ) ; minimum
;; AUTHORITY SECTION:
isc.org. 1H IN NS ns-ext.isc.org.
isc.org. 1H IN NS ns-ext.lga1.isc.org.
isc.org. 1H IN NS ns-ext.nrt1.isc.org.
isc.org. 1H IN NS ns-ext.sth1.isc.org.
;; ADDITIONAL SECTION:
ns-ext.isc.org. 1H IN A 204.152.184.64
ns-ext.lga1.isc.org. 26m5s IN A 192.228.91.19
ns-ext.nrt1.isc.org. 26m5s IN A 192.228.90.19
ns-ext.sth1.isc.org. 26m5s IN A 192.228.89.19
ns-ext.isc.org. 1H IN AAAA 2001:4f8:0:2::13
;; Total query time: 0 msec
;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1
;; WHEN: Fri Nov 12 03:12:41 2004
;; MSG SIZE sent: 25 rcvd: 270
Post by SilentRageNever heard of journalprint, but I do know that BIND 9.3.0 introduced a featu
re in named-checkzone to print the zone from the journal if it exists. It's
probably my second favorite feature with rndc freeze/thaw barely making first
.
But yeah, as I said, it is NOT a problem that the zone file isn't being dumpe
d to. The zone file is not even being read anymore unless you remove that jn
l file. I suggest that you run these two commands replacing paths and zone n
named-checkzone -qD domain.tld "/var/named/domain.tld.zone"
named-checkzone -jqD domain.tld "/var/named/domain.tld.zone"
The first command prints the zone file. The second command prints the journa
l file. See if they're identical. This might not actually teach us anything
new about the problem, but it's a nice thing to look at. I can't explain wh
y the zone file isn't being dumped to 15 minutes after the last update. You
# ls -la /var/named/domain.tld.jnl
# date
Make sure the last time the journal was updated was over 15 minutes ago. I t
hink I'll go check the BIND 9.3.0 manual about this. The last time I read th
e 15 minute thing was when I had BIND 9.2.3.
Dave
Post by Stefan PuiuNot sure about BIND 9.3.0, but for 9.2.3 the ARM says the zones have
to
be dumped every 15 minutes, as you implied.
Does the zone load properly? If the rollforward of a journal file
fails
for a zone, BIND 9.2.3 won't be able to properly serve that zone (look
for zone rollforward errors in your logs). Do you usually edit your
zone
files manually? In 9.3, I think you're supposed to run 'rndc freeze'
(?)
in order to block updates for the zone you're editing, change the zone
and then do a 'rndc thaw'.
You can check the journal contents with 'journalprint' from the BIND 9
source (in bin/tests). You might want to check the SOA serials in the
journal and the one in the zone file - if the zone file serial in
bigger, you'd have problems (in BIND 9.2 at least).
Post by Bind Mailing ListWe don't receive updates rather frequently. I realy don't know why
zones are
Post by Bind Mailing Listnot updated evrey 15 minutes.
Any other ideas?
----- Original Message -----
Sent: Wednesday, November 10, 2004 4:30 PM
Subject: Re: Journal problem (jnl files)
Well, this isn't a problem. BIND reads from the jnl file if you
should
Post by Bind Mailing Listrestart it. But I do find it strange that the zone file hasn't been
updated. Perhaps it's cause you recieve updates rather frequently?
As far
Post by Bind Mailing Listas I know, BIND dumps the jnl file to text format in the zone file
after 15
Post by Bind Mailing Listminutes since the last update.
Dave
Post by Bind Mailing ListNeed help!
We use bind 9.3.0 on Solaris 8. We have some problems with the
journal
Post by Bind Mailing ListPost by Bind Mailing Listfonctionality.
Regularly we can find some old zone files in /etc/named even if the
jnl files are up to date on our server.
-rw-r--r-- 1 root sys 2365 Nov 3 15:18
domainexample.com
-rw-r--r-- 1 root sys 812 Nov 10 14:45
domainexample.com.jnl
In this example, the domain is 7 days old and the jnl is up to
date.
Post by Bind Mailing ListPost by Bind Mailing ListThe refresh time of this zones is 15 minutes.
Is-that normal?
If not, how can we fix it?
We are effraid about losing some updates.
Waiting for you answer!
Thanks a lot!
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org