named-xfer using 'generic' source after 'transfer-source' failed

[Paul A Vixie]

> That for the drawbacks, but what are/were the benefits motivating the
> second attempt and is there any chance to make this feature disappear or
> become optional in 8.2.3-final?

when f.root-servers.net grew into a cluster, using cisco CEF, only one of
the hosts could initiate tcp from 192.5.5.241 at a time even though both
of them could answer udp transactions all day long.  so they each try first
to fetch zones from the real masters (a.root-servers.net, for example) and
then each tries to fetch from the "other F".  due to CEF hashing, one of
them always succeeds at fetching from the real master server, and the other
always fails.  the one who succeeds does the "also-notify" thing to the one
that failed, and the one that failed tries its fallback address (since it
just won't work to fetch using 192.5.5.241's address if the "other F" has
that as one of its lo0 aliases.)

in other words this was put in for clustering.  and, we failed to respect
"transfer-source" on the SOA query, so we're currently burning more named-xfer
slots than we need to since the SOA query "almost always fails" if in fact
transfer-source is going to be necessary in order to fetch the zone.  let's
fix THAT and then see how your slot occupancy goes.

making it optional is certainly an, um, option.  but i'd rather avoid that
if there are other ways to solve the problem you're actually having.