[Opendnssec-develop] OpenDNSSEC Project Management

Stephen.Morris at nominet.org.uk Stephen.Morris at nominet.org.uk
Wed Jan 14 12:11:44 UTC 2009


"Rickard Bondesson" <Rickard.Bondesson at iis.se> wrote on 14/01/2009 
10:49:12:

> Agenda
> 
> Time: 14:00 - 15:30 CET / 90 minutes
> 
> 1. Project management (10 min)
> 1a. Who will be responsible?
> 1b. What responsibilities does this person have?
> 1c. Meetings? In real life? Jabber? Telephone?
> 
> 2. Agree what the components are (System design) (35 min)
> 2a. Agree on the general system design
> 2b. Discuss any known contradictions on the wiki
> 2c. How do the components interface with each other in both the 
> prototype and final systems
> 2d. Discuss technology to be used for each component
> 2e. Do we know the requirements for each component?
> 2f. Answer the question Matthijs asked in his email (see below)
> 
> 3. Agree who is developing each component (6 min)
> 
> 4. Discussion of the commitment needed for each component and 
> available from each party. (6 min)
> 
> 5. Brief update on the state of each component where possible (10 min)
> 
> 6. Discuss and agree plan to move forward (10 min)
> 6a. Discuss timeline for whole project
> 6b. Decide on milestones for each component
> 6c. What about testing?
> 
> 7. Decide on date of next meeting (3 min)
> 
> 8. Agree actions (10 min)
> 8a. Who writes minutes
> 8b. Who is writing any documentation still needed
> 8c. Who updates the wiki based on this meeting
> 8d. Other...


For the recent conversations on the list, it seems to me that although 
there is a general agreement as to what we are going to produce in 
principle, there is some confusion as to what are are going to produce in 
detail.  I think it would be helpful if we could tackle this question 
before we get down to the system design (item 1.5?)

In software development projects I've managed, I've found the following 
two documents useful:

i) A project description: a general statement of the problem, a broad 
description of the solution, and identification of intended users.
ii) A high-level use-case document: how is the completed software used by 
different users in different situations?

I think that we should try to produce such high-level documents for this 
project, else I think we are in danger of (as we say in England) "not 
being able to see the wood for the trees".  I've had a stab at producing a 
first draft of a project description - please feel free to comment:

===
A major obstacle to the widespread adoption of DNSSEC is the complexity of 
implementing it.  There is no package that one can install on a system, 
click the "start" button, and have DNSSEC running.  Instead, there are a 
variety of tools, none of which on their own is a complete solution.  To 
actually run a DNSSEC-enabled authoritative server requires writing custom 
scripts to link them together.  Even then, aspects of DNSSEC management 
such as key management and use of hardware assistance (such as HSMs) have 
not been adequately addressed.

The aim of the OpenDNSSEC project is to produce software that will provide 
this comprehensive package.  Installed on a system it will, with a minimum 
amount of operator input:

* Handle the signing of DNS records, including the regular re-signing 
needed during normal operations.
* Handle the generation and management of keys, including key rollover.
* Seamlessly integrate with external cryptographic hardware such as HSMs.

The OpenDNSSEC software will be applicable to a wide variety of DNS 
configurations, including (but not limited to):

* Organisations (such as TLDs) that manage few zones, each with a large 
number of records.
* Organisations (such as ISPs) that manage a large number of zones, each 
with few records.
* Organisations (such as companies managing their own zones) that have a 
single zone with relatively few records.
===

Stephen



More information about the Opendnssec-develop mailing list