(no subject)

[Kevin Darcy]

Mikael Forsberg wrote:

> Hi,
>
> I'm running 8.2.2p5 on NT and have tested dynamic updates,
> which generated a couple of questions.
>
> The file db.example.se.ixfr is created together with the file
> db.example.se.log, which contains the updates, when an update is made.
>
> Named updates the db.example.se file with the new data after
> a while and deletes the db.example.log file, but leaves the
> db.example.se.ixfr file as is.
>
> A dynamic delete of the created data adds the delete operation to
> the db.example.se.ixfr file which now contains both an add and a
> delete of the same record.
>
> I've tested with a single master configuration and with a slave,
> but the IXFR file is still not removed.
>
> 1) How is the IXFR file used with incremental zone transfers?

When a zone is Dynamic Update enabled, it is assumed that all changes are
done via Dynamic Update. Therefore, there is synergy to be gained by
recording those changes and then sending them as IXFR's to slaves, assuming
that the type of change can be expressed in IXFR semantics (a new RRset is
no problem -- just transmit the new data. And I think a modification of an
existing RRset is probably also trivial -- just send the changed RRset. But
not being terribly familiar with the internals of IXFR, I don't know whether
the deletion of a whole RRset can be expressed in IXFR, in which case
AXFR would be mandatory). That way, the slaves get all of the updates
without incurring all of the overhead associated with AXFR.

I don't know that there is any graceful way to disable the
creation/maintenance of IXFR logs for Dynamic Update-enabled zones. But, as
a kludge, I suppose one could always set the filename to that of a data sink
(/dev/null on Unix) or to a file to which named has no write permission...

> 2) Should it be removed automatically?

Yes, it should, unless the changes to the zone are so frequent that named
never gets a chance to run a full maintenance cycle between updates.
According to the code, a delta (marked with "[END DELTA]") in the IXFR log
should be removed when the zone file is dumped. If the resulting IXFR log is
then empty, it is removed.

> 3) I got the following error when Named updated the db.example.se
>    with the db.example.se.log data.
>
>    08-Sep-2000 17:00:34.000 default: warning: can not rename
>    db.example.se.ixfr.a00229 to db.example.se.ixfr :File exists

On Unix, rename() only fails with EEXIST if the new name is a non-empty
directory. Assuming this is *not* the case on your box, this looks like it
might be a difference in rename() semantics between Unix and NT.
Unfortunately, when the rename() fails, named implements no recovery
mechanism (e.g. unlink()'ing the destination file, then retrying the
rename()), so the changed file with the removed delta(s) never actually gets
renamed (the temp file just gets deleted). And the .ixfr file keeps growing.
So it looks to me like it might be a bug in the NT port of BIND. But I'm
sticking my neck out here, since I don't know much about NT internals. For
all I know, it could be something as banal as a permissions problem.

> 4) I assume it is safe to delete the IXFR file, as it is created when
>    a dynamic update is done and not when the zone files are edited
>    manually. I don't want to have a file that grows forever...

I don't know anything about NT's file-writing semantics, but on Unix, at
least, it would not be safe to make manual changes to zonefiles or .ixfr
files while the nameserver is running; you might get intermingled writes and
corrupted files. Also, on Unix, if you deleted an open file from the
filesystem, any data written to that file would be effectively lost. Even if
NT implements some sort of mutual-exclusion for file writes and/or deletes,
you could lose your manual changes to a zonefile if the "named" later
overwrites them with a manual "dump" from the change log. Also, if you
manually change a .ixfr file, I think it would be best to only delete up
through the last "[END DELTA]" line; this would more accurately mimic what
named itself does.


- Kevin