[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