[Opendnssec-develop] interaction between the Signer and KASP
Rick van Rein
rick at openfortress.nl
Wed Jan 14 09:11:29 UTC 2009
Hello,
Thanks to John for writing down his thoughts and understanding of
the OpenDNSSEC project so far. We need people who document and get
us talking about the design, instead of only detail. This doc
certainly gets me going! Here are points of feedback on what we
currently have.
>> POLICIES
What I am missing in your document as well as in anything I've seen
so far, is some form of requirements. A quick word about importing
and exporting IXFR/AXFR is about all I've seen. Concretely, it is not
clear who put in the policies and what they are meant for. I've come
in later than others, and have hitherto assumed that I must've missed
it, but there's nothing written down on it, is there? So now that I'm
faced with an ER diagram I'm starting to wonder what all these blocks
with intuitive names and their associations mean. I think pinning
down the semantics is much more important than settling an ER diagram.
Who introduced policies, and what is s/he trying to achieve with it?
Do we need explicitly modelled policies with per-domain settings, or
are these the usual global settings that we normally put in a config
file to influence local choices at pivotal points in our code, or is
it even possible to derive them from RFCs and hardcode them into the
software? I wonder if putting in policies from the start is a true
need for a first release of OpenDNSSEC.
>> COMPONENT IDENTIFICATION
We have introduced a number of components, but once again it is not
clear to me what their exact task is. Judging from the brevity of
John's descriptions, I am not the only one who is looking for more
information. The names surely are not give-aways for their intentions
(nor would that suffice).
A way to pin down the components' functions could be:
1. Brainstorm to identify responsibilities that OpenDNSSEC should have
2. Allocate responsibilities to components
3. In case of mismatches during 2, introduce/change/remove components
4. Assign coding such responsibilities to parties involved in OpenDNSSEC
Given that responsibilities are distributed, hopefully it suffices to
draw up scenarios or use cases for all normal *and* abnormal use, and
then to define an API and start coding it.
>> OBJECT IDENTIFICATION
When concerned with objects that need to be stored, we could (and probably
should) be guided a bit more by the concepts that we are trying to capture.
A "dnsseckey" may be clear from the RFCs but it would be helpful to know
when it is created, read, updated, deleted and who does so. New objects
such as "adapters" need a lot more descriptive information to settle their
semantics like the RFCs do for "dnsseckeys".
When identifying concepts, do not overlook associations/relations between
data objects. They have cardinality, but also a meaning. A name is the
least to add as a minor hint towards the intentions of a relationship
between data objects.
This is not me being picky, but having experienced over and over again
that a database schema simply isn't sufficient documentation to get a
heterogeneous group of more than one person in line with the ideas
behind the scheme. Most of us will have peeked in a database that
someone else created without other documentation than what will be
surrendered by the database, only to find that a lot of assumptions
are called for to work on it.
>> CENTRAL/MANAGEMENT COMPONENTS
A design should be very cautious about introducing a "manager" or
"controller" block in a design. Such blocks tend to contain all
intelligence, leaving the rest as dumb data-servicing elements.
This means that the attempt to analyse the problem and come up with
smaller blocks has failed. One ends up with a molog of a block.
Think of governments and you'll see my point: Do not centralise
any responsibility if you can avoid it.
In the current design, I see a few blocks that seem to want to
coordinate: Enforcer, Signer Engine, and perhaps KASP too. If
one coordinator is a problem, then multiple are worse. I do
not think that style of design is helpful in pinning down the
responsibilities to be picked up by the parties involved in
OpenDNSSEC.
I think these problems can be avoided, but from another viewpoint
than taken by this design. For that reason, I've made another
model and description, more shaped like a dataflow, through which
DNS updates ripple from input or an internal event all the way to
the output, where they represent a signed zone. It has no unit
in central control of anything; responsibilities are split into
smaller parts and spread over components, which end up being
doable implementation efforts.
This other view on OpenDNSSEC is attached to this email, and yes,
you are *quite* welcome to publicly beat me up if it is faulty in any
way. It certainly makes choices in the realms of concurrency,
scheduling and the overall collaboration of OpenDNSSEC parts that are
new, and thus open to debate. I'd have released it after a bit more
discussion with NLNet Labs if it weren't for the conference call later
this day.
>> NO GUESSWORK
We are building a secure system, and anything that makes us guess what
another guy or gal means is a potential hole in the eventual software.
So even if I'm writing not because I'm picky but because I'm confused,
I also have reasons to be picky on the software that we build We need
to properly document our thoughts, and follow the proper tools set out
for these tasks.
I want to vent my gut feeling is that nobody knows where we are heading,
and that we should get this train back on the rails -- preferrably on
bars that run in parallel. If I'm the only one to think so, be sure to
tell me. But I'm starting to suspect I might be phrasing what others
feel as well. I hope the attached designs create so much concrete
handle bars that we can start debating about the structure of
OpenDNSSEC and distribute responsibilities sometime soon.
I sincerely hope this helps.
Warm regards,
Rick van Rein
OpenFortress Digital signatures
for SURFnet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opendnssec.pdf
Type: application/pdf
Size: 18007 bytes
Desc: dataflow diagram
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090114/b657596b/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flow-descr.pdf
Type: application/pdf
Size: 102580 bytes
Desc: descriptive document
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090114/b657596b/attachment-0001.pdf>
-------------- next part --------------
--- ./flow-descr.rst 2009/01/14 08:05:08 1.1
+++ ./flow-descr.rst 2009/01/14 08:18:06
@@ -16,7 +16,7 @@
We need a few clear concepts to guide us through the incredibly versatile
possibilities of concurrency. If not, we could easily drown and be left
-with a scheduling problem that is too broad to be effectivel implemented.
+with a scheduling problem that is too broad to be effectively implemented.
Below, the following principles are proposed as guidelines to keep the
concurrency model simple yet flexible:
@@ -27,7 +27,7 @@
* Serialisable domain updates
* State-of-the-art DNS queries
-These concepts help to avoid rece conditions, and the absense of directed
+These concepts help to avoid race conditions, and the absense of directed
cycles (that is, cycles found when following arrows in their pointing
direction) makes it possible to be sure that there will be no deadlock
either.
@@ -45,7 +45,7 @@
of a resource record, followed by new record data (or nothing if there are no
new contents). These "Diff" records are conceptually similar to an IXFR,
although it is likely that a realistic IXFR will be split into smaller
-blocks, each of which would separately be treated an RRset to be signed.
+blocks, each of which would separately be treated as an RRset to be signed.
The separation of IXFR into minimalistic "Diff" records (and differencing
an AXFR to obtain similarly small "Diff" records) is helpful in enabling
@@ -60,7 +60,7 @@
A queue is a conceptually straightforward synchronisation construct.
Its principal operation comes down to a first-in, first-out structure.
In reality though, a queue could optimise by sending out high-priority
-events before normal-priority ones. This could be used to avance
+events before normal-priority ones. This could be used to advance
emergency operations like emergency key rollover.
Queues should adhere to the principle of domain serialisability,
@@ -79,7 +79,7 @@
not be a need to actually lock anything.
Also, an implementation might do everything before Q2 in one process
-(probably using ``select()`` to be able to wait for I/O or alerts) then
+(probably using ``select()`` to wait for I/O or alerts) then
there is effectively no need to lock the writing side of Q2 at all,
let alone compete.
@@ -160,17 +160,42 @@
locked -- the latter being subject to change.
For example, if the step "re-list all RR" needs to query for all records
-in a domain, it would as Q2, who could either find a "Diff" that answers
+in a domain, it would ask Q2, who could either find a "Diff" that answers
the query, or pass it on to Q3, Q4 and so on until zoneDB. If the same
name occurs in Q2 and zoneDB, the "Diff" in Q2 prevails. If a "Diff"
exists in Q3 and Q4 covering the same DNS request, the version in Q3
is delivered back to the inquiring process.
-NSEC(3): Mathematics of ordering
+Structure: Timing and scheduling
================================
-DNS data for signing comprises of resource records as well as holes
+DNS introduces timing requirements in the form of TTL and SOA parameters.
+DNSSEC adds even more such constraints.
+
+In essence, the adjoining schema does not take all these timing requirements
+into account. Instead, the proposal is to look upon it as a generic
+problem of *realtime scheduling*.
+
+Based on this view, it ought to be possible to infer a set of queries
+that can be sent to the various blocks of the system to investigate how
+much work is still in progress, how much is lying ahead (due to timer-based
+events) and at what time each change should be triggered.
+
+I expect a generic realtime scheduler to solve this problem for us, and
+that we will only have to supply it with timing details and the proper set
+of priorities. Low priorities for user-initiated changes (IXFR from the
+master), medium for emergency rollovers and medium to high for
+time-scheduled operations.
+
+The realtime scheduler will be linked in with the processes that run, as
+well as the ordering of queues.
+
+
+Model: NSEC(3) and ordering
+===========================
+
+DNS data for signing comprises of resource records as well as *holes*
between them. The holes need explicit handling because they will
be signed just as well as resource records.
@@ -184,11 +209,11 @@
Note that this is not likely to happen at all, since NSEC3 makes
multiple passes with a single hash which is thought to be good.
-But if it ever happens, it is best to resolve it withouth domain
+But if it ever happens, it is best to resolve it without domain
downtime, especially because such changes would probably apply to
many domains at the same time.
-Efficiency of NSEC3 chain rollover is an interesting concern if it
+Efficiency of NSEC3 chain rollover is an important concern if it
is indeed the case that multiple domains will want to do the same
rollover at the same time.
@@ -204,10 +229,10 @@
records; and ``R`` defines relations between elements of ``S``. The
relation ``R`` can have a number of useful properties:
-* ``R`` is tranisitively closed if for any ``(a,b)`` and ``(b,c)`` in ``R``,
+* ``R`` is *transitively closed* if for any ``(a,b)`` and ``(b,c)`` in ``R``,
their composition ``(a,c)`` is also part of ``R``
-* ``R`` is complete if for any pair of different values ``a`` and ``b`` in
+* ``R`` is *complete* if for any pair of different values ``a`` and ``b`` in
``S``, either ``(a,b)`` or ``(b,a)`` is part of ``R``
If we use ``R`` to model the order in which NSEC or NSEC3 records are
@@ -249,15 +274,15 @@
zones, notably TLDs. This means that it is probably best to create
an order in one operation covering all records found in a domain.
Later, when records are individually removed or added as a result of
-"Diff" records, loose changes to the NSEC or NSEC3 order can be made
-by way of cutting and joining holes as described above.
+"Diff" records, small changes to the NSEC or NSEC3 order can be made
+by way of cutting-up and joining holes as described above.
-Explaining the diagram blocks
-=============================
+Description: Diagram blocks
+===========================
-Following is a description from each non-trivial block in the diagram.
+Following is a description for each block in the diagram.
DNS from master
---------------
@@ -269,21 +294,25 @@
---------
For incoming IXFR, it is good to know that the order in which data comes
-in is reliable. If not, an AXFR should be requested instead and treated
+in is correct. If not, an AXFR should be requested instead and treated
by the "diff" process.
-A sinlge IXFR may be split into multiple "Diff" records, each covering
+A single IXFR may be split into multiple "Diff" records, each covering
an RRset. This means that the "Diff" records are nice and small.
-SOA/dom
--------
+serial/dom
+----------
Stores the latest accepted SOA serial number per domain. This may come
from either IXFR or AXFR interactions with the master.
-Note that SOA and its serial numbers need not be passed on in the rest
+Note that SOA serial numbers need not be passed on in the rest
of the OpenDNSSEC flow of "Diff" events. The last stages will add a
-SOA value to match the version of the domain.
+serial number to match the version of the domain.
+
+The reason that incoming and outgoing serial numbers are not coupled
+is that, between two consecutive incoming numbers, OpenDNSSEC may have
+to insert a version for its own reasons, for reasons like a key rollover.
diff
----
@@ -313,7 +342,7 @@
KASP will trigger a Timeout for a DNSKEY under a zone, and trigger its
replacement.
-It is a matter of taste if the DNSKEY durability knowlede is located
+It is a matter of taste if the DNSKEY durability knowledge is located
in the KASP, or that the KASP is only the source of Timeouts at given
moments. Since a HSM often contains a secure timer, it makes sense
to assign the responsibility of timekeeping to the KASP.
@@ -342,6 +371,11 @@
timeouts, namely those for introduction and those for removal of DNSKEY
records.
+This process also craetes a "Diff" record for a SOA to indicate a wish
+to publish a zone's intermediate state. To get this, it simply requests
+the state-of-the-art SOA record and creates a "Diff" that both removes
+and creates that same SOA. Serial numbers are a matter of later concern.
+
KASP pubkeys
------------
@@ -358,7 +392,7 @@
create a new NSEC3 chain, a process similar to DNSKEY rollover can be
initiated. The "Diff" submitted will also proceed in two phases; first,
a new NSEC3PARAM will be added to the state-of-the-art NSEC3PARAM, and
-second, the oldest NSEC3PARAM will be removed.
+second, the older NSEC3PARAM will be removed.
NSEC3 emerg
-----------
@@ -373,6 +407,11 @@
their useful life. Note that NSEC3 and NSEC chains are created further
down the workflow.
+This process also craetes a "Diff" record for a SOA to indicate a wish
+to publish a zone's intermediate state. To get this, it simply requests
+the state-of-the-art SOA record and creates a "Diff" that both removes
+and creates that same SOA. Serial numbers are a matter of later concern.
+
AND
---
@@ -402,11 +441,20 @@
in the same atomic "Diff", reconstructs it. This is intended to trigger
the signing processes downstream.
+This process also craetes a "Diff" record for a SOA to indicate a wish
+to publish a zone's intermediate state. This may be prudent to do after
+partial updates, so that other processes can intervene and the domain
+updates are split in separate IXFR records. To get this, it requests
+the state-of-the-art SOA record and creates a "Diff" that both removes
+and creates that same SOA. Serial numbers are a matter of later concern.
+
name*order storage
------------------
This database stores the ``(S,R)`` relations of DNS names and the
-corresponding order or orders that are currently in use.
+corresponding order or orders that are currently in use. If multiple
+NSEC/NSEC3 chains are being built or used, multiple name*order relations
+are stored for a single zone.
add NSEC(3)
-----------
@@ -422,7 +470,7 @@
for "name*order". As part of the same transaction, all NSEC3 records
are supplied as "Diff" records on the process's output.
-In general, when a RRset is changed by a "Diff" on the input (and that
+In general, when an RRset is changed by a "Diff" on the input (and that
includes NSEC3PARAM) the "name*order" storage and the NSEC and/or NSEC3
records are created to match:
@@ -430,7 +478,7 @@
* If a record name is inserted, the hole in which it falls is cut in two.
-* If a new record type is added to or removed from a name that existed
+* If a new record type is added to or removed from a name that exists
beforehand and afterwards, the set of RRtypes in any NSEC3 record is
altered and a new NSEC3 record created.
@@ -453,22 +501,24 @@
contained in it. This usually includes NSEC3 records as well as plain
records.
-It is this unit that creates new SOA records for outgoing domain names.
-It has the freedom to pull in multiple "Diff" records for the same domain
-if it can find them. It is probably smart to avoid collecting too much
-in one stroke, to avoid loosing the OpenDNSSEC's responsiveness. On the
-other hand, signing every RRset (or "Diff" record) separately may be
-too fine a granularity for signing. Something practical could be found
-somewhere halfway.
+This step also creates a new SOA serial number for the newly signed
+zone. It does this whenever it comes accross a SOA record, which it
+sees as an indication that the zone should be published.
+
+The simplicity of the RRset signer mainly stems from the preparation
+by the previously added NSEC(3) records and by the separation of
+"Diff" messages into atomic RRset changes.
+
+The relative indpendency of the RRsets to be signed means that an
+optimisation for parallel signing could be setup. Note that the
+best way of doing this is probably to delegate such concurrency
+to the KASP's privkey ops, that is, the signer engine.
-Note: Combining "Diff" records for a domain could be a separate
-processing step.
-
-SOA/dom
--------
+serial/dom
+----------
This is a database similar to its same-named compadre in the input processing
-stage. It stores the SOA values added to the output records.
+stage. It stores the SOA serial values added to the output records.
zoneDB
------
@@ -476,6 +526,8 @@
This database stores the completely signed records for a zone. This
database supports a number of operations, all of which are transactional:
+* Collecting a new IXFR as a sequence of RRsets
+
* Inserting an additional "Diff" for a zone as an IXFR
* Retrieving a zone's IXFR and AXFR data
@@ -489,7 +541,7 @@
principles, possibly in combination, to achieve this effect:
* When there is more IXFR data than AXFR data for a zone, any number of
- IXFRs can be combined with the AXFR
+ the oldest IXFRs can be combined with the AXFR
* When an IXFR is past its SOA-indicated lifetime, it can be combined with
the AXFR
@@ -507,6 +559,8 @@
Scenarios
=========
-This section will show a number of scenario's or use cases rolling through
-the workflow. It will end by detailing the interactions between the
+This section shows a number of scenarios or use cases rolling through
+the workflow. It ends by detailing the interactions between the
DNS workflow module and the KASP module.
+
+**TODO**
-------------- 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/b657596b/attachment.bin>
More information about the Opendnssec-develop
mailing list