slave zone files unreadable

[Evan Hunt]

On Fri, Jul 11, 2014 at 12:12:22PM -0400, John Wobus wrote:
> In cases analogous to this, software often saves both
> text and binary, and when initializing, uses mtime to
> decide whether it can safely use the binary.  Some resources
> are spent storing the extra file and admins have yet
> another way to screw things up, but the strategy
> does have benefits.

You can't always rely on mtime for that.  The disk may have been hit by
cosmic rays since last time you read the file, and mtime hasn't changed but
the file is different anyway.

If named had been designed from the beginning with the supposition that it
might, at any time, discover that its database was corrupt, and simply
stopped serving that particular zone until corrective measures had been
taken, then that would be okay.  But named is designed to verify its
data thoroughly at load time, and then throw an assertion failure if
anything looks wrong later.  The assumption that the database is reliable,
and if it isn't we should crash, runs all through the code; it would be a
huge job of work to change it.

So with map files, we load the database image with mmap(), then walk down
through the tree and verify the checksums.  That means the whole database
gets paged into physical memory at load time, and that's why map files
don't load instantly.  Still 3-4 times faster than raw, though.

(The idea of keeping both text and map versions of master files around,
though -- loading the zone from the map, or else loading from text and
creating a new map, depending on mtime -- is definitely under consideration
and may turn up in 9.11 if time permits.)

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.