<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Jan-Piet Mens <a class="moz-txt-link-rfc2396E" href="mailto:jpmens.dns@gmail.com"><jpmens.dns@gmail.com></a> wrote:<br>
<blockquote type="cite">
<pre wrap="">This might make you sad if you have lots of zones or large zones.
</pre>
<pre wrap="">.. or even just want to look at what was transferred (whitout having to
recurse to a `dig axfr').
I see no reason to omit 'file' (except on a diskless slave <span class="moz-smiley-s3" title=";-)"></span>
</pre>
</blockquote>
Or if you care about availability, which is a strong reason for
having a slave in the first place. (Performance is the other.)<br>
<br>
If a diskless slave restarts when the master is down, it has no data
to serve. This will also make you (or your clients) sad, even if
you only have a few small zones <span class="moz-smiley-s2"><span>
:-( </span></span><br>
<br>
I agree - don't omit 'file', except on a diskless slave. Don't try
to share the file, even when it seems to work. And think twice
about why you have a diskless slave...<br>
<br>
The only fault that I find with bind's decision to prohibit shared
writable files is that it took so long to arrive. Instead of
complaining, which seems to appear here every few months, the
response should be "Thank you - for <b>finally</b> preventing this
disastrous misconfiguration."<br>
<br>
I've lost count of how many times I've encountered someone who had
corruption due to this misconfiguration. There are many (working)
ways to replicate data. Among them: in-view, dname, external
scripts to copy files, external tools that write records to multiple
files, replicators triggered by file writes (e.g. inotify) or
database update triggers .... <br>
<br>
Although I remember when a 1MB ("hard") disk was huge - today disk
space is cheap. Don't trade a few MB (or GB) of space for eventual
data corruption. And the manpower to implement any of the above is
far less that that spent on recovering from corruption, which can go
undetected for a long time. [And usually, the folks who run into it
haven't tested their backups...]<br>
<br>
As for the "I know I'll never have bind update that zone" - that may
be true today. But it changes -- perhaps when your successor
discovers it. Either a tool requires dynamic update, or someone
discovers signed zones, or realizes that dnssec maintain saves a lot
of work, or the next technology comes along. To misappropriate a
K&R quote - "Your constant is my variable". Or the ever popular
"If you don't take the time to do it right, you'll have to make the
time to do it over...and over again".<br>
<br>
<pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
<br>
</body>
</html>