[Opendnssec-develop] OpenDNSSEC Project Management

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Dickinson wrote:
> 
> 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.
> 

Initially, me too, and that we (labs) were just going to make an rrset-signer
that talks pkcs. But the earlier jabber meetings showed that there was still a
lot more to work out.

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

That's already different from the approach taken in the diagram on the wiki...


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

Actually, there is already a version of NSD that does automatic zone
(re)signing. It's the one modified by secure64. But I don't think NSD is a good
starting point. We don't need something that's optimized on fast individual
answers, we need something that is optimized to coherent changes both from
within (automatic signing) and outside (zone updates and key changes) to
individual zones.

This is even without IXFR. But if we're looking ahead; NSD is *really* not
suited for serving IXFR.

(yes i am approaching this from the nameserver point of view, not the keys pov)

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkltIeIACgkQ4nZCKsdOncUUXgCfc/tcxURLOCBPq+757miF6yDp
JMsAmwSfwuTXYMlfnNnTgVX5+GR816W+
=Z3wS
-----END PGP SIGNATURE-----