[Opendnssec-develop] OpenDNSSEC Project Management

[John Dickinson]

On 13 Jan 2009, at 14:40, Roy Arends wrote:

> OpenDNSSECers,
>
> When I took the lead to manage this project, I had the assumption that
> most of the architecture design was done, and what needed to follow  
> was a
> simple implementation of the parts. My view was that this would be  
> done in
> two phases. The first phase was a simple proof of concept, with mostly
> existing tools. The second phase is a production version.

That's what I understood as well.

> The proof of concept is simply a nameserver running as slave for the
> incoming unsigned zone, and as a master for the outgoing signed  
> zone. The
> magic that causes the flip from unsigned to signed would be a regular
> running script that consults a database for the proper crypto-related
> data.
>
> I stand corrected.
>
> The necessity for IXFR, and the complexity that comes with it,  
> renders the
> proof of concept completely useless for the production version. This
> became clear during the discussions at NLNetLabs last month.
>
> To be clear: I still want the proof of concept (PoC) version, albeit
> without IXFR.

Sorry, I don't understand now what the PoC is going to be. Something  
like what is on the wiki or a "...nameserver running as slave for the  
incoming unsigned zone, and as a master for the outgoing signed zone."?

I know the nameserver version is something that we want, but I never  
realized that was what we were building as a PoC. In my mind the PoC  
was more for investigating how the bits would hang together, what data  
KASP would contain and what algorithms are needed for manipulating the  
KASP data and turning that in to signing operations.

The nameserver version would evolve from that and reuse the technology  
and ideas developed by building the PoC.

Regarding the nameserver version - I did a bit of thinking about that  
last year and came to the conclusion that it would be better to start  
with a nameserver and add signing than to start with a signer and add  
most of a nameserver to it. I came up with the following vague idea  
(the may be mis-understandings about how NSD works so feel free to put  
me right):

NSD already has the ability to fork a process to perform XFR. This  
process uses IPC to signal to the parent that new zone data needs  
reloading. How about adding a signer process to NSD and re-directing  
the IPC so that it goes to the signer and once any signatures are  
added a signal is sent to parent to trigger the reload. NSD also has  
the necessary timers needed to trigger refreshes of the zone.  
presumably these could be used to trigger re-signings and key rollover  
as well. This signer process might well use KASP in order to figure  
out what to do and when. Thus it would evolve from the PoC of  
OpenDNSSEC.

Are you or Stephen going to be calling into the meeting tomorrow?
John