Handling of zone transfers and notify messages

[Robert E.Seastrom]

Måns Nilsson <mansaxel at sunet.se> writes:

> It is probably a side effect of the same issue that hit me with one of my
> NSD boxen, where the inability of zonec (and perhaps nsd) to grok AFSDB
> records led to all updates being suspended. The fix was, of course, more
> straightforward; simply support AFSBD. Until that was in, I had to leave
> out that zone from my nsd.zones file, which was crude yet necessary to be
> able to continue serving the other zones.

Yep, precisely so.  I recall having a record type in there a couple of
years ago that wasn't supported which caused me identical results.

> However, I (like Robert) feel a need for more graceful handling of partial
> master b0rkenness from the slave perspective; if a zone can't be compiled
> (for whatever reason) deal with it and continue to build the database,
> including the working zones and signal (some way) that there are things
> missing.

It would sure be nice to be able to make the zone info compilation
almost-completely-un-chatty too - where the only output is in the form
of errors.  My disclaimer about "maybe this has already been done"
still applies...  have you ever tried to eyeball-scan the output from
a couple of thousand zones to find the ONE ZONE that is hosing your
update?

> I'm not certain about the "no AA bit" vs "no zone at all" choice.
> "No zone at all" looks cleaner on the outside, but one might benefit
> (albeit in a dirty, tainted way) from non-AA answers from a server you'd
> expect to hand out trusty AA's. 

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.  Likewise, if the zone is expired but it
was able to at least load data that it got previously, BIND will
continue to serve the data without the AA bit set (and disallow AXFR).

Note that my current hack makes the server go lame instead of
non-authoritative.  Having all one's secondary servers go lame because
of a problem with the primary server is a problem I'd rather not have
- not in the least because people are doofuses and put too-short
expiry times in their SOAs because they don't know the difference
between expire and min ttl.

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.  :)

(or compromise by having the behavior modify itself based on the value
least significant bit of the rightmost number in the version
identifier, heh heh heh)

> -- 
> Måns Nilsson         Systems Specialist
> +46 70 681 7204         KTHNOC
>                         MN1334-RIPE

                                        ---Rob