From rickard at opendnssec.org  Mon Jun  6 08:11:19 2011
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Mon, 6 Jun 2011 10:11:19 +0200
Subject: [Opendnssec-develop] Re: Meetings in June
In-Reply-To: <BANLkTimD=bsWkeAu0iQosjiSa_28an0pWA@mail.gmail.com>
References: <BANLkTimD=bsWkeAu0iQosjiSa_28an0pWA@mail.gmail.com>
Message-ID: <BANLkTimNEXg-yOyDT6vBx89K0iqhb6aLAw@mail.gmail.com>

Hi everyone

I have now scheduled three meetings in June:

8th, Wednesday
16th, Thursday
29th, Wednesday

14 CEST, 13 BST (Hoping to keep them short).

// Rickard

On Thu, May 26, 2011 at 10:46 AM, Rickard Bellgrim
<rickard at opendnssec.org> wrote:
> Hi
>
> We should try to find some dates in June when we can have a telephone
> meeting between 14-15 CEST (13-14 BST).
>
> Could you please enter your information here:
> http://www.doodle.com/ax6vkkipfe5aipp2
>
> Thank you
> // Rickard
>


From rickard at opendnssec.org  Mon Jun  6 08:40:56 2011
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Mon, 6 Jun 2011 10:40:56 +0200
Subject: [Opendnssec-develop] Meeting on Wednesday (20110608)
Message-ID: <BANLkTi=Bgb8z0KJeCH6LB_xOyjA0MPfpvw@mail.gmail.com>

Hi everyone

A meeting is scheduled for Wednesday. 14 CEST, 13 BST.

http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-06-08

// Rickard


From matthijs at NLnetLabs.nl  Mon Jun  6 10:46:52 2011
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Mon, 06 Jun 2011 12:46:52 +0200
Subject: [Opendnssec-develop] Meeting on Wednesday (20110608)
In-Reply-To: <BANLkTi=Bgb8z0KJeCH6LB_xOyjA0MPfpvw@mail.gmail.com>
References: <BANLkTi=Bgb8z0KJeCH6LB_xOyjA0MPfpvw@mail.gmail.com>
Message-ID: <4DECB01C.3050200@nlnetlabs.nl>

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

There is a chance that I can't make it. My fault: I filled in the Doodle
incorrectly.

Matthijs

On 06/06/2011 10:40 AM, Rickard Bellgrim wrote:
> Hi everyone
> 
> A meeting is scheduled for Wednesday. 14 CEST, 13 BST.
> 
> http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-06-08
> 
> // Rickard
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

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

iQEbBAEBAgAGBQJN7LAcAAoJEA8yVCPsQCW5XcUH9inCZXmXMCd8R3q5exVgZFob
EsxLbNi4jQUwD+ZxPPGFZlAojM7bFMEuUz3NyDcwpbzzP+AAeXSK5yMsfzo35mgG
mYgFRsCsy3dnsbcg9UkGvOPhFjw/OFPhqt3uXnNEshPP8R1GwI/TOYqJX7Lfk+ho
1xETwB2MAdhEhCB4nQEFsNykoEHkegeyajGv/lAV7OgaUtAcvl1ToyZiaBovD7mZ
vVLbwTOLQtkSm0GzmlJg45NjSMJJcuj4nTRTMDsdKczKPAgvegboQQnewyzu6/4X
ZyEZsKjswrt1ftqstMFnI8Ed/sSXXaeGQaFaAhJovHxJZ7n7VHTlwh4TmmsQBQ==
=31sT
-----END PGP SIGNATURE-----


From yuri at NLnetLabs.nl  Mon Jun  6 15:05:13 2011
From: yuri at NLnetLabs.nl (Yuri Schaeffer)
Date: Mon, 06 Jun 2011 17:05:13 +0200
Subject: [Opendnssec-develop] Enforcer engine
Message-ID: <4DECECA9.9010101@nlnetlabs.nl>

Hi,

As stated in last (enforcer) teleconf, I was not completely happy about
the model. Last Friday night I decided sleep wasn't all that important
and came up with an alternative. I want to share it with you before a
next meeting, therefore I hastily compiled the attached document. It's a
bit rough on the edges so to say... sorry.

as far as I can see at has a couple of advantages in comparison with my
previous design:

- simpler to implement
- computationally far less complex (no nested 'exists' loops)
- explicit state for RRSIG DNSKEY (for better 5011 support)
   - and no mapping to signer configuration required.
- 'smooth transitions' by design
- self repairing to some extent
- Less (no) logical difference between ksk and zsk
- no need for NULL keys to switch between a signed and an unsigned zone

The design needs a little bit of tweaking before it's perfect. Also
attached is a python proof of concept. Undocumented of course. call with
'python prototype.py 2>/dev/null' for less debugging information.

doc and code can also be found in svn on home/yuri/enforcer_model2

//Yuri


-- 
Yuri Schaeffer
NLnet Labs
http://www.nlnetlabs.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enforcer_rules.pdf
Type: application/pdf
Size: 125136 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20110606/a2e97791/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: prototype.py
Type: text/x-python
Size: 4635 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20110606/a2e97791/attachment.py>

From Roland.vanRijswijk at surfnet.nl  Tue Jun  7 09:19:07 2011
From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 7 Jun 2011 11:19:07 +0200
Subject: [Opendnssec-develop] Meeting minutes of Enforcer TNG call 2011-06-07
Message-ID: <88CC0412-C8A6-4F22-A9A9-2AF793E888B1@surfnet.nl>

Hi guys,

The minutes are online: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-06-07

Please make changes as you see fit.

Cheers,

Roland

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl



From yuri at nlnetlabs.nl  Tue Jun  7 21:43:18 2011
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Tue, 07 Jun 2011 23:43:18 +0200
Subject: [Opendnssec-develop] Enforcer engine design v2 work breakdown
Message-ID: <1307482998.2608.95.camel@thorin>

Hi everyone,

In the teleconference about the enforcer this morning I was asked to
provide a breakdown of the work I think is necessary to switch to the
proposed model. This is it. Note that there are some extra points which
are not explicit in the requirements but are on the wish list for the
future (Such as 5011). I feel support for this should be done correctly
from the start, even when not providing an interface to the user for it
-yet-.

Document
--------
- The current document is very rudimentary and needs to explain the
algorithm more clear (and should use more natural language rather than
text!).
- Merge the previous document in this one "Roland: One document to rule
them all", keep the old one as reference.
- Improve notation (e.g. include signing algorithm in it)
- Work out the scenarios for a couple of different rollovers as
examples. This is also useful for Nick at a later stage of testing.
- Explain (and find out) why these rules are valid *and* sound.

Theory
---------
- Work out how to apply the 'minimize flags' to achieve different
rollover strategies. Must be better than gut feeling.
- Work out how a 5011 rollover would work in this model _exactly_.
- Formulate a rule that prevents the RRSIG DNSKEY to transition quicker
than the actual DNSKEY.
- Work out how 'normal' standby keys are supposed to work.

Code
-------------
- Figure out how the user indicates which rollover strategy it wants in
the kasp.xml (input request for all of you). 
- Replace the decision mechanism in the current enforcer-ng code.
- Introduce a function $f(x, y, p): t$ which indicates how much time a
record should at least spend in state x before transitioning to state y
given policy p. (This is currently very much intertwined in the
TransitionDecisionMechanism :-O )
- Introduce a state for the RRSIG DNSKEY in the database and interface
to the rest of the enforcer. (Rene already did this if I'm correct!)
- Figure out how the user should indicate that an insecure zone is okay
to have. How does this policy look like? (again, input request for all
of you)

regards,
Yuri




From sion at nominet.org.uk  Wed Jun  8 12:28:18 2011
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Wed, 8 Jun 2011 13:28:18 +0100
Subject: [Opendnssec-develop] Meeting on Wednesday (20110608)
In-Reply-To: <BANLkTi=Bgb8z0KJeCH6LB_xOyjA0MPfpvw@mail.gmail.com>
References: <BANLkTi=Bgb8z0KJeCH6LB_xOyjA0MPfpvw@mail.gmail.com>
Message-ID: <4DEF6AE2.2020908@nominet.org.uk>

On 06/06/11 09:40, Rickard Bellgrim wrote:
> Hi everyone
>
> A meeting is scheduled for Wednesday. 14 CEST, 13 BST.
>
> http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-06-08
>
> // Rickard
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

Minutes posted:

http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-06-08

Sion


From AlexD at nominet.org.uk  Wed Jun  8 12:37:02 2011
From: AlexD at nominet.org.uk (Alex Dalitz)
Date: Wed, 8 Jun 2011 12:37:02 +0000
Subject: [Opendnssec-develop] Auditor and adaptors
Message-ID: <E1659390-20D7-41AB-BA57-62F4273834AB@nominet.org.uk>

Hi  -

I have an outstanding action to kick off a discussion on the mailing list about how the auditor should interact with the new adaptors.

Perhaps we could start by defining the functionality of the new adaptors?

Thanks,


Alex.

From sion at nominet.org.uk  Wed Jun  8 13:33:49 2011
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Wed, 8 Jun 2011 14:33:49 +0100
Subject: [Opendnssec-develop] sqlite backup
Message-ID: <4DEF7A3D.20306@nominet.org.uk>

So it seems that the sqlite developers are aware of the limitations of 
.dump but it is correct behaviour:

http://www.sqlite.org/cvstrac/tktview?tn=2223,39


If the version of sqlite3 is >= 3.6.11 then the following should work:

sqlite3 <path to your token> ".backup copy.db"

Otherwise, or if dump has been used, then the pragma will need to be 
added back in manually.

I can add this to the end of:

http://trac.opendnssec.org/wiki/SoftHSM/Install

But I don't think that I have permissions to update:

http://www.opendnssec.org/documentation/using-softhsm/



Sion


From rickard at opendnssec.org  Thu Jun  9 09:33:20 2011
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Thu, 9 Jun 2011 11:33:20 +0200
Subject: [Opendnssec-develop] sqlite backup
In-Reply-To: <4DEF7A3D.20306@nominet.org.uk>
References: <4DEF7A3D.20306@nominet.org.uk>
Message-ID: <BANLkTikg8GeUAXswhSph=Mu=SAW5O6QXnw@mail.gmail.com>

Thanks Sion for finding the information.

I have updated the relevant texts.

// Rickard

On Wed, Jun 8, 2011 at 3:33 PM, Si?n Lloyd <sion at nominet.org.uk> wrote:
> So it seems that the sqlite developers are aware of the limitations of .dump
> but it is correct behaviour:
>
> http://www.sqlite.org/cvstrac/tktview?tn=2223,39
>
>
> If the version of sqlite3 is >= 3.6.11 then the following should work:
>
> sqlite3 <path to your token> ".backup copy.db"
>
> Otherwise, or if dump has been used, then the pragma will need to be added
> back in manually.
>
> I can add this to the end of:
>
> http://trac.opendnssec.org/wiki/SoftHSM/Install
>
> But I don't think that I have permissions to update:
>
> http://www.opendnssec.org/documentation/using-softhsm/
>
>
>
> Sion
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>


From matthijs at NLnetLabs.nl  Thu Jun  9 13:36:54 2011
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Thu, 09 Jun 2011 15:36:54 +0200
Subject: [Opendnssec-develop] Enforcer engine design v2 work breakdown
Message-ID: <4DF0CC76.50005@nlnetlabs.nl>

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

On 06/07/2011 11:43 PM, Yuri Schaeffer wrote:
> Code
> -------------
> - Figure out how the user indicates which rollover strategy it wants in
> the kasp.xml (input request for all of you).

I would suggest something in the line of this:

- --- kasp.xml.in	(revision 5201)
+++ kasp.xml.in	(working copy)
@@ -50,6 +50,7 @@

 			<!-- Parameters for KSK only -->
 			<KSK>
+				<RolloverType>DoubleDS</RolloverType>
 				<Algorithm length="2048">8</Algorithm>
 				<Lifetime>P1Y</Lifetime>
 				<Repository>SoftHSM</Repository>
@@ -57,6 +58,7 @@

 			<!-- Parameters for ZSK only -->
 			<ZSK>
+			<RolloverType>Prepublication</RolloverType>
 				<Algorithm length="1024">8</Algorithm>
 				<Lifetime>P30D</Lifetime>
 				<Repository>SoftHSM</Repository>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN8Mx2AAoJEA8yVCPsQCW5zOMIAJpX/AtngPfZ0oYsxD/p7klf
Sg5+gAdiay/sTbjtSRbuJkbFNXJIBkSFDnfCwgi77o6qtZmBjiOCXWfi/cEYNCuW
5XURUc55a0ihEUyDq4GXgfh1JlTBTvYuSyT6gsedPOigv0VbdoCXuX1XhDpCZPTi
aXbZGuux/S65SxggiedOikbfHVn3sPAeDfXXeMAE11Q63baSChJ0/WETtbOIx6E4
QwMBo129VpxV+pOichg8VmgnG6wv+S4/Zt8V8ZyF/jzj0+esjGVqItbeuO217EJp
fuOY2TKvuxWMU1k/ZBRNLGZqTniqOdCRVI5dkCrJY8nklNeI6URzYINDWIcbZQc=
=8OIo
-----END PGP SIGNATURE-----


From rickard at opendnssec.org  Fri Jun 10 06:34:08 2011
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Fri, 10 Jun 2011 08:34:08 +0200
Subject: [Opendnssec-develop] Refresh == 0S
Message-ID: <BANLkTin92vQJU5T2aA5mQmMYJmAzMJsViQ@mail.gmail.com>

Hello

I was wondering if the zero second refresh is an undocumented feature?

If you set it to zero, then you disable signature re-usage and all
signatures are regenerated each time.

// Rickard


From rickard at opendnssec.org  Fri Jun 10 12:01:21 2011
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Fri, 10 Jun 2011 14:01:21 +0200
Subject: [Opendnssec-develop] Enforcer engine design v2 work breakdown
In-Reply-To: <1307482998.2608.95.camel@thorin>
References: <1307482998.2608.95.camel@thorin>
Message-ID: <BANLkTikSm5cH9SABehQ4OmEk6Dmc6D6_iA@mail.gmail.com>

On Tue, Jun 7, 2011 at 11:43 PM, Yuri Schaeffer <yuri at nlnetlabs.nl> wrote:
> - Work out how 'normal' standby keys are supposed to work.

By 'normal' standby keys, do we mean the standby keys that we can
store in a separate repository?

But the standby keys can be saved for later. It is more important to
get the alpha version ready.

> - Figure out how the user should indicate that an insecure zone is okay
> to have. How does this policy look like? (again, input request for all
> of you)

Perhaps just naming the policy "unsigned" in zonelist?

// Rickard


From owner-dnssec-trac at kirei.se  Wed Jun 15 01:50:32 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Wed, 15 Jun 2011 01:50:32 -0000
Subject: [Opendnssec-develop] [OpenDNSSEC] #244: Feature request: add
 'delete keys' option to ods-ksmutil
Message-ID: <078.8bcc35c1e1596650d36eb5fe3c61ac13@kirei.se>

#244: Feature request: add 'delete keys' option to ods-ksmutil
-----------------------------------------------------+----------------------
Reporter:  Sebastian Castro <sebastian@?>            |       Owner:  sion    
    Type:  enhancement                               |      Status:  new     
Priority:  minor                                     |   Component:  Enforcer
 Version:  trunk                                     |    Keywords:          
-----------------------------------------------------+----------------------
 We came across a use case for deleting keys from the HSM/KASP.
 During testing we created a few keys with ods-ksmutil, which later were
 deleted using ods-hsmutil. The problem is those keys who have never been
 used left a trace on the KASP, and there is no way (unless to hack into
 the KASP) to delete those traces.

 Let's assume that an operator has a policy with keys of certain size, and
 pre-generates a pool of keys for a long period. If at some point during
 that period they need to change the key size of the policy, and generate
 new keys, they will end up with a few unused keys who will sit-up forever
 in the HSM and the KASP. Those keys won't be deleted by "purge", because
 they are not in DEAD state.

 The proposed interface for the command could be
 ods-ksmutil key delete --cka_id LOCATOR [--force]

 If the key is in the GENERATE state, could be deleted without any side
 effect.
 If the key is in any other state, the key won't be deleted and the command
 will complain. That behavior can be overridden by the --force option.

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/244>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From owner-dnssec-trac at kirei.se  Wed Jun 15 05:06:42 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Wed, 15 Jun 2011 05:06:42 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #242: Race condition when
 receiving multiple NOTIFIES for a zone
In-Reply-To: <078.a9b4bb255040558f07a1d4ffcd8a4f92@kirei.se>
References: <078.a9b4bb255040558f07a1d4ffcd8a4f92@kirei.se>
Message-ID: <093.754ddb78e04ce48691c21012f4e8c96b@kirei.se>

#242: Race condition when receiving multiple NOTIFIES for a zone
-----------------------------------------------------+----------------------
Reporter:  Sebastian Castro <sebastian@?>            |        Owner:  matthijs
    Type:  defect                                    |       Status:  accepted
Priority:  major                                     |    Component:  Signer  
 Version:  1.2.1                                     |   Resolution:          
Keywords:                                            |  
-----------------------------------------------------+----------------------

Comment (by Sebastian Castro <sebastian@?>):

 My apologies for taking two weeks to respond. The patch is working.

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/242#comment:2>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From owner-dnssec-trac at kirei.se  Wed Jun 15 08:38:43 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Wed, 15 Jun 2011 08:38:43 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #242: Race condition when
 receiving multiple NOTIFIES for a zone
In-Reply-To: <078.a9b4bb255040558f07a1d4ffcd8a4f92@kirei.se>
References: <078.a9b4bb255040558f07a1d4ffcd8a4f92@kirei.se>
Message-ID: <093.c7ef88860e220ebe46a0df505324da7f@kirei.se>

#242: Race condition when receiving multiple NOTIFIES for a zone
-----------------------------------------------------+----------------------
Reporter:  Sebastian Castro <sebastian@?>            |        Owner:  matthijs
    Type:  defect                                    |       Status:  closed  
Priority:  major                                     |    Component:  Signer  
 Version:  1.2.1                                     |   Resolution:  fixed   
Keywords:                                            |  
-----------------------------------------------------+----------------------
Changes (by matthijs):

  * status:  accepted => closed
  * resolution:  => fixed


Comment:

 No worries. Thanks for your response.

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/242#comment:3>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From rickard at opendnssec.org  Thu Jun 16 07:34:19 2011
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Thu, 16 Jun 2011 09:34:19 +0200
Subject: [Opendnssec-develop] Meeting today
Message-ID: <BANLkTiks-4T_cYEZVRPJNnVx3UcX7JfKcw@mail.gmail.com>

Hi

Today we have an OpenDNSSEC telephone meeting.

Date: Thursday 16 June
Time: 14:00-15:00 CEST, 13:00-14:00 BST

Agenda:
http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-06-16

// Rickard


From matthijs at NLnetLabs.nl  Thu Jun 16 13:11:06 2011
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Thu, 16 Jun 2011 15:11:06 +0200
Subject: [Opendnssec-develop] Minutes Thu Jun 16 2011
Message-ID: <4DFA00EA.5030906@nlnetlabs.nl>

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

http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-06-16

About the auditor. I really thought it was going to be disabled in
feature releases, when the code has become more mature. I thought we
decided that in Stockholm, Feb 2011. Eventually we already wanted to do
that already in 1.3, but I said it might be better to do it later, as I
was just introducing the drudgers. I wanted to look it up in the
minutes, but I couldn't find them (are there any?)

Also, Alex has suggested this in his mail to the develop list on Auditor
Support (02/03/2011 03:06 PM).


Best regards,
 Matthijs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN+gDqAAoJEA8yVCPsQCW5KQwIAIdkrjfN/xM0mQFpVGLUuSdb
9cY3T2gM+F/gfQSJL4YIf5bEnkw227gBIZKTHMz7d+4BBaOdxmi5aJHi/CCpkVDf
y8IPyxAPOvuPvkJIliDQcecp2CBac1R0XeB53gF697d3Demwgrq3jMv7Fo6s+baG
PN8cfXcclF8z2+vNFvYBI2KqacXjnhWV0jTeKiCEiaBe/Q3NrJtRwk0NloJ7FO2E
iV0iUYswgTvbpNMWM6Urb45zYh1gIYvyj4H93cE/wbv7Z3ilzo5J8+LuQWoLM7ma
61BM5pt86a8lYSn9C+T/Twc4dWrp0rPrZ1l8cGG7XDOcV4KcKtROPvzLj9PH8b4=
=NN7F
-----END PGP SIGNATURE-----


From owner-dnssec-trac at kirei.se  Thu Jun 16 13:36:10 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Thu, 16 Jun 2011 13:36:10 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #244: Feature request: add
 'delete keys' option to ods-ksmutil
In-Reply-To: <078.8bcc35c1e1596650d36eb5fe3c61ac13@kirei.se>
References: <078.8bcc35c1e1596650d36eb5fe3c61ac13@kirei.se>
Message-ID: <093.564dc89c45e9be349fb749126b2e4070@kirei.se>

#244: Feature request: add 'delete keys' option to ods-ksmutil
-----------------------------------------------------+----------------------
Reporter:  Sebastian Castro <sebastian@?>            |        Owner:  sion    
    Type:  enhancement                               |       Status:  accepted
Priority:  minor                                     |    Component:  Enforcer
 Version:  trunk                                     |   Resolution:          
Keywords:                                            |  
-----------------------------------------------------+----------------------
Changes (by sion):

  * status:  new => accepted


Comment:

 This sounds reasonable; I've added a story to our pivotal tracker for it.

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/244#comment:1>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From owner-dnssec-trac at kirei.se  Thu Jun 16 14:01:05 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Thu, 16 Jun 2011 14:01:05 -0000
Subject: [Opendnssec-develop] [OpenDNSSEC] #245: Signer daemon keeps running
 after signing large zone
Message-ID: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se>

#245: Signer daemon keeps running after signing large zone
--------------------------------+-------------------------------------------
Reporter:  Nick van den Heuvel  |       Owner:  rb      
    Type:  defect               |      Status:  new     
Priority:  major                |   Component:  Unknown 
 Version:  1.3.0                |    Keywords:  1.3.0rc2
--------------------------------+-------------------------------------------
 Last week I had the problem (with ODS 1.3.0rc2), that after the signing of
 a large zone (> 4M domeinnames) de signer daemon keeps running. The memory
 usage remains the same as during the signing. Closing the signer daemon
 down by using "ods-control stop" was not succesful: The message "Stopping
 Enforcer"stayed on the screen in the terminal.

 Yesterday I tried to reproduce it with succes. Voor the signing I did use
 the .nl zone from March 2011, in which 50 % DS has been added. I have
 signed the zone on my werkstation (Ubuntu 10.04 64 bit, 8 Gb ram, Intel
 core 2 duo @ 3,33 GHZ, ODS 1.3.0rc2). The memory usage was 100 % (8Gb +
 6,6 Swap memory (which is slow, but soit).

 In the attacment, you see the syslog. The behaveour of ODS seem not right.
 I would expect that after ODS signs the zone, de signer daemon is stopped
 by the enforcer and the memory usage will lower to the usage before
 signing.

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/245>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From jakob at kirei.se  Fri Jun 17 13:08:19 2011
From: jakob at kirei.se (Jakob Schlyter)
Date: Fri, 17 Jun 2011 15:08:19 +0200
Subject: [Opendnssec-develop] Minutes Thu Jun 16 2011
In-Reply-To: <4DFA00EA.5030906@nlnetlabs.nl>
References: <4DFA00EA.5030906@nlnetlabs.nl>
Message-ID: <1FE9786D-5FF3-45F3-86DE-667CEBE44F6D@kirei.se>

On 16 jun 2011, at 15.11, Matthijs Mekking wrote:

> About the auditor. I really thought it was going to be disabled in
> feature releases, when the code has become more mature. I thought we
> decided that in Stockholm, Feb 2011. Eventually we already wanted to do
> that already in 1.3, but I said it might be better to do it later, as I
> was just introducing the drudgers. I wanted to look it up in the
> minutes, but I couldn't find them (are there any?)

Yes, we've said we will disable it by default, but not remove it.

	jakob



From yuri at NLnetLabs.nl  Tue Jun 21 10:46:03 2011
From: yuri at NLnetLabs.nl (Yuri Schaeffer)
Date: Tue, 21 Jun 2011 12:46:03 +0200
Subject: [Opendnssec-develop] Enforcer engine
In-Reply-To: <4DECECA9.9010101@nlnetlabs.nl>
References: <4DECECA9.9010101@nlnetlabs.nl>
Message-ID: <4E00766B.4020105@nlnetlabs.nl>

Hi,

Attached you will find the newest version of this document. It is
largely complete but might still receive updates in the coming days.
However, I think it is useable for anyone joining the enforcer-ng
teleconf next Thursday.

A newer version might be found in svn at any time
/home/yuri/enforcer_model2/

Regards,
Yuri

-- 
Yuri Schaeffer
NLnet Labs
http://www.nlnetlabs.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enforcer_rules.pdf
Type: application/pdf
Size: 217943 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20110621/8b9f9ab4/attachment.pdf>

From yuri at NLnetLabs.nl  Tue Jun 21 15:16:02 2011
From: yuri at NLnetLabs.nl (Yuri Schaeffer)
Date: Tue, 21 Jun 2011 17:16:02 +0200
Subject: [Opendnssec-develop] Enforcer engine
In-Reply-To: <4E00766B.4020105@nlnetlabs.nl>
References: <4DECECA9.9010101@nlnetlabs.nl> <4E00766B.4020105@nlnetlabs.nl>
Message-ID: <4E00B5B2.9060902@nlnetlabs.nl>

erratum:

> A newer version might be found in svn at any time
> /home/yuri/enforcer_model2/

I made an error in the rules after someone made a suggestion for a
better notation.
The first few characters of rule 2 must state:
	There exist no key with its DS rumoured
But I erroneously changed it in to
	There exist a key with its DS not rumoured

Rule 3 had a similar problem.

If someone is _really_ motivated to understand the rules, the new
version can be found in svn.

Regards,
Yuri

-- 
Yuri Schaeffer
NLnet Labs
http://www.nlnetlabs.nl


From rickard at opendnssec.org  Tue Jun 21 15:17:22 2011
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Tue, 21 Jun 2011 17:17:22 +0200
Subject: [Opendnssec-develop] Enforcer engine
In-Reply-To: <4E00766B.4020105@nlnetlabs.nl>
References: <4DECECA9.9010101@nlnetlabs.nl>
	<4E00766B.4020105@nlnetlabs.nl>
Message-ID: <BANLkTikYQL=VxjEt133u64vSOQOo7FdHjQ@mail.gmail.com>

Thanks, great document.

Questions:

* The key "i" in the rules indicates all keys, right?

* ZSK Double Signature rollover is said to be fastest. But what if
TTL(key)=1 and TTL(sig)=3?
ZSK Double Signature rollover: 2xMaxTTL(key,sig) = 6
ZSK Pre-Pubplucation[sic] rollover: 2xTTL(key) + TTL(sig) = 5



On Tue, Jun 21, 2011 at 12:46 PM, Yuri Schaeffer <yuri at nlnetlabs.nl> wrote:
> Hi,
>
> Attached you will find the newest version of this document. It is
> largely complete but might still receive updates in the coming days.
> However, I think it is useable for anyone joining the enforcer-ng
> teleconf next Thursday.
>
> A newer version might be found in svn at any time
> /home/yuri/enforcer_model2/
>
> Regards,
> Yuri
>
> --
> Yuri Schaeffer
> NLnet Labs
> http://www.nlnetlabs.nl
>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>
>


From yuri at nlnetlabs.nl  Wed Jun 22 09:37:18 2011
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Wed, 22 Jun 2011 11:37:18 +0200
Subject: [Opendnssec-develop] Enforcer engine
In-Reply-To: <BANLkTikYQL=VxjEt133u64vSOQOo7FdHjQ@mail.gmail.com>
References: <4DECECA9.9010101@nlnetlabs.nl>	<4E00766B.4020105@nlnetlabs.nl>
	<BANLkTikYQL=VxjEt133u64vSOQOo7FdHjQ@mail.gmail.com>
Message-ID: <4E01B7CE.7010205@nlnetlabs.nl>

> * The key "i" in the rules indicates all keys, right?

The subscript i indicates the current key which we try to bring to the
next state. It is true we need to do this for all keys (at least once
per run).

Subscripts x, y, z indicate *some* key with the same algorithm as key i.

> * ZSK Double Signature rollover is said to be fastest. But what if
> TTL(key)=1 and TTL(sig)=3?
> ZSK Double Signature rollover: 2xMaxTTL(key,sig) = 6
> ZSK Pre-Pubplucation[sic] rollover: 2xTTL(key) + TTL(sig) = 5

Nice catch, I see you are awake. Actually I tripped over this myself
yesterday as well. As of r5239 it is corrected in the repository.

ZSK Double Signature is indeed faster. The correct Total should actually
be: TTL(key) + TTL(sig) = 4

The fast set must wait with introducing the new key till the slow set
has introduced the new key. The time gain is when the new key is
introduced for the fast set, the old key can _already_ outroduce for the
slow set.

This is the output the prototype gives for this scenario:
Records in the same order as in the document's tables.

     key 0 (out) |     key 1 (out) |      key 2 (in) | T
----------------------------------------------------------
 OMN,OMN,OMN,--- | ---,OMN,---,OMN | ---,HID,---,HID | None
 OMN,OMN,OMN,--- | ---,OMN,---,OMN | ---,RUM,---,RUM | 0
 OMN,OMN,OMN,--- | ---,OMN,---,UNR | ---,OMN,---,RUM | 1
 OMN,OMN,OMN,--- | ---,UNR,---,UNR | ---,OMN,---,OMN | 3
 OMN,OMN,OMN,--- | ---,HID,---,HID | ---,OMN,---,OMN | 4

//yuri



From roland.vanrijswijk at surfnet.nl  Thu Jun 23 13:52:18 2011
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Thu, 23 Jun 2011 15:52:18 +0200
Subject: [Opendnssec-develop] Minutes for Enforcer TNG meeting 2011-06-23
Message-ID: <7019F3FB-A5E8-4C59-87D7-8ED282C040F2@surfnet.nl>

Hi guys,

Minutes are here: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-06-23

Please add any additional information that you feel I've forgotten to include ;-)

Cheers,

Roland

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl



From matthijs at NLnetLabs.nl  Thu Jun 23 14:06:43 2011
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Thu, 23 Jun 2011 16:06:43 +0200
Subject: [Opendnssec-develop] Minutes for Enforcer TNG meeting 2011-06-23
In-Reply-To: <7019F3FB-A5E8-4C59-87D7-8ED282C040F2@surfnet.nl>
References: <7019F3FB-A5E8-4C59-87D7-8ED282C040F2@surfnet.nl>
Message-ID: <4E034873.2010700@nlnetlabs.nl>

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

The example from George Barwood I mentioned on the AOB topic on Single
Type Signing Scheme rollovers. This rollover is perfectly valid if you
don't restrict that DNSKEY RR and its RRSIG(DNSKEY) travel together.

http://www.ietf.org/mail-archive/web/dnsop/current/msg09081.html

Best regards,
Matthijs

On 06/23/2011 03:52 PM, Roland van Rijswijk wrote:
> Hi guys,
> 
> Minutes are here: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-06-23
> 
> Please add any additional information that you feel I've forgotten to include ;-)
> 
> Cheers,
> 
> Roland
> 
> -- Roland M. van Rijswijk
> -- SURFnet Middleware Services
> -- t: +31-30-2305388
> -- e: roland.vanrijswijk at surfnet.nl
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 

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

iQEcBAEBAgAGBQJOA0hzAAoJEA8yVCPsQCW5tUsIAIM8dxXUGwb58I5FBHwhdPQl
2FY+rXVn73gbRKhoQpfMZPyYHv7Ou0k2otnJVtPUHhkc0yXRj122beHp7wn/N9tT
K3dPj4Bs4uxNfI/Xdwple9YtMylRjGwLJiV1ovgamV7TyDq0a/1dbF9qqH4KOz39
JPuCWdTprYAAyXl0DwtWYxjzGpU/B21mmQLdM0Ovy16HH2GloKb/RpXyuKaDE5e3
uZYoy8fK7J0UaJCGWVXCLXZPZDOkWpZQx86UEa0lFrjVQv9VPyj2OtIstsH8pvOF
izn5niDqbny0s8CqbnGaAXvJwaWbxuvLBCVg3JfPijmYbXAxAh+oTaS9ufyZ/yo=
=ximl
-----END PGP SIGNATURE-----


From owner-dnssec-trac at kirei.se  Fri Jun 24 12:43:42 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Fri, 24 Jun 2011 12:43:42 -0000
Subject: [Opendnssec-develop] [OpenDNSSEC] #246: Kaspcheck validates
 kasp.xml when NSEC3 algorithm is 0
Message-ID: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se>

#246: Kaspcheck validates kasp.xml when NSEC3 algorithm is 0
--------------------------------+-------------------------------------------
Reporter:  Nick van den Heuvel  |       Owner:  rb      
    Type:  defect               |      Status:  new     
Priority:  minor                |   Component:  Unknown 
 Version:  1.3.0                |    Keywords:  1.3.0rc3
--------------------------------+-------------------------------------------
 Teststeps:
     * Use kasp.xml were NSEC3 algorithm is 0 (instead of 1)
     * Update configuration
     * Check if ods-kaspcheck fails

 Expected result:
     * ods-kaspcheck fails for kasp.xml
     * warning that the algorithm value is wrong

 Observed result:

     * ods-kaspcheck validates
     * warning that the algorithm value is wrong

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/246>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From owner-dnssec-trac at kirei.se  Tue Jun 28 08:24:31 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Tue, 28 Jun 2011 08:24:31 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps
 running after signing large zone
In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se>
References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se>
Message-ID: <072.f406aaa3ba7113386f85cab05ead7937@kirei.se>

#245: Signer daemon keeps running after signing large zone
--------------------------------+-------------------------------------------
Reporter:  Nick van den Heuvel  |        Owner:  rb     
    Type:  defect               |       Status:  new    
Priority:  major                |    Component:  Unknown
 Version:  1.3.0                |   Resolution:         
Keywords:  1.3.0rc2             |  
--------------------------------+-------------------------------------------

Comment (by rb):

 The Signer Engine will not lower its memory usage after the signing has
 been done. This is because all of the signatures are kept in memory.

 The Enforcer will not stop the Signer Engine. They act as two separate
 daemons that will run until they are stopped. '''sudo ods-control stop'''
 will call '''sudo ods-ksmutil stop''' and '''sudo ods-signer stop'''.

 Are you running the latest SoftHSM? SoftHSM 1.2.1 will increase the
 performance. Or maybe 565 signatures per seconds is the maximum on your
 machine.

 It sound like the problem is that the Enforcer does not stop.

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/245#comment:1>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From owner-dnssec-trac at kirei.se  Tue Jun 28 08:31:49 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Tue, 28 Jun 2011 08:31:49 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #246: Kaspcheck validates
 kasp.xml when NSEC3 algorithm is 0
In-Reply-To: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se>
References: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se>
Message-ID: <072.9a23e6aa02c035d7ff2b1ed4e603fdd4@kirei.se>

#246: Kaspcheck validates kasp.xml when NSEC3 algorithm is 0
--------------------------------+-------------------------------------------
Reporter:  Nick van den Heuvel  |        Owner:  rb     
    Type:  defect               |       Status:  new    
Priority:  minor                |    Component:  Unknown
 Version:  1.3.0                |   Resolution:         
Keywords:  1.3.0rc3             |  
--------------------------------+-------------------------------------------

Comment (by rb):

 I get this in the latest v1.3

 {{{
 rickard at fou:~$ sudo ods-kaspcheck
 /etc/opendnssec/conf.xml validates
 /home/rickard/opendnssec/kasp.xml validates
 WARNING: Keys/PublishSafety (0 seconds) in Policy1 policy in
 /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (60 seconds)
 WARNING: Keys/RetireSafety (0 seconds) in Policy1 policy in
 /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (60 seconds)
 WARNING: Keys/PublishSafety (0 seconds) in Policy2 policy in
 /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (900 seconds)
 WARNING: Keys/RetireSafety (0 seconds) in Policy2 policy in
 /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (900 seconds)
 ERROR: NSEC3 Hash algorithm is 0 but should be 1

 rickard at fou:~$ sudo ods-ksmutil update kasp
 MySQL database schema set to: opendnssec
 MySQL database user set to: opendnssec
 MySQL database password set
 zonelist filename set to /home/rickard/opendnssec/zonelist.xml.
 kasp filename set to /home/rickard/opendnssec/kasp.xml.
 /etc/opendnssec/conf.xml validates
 /home/rickard/opendnssec/kasp.xml validates
 WARNING: Keys/PublishSafety (0 seconds) in Policy1 policy in
 /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (60 seconds)
 WARNING: Keys/RetireSafety (0 seconds) in Policy1 policy in
 /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (60 seconds)
 WARNING: Keys/PublishSafety (0 seconds) in Policy2 policy in
 /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (900 seconds)
 WARNING: Keys/RetireSafety (0 seconds) in Policy2 policy in
 /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (900 seconds)
 ERROR: NSEC3 Hash algorithm is 0 but should be 1
 ods-kaspcheck returned an error, please check your policy
 Failed to update policies
 }}}

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/246#comment:1>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From rickard at opendnssec.org  Tue Jun 28 08:46:30 2011
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Tue, 28 Jun 2011 10:46:30 +0200
Subject: [Opendnssec-develop] Meeting 20110629
Message-ID: <BANLkTi=tpQ-NigFXBOvFbSb0vnu8ZO9gDw@mail.gmail.com>

Hi

A reminder that we will have a telephone meeting tomorrow at 14 CET.

http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-06-29

// Rickard


From owner-dnssec-trac at kirei.se  Tue Jun 28 12:19:40 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Tue, 28 Jun 2011 12:19:40 -0000
Subject: [Opendnssec-develop] [OpenDNSSEC] #247: Hang signer processes after
 receiving several notifies in succession
Message-ID: <056.168398051f6878f3b30e025dabd6d8c8@kirei.se>

#247: Hang signer processes after receiving several notifies in succession
-------------------------------+--------------------------------------------
Reporter:  goeran@?            |       Owner:  matthijs              
    Type:  defect              |      Status:  new                   
Priority:  major               |   Component:  Signer                
 Version:  1.3.0               |    Keywords:  signer, hang, notifies
-------------------------------+--------------------------------------------
 A reproducable problem with 1.3.0rc3 on Red Hat Enterprise Linux 5.6.

 4 notifies (with increasing s/n) sent to OpenDNSSEC in less than 30
 seconds
 cause a hang OpenDNSSEC signer process blocking signing for the zone in
 question and prevening normal OpenDNSSEC shutdown.

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/247>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From owner-dnssec-trac at kirei.se  Wed Jun 29 07:13:21 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Wed, 29 Jun 2011 07:13:21 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #247: Hang signer processes
 after receiving several notifies in succession
In-Reply-To: <056.168398051f6878f3b30e025dabd6d8c8@kirei.se>
References: <056.168398051f6878f3b30e025dabd6d8c8@kirei.se>
Message-ID: <071.3470b444aa5e597c7a0ca8150fef4a39@kirei.se>

#247: Hang signer processes after receiving several notifies in succession
-----------------------------------+----------------------------------------
Reporter:  goeran@?                |        Owner:  matthijs
    Type:  defect                  |       Status:  new     
Priority:  major                   |    Component:  Signer  
 Version:  1.3.0                   |   Resolution:          
Keywords:  signer, hang, notifies  |  
-----------------------------------+----------------------------------------

Comment (by anonymous):

 The last problem (a ods-signer process consuming CPU in a
 clock_gettime(CLOCK_REALTIME, {1309331467, 567112892}) = 0
 futex(0x97fc2d0, FUTEX_WAIT_PRIVATE, 37, {72, 54513804}
 loop (and blocking furher signing) can also be
 triggered by repeated ods-signer sign <zone>.

   / G?ran

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/247#comment:1>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From owner-dnssec-trac at kirei.se  Wed Jun 29 07:27:09 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Wed, 29 Jun 2011 07:27:09 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #246: Kaspcheck validates
 kasp.xml when NSEC3 algorithm is 0
In-Reply-To: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se>
References: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se>
Message-ID: <072.ec103cd8c9faece341828d313b854f1c@kirei.se>

#246: Kaspcheck validates kasp.xml when NSEC3 algorithm is 0
--------------------------------+-------------------------------------------
Reporter:  Nick van den Heuvel  |        Owner:  rb     
    Type:  defect               |       Status:  new    
Priority:  minor                |    Component:  Unknown
 Version:  1.3.0                |   Resolution:         
Keywords:  1.3.0rc3             |  
--------------------------------+-------------------------------------------

Comment (by Nick van den Heuvel):

 Did you get this result with the 1.3.0rc3 release or the latest version
 from the trunk?

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/246#comment:2>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From owner-dnssec-trac at kirei.se  Wed Jun 29 07:35:03 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Wed, 29 Jun 2011 07:35:03 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #246: Kaspcheck validates
 kasp.xml when NSEC3 algorithm is 0
In-Reply-To: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se>
References: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se>
Message-ID: <072.101f2d447bb8b01e61a1818300d1a19e@kirei.se>

#246: Kaspcheck validates kasp.xml when NSEC3 algorithm is 0
--------------------------------+-------------------------------------------
Reporter:  Nick van den Heuvel  |        Owner:  rb     
    Type:  defect               |       Status:  new    
Priority:  minor                |    Component:  Unknown
 Version:  1.3.0                |   Resolution:         
Keywords:  1.3.0rc3             |  
--------------------------------+-------------------------------------------

Comment (by rb):

 Latest OpenDNSSEC 1.3 branch

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/246#comment:3>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From owner-dnssec-trac at kirei.se  Wed Jun 29 07:53:19 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Wed, 29 Jun 2011 07:53:19 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #246: Kaspcheck validates
 kasp.xml when NSEC3 algorithm is 0
In-Reply-To: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se>
References: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se>
Message-ID: <072.f8a6ad89f1324a75a2b0b3d97fb0fd4f@kirei.se>

#246: Kaspcheck validates kasp.xml when NSEC3 algorithm is 0
--------------------------------+-------------------------------------------
Reporter:  Nick van den Heuvel  |        Owner:  rb     
    Type:  defect               |       Status:  new    
Priority:  minor                |    Component:  Unknown
 Version:  1.3.0                |   Resolution:         
Keywords:  1.3.0rc3             |  
--------------------------------+-------------------------------------------

Comment (by Nick van den Heuvel):

 When running ods-ksmutil setup I get this error:
 -----------------------------------------------------
 root at elmo-desktop:/etc/opendnssec# ods-ksmutil setup
 *WARNING* This will erase all data in the database; are you sure? [y/N] y
 SQLite database set to: /var/opendnssec/kasp.db
 fixing permissions on file /var/opendnssec/kasp.db
 zonelist filename set to /etc/opendnssec/zonelist.xml.
 kasp filename set to /etc/opendnssec/kasp.xml.
 Repository SoftHSM found
 No Maximum Capacity set.
 RequireBackup NOT set; please make sure that you know the potential
 problems of using keys which are not recoverable
 /etc/opendnssec/conf.xml validates
 /etc/opendnssec/kasp.xml validates
 ERROR: NSEC3 Hash algorithm is 0 but should be 1
 ods-kaspcheck returned an error, please check your policy
 Failed to update policies
 SETUP FAILED
 -----------------------------------------------------

 kasp.xml validates with ods-kaspcheck. Is this how is should work?
 -----------------------------------------------------
 root at elmo-desktop:/etc/opendnssec# ods-kaspcheck
 /etc/opendnssec/conf.xml validates
 /etc/opendnssec/kasp.xml validates
 ERROR: NSEC3 Hash algorithm is 0 but should be 1
 -----------------------------------------------------

 Conclusion, signing a zone with this kasp.xml is not possible (setup
 fails). Though kasp.xml still validates, should this be changed?

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/246#comment:4>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From yuri at nlnetlabs.nl  Wed Jun 29 10:37:51 2011
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Wed, 29 Jun 2011 12:37:51 +0200
Subject: [Opendnssec-develop] Enforcer engine design v2 work breakdown
In-Reply-To: <1307482998.2608.95.camel@thorin>
References: <1307482998.2608.95.camel@thorin>
Message-ID: <1309343871.1954.40.camel@thorin>

A status update:

I'm happy to tell I made some good progress with the rules. I've
introduced a bunch of likely rollovers to my prototype which all roll as
expected as far as I can tell. Next thing I will do is update the
document with the changed rules and add a better explanation. Than start
coding again. I asked Matthijs to review the output of the prototype. 

Aside the dnssec validity rules the are some policy issues coming to the
surface the past days. 

The main problem is that policy information is not tied to a key (in my
initial design it was but this was somehow dropped by Rene and me in the
actual implementation as redundant). When a policy changes all existing
keys should still propagate according to the old policy. This is fixable
after Rene's vacation. (I will not block on this)

The other thing that *might* be a problem is that the algorithm
implicitly assumes you'll want to have only one key of each role. It
will not keep juggling two ZSKs if one is enough to validate. I worked
out a rough idea for a fix with Matthijs. It requires no changes from
Rene but it's non-trivial. Therefore I want to know whether or not we
want to support this. Is there a usecase? There is not much
code-dependency so changing this at a later time will not increase
required work.

> - Explain (and find out) why these rules are valid *and* sound.

My understanding grows. Expect better fundament of these rules soon.

> - Work out how to apply the 'minimize flags' to achieve different
> rollover strategies. Must be better than gut feeling.

This works. The flags are evaluated in the 'policy step'. TODO:
introduces exceptions when to ignore the roll strategies. (e.g. you
can't do dnskey prepublication on a algorithm rollover)

> - Work out how a 5011 rollover would work in this model _exactly_.

Moved to the bottom of the priority list.

> - Formulate a rule that prevents the RRSIG DNSKEY to transition quicker
> than the actual DNSKEY.

I did (and introduced an ordening) and dropped it again. This is now a
policy decision, not reflected in the rules.

> - Figure out how the user should indicate that an insecure zone is okay
> to have. How does this policy look like? (again, input request for all
> of you)

Don't know yet. How about a policy with no keys?

//yuri



From sion at nominet.org.uk  Wed Jun 29 12:56:33 2011
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Wed, 29 Jun 2011 13:56:33 +0100
Subject: [Opendnssec-develop] Meeting 20110629
In-Reply-To: <BANLkTi=tpQ-NigFXBOvFbSb0vnu8ZO9gDw@mail.gmail.com>
References: <BANLkTi=tpQ-NigFXBOvFbSb0vnu8ZO9gDw@mail.gmail.com>
Message-ID: <4E0B2101.4020908@nominet.org.uk>

On 28/06/11 09:46, Rickard Bellgrim wrote:
> Hi
>
> A reminder that we will have a telephone meeting tomorrow at 14 CET.
>
> http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-06-29
>

minutes are up:

http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-06-29

Feel free to correct or edit as you see fit.

Sion


From sion at nominet.org.uk  Wed Jun 29 13:35:37 2011
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Wed, 29 Jun 2011 14:35:37 +0100
Subject: [Opendnssec-develop] Performance values
Message-ID: <4E0B2A29.3050205@nominet.org.uk>

This message came to me as a list admin; not sure what happened exactly...

Sion


As promised in the meeting this afternoon, I hereby send some 
performance values I found when comparing 1.2.1 with 1.3.0rc2.

Regards,

Nick

-----------------------------------------------------------------------------------------

Performance overview:
No       Zone    Specification                             Total Time 
needed (s)    ODS version        Max memory used
1          lar        5M domainnames, 1% DS                    233    
               1.3.0rc2                       6,1 Gb
2          ler        5M domainnames, 30% DS                  1130    
             1.3.0rc2           7,7 Gb + 3,4 Gb swap
3          lir         5M domainnames, 10% DS                  389    
               1.3.0rc2                       6,8 Gb

4          lar        5M domainnames, 1% DS                    398    
               1.2.1                            6,0 Gb
5          ler        5M domainnames, 30% DS                  1299    
             1.2.1                            7,5 Gb
6          lir         5M domainnames, 10% DS                  698    
               1.2.1                            6,3 Gb

Nick van den Heuvel

Testanalist

SIDN | Utrechtseweg 310 | 6812 AR | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 00 | F +31 (0)26 352 55 05
nick.vandenheuvel at sidn.nl <mailto:mailadres at sidn.nl> | www.sidn.nl 
<http://www.sidn.nl>

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

From matthijs at NLnetLabs.nl  Wed Jun 29 14:27:28 2011
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Wed, 29 Jun 2011 16:27:28 +0200
Subject: [Opendnssec-develop] On OpenDNSSEC Adapters
Message-ID: <4E0B3650.1030600@nlnetlabs.nl>

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

Hi,

As said in the meeting, I am working on the adapters in a separate
branch. In parallel, I am trying to see if I can reduce the memory usage.

In a nutshell:

In the current signer (1.{2,3}.x), The zone data is stored as a tree of
domains. On each domain, I maintain a collection of RRset structures.
Each RRset structure has a list of RRs that exist in the current version
of the zone, a list of RRs that have to be added and a list of RRs that
have to be removed.

To be able to introduce incremental adapters, I want to introduce a
journal entry at the top level of the zone data. When changing signer
configuration or reading a new version of the unsigned zone, I keep
track of all records that need to be added and removed this specific
update (including DNSKEYs, NSEC3PARAM, NSEC(3)s and RRSIGs). When having
a zone with an IXFR output adapter, the journal entry is written
(instead of the whole zone).

The main advantages are:
- - The adapter so to say is now presented with a journal entry and can
decide on purging and condensing strategies, without the signer kernel
having to worry about that.

- - No more need to maintain a list of RRs to be added and to be removed
at RRset structure (will save a lot of pointers and RR clones).


Best regards,

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

iQEcBAEBAgAGBQJOCzZQAAoJEA8yVCPsQCW5MxoH/1Tvtkc+OCjCpN38y3QsFN6t
AI8a/Nymn3AtUpiMz/0AOZbkxG98K9wpFTZc8Fe2SVXfk7bTzX6aJsUO3cuScz0j
TrljrBMgvJjO2s0ZY2ilSy+gl2Hr/4suCUBxgeGgRN/f5SnAPmDd/UHnlot0ZzfR
t7MRrtvLDMjf9UOftOwovcG2Q31ZYfcn5b22EobN/CVSGx/2vfu8XQLH4kBcTRsx
n75GFBbCFdpCXAIz2Ti+8grfM1bIGzM/Fggi1b/jl/S+AVBeBLAAuhugn05rmV16
6lo0THKwbJIRO69/ZvkX36wGr4KbtXfc5f6i4wszLzRg1p0AfCW2QddB565VczA=
=IcGa
-----END PGP SIGNATURE-----


From Roland.vanRijswijk at surfnet.nl  Wed Jun 29 15:24:30 2011
From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk)
Date: Wed, 29 Jun 2011 17:24:30 +0200
Subject: [Opendnssec-develop] Enforcer engine design v2 work breakdown
In-Reply-To: <1309343871.1954.40.camel@thorin>
References: <1307482998.2608.95.camel@thorin> <1309343871.1954.40.camel@thorin>
Message-ID: <9593CF16-BCD4-4194-BFB8-0D1942D61661@surfnet.nl>

Hi Yuri,

On 29 jun 2011, at 12:37, Yuri Schaeffer wrote:

> A status update:
> 
> I'm happy to tell I made some good progress with the rules. I've
> introduced a bunch of likely rollovers to my prototype which all roll as
> expected as far as I can tell. Next thing I will do is update the
> document with the changed rules and add a better explanation. Than start
> coding again. I asked Matthijs to review the output of the prototype. 
> 
> Aside the dnssec validity rules the are some policy issues coming to the
> surface the past days. 
> 
> The main problem is that policy information is not tied to a key (in my
> initial design it was but this was somehow dropped by Rene and me in the
> actual implementation as redundant). When a policy changes all existing
> keys should still propagate according to the old policy. This is fixable
> after Rene's vacation. (I will not block on this)

Do I understand correctly that this will only affect keys that are already in use?

> The other thing that *might* be a problem is that the algorithm
> implicitly assumes you'll want to have only one key of each role. It
> will not keep juggling two ZSKs if one is enough to validate. I worked
> out a rough idea for a fix with Matthijs. It requires no changes from
> Rene but it's non-trivial. Therefore I want to know whether or not we
> want to support this. Is there a usecase? There is not much
> code-dependency so changing this at a later time will not increase
> required work.

I don't really see a use case for having two ZSKs other than when you are using two algorithms to sign a zone or perhaps if you want a standby ZSK (e.g. if you keep separate key material on two physically separate HSMs with different security worlds, although this would be ultra paranoid). But perhaps I'm overlooking more valid use cases ;-)

> I did (and introduced an ordening) and dropped it again. This is now a
> policy decision, not reflected in the rules.

Can you explain why that is and what changes you made? I recall we had quite a bit of discussion about this during the last call.

>> - Figure out how the user should indicate that an insecure zone is okay
>> to have. How does this policy look like? (again, input request for all
>> of you)
> 
> Don't know yet. How about a policy with no keys?

That sounds reasonable.

Cheers,

Roland

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl



From yuri at nlnetlabs.nl  Thu Jun 30 07:46:55 2011
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Thu, 30 Jun 2011 09:46:55 +0200
Subject: [Opendnssec-develop] Enforcer engine design v2 work breakdown
In-Reply-To: <9593CF16-BCD4-4194-BFB8-0D1942D61661@surfnet.nl>
References: <1307482998.2608.95.camel@thorin> <1309343871.1954.40.camel@thorin>
	<9593CF16-BCD4-4194-BFB8-0D1942D61661@surfnet.nl>
Message-ID: <1309420015.1913.61.camel@thorin>

Roland,

> > The main problem is that policy information is not tied to a key (in my
> > initial design it was but this was somehow dropped by Rene and me in the
> > actual implementation as redundant). When a policy changes all existing
> > keys should still propagate according to the old policy. This is fixable
> > after Rene's vacation. (I will not block on this)

> Do I understand correctly that this will only affect keys that are already in use?

I think new keys are affected as well. When for example the new DNSKEY
TTL is shorter than the old DNSKEY TTL, the old and the new set both
roll too quick. (zone may become invalid)

When the new TTL is longer. The roll is unnecessary slow. (but will stay
valid)

> > I did (and introduced an ordening) and dropped it again. This is now a
> > policy decision, not reflected in the rules.

> Can you explain why that is and what changes you made? I recall we had quite a bit of discussion about this during the last call.

So the problem is that you may always introduce the RRSIG DNSKEY without
affecting validity. The situation was that in some cases the DNSKEY
could not introduce yet, but its signature did.

I tried to capture this in a rule having state(DNSKEY) >= state(RRSIG
DNSKEY). This worked without a problem. Later I realized introducing the
signatures first is not wrong, just undesirable. Hence I removed it from
the rules and added the case to the policy of the enforcer. (note: I'm
not referring to the user defined policy, the kasp.xml).
Now the RRSIG DNSKEY may only introduce when the DNSKEY is not hidden.
In almost all cases this will cause the DNSKEY and RRSIG DNSKEY to
propagate at the same time and pace.

Let me finally remark that having no restrictions on the RRSIG DNSKEY
will not make the zone invalid, nor will it affect the speed of a
rollover. It could however give the signer more work.

//yuri



From owner-dnssec-trac at kirei.se  Thu Jun 30 07:51:21 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Thu, 30 Jun 2011 07:51:21 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #247: Hang signer processes
 after receiving several notifies in succession
In-Reply-To: <056.168398051f6878f3b30e025dabd6d8c8@kirei.se>
References: <056.168398051f6878f3b30e025dabd6d8c8@kirei.se>
Message-ID: <071.066117c2f67851493bd8fc02c12de630@kirei.se>

#247: Hang signer processes after receiving several notifies in succession
-----------------------------------+----------------------------------------
Reporter:  goeran@?                |        Owner:  matthijs
    Type:  defect                  |       Status:  accepted
Priority:  major                   |    Component:  Signer  
 Version:  1.3.0                   |   Resolution:          
Keywords:  signer, hang, notifies  |  
-----------------------------------+----------------------------------------
Changes (by matthijs):

  * status:  new => accepted


-- 
Ticket URL: <http://trac.opendnssec.org/ticket/247#comment:2>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From sion at nominet.org.uk  Thu Jun 30 08:08:22 2011
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Thu, 30 Jun 2011 09:08:22 +0100
Subject: [Opendnssec-develop] Meeting 20110629
In-Reply-To: <4E0B2101.4020908@nominet.org.uk>
References: <BANLkTi=tpQ-NigFXBOvFbSb0vnu8ZO9gDw@mail.gmail.com>
	<4E0B2101.4020908@nominet.org.uk>
Message-ID: <4E0C2EF6.2000802@nominet.org.uk>


> http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-06-29
>
I have finished patching the 1.2 branch now.

Sion


From matthijs at NLnetLabs.nl  Thu Jun 30 08:26:58 2011
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Thu, 30 Jun 2011 10:26:58 +0200
Subject: [Opendnssec-develop] Enforcer engine design v2 work breakdown
In-Reply-To: <1309420015.1913.61.camel@thorin>
References: <1307482998.2608.95.camel@thorin>
	<1309343871.1954.40.camel@thorin>	<9593CF16-BCD4-4194-BFB8-0D1942D61661@surfnet.nl>
	<1309420015.1913.61.camel@thorin>
Message-ID: <4E0C3352.5040007@nlnetlabs.nl>

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

On 06/30/2011 09:46 AM, Yuri Schaeffer wrote:
> Roland,
> 
>>> The main problem is that policy information is not tied to a key
>>> (in my initial design it was but this was somehow dropped by Rene
>>> and me in the actual implementation as redundant). When a policy
>>> changes all existing keys should still propagate according to the
>>> old policy. This is fixable after Rene's vacation. (I will not
>>> block on this)
> 
>> Do I understand correctly that this will only affect keys that are
>> already in use?
> 
> I think new keys are affected as well. When for example the new
> DNSKEY TTL is shorter than the old DNSKEY TTL, the old and the new
> set both roll too quick. (zone may become invalid)
> 
> When the new TTL is longer. The roll is unnecessary slow. (but will
> stay valid)

Yes. When key rollovers talk about 'waiting approximately one TTL', it
is assumed the Maximum Zone/DNSKEY TTL (depending on ZSK or KSK
rollover) of the RRset of the previous version of the zone.

If you are going to introduce keys at a faster rate than TTL, the TTL
can even span multiple versions of previous zones.

- - Matthijs

> 
>>> I did (and introduced an ordening) and dropped it again. This is
>>> now a policy decision, not reflected in the rules.
> 
>> Can you explain why that is and what changes you made? I recall we
>> had quite a bit of discussion about this during the last call.
> 
> So the problem is that you may always introduce the RRSIG DNSKEY
> without affecting validity. The situation was that in some cases the
> DNSKEY could not introduce yet, but its signature did.
> 
> I tried to capture this in a rule having state(DNSKEY) >=
> state(RRSIG DNSKEY). This worked without a problem. Later I realized
> introducing the signatures first is not wrong, just undesirable.
> Hence I removed it from the rules and added the case to the policy of
> the enforcer. (note: I'm not referring to the user defined policy,
> the kasp.xml). Now the RRSIG DNSKEY may only introduce when the
> DNSKEY is not hidden. In almost all cases this will cause the DNSKEY
> and RRSIG DNSKEY to propagate at the same time and pace.
> 
> Let me finally remark that having no restrictions on the RRSIG
> DNSKEY will not make the zone invalid, nor will it affect the speed
> of a rollover. It could however give the signer more work.
> 
> //yuri
> 
> _______________________________________________ Opendnssec-develop
> mailing list Opendnssec-develop at lists.opendnssec.org 
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

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

iQEcBAEBAgAGBQJODDNSAAoJEA8yVCPsQCW5bIEH/3PKi/cG/6l2V9gdNVIJxp2j
nukkhx8OArpYVcU7N7OnUvWd2ZXyfWIQN6MOAy+G1j9zXk6+v7rMX52BzvBE80gZ
aq2uRQAz8f0nFnNJ7DHuFu3TpWoiAo1lweH+5iKsmAxCk+ki9WLOfGD6lpL0Rtls
AM5KdsAcHlhSa7DxASmBLDnFDCdA8b3yO7yLl2lV2T0j7/nXEDytOGg6ffSWm8L/
iy2c+7g7b9UrXKcUQaxSHf3io9ax/Xetdwu8h+4DmR36uVe8N0VlKPz7WRFAnBJ6
w0XnKxjqMrHmFHGnAAeJKSH8o7EABnUq4lMYPGIjSFdVzi72gWOrUMBlqHtZQ5Q=
=4ls9
-----END PGP SIGNATURE-----


From rickard at opendnssec.org  Thu Jun 30 11:32:27 2011
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Thu, 30 Jun 2011 13:32:27 +0200
Subject: [Opendnssec-develop] Enforcer engine design v2 work breakdown
In-Reply-To: <9593CF16-BCD4-4194-BFB8-0D1942D61661@surfnet.nl>
References: <1307482998.2608.95.camel@thorin> <1309343871.1954.40.camel@thorin>
	<9593CF16-BCD4-4194-BFB8-0D1942D61661@surfnet.nl>
Message-ID: <BANLkTinRStx+bK-vESR8gwxz1Crz8hendw@mail.gmail.com>

On Wed, Jun 29, 2011 at 5:24 PM, Roland van Rijswijk
<Roland.vanRijswijk at surfnet.nl> wrote:
>> The other thing that *might* be a problem is that the algorithm
>> implicitly assumes you'll want to have only one key of each role. It
>> will not keep juggling two ZSKs if one is enough to validate. I worked
>> out a rough idea for a fix with Matthijs. It requires no changes from
>> Rene but it's non-trivial. Therefore I want to know whether or not we
>> want to support this. Is there a usecase? There is not much
>> code-dependency so changing this at a later time will not increase
>> required work.
>
> I don't really see a use case for having two ZSKs other than when you are using two algorithms to sign a zone or perhaps if you want a standby ZSK (e.g. if you keep separate key material on two physically separate HSMs with different security worlds, although this would be ultra paranoid). But perhaps I'm overlooking more valid use cases ;-)

Those would be the use cases. We had a discussion yesterday on the
OpenDNSSEC meeting where we decided that this support could wait until
we have a running Enforcer.

// Rickard


From owner-dnssec-trac at kirei.se  Thu Jun 30 12:55:21 2011
From: owner-dnssec-trac at kirei.se (OpenDNSSEC)
Date: Thu, 30 Jun 2011 12:55:21 -0000
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #247: Hang signer processes
 after receiving several notifies in succession
In-Reply-To: <056.168398051f6878f3b30e025dabd6d8c8@kirei.se>
References: <056.168398051f6878f3b30e025dabd6d8c8@kirei.se>
Message-ID: <071.753682283f2a33d6247fe4f40cb49f8c@kirei.se>

#247: Hang signer processes after receiving several notifies in succession
-----------------------------------+----------------------------------------
Reporter:  goeran@?                |        Owner:  matthijs
    Type:  defect                  |       Status:  accepted
Priority:  major                   |    Component:  Signer  
 Version:  1.3.0                   |   Resolution:          
Keywords:  signer, hang, notifies  |  
-----------------------------------+----------------------------------------

Comment (by matthijs):

 I think this happens when notifies are coming in quicker than the signer
 can sign the zone. In the OpenDNSSEC-1.3 branch, I have committed a change
 (r5272) where the zone fetcher unlocks the axfr file before it kicks the
 signer daemon. This solved this issue for me.

 Could you try out r5272+ of the branch?

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/247#comment:3>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC

From goeran at chalmers.se  Thu Jun 30 18:28:21 2011
From: goeran at chalmers.se (=?ISO-8859-1?Q?G=F6ran_Bengtson?=)
Date: Thu, 30 Jun 2011 20:28:21 +0200 (CEST)
Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #247: Hang signer processes
 after receiving several notifies in succession
In-Reply-To: <071.753682283f2a33d6247fe4f40cb49f8c@kirei.se>
References: <056.168398051f6878f3b30e025dabd6d8c8@kirei.se>
	<071.753682283f2a33d6247fe4f40cb49f8c@kirei.se>
Message-ID: <alpine.LRH.2.01.1106301820280.5579@olydig.cdg.chalmers.se>

On Thu, 30 Jun 2011, OpenDNSSEC wrote:

> From: OpenDNSSEC <owner-dnssec-trac at kirei.se>
> Cc: "opendnssec-develop at lists.opendnssec.org"
>     <opendnssec-develop at lists.opendnssec.org>
> Message-ID: <071.753682283f2a33d6247fe4f40cb49f8c at kirei.se>
> Date: Thu, 30 Jun 2011 14:55:21 +0200
> Subject: Re: [OpenDNSSEC] #247: Hang signer processes after receiving several
>     notifies in succession
> 
> #247: Hang signer processes after receiving several notifies in succession
> -----------------------------------+----------------------------------------
> Reporter:  goeran@?                |        Owner:  matthijs
>    Type:  defect                  |       Status:  accepted
> Priority:  major                   |    Component:  Signer
> Version:  1.3.0                   |   Resolution:
> Keywords:  signer, hang, notifies  |
> -----------------------------------+----------------------------------------
>
> Comment (by matthijs):
>
> I think this happens when notifies are coming in quicker than the signer
> can sign the zone. In the OpenDNSSEC-1.3 branch, I have committed a change
> (r5272) where the zone fetcher unlocks the axfr file before it kicks the
> signer daemon. This solved this issue for me.

Sounds reasonable.

>
> Could you try out r5272+ of the branch?

I was back at 1.2.1 and upgraded to 1.3.0 r5273.
After a couple of upgrade problems (soa s/n not incremented etc)
I was able to check if the notify-problem was resolved.
Unfortunately I don't think it is, at least not for me.

After receiving 2 notifies (of several, se below), both resulting in
an axfr, the signer process seems to endup consume cpu but never to
complete the signing operation. It also blocks signing of other zones.

[root at ns-test rc3]# ods-signer queue
It is now Thu Jun 30 20:16:34 2011
Working with task [sign] on zone itsnat.se

I have 9 tasks scheduled.
On Thu Jun 30 20:16:35 2011 I will [sign] zone 50.5.192.in-addr.arpa
On Thu Jun 30 20:19:44 2011 I will [sign] zone 16.129.in-addr.arpa
On Thu Jun 30 20:52:34 2011 I will [sign] zone chalmers.se
On Thu Jun 30 21:04:52 2011 I will [sign] zone chalmers.eu
On Thu Jun 30 21:05:06 2011 I will [sign] zone 120.36.192.in-addr.arpa
On Thu Jun 30 21:05:24 2011 I will [sign] zone gbg.sunet.se
On Thu Jun 30 21:06:39 2011 I will [sign] zone 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa
On Thu Jun 30 21:07:00 2011 I will [sign] zone 224.36.192.in-addr.arpa
On Thu Jun 30 21:07:05 2011 I will [sign] zone 225.36.192.in-addr.arpa

It is now Thu Jun 30 20:27:22 2011
Working with task [sign] on zone itsnat.se
Working with task [sign] on zone 50.5.192.in-addr.arpa
Working with task [sign] on zone chalmers.eu
Working with task [sign] on zone 16.129.in-addr.arpa

I have 6 tasks scheduled.
On Thu Jun 30 20:52:34 2011 I will [sign] zone chalmers.se
On Thu Jun 30 21:05:06 2011 I will [sign] zone 120.36.192.in-addr.arpa
On Thu Jun 30 21:05:24 2011 I will [sign] zone gbg.sunet.se
On Thu Jun 30 21:06:39 2011 I will [sign] zone 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa
On Thu Jun 30 21:07:00 2011 I will [sign] zone 224.36.192.in-addr.arpa
On Thu Jun 30 21:07:05 2011 I will [sign] zone 225.36.192.in-addr.arpa



>From the NS sending the notifies:

Jun 30 20:08:14 ns-test named[3604]: general: info: received control channel command 'reload itsnat.se'
Jun 30 20:08:14 ns-test named[3604]: general: info: zone itsnat.se/IN: loaded serial 2011063008
Jun 30 20:08:14 ns-test named[3604]: notify: info: zone itsnat.se/IN: sending notifies (serial 2011063008)
Jun 30 20:08:14 ns-test named[3604]: xfer-out: info: client 127.0.0.1#41663: transfer of 'itsnat.se/IN': AXFR started
Jun 30 20:08:14 ns-test named[3604]: xfer-out: info: client 127.0.0.1#41663: transfer of 'itsnat.se/IN': AXFR ended
Jun 30 20:08:33 ns-test named[3604]: general: info: received control channel command 'reload itsnat.se'
Jun 30 20:08:34 ns-test named[3604]: general: info: zone itsnat.se/IN: loaded serial 2011063009
Jun 30 20:08:34 ns-test named[3604]: notify: info: zone itsnat.se/IN: sending notifies (serial 2011063009)
Jun 30 20:08:34 ns-test named[3604]: xfer-out: info: client 127.0.0.1#41664: transfer of 'itsnat.se/IN': AXFR started
Jun 30 20:08:34 ns-test named[3604]: xfer-out: info: client 127.0.0.1#41664: transfer of 'itsnat.se/IN': AXFR ended
Jun 30 20:08:38 ns-test named[3604]: general: info: received control channel command 'reload itsnat.se'
Jun 30 20:08:38 ns-test named[3604]: general: info: zone itsnat.se/IN: loaded serial 2011063010
Jun 30 20:08:39 ns-test named[3604]: notify: info: zone itsnat.se/IN: sending notifies (serial 2011063010)
Jun 30 20:08:50 ns-test named[3604]: general: info: received control channel command 'reload itsnat.se'
Jun 30 20:08:51 ns-test named[3604]: general: info: zone itsnat.se/IN: loaded serial 2011063011
Jun 30 20:08:51 ns-test named[3604]: notify: info: zone itsnat.se/IN: sending notifies (serial 2011063011)
Jun 30 20:09:03 ns-test named[3604]: general: info: received control channel command 'reload itsnat.se'
Jun 30 20:09:04 ns-test named[3604]: general: info: zone itsnat.se/IN: loaded serial 2011063012
Jun 30 20:09:04 ns-test named[3604]: notify: info: zone itsnat.se/IN: sending notifies (serial 2011063012)


>From opendnssec:
Jun 30 20:08:14 ns-test ods-signerd: zone fetcher received NOTIFY for zone itsnat.se
Jun 30 20:08:15 ns-test ods-signerd: zone fetcher transferred zone itsnat.se serial 2011063008 successfully
Jun 30 20:08:34 ns-test ods-signerd: zone fetcher received NOTIFY for zone itsnat.se
Jun 30 20:08:34 ns-test ods-signerd: zone fetcher transferred zone itsnat.se serial 2011063009 successfully

>
> -- 
> Ticket URL: <http://trac.opendnssec.org/ticket/247#comment:3>
> OpenDNSSEC <http://www.opendnssec.org/>
> OpenDNSSEC

 			/ G?ran Bengtson
 			  Chalmers University of Technology