[Opendnssec-develop] interaction between the Signer and KASP

Rick van Rein rick at openfortress.nl
Wed Jan 14 10:42:08 UTC 2009


Olaf,

> Skimming your documents I understand that you focus on the atomic  
> coherency of possibly small sets of data (a couple of RRsets). The  
> immediate question that I have is how you take care of zone coherency.

The small (RRset size) changes that propagate through the dataflow end
at the zoneDB -- at that place, I imagine collecting all RRsets under
a zone until they are followed by a SOA.  Then all up to then, including
the SOA, is stored as an IXFR or AXFR into the zoneDB.

This means that there is a transaction for each domain being signed,
maintained upon entry in the zoneDB.  Or in other words, data is
being collected in a pre-publishing file and later moved into the
publication area if zoneDB is implemented in files.

> From a metalevel it is the operation on a zone that needs to be  
> 'atomic'. I would need to be explained how you maintain that view  
> within your design.

1a. Stuff comes in as an IXFR or AXFR, or
1b. Stuff is created in response to internal needs

2. Stuff is passed on as RRset-sized "Diff" messages, each atomic,
   with a SOA "Diff" closing a zone's changes

3. Stuff gets processed per RRset: NSEC(3) appended, SOA serial number
   inserted, RRSet signing

4. Stuff gets collected and only published when the trailing SOA drips in

So the SOA record mirrors what "commit" does in a database.  A new SOA
record is needed on any change, as its serial number must be updated.
And you'll never need more than one such change per zone update.  So
it can serve as the "end of transaction" marker.


Hope this helps,

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


More information about the Opendnssec-develop mailing list