[Opendnssec-develop] Re: Our little get-together. Re: Progressing OpenDNSSEC.
roy at nominet.org.uk
Sat Nov 15 23:22:49 UTC 2008
Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 11/15/2008 04:51:51 PM:
> >> - During the meeting I referred to the 'vapor ware' that we call
> >> Masterdont. The core of this idea is that we have a kernel that is
> >> aware of all possible interactions with, properties off, and
> >> relations
> >> of the environments with zone.
> >> In that context I think it is important to make the zone I/O
> >> intelligence and the KASP language extendible so that KASP is to
> >> become a subset of a zone-policy language that not only describes the
> >> signing and key properties of zones but can also describe TTL,
> >> Nameserver, and content properties for zones.
> > KASP was specifically designed with DNSSEC in mind, and deals with the
> > various timings, state and properties of keys. I think what you are
> > referring to is the ability to contain KASP in NSCP. I think that
> > generic
> > configuration items should go into NSCP, and that various state
> > properties
> > of keys should remain in KASP.
> That is not exactly what I refer to.
> A zone can have many properties, such as the policy it is signed with,
> which keys are used to implement that policy, which nameservers it is
> served on, which clients are allowed to query it, its SOA timing
> prarameters, etc, etc. Some of these properties are expressed in the
> language that KASP will use for its configuration, others will be used
> in NSCP.
> If you are starting on a framework to maintain a subset of properties
> for zones, which I think KASP is, then you better make sure you can
> add the other pieces too. Make it extendable: while not solving all of
> ones problems at once make sure you can in the future build upon the
> foundations you are setting.
Okay. Lets go over this face to face next week. I think we're in
agreement, though we might not be convinced ;-)
> >> I have asked Matthijs to set up requirements for this (based on KASP
> >> and NSCP) and come up with an architecuture of what I refer to as the
> >> "Masterdont kernel". Although work on phase 1 of the project is to
> >> large extend orthogonal to this idea there are a few hooks,
> >> specifically
> >> - Colleagues from SURFNET are interested in working along and even
> >> providing resources in the form of a programmer. I am not sure if
> >> there is need for adding resources to phase 1 of the project (and if
> >> we do if there is efficiency gain). But I think they should be privy
> >> to the requirements document.
> > I think that we have covered most (all) bases with the current team. I
> > have no problem adding development resources if there is a yet
> > unidentified part of this project. However, I'm not convinced we more
> > resources. However, since SURFNET host a large amount of zones, I
> > can see
> > value in inviting them to test the software.
> I think that might be rather late. Why not use them as a sounding
> board for assessing if your current set of requirements and your
> vision would work for them?
That is a good idea. Could you elaborate on who is your point of contact
More information about the Opendnssec-develop