[Opendnssec-develop] Role of the Auditor

Roy Arends roy at nominet.org.uk
Fri Aug 28 13:04:49 UTC 2009


Stephen Morris wrote on 08/28/2009 02:46:11 PM:

> Stephen.Morris at nominet.org.uk 
> Sent by: opendnssec-develop-bounces at lists.opendnssec.org
> 
> 08/28/2009 02:46 PM
> 
> To
> 
> opendnssec-develop at lists.opendnssec.org
> 
> cc
> 
> Subject
> 
> [Opendnssec-develop] Role of the Auditor
> 
> Following up from our discussion about the auditor yesterday, this 
> is a description of what I think it should be doing: 
> 
> a. The auditor is an quality check in the OpenDNSSEC signing process
> to ensure that incorrect or out of date signed data is not 
> inadvertently loaded into production nameservers.  It is run by the 
> signer engine once the zone file has been signed and checks the 
> signed file against the unsigned file (and against the policy) to 
> ensure that the signer has done its work correctly.   If the auditor
> does not detect a problem, the signed zone file can be loaded.  To 
> ensure that the process is a proper quality check, the auditor has 
> been coded by a different programmer to that of the signer and in a 
> different language.  However, both the signer and the auditor have a
> dependency on the OpenSSL library. 

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).

> The auditor is an optional component of OpenDNSSEC and the 
> configuration file can specify that it not be run.  If the auditor 
> _is_ configured to run, the signer writes its output to an auditor 
> directory and the auditor, on successful completion of the audit, 
> moves it to the "signed" directory.  If the auditor _is not_ 
> configured to run, the signer writes its output directly to the 
> "signed" directory. 

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?
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.

> Notes: 
> i) The writing of the output file by the signer should be a two-
> stage process - write to a temporary file then rename.  Such a 
> scheme ensure that a valid signed file is not replaced by an 
> incomplete one should the signer fail. 
> ii) Can we agree to rename "signer engine" to something like the 
> "scheduler"?  As it is responsible for initiating the auditor, I 
> think the name is more accurate and will lead to less confusion. 

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.

> b. The monitor is a daemon that runs on a system that can see the 
> public nameservers for the zone and does consistency checks on the 
> data retrieved from them.  As such, it shares much of the code of 
> the auditor and has been referred to as the "auditor daemon" (a name
> I think we should no longer use). Its primary purpose is to check 
> signature lifetimes to see if any are approaching their expiration 
> date - if some are, it could indicate that either the signer is not 
> running or that the distribution of zone data to the secondaries has
> been interrupted.  It should also do other consistency checks (e.g. 
> checking that the KSK has a DS record in the parent zone), which may
> include extensive checking of zone data should it have a copy of the
> input zone file or list of names in the zone. 

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. 

However, I'd really welcome such code.

Roy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090828/a40b3d98/attachment.htm>


More information about the Opendnssec-develop mailing list