[Opendnssec-develop] signer 2.0 design

Matthijs Mekking matthijs at NLnetLabs.nl
Wed Jan 26 11:06:59 UTC 2011

Hash: SHA1


This is my attempt to visualize the design of the signer engine.

Best regards,


- -----------------------------------------------------------------
Input files (orange):
- - config xmlfile
- - zonelist xmlfile
- - one ore more signconf xmlfiles

Signer client (light green):
The client is the way to control the signer. The client is connected to
the daemon via a unix socket. With a list of dedicated commands, the
daemon can be started, stopped, reloaded and you can monitor and manage
the zone list, zones and task queue.

Signer daemon (also light green):
The daemon is the core of the signer. up to six different type of
threads are dedicated to do the work of the signer.

Threads (white):
- - The main thread is the engine. Starting the engine makes the signer
read and store the configuration settings and zone list. In addition, it
sets up a task schedule. Tasks are scheduled by time and each zone can
have only one task in the schedule.

- - The workers will grab tasks from the schedule and do the piece of
work. The task is a subtaks, such as reading or writing a zone, adding
NSEC(3) records, or RRSIG records. A worker picks the correct signconf
and zone files and starts working on the task. If the appointed task is
completed, the worker determines the successor task and when it needs to
be executed. It puts the successor task on the schedule and grabs a new

Note that workers do not add the RRSIG records: they delegate this hard
job to the drudgers. The worker selects the RRsets that need signatures
and puts them in a FIFO queue.

- - Drudgers are also workers, only they have to do the hard, menial
work.  The drudgers will pick up the job from the FIFO queue and provide
RRsets with the necessary signatures. It uses the HSM for that (through
libhsm). This makes it possible to have a *threaded signer*.

- - The command handler (cmdhndlr) is the so to say the help desk. It
handles the commands received from the client. Some commands require
action to be taken. For example, if a zone needs to be added, the
command handler informs the engine. The engine adjusts the zone list and
task schedule, so that the workers will follow the correct schedule.

- - The fetcher will perform zone transfers. Transfers will be requested
when the refresh timer for a zone expires, or when a notify is received.
Such a notify can come from the command handler or from the listener.

- - The listener will listen to incoming DNS packets. These can be
notifies from the master or transfer requests from a secondary. Notifies
are forwarded to the fetcher, transfer requests are handled by
transferring the latest signed zone.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ods-signer-design.pdf
Type: application/pdf
Size: 29720 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20110126/9e058cc0/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ods-signer-design.pdf.sig
Type: application/octet-stream
Size: 287 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20110126/9e058cc0/attachment.obj>

More information about the Opendnssec-develop mailing list