The purpose of this page is to give an overview of the EnforcerNG design, design decisions, and implementation details. 

Future work on EnforcerNG

Recommendation: Further work on profiling the enforcement of zones is required!

A decision was taken to re-factor the entire database layer in March 2014. Here are some suggestions for how the re-factor could be done:

• There has been some discussion on the developer list as to why and how the re-factor should be done. It is recommended that this page is used to hold design documents as the re-factor moves forward. It would be helpful from an architectural and knowledge sharing point of view if the following documents were created:
  • the architecture of the system immediately prior to the re-factor and the
  • the proposed design for the re-factor and the reasons for it
  • the actual design after the re-factor
• It is also proposed that a review team of at least 3 developers is involved in the re-factor as it progresses. This is to reduce the risk of 
  • a single developer making design decisions in isolation
  • ending up with a component that is only well understood by a single developer, which is clearly a risk for the project
  • sufficient documentation not being produced
• It is recommended that as many regression tests as possible are enabled before the re-factor is done to provide as much automated regression testing as possible
• It is also recommended that the benchmarking tests are improved and re-run as each of the stages of the re-factor are completed to ensure that the previous levels of performance are met or exceeded. 

Enforcer NG (Q4 2013-Q1 2014)

• Status report produced in Q1 2014 by Sara Dickinson: Status_of_2.0_feb_2104.pdf
• Benchmarking report produced Q1 by Sinodun: OpenDNSSEC-performance.pdf
• Update on benchmarking report produced by Sara Dickinson: Benchmarking update.pdf  
  • Vallgrind files (summary file in zone_add directory has commands used): valgrind.zip

Enforcer NG 2011-2013

This section contains documents generated in the developmet done mostly during 2011-2103:

• Document prepared by OpenFortress analysing the 1.1 enforcer: kasp-1.1-maintainability.pdf

Theory:

• Yuri's paper on DNSSSEC key state transitions: enforcer_rules.pdf 
• Yuri's paper on "Flexible and Robust Key Rollover in DSNSSEC": satin2012-Schaeffer.pdf
• Underlying key states as described in the above paper:

Development docs:

• Mind map from early days of development: ODSEnforcerNG.pdf
• Document produced by Rene on the use of Protobuf in the original design: protobuf-20110111.pdf
• Document produced by Rene evaluating if ligsql could be used in the original design: litesql-20110111.pdf