From sara at sinodun.com  Mon Sep  2 13:06:25 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 2 Sep 2013 14:06:25 +0100
Subject: [Opendnssec-develop] RE: 1.4.2rc1 release planned for tomorrow
Message-ID: <AC3E72F7-417B-4F23-B881-A8638F0E24B0@sinodun.com>

Hi All, 

I would like to go ahead with a 1.4.2rc1 release tomorrow if possible since the latest signer fixes have now been tested. If anyone wants any further changes to this release before the rc is made available them please let me know asap. 

There are a few bug fixes that still need porting to 1.3.15 and Matthijs has one development to do that won't be finished till next week so I suggest we hold off on 1.3.15 for now. 

Sara. 



From sara at sinodun.com  Mon Sep  2 13:44:10 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 2 Sep 2013 14:44:10 +0100
Subject: [Opendnssec-develop] RE: OpenDNSSEC Developer workshop 
In-Reply-To: <6670AC33-18A1-48DF-A55A-686307739B23@sinodun.com>
References: <6670AC33-18A1-48DF-A55A-686307739B23@sinodun.com>
Message-ID: <EE66F5D1-F295-43BC-A965-9C18159B499D@sinodun.com>

Hi All, 

Thanks to those that filled in the last doodle. Firstly, it seems that only a few people are going to RIPE. Secondly since we are a bigger team now it seems like it might make more sense to have a dedicated 2 or 3 day developer workshop to get us all meeting (and working!) face to face. 

After a bit of discussion with Jakob and Patrik we came up with two dates that we thought might work for this:

1) The days immediately before the IETF 88 in Vancouver (e.g. Thur 31st Oct - Sat 2nd Nov) or

2) A separate meeting in Stockholm during the week after IETF 88 (e.g. Wed 13th Nov - Fri 15th Nov)

I have set up a doodle to find out availability for these dates:

http://doodle.com/v4hnzxmef5xd7vic

Please note that there is a (Yes) option on the poll which acts as a 'maybe' answer. Please use this if you are free on these dates but would need to get agreement from your boss and/or agree funding for the trip. 

Thanks

Sara. 


On 22 Aug 2013, at 15:49, Sara Dickinson wrote:

> Hi All, 
> 
> I'd like to get an idea of how many people think they will be at RIPE 67 so we can decide if we can do a developer workshop there, or if we need to arrange a separate one. Could you please fill in the following doodle with your best guess at your attendance?
> 
> http://doodle.com/y39evixupud4x67h





From jakob at kirei.se  Mon Sep  2 14:42:41 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 2 Sep 2013 16:42:41 +0200
Subject: [Opendnssec-develop] RE: OpenDNSSEC Developer workshop 
In-Reply-To: <EE66F5D1-F295-43BC-A965-9C18159B499D@sinodun.com>
References: <6670AC33-18A1-48DF-A55A-686307739B23@sinodun.com>
	<EE66F5D1-F295-43BC-A965-9C18159B499D@sinodun.com>
Message-ID: <682D7D03-CE03-4E0B-9129-19C6EBDEF1D8@kirei.se>

2 sep 2013 kl. 15:44 skrev Sara Dickinson <sara at sinodun.com>:

> Please note that there is a (Yes) option on the poll which acts as a 'maybe' answer. Please use this if you are free on these dates but would need to get agreement from your boss and/or agree funding for the trip. 

I'd like to emphasize the above - if funding is the reason for not being able to participate, please mark as MAYBE.

  Jakob



From sara at sinodun.com  Tue Sep  3 12:00:50 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 3 Sep 2013 13:00:50 +0100
Subject: [Opendnssec-develop] RE: OpenDNSSEC 1.4.2rc1 release candidate
Message-ID: <C73C4EC5-E03C-4389-9720-095FB26EAE9D@sinodun.com>

All, 

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


OpenDNSSEC 1.4.2rc1 - 2013-09-03
-----------------------------------------------------

Updates:
* OPENDNSSEC-428: ods-ksmutil: Add option for 'ods-ksmutil key generate' to take number of zones as a parameter

Bugfixes:
* OPENDNSSEC-438: 'ods-ksmutil key generate' and the enforcer can create too many keys for <SharedKeys/> policies when KSK and ZSK use same algorithm and length
* OPENDNSSEC_440: 'ods-ksmutil key generate' and the enforcer can create too many keys if there are keys already available and the KSK and ZSK use same algorithm and length
* SUPPORT-66: Signer Engine: Fix file descriptor leak in case of TCP write error [OPENDNSSEC-427].
* OPENDNSSEC-424: Signer Engine: Respond to SOA queries from file instead of memory. Makes response non-blocking.
* OPENDNSSEC-425 Change "hsmutil list" output so that the table header goes to stdout not stderr
* Signer Engine: Improved Inbound XFR checking.
* Signer Engine: Fix double free corruption in case of adding zone with DNS Outbound Adapters and NotifyCommand enabled.
* OPENDNSSEC-443: ods-ksmutil: Clean up of hsm connection handling
* OPENDNSSEC-401: 'ods-signer sign <zone> --serial <nr>' command produces seg fault when run directly on command line (i.e. not via interactive mode)
* OPENDNSSEC-444: Fix double free corruption in case of HSM connection error while signing RRsets (also fixes SUPPORT-71).

Downloads:
* http://dist.opendnssec.org/source/testing/opendnssec-1.4.2rc1.tar.gz
* http://dist.opendnssec.org/source/testing/opendnssec-1.4.2rc1.tar.gz.sig
* Checksum sha1: 5766c5510f225f09c13e9ffaaf09cb447aa428f1
* Checksum sha256: c3ad800b7548480fa36d65889d452333f7e03ef8909719d4ffdb97274452a186


A full 1.4.2 release is planned for Tuesday 10th September. 

//OpenDNSSEC team




From sara at sinodun.com  Tue Sep  3 12:38:51 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 3 Sep 2013 13:38:51 +0100
Subject: [Opendnssec-develop] RE: Jenkins unavailable this weekend (6th-9th
	Sept 2013)
Message-ID: <FD5D9B3F-C4FE-4912-8EAF-F38579CAF452@sinodun.com>

Hi All, 

Due to maintenance on the electrical system in our office the jenkins master sever and web front end will be unavailable over the coming weekend:

From: Friday 6th Sept 17:00 UTC
To:     Monday 9th Sept 9:00 UTC

Apologies for any inconvenience this may cause. 

Sara. 




From rick at openfortress.nl  Thu Sep  5 14:07:32 2013
From: rick at openfortress.nl (Rick van Rein (OpenFortress))
Date: Thu, 5 Sep 2013 16:07:32 +0200
Subject: [Opendnssec-develop] Manually checking DNSSEC signatures
Message-ID: <1281B6E7-56C6-43A5-BECB-705BE30A9309@openfortress.nl>

Hello,

When OpenDNSSEC is behave a bit wild, we sometimes feel a desire to check the signatures by hand, and try alternatives.  I suppose that desire could also rise with others, so we've written out our procedure.  It's just a few easy steps with Python, really:

https://dnssec.surfnet.nl/?p=873

I hope this is useful to others, as well as to us.  If not, then at least we have it a proper document for our own use  ;-)

Cheers,
 -Rick

From rick at openfortress.nl  Thu Sep  5 14:13:48 2013
From: rick at openfortress.nl (Rick van Rein (OpenFortress))
Date: Thu, 5 Sep 2013 16:13:48 +0200
Subject: [Opendnssec-develop] Re: Manually checking DNSSEC signatures
In-Reply-To: <20130905141033.GA27895@nic.fr>
References: <1281B6E7-56C6-43A5-BECB-705BE30A9309@openfortress.nl>
	<20130905141033.GA27895@nic.fr>
Message-ID: <6C7F2D32-6100-4043-9831-C569CAA2FD8E@openfortress.nl>

Hi,

>> we sometimes feel a desire to check the signatures by hand, 
> 
> Why checking by hand a few signatures when you can automatically check
> them all?

We had a problem where a different key was used than was claimed in DNS.  It helped us to analyse the problem that we could find out which key was behaving badly.  It's a great help with debugging and development.

In general, knowing how to do this means you have more control than what may be constrained by your software.  I thought that was enough reason to share.

-Rick

From jerry at opendnssec.org  Fri Sep  6 07:58:20 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Fri, 6 Sep 2013 09:58:20 +0200
Subject: [Opendnssec-develop] Team meetings,
	move it half an hour to 14.30 CEST?
Message-ID: <55BD88C0-CAA0-4D25-AD5D-0109F42C02AF@opendnssec.org>

Hi all,

Can we move the meeting half an hour to 14.30 CEST?

I am already booked on another meeting from 13.30 to 14.30 :/

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130906/6489bbca/attachment.bin>

From sara at sinodun.com  Fri Sep  6 09:01:51 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 6 Sep 2013 10:01:51 +0100
Subject: [Opendnssec-develop] Team meetings,
	move it half an hour to 14.30 CEST?
In-Reply-To: <55BD88C0-CAA0-4D25-AD5D-0109F42C02AF@opendnssec.org>
References: <55BD88C0-CAA0-4D25-AD5D-0109F42C02AF@opendnssec.org>
Message-ID: <2F341C4A-E94D-4E3B-A0A8-C012AC20E80D@sinodun.com>


On 6 Sep 2013, at 08:58, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> Hi all,
> 
> Can we move the meeting half an hour to 14.30 CEST?
> 
> I am already booked on another meeting from 13.30 to 14.30 :/
> 

That is no problem for me. 

Is this just the case for Thursdays? If we have the meeting on a Tuesday (as we plan to do next week) can you make 14:00 CEST?

Sara. 



From jerry at opendnssec.org  Fri Sep  6 09:05:35 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Fri, 6 Sep 2013 11:05:35 +0200
Subject: [Opendnssec-develop] Team meetings,
	move it half an hour to 14.30 CEST?
In-Reply-To: <2F341C4A-E94D-4E3B-A0A8-C012AC20E80D@sinodun.com>
References: <55BD88C0-CAA0-4D25-AD5D-0109F42C02AF@opendnssec.org>
	<2F341C4A-E94D-4E3B-A0A8-C012AC20E80D@sinodun.com>
Message-ID: <E8CF4C41-0A4F-44CC-A585-E73086124986@opendnssec.org>

On Sep 6, 2013, at 11:01 , Sara Dickinson wrote:

> Is this just the case for Thursdays? If we have the meeting on a Tuesday (as we plan to do next week) can you make 14:00 CEST?


Huh? According to the latest agenda next meeting is on the 10th (Tuesday) next week and I have a meeting before that every Tuesday.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130906/c7f3f917/attachment.bin>

From sara at sinodun.com  Fri Sep  6 09:14:28 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 6 Sep 2013 10:14:28 +0100
Subject: [Opendnssec-develop] Team meetings,
	move it half an hour to 14.30 CEST?
In-Reply-To: <E8CF4C41-0A4F-44CC-A585-E73086124986@opendnssec.org>
References: <55BD88C0-CAA0-4D25-AD5D-0109F42C02AF@opendnssec.org>
	<2F341C4A-E94D-4E3B-A0A8-C012AC20E80D@sinodun.com>
	<E8CF4C41-0A4F-44CC-A585-E73086124986@opendnssec.org>
Message-ID: <15D59E7B-4A10-4240-BD00-847736F86480@sinodun.com>


On 6 Sep 2013, at 10:05, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> On Sep 6, 2013, at 11:01 , Sara Dickinson wrote:
> 
>> Is this just the case for Thursdays? If we have the meeting on a Tuesday (as we plan to do next week) can you make 14:00 CEST?
> 
> 
> Huh? According to the latest agenda next meeting is on the 10th (Tuesday) next week and I have a meeting before that every Tuesday.
> 

Next week the meeting is on a Tuesday because not enough people could make the Thursday but most recent meetings have all been on a Thursday. 

Sara.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130906/e6e4f478/attachment.htm>

From yuri at nlnetlabs.nl  Fri Sep  6 09:37:54 2013
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Fri, 06 Sep 2013 11:37:54 +0200
Subject: [Opendnssec-develop] Team meetings, move it half an hour to 14.30
	CEST?
In-Reply-To: <55BD88C0-CAA0-4D25-AD5D-0109F42C02AF@opendnssec.org>
References: <55BD88C0-CAA0-4D25-AD5D-0109F42C02AF@opendnssec.org>
Message-ID: <5229A272.7070409@nlnetlabs.nl>

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

> Can we move the meeting half an hour to 14.30 CEST?

no problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlIponIACgkQI3PTR4mhavihEACeLfI/Njrk36KJYiIUFp5mVXVZ
i24An37/nIeSeshi9KDsLFpjMjh26PYX
=QNXa
-----END PGP SIGNATURE-----


From jerry at opendnssec.org  Fri Sep  6 10:56:31 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Fri, 6 Sep 2013 12:56:31 +0200
Subject: [Opendnssec-develop] Team meetings,
	move it half an hour to 14.30 CEST?
In-Reply-To: <15D59E7B-4A10-4240-BD00-847736F86480@sinodun.com>
References: <55BD88C0-CAA0-4D25-AD5D-0109F42C02AF@opendnssec.org>
	<2F341C4A-E94D-4E3B-A0A8-C012AC20E80D@sinodun.com>
	<E8CF4C41-0A4F-44CC-A585-E73086124986@opendnssec.org>
	<15D59E7B-4A10-4240-BD00-847736F86480@sinodun.com>
Message-ID: <38B1B407-170F-41F0-9851-CD0E1C3FB027@opendnssec.org>

On Sep 6, 2013, at 11:14 , Sara Dickinson wrote:

> Next week the meeting is on a Tuesday because not enough people could make the Thursday but most recent meetings have all been on a Thursday. 


Ok, Thursdays are not a problem. Tuesdays are. So just for the next meeting on the 10th.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130906/8d70831b/attachment.bin>

From sara at sinodun.com  Sun Sep  8 16:10:20 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Sun, 8 Sep 2013 17:10:20 +0100
Subject: [Opendnssec-develop] RE: Team meeting - Tuesday 10 Sept 2013 @
	14:30 CEST
Message-ID: <056AD924-5FD8-43B5-A5CC-7CA78A3F8A40@sinodun.com>

Hi All, 

We have a team meeting on Tuesday this week:

Date:      Tuesday 10 Sep 2013
Time:      14:30-15:30 CEST, 13:30-14:30 BST, 20:30 CST, 12:30 UTC
Method:  Teamspeak. Server name and password are here (requires login):
https://wiki.opendnssec.org/display/OpenDNSSEC/Conference+call+details
Agenda: https://wiki.opendnssec.org/display/OpenDNSSEC/2013-09-10+Agenda

We will give Teamspeak a go this week using the server that Yuri has set up. So please take a minute to set up the client before the meeting. If anyone wants to check they can connect OK then just drop me a line and we can have a short test call anytime. 

Also - note the change in time to 14:30 CEST as requested by Jerry. 


Sara.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130908/4c2a5b03/attachment.htm>

From sara at sinodun.com  Sun Sep  8 16:20:39 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Sun, 8 Sep 2013 17:20:39 +0100
Subject: [Opendnssec-develop] RE: JIRA issues and Crucible code reviews
Message-ID: <091C577F-072F-40F5-BB90-947E1937BFF3@sinodun.com>

Hi All, 

Firstly - I have updated the page describing how we handle JIRA issues to make it a bit clearer and to reflect the fact that we now use the agile workflow to manage our issues:
https://wiki.opendnssec.org/display/OpenDNSSEC/Issue+tracking+process
Please let me have any comments/feedback on this.

Secondly - we now have Crucible available for code reviews. I have tried to write up a basic workflow here:
https://wiki.opendnssec.org/display/OpenDNSSEC/Code+Review+process
But if you get stuck there is official documentation available here:
https://confluence.atlassian.com/display/CRUCIBLE030/Using+Crucible
Again comments/feedback welcomed. 

I suggest that we all start to use Crucbile for code reviews in JIRA issues from now on and we can review how we think this is working in a few weeks! 

Best regards

Sara. 

From sara at sinodun.com  Sun Sep  8 16:58:57 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Sun, 8 Sep 2013 17:58:57 +0100
Subject: Fwd: [Opendnssec-develop] RE: Jenkins unavailable this weekend
	(6th-9th Sept 2013)
References: <FD5D9B3F-C4FE-4912-8EAF-F38579CAF452@sinodun.com>
Message-ID: <A4B1029C-1AC8-40AC-96D4-6421A960087C@sinodun.com>

Hi All, 

Jenkins is back online now.

Sara.

Begin forwarded message:

> From: Sara Dickinson <sara at sinodun.com>
> Date: 3 September 2013 13:38:51 GMT+01:00
> To: "opendnssec-develop at lists.opendnssec.org Developers" <Opendnssec-develop at lists.opendnssec.org>
> Subject: [Opendnssec-develop] RE: Jenkins unavailable this weekend (6th-9th Sept 2013)
> 
> Hi All, 
> 
> Due to maintenance on the electrical system in our office the jenkins master sever and web front end will be unavailable over the coming weekend:
> 
> From: Friday 6th Sept 17:00 UTC
> To:     Monday 9th Sept 9:00 UTC
> 
> Apologies for any inconvenience this may cause. 
> 
> Sara. 
> 
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From rafiee at hpi.uni-potsdam.de  Mon Sep  9 14:34:01 2013
From: rafiee at hpi.uni-potsdam.de (Rafiee, Hosnieh)
Date: Mon, 9 Sep 2013 14:34:01 +0000
Subject: [Opendnssec-develop] Question
Message-ID: <8EBBE4774B42FC45BA1143BE7F3F5A0F0E7A8D@MXMA2012.hpi.uni-potsdam.de>

Hello,

Would you please help me and tell me where I can find this header file "config.h".

Thanks,
Best Regards,
Hosnieh


From sara at sinodun.com  Mon Sep  9 15:02:37 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 9 Sep 2013 16:02:37 +0100
Subject: [Opendnssec-develop] Question
In-Reply-To: <8EBBE4774B42FC45BA1143BE7F3F5A0F0E7A8D@MXMA2012.hpi.uni-potsdam.de>
References: <8EBBE4774B42FC45BA1143BE7F3F5A0F0E7A8D@MXMA2012.hpi.uni-potsdam.de>
Message-ID: <0F051135-DE4C-4723-9FBC-1444E177553C@sinodun.com>


On 9 Sep 2013, at 15:34, Rafiee, Hosnieh wrote:

> Hello,
> 
> Would you please help me and tell me where I can find this header file "config.h".

Hi Hosneih, 

There is a file common/config.h which is created from configure.ac (so it does not exist in the repository but you see included lots of places) - do you mean this?

Sara.

> 
> Thanks,
> Best Regards,
> Hosnieh
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From matthijs at nlnetlabs.nl  Tue Sep 10 13:01:35 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Tue, 10 Sep 2013 15:01:35 +0200
Subject: [Opendnssec-develop] signed serial > unsigned serial?
Message-ID: <522F182F.60407@nlnetlabs.nl>

Should the signed serial always be higher than the unsigned serial?

I have written my thoughts down here:

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

As a reaction to the report SUPPORT-73. My initial thoughts:

Should we always have the signed serial to be higher than the unsigned
serial? We now only do that if the signer has no state about the zone
(eg "first run").

In case of keep: no.
In case of unixtime: I would prefer to use unixtime if possible.
In case of datecounter: I would prefer to use datecounter if possible.
In case of counter: We could consider this.

But that will only happen if the signer reads the unsigned zone, as we
only read the unsigned zone if the operator specifically tells us to do
with "ods-signer sign <zone>" (or in case of DNS adapters, the master
gives us a NOTIFY, or the REFRESH/RETRY timer has triggered).

So in case of a regular re-sign, we cannot satisfy this requirement.

Take this as a starting point of the discussion and I like your thoughts
on this, whether we should accept this feature request or stick to the
current behavior.

Best regards,
  Matthijs


From sion at nominet.org.uk  Tue Sep 10 13:58:04 2013
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Tue, 10 Sep 2013 14:58:04 +0100
Subject: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <522F182F.60407@nlnetlabs.nl>
References: <522F182F.60407@nlnetlabs.nl>
Message-ID: <522F256C.2010801@nominet.org.uk>

What is the use-case? So long as the serial in the published zone is
always increasing then we are okay surely...

Sion

On 10/09/13 14:01, Matthijs Mekking wrote:
> Should the signed serial always be higher than the unsigned serial?
>
> I have written my thoughts down here:
>
>   https://issues.opendnssec.org/browse/OPENDNSSEC-446
>
> As a reaction to the report SUPPORT-73. My initial thoughts:
>
> Should we always have the signed serial to be higher than the unsigned
> serial? We now only do that if the signer has no state about the zone
> (eg "first run").
>
> In case of keep: no.
> In case of unixtime: I would prefer to use unixtime if possible.
> In case of datecounter: I would prefer to use datecounter if possible.
> In case of counter: We could consider this.
>
> But that will only happen if the signer reads the unsigned zone, as we
> only read the unsigned zone if the operator specifically tells us to do
> with "ods-signer sign <zone>" (or in case of DNS adapters, the master
> gives us a NOTIFY, or the REFRESH/RETRY timer has triggered).
>
> So in case of a regular re-sign, we cannot satisfy this requirement.
>
> Take this as a starting point of the discussion and I like your thoughts
> on this, whether we should accept this feature request or stick to the
> current behavior.
>
> Best regards,
>   Matthijs
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From matthijs at nlnetlabs.nl  Tue Sep 10 14:02:47 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Tue, 10 Sep 2013 16:02:47 +0200
Subject: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <522F256C.2010801@nominet.org.uk>
References: <522F182F.60407@nlnetlabs.nl> <522F256C.2010801@nominet.org.uk>
Message-ID: <522F2687.7040702@nlnetlabs.nl>

The use case is described in SUPPORT-73. Basically it is part of a check
before publishing, that requires the outgoing serial to be equal or
higher than the incoming serial. Quoting:

"So the serial of signed file must be higher than or equal to that in
unsigned zone, to ensure the signed file which we got is for the newest
unsigned zone."

Best regards,
  Matthijs

On 09/10/2013 03:58 PM, Si?n Lloyd wrote:
> What is the use-case? So long as the serial in the published zone is
> always increasing then we are okay surely...
> 
> Sion
> 
> On 10/09/13 14:01, Matthijs Mekking wrote:
>> Should the signed serial always be higher than the unsigned serial?
>>
>> I have written my thoughts down here:
>>
>>   https://issues.opendnssec.org/browse/OPENDNSSEC-446
>>
>> As a reaction to the report SUPPORT-73. My initial thoughts:
>>
>> Should we always have the signed serial to be higher than the unsigned
>> serial? We now only do that if the signer has no state about the zone
>> (eg "first run").
>>
>> In case of keep: no.
>> In case of unixtime: I would prefer to use unixtime if possible.
>> In case of datecounter: I would prefer to use datecounter if possible.
>> In case of counter: We could consider this.
>>
>> But that will only happen if the signer reads the unsigned zone, as we
>> only read the unsigned zone if the operator specifically tells us to do
>> with "ods-signer sign <zone>" (or in case of DNS adapters, the master
>> gives us a NOTIFY, or the REFRESH/RETRY timer has triggered).
>>
>> So in case of a regular re-sign, we cannot satisfy this requirement.
>>
>> Take this as a starting point of the discussion and I like your thoughts
>> on this, whether we should accept this feature request or stick to the
>> current behavior.
>>
>> Best regards,
>>   Matthijs
>> _______________________________________________
>> 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 yuri at nlnetlabs.nl  Tue Sep 10 14:38:14 2013
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Tue, 10 Sep 2013 16:38:14 +0200
Subject: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <522F182F.60407@nlnetlabs.nl>
References: <522F182F.60407@nlnetlabs.nl>
Message-ID: <522F2ED6.1080103@nlnetlabs.nl>

> Should the signed serial always be higher than the unsigned serial?
> #OPENDNSSEC-446 #SUPPORT-73.

I do not agree with the reporter that ODS should follow the unsigned
serial. As an admin you explicitly transfer the management
responsibility to ODS. The way you describe it is now sounds like the
sanest solution to me. The serial of an unpublished version of the zone
is not relevant at all.

//Yuri

-- 
Composed on an actual keyboard: all typos genuine.


From rick at openfortress.nl  Tue Sep 10 15:29:01 2013
From: rick at openfortress.nl (Rick van Rein (OpenFortress))
Date: Tue, 10 Sep 2013 17:29:01 +0200
Subject: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <522F2ED6.1080103@nlnetlabs.nl>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
Message-ID: <97557EE9-C100-4D17-A25F-C26EF95F4E55@openfortress.nl>

Hi,

>> Should the signed serial always be higher than the unsigned serial?
>> #OPENDNSSEC-446 #SUPPORT-73.
> 
> I do not agree with the reporter that ODS should follow the unsigned
> serial.

Clear statement, and understood.  But you're forgetting something...

> As an admin you explicitly transfer the management
> responsibility to ODS.

To be able to switch OpenDNSSEC on and off (which can really help its acceptance) you need to rely on *some* relation between the serials coming out; if you cannot influence them and they'd start at 1 (say), then the name server might miss out on the updates ODS makes.

Had we had the null (or passthrough, or transparent) encryption algorithm then users could always pass unsigned zones through ODS and let it do its thing with SOA and no matter what, it would all work fine.  That sort of architectural advantage is precisely why we'd love to see this one.  We've been working around this sort of problem over and over, and SOA sequencing is a nasty bit we have had to chew on more than once, while wishing the null signature alg were there.

-Rick

From sara at sinodun.com  Tue Sep 10 16:41:17 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 10 Sep 2013 17:41:17 +0100
Subject: Fwd: [Opendnssec-develop] RE: Team meeting - Tuesday 10 Sept 2013 @
	14:30 CEST
References: <056AD924-5FD8-43B5-A5CC-7CA78A3F8A40@sinodun.com>
Message-ID: <E7537DA0-A092-4B2A-B224-D807A7CEF43D@sinodun.com>

Hi All, 

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

https://wiki.opendnssec.org/display/OpenDNSSEC/2013-09-10+Minutes

Sara.

Begin forwarded message:

> From: Sara Dickinson <sara at sinodun.com>
> Date: 8 September 2013 17:10:20 GMT+01:00
> To: Opd Dev <opendnssec-develop at lists.opendnssec.org>
> Subject: [Opendnssec-develop] RE: Team meeting - Tuesday 10 Sept 2013 @ 14:30 CEST
> 
> Hi All, 
> 
> We have a team meeting on Tuesday this week:
> 
> Date:      Tuesday 10 Sep 2013
> Time:      14:30-15:30 CEST, 13:30-14:30 BST, 20:30 CST, 12:30 UTC
> Method:  Teamspeak. Server name and password are here (requires login):
> https://wiki.opendnssec.org/display/OpenDNSSEC/Conference+call+details
> Agenda: https://wiki.opendnssec.org/display/OpenDNSSEC/2013-09-10+Agenda
> 
> We will give Teamspeak a go this week using the server that Yuri has set up. So please take a minute to set up the client before the meeting. If anyone wants to check they can connect OK then just drop me a line and we can have a short test call anytime. 
> 
> Also - note the change in time to 14:30 CEST as requested by Jerry. 
> 
> 
> Sara.
> 
> 
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130910/4587a4d6/attachment.htm>

From matthijs at nlnetlabs.nl  Wed Sep 11 05:50:42 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Wed, 11 Sep 2013 07:50:42 +0200
Subject: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <97557EE9-C100-4D17-A25F-C26EF95F4E55@openfortress.nl>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
	<97557EE9-C100-4D17-A25F-C26EF95F4E55@openfortress.nl>
Message-ID: <523004B2.4060108@nlnetlabs.nl>

Hi Rick,

On 09/10/2013 05:29 PM, Rick van Rein (OpenFortress) wrote:
> Hi,
> 
>>> Should the signed serial always be higher than the unsigned
>>> serial? #OPENDNSSEC-446 #SUPPORT-73.
>> 
>> I do not agree with the reporter that ODS should follow the
>> unsigned serial.
> 
> Clear statement, and understood.  But you're forgetting something...
> 
>> As an admin you explicitly transfer the management responsibility
>> to ODS.
> 
> To be able to switch OpenDNSSEC on and off (which can really help its
> acceptance) you need to rely on *some* relation between the serials
> coming out; if you cannot influence them and they'd start at 1 (say),
> then the name server might miss out on the updates ODS makes.

The signer keeps zone state on disk in order to achieve this.

> 
> Had we had the null (or passthrough, or transparent) encryption
> algorithm then users could always pass unsigned zones through ODS and
> let it do its thing with SOA and no matter what, it would all work
> fine.  That sort of architectural advantage is precisely why we'd
> love to see this one.  We've been working around this sort of problem
> over and over, and SOA sequencing is a nasty bit we have had to chew
> on more than once, while wishing the null signature alg were there.

Pass-through of unsigned zones has no serial management, so SOA
sequencing is in that scenario not difficult at all.

Best regards,
  Matthijs


> 
> -Rick_______________________________________________ 
> Opendnssec-develop mailing list 
> Opendnssec-develop at lists.opendnssec.org 
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 



From matthijs at nlnetlabs.nl  Wed Sep 11 06:46:12 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Wed, 11 Sep 2013 08:46:12 +0200
Subject: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <522F2ED6.1080103@nlnetlabs.nl>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
Message-ID: <523011B4.8010003@nlnetlabs.nl>

On 09/10/2013 04:38 PM, Yuri Schaeffer wrote:
>> Should the signed serial always be higher than the unsigned serial?
>> #OPENDNSSEC-446 #SUPPORT-73.
> 
> I do not agree with the reporter that ODS should follow the unsigned
> serial. As an admin you explicitly transfer the management
> responsibility to ODS. The way you describe it is now sounds like the
> sanest solution to me. The serial of an unpublished version of the zone
> is not relevant at all.
> 
> //Yuri

I am not sure that the serial of an unpublished version is not relevant
at all. While it is not published, it can be used for operational
practice. The kasp serial 'keep' already implies this.

To me it sounds like the reporter wants something like a cross between
'keep' (have control over the serial) and 'counter' (automatic
resigning). I am not sure if we should satisfy this requirement, and if
so whether we do this by:

* changing the behavior of counter;
* introducing a new serial value 'keepcounter' (name under debate);

The name keepcounter vaguely rings a bell. Ah!:

  https://issues.opendnssec.org/browse/ODSTRACIMPORT-31

It looks like that we have this discussion before. And it looks like we
have implemented this when reading the unsigned zone (not when doing an
automatic re-sign).

I'm going back to the reporter.

Best regards,
  Matthijs






From wanggd at conac.cn  Wed Sep 11 07:15:46 2013
From: wanggd at conac.cn (wangguodong)
Date: Wed, 11 Sep 2013 15:15:46 +0800
Subject: reply: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <522F2ED6.1080103@nlnetlabs.nl>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
Message-ID: <002401ceaebe$bc57c110$35074330$@cn>

Hi,

I think there is a relationship between the signed zone and unsigned zone. 

Because in the NEWG TLD applicant Guidebook, the registry's zone file should
be accessed by a third party.( AGB SPECIFICATION 4,P43)
	   
So if a third party get an unsigned zone, the unsigned zone's serial is
higher than the current signed zone(can be dug from the internet), this may
be a problem.

So as this, I think it's better to ensure the signed zone's serial higher
than the unsigned zone.


Warren

-----????-----
???: opendnssec-develop-bounces at lists.opendnssec.org
[mailto:opendnssec-develop-bounces at lists.opendnssec.org] ?? Yuri Schaeffer
????: 2013?9?10? 22:38
???: opendnssec-develop at lists.opendnssec.org
??: Re: [Opendnssec-develop] signed serial > unsigned serial?

> Should the signed serial always be higher than the unsigned serial?
> #OPENDNSSEC-446 #SUPPORT-73.

I do not agree with the reporter that ODS should follow the unsigned serial.
As an admin you explicitly transfer the management responsibility to ODS.
The way you describe it is now sounds like the sanest solution to me. The
serial of an unpublished version of the zone is not relevant at all.

//Yuri

--
Composed on an actual keyboard: all typos genuine.
_______________________________________________
Opendnssec-develop mailing list
Opendnssec-develop at lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop




From jakob at kirei.se  Wed Sep 11 07:26:48 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 11 Sep 2013 09:26:48 +0200
Subject: reply: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <002401ceaebe$bc57c110$35074330$@cn>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
	<002401ceaebe$bc57c110$35074330$@cn>
Message-ID: <8077AD2E-AF53-43D9-8155-0E4F97A40B43@kirei.se>

On 11 sep 2013, at 09:15, "wangguodong" <wanggd at conac.cn> wrote:

> Because in the NEWG TLD applicant Guidebook, the registry's zone file should
> be accessed by a third party.( AGB SPECIFICATION 4,P43)

Is the 3rd party zone access for an unsigned or signed zone?

> So if a third party get an unsigned zone, the unsigned zone's serial is
> higher than the current signed zone(can be dug from the internet), this may
> be a problem.

I don't think is a real problem, but I do agree it might look strange. I also believe the signed zone serial should always be equal or higher than the unsigned version.

> So as this, I think it's better to ensure the signed zone's serial higher
> than the unsigned zone.

I agree.


	jakob


From jerry at opendnssec.org  Wed Sep 11 08:01:46 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 11 Sep 2013 10:01:46 +0200
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
Message-ID: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>

Hi,

Since now that the database is the true source of the zone list how about
we simple remove the zonelist.xml from the configuration directory.

This will clearly indicate that the zonelist.xml file is no longer of any
relevance.

This would require a small change to setup, namely that it does not expect
a zonelist.xml but should be able to take one via command line option.

There should also be an export and import command for the zone list, export
already exists and maybe import also does.

Comments?

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/384051c2/attachment.htm>

From matthijs at nlnetlabs.nl  Wed Sep 11 08:08:12 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Wed, 11 Sep 2013 10:08:12 +0200
Subject: reply: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <8077AD2E-AF53-43D9-8155-0E4F97A40B43@kirei.se>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
	<002401ceaebe$bc57c110$35074330$@cn>
	<8077AD2E-AF53-43D9-8155-0E4F97A40B43@kirei.se>
Message-ID: <523024EC.3060601@nlnetlabs.nl>

On 09/11/2013 09:26 AM, Jakob Schlyter wrote:
> On 11 sep 2013, at 09:15, "wangguodong" <wanggd at conac.cn> wrote:
> 
>> Because in the NEWG TLD applicant Guidebook, the registry's zone file should
>> be accessed by a third party.( AGB SPECIFICATION 4,P43)
> 
> Is the 3rd party zone access for an unsigned or signed zone?
> 
>> So if a third party get an unsigned zone, the unsigned zone's serial is
>> higher than the current signed zone(can be dug from the internet), this may
>> be a problem.
> 
> I don't think is a real problem, but I do agree it might look strange. I also believe the signed zone serial should always be equal or higher than the unsigned version.

I don't like having functionality that polls the serial from the
unsigned zone to verify that the upcoming signed serial is higher than
the unsigned serial. So *always* is problematic for me. It's okay when
you already reading the unsigned zone. That is also more in line with
our requirement to only read the unsigned zone upon manual request (e.g.
sign command).

Best regards,
  Matthijs

> 
>> So as this, I think it's better to ensure the signed zone's serial higher
>> than the unsigned zone.
> 
> I agree.
> 
> 
> 	jakob
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 



From wanggd at conac.cn  Wed Sep 11 08:14:12 2013
From: wanggd at conac.cn (wangguodong)
Date: Wed, 11 Sep 2013 16:14:12 +0800
Subject: reply: reply: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <8077AD2E-AF53-43D9-8155-0E4F97A40B43@kirei.se>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
	<002401ceaebe$bc57c110$35074330$@cn>
	<8077AD2E-AF53-43D9-8155-0E4F97A40B43@kirei.se>
Message-ID: <003401ceaec6$e5eff8f0$b1cfead0$@cn>



-----????-----
???: Jakob Schlyter [mailto:jakob at kirei.se] 
????: 2013?9?11? 15:27
???: wangguodong
??: 'Yuri Schaeffer'; opendnssec-develop at lists.opendnssec.org
??: Re: reply: [Opendnssec-develop] signed serial > unsigned serial?

>On 11 sep 2013, at 09:15, "wangguodong" <wanggd at conac.cn> wrote:

>> Because in the NEWG TLD applicant Guidebook, the registry's zone file 
>> should be accessed by a third party.( AGB SPECIFICATION 4,P43)

>Is the 3rd party zone access for an unsigned or signed zone?


The AGB mentions the unsigned zone should be accessed by a third party. I
have copy the relative content below:

2. Zone File Access
2.1. Third-Party Access
2.1.1. Zone File Access Agreement. Registry Operator will enter into an
agreement with
any Internet user that will allow such user to access an Internet host
server or servers designated by
Registry Operator and download zone file data. The agreement will be
standardized, facilitated and
administered by a Centralized Zone Data Access Provider (the ?CZDA
Provider?). Registry Operator
will provide access to zone file data per Section 2.1.3 and do so using the
file format described in Section
2.1.4. Notwithstanding the foregoing, (a) the CZDA Provider may reject the
request for access of any
user that does not satisfy the credentialing requirements in Section 2.1.2
below; (b) Registry Operator
may reject the request for access of any user that does not provide correct
or legitimate credentials under
Section 2.1. 2 or where Registry Operator reasonably believes will violate
the terms of Section 2.1.5.
below; and, (c) Registry Operator may revoke access of any user if Registry
Operator has evidence to
support that the user has violated the terms of Section 2.1.5.
2.1.2. Credentialing Requirements. Registry Operator, through the
facilitation of the
CZDA Provider, will request each user to provide it with information
sufficient to correctly identify and
locate the user. Such user information will include, without limitation,
company name, contact name,
address, telephone number, facsimile number, email address, and the Internet
host machine name and IP
address.
2.1.3. Grant of Access. Each Registry Operator will provide the Zone File
FTP (or other
Registry supported) service for an ICANN-specified and managed URL
(specifically,
<TLD>.zda.icann.org where <TLD> is the TLD for which the registry is
responsible) for the user to
access the Registry?s zone data archives. Registry Operator will grant the
user a non-exclusive, nontransferable,
limited right to access Registry Operator?s Zone File FTP server, and to
transfer a copy of
the top-level domain zone files, and any associated cryptographic checksum
files no more than once per
24 hour period using FTP, or other data transport and access protocols that
may be prescribed by
ICANN. For every zone file access server, the zone files are in the
top-level directory called
<zone>.zone.gz, with <zone>.zone.gz.md5 and <zone>.zone.gz.sig to verify
downloads. If the Registry
Operator also provides historical data, it will use the naming pattern
<zone>-yyyymmdd.zone.gz, etc.
2.1.4. File Format Standard. Registry Operator will provide zone files using
a subformat
of the standard Master File format as originally defined in RFC 1035,
Section 5, including all the
records present in the actual zone used in the public DNS. Sub-format is as
follows:
1. Each record must include all fields in one line as: <domain-name> <TTL>
<class> <type>
<RDATA>.
2. Class and Type must use the standard mnemonics and must be in lower case.
43
NEW GTLD AGREEMENT SPECIFICATIONS
3. TTL must be present as a decimal integer.
4. Use of /X and /DDD inside domain names is allowed.
5. All domain names must be in lower case.
6. Must use exactly one tab as separator of fields inside a record.
7. All domain names must be fully qualified.
8. No $ORIGIN directives.
9. No use of "@" to denote current origin.
10. No use of "blank domain names" at the beginning of a record to continue
the use of the domain
name in the previous record.
11. No $INCLUDE directives.
12. No $TTL directives.
13. No use of parentheses, e.g., to continue the list of fields in a record
across a line boundary.
14. No use of comments.
15. No blank lines.
16. The SOA record should be present at the top and (duplicated at) the end
of the zone file.
17. With the exception of the SOA record, all the records in a file must be
in alphabetical order.
18. One zone per file. If a TLD divides its DNS data into multiple zones,
each goes into a separate
file named as above, with all the files combined using tar into a file
called <tld>.zone.tar.
2.1.5. Use of Data by User. Registry Operator will permit user to use the
zone file for
lawful purposes; provided that, (a) user takes all reasonable steps to
protect against unauthorized access to
and use and disclosure of the data, and (b) under no circumstances will
Registry Operator be required or
permitted to allow user to use the data to, (i) allow, enable, or otherwise
support the transmission by email,
telephone, or facsimile of mass unsolicited, commercial advertising or
solicitations to entities other
than user?s own existing customers, or (ii) enable high volume, automated,
electronic processes that send
queries or data to the systems of Registry Operator or any ICANN-accredited
registrar.
2.1.6. Term of Use. Registry Operator, through CZDA Provider, will provide
each user
with access to the zone file for a period of not less than three (3) months.
Registry Operator will allow
users to renew their Grant of Access.
2.1.7. No Fee for Access. Registry Operator will provide, and CZDA Provider
will
facilitate, access to the zone file to user at no cost.

>> So if a third party get an unsigned zone, the unsigned zone's serial 
>> is higher than the current signed zone(can be dug from the internet), 
>> this may be a problem.

>I don't think is a real problem, but I do agree it might look strange. I
also believe the signed zone serial should always be equal or higher than
the unsigned version.

>> So as this, I think it's better to ensure the signed zone's serial 
>>higher than the unsigned zone.

>I agree.


>	jakob




From jerry at opendnssec.org  Wed Sep 11 08:29:51 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 11 Sep 2013 10:29:51 +0200
Subject: [Opendnssec-develop] Release of OpenDNSSEC 1.4.2 and the failing
	tests
Message-ID: <CAGTFMNY_FfHkDd3Hqh-U3FM7E0OpECO1yooUEOM+1ybBx_x4yA@mail.gmail.com>

Hi,

Should the failing tests in Jenkins block 1.4.2 release?

We have a policy that tests in Jenkins should pass before we do a release
but I don't know if the test if failing because of software problems or if
the test isn't functional yet.

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/94827276/attachment.htm>

From yuri at nlnetlabs.nl  Wed Sep 11 08:41:39 2013
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Wed, 11 Sep 2013 10:41:39 +0200
Subject: [Opendnssec-develop] signed serial > unsigned serial?
In-Reply-To: <97557EE9-C100-4D17-A25F-C26EF95F4E55@openfortress.nl>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
	<97557EE9-C100-4D17-A25F-C26EF95F4E55@openfortress.nl>
Message-ID: <52302CC3.20105@nlnetlabs.nl>

On 09/10/2013 05:29 PM, Rick van Rein (OpenFortress) wrote:
> Clear statement, and understood.  But you're forgetting something...

Well, starting a discussion with a bold statement works *so* much better
than nuance. ;)


From olaf at NLnetLabs.nl  Wed Sep 11 08:45:18 2013
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Wed, 11 Sep 2013 10:45:18 +0200
Subject: [Opendnssec-develop] Release of OpenDNSSEC 1.4.2 and the failing
	tests
In-Reply-To: <CAGTFMNY_FfHkDd3Hqh-U3FM7E0OpECO1yooUEOM+1ybBx_x4yA@mail.gmail.com>
References: <CAGTFMNY_FfHkDd3Hqh-U3FM7E0OpECO1yooUEOM+1ybBx_x4yA@mail.gmail.com>
Message-ID: <B55E5718-F3F3-4274-B97C-E247B18B47DB@NLnetLabs.nl>


On 11 sep. 2013, at 10:29, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> 
> Should the failing tests in Jenkins block 1.4.2 release?


Yes!

> 
> We have a policy that tests in Jenkins should pass before we do a release but I don't know if the test if failing because of software problems or if the test isn't functional yet.
> 


Nuance: If you have clearly identified and checked that there is a bug in the test then it is ok to ignore the test. But as long as you have failing test without understanding: Block.

That is why we do tests in the first place.

--Olaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/d6b610a7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/d6b610a7/attachment.bin>

From jerry at opendnssec.org  Wed Sep 11 08:52:41 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 11 Sep 2013 10:52:41 +0200
Subject: [Opendnssec-develop] Release of OpenDNSSEC 1.4.2 and the failing
	tests
In-Reply-To: <B55E5718-F3F3-4274-B97C-E247B18B47DB@NLnetLabs.nl>
References: <CAGTFMNY_FfHkDd3Hqh-U3FM7E0OpECO1yooUEOM+1ybBx_x4yA@mail.gmail.com>
	<B55E5718-F3F3-4274-B97C-E247B18B47DB@NLnetLabs.nl>
Message-ID: <CAGTFMNabrAWKF9j3msnpYGiAoZx2-X79sRfWpHjtj4=oKW+6yw@mail.gmail.com>

On Wed, Sep 11, 2013 at 10:45 AM, Olaf Kolkman <olaf at nlnetlabs.nl> wrote:

> Nuance: If you have clearly identified and checked that there is a bug in
> the test then it is ok to ignore the test. But as long as you have failing
> test without understanding: Block.
>

Yes I know, I was more asking about it to get more background information
since I've been gone from this project for some time now.

The test in question is enforcer.keys.generate, failing on two platforms.

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/fa44eadd/attachment.htm>

From olaf at NLnetLabs.nl  Wed Sep 11 08:56:19 2013
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Wed, 11 Sep 2013 10:56:19 +0200
Subject: [Opendnssec-develop] Release of OpenDNSSEC 1.4.2 and the failing
	tests
In-Reply-To: <CAGTFMNabrAWKF9j3msnpYGiAoZx2-X79sRfWpHjtj4=oKW+6yw@mail.gmail.com>
References: <CAGTFMNY_FfHkDd3Hqh-U3FM7E0OpECO1yooUEOM+1ybBx_x4yA@mail.gmail.com>
	<B55E5718-F3F3-4274-B97C-E247B18B47DB@NLnetLabs.nl>
	<CAGTFMNabrAWKF9j3msnpYGiAoZx2-X79sRfWpHjtj4=oKW+6yw@mail.gmail.com>
Message-ID: <62C59964-0DD9-41D7-AB19-99D9FAAC5EC1@NLnetLabs.nl>


On 11 sep. 2013, at 10:52, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> On Wed, Sep 11, 2013 at 10:45 AM, Olaf Kolkman <olaf at nlnetlabs.nl> wrote:
> Nuance: If you have clearly identified and checked that there is a bug in the test then it is ok to ignore the test. But as long as you have failing test without understanding: Block.
> 
> Yes I know, I was more asking about it to get more background information since I've been gone from this project for some time now.
> 
> The test in question is enforcer.keys.generate, failing on two platforms.


Aha, sorry, I misunderstood that you were actually saying:
   Pending an answer to why these tests fail we cannot release, please help!

--Olaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/78195845/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/78195845/attachment.bin>

From jerry at opendnssec.org  Wed Sep 11 09:04:39 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 11 Sep 2013 11:04:39 +0200
Subject: [Opendnssec-develop] Release of OpenDNSSEC 1.4.2 and the failing
	tests
In-Reply-To: <62C59964-0DD9-41D7-AB19-99D9FAAC5EC1@NLnetLabs.nl>
References: <CAGTFMNY_FfHkDd3Hqh-U3FM7E0OpECO1yooUEOM+1ybBx_x4yA@mail.gmail.com>
	<B55E5718-F3F3-4274-B97C-E247B18B47DB@NLnetLabs.nl>
	<CAGTFMNabrAWKF9j3msnpYGiAoZx2-X79sRfWpHjtj4=oKW+6yw@mail.gmail.com>
	<62C59964-0DD9-41D7-AB19-99D9FAAC5EC1@NLnetLabs.nl>
Message-ID: <CAGTFMNZy5pAUHqfmnvrBzFYxTPKB0TJaT+9Hx722a7A319711Q@mail.gmail.com>

On Wed, Sep 11, 2013 at 10:56 AM, Olaf Kolkman <olaf at nlnetlabs.nl> wrote:

>
> Aha, sorry, I misunderstood that you were actually saying:
>    Pending an answer to why these tests fail we cannot release, please
> help!
>

More or less, yes. Sorry if I was unclear.

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/2c3f422c/attachment.htm>

From olaf at NLnetLabs.nl  Wed Sep 11 09:18:01 2013
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Wed, 11 Sep 2013 11:18:01 +0200
Subject: [Opendnssec-develop] Release of OpenDNSSEC 1.4.2 and the failing
	tests
In-Reply-To: <CAGTFMNZy5pAUHqfmnvrBzFYxTPKB0TJaT+9Hx722a7A319711Q@mail.gmail.com>
References: <CAGTFMNY_FfHkDd3Hqh-U3FM7E0OpECO1yooUEOM+1ybBx_x4yA@mail.gmail.com>
	<B55E5718-F3F3-4274-B97C-E247B18B47DB@NLnetLabs.nl>
	<CAGTFMNabrAWKF9j3msnpYGiAoZx2-X79sRfWpHjtj4=oKW+6yw@mail.gmail.com>
	<62C59964-0DD9-41D7-AB19-99D9FAAC5EC1@NLnetLabs.nl>
	<CAGTFMNZy5pAUHqfmnvrBzFYxTPKB0TJaT+9Hx722a7A319711Q@mail.gmail.com>
Message-ID: <4F48836C-2D9F-454F-9880-0DE85E2B2EDE@NLnetLabs.nl>


On 11 sep. 2013, at 11:04, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> On Wed, Sep 11, 2013 at 10:56 AM, Olaf Kolkman <olaf at nlnetlabs.nl> wrote:
> 
> Aha, sorry, I misunderstood that you were actually saying:
>    Pending an answer to why these tests fail we cannot release, please help!
> 
> More or less, yes. Sorry if I was unclear.

On the users list somebody is looking for the release. I would respond: 

A plan is a plan, until it fails.

As part of the release engineering process we do a large number of tests. Some of these tests failed on some platform. Pending the understanding of the root-cause we are delaying release.


(But now I am micromanaging things that I should not be managing :-) ) 

--Olaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/64ea3831/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/64ea3831/attachment.bin>

From sara at sinodun.com  Wed Sep 11 09:37:33 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 11 Sep 2013 10:37:33 +0100
Subject: [Opendnssec-develop] Release of OpenDNSSEC 1.4.2 and the failing
	tests
In-Reply-To: <4F48836C-2D9F-454F-9880-0DE85E2B2EDE@NLnetLabs.nl>
References: <CAGTFMNY_FfHkDd3Hqh-U3FM7E0OpECO1yooUEOM+1ybBx_x4yA@mail.gmail.com>
	<B55E5718-F3F3-4274-B97C-E247B18B47DB@NLnetLabs.nl>
	<CAGTFMNabrAWKF9j3msnpYGiAoZx2-X79sRfWpHjtj4=oKW+6yw@mail.gmail.com>
	<62C59964-0DD9-41D7-AB19-99D9FAAC5EC1@NLnetLabs.nl>
	<CAGTFMNZy5pAUHqfmnvrBzFYxTPKB0TJaT+9Hx722a7A319711Q@mail.gmail.com>
	<4F48836C-2D9F-454F-9880-0DE85E2B2EDE@NLnetLabs.nl>
Message-ID: <359A8C6D-EE0B-409B-B63A-13511C408C85@sinodun.com>

Hi All, 

Sorry - I wasn't in the office this morning. The test failures are due to changes to the test scripts I made on Monday. I thought I had fixed this yesterday but clearly not (but will do so now). However I have no problem with the release going out as I understand exactly why these tests are failing. 

Jerry - everything is up to date in the branch so please go ahead with the release. 

Sara.

On 11 Sep 2013, at 10:18, Olaf Kolkman wrote:

> 
> On 11 sep. 2013, at 11:04, Jerry Lundstr?m <jerry at opendnssec.org> wrote:
> 
>> On Wed, Sep 11, 2013 at 10:56 AM, Olaf Kolkman <olaf at nlnetlabs.nl> wrote:
>> 
>> Aha, sorry, I misunderstood that you were actually saying:
>>    Pending an answer to why these tests fail we cannot release, please help!
>> 
>> More or less, yes. Sorry if I was unclear.
> 
> On the users list somebody is looking for the release. I would respond: 
> 
> A plan is a plan, until it fails.
> 
> As part of the release engineering process we do a large number of tests. Some of these tests failed on some platform. Pending the understanding of the root-cause we are delaying release.
> 
> 
> (But now I am micromanaging things that I should not be managing :-) ) 
> 
> --Olaf



From jakob at kirei.se  Wed Sep 11 11:49:58 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 11 Sep 2013 13:49:58 +0200
Subject: reply: reply: [Opendnssec-develop] signed serial > unsigned
	serial?
In-Reply-To: <003401ceaec6$e5eff8f0$b1cfead0$@cn>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
	<002401ceaebe$bc57c110$35074330$@cn>
	<8077AD2E-AF53-43D9-8155-0E4F97A40B43@kirei.se>
	<003401ceaec6$e5eff8f0$b1cfead0$@cn>
Message-ID: <15458B49-E553-455D-8D87-4FBB7DF9C937@kirei.se>

I cannot see where the AGB states it is the unsigned zone that is to be served.

	jakob



From olaf at NLnetLabs.nl  Wed Sep 11 12:22:42 2013
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Wed, 11 Sep 2013 14:22:42 +0200
Subject: reply: reply: [Opendnssec-develop] signed serial > unsigned
	serial?
In-Reply-To: <15458B49-E553-455D-8D87-4FBB7DF9C937@kirei.se>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
	<002401ceaebe$bc57c110$35074330$@cn>
	<8077AD2E-AF53-43D9-8155-0E4F97A40B43@kirei.se>
	<003401ceaec6$e5eff8f0$b1cfead0$@cn>
	<15458B49-E553-455D-8D87-4FBB7DF9C937@kirei.se>
Message-ID: <C06EFF72-220D-43C9-9926-C7BFC75B1BEB@NLnetLabs.nl>


On 11 sep. 2013, at 13:49, Jakob Schlyter <jakob at kirei.se> wrote:

> I cannot see where the AGB states it is the unsigned zone that is to be served.

Me neither, nor do I understand why the AGB would call for a zone different from the zone that appeared in the DNS.

If ICANN where to clarify that the AGB should be interpreted that an unsigned zone is to be served then I would like to see the motivation for that requirement.

--Olaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/1106f906/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/1106f906/attachment.bin>

From sara at sinodun.com  Wed Sep 11 12:46:18 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 11 Sep 2013 13:46:18 +0100
Subject: [Opendnssec-develop] OpenDNSSEC 1.4.2
Message-ID: <FF018B05-02EB-449F-A800-70C78CC5B4AC@sinodun.com>

All, 

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

Updates:

* OPENDNSSEC-428: ods-ksmutil: Add option for 'ods-ksmutil key generate' to take number of zones as a parameter

Bugfixes:

* SUPPORT-66: Signer Engine: Fix file descriptor leak in case of TCP write error [OPENDNSSEC-427].
* SUPPORT-71: Signer Engine: Fix double free crash in case of HSM connection error during signing [OPENDNSSEC-444].
* OPENDNSSEC-401: 'ods-signer sign <zone> --serial <nr>' command produces seg fault when run directly on command line (i.e. not via interactive mode)
* OPENDNSSEC-440: 'ods-ksmutil key generate' and the enforcer can create too many keys if there are keys already available and the KSK and ZSK use same algorithm and length
* OPENDNSSEC-424: Signer Engine: Respond to SOA queries from file instead of memory. Makes response non-blocking.
* OPENDNSSEC-425 Change "hsmutil list" output so that the table header goes to stdout not stderr
* OPENDNSSEC-438: 'ods-ksmutil key generate' and the enforcer can create too many keys for <SharedKeys/> policies when KSK and ZSK use same algorithm and length
* OPENDNSSEC-443: ods-ksmutil: Clean up of hsm connection handling
* Signer Engine: Improved Inbound XFR checking.
* Signer Engine: Fix double free corruption in case of adding zone with DNS Outbound Adapters and NotifyCommand enabled.

Documentation:

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

Download:

* http://dist.opendnssec.org/source/opendnssec-1.4.2.tar.gz
* http://dist.opendnssec.org/source/opendnssec-1.4.2.tar.gz.sig
* Checksum sha1: 82991f3110820ec0b12608fd3175bb70252a6f2b
* Checksum sha256: b4bc70bfb54ede8ed657cc7f669b5f58bc5e20eabf9b01ca107a6876b08bed35


//OpenDNSSEC team




From sion at nominet.org.uk  Wed Sep 11 13:22:08 2013
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Wed, 11 Sep 2013 14:22:08 +0100
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
Message-ID: <52306E80.1060706@nominet.org.uk>

On 11/09/13 09:01, Jerry Lundstr?m wrote:
> Hi,
>
> Since now that the database is the true source of the zone list how
> about we simple remove the zonelist.xml from the configuration directory.
>
> This will clearly indicate that the zonelist.xml file is no longer of
> any relevance.
>
> This would require a small change to setup, namely that it does not
> expect a zonelist.xml but should be able to take one via command line
> option.
>
> There should also be an export and import command for the zone list,
> export already exists and maybe import also does.
>
> Comments?
>

It certainly seems reasonable that if zonelist.xml is not a
configuration file then it should not be in the configuration directory.

Should we still include an example zonelist as a way of initialising the
system? Would we still want all the schema checking code for this file?
(I'm guessing yes to both.)

Sion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/c14e2b86/attachment.htm>

From jerry at opendnssec.org  Wed Sep 11 13:30:47 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 11 Sep 2013 15:30:47 +0200
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <52306E80.1060706@nominet.org.uk>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
	<52306E80.1060706@nominet.org.uk>
Message-ID: <CAGTFMNa0oEr2jqpgBVh5cZ7JE-3jca4NK-sRdb-gwZ0ampzNyQ@mail.gmail.com>

On Wed, Sep 11, 2013 at 3:22 PM, Si?n Lloyd <sion at nominet.org.uk> wrote:

> Should we still include an example zonelist as a way of initialising the
> system? Would we still want all the schema checking code for this file?
> (I'm guessing yes to both.)
>

Yes, it would be the best since we use a XML based zone list on
export/import/setup we should also include a example file and do schema
checking.

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130911/94996069/attachment.htm>

From matthijs at nlnetlabs.nl  Wed Sep 11 13:39:13 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Wed, 11 Sep 2013 15:39:13 +0200
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <52306E80.1060706@nominet.org.uk>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
	<52306E80.1060706@nominet.org.uk>
Message-ID: <52307281.5000000@nlnetlabs.nl>

On 09/11/2013 03:22 PM, Si?n Lloyd wrote:
> On 11/09/13 09:01, Jerry Lundstr?m wrote:
>> Hi,
>>
>> Since now that the database is the true source of the zone list how
>> about we simple remove the zonelist.xml from the configuration directory.
>>
>> This will clearly indicate that the zonelist.xml file is no longer of
>> any relevance.
>>
>> This would require a small change to setup, namely that it does not
>> expect a zonelist.xml but should be able to take one via command line
>> option.
>>
>> There should also be an export and import command for the zone list,
>> export already exists and maybe import also does.
>>
>> Comments?
>>
> 
> It certainly seems reasonable that if zonelist.xml is not a
> configuration file then it should not be in the configuration directory.
> 
> Should we still include an example zonelist as a way of initialising the
> system? Would we still want all the schema checking code for this file?
> (I'm guessing yes to both.)

I am guessing yes to both as well. Only the database becomes
authoritative and the signer would read the zonelist file from a var
directory (signconf?) that is created by the enforcer.

Best regards,
  Matthijs


> 
> Sion
> 
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 



From sara at sinodun.com  Wed Sep 11 18:26:23 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 11 Sep 2013 19:26:23 +0100
Subject: [Opendnssec-develop] OpenDNSSEC 1.3.15 release candidate
Message-ID: <FEF9F90E-E164-4F7B-BCB6-67937FEC6A31@sinodun.com>

All, 

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


OpenDNSSEC 1.3.15rc1
----------------------------------

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-423].
* OPENDNSSEC-428: Add option for 'ods-ksmutil key generate' to take total number of zones as a parameter
* OPENDNSSEC-448: Signer Engine: Enhancements to signer debug locks.

Bugfixes:
* SUPPORT-75: Signer Engine: Fix double free crash in case of HSM connection error during signing [OPENDNSSEC-452].
* OPENDNSSEC-397: Change "hsmutil list" output so that the table header goes to stdout not stderr
* OPENDNSSEC-438: 'ods-ksmutil key generate' and the enforcer can create too many keys for <SharedKeys/> policies when KSK and ZSK use same  algorithm and length
* OPENDNSSEC-445: ods-ksmutil: Clean up of hsm connection handling

Download: 
* http://dist.opendnssec.org/source/testing/opendnssec-1.3.15rc1.tar.gz
* http://dist.opendnssec.org/source/testing/opendnssec-1.3.15rc1.tar.gz.sig
* Checksum sha1: ee5f7b68968311104dbc1432470bc8ca920b8e7c
* Checksum sah256:  5178e33bc17171f20ec0c26bd7240e8352b5a66f299bd771f8e2d07888cdb59a


A full 1.3.15 release is planned for Wednesday 18th September.

// OpenDNSSEC team




From jakob at kirei.se  Wed Sep 11 19:31:44 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 11 Sep 2013 21:31:44 +0200
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <52307281.5000000@nlnetlabs.nl>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
	<52306E80.1060706@nominet.org.uk> <52307281.5000000@nlnetlabs.nl>
Message-ID: <F7F79EFD-5281-4B32-9B14-24640895D619@kirei.se>

On 11 sep 2013, at 15:39, Matthijs Mekking <matthijs at NLnetLabs.nl> wrote:

> I am guessing yes to both as well. Only the database becomes
> authoritative and the signer would read the zonelist file from a var
> directory (signconf?) that is created by the enforcer.

When will the enforcer update/write the zone list file aimed for the signer? Not at every add/delete zone, that's for sure. Or should be look at having shared database? Or one file per zone (remove zone will remove file)?

	jakob

-- 
Jakob Schlyter
Kirei AB - www.kirei.se





From matthijs at nlnetlabs.nl  Thu Sep 12 07:55:23 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Thu, 12 Sep 2013 09:55:23 +0200
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <F7F79EFD-5281-4B32-9B14-24640895D619@kirei.se>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
	<52306E80.1060706@nominet.org.uk> <52307281.5000000@nlnetlabs.nl>
	<F7F79EFD-5281-4B32-9B14-24640895D619@kirei.se>
Message-ID: <5231736B.1090902@nlnetlabs.nl>

On 09/11/2013 09:31 PM, Jakob Schlyter wrote:
> On 11 sep 2013, at 15:39, Matthijs Mekking <matthijs at NLnetLabs.nl> wrote:
> 
>> I am guessing yes to both as well. Only the database becomes
>> authoritative and the signer would read the zonelist file from a var
>> directory (signconf?) that is created by the enforcer.
> 
> When will the enforcer update/write the zone list file aimed for the signer? Not at every add/delete zone, that's for sure. Or should be look at having shared database? Or one file per zone (remove zone will remove file)?

During the commit transaction.

> 
> 	jakob
> 



From sion at nominet.org.uk  Thu Sep 12 08:07:58 2013
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Thu, 12 Sep 2013 09:07:58 +0100
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <F7F79EFD-5281-4B32-9B14-24640895D619@kirei.se>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
	<52306E80.1060706@nominet.org.uk> <52307281.5000000@nlnetlabs.nl>
	<F7F79EFD-5281-4B32-9B14-24640895D619@kirei.se>
Message-ID: <5231765E.7040407@nominet.org.uk>

On 11/09/13 20:31, Jakob Schlyter wrote:
> On 11 sep 2013, at 15:39, Matthijs Mekking <matthijs at NLnetLabs.nl> wrote:
>
>> I am guessing yes to both as well. Only the database becomes
>> authoritative and the signer would read the zonelist file from a var
>> directory (signconf?) that is created by the enforcer.
> When will the enforcer update/write the zone list file aimed for the signer? Not at every add/delete zone, that's for sure. Or should be look at having shared database? Or one file per zone (remove zone will remove file)?
>
> 	jakob
>

One file per zone could work; we could add the config information that
the signer needs for the adapters, etc. to the signconf files.

Sion


From jerry at opendnssec.org  Thu Sep 12 08:15:22 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 12 Sep 2013 10:15:22 +0200
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <5231765E.7040407@nominet.org.uk>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
	<52306E80.1060706@nominet.org.uk> <52307281.5000000@nlnetlabs.nl>
	<F7F79EFD-5281-4B32-9B14-24640895D619@kirei.se>
	<5231765E.7040407@nominet.org.uk>
Message-ID: <-2954920784596733667@unknownmsgid>

On 12 sep 2013, at 10:08, "Si?n Lloyd" <sion at nominet.org.uk> wrote:

> One file per zone could work

We need to think more about this.

There are limits to the number of files in a single directory for
about half of the filesystems and the most common one (ext*).

> we could add the config information that
> the signer needs for the adapters, etc. to the signconf files.

Yes, we should add all nessesary configuration for a zone in the same space.

/Jerry


From wanggd at conac.cn  Thu Sep 12 08:15:44 2013
From: wanggd at conac.cn (wangguodong)
Date: Thu, 12 Sep 2013 16:15:44 +0800
Subject: reply: reply: reply: [Opendnssec-develop] signed serial > unsigned
	serial?
In-Reply-To: <C06EFF72-220D-43C9-9926-C7BFC75B1BEB@NLnetLabs.nl>
References: <522F182F.60407@nlnetlabs.nl> <522F2ED6.1080103@nlnetlabs.nl>
	<002401ceaebe$bc57c110$35074330$@cn>
	<8077AD2E-AF53-43D9-8155-0E4F97A40B43@kirei.se>
	<003401ceaec6$e5eff8f0$b1cfead0$@cn>
	<15458B49-E553-455D-8D87-4FBB7DF9C937@kirei.se>
	<C06EFF72-220D-43C9-9926-C7BFC75B1BEB@NLnetLabs.nl>
Message-ID: <003601ceaf90$47268020$d5738060$@cn>

 

Yes, you are right.  It's not restrict an unsigned zone or signed zone.

 

I am sorry for that.

 

The zone can be accessed by a third party such as the data escrow provider,
so unsigned zone may be also useful.

 

 

Warren

 

???: Olaf Kolkman [mailto:olaf at NLnetLabs.nl] 
????: 2013?9?11? 20:23
???: Jakob Schlyter
??: wangguodong; opendnssec-develop at lists.opendnssec.org
??: Re: reply: reply: [Opendnssec-develop] signed serial > unsigned
serial?

 

 

On 11 sep. 2013, at 13:49, Jakob Schlyter <jakob at kirei.se> wrote:





I cannot see where the AGB states it is the unsigned zone that is to be
served.

 

Me neither, nor do I understand why the AGB would call for a zone different
from the zone that appeared in the DNS.

 

If ICANN where to clarify that the AGB should be interpreted that an
unsigned zone is to be served then I would like to see the motivation for
that requirement.

 

--Olaf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130912/e3942cd2/attachment.htm>

From sion at nominet.org.uk  Thu Sep 12 08:30:41 2013
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Thu, 12 Sep 2013 09:30:41 +0100
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <-2954920784596733667@unknownmsgid>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
	<52306E80.1060706@nominet.org.uk> <52307281.5000000@nlnetlabs.nl>
	<F7F79EFD-5281-4B32-9B14-24640895D619@kirei.se>
	<5231765E.7040407@nominet.org.uk>
	<-2954920784596733667@unknownmsgid>
Message-ID: <52317BB1.8050409@nominet.org.uk>

On 12/09/13 09:15, Jerry Lundstr?m wrote:
> On 12 sep 2013, at 10:08, "Si?n Lloyd" <sion at nominet.org.uk> wrote:
>
>> One file per zone could work
> We need to think more about this.
>
> There are limits to the number of files in a single directory for
> about half of the filesystems and the most common one (ext*).
>

This is true, although they are much higher than we might reasonably
expect to be using. There is also a performance hit and you run into
issues if you try to use shell expansion.

>> we could add the config information that
>> the signer needs for the adapters, etc. to the signconf files.
> Yes, we should add all nessesary configuration for a zone in the same space.
>
> /Jerry



From wanggd at conac.cn  Thu Sep 12 09:01:27 2013
From: wanggd at conac.cn (wangguodong)
Date: Thu, 12 Sep 2013 17:01:27 +0800
Subject: reply: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <-2954920784596733667@unknownmsgid>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>	<52306E80.1060706@nominet.org.uk>
	<52307281.5000000@nlnetlabs.nl>	<F7F79EFD-5281-4B32-9B14-24640895D619@kirei.se>	<5231765E.7040407@nominet.org.uk>
	<-2954920784596733667@unknownmsgid>
Message-ID: <004101ceaf96$aa2ceff0$fe86cfd0$@cn>



If we remove the zonelist configuration file, there may be some disadvantages:

1. It's not very friendly for the users because it's inconsistent for the configuration. some from the files, and some from database.
  
2. No obvious convenience.
Now we update the zonelist file then execute the update command.
After changed, we should export -> edit -> import, may be more steps.

If we base on the database not the configuration files, the configuration based on web may be more friendly for users.


Besides, 
The communication method between enforcer and signer is not very good for thousands of zones scenes.
Because there are so many files. If there are more than one thounsand files under a file, the OS's search speed would slow down.
 
Jakob mentioned that we can use a shared database may be a nice choice.
We can added some new tables that record the information signconf contains.

-----????-----
???: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] ?? Jerry Lundstr?m
????: 2013?9?12? 16:15
???: Si?n Lloyd
??: opendnssec-develop at lists.opendnssec.org
??: Re: [Opendnssec-develop] 2.0 - zonelist.xml

On 12 sep 2013, at 10:08, "Si?n Lloyd" <sion at nominet.org.uk> wrote:

> One file per zone could work

We need to think more about this.

There are limits to the number of files in a single directory for about half of the filesystems and the most common one (ext*).

> we could add the config information that the signer needs for the 
> adapters, etc. to the signconf files.

Yes, we should add all nessesary configuration for a zone in the same space.

/Jerry
_______________________________________________
Opendnssec-develop mailing list
Opendnssec-develop at lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop




From jerry at opendnssec.org  Thu Sep 12 09:13:53 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 12 Sep 2013 11:13:53 +0200
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <3732588.510.1378974778250.JavaMail.mobile-sync@vecoi2>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
	<52306E80.1060706@nominet.org.uk> <52307281.5000000@nlnetlabs.nl>
	<F7F79EFD-5281-4B32-9B14-24640895D619@kirei.se>
	<5231765E.7040407@nominet.org.uk>
	<-2954920784596733667@unknownmsgid>
	<3732588.510.1378974778250.JavaMail.mobile-sync@vecoi2>
Message-ID: <-6472557402889231431@unknownmsgid>

On 12 sep 2013, at 10:30, "Si?n Lloyd" <sion at nominet.org.uk> wrote:

> This is true, although they are much higher than we might reasonably
> expect to be using.

I would rather design something that is scalable then think that we
will never use that many zones (why not 10mil zones?).

> There is also a performance hit and you run into
> issues if you try to use shell expansion.

This should not be a problem from a program perspective.

>From a administrative perspective its another matter but we could make
it easy to manage that data with tools rather then have people mess
around in the data structure (how ever it will look).
>


/Jerry


From jakob at kirei.se  Thu Sep 12 10:40:38 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 12 Sep 2013 12:40:38 +0200
Subject: [Opendnssec-develop] 2.0 - zonelist.xml
In-Reply-To: <-2954920784596733667@unknownmsgid>
References: <CAGTFMNaV65cAizv+=pahqXzmWbt6ghxe_7ucCep2d2iCf7RdKw@mail.gmail.com>
	<52306E80.1060706@nominet.org.uk> <52307281.5000000@nlnetlabs.nl>
	<F7F79EFD-5281-4B32-9B14-24640895D619@kirei.se>
	<5231765E.7040407@nominet.org.uk>
	<-2954920784596733667@unknownmsgid>
Message-ID: <55F6C272-8471-46F5-B329-765D192995D4@kirei.se>

On 12 sep 2013, at 10:15, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> There are limits to the number of files in a single directory for
> about half of the filesystems and the most common one (ext*).

All files in one directory would be wrong, hashing the filenames works just fine.

	jakob



From jerry at opendnssec.org  Tue Sep 17 09:07:33 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Tue, 17 Sep 2013 11:07:33 +0200
Subject: [Opendnssec-develop] Maintenance of dist.opendnssec.org and SVN
	today Tuesday 14:30 - 15:00 CEST
Message-ID: <E258F789-FEDB-4A68-9CD0-F8820499D3B9@opendnssec.org>

Hi,

I would like to do some maintenance work on the servers here at .SE so please don't use SVN during this time.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130917/a2fcaa11/attachment.bin>

From sara at sinodun.com  Tue Sep 17 12:45:10 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 17 Sep 2013 13:45:10 +0100
Subject: [Opendnssec-develop] RE: Off sick. 
Message-ID: <6C04E71D-9833-4B2E-8821-149C19032597@sinodun.com>

Hi All, 

Very sorry for not replying to various emails - I am off sick at the moment. Should be back tomorrow.

Sara.

From jerry at opendnssec.org  Tue Sep 17 13:32:24 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Tue, 17 Sep 2013 15:32:24 +0200
Subject: [Opendnssec-develop] Re: Maintenance of dist.opendnssec.org and SVN
	today Tuesday 14:30 - 15:00 CEST
In-Reply-To: <E258F789-FEDB-4A68-9CD0-F8820499D3B9@opendnssec.org>
References: <E258F789-FEDB-4A68-9CD0-F8820499D3B9@opendnssec.org>
Message-ID: <4B229213-5724-450B-B50D-4CFD641585EA@opendnssec.org>

On Sep 17, 2013, at 11:07 , Jerry Lundstr?m wrote:

> I would like to do some maintenance work on the servers here at .SE so please don't use SVN during this time.


Forgot to say, maintenance is over, feel free to use SVN.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130917/0c874c16/attachment.bin>

From jad at sinodun.com  Wed Sep 18 12:45:18 2013
From: jad at sinodun.com (John Dickinson)
Date: Wed, 18 Sep 2013 12:45:18 +0000
Subject: [Opendnssec-develop] new node on jenkins
Message-ID: <697919A9-34B3-4963-A18F-3DF2874CE9A7@sinodun.com>

FYI

I have added a new node (sqlite-version-test) on jenkins to allow testing against multiple sqlite3 versions. This is to allow me to test new sqllite functionality code (foreign keys etc.) that I have just written for the 1.4 branch. It has the following versions installed sqlite-3.6.18, sqlite-3.6.19, sqlite-3.7.0, sqlite-3.7.16 and sqlite-3.8.0.2.

I suspect this node may disappear once the new code is committed.

John


---
jad at sinodun.com

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

+44 (0)1491 834957

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130918/41e7f2dd/attachment.bin>

From jerry at opendnssec.org  Wed Sep 18 14:08:00 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 18 Sep 2013 16:08:00 +0200
Subject: [Opendnssec-develop] NSEC3 salt handling, do we need tools perhaps?
Message-ID: <2176245A-DEBD-4534-815C-6DCA31A0DC3E@opendnssec.org>

Hi all,

I'm working on a plugin ( https://github.com/jelu/lim-plugin-orr/tree/develop ) to Lim, the framework I started to develop last year to bring REST/SOAP API to OpenDNSSEC (check my GibHub page).

Right now I'm working on logic for a backup/failover solution for OpenDNSSEC and trying to only use the tools we have (ods-ksmutil etc).

Handling KSK/ZSK is all fine and dandy, I can set policy to manual everything and copy the key between nodes... but what about NSEC3 salt?

From what I can find we only configure it in the policy, there are no tools to check the current salt from the KASP database, regenerate it or display when it will resalt (Maybe we need these tools?).

Say for example that you have two nodes, A and B, both running the same KSK and ZSK but different salts. A is primary and the signed zone it has generated is live. A then breaks down and we send a new update of the zone to B and it generates a new signed zone with the same KSK and ZSK but with a different NSEC3 salt.

Can or will there be a problem here when that zone goes live?

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130918/f5f29aa9/attachment.bin>

From olaf at NLnetLabs.nl  Wed Sep 18 15:50:30 2013
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Wed, 18 Sep 2013 17:50:30 +0200
Subject: [Opendnssec-develop] NSEC3 salt handling,
	do we need tools perhaps?
In-Reply-To: <2176245A-DEBD-4534-815C-6DCA31A0DC3E@opendnssec.org>
References: <2176245A-DEBD-4534-815C-6DCA31A0DC3E@opendnssec.org>
Message-ID: <50ADE6FB-EC86-4B61-A7F6-23086C244677@NLnetLabs.nl>


On 18 sep. 2013, at 16:08, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> 
> Say for example that you have two nodes, A and B, both running the same KSK and ZSK but different salts. A is primary and the signed zone it has generated is live. A then breaks down and we send a new update of the zone to B and it generates a new signed zone with the same KSK and ZSK but with a different NSEC3 salt.
> 
> Can or will there be a problem here when that zone goes live?

From the point of view from the resolver this is a pretty atomic operation and I do not immediately (in the few minutes I thought about this) see a problem.

From the point of view from the authoritative name servers to which A and B push their content this will trigger a full zone changes i.e. an AXFR instead of an IXFR.  That could be painful.

--Olaf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130918/fa2ca39c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130918/fa2ca39c/attachment.bin>

From matthijs at nlnetlabs.nl  Thu Sep 19 05:21:52 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Thu, 19 Sep 2013 07:21:52 +0200
Subject: [Opendnssec-develop] NSEC3 salt handling,
	do we need tools perhaps?
In-Reply-To: <50ADE6FB-EC86-4B61-A7F6-23086C244677@NLnetLabs.nl>
References: <2176245A-DEBD-4534-815C-6DCA31A0DC3E@opendnssec.org>
	<50ADE6FB-EC86-4B61-A7F6-23086C244677@NLnetLabs.nl>
Message-ID: <523A89F0.3080401@nlnetlabs.nl>

On 09/18/2013 05:50 PM, Olaf Kolkman wrote:
> 
> On 18 sep. 2013, at 16:08, Jerry Lundstr?m <jerry at opendnssec.org
> <mailto:jerry at opendnssec.org>> wrote:
> 
>>
>> Say for example that you have two nodes, A and B, both running the
>> same KSK and ZSK but different salts. A is primary and the signed zone
>> it has generated is live. A then breaks down and we send a new update
>> of the zone to B and it generates a new signed zone with the same KSK
>> and ZSK but with a different NSEC3 salt.
>>
>> Can or will there be a problem here when that zone goes live?
> 
> From the point of view from the resolver this is a pretty atomic
> operation and I do not immediately (in the few minutes I thought about
> this) see a problem.

Short answer: Correct.

Long answer: Correct. There must be at least one complete NSEC/NSEC3
chain in the published zone, then it poses no validation issues at the
resolver. The resolver only needs to get consistent NSEC3 records in the
response. There are no timing issues like with DNSKEYs.

Best regards,
  Matthijs

> From the point of view from the authoritative name servers to which A
> and B push their content this will trigger a full zone changes i.e. an
> AXFR instead of an IXFR.  That could be painful.
>
> 
> --Olaf
> 
> 
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 



From jerry at opendnssec.org  Thu Sep 19 06:59:29 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 19 Sep 2013 08:59:29 +0200
Subject: [Opendnssec-develop] NSEC3 salt handling,
	do we need tools perhaps?
In-Reply-To: <13779036.58432.1379569391245.JavaMail.mobile-sync@vecdf17>
References: <2176245A-DEBD-4534-815C-6DCA31A0DC3E@opendnssec.org>
	<50ADE6FB-EC86-4B61-A7F6-23086C244677@NLnetLabs.nl>
	<13779036.58432.1379569391245.JavaMail.mobile-sync@vecdf17>
Message-ID: <-457091537484733586@unknownmsgid>

Hi,

On 19 sep 2013, at 07:21, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:

> On 09/18/2013 05:50 PM, Olaf Kolkman wrote:
>>
>> From the point of view from the resolver this is a pretty atomic
>> operation and I do not immediately (in the few minutes I thought about
>> this) see a problem.
>
> Short answer: Correct.
>
> Long answer: Correct. There must be at least one complete NSEC/NSEC3
> chain in the published zone, then it poses no validation issues at the
> resolver. The resolver only needs to get consistent NSEC3 records in the
> response. There are no timing issues like with DNSKEYs.

Ah, good. Thanks for the answers!
>

/Jerry


From sion at nominet.org.uk  Thu Sep 19 08:13:19 2013
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Thu, 19 Sep 2013 09:13:19 +0100
Subject: [Opendnssec-develop] NSEC3 salt handling,
	do we need tools perhaps?
In-Reply-To: <2176245A-DEBD-4534-815C-6DCA31A0DC3E@opendnssec.org>
References: <2176245A-DEBD-4534-815C-6DCA31A0DC3E@opendnssec.org>
Message-ID: <523AB21F.5090802@nominet.org.uk>

On 18/09/13 15:08, Jerry Lundstr?m wrote:
> Say for example that you have two nodes, A and B, both running the same KSK and ZSK but different salts. A is primary and the signed zone it has generated is live. A then breaks down and we send a new update of the zone to B and it generates a new signed zone with the same KSK and ZSK but with a different NSEC3 salt.
>
> Can or will there be a problem here when that zone goes live?
>

If you have different salt it implies that you have an enforcer running
at both nodes, or at least that the signconfs are not in sync. The
problem that you need to worry about here is what happens when one node
kicks off a key roll?

As has been said the salt change is not in itself an issue; but it would
indicate that the two nodes are not in step - which could be serious.

Sion


From jerry at opendnssec.org  Thu Sep 19 08:44:41 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 19 Sep 2013 10:44:41 +0200
Subject: [Opendnssec-develop] NSEC3 salt handling,
	do we need tools perhaps?
In-Reply-To: <523AB21F.5090802@nominet.org.uk>
References: <2176245A-DEBD-4534-815C-6DCA31A0DC3E@opendnssec.org>
	<523AB21F.5090802@nominet.org.uk>
Message-ID: <9EDE443A-51A4-4E0B-8BBB-42F187A297E7@opendnssec.org>

On Sep 19, 2013, at 10:13 , Si?n Lloyd wrote:

> If you have different salt it implies that you have an enforcer running
> at both nodes, or at least that the signconfs are not in sync. The
> problem that you need to worry about here is what happens when one node
> kicks off a key roll?

Yes, both will have enforcers since I will be trying to manage multiple instances with the interfaces we have and NOT mess around with the internal files (which you should really really really not do).

Key rollovers will be set to manually in the policy and handled automatically by the management tool.

> As has been said the salt change is not in itself an issue; but it would
> indicate that the two nodes are not in step - which could be serious.


Not really, everything but the salt will be synchronized since we don't have interfaces to manage the salt. And since the salt does not seem to be a problem it should work.

/Jerry

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130919/ad21bc70/attachment.bin>

From sara at sinodun.com  Thu Sep 19 13:56:45 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 19 Sep 2013 14:56:45 +0100
Subject: [Opendnssec-develop] OpenDNSSEC 1.3.15
Message-ID: <970D19A1-D31F-4193-9516-C5663C1BFB7A@sinodun.com>

All, 

Version 1.3.15 of OpenDNSSEC has now been released. 

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-423].
* OPENDNSSEC-428: Add option for ?ods-ksmutil key generate? to take total  number of zones as a parameter
* OPENDNSSEC-448: Signer Engine: Enhancements to signer debug locks.

Bugfixes:

* SUPPORT-75: Signer Engine: Fix double free crash in case of HSM connection error during signing [OPENDNSSEC-452].
* OPENDNSSEC-397: Change ?hsmutil list? output so that the table header goes to stdout not stderr
* OPENDNSSEC-438: ?ods-ksmutil key generate? and the enforcer can create too many keys for <SharedKeys/> policies when KSK and ZSK use same  algorithm and length
* OPENDNSSEC-445: ods-ksmutil: Clean up of hsm connection handling

Documentation:

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

Download:

* http://dist.opendnssec.org/source/opendnssec-1.3.15.tar.gz
* http://dist.opendnssec.org/source/opendnssec-1.3.15.tar.gz.sig
* Checksum sha1: 7241936811ae079af6002115cda057e825b60cfe
* Checksum sha256: c29884f76d278862de59576c2e5440e37c2b7c16f1984ccc7685a3a049e1c081


//OpenDNSSEC team




From jad at sinodun.com  Thu Sep 19 14:03:11 2013
From: jad at sinodun.com (John Dickinson)
Date: Thu, 19 Sep 2013 14:03:11 +0000
Subject: [Opendnssec-develop] NSEC3 salt handling,
	do we need tools perhaps?
In-Reply-To: <9EDE443A-51A4-4E0B-8BBB-42F187A297E7@opendnssec.org>
References: <2176245A-DEBD-4534-815C-6DCA31A0DC3E@opendnssec.org>
	<523AB21F.5090802@nominet.org.uk>
	<9EDE443A-51A4-4E0B-8BBB-42F187A297E7@opendnssec.org>
Message-ID: <C816925F-163D-48D2-8313-F97AB673C0AD@sinodun.com>


On 19 Sep 2013, at 08:44, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> On Sep 19, 2013, at 10:13 , Si?n Lloyd wrote:
> 
>> If you have different salt it implies that you have an enforcer running
>> at both nodes, or at least that the signconfs are not in sync. The
>> problem that you need to worry about here is what happens when one node
>> kicks off a key roll?
> 
> Yes, both will have enforcers since I will be trying to manage multiple instances with the interfaces we have and NOT mess around with the internal files (which you should really really really not do).
> 
> Key rollovers will be set to manually in the policy and handled automatically by the management tool.

I have not had time to look at LIM, so this may be a stupid comment...

IMHO: This kind of makes some of the enforcer pointless if an external mgmt. app is doing the key rollover (even more so in v2 ????). I would imagine that most operators would prefer a active-active system where the two enforcers communicate state to each other and both signers act as masters for the zones. I do realise that this might be a lot more work :)

Out of interest, has there been any architecture discussion for this kind of functionality? I could not find it...

regards
John

> 
>> As has been said the salt change is not in itself an issue; but it would
>> indicate that the two nodes are not in step - which could be serious.
> 
> 
> Not really, everything but the salt will be synchronized since we don't have interfaces to manage the salt. And since the salt does not seem to be a problem it should work.
> 
> /Jerry
> 
> --
> Jerry Lundstr?m - OpenDNSSEC Developer
> http://www.opendnssec.org/
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

---
jad at sinodun.com

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

+44 (0)1491 834957

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130919/856440ad/attachment.bin>

From jerry at opendnssec.org  Thu Sep 19 14:28:40 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 19 Sep 2013 16:28:40 +0200
Subject: [Opendnssec-develop] NSEC3 salt handling,
	do we need tools perhaps?
In-Reply-To: <C816925F-163D-48D2-8313-F97AB673C0AD@sinodun.com>
References: <2176245A-DEBD-4534-815C-6DCA31A0DC3E@opendnssec.org>
	<523AB21F.5090802@nominet.org.uk>
	<9EDE443A-51A4-4E0B-8BBB-42F187A297E7@opendnssec.org>
	<C816925F-163D-48D2-8313-F97AB673C0AD@sinodun.com>
Message-ID: <545363AA-D964-450B-98B0-72ECFDB9C40F@opendnssec.org>

On Sep 19, 2013, at 16:03 , John Dickinson wrote:

> I have not had time to look at LIM, so this may be a stupid comment?

It's Lim not LIM, its not an acronym. Just the swedish word for glue. All comments are welcomed.

> IMHO: This kind of makes some of the enforcer pointless if an external mgmt. app is doing the key rollover (even more so in v2 ????). I would imagine that most operators would prefer a active-active system where the two enforcers communicate state to each other and both signers act as masters for the zones. I do realise that this might be a lot more work :)

The whole idea behind Lim, and the plugins that I've made, is that it is A LOT more work to redesign and develop OpenDNSSEC to have internal support for active-active solutions then to just put something on top of OpenDNSSEC.

As the API plugins for OpenDNSSEC and SoftHSM are complete I am now working on something that will manage these applications.

I do not think operators will care what layer is doing the active-active solution as long as there is one and this plugin that I'm developing now will take care of all this. And I want to do this with ONLY using the tools that come with OpenDNSSEC and SoftHSM because otherwise you are essentially hacking the program and creating very hard to manage dependancies (you would not edit a MySQL database file by hand just because you can, now would you?).

> Out of interest, has there been any architecture discussion for this kind of functionality? I could not find it?

For OpenDNSSEC's part, no, there has not been any discussion of this kind. Theres only been a API/CLI discussion.

For Lim's part or rather the plugin I am developing now (Lim is really just a framework, it does not do anything on its own), not really. This work isn't really a part of OpenDNSSEC per say. I welcome the discussion but I have no material to present, right now I am just testing my way forward.

/Jerry

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130919/341e1ef6/attachment.bin>

From sara at sinodun.com  Fri Sep 20 13:22:58 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 20 Sep 2013 14:22:58 +0100
Subject: [Opendnssec-develop] RE: OpenDNSSEC Developer workshop 
In-Reply-To: <682D7D03-CE03-4E0B-9129-19C6EBDEF1D8@kirei.se>
References: <6670AC33-18A1-48DF-A55A-686307739B23@sinodun.com>
	<EE66F5D1-F295-43BC-A965-9C18159B499D@sinodun.com>
	<682D7D03-CE03-4E0B-9129-19C6EBDEF1D8@kirei.se>
Message-ID: <8ACE7663-5AF7-440F-B9C9-0DDA6406B3E0@sinodun.com>

Hi All, 

Just to update you that there are still various discussing on travel and visa arrangements ongoing but that I hope we can make a decision on the location early next week!

Sara. 

On 2 Sep 2013, at 15:42, Jakob Schlyter wrote:

> 2 sep 2013 kl. 15:44 skrev Sara Dickinson <sara at sinodun.com>:
> 
>> Please note that there is a (Yes) option on the poll which acts as a 'maybe' answer. Please use this if you are free on these dates but would need to get agreement from your boss and/or agree funding for the trip. 
> 
> I'd like to emphasize the above - if funding is the reason for not being able to participate, please mark as MAYBE.
> 
>  Jakob
> 



From sara at sinodun.com  Fri Sep 20 14:30:10 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 20 Sep 2013 15:30:10 +0100
Subject: [Opendnssec-develop] SoftHSM 1.3.5rc1 release candidate
Message-ID: <8698C353-C8AA-4AB2-AA63-F2A85BEDA58F@sinodun.com>

All, 

Version 1.3.5rc1 of SoftHSM is now available. This is a release candidate for testing purposes:


SoftHSM 1.3.5rc1
-------------------------

Bugfixes:
* SOFTHSM-45: Improved handling of a busy database
* SUPPORT-76: Add -Wall -Werror flags and fix the warnings.

Download:
* http://dist.opendnssec.org/source/testing/softhsm-1.3.5rc1.tar.gz
* http://dist.opendnssec.org/source/testing/softhsm-1.3.5rc1.tar.gz.sig
* Checksum sha1: b3c58f7462415864d19da49fde279763d976a0d6
* Checksum sha256: 1132b4db2c1a20dec66ac9d398226d062c289fe7e08738c3672c289b4fcda8ce

A full SoftHSM 1.3.5 release is planned for Friday 27th September.


//OpenDNSSEC team

  

From sara at sinodun.com  Wed Sep 25 09:47:45 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 25 Sep 2013 10:47:45 +0100
Subject: [Opendnssec-develop] RE: Team meeting - Thursday 26 Sept 2013 @
	14:00 CEST
Message-ID: <F6EA14B6-BD1B-42B9-93B7-1DE27E517229@sinodun.com>

Hi All, 

We have a team meeting on Thursday this week:

Date:      Thursday 26 Sep 2013
Time:      14:00-15:00 CEST, 13:00-14:00 BST, 20:00 CST, 12:00 UTC
Method:  Teamspeak. Server name and password are here (requires login): https://wiki.opendnssec.org/display/OpenDNSSEC/Conference+call+details
Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2013-09-26+Agenda


Sara.

P.S. I've attached an iCal invitation to this message if this is useful for anyone?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130925/ac56d341/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenDNSSEC team meeting.ics
Type: text/calendar
Size: 920 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130925/ac56d341/attachment.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130925/ac56d341/attachment-0001.htm>

From yuri at nlnetlabs.nl  Thu Sep 26 09:04:40 2013
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Thu, 26 Sep 2013 11:04:40 +0200
Subject: [Opendnssec-develop] RE: Team meeting - Thursday 26 Sept 2013
	@ 14:00 CEST
In-Reply-To: <F6EA14B6-BD1B-42B9-93B7-1DE27E517229@sinodun.com>
References: <F6EA14B6-BD1B-42B9-93B7-1DE27E517229@sinodun.com>
Message-ID: <5243F8A8.5040405@nlnetlabs.nl>

> P.S. I've attached an iCal invitation to this message if this is useful
> for anyone?

Not really for me. I'm using my android agenda and while it is possible
to import ics in the google webinterface it is not convenient at all.

Plus 24h in advance is a bit short. :)

//Yuri


-- 
Composed on an actual keyboard: all typos genuine.


From jerry at opendnssec.org  Thu Sep 26 09:21:22 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 26 Sep 2013 11:21:22 +0200
Subject: [Opendnssec-develop] Team meeting - Thursday 26 Sept 2013 @ 14:00
	CEST
In-Reply-To: <5243F8A8.5040405@nlnetlabs.nl>
References: <F6EA14B6-BD1B-42B9-93B7-1DE27E517229@sinodun.com>
	<5243F8A8.5040405@nlnetlabs.nl>
Message-ID: <0C1F40FD-9594-43D1-A878-45898D701563@opendnssec.org>

On Sep 26, 2013, at 11:04 , Yuri Schaeffer wrote:

>> P.S. I've attached an iCal invitation to this message if this is useful
>> for anyone?
> 
> Not really for me. I'm using my android agenda and while it is possible
> to import ics in the google webinterface it is not convenient at all.


I always add the next meeting in my calendar at the end of the meeting, so I don't really have a need for an invite.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 625 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130926/b9b27af3/attachment.bin>

From rick at openfortress.nl  Thu Sep 26 09:37:41 2013
From: rick at openfortress.nl (Rick van Rein (OpenFortress))
Date: Thu, 26 Sep 2013 11:37:41 +0200
Subject: [Opendnssec-develop] Team meeting - Thursday 26 Sept 2013 @ 14:00
	CEST
In-Reply-To: <0C1F40FD-9594-43D1-A878-45898D701563@opendnssec.org>
References: <F6EA14B6-BD1B-42B9-93B7-1DE27E517229@sinodun.com>
	<5243F8A8.5040405@nlnetlabs.nl>
	<0C1F40FD-9594-43D1-A878-45898D701563@opendnssec.org>
Message-ID: <EC551ACC-F4E3-43FE-99E4-C943893CEE67@openfortress.nl>

Hi,

Hearing the responses from Yuri and Jerry, it sounds as if an iCalender event at the time it is established is useful.  My use for it is to have a reminder alarm just before the meeting, which might be something to add to the event before it is sent, or by us recipients.  It would also mean that Sara can forego the reminders, which might simplify her flow.

-Rick

From sara at sinodun.com  Thu Sep 26 09:59:43 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 26 Sep 2013 10:59:43 +0100
Subject: [Opendnssec-develop] Team meeting - Thursday 26 Sept 2013 @ 14:00
	CEST
In-Reply-To: <EC551ACC-F4E3-43FE-99E4-C943893CEE67@openfortress.nl>
References: <F6EA14B6-BD1B-42B9-93B7-1DE27E517229@sinodun.com>
	<5243F8A8.5040405@nlnetlabs.nl>
	<0C1F40FD-9594-43D1-A878-45898D701563@opendnssec.org>
	<EC551ACC-F4E3-43FE-99E4-C943893CEE67@openfortress.nl>
Message-ID: <D8507CE6-F0FD-45D8-94B7-EA7E2318B693@sinodun.com>


On 26 Sep 2013, at 10:37, Rick van Rein (OpenFortress) wrote:

> Hi,
> 
> Hearing the responses from Yuri and Jerry, it sounds as if an iCalender event at the time it is established is useful.  My use for it is to have a reminder alarm just before the meeting, which might be something to add to the event before it is sent, or by us recipients.  It would also mean that Sara can forego the reminders, which might simplify her flow.


It is simple for me to add an iCal invite for the next meeting to the email I send indicating the minutes for the last meeting are available so I'll do this in future for anyone who wants it!

Sara.

From yuri at nlnetlabs.nl  Thu Sep 26 10:29:29 2013
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Thu, 26 Sep 2013 12:29:29 +0200
Subject: [Opendnssec-develop] Team meeting - Thursday 26 Sept 2013 @ 14:00
	CEST
In-Reply-To: <EC551ACC-F4E3-43FE-99E4-C943893CEE67@openfortress.nl>
References: <F6EA14B6-BD1B-42B9-93B7-1DE27E517229@sinodun.com>
	<5243F8A8.5040405@nlnetlabs.nl>
	<0C1F40FD-9594-43D1-A878-45898D701563@opendnssec.org>
	<EC551ACC-F4E3-43FE-99E4-C943893CEE67@openfortress.nl>
Message-ID: <52440C89.8050800@nlnetlabs.nl>

> Hearing the responses from Yuri and Jerry, it sounds as if an
> iCalender event at the time it is established is useful.  My use for
> it is to have a reminder alarm just before the meeting, which might
> be something to add to the event before it is sent, or by us
> recipients.  It would also mean that Sara can forego the reminders,
> which might simplify her flow.

Well I have the same workflow as Jerry, including an alarm. But it
happened once or twice that I forgot to add it to my agenda. Sara's
reminder saved the day. Having some ics file attached to an email will
not increase probability call reaches my agenda.

//Yuri

-- 
Composed on an actual keyboard: all typos genuine.


From jerry at opendnssec.org  Thu Sep 26 11:50:25 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 26 Sep 2013 13:50:25 +0200
Subject: [Opendnssec-develop] Test platforms update/upgrade/reinstall
Message-ID: <5BB117ED-C960-44F8-BA09-E3F555B3555D@opendnssec.org>

Hi all,

I'm planing to update, upgrade or reinstall some or all of the platforms we test on. This is to get the latest and greatest for some and make a clean install for others. With this change I also want to try and get LDAP working with Crowd (Atlassians Auth server) so we can have a special group that controls who has access to the test platforms and you can use your JIRA account, hopefully with public ssh keys as attributes.

I will try and perform the change with minimal impact to Jenkins by setting up a temporary transition VM and redirect the node in Jenkins to that one during the work on the node.

There will also be a slight change to the list of platforms we test on but it has been thing we discussed before but haven't got around to yet. I will also make room for the upcoming Ubuntu 14.04 LTS release.

The distribution list will be as follows, all will have 64bit environments and a few will also have a 32bit environment:

Debian (latest stable)
Ubuntu 10.04 LTS
Ubuntu 12.04 LTS
CentOS (latest stable)
RedHat (latest stable)
OpenSUSE (latest stable)
SUSE (latest stable)
Solaris (latest stable)
FreeBSD (latest stable)
NetBSD (latest stable)
OpenBSD (latest stable)

If you have any comments, please let me know.

/Jerry

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 625 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130926/2376be51/attachment.bin>

From rick at openfortress.nl  Thu Sep 26 13:09:56 2013
From: rick at openfortress.nl (Rick van Rein (OpenFortress))
Date: Thu, 26 Sep 2013 15:09:56 +0200
Subject: [Opendnssec-develop] Wild idea :- Kerberos for fine-grained control
Message-ID: <90C6BD1B-5CF9-4496-B9D8-04D79457A9FA@openfortress.nl>

Hello,

I've lately been catching up on Kerberos, and found that it is incredibly powerful.  It might actually be beneficial to OpenDNSSEC...

 * to offload the root account
    - bring limited uses of the tools down to user level -- so less need to use the PIN-owning root account
    - note that OpenDNSSEC assumes that the PIN is stored in a file visible to root
    - also note that many PKCS #11 libraries store the PIN in memory and send it along with every card transaction
    - this could make it less scary to run the tools (indirectly) from a web environment
    - this could make it less scary to run the tools in response to an SSH request

 * for finer-grained access control
    - who can make change X to zone Y could be configured in kasp.xml or zones.xml
    - zone reloads, re-signing actions and so on might follow a similar system
    - ideal for multiple-tennant systems such as in use by DNS service providers / registrants?

 * for end-to-end authentication
    - user's authenticity forms a chain from their local machine through to OpenDNSSEC
    - Kerberos can cut through protocols like RSH, SSH, RSYNC, MOSH and even HTTP
    - most web browsers support Kerberos authentication: IE, FireFox, Safari, and even Curl; unsupporting ones are rare: Opera, wget
    - end-user can start their authentication chain on any system, independent of POSIX accounts, as long as "kinit" is installed
    - note that arrangements for cross-realm authentication exist, so a client need not logon to OpenDNSSEC's domain to access it

 * to make it fit into many environments with much grace
    - Apple has it on board; you can run kinit in a shell or integrate it with the normal login process
    - Windows does this all the time, when logging on to a domain (WFW or AD DC)
    - Linux users just install "krb5-user" or a similar package to be able to "kinit"
    - To a user, Kerberos is actually very simple? logon once a day/session and use as SSO
    - Users can switch between authenticated names, or roles, e.g. rick at OPENDNSSEC.ORG vs. rick/admin at OPENDNSSEC.ORG

I can get really excited about technology I've just discovered, but this list of possibilities might be worthy of some attention to OpenDNSSEC?


Cheers,
 -Rick

From jerry at opendnssec.org  Thu Sep 26 13:43:13 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 26 Sep 2013 15:43:13 +0200
Subject: [Opendnssec-develop] Wild idea :- Kerberos for fine-grained
	control
In-Reply-To: <90C6BD1B-5CF9-4496-B9D8-04D79457A9FA@openfortress.nl>
References: <90C6BD1B-5CF9-4496-B9D8-04D79457A9FA@openfortress.nl>
Message-ID: <D902B7E7-B323-407E-8990-0C5814181D7C@opendnssec.org>

Hi,

On Sep 26, 2013, at 15:09 , Rick van Rein (OpenFortress) wrote:

> I've lately been catching up on Kerberos, and found that it is incredibly powerful.  It might actually be beneficial to OpenDNSSEC...


This is really a wild idea.

At first glance, I think you may be misunderstanding what Kerberos actually is. It will authenticate a user in a very secure way but it does not handles access control in the way you describe in some of the suggestions.

Currently for 1.3/1.4 there is also the issue of file system access, the user that is performing actions needs certain kind of access to different files and that it not something Kerberos can help you with.

For 2.0 we will have a clear separation of the file level access between the user and daemon by doing almost everything via UNIX sockets but I don't see a real use of Kerberos here.

If we want to implement something like Kerberos we first must implement multi-user access, today if you have access to OpenDNSSEC tools you can do anything. If we redesign OpenDNSSEC for a multi-user environment in the future I would rather see PAM or similar systems integrated that will give access to even more ways to authenticate users.

/Jerry

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 625 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130926/3ef3a6db/attachment.bin>

From rick at openfortress.nl  Thu Sep 26 13:55:54 2013
From: rick at openfortress.nl (Rick van Rein (OpenFortress))
Date: Thu, 26 Sep 2013 15:55:54 +0200
Subject: [Opendnssec-develop] Wild idea :- Kerberos for fine-grained
	control
In-Reply-To: <D902B7E7-B323-407E-8990-0C5814181D7C@opendnssec.org>
References: <90C6BD1B-5CF9-4496-B9D8-04D79457A9FA@openfortress.nl>
	<D902B7E7-B323-407E-8990-0C5814181D7C@opendnssec.org>
Message-ID: <282537FC-0F5E-481A-89DC-AE08ACDADA8F@openfortress.nl>

Hi,

> This is really a wild idea.

I know? but setting an ideal future can be helpful to give a direction to a project.

> At first glance, I think you may be misunderstanding what Kerberos actually is. It will authenticate a user in a very secure way but it does not handles access control in the way you describe in some of the suggestions.

I know.  Usually, authorization (access control) is setup within an application based on the authenticated identity provided by, in this case, Kerberos.  For example, the ~/.k5login file does to Kerberised RSH what .ssh/authorized_keys does to SSH.

> Currently for 1.3/1.4 there is also the issue of file system access, the user that is performing actions needs certain kind of access to different files and that it not something Kerberos can help you with.

You'd have to run setuid root or do what 2.0 does:

> For 2.0 we will have a clear separation of the file level access between the user and daemon by doing almost everything via UNIX sockets but I don't see a real use of Kerberos here.

So that's a -1 from you.

> If we want to implement something like Kerberos we first must implement multi-user access, today if you have access to OpenDNSSEC tools you can do anything. If we redesign OpenDNSSEC for a multi-user environment in the future I would rather see PAM or similar systems integrated that will give access to even more ways to authenticate users.

The sort of things I proposed to put into the config files are, I suppose, what you mean with multi-user access.  Yes, that might be difficult to do in general.  In that setting, I suppose I'm proposing to not jump to the locally available Posix accounts without further thought.  Many users could share a Posix account ("www-data" for instance) to get constrained access to ODS based on their Kerberos credentials.

PAM is a more general solution because it does Kerberos and much more as well.  Perfect.  I will still see an opening to put Kerberos in though, and will probably look make sure it remains possible.


Thanks,
 -Rick

From sara at sinodun.com  Thu Sep 26 13:59:10 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 26 Sep 2013 14:59:10 +0100
Subject: [Opendnssec-develop] RE: Discussion of usability developments
Message-ID: <7E8D398D-7631-4B93-BF34-238C4F44512D@sinodun.com>

Hi All, 

As a result of discussions and the user survey we heard clearly from users that they would like some usability developments implemented to make their lives easier! It has take a while but here is a page where I have gathered together a (slightly) more detailed list of the developments we could consider for 1.3/1.4:

https://wiki.opendnssec.org/display/OpenDNSSEC/Usability+requirements

I'm hoping we can do a general review of content and priority first, then I'll create some JIRA issues and send this out on the user list to get some more feedback. 

Thanks

Sara.

From sara at sinodun.com  Thu Sep 26 14:09:40 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 26 Sep 2013 15:09:40 +0100
Subject: Fwd: [Opendnssec-develop] RE: Team meeting - Thursday 26 Sept 2013 @
	14:00 CEST
References: <F6EA14B6-BD1B-42B9-93B7-1DE27E517229@sinodun.com>
Message-ID: <6A8BDFF7-B590-4A87-B4CB-65EECA89FBDB@sinodun.com>

Hi All, 

The minutes from the meeting today are available for review:

https://wiki.opendnssec.org/display/OpenDNSSEC/2013-09-26+Minutes

Next meeting is 8th October @ 14:30 CEST

Sara.




Begin forwarded message:

> From: Sara Dickinson <sara at sinodun.com>
> Date: 25 September 2013 10:47:45 GMT+01:00
> To: Opd Dev <opendnssec-develop at lists.opendnssec.org>
> Subject: [Opendnssec-develop] RE: Team meeting - Thursday 26 Sept 2013 @ 14:00 CEST
> 
> Hi All, 
> 
> We have a team meeting on Thursday this week:
> 
> Date:      Thursday 26 Sep 2013
> Time:      14:00-15:00 CEST, 13:00-14:00 BST, 20:00 CST, 12:00 UTC
> Method:  Teamspeak. Server name and password are here (requires login): https://wiki.opendnssec.org/display/OpenDNSSEC/Conference+call+details
> Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2013-09-26+Agenda
> 
> 
> Sara.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130926/29f45019/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenDNSSEC team meeting.ics
Type: text/calendar
Size: 718 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130926/29f45019/attachment.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130926/29f45019/attachment-0001.htm>

From jerry at opendnssec.org  Thu Sep 26 14:23:19 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 26 Sep 2013 16:23:19 +0200
Subject: [Opendnssec-develop] Wild idea :- Kerberos for fine-grained
	control
In-Reply-To: <282537FC-0F5E-481A-89DC-AE08ACDADA8F@openfortress.nl>
References: <90C6BD1B-5CF9-4496-B9D8-04D79457A9FA@openfortress.nl>
	<D902B7E7-B323-407E-8990-0C5814181D7C@opendnssec.org>
	<282537FC-0F5E-481A-89DC-AE08ACDADA8F@openfortress.nl>
Message-ID: <DD6042AE-7BB1-4587-9931-5CE55A88E5C2@opendnssec.org>

Hi,

On Sep 26, 2013, at 15:55 , Rick van Rein (OpenFortress) wrote:

>> Currently for 1.3/1.4 there is also the issue of file system access, the user that is performing actions needs certain kind of access to different files and that it not something Kerberos can help you with.
> 
> You'd have to run setuid root or do what 2.0 does:

No you don't need setuid root (you should never do that). I should be possible (I have, works but not tested fully) setup OpenDNSSEC and SoftHSM usable by other account by adding them into the correct groups and making sure files stay in the right user:group and access.

>> If we want to implement something like Kerberos we first must implement multi-user access, today if you have access to OpenDNSSEC tools you can do anything. If we redesign OpenDNSSEC for a multi-user environment in the future I would rather see PAM or similar systems integrated that will give access to even more ways to authenticate users.
> 
> The sort of things I proposed to put into the config files are, I suppose, what you mean with multi-user access.  Yes, that might be difficult to do in general.  In that setting, I suppose I'm proposing to not jump to the locally available Posix accounts without further thought.  Many users could share a Posix account ("www-data" for instance) to get constrained access to ODS based on their Kerberos credentials.

If they are sharing an account, in what ever way, to access OpenDNSSEC then its all outside of OpenDNSSEC and there is no need for multi-user support in OpenDNSSEC.

If OpenDNSSEC supports multi-user environments with access levels then they won't need a shared account since they have the access that is defined to them in what ever way they authenticate.

/Jerry

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 625 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130926/a8f3b4d2/attachment.bin>

From jerry at opendnssec.org  Thu Sep 26 14:27:18 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 26 Sep 2013 16:27:18 +0200
Subject: [Opendnssec-develop] Discussion of usability developments
In-Reply-To: <7E8D398D-7631-4B93-BF34-238C4F44512D@sinodun.com>
References: <7E8D398D-7631-4B93-BF34-238C4F44512D@sinodun.com>
Message-ID: <B9E66794-C3C1-4DE5-A226-8F100CC25A3C@opendnssec.org>

Hi,

On Sep 26, 2013, at 15:59 , Sara Dickinson wrote:

> As a result of discussions and the user survey we heard clearly from users that they would like some usability developments implemented to make their lives easier! It has take a while but here is a page where I have gathered together a (slightly) more detailed list of the developments we could consider for 1.3/1.4:
> 
> https://wiki.opendnssec.org/display/OpenDNSSEC/Usability+requirements


Instead of implementing email (please don't!) why not just add more events that users can configure to trigger scripts for and then they can decide what to do with the event.

/Jerry

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 625 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130926/bbc70601/attachment.bin>

From jad at sinodun.com  Thu Sep 26 16:17:36 2013
From: jad at sinodun.com (John Dickinson)
Date: Thu, 26 Sep 2013 16:17:36 +0000
Subject: [Opendnssec-develop] Discussion of usability developments
In-Reply-To: <B9E66794-C3C1-4DE5-A226-8F100CC25A3C@opendnssec.org>
References: <7E8D398D-7631-4B93-BF34-238C4F44512D@sinodun.com>
	<B9E66794-C3C1-4DE5-A226-8F100CC25A3C@opendnssec.org>
Message-ID: <C859CD9B-4DB7-4224-BE1C-BD337D258C8C@sinodun.com>


On 26 Sep 2013, at 14:27, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> Hi,
> 
> On Sep 26, 2013, at 15:59 , Sara Dickinson wrote:
> 
>> As a result of discussions and the user survey we heard clearly from users that they would like some usability developments implemented to make their lives easier! It has take a while but here is a page where I have gathered together a (slightly) more detailed list of the developments we could consider for 1.3/1.4:
>> 
>> https://wiki.opendnssec.org/display/OpenDNSSEC/Usability+requirements
> 
> 
> Instead of implementing email (please don't!) why not just add more events that users can configure to trigger scripts for and then they can decide what to do with the event.

IMHO: Adding additional events that the user can write scripts for doesn't make it easier for users. The whole point of this project is to make a push button DNSSEC implementation. Also, just adding more events could result in OpenDNSSEC developers troubleshooting users scripts.

How about adding more events and writing scripts that take their config from conf.xml and do useful things like email/xmpp/twitter? 

regards
John


---
jad at sinodun.com

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

+44 (0)1491 834957

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130926/d01a343c/attachment.bin>

From matthijs at nlnetlabs.nl  Fri Sep 27 06:29:34 2013
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Fri, 27 Sep 2013 08:29:34 +0200
Subject: [Opendnssec-develop] RE: Discussion of usability developments
In-Reply-To: <7E8D398D-7631-4B93-BF34-238C4F44512D@sinodun.com>
References: <7E8D398D-7631-4B93-BF34-238C4F44512D@sinodun.com>
Message-ID: <524525CE.7020705@nlnetlabs.nl>

Hi,

I don't understand the need for:

* Output 'ods-control summary' to syslog daily

And if such thing is necessary, I don't think it should include a list
of zones. At most, if you are interested if the signing was successful
or not, perhaps cap the list at 10 zones and/or only list the failed ones.

Best regards,
  Matthijs


On 09/26/2013 03:59 PM, Sara Dickinson wrote:
> Hi All, 
> 
> As a result of discussions and the user survey we heard clearly from users that they would like some usability developments implemented to make their lives easier! It has take a while but here is a page where I have gathered together a (slightly) more detailed list of the developments we could consider for 1.3/1.4:
> 
> https://wiki.opendnssec.org/display/OpenDNSSEC/Usability+requirements
> 
> I'm hoping we can do a general review of content and priority first, then I'll create some JIRA issues and send this out on the user list to get some more feedback. 
> 
> Thanks
> 
> Sara._______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 



From jerry at opendnssec.org  Fri Sep 27 07:21:57 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Fri, 27 Sep 2013 09:21:57 +0200
Subject: [Opendnssec-develop] Discussion of usability developments
In-Reply-To: <C859CD9B-4DB7-4224-BE1C-BD337D258C8C@sinodun.com>
References: <7E8D398D-7631-4B93-BF34-238C4F44512D@sinodun.com>
	<B9E66794-C3C1-4DE5-A226-8F100CC25A3C@opendnssec.org>
	<C859CD9B-4DB7-4224-BE1C-BD337D258C8C@sinodun.com>
Message-ID: <CAGTFMNYy58Nub3p_9-RsTCyE09_87pyfNgA-YqyQ1d9uuR_N+Q@mail.gmail.com>

On Thu, Sep 26, 2013 at 6:17 PM, John Dickinson <jad at sinodun.com> wrote:

>
> IMHO: Adding additional events that the user can write scripts for doesn't
> make it easier for users. The whole point of this project is to make a push
> button DNSSEC implementation. Also, just adding more events could result in
> OpenDNSSEC developers troubleshooting users scripts.
>

A push button DNSSEC system does not mean you have to add
email/xmpp/twitter functionality into the Enforcer or the Signer. What to
do with events can easily be managed by wizards and providing example
scripts.

How about adding more events and writing scripts that take their config
> from conf.xml and do useful things like email/xmpp/twitter?
>

+1 more events (we really need a lot more), +1 script examples, -1 config
in conf.xml.

They should have their own config files to separate them from the
Enforcer/Signer, not depend on XML format, not clog conf.xml and to make it
easier to package it separately.

/Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130927/6ff95fc3/attachment.htm>

From rick at openfortress.nl  Fri Sep 27 08:00:56 2013
From: rick at openfortress.nl (Rick van Rein (OpenFortress))
Date: Fri, 27 Sep 2013 10:00:56 +0200
Subject: [Opendnssec-develop] Database optimisation
Message-ID: <5F7FF646-F9FC-45B1-913C-F0A2D6A48DB4@openfortress.nl>

Youri, others,

When we discussed database optimisation yesterday, I got the feeling that some of the reasons for choosing a database are not well understood in the group.  So, hoping not to state too many obvious things, here's how I see the general approach of OpenDNSSEC following the same design flaw that underpins many websites as well.

SQL is a Set Query Language, and its operations are designed to work on sets, preferrably in bulk.  This means that overhead on queries are often an investment in efficient bulk handling.  The common use in OpenDNSSEC and web applications to use SQL for per-object queries risks the overhead without getting the appropriate "return on investment" that would have applied on bulk operations.

Overhead takes a number of shapes, but at least:
 - updating indexes when inserting, deleting or modifying indexes fields
 - locking to achieve ACID (Atomicity, Consistency, Isolation, Durability) properties (especially locks for individual rows can be inefficient -- and incorrect [1])
 - maintaining a split-brain data set to be able to rollback, possibly in two phases in support distributed transactions
 - deadlock avoidance algorithms (detecting cyclic dependencies on locks)
 - using a file system as a storage vehicle for a series of blocks
 - guarding consistency: foreign key properties

When MySQL started, they evaded many of these forms of overhead.  What they did, was introduce an intuitive notion that N queries of size 1 could run as efficiently as 1 query of size N.  In other words, that it did not matter that you did individual record queries.  The choices made were clear too -- locking was a matter of manually locking an entire table.  As soon as MySQL introduced transactions, I knew their performance would plummet, especially in those not-so-blik cases.  I think that is what we are experiencing now.

There are many alternatives to the SQL data model; usually they attack either the notion of bulk operation or the strong guarantees (well? [1]) provided by ACID.  Removing these assumptions underpinning your data model is often not at all harmful to your application, although it requires some explicit thought, but it will improve efficiency.  Given this, there are a few ways out I gues.

One would be to use MySQL without transactions; I don't know if you can mix it with MySQL and if the semantics are right, but inserting one record in one table is atomic and if it does wait for locks by transactions running, it would be possible to do this without the overhead of a transaction -- but not for one record in one table and another record in another table, you would risk problems with referetial integrity.  You could design your system to even work well in that setting, but this is not how the database layer of the Enforcer was? designed.

Another option is to collate information and offer it all in one set to OpenDNSSEC, *and* process it with a single INSERT statement or otherwise within one transaction.  The mention of multiple -z arguments and feeding a -Z filelist are the options that came up in that direction yesterday.  What I've seen of the KASP code suggests that it too doesn't make bulk queries, so it might be possible to improve things there too.

You could investigate the indexes that are setup (I looked but it looks like there aren't many -- although the foreign key references might create some).

Finally, and most importantly, you could choose a database model whose semantics better fit the purposes of OpenDNSSEC.  This would be a drama to introduce, so in practice it is probably a very remote option.  But it does take away the basic fault of using SQL for mostly singular lookups.  The other models are sometimes referred to as NoSQL databases; they do not include just frivolour-dataformat-of-the-day-over-HTTP but also stuff like text files, DBM, LDAP.  I already mentioned BerkeleyDB in the past, as a key->value database with redundancy (with self-recovery based on majority voting, much more advanced and useful than what MySQL does), thread support and so on.  LDAP is the option that runs on top of that if you need stronger query options including delivering lists that fulfil a property.   The limitation of LDAP is that it cannot join objects to form a larger object, and so you can filter on (attr1=3) or (attr2=*Rein) but not (att3=attr4).  I fully understand that LDAP is too far off for the project, and DBM probably lacks query luxoury, but it should be clear that we are then relying on a database paradigm that was not designed to do what we do with it.  There is one alternative that may be more suitable; Oracle provides a drop-in replacement for SQLite3 that is founded on BerkeleyDB.  Allas, I mentioned all of this before but not with the underpinning I'm giving here.

I wrote a series of articles entitled "Silly SQL" for the Dutch DB/M database magazine; since it's Dutch, I will send it directly to you.


I hope this is helpful,


Cheers,
 -Rick


[1] Row locking can only lock on data that has been seen, not data that has shown to not be present.  So-called "ghost entries" can be inserted by other transactions and leak into your transaction, possibly invalidating your assumptions that rows are not present in a table.  AFAIK, database engineers have never compared queries but only been focussing on row locking as the most refined form of concurrency control.




From jerry at opendnssec.org  Fri Sep 27 09:07:52 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Fri, 27 Sep 2013 11:07:52 +0200
Subject: [Opendnssec-develop] SoftHSM 1.3.5?
Message-ID: <CAGTFMNaxcq9LX8c0M0s1m8nPijk9Fdg1cRYXNq+fUfqmehgRmQ@mail.gmail.com>

Hi,

We got commits during 1.3.5rc1 that fixes warnings.

Shall we do another RC for a week or skip those commits?

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130927/b41b0f1c/attachment.htm>

From jakob at kirei.se  Fri Sep 27 09:28:43 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Fri, 27 Sep 2013 11:28:43 +0200
Subject: [Opendnssec-develop] SoftHSM 1.3.5?
In-Reply-To: <CAGTFMNaxcq9LX8c0M0s1m8nPijk9Fdg1cRYXNq+fUfqmehgRmQ@mail.gmail.com>
References: <CAGTFMNaxcq9LX8c0M0s1m8nPijk9Fdg1cRYXNq+fUfqmehgRmQ@mail.gmail.com>
Message-ID: <A08C9367-CFFA-4C98-96A5-7976ECFF2FB1@kirei.se>

On 27 sep 2013, at 11:07, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> Shall we do another RC for a week or skip those commits?

Can you show a diff?

	jakob



From jerry at opendnssec.org  Fri Sep 27 09:32:27 2013
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Fri, 27 Sep 2013 11:32:27 +0200
Subject: [Opendnssec-develop] SoftHSM 1.3.5?
In-Reply-To: <A08C9367-CFFA-4C98-96A5-7976ECFF2FB1@kirei.se>
References: <CAGTFMNaxcq9LX8c0M0s1m8nPijk9Fdg1cRYXNq+fUfqmehgRmQ@mail.gmail.com>
	<A08C9367-CFFA-4C98-96A5-7976ECFF2FB1@kirei.se>
Message-ID: <CAGTFMNbwj4huEtKPE5j4qw1Ex0NA_j7NsNGqDZdR1SY7azL2=Q@mail.gmail.com>

On Fri, Sep 27, 2013 at 11:28 AM, Jakob Schlyter <jakob at kirei.se> wrote:

>
> Can you show a diff?
>

You that lazy? :)

svn diff -r 7320:7321

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130927/feb0f40f/attachment.htm>

From rickard at opendnssec.org  Fri Sep 27 10:40:14 2013
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Fri, 27 Sep 2013 12:40:14 +0200
Subject: [Opendnssec-develop] SoftHSM 1.3.5?
In-Reply-To: <CAGTFMNbwj4huEtKPE5j4qw1Ex0NA_j7NsNGqDZdR1SY7azL2=Q@mail.gmail.com>
References: <CAGTFMNaxcq9LX8c0M0s1m8nPijk9Fdg1cRYXNq+fUfqmehgRmQ@mail.gmail.com>
	<A08C9367-CFFA-4C98-96A5-7976ECFF2FB1@kirei.se>
	<CAGTFMNbwj4huEtKPE5j4qw1Ex0NA_j7NsNGqDZdR1SY7azL2=Q@mail.gmail.com>
Message-ID: <CAKFiof=6+jQc0xBMyJojGVpHy3y7Nv5B=RjwUAMmcN9cTeoQnw@mail.gmail.com>

>
>
> svn diff -r 7320:7321
>
>
I switch from int to size_t in some places in order to fix the build
warning on EPEL.

// Rickard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130927/5aa4825c/attachment.htm>

From sara at sinodun.com  Sat Sep 28 15:42:21 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Sat, 28 Sep 2013 16:42:21 +0100
Subject: [Opendnssec-develop] Discussion of usability developments
In-Reply-To: <B9E66794-C3C1-4DE5-A226-8F100CC25A3C@opendnssec.org>
References: <7E8D398D-7631-4B93-BF34-238C4F44512D@sinodun.com>
	<B9E66794-C3C1-4DE5-A226-8F100CC25A3C@opendnssec.org>
Message-ID: <A4A079DD-FA19-42E1-888D-57018FCD5406@sinodun.com>


On 26 Sep 2013, at 15:27, Jerry Lundstr?m wrote:

> Hi,
> 
> On Sep 26, 2013, at 15:59 , Sara Dickinson wrote:
> 
>> As a result of discussions and the user survey we heard clearly from users that they would like some usability developments implemented to make their lives easier! It has take a while but here is a page where I have gathered together a (slightly) more detailed list of the developments we could consider for 1.3/1.4:
>> 
>> https://wiki.opendnssec.org/display/OpenDNSSEC/Usability+requirements
> 
> 
> Instead of implementing email (please don't!) why not just add more events that users can configure to trigger scripts for and then they can decide what to do with the event.
> 

Hi Jerry, 

So we have had several specific requests from users to provide an email notifications. We have also had a lot of feedback that users find OpenDNSSEC hard to configure, very had to monitor and they don't like the XML/script combination. These developments are an attempt to address some of those user concerns. 

The details of HOW we offer the ability to do email notification is obviously up for discussion but we need to be mindful that users want something simple for them (not necessarily simple for us) :-)

What is your specific technical objection to implementing email?

Sara. 



From jerry at opendnssec.org  Mon Sep 30 08:34:17 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 30 Sep 2013 10:34:17 +0200
Subject: [Opendnssec-develop] Maintenance of dist.opendnssec.org and SVN
	today Monday 13:30 - 14:00 CEST
Message-ID: <CE0CFF8E-5F82-46E6-A47D-EC5A0563A26A@opendnssec.org>

Hi,

I would like to do some maintenance work on the servers here at .SE so please don't use SVN during this time.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 625 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130930/288810ad/attachment.bin>

From jerry at opendnssec.org  Mon Sep 30 09:05:38 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 30 Sep 2013 11:05:38 +0200
Subject: [Opendnssec-develop] Discussion of usability developments
In-Reply-To: <A4A079DD-FA19-42E1-888D-57018FCD5406@sinodun.com>
References: <7E8D398D-7631-4B93-BF34-238C4F44512D@sinodun.com>
	<B9E66794-C3C1-4DE5-A226-8F100CC25A3C@opendnssec.org>
	<A4A079DD-FA19-42E1-888D-57018FCD5406@sinodun.com>
Message-ID: <D4BD073C-D02D-4EFB-80D5-F97BF752C39F@opendnssec.org>

On Sep 28, 2013, at 17:42 , Sara Dickinson wrote:

> The details of HOW we offer the ability to do email notification is obviously up for discussion but we need to be mindful that users want something simple for them (not necessarily simple for us) :-)
> 
> What is your specific technical objection to implementing email?


On the HOW; I object implementing email/xmpp/whatever support into the Enforcer and/or Signer because I don't think thats their purpose.

On the IF; Of course there should be ways to get notifications from our software, I feel we are lacking a lot here. This is somewhat also connected to the monitoring of OpenDNSSEC. If we could provide better logging, for example tagging log message with error/info codes etc for a lot easier parsing, implement a simple hook/event system and provide more tools and/or better output from existing tools then any system administrator will be able to integrate OpenDNSSEC with their environment being emails, XMPP or whatever. This essentially kills a few birds with the same stone.

/Jerry

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 625 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130930/b658881b/attachment.bin>

From jerry at opendnssec.org  Mon Sep 30 11:49:14 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 30 Sep 2013 13:49:14 +0200
Subject: [Opendnssec-develop] Re: Maintenance of dist.opendnssec.org and SVN
	today Monday 13:30 - 14:00 CEST
In-Reply-To: <CE0CFF8E-5F82-46E6-A47D-EC5A0563A26A@opendnssec.org>
References: <CE0CFF8E-5F82-46E6-A47D-EC5A0563A26A@opendnssec.org>
Message-ID: <84F142ED-9685-4156-9388-F469F2B0C12D@opendnssec.org>

On Sep 30, 2013, at 10:34 , Jerry Lundstr?m wrote:

> I would like to do some maintenance work on the servers here at .SE so please don't use SVN during this time.


Maintenance is done, feel free to use SVN.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 625 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130930/c0881467/attachment.bin>