IXFR and lost (?) updates of a TTL
Stephane Bortzmeyer
transfer from a BIND master. The TTL on the NS records were
changed. While the master had:
$TTL 172800
wf IN SOA nsmaster.nic.fr. hostmaster.nic.fr. (
2006022800
3600
1800
3600000
5400
)
NS a.ext.nic.fr.
NS a.nic.fr.
NS b.ext.nic.fr.
NS b.nic.fr.
NS c.nic.fr.
NS d.ext.nic.fr.
NS e.ext.nic.fr.
NS e.nic.fr.
The IXFR slaves had:
$ORIGIN .
$TTL 172800 ; 2 days
wf IN SOA nsmaster.nic.fr. hostmaster.nic.fr. (
2006022800 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 minutes)
3600000 ; expire (5 weeks 6 days 16 hours)
5400 ; minimum (1 hour 30 minutes)
)
$TTL 345600 ; 4 days
NS a.ext.nic.fr.
NS a.nic.fr.
NS b.ext.nic.fr.
NS b.nic.fr.
NS c.nic.fr.
NS d.ext.nic.fr.
NS e.ext.nic.fr.
NS e.nic.fr.
[Note the spurious $TTL.]
'rndc retransfer $ZONE' fixed the problem but I wonder if it may comes
back. Can ".jnl" files get corrupted? Any tool to scrutinize them?
The slaves which used AXFR (like a nsd box) were not affected.
Stefan Puiu
> 'rndc retransfer $ZONE' fixed the problem but I wonder if it may comes
> back. Can ".jnl" files get corrupted? Any tool to scrutinize them?
For checking journal files, you could try out journalprint under
bin/tests in the BIND source. At least on my machine it seems I have
to cd to that dir and 'make journalprint' (I have an unpacked BIND
9.3.2).
At least that's what I was using on a previous project, and I found it
pretty handy. It probably won't build under Windows - we needed to
work with that, too, but I had written a simple program that would
read in the journal anyway, and we'd use that on Win32 and
journalprint on UNIX.
Stefan.
Stephane Bortzmeyer
Stefan Puiu <stefa...@gmail.com> wrote
> For checking journal files, you could try out journalprint under
> bin/tests in the BIND source. At least on my machine it seems I have
> to cd to that dir and 'make journalprint'
Great! Very handy, indeed, thanks.
Stephane Bortzmeyer
Stephane Bortzmeyer <bortz...@nic.fr> wrote
> We experienced a curious BIND bug on slave machines which use IXFR to
> transfer from a BIND master. The TTL on the NS records were
> changed. While the master had:
Well, thanks to Jean-Philippe Pick and Stefan Puiu, we can now
reproduce the bug :-)
If, on the master, you just change the TTL of a RRset, this change is
not reflected in the journal file (as displayed by journalprint) and
obviously not propagated to IXFR clients (AXFR clients - and regular
DNS clients like dig - see the new TTL).
Our master is 9.3.1.
Chris Thompson
Could this be:
1855. [bug] ixfr-from-differences was failing to detect changes
of ttl due to dns_diff_subtract() was ignoring the ttl
of records. [RT #14616]
fixed in 9.3.2? Your original post doesn't make it obvious whether you are
using ixfr-from-differences or not.
In any case, experiments with 9.3.2 seem to show that it constructs correct
IXFRs from changes of TTL (only), whether that is done via dynamic update
or via ixfr-from-differences.
--
Chris Thompson
Email: ce...@cam.ac.uk
Stephane Bortzmeyer
Chris Thompson <ce...@hermes.cam.ac.uk> wrote
a message of 36 lines which said:
> Could this be:
It certainly looks so. Thanks for the changelog-digging.
Stephane Bortzmeyer
Chris Thompson <ce...@hermes.cam.ac.uk> wrote
a message of 36 lines which said:
> 1855. [bug] ixfr-from-differences was failing to detect changes
> of ttl due to dns_diff_subtract() was ignoring the
> ttl
> of records. [RT #14616]
>
> fixed in 9.3.2?
Indeed, upgrading to 9.3.2 solved the problem (IXFR seems to trigger
interesting bugs). Thanks.
The journal file now shows "del" and subsequent "add" even if you just
change the TTLs.
Stefan Puiu
>
> The journal file now shows "del" and subsequent "add" even if you just
> change the TTLs.
IIIRc, that's what happens when you change any part of an RR - I can't
think of a way (using DDNS) to specify that a record was changed
without deleting the old one and adding the modified one. It also
happens when you change fields in the SOA - that's the most minimal
journal entry, I guess.
Stefan.
>
>
>