Method of writing zone files

Timothe Litt litt at acm.org
Tue Nov 13 11:37:59 UTC 2018


On 12-Nov-18 14:39, Marcus Frenkel asked about backing up slave zone
files & bind's update mechanism:

I believe you're asking the wrong questions and are likely to run into
complications.  You don't know when BIND will merge the journal, or that
rsync will atomically snapshot the zone file and the journal.  So you
will get a coherent copy of the the zone file - but it may be stale. 
The journal may be earlier or later than the zone file, or it may be
incomplete. This means that a restore  may have the slave serve stale
data - until it queries the master for any updates & if necessary, fixes
the journal file.  If the master happens to be down, this is especially
suboptimal.

So I would exclude both files from rsync, and use another approach to
save a coherent copy of the zone file(s) in my backup procedure.

One approach is to axfr the zone (from the slave, or any other server)
to your backup server.

You can do that directly with dig, or using a library (e.g. Perl's
Net::DNS).  Recent versions of BIND write slave zone files in a binary
format by default.  Just pipe the data through named-compilezone -F when
writing the file.  This has the advantage that it doesn't have to run on
the slave. (You can pull the data to your backup server, or push it from
a machine other than the slave.)

If you are dealing with very large files and/or a slow network link, you
may prefer to use named-compilezone -j to merge the zone & any journal
file into a temporary snapshot & back that up with rsync.  I'm not sure
how BIND's binary format interacts with rsync - it's possible that
outputting text format would be more efficient.  You'd have to benchmark
to decide.

If you restore from such a backup, you'll want to delete the journal
file to save named some work when it loads the zone.  And, of course,
make sure that named isn't running :-)  If you backup the zone in text
format, you can compile it only during restore to save time at the cost
of space.  (Backups should be frequent; restores rare.)

This assumes that your recovery strategy depends on being able to
restore the slave with the master down.

If you can assume that the master will be up (or restored first), by far
the simplest approach is not backup the zone data (file or journal) on
the slaves at all.  This is often the case, since restoring a master
tends to be higher priority than restoring slaves.  To restore, simply
start named.  If you are restoring over existing files, delete both zone
and journal files first.  Named will notice that it has no data, and
will do the axfr(s) & create the files in fairly short order.  Named
will spread the transfers of multiple zones out over time, but you'll
want to do some math to determine if the restore time and impact on your
network are acceptable.

Although you asked about slaves, note that masters have similar issues &
solutions.  Masters will also have journal files if they do dynamic
updates (including for DNSSEC).

For servers which are masters for some zones and slaves for others, the
strategy should be determined per-zone, not per server.

The bottom line: backups of databases (and DNS is a distributed
database) are complicated.  The best approach depends on the details of
your operational environment -- and not on the minutiae of BINDs
implementation.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

On 12-Nov-18 14:39, Marcus Frenkel wrote:
> Thank you for the quick reply Tony!
>
> Follow-up questions just to be sure:
> 1. The new zone file is renamed in the placed of the old one, only
> after all changes to the new file are written?
> 2. Is the zone file atomically replaced during the renaming process,
> in a sense that there is no window in which the file is empty or
> non-existent?
>
> I'm running BIND on Debian 9. Based on this
> <http://man7.org/linux/man-pages/man2/rename.2.html> Linux man page,
> the rename function should be atomic. I would not imagine that BIND
> does it in different way, like the worst case scenario to first remove
> the current file and then move the new one to the same path. I know
> I'm too cautious, I'm just trying to avoid any chance for rsync to
> transfer incomplete or empty zone file, or maybe delete the file at
> the destination if it does not exist at the source for a short moment.
>
> Marcus
>
> On Mon, Nov 12, 2018 at 7:19 PM Tony Finch <dot at dotat.at
> <mailto:dot at dotat.at>> wrote:
>
>     Marcus Frenkel <marcus.frenkel at gmail.com
>     <mailto:marcus.frenkel at gmail.com>> wrote:
>     >
>     > I need to know how BIND writes to slave zone files after zone
>     has been
>     > updated. Does it modify the file in place or it replaces the
>     file with
>     > new one at once?
>
>     Changes are written to a journal append-only style. Every so often the
>     master file is rewritten to incorporate the contents of the
>     journal; this
>     is done by writing to a new file and renaming it in place of the
>     old one.
>
>     Tony.
>     -- 
>     f.anthony.n.finch  <dot at dotat.at <mailto:dot at dotat.at>> 
>     http://dotat.at/
>     sovereignty rests with the people and authority
>     in a democracy derives from the people
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20181113/f09edc60/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20181113/f09edc60/attachment.bin>


More information about the bind-users mailing list