Handling of zone transfers and notify messages

[Arnt Gulbrandsen]

Robert E.Seastrom writes:
> Well, not to hold up BIND as a paragon of the Right Thing (cough), but 
> if you have a typo in the zone file that confuses the parser, BIND 
> will continue to serve up whatever data it was able to figure out, 
> albiet non-authoritatively.

In a sense, BIND indirectly defines the right thing: One can say that a 
program behaves correctly if it does what the user expects, and in the 
case of NSD, a lot of user expectations have been shaped by BIND.

> I'd rather have the server continue serving the data and go 
> non-authoritative. I can see where reasonable people may disagree. 
> Perhaps a good way of addressing the problem is to make it 
> compile-time tuneable, and then we can have an arm-wrestling match 
> for what the default behavior should be in the distribution. :)

How about matching BIND in such odd cases unless there's a good reason 
to, and then spending effort on a good way to alert the operator in 
case of errors instead of on an arm-wrestling match? After all, the 
_right_ way to deal with this situation is to make it go away quickly.

Seriously, how about this? nsdc logs errors as per usual, and also 
writes a status file. The same file is written every time, and its 
content doesn't change unless there's an error.

It could look like this two-liner:

Zones: nnnn (prinary nnnn, secondary nnnn).
Zones with errors: <names>

On freebsd, it's really easy to keep looking at such a file. There's a 
system which will mail it to the administrator every time the file 
changes.

Arnt