[Opendnssec-develop] Proposal: View-based Maintenance Support

[Rick van Rein]

Hello,

A while back I proposed an approach to views [1] in OpenDNSSEC that was
appreciated.  I'd like to add a few ideas that I think would make
OpenDNSSEC much easier to handle for admins, without adding a lot of
complexity to it.  It's a set, so this is a somewhat long email.

	[1] by identifying a zone with zone name + custom view label
	    instead of just by zone name.


** Experimenting in Zone Views

The basic idea that I had, was that views might be useful to experiment
with difficult (manual) zone changes.  For instance, to practice a key
rollover procedure and see where things (could) go wrong.  Anything
outside the usual line of action is very hard with OpenDNSSEC, and
scary to do on live data.

Experimenting in a view could solve this, if a view is setup as a test
environment.  It is possible to define a test zone, but nothing beats
being able to do it with the same zone and data as is used "live".


** Views as a Rollback Option

It would be tremendously useful if there was a rollback operation for
difficult manual changes to OpenDNSSEC.  But some operations are hard
or impossible to reverse, notably the removal of keys from a zone.
(I've reversed such things in MySQL, but that is not how it should be.)

If the previous version of a zone is retained in another view, then it
should take little effort to conduct a rollback; notably, it would not
require any involvement from OpenDNSSEC, the admin can resort to simple
zone file references in his name server configuration; even if that has
a risk of temporarily going bogus, it may still be pleasant to know to
have as an emergency break.


** Operation: Forking or Splitting Zone Views

To support this more flexible style of manamgent, OpenDNSSEC should
support a "fork" operation that basically clones a zone into that
same zone with another view label.  After that, two views exist that
start off with the same key information.  I think "split" might be
a better name than "fork", to mirror the proposed "merge" below.

Technicalities that I would expect here deal with sharing key state
when it develops, or splitting the management at the time of the
view split, basically appear as if a copy of a key is made.  There
are probably use cases for both approaches, so that the user may be
forced to choose.  This may even be useful at a per-key level?


** Operations: Freezing and Defrosting a Zone View

I've proposed operations to freeze and unfreeze/defrost Enforcer
operation on individual zones, while staying active on others.  With
views added, I suppose it would be useful to perform such operations
not on an entire zone, but on individual views as well.  When
splitting views, this state would be copied along with the rest.

One useful application of this is to first freeze a zone or view,
then to split off another view, defrost and develop the public one
and keep the other frozen as a rollback option.

Another useful application could be to first freeze a zone or view,
then to split off another view, develop the _private_ view and when
it passes all tests, migrate what is public to that new view, and
then defrost the whole thing.  The previous public one could be kept
kept for some time as a rollback option, and deleted when the admin
is happy and feeling secure.


** NG Operation: Migrating between Zone Views

When views are split for management reasons, it is also useful to
have means of reuniting them.  Something that I would expect to be
possible with the self-controlling manners of Enforcer NG is to
say "I know you are now acting according to view A, but I want you
to migrate into the situation of view B".  The Enforcer NG could
then start to drop keys and introduce new ones in their place.  Its
internal logic would keep it from going bogus.

This could be useful to do complex things such as policy changes,
including those needed to stay up to pace with secure algorithm
preferences. Rather than doing this live, one could setup a test
environment, run it against whatever caches one would be interested
in, perhaps have the auditor take a stab at it, and so on.  When all
looked well, one could ask the Enforcer NG to migrate to the new
situation, and it would gracefully adopt the new policy, no matter
what had been changed in the new policy.


** Operation: Merging Zone Views

This is arguably the most difficult part.  But as shown above,
useful scenarios also exist without it.  So this could be a
future addition even if the rest was already implemented.

In both the old and new Enforcer, it would be pleasant to have
some way of merging one view into another one.    The whole
procedure would probably fall apart in these three stages:

1. Introduce RRSIGs with DNSKEYs that introduce new algorithms
2. Introduce new DNSKEYs
3. Introduce RRSIGs for the rest of the DNSKEYs

Note that it does not matter that the signer produces different
RRSIGs for different views; as long as the same keys sign for the
same data, the independently made RRSIG could even replace each
other without breaking a thing.  But they won't if views are the
basis for merging.

Also note that this adds keys, but does not remove older material;
that would be done through (manually initiated?) key rollovers.

Signing the same data may in some cases be important?  But when
merging zones, I can think of no reason why you would want to use
different data sources [2].  So a check on matching zone origins,
as would naturally arise from a zone split, would seem to be a
warranted precondition.

	[2] Although I'm still puzzled about secure zone transfers.



I hope this is useful!


Cheers,
 -Rick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 274 bytes
Desc: Digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20120529/fdb53744/attachment.bin>