[bind10-dev] addZone interface for the new loadzone and zone management framework

[JINMEI Tatuya / 神明達哉]

At Thu, 06 Dec 2012 23:52:09 -0800,
JINMEI Tatuya <jinmei at isc.org> wrote:

> Focusing on the short term plan of what to do for this sprint and the
> beta release (as I don't think we can have sufficient time to discuss
> the larger design issues): I've been thinking about it for a while,
> and would like to propose basically keeping the addZone() interface I
> proposed, ignoring the atomicity issue for now.  In fact, if I
> read the code correctly, BIND 9's "rndc addzone" has the same issue,
> and, unless the administrator tries to add a fully new zone while
> keeping BIND 10 already running, this is not an issue in practice.
> 
> So I'd like to defer other issues to later discussions.  Whichever
> initial approach we take, it's pretty likely to be subject to future
> changes anyway.

A bit more explanation: I guess there can actually be a situation
where a zone exists but its contents (RRs) don't.  For example, if a
secondary server (which is already referenced from the parent zone) is
being setup but zone transfer from the primary server somehow hasn't
succeeded (due to temporary failure of the primary, network problems,
etc).  In this case, the secondary server should recognize it's
managing the zone without the contents and should return SERVFAIL to
queries for the zone rather than a response indicating it's not really
authoritative for that zone (in our implementation, it would be
REFUSED).

So I think it makes some sense to be able to manage the
existence/non-existence of zones independently from loading RRs for
the zones.

Of course, there are other cases where we'd rather hide the existence
of a zone until it's ready with its full contents.  Configuring a
primary server before registering it at the parent zone would be one
such case.  This can be done with a different way than making
everything in a single transaction.  For example, we can take 2-phase
commit approach with an additional state of a zone: we first set up a
zone (without loading RRs) with the state of "not ready".  As long as
the zone is in that state it will be invisible in terms of query
handling.  We can then load RRs to the zone, and change the state to
"ready".  A zone can also be in the "ready" state without having the
RRs; that would be the case for the secondary server scenario above.

Implementation-wise, returning an updater from something else (like
an "addZone()" method) will require non trivial redesign of the APIs
because the updater is currently designed to have its own
transaction.  If we want to make addZone+update(i.e. loading) an
atomic operation, we'll need to revisit this level of design for the
updater.  Depending on the result of the larger discussion we may
conclude that's the way to go, but that will be a bigger task than
something doable in the middle of a single sprint.

Extending the updater and/or ZoneLoader by adding the "add_zone"
parameter is another possibility, but personally I'd first like to
clarify the relationship between managing zones and loading their
contents ("the bigger discussion") before enlarging the responsibility
of existing classes.  For a short term it may look a convenient way to
achieve what we want because we only need to add a new method or
extending an existing method with an additional parameter to make
everything happen automagically, but we'll eventually have to pay the
cost of making classes more monolithic in terms of maintainability,
extendibility, or testability.

---
JINMEI, Tatuya