<tt><font size=2>Stephen Morris wrote on 08/28/2009 02:46:11 PM:<br>
<br>
> Stephen.Morris@nominet.org.uk </font></tt>
<br><tt><font size=2>> Sent by: opendnssec-develop-bounces@lists.opendnssec.org<br>
> </font></tt>
<br><tt><font size=2>> 08/28/2009 02:46 PM</font></tt>
<br><tt><font size=2>> <br>
> To</font></tt>
<br><tt><font size=2>> <br>
> opendnssec-develop@lists.opendnssec.org</font></tt>
<br><tt><font size=2>> <br>
> cc</font></tt>
<br><tt><font size=2>> <br>
> Subject</font></tt>
<br><tt><font size=2>> <br>
> [Opendnssec-develop] Role of the Auditor</font></tt>
<br><tt><font size=2>> <br>
> Following up from our discussion about the auditor yesterday, this
<br>
> is a description of what I think it should be doing: <br>
> <br>
> a. The auditor is an quality check in the OpenDNSSEC signing process<br>
> to ensure that incorrect or out of date signed data is not <br>
> inadvertently loaded into production nameservers.  It is run
by the <br>
> signer engine once the zone file has been signed and checks the <br>
> signed file against the unsigned file (and against the policy) to
<br>
> ensure that the signer has done its work correctly.   If the
auditor<br>
> does not detect a problem, the signed zone file can be loaded.  To
<br>
> ensure that the process is a proper quality check, the auditor has
<br>
> been coded by a different programmer to that of the signer and in
a <br>
> different language.  However, both the signer and the auditor
have a<br>
> dependency on the OpenSSL library. </font></tt>
<br>
<br><tt><font size=2>I assume that the signer depends on a (soft)HSM which
have its own dependency (on Botan in the case of softHSM). So there should
not be a mutual dependency on cryptolibs. As for the language, I still
do not see the language difference as an asset, but more a complexity.
(I understand the reason _why_ there are different languages used here,
but code diversity wasn't one).</font></tt>
<br>
<br><tt><font size=2>> The auditor is an optional component of OpenDNSSEC
and the <br>
> configuration file can specify that it not be run.  If the auditor
<br>
> _is_ configured to run, the signer writes its output to an auditor
<br>
> directory and the auditor, on successful completion of the audit,
<br>
> moves it to the "signed" directory.  If the auditor
_is not_ <br>
> configured to run, the signer writes its output directly to the <br>
> "signed" directory. </font></tt>
<br>
<br><tt><font size=2>Would it be an option to state in the signed file,
commented out and in the top of the file, if the file was audited?</font></tt>
<br><tt><font size=2>In general, more state can be dumped as comments into
the signed/audited file. During development of the NSEC3 testbed, this
turned out to be extremely useful.</font></tt>
<br>
<br><tt><font size=2>> Notes: <br>
> i) The writing of the output file by the signer should be a two-<br>
> stage process - write to a temporary file then rename.  Such
a <br>
> scheme ensure that a valid signed file is not replaced by an <br>
> incomplete one should the signer fail. <br>
> ii) Can we agree to rename "signer engine" to something
like the <br>
> "scheduler"?  As it is responsible for initiating the
auditor, I <br>
> think the name is more accurate and will lead to less confusion. </font></tt>
<br>
<br><tt><font size=2>I think we should submit all the daemons to a naming
policy. Communicated/keygend/signer_engine all could use a od_ prefix,
like Rick mentioned in his mail.</font></tt>
<br><tt><font size=2><br>
> b. The monitor is a daemon that runs on a system that can see the
<br>
> public nameservers for the zone and does consistency checks on the
<br>
> data retrieved from them.  As such, it shares much of the code
of <br>
> the auditor and has been referred to as the "auditor daemon"
(a name<br>
> I think we should no longer use). Its primary purpose is to check
<br>
> signature lifetimes to see if any are approaching their expiration
<br>
> date - if some are, it could indicate that either the signer is not
<br>
> running or that the distribution of zone data to the secondaries has<br>
> been interrupted.  It should also do other consistency checks
(e.g. <br>
> checking that the KSK has a DS record in the parent zone), which may<br>
> include extensive checking of zone data should it have a copy of the<br>
> input zone file or list of names in the zone. </font></tt>
<br>
<br><tt><font size=2>It is likely that secure deployment requires that
the system with the attached hsm, and thus the signing engine, is severely
limited, on even completely prohibited, in communication with anything
that can be found on the public internet, including all the secondaries.
Also, it would make sense to have the monitor completely separated from
OpenDNSSEC systems and part of the generic health monitoring system of
all systems. </font></tt>
<br>
<br><tt><font size=2>However, I'd really welcome such code.</font></tt>
<br>
<br><tt><font size=2>Roy</font></tt>