From jakob at kirei.se  Mon Jun  3 07:07:52 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 3 Jun 2013 09:07:52 +0200
Subject: [Opendnssec-develop] SoftHSMv2 in Fisheye
Message-ID: <37FEA117-9528-4A58-B268-07F4D0235BFE@kirei.se>

SoftHSMv2 is now available for browsing through the Fisheye; http://fisheye.opendnssec.org/browse/SoftHSMv2

	jakob



From sara at sinodun.com  Thu Jun  6 13:23:34 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 6 Jun 2013 14:23:34 +0100
Subject: [Opendnssec-develop] RE: Restart of JIRA application planned for
	16:00 CET today - Thu 6 Jun 2013
Message-ID: <434C7C4E-6E04-4064-9908-1FC39E99AA20@sinodun.com>

Hi All, 

The SURFNet support folks are planning to restart the JIRA application at 16:00 today to try to fix a problem. Please avoid using the server around this time and make sure to save any work ahead of the restart. If this is going to cause a problem for anyone then please let me know asap.

Regards

Sara.

From sara at sinodun.com  Mon Jun 10 10:59:28 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 10 Jun 2013 11:59:28 +0100
Subject: [Opendnssec-develop] RE: Greenhopper - Agile plugin for JIRA
Message-ID: <FAD5785D-6B0B-4652-AB5D-6852D9EE983E@sinodun.com>

Hi All, 

I spent a bit of time last week playing with and configuring the agile plugin to JIRA which is called Greenhopper. I've been using it on another project I manage as a planning tool and I'm really liking it. If you look at JIRA you will now see an 'Agile' drop down along the top with a couple of boards set up. I've been using it specifically to plan the 2.0 release by using sprints to group issues together e.g. 

https://issues.opendnssec.org/secure/RapidBoard.jspa?rapidView=8&view=planning&selectedIssue=OPENDNSSEC-407&versions=visible&epics=hidden&selectedVersion=10729

I'd like us to consider switching to using it to do our issue reviews and planning. I'm not suggesting we move to a time-boxed agile workflow, as that simply wouldn't fit with the project, rather that we just use the agile view (instead of the classic view) and possibly use 'sprints' to track the progress of our (content based) releases. 

There are some subtleties to using it so I was planning to do a walk through in the team meeting on Thursday so if you get chance please take a tour ahead of that or if you have any thoughts/questions on this then do let me know. 

Sara.

From matthijs at nlnetlabs.nl  Mon Jun 10 12:53:39 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Mon, 10 Jun 2013 14:53:39 +0200
Subject: [Opendnssec-develop] broken links in jenkins
Message-ID: <51B5CC53.2050906@nlnetlabs.nl>

Hi!,

It seems that there are a lot of broken links in Jenkins. For example on
this page:

https://jenkins.opendnssec.org/computer/netbsd64-ods09/

A lot of links in the name column are 404s.



From jad at sinodun.com  Mon Jun 10 14:28:48 2013
From: jad at sinodun.com (John Dickinson)
Date: Mon, 10 Jun 2013 14:28:48 +0000
Subject: [Opendnssec-develop] broken links in jenkins
In-Reply-To: <51B5CC53.2050906@nlnetlabs.nl>
References: <51B5CC53.2050906@nlnetlabs.nl>
Message-ID: <77BF8EE6-B6D7-4E91-A369-C16161B4BD1C@sinodun.com>

It appears to be a wider problem than just netbsd64-ods09 - I am investigating...


On 10 Jun 2013, at 12:53, Matthijs Mekking <matthijs at NLnetLabs.nl> wrote:

> Hi!,
> 
> It seems that there are a lot of broken links in Jenkins. For example on
> this page:
> 
> https://jenkins.opendnssec.org/computer/netbsd64-ods09/
> 
> A lot of links in the name column are 404s.
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From jad at sinodun.com  Mon Jun 10 16:10:40 2013
From: jad at sinodun.com (John Dickinson)
Date: Mon, 10 Jun 2013 16:10:40 +0000
Subject: [Opendnssec-develop] broken links in jenkins
In-Reply-To: <51B5CC53.2050906@nlnetlabs.nl>
References: <51B5CC53.2050906@nlnetlabs.nl>
Message-ID: <F1E5EEA3-3B01-4208-A216-8F5D58F9FEFF@sinodun.com>

I have also updated all plugins (except the ssh slaves - requires changes to credential handling).

freebsd64-ods06 is out of disk space - Jerry could you free some up?

Thanks
John

On 10 Jun 2013, at 12:53, Matthijs Mekking <matthijs at NLnetLabs.nl> wrote:

> Hi!,
> 
> It seems that there are a lot of broken links in Jenkins. For example on
> this page:
> 
> https://jenkins.opendnssec.org/computer/netbsd64-ods09/
> 
> A lot of links in the name column are 404s.
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From sara at sinodun.com  Tue Jun 11 10:21:49 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 11 Jun 2013 11:21:49 +0100
Subject: [Opendnssec-develop] RE: User survey on upcoming features
Message-ID: <C2BD4D4D-C277-418C-B294-A19CAED4CB18@sinodun.com>

Hi All, 

Following all the discussions at RIPE on 'what users really want' after 2.0 I was planning to set up a user survey so users could vote on what features would be most useful to them. The point would be to help us understand the users' perspective better and prioritise _the order_ we do these developments in. 

I've put a list together, based on the current roadmap and specific user requests I'm aware of:

Interface/Usability
--------------------------
Enhancements to DS handling (e.g. hook for notification of DS generation, OPENDNSSEC-295, ds-seen --all option)
Improvements to existing API (e.g. more consistent, better output, OPENDNSSEC-404)
New, unified control API
Alternative text based front end to update configuration options (currently stored in XML)
Alternative graphical front end to update configuration options (currently stored in XML)
Improved Monitoring (e.g. email notifications of events, daily email summary, 'ods summary' command)

Key handling
-----------------------
Support multiple key rollover methods
Support policy rollover
Support algorithm rollover
Allow KSK and ZSK to be the same key
Offline KSK

Signer
---------
Dynamic update adapter
Database adapter
Plugin adapter
Incremental transition from/to NSEC to/from NSEC3
Reduced Memory usage

Other
---------
Support for GOST/DSA
Support for Postgres DB backend 
Support for Views (OPENDNSSEC-232)


I plan to ask users to rate each feature as
- Blocking/problematic in our use of OpenDNSSEC
- Really want this feature right now please
- Would use if available
- Not important to us
and ask for anything not on the list that they really want. 

Did I miss anything? Comments?

Sara.

From sara at sinodun.com  Tue Jun 11 10:23:44 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 11 Jun 2013 11:23:44 +0100
Subject: [Opendnssec-develop] RE: Summary of training sessions
Message-ID: <B3852312-6E7C-4E79-A4FF-FEEE11894A88@sinodun.com>

Hi Patrik/Jakob, 

One comment made at RIPE was that the developers would like to be more aware of what happens in the training sessions as we don't tend to hear about them normally. Do you think it would be possible to write a few lines after each session letting us know what kind of people attended (particularly if a new organisation is using it), which version was used and any feedback on what they found easy/useful/cool/confusing? It would be really nice to have more visibility of this side of things :-)

Thanks

Sara.

From jad at sinodun.com  Tue Jun 11 12:20:03 2013
From: jad at sinodun.com (John Dickinson)
Date: Tue, 11 Jun 2013 12:20:03 +0000
Subject: Fwd: [Opendnssec-develop] broken links in jenkins
References: <CCAAA3CB-C616-414A-80E3-81BF278D41A2@sinodun.com>
Message-ID: <2A47E13D-5314-46B6-A421-2DA668924FCA@sinodun.com>

Sorry, forgot to cc the list

Begin forwarded message:

> From: John Dickinson <jad at sinodun.com>
> Subject: Re: [Opendnssec-develop] broken links in jenkins
> Date: 10 June 2013 15:49:25 +0000
> To: Matthijs Mekking <matthijs at nlnetlabs.nl>
> 
> Hi
> 
> reverting back to jenkins 1.516 did not help.
> 
> It is giving the wrong URLs! Clicking on the list at your URL tries to take you to
> 
> https://jenkins.opendnssec.org/job/build-botan-softhsm2-trunk-bota./label=centos32-ods13/
> 
> It should read
> 
> https://jenkins.opendnssec.org/job/build-botan-softhsm2-trunk-botan/label=centos32-ods13/
> 
> If you navigate via the jobs on the dashboard it works fine?
> 
> John
> 
> 
> On 10 Jun 2013, at 14:34, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:
> 
>> On 06/10/2013 04:28 PM, John Dickinson wrote:
>>> It appears to be a wider problem than just netbsd64-ods09 - I am investigating...
>> 
>> Yes, it was just an example. Thanks for looking into this.
>> 
>>> 
>>> 
>>> On 10 Jun 2013, at 12:53, Matthijs Mekking <matthijs at NLnetLabs.nl> wrote:
>>> 
>>>> Hi!,
>>>> 
>>>> It seems that there are a lot of broken links in Jenkins. For example on
>>>> this page:
>>>> 
>>>> https://jenkins.opendnssec.org/computer/netbsd64-ods09/
>>>> 
>>>> A lot of links in the name column are 404s.
>>>> 
>>>> _______________________________________________
>>>> Opendnssec-develop mailing list
>>>> Opendnssec-develop at lists.opendnssec.org
>>>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>>> 
>>> _______________________________________________
>>> Opendnssec-develop mailing list
>>> Opendnssec-develop at lists.opendnssec.org
>>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>>> 
>> 
> 



From matthijs at nlnetlabs.nl  Tue Jun 11 12:20:57 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Tue, 11 Jun 2013 14:20:57 +0200
Subject: [Opendnssec-develop] RE: User survey on upcoming features
In-Reply-To: <C2BD4D4D-C277-418C-B294-A19CAED4CB18@sinodun.com>
References: <C2BD4D4D-C277-418C-B294-A19CAED4CB18@sinodun.com>
Message-ID: <51B71629.9090104@nlnetlabs.nl>

Hi Sara,

Some comments, based on people I have spoke on the CENTR last week

On 06/11/2013 12:21 PM, Sara Dickinson wrote:
> Hi All, 
> 
> Following all the discussions at RIPE on 'what users really want' after 2.0 I was planning to set up a user survey so users could vote on what features would be most useful to them. The point would be to help us understand the users' perspective better and prioritise _the order_ we do these developments in. 
> 
> I've put a list together, based on the current roadmap and specific user requests I'm aware of:
> 
> Interface/Usability
> --------------------------
> Enhancements to DS handling (e.g. hook for notification of DS generation, OPENDNSSEC-295, ds-seen --all option)
> Improvements to existing API (e.g. more consistent, better output, OPENDNSSEC-404)
> New, unified control API
> Alternative text based front end to update configuration options (currently stored in XML)
> Alternative graphical front end to update configuration options (currently stored in XML)
> Improved Monitoring (e.g. email notifications of events, daily email summary, 'ods summary' command)
> 
> Key handling
> -----------------------
> Support multiple key rollover methods
> Support policy rollover
> Support algorithm rollover

One of the things that was discussed during the CENTR was ECDSA and why
nobody it is using it. One of the key points is that vendors and tools
are lacking support. So ECDSA support in PKCS#11 and the possibility to
switch algorithms is something which I think is important.


> Allow KSK and ZSK to be the same key
> Offline KSK
> 
> Signer
> ---------
> Dynamic update adapter

Two organizations mentioned on the hallway that they are waiting for
this functionality.

> Database adapter
> Plugin adapter

Database adapter and Plugin adapter are two different names for the same
thing.

> Incremental transition from/to NSEC to/from NSEC3
> Reduced Memory usage
> 
> Other
> ---------
> Support for GOST/DSA

ECDSA that is. See comment above.

Best regards,
  Matthijs

> Support for Postgres DB backend 
> Support for Views (OPENDNSSEC-232)
> 
> 
> I plan to ask users to rate each feature as
> - Blocking/problematic in our use of OpenDNSSEC
> - Really want this feature right now please
> - Would use if available
> - Not important to us
> and ask for anything not on the list that they really want. 
> 
> Did I miss anything? Comments?
> 
> Sara._______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 



From sion at nominet.org.uk  Wed Jun 12 09:46:05 2013
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Wed, 12 Jun 2013 10:46:05 +0100
Subject: [Opendnssec-develop] RE: User survey on upcoming features
In-Reply-To: <C2BD4D4D-C277-418C-B294-A19CAED4CB18@sinodun.com>
References: <C2BD4D4D-C277-418C-B294-A19CAED4CB18@sinodun.com>
Message-ID: <51B8435D.4050302@nominet.org.uk>

A couple of others...

On 11/06/13 11:21, Sara Dickinson wrote:
> Interface/Usability
> --------------------------
> Enhancements to DS handling (e.g. hook for notification of DS generation, OPENDNSSEC-295, ds-seen --all option)
> Improvements to existing API (e.g. more consistent, better output, OPENDNSSEC-404)
> New, unified control API
> Alternative text based front end to update configuration options (currently stored in XML)
> Alternative graphical front end to update configuration options (currently stored in XML)
> Improved Monitoring (e.g. email notifications of events, daily email summary, 'ods summary' command)

Maybe this comes under the API comments above; but machine parseable
output has been requested in the past.

> Key handling
> -----------------------
> Support multiple key rollover methods
> Support policy rollover
> Support algorithm rollover
> Allow KSK and ZSK to be the same key
> Offline KSK

The ability to generate a pool of keys that can be allocated to any
(suitable) policy.

Sion


From sara at sinodun.com  Wed Jun 12 12:58:29 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 12 Jun 2013 13:58:29 +0100
Subject: [Opendnssec-develop] RE: Team meeting - Thursday 13 Jun @ 14:00 CEST
Message-ID: <F3C01B7B-531B-4C0A-8E7E-4BD1D4BEF70C@sinodun.com>

Hi All, 

We have a team meeting tomorrow:

Date:      Thursday 13 JUN 2013
Time:      14:00-15:00 CEST, 13:00-14:00 BST
Method:  Google+
Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2013-06-13+Agenda


Sara.



From jakob at kirei.se  Wed Jun 12 19:00:24 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 12 Jun 2013 21:00:24 +0200
Subject: [Opendnssec-develop] Summary of training sessions
In-Reply-To: <B3852312-6E7C-4E79-A4FF-FEEE11894A88@sinodun.com>
References: <B3852312-6E7C-4E79-A4FF-FEEE11894A88@sinodun.com>
Message-ID: <2C0C89DD-AFD6-4789-9941-20FD64519109@kirei.se>

On 11 jun 2013, at 12:23, Sara Dickinson <sara at sinodun.com> wrote:

> One comment made at RIPE was that the developers would like to be more aware of what happens in the training sessions as we don't tend to hear about them normally. Do you think it would be possible to write a few lines after each session letting us know what kind of people attended (particularly if a new organisation is using it), which version was used and any feedback on what they found easy/useful/cool/confusing? It would be really nice to have more visibility of this side of things :-)

I'm always trying to file all bugs that we discover, but other reporting is missing. I can take some additional nodes and present that back to the group.

	jakob



From sara at sinodun.com  Thu Jun 13 09:16:11 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 13 Jun 2013 10:16:11 +0100
Subject: [Opendnssec-develop] Summary of training sessions
In-Reply-To: <2C0C89DD-AFD6-4789-9941-20FD64519109@kirei.se>
References: <B3852312-6E7C-4E79-A4FF-FEEE11894A88@sinodun.com>
	<2C0C89DD-AFD6-4789-9941-20FD64519109@kirei.se>
Message-ID: <C8464D29-104A-4B90-9730-559BF96D387E@sinodun.com>


On 12 Jun 2013, at 20:00, Jakob Schlyter wrote:

> On 11 jun 2013, at 12:23, Sara Dickinson <sara at sinodun.com> wrote:
> 
>> One comment made at RIPE was that the developers would like to be more aware of what happens in the training sessions as we don't tend to hear about them normally. Do you think it would be possible to write a few lines after each session letting us know what kind of people attended (particularly if a new organisation is using it), which version was used and any feedback on what they found easy/useful/cool/confusing? It would be really nice to have more visibility of this side of things :-)
> 
> I'm always trying to file all bugs that we discover, but other reporting is missing. I can take some additional nodes and present that back to the group.

Cool - thank you!

Sara. 

> 
> 	jakob
> 



From matthijs at nlnetlabs.nl  Thu Jun 13 13:46:17 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Thu, 13 Jun 2013 15:46:17 +0200
Subject: [Opendnssec-develop] Passing through signed zones
Message-ID: <51B9CD29.4080906@nlnetlabs.nl>

Hi devs,

We have this issue for passing through unsigned zones:

https://issues.opendnssec.org/browse/OPENDNSSEC-138

But we probably also want to support passing though signed zones. Our
current solution only works for unsigned zones. Yuri and I have been
discussing and we want to propose the following solution for passing
through both types of zones:

The user should configure in the zonelist.xml if a zone should be passed
through by using a special name:

    <Policy>passthrough</Policy>

ods-kaspcheck should check that kasp.xml does not contain a policy with
that name. <SignerConfiguration> is ignored.*

If a zone is configured with such a policy name, the enforcer won't
create keys and signer configuration, the signer will not change zone
contents.

Pro:
- If you want to schedule a zone in for signing (in other words, no more
pass-through, sign with opendnssec) it is just a matter of changing the
policy name to one of the (existing) policies and run the update commands.
- You can have unsigned and signed zones under your control and unsigned
and signed zones not under your control go through the same signing
infrastructure.

Con:
- Hijacking a policy name is a bit ugly. On the other hand, having to
specifically mention this zone should be passed through makes it less
likely that users configure this unintentionally. Alternatively, we
could use a new zonelist.xml option <Pass-through/>.

What do you think?

Best regards,
  Matthijs


* Yuri and I have discussed that <SignerConfiguration> should not be
there in case of the policy is "passthrough", but I think ignoring is
better: In case you change it to a kasp, it takes less configuration
changes to make.


From sara at sinodun.com  Thu Jun 13 14:13:42 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 13 Jun 2013 15:13:42 +0100
Subject: Fwd: [Opendnssec-develop] RE: Team meeting - Thursday 13 Jun @ 14:00
	CEST
References: <F3C01B7B-531B-4C0A-8E7E-4BD1D4BEF70C@sinodun.com>
Message-ID: <470D4CDC-ACBD-45C8-8E26-A177E8885CA9@sinodun.com>

Hi All, 

The minutes of the meeting today are available online for review:

https://wiki.opendnssec.org/display/OpenDNSSEC/2013-06-13+Minutes

Sara. 

Begin forwarded message:

> From: Sara Dickinson <sara at sinodun.com>
> Date: 12 June 2013 13:58:29 GMT+01:00
> To: OpenDNSSEC Developers <Opendnssec-develop at lists.opendnssec.org>
> Subject: [Opendnssec-develop] RE: Team meeting - Thursday 13 Jun @ 14:00 CEST
> 
> Hi All, 
> 
> We have a team meeting tomorrow:
> 
> Date:      Thursday 13 JUN 2013
> Time:      14:00-15:00 CEST, 13:00-14:00 BST
> Method:  Google+
> Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2013-06-13+Agenda
> 
> 
> Sara.
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From jakob at kirei.se  Thu Jun 13 14:37:46 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 13 Jun 2013 16:37:46 +0200
Subject: [Opendnssec-develop] Passing through signed zones
In-Reply-To: <51B9CD29.4080906@nlnetlabs.nl>
References: <51B9CD29.4080906@nlnetlabs.nl>
Message-ID: <AB5371FD-9AF3-455A-B750-81AE6A917393@kirei.se>

On 13 jun 2013, at 15:46, Matthijs Mekking <matthijs at NLnetLabs.nl> wrote:

> Con:
> - Hijacking a policy name is a bit ugly. On the other hand, having to
> specifically mention this zone should be passed through makes it less
> likely that users configure this unintentionally. Alternatively, we
> could use a new zonelist.xml option <Pass-through/>.
> 
> What do you think?

I'd say we should go for a <PassThrough/> (or perhaps <Transparent/>) element in the zonelist - hijacking a policy name is a slippery slope that I do not want to take.

	jakob



From rick at openfortress.nl  Thu Jun 13 14:43:27 2013
From: rick at openfortress.nl (Rick van Rein (OpenFortress))
Date: Thu, 13 Jun 2013 16:43:27 +0200
Subject: [Opendnssec-develop] Passing through signed zones
In-Reply-To: <51B9CD29.4080906@nlnetlabs.nl>
References: <51B9CD29.4080906@nlnetlabs.nl>
Message-ID: <F728DE86-16DA-4C43-B3B1-B614E739A0AE@openfortress.nl>

Hallo,

> We have this issue for passing through unsigned zones:

You must mean "for passing zones without adding signatures".
The zone might already be signed of course.

> The user should configure in the zonelist.xml if a zone should be passed
> through by using a special name:
> 
>    <Policy>passthrough</Policy>

I assume this is a user-picked name that suggests to them what they mean, but that the name is not, as Jakob assumed from this text, in any way special.

I assume the real configuration would come down to setting no cryptographic configuration, or explicitly selecting a null or passthrough mechanism for signing/keying?

> Con:

 - Temporary passthrough signatures, such as during a zone migration between vendors, could end up requiring a change of signing policy.  You might not be prepared to support that.

> What do you think?

I think it's wonderful that this is being added.  I've missed it for a long time.

-Rick

From jakob at kirei.se  Thu Jun 13 14:56:39 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 13 Jun 2013 16:56:39 +0200
Subject: [Opendnssec-develop] Passing through signed zones
In-Reply-To: <F728DE86-16DA-4C43-B3B1-B614E739A0AE@openfortress.nl>
References: <51B9CD29.4080906@nlnetlabs.nl>
	<F728DE86-16DA-4C43-B3B1-B614E739A0AE@openfortress.nl>
Message-ID: <1AB80FCB-A734-437E-8435-E672A711B4D7@kirei.se>

On 13 jun 2013, at 16:43, "Rick van Rein (OpenFortress)" <rick at openfortress.nl> wrote:

> I assume this is a user-picked name that suggests to them what they mean, but that the name is not, as Jakob assumed from this text, in any way special.

Matthijs did in fact suggest a special name, that's why I proposed another tag.

As I understand this, the enforcer would ignore any zone parked as PassThrough/Transparent, correct?


	jakob



From matthijs at nlnetlabs.nl  Thu Jun 13 14:58:22 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Thu, 13 Jun 2013 16:58:22 +0200
Subject: [Opendnssec-develop] Passing through signed zones
In-Reply-To: <F728DE86-16DA-4C43-B3B1-B614E739A0AE@openfortress.nl>
References: <51B9CD29.4080906@nlnetlabs.nl>
	<F728DE86-16DA-4C43-B3B1-B614E739A0AE@openfortress.nl>
Message-ID: <51B9DE0E.5070808@nlnetlabs.nl>

On 06/13/2013 04:43 PM, Rick van Rein (OpenFortress) wrote:
> Hallo,
> 
>> We have this issue for passing through unsigned zones:
> 
> You must mean "for passing zones without adding signatures".
> The zone might already be signed of course.

Well, if we are going to nitpick :-p: The issue is for passing through
unsigned zones. And yes, we also want to support passing though signed
zones.

>> The user should configure in the zonelist.xml if a zone should be passed
>> through by using a special name:
>>
>>    <Policy>passthrough</Policy>
> 
> I assume this is a user-picked name that suggests to them what they mean, but that the name is not, as Jakob assumed from this text, in any way special.

The suggestion it was a special name (hence the suggestion ods-kaspcheck
should check for it). <Passthrough/> might be better.

> I assume the real configuration would come down to setting no cryptographic configuration, or explicitly selecting a null or passthrough mechanism for signing/keying?

The first would conflict with zones that go through unsigned gradually.
Explicitly selecting passthrough is probably the way to go.

> 
>> Con:
> 
>  - Temporary passthrough signatures, such as during a zone migration between vendors, could end up requiring a change of signing policy.  You might not be prepared to support that.

I need more information on what you exactly mean. What do you mean with
vendors? Different DNS operators? Different tooling?

The comment does make me realize that we might have to think about
gradually switching between passtrough and a kasp policy.

Best regards,
  Matthijs


> 
>> What do you think?
> 
> I think it's wonderful that this is being added.  I've missed it for a long time.

> 
> -Rick
> 



From matthijs at nlnetlabs.nl  Thu Jun 13 15:01:07 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Thu, 13 Jun 2013 17:01:07 +0200
Subject: [Opendnssec-develop] Passing through signed zones
In-Reply-To: <1AB80FCB-A734-437E-8435-E672A711B4D7@kirei.se>
References: <51B9CD29.4080906@nlnetlabs.nl>
	<F728DE86-16DA-4C43-B3B1-B614E739A0AE@openfortress.nl>
	<1AB80FCB-A734-437E-8435-E672A711B4D7@kirei.se>
Message-ID: <51B9DEB3.3080002@nlnetlabs.nl>

On 06/13/2013 04:56 PM, Jakob Schlyter wrote:
> On 13 jun 2013, at 16:43, "Rick van Rein (OpenFortress)" <rick at openfortress.nl> wrote:
> 
>> I assume this is a user-picked name that suggests to them what they mean, but that the name is not, as Jakob assumed from this text, in any way special.
> 
> Matthijs did in fact suggest a special name, that's why I proposed another tag.
> 
> As I understand this, the enforcer would ignore any zone parked as PassThrough/Transparent, correct?

Correct. This does open issues when you switch from a kasp policy to
passthrough or vice versa, as said in the reply to Rick (think gradually
transition). Especially in the passing through signed zones.

> 
> 
> 	jakob
> 
> 



From jakob at kirei.se  Thu Jun 13 18:57:56 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 13 Jun 2013 20:57:56 +0200
Subject: [Opendnssec-develop] Passing through signed zones
In-Reply-To: <51B9DEB3.3080002@nlnetlabs.nl>
References: <51B9CD29.4080906@nlnetlabs.nl>
	<F728DE86-16DA-4C43-B3B1-B614E739A0AE@openfortress.nl>
	<1AB80FCB-A734-437E-8435-E672A711B4D7@kirei.se>
	<51B9DEB3.3080002@nlnetlabs.nl>
Message-ID: <A41F6D0F-7B32-48F5-9850-FDF08C74EB99@kirei.se>

On 13 jun 2013, at 17:01, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:

> Correct. This does open issues when you switch from a kasp policy to
> passthrough or vice versa, as said in the reply to Rick (think gradually
> transition). Especially in the passing through signed zones.

Unless we try to support switching from passthrough signed to non-passthrough signed, that shouldn't be a problem?

	jakob



From matthijs at nlnetlabs.nl  Fri Jun 14 06:07:51 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Fri, 14 Jun 2013 08:07:51 +0200
Subject: [Opendnssec-develop] Passing through signed zones
In-Reply-To: <A41F6D0F-7B32-48F5-9850-FDF08C74EB99@kirei.se>
References: <51B9CD29.4080906@nlnetlabs.nl>
	<F728DE86-16DA-4C43-B3B1-B614E739A0AE@openfortress.nl>
	<1AB80FCB-A734-437E-8435-E672A711B4D7@kirei.se>
	<51B9DEB3.3080002@nlnetlabs.nl>
	<A41F6D0F-7B32-48F5-9850-FDF08C74EB99@kirei.se>
Message-ID: <51BAB337.6000805@nlnetlabs.nl>

On 06/13/2013 08:57 PM, Jakob Schlyter wrote:
> On 13 jun 2013, at 17:01, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:
> 
>> Correct. This does open issues when you switch from a kasp policy to
>> passthrough or vice versa, as said in the reply to Rick (think gradually
>> transition). Especially in the passing through signed zones.
> 
> Unless we try to support switching from passthrough signed to non-passthrough signed, that shouldn't be a problem?

I think in all cases where you try to switch a signed zone to or from
passthrough is difficult, because you have to taken into account other
dnssec material. The simple cases are:

1. Switching from passthrough unsigned to non-passthrough unsigned:
* Switch to a policy that has no keys configured

2. Switching from passthrough unsigned to non-passthrough signed:
* Switch to a regular policy

3. Switching from non-passthrough unsigned to passthrough unsigned:
* Switch to a passthrough policy

4. Switching from non-passthrough unsigned to passthrough signed:
* Switch to a passthrough policy

The other four cases should be well documented that it breaks stuff,
unless clever things are being done.

Best regards,
  Matthijs



> 
> 	jakob
> 
> 



From sara at sinodun.com  Fri Jun 14 16:16:49 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 14 Jun 2013 17:16:49 +0100
Subject: [Opendnssec-develop] RE: Agile boards
Message-ID: <4E3761B8-56E8-4A5E-B190-4BC82DF5E5CC@sinodun.com>

Hi All, 

Following on from the team meeting I have set up the following Agile boards in JIRA:

Development releases - to be used to track 1.3.X and 1.4.X releases via sprints (note: I have added enforcer/signer quick filters)
enforcer-ng                 - for all 2.0 related issues (currently hard-filtered to 2.0.0b1 & 2.0.0rc1)
Support                      - for the support project

Summary of things to remember with agile in JIRA:
- Epics don't appear in the planning or work boards. They only show up in the 'Epic' panel in the planning board
- Sub-tasks don't appear in the planning board. They do show up in the work board if the parent issue is in the sprint
(The agile theory is that Epics with sub-stories are for when the stories will happen in different sprints. Stories and their sub-tasks should always all happen in the same sprint).

- An issue can only be in one sprint at a time. To cope with the fact that we often implement in more than one release I suggest the following approach to start with in this case:
	- If the issue is going to sit on the backlog for a while then create it as we currently do i.e. a single issue with multiple fix versions. This means we won't have lots of clones sat on the backlog.
        - When we agree the issue should be moved into a sprint, or you start work on the issue then use the original issue for the version the problem was reported against/will be implemented in first (and correct the fix version to match this) and create clones for any other releases. Use the 'original' issue for any notes/discussions and the clones will simply track the porting of the code to other versions. Put all the issues in relevant sprints if they exist (or leave on the backlog otherwise).
        - When adding to the NEWS file why don't we just use the issue number of the 'original' issue in all the releases. (I'm not sure what is best but this seems least change from what we do now!). 

Lets see how this works for a while and let me know of any problems you find!

Sara.



From sara at sinodun.com  Mon Jun 17 13:43:52 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 17 Jun 2013 14:43:52 +0100
Subject: [Opendnssec-develop] RE: 1.4.1 release candidate
Message-ID: <9EEC7E8F-3E10-4DE0-8063-EB743FE670F6@sinodun.com>

Hi All, 

All of the issues that were discussed in the team meeting last week as being planned for 1.4.1 are now complete. If no-one has anything else that they want to nominate for 1.4.1 then we will go ahead and create a release candidate on Wednesday (19th).

Sara.

From sara at sinodun.com  Wed Jun 19 10:38:56 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 19 Jun 2013 11:38:56 +0100
Subject: [Opendnssec-develop] RE: User survey on future developments
Message-ID: <9CFA6FBE-A392-4A0B-9C57-904EA69182D0@sinodun.com>

Hi All, 

The 2.0 release of OpenDNSSEC is a re-write of the enforcer targeted at providing improved scalability and a more flexible architecture. 

Beyond 2.0 we have a long list of developments on the roadmap, many of which come from specific user requests. We would like to gather some general feedback on which of the features would be most valuable to the user community so we can use this as input when prioritising the list. Note that our issue tracker (https://issues.opendnssec.org) does support voting on issues but we wanted a more structured survey here.

The survey is split into two parts:

Specific key handling and zone signing features:
http://sinodun.wufoo.com/forms/opendnssec-survey-key-handling-zone-signing/

Usability, interface and general features:
http://sinodun.wufoo.com/forms/opendnssec-survey-usability-interface/

We would be grateful for any and all feedback on the above to help us understand the needs of our users. 

Regards

Sara.



From sara at sinodun.com  Wed Jun 19 10:58:50 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 19 Jun 2013 11:58:50 +0100
Subject: [Opendnssec-develop] RE: 1.4.1 release candidate
Message-ID: <FBF693B9-387E-4491-9296-2FED788E53A1@sinodun.com>

All, 

Version 1.4.1rc1 of OpenDNSSEC is now available. This is a release candidate for testing purposes:


OpenDNSSEC 1.4.1rc1 - 2013-06-19
------------------------------------------------------
 
Updates:
* SUPPORT-58: Extend ods-signer sign <zone> with --serial <nr> so that the user can specify the SOA serial to use in the signed zone [OPENDNSSEC-401].
* OPENDNSSEC-91: Make the keytype flag required when rolling keys
 
Bugfixes:
* SUPPORT-60: Fix datecounter in case inbound serial is higher than outbound serial [OPENDNSSEC-420].
* OPENDNSSEC-247: Signer Engine: TTL on NSEC3 was not updated on SOA Minimum change.
* OPENDNSSEC-421: Signer Engine: Fix assertion error in case NSEC3 hash algorithm in signconf is not SHA1.
* OPENDNSSEC-421: ods-kaspcheck: Check whether NSEC3 hash algorithm in kasp is valid.
* Bugfix: The time when inbound serial is acquired was reset invalidly could cause OpenDNSSEC wanting AXFR responses while requesting IXFR (thanks Stuart Lau).
* Bugfix: Fix malform in Outbound IXFR/TCP subsequent packet (thanks Stuart Lau).
* OPENDNSSEC-398: The ods-ksmutil key rollover command does not work correctly when rolling all keys using the --policy option

Downloads:
* https://dist.opendnssec.org/source/testing/opendnssec-1.4.1rc1.tar.gz
* https://dist.opendnssec.org/source/testing/opendnssec-1.4.1rc1.tar.gz.sig
* Checksum sha1: b19e80d4ab9b93c3a34cb9858241716ee67ad85d
* Checksum sha256: b6728d2bafe3e5678e1f1676d165d78e0812e4f2896fac0fe3bbe8267e8e841a


A full 1.4.1 release is planned for Wednesday 26th June.

//OpenDNSSEC team




From sebastian at nzrs.net.nz  Wed Jun 19 21:22:04 2013
From: sebastian at nzrs.net.nz (Sebastian Castro)
Date: Thu, 20 Jun 2013 09:22:04 +1200
Subject: [Opendnssec-develop] Re: [Opendnssec-user] RE: User survey on
	future developments
In-Reply-To: <9CFA6FBE-A392-4A0B-9C57-904EA69182D0@sinodun.com>
References: <9CFA6FBE-A392-4A0B-9C57-904EA69182D0@sinodun.com>
Message-ID: <51C220FC.6060007@nzrs.net.nz>

On 19/06/13 22:38, Sara Dickinson wrote:
> Hi All,

Hi Sara,

> 
> The 2.0 release of OpenDNSSEC is a re-write of the enforcer targeted
> at providing improved scalability and a more flexible architecture.
> 
> Beyond 2.0 we have a long list of developments on the roadmap, many
> of which come from specific user requests. We would like to gather
> some general feedback on which of the features would be most valuable
> to the user community so we can use this as input when prioritising
> the list. Note that our issue tracker (https://issues.opendnssec.org)
> does support voting on issues but we wanted a more structured survey
> here.
> 
> The survey is split into two parts:
> 
> Specific key handling and zone signing features: 
> http://sinodun.wufoo.com/forms/opendnssec-survey-key-handling-zone-signing/
>
>  Usability, interface and general features: 
> http://sinodun.wufoo.com/forms/opendnssec-survey-usability-interface/

Thanks for making this possible.
I was wondering, from a user's point of view, if it's possible to have
links to the issues tracker for those features that have a ticket?

For example, "Improvements to DS handling" corresponds to ticket 295.
For those who don't have fresh in their memories the context of each
request, is going to require a different window/tab with the issue
tracker and a search.

I'll answer the survey during the day.


>
>  We would be grateful for any and all feedback on the above to help
> us understand the needs of our users.

Do you have a date when are you going to close the survey?

Cheers,

> 
> Regards
> 
> Sara.
> 
> _______________________________________________ Opendnssec-user
> mailing list Opendnssec-user at lists.opendnssec.org 
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> 


-- 
Sebastian Castro
DNS Specialist
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 495 2337
mobile: +64 21 400535


From sara at sinodun.com  Thu Jun 20 12:24:42 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 20 Jun 2013 13:24:42 +0100
Subject: [Opendnssec-develop] Re: [Opendnssec-user] RE: User survey on
	future developments
In-Reply-To: <51C220FC.6060007@nzrs.net.nz>
References: <9CFA6FBE-A392-4A0B-9C57-904EA69182D0@sinodun.com>
	<51C220FC.6060007@nzrs.net.nz>
Message-ID: <56583BEF-250C-4349-B8F8-A18CF745F37D@sinodun.com>


On 19 Jun 2013, at 22:22, Sebastian Castro wrote:

> 
> I was wondering, from a user's point of view, if it's possible to have
> links to the issues tracker for those features that have a ticket?

Hi Sebastian,

Thanks for the mail. The webpage wouldn't let me embed links so here are links to specific issues mentioned:

Improvements to DS handling (e.g. hook for notification of DS generation, OPENDNSSEC-295, ds-seen --all option):
 - https://issues.opendnssec.org/browse/OPENDNSSEC-295

Improvements to existing API (e.g. more consistent input/output, parsable output, OPENDNSSEC-404)
- https://issues.opendnssec.org/browse/OPENDNSSEC-404

Support for views (OPENDNSSEC-232)
- https://issues.opendnssec.org/browse/OPENDNSSEC-232

Offline KSK (OPENDNSSEC-251)
- https://issues.opendnssec.org/browse/OPENDNSSEC-251

Generate a pool of keys that can be allocated to any policy (OPENDNSSEC-103)
- https://issues.opendnssec.org/browse/OPENDNSSEC-103


There are issues for many of the other features but they just have titles and no real content at the moment :-)  This link lists most of them in case users want to add comments directly:
- https://issues.opendnssec.org/issues/?jql=fixVersion%20%3D%20%222.X%22%20AND%20project%20%3D%20OPENDNSSEC


> 
> Do you have a date when are you going to close the survey?

I was going to give it until the end of next week so 28th July. I'll report back the findings after that.

Sara.



From sara at sinodun.com  Wed Jun 26 09:54:00 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 26 Jun 2013 10:54:00 +0100
Subject: [Opendnssec-develop] RE: Team meeting - Thursday 27 Jun @ 14:00 CEST
Message-ID: <FA3BD1F4-4F55-4E75-B80D-EE2E7FF5B512@sinodun.com>

Hi All, 

We have a team meeting tomorrow:

Date:      Thursday 27 Jun 2013
Time:      14:00-15:00 CEST, 13:00-14:00 BST
Method:  Google+
Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2013-06-27+Agenda


Sara.




From sara at sinodun.com  Thu Jun 27 11:06:52 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 27 Jun 2013 12:06:52 +0100
Subject: [Opendnssec-develop] OpenDNSSEC 1.4.1
Message-ID: <322E17E6-A7F6-4E2D-A325-B8FEEB2AF7C0@sinodun.com>

All, 

Version 1.4.1 of OpenDNSSEC has now been released. This is the latest stable release.

Updates:

* SUPPORT-58: Extend ods-signer sign <zone> with --serial <nr> so that the user can specify the SOA serial to use in the signed zone [OPENDNSSEC-401].
* OPENDNSSEC-91: Make the keytype flag required when rolling keys
 
Bugfixes:

* SUPPORT-60: Fix datecounter in case inbound serial is higher than outbound serial [OPENDNSSEC-420].
* OPENDNSSEC-247: Signer Engine: TTL on NSEC3 was not updated on SOA Minimum change.
* OPENDNSSEC-421: Signer Engine: Fix assertion error in case NSEC3 hash algorithm in signconf is not SHA1.
* OPENDNSSEC-421: ods-kaspcheck: Check whether NSEC3 hash algorithm in kasp is valid.
* Bugfix: The time when inbound serial is acquired was reset invalidly, could cause OpenDNSSEC wanting AXFR responses while requesting IXFR (thanks Stuart Lau).
* Bugfix: Fix malform in Outbound IXFR/TCP subsequent packet (thanks Stuart Lau).
* OPENDNSSEC-398: The ods-ksmutil key rollover command does not work correctly when rolling all keys using the --policy option

Documentation:

* http://wiki.opendnssec.org/display/DOCS

Download:

* http://dist.opendnssec.org/source/opendnssec-1.4.1.tar.gz
* http://dist.opendnssec.org/source/opendnssec-1.4.1.tar.gz.sig
* Checksum sha1: 90020d343456af0846b13c951a6a914109cb5d22
* Checksum sha256: 7795ba9f98f9c8292d5f9f9d6ffbf88352a6f77986f43acc1a30141f6027cc82


//OpenDNSSEC team