From sara at sinodun.com Sun Jul 1 17:53:10 2012 From: sara at sinodun.com (Sara Dickinson) Date: Sun, 1 Jul 2012 18:53:10 +0100 Subject: [Opendnssec-develop] RE: Documentation for 1.4 Message-ID: <705CE97B-936E-491C-B009-ED56803BA661@sinodun.com> Hi All, I took a spin through the documentation on the wiki for 1.4 and made a few minor updates including: - Validation: created place holder for a page describing how to validation zones using external tools: https://wiki.opendnssec.org/display/DOCSTRUNK/External+Auditing+of+Zones Jakob was pencilled in to write this page but if someone else could please review and add content that would be a big help as I wasn't involved in the discussions on this. - Migration: added new page to describe migration from earlier versions: https://wiki.opendnssec.org/display/DOCSTRUNK/Migrating+from+earlier+versions+of+OpenDNSSEC Sion if you could review? - Re-worked the architecture diagram for 1.4: https://wiki.opendnssec.org/display/DOCSTRUNK/Overview+of+OpenDNSSEC Thoughts or comments? - removed Ruby from the Dependancies page and removed a handful of references to the auditor from various pages - updated the list of supported platforms to match the latest list agreed (hope this wasn't premature - I didn't update 1.3) - added a comment about choice of database to the installation page Please review and correct any mistakes if you find them! Sara. From jerry at opendnssec.org Mon Jul 2 08:54:34 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Mon, 2 Jul 2012 10:54:34 +0200 Subject: [Opendnssec-develop] Jenkins: All jobs have disappeared Message-ID: Hi John, Can you check whats up with Jenkins, theres no jobs. /Jerry -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From jad at sinodun.com Mon Jul 2 09:52:25 2012 From: jad at sinodun.com (John Dickinson) Date: Mon, 2 Jul 2012 10:52:25 +0100 Subject: [Opendnssec-develop] Re: Jenkins: All jobs have disappeared In-Reply-To: References: Message-ID: <5943CAED-69D5-4A94-AC66-3F0DD72DA705@sinodun.com> It appears to be a bug in jenkins 1.473 which was automatically updated at 05:03:10 this morning. So I have downgraded to 1.472. I will submit a bug report. John On Jul 2, 2012, at 9:54 AM, Jerry Lundstr?m wrote: > Hi John, > > Can you check whats up with Jenkins, theres no jobs. > > /Jerry > > -- > Jerry Lundstr?m - OpenDNSSEC Developer > http://www.opendnssec.org/ > --- 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: From jad at sinodun.com Mon Jul 2 10:02:52 2012 From: jad at sinodun.com (John Dickinson) Date: Mon, 2 Jul 2012 11:02:52 +0100 Subject: [Opendnssec-develop] Jenkins: All jobs have disappeared In-Reply-To: <5943CAED-69D5-4A94-AC66-3F0DD72DA705@sinodun.com> References: <5943CAED-69D5-4A94-AC66-3F0DD72DA705@sinodun.com> Message-ID: It seems we are hitting https://issues.jenkins-ci.org/browse/JENKINS-14273 John On Jul 2, 2012, at 10:52 AM, John Dickinson wrote: > It appears to be a bug in jenkins 1.473 which was automatically updated at 05:03:10 this morning. So I have downgraded to 1.472. > > I will submit a bug report. > > John > > On Jul 2, 2012, at 9:54 AM, Jerry Lundstr?m wrote: > >> Hi John, >> >> Can you check whats up with Jenkins, theres no jobs. >> >> /Jerry >> >> -- >> Jerry Lundstr?m - OpenDNSSEC Developer >> http://www.opendnssec.org/ >> > > > > --- > 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 > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -------------- 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: From matthijs at nlnetlabs.nl Mon Jul 2 13:00:08 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Mon, 02 Jul 2012 15:00:08 +0200 Subject: [Opendnssec-develop] RE: Documentation for 1.4 In-Reply-To: <705CE97B-936E-491C-B009-ED56803BA661@sinodun.com> References: <705CE97B-936E-491C-B009-ED56803BA661@sinodun.com> Message-ID: <4FF19B58.4080200@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sara, Thanks for catching the auditor references I missed. The Troubleshooting page could use an update on error messages for the signer engine, I'll take a look at it and update. Best regards, Matthijs On 07/01/2012 07:53 PM, Sara Dickinson wrote: > Hi All, > > I took a spin through the documentation on the wiki for 1.4 and > made a few minor updates including: > > - Validation: created place holder for a page describing how to > validation zones using external tools: > > https://wiki.opendnssec.org/display/DOCSTRUNK/External+Auditing+of+Zones > > Jakob was pencilled in to write this page but if someone else > could please review and add content that would be a big help as I > wasn't involved in the discussions on this. > > > - Migration: added new page to describe migration from earlier > versions: > > https://wiki.opendnssec.org/display/DOCSTRUNK/Migrating+from+earlier+versions+of+OpenDNSSEC > > Sion if you could review? > > > - Re-worked the architecture diagram for 1.4: > > https://wiki.opendnssec.org/display/DOCSTRUNK/Overview+of+OpenDNSSEC > > Thoughts or comments? > > > - removed Ruby from the Dependancies page and removed a handful of > references to the auditor from various pages > > - updated the list of supported platforms to match the latest list > agreed (hope this wasn't premature - I didn't update 1.3) > > - added a comment about choice of database to the installation > page > > > Please review and correct any mistakes if you find them! > > Sara. > > > _______________________________________________ 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/ iQEcBAEBAgAGBQJP8ZtYAAoJEA8yVCPsQCW5Z5kH/ifGYJHmqRcTnzBlPnnla47l p84unxdY/ZVXSe4E0rhH0hkc+FvR7xeQ9lUlWYvduTvb4h79s/lNAQj13U9IVYcJ D2Dny7Ki6I5m/J/Q+wbjkFC9lYG4DF6Pt1NcmHWpZpMCFtQ6Nt0liLt7GLLjXcnV iFv/sEACXvDWC0frJnwYb/DJ2W9zYVbfIINJtwJsFTIXNzZKCTcbRlhQGxwbAQNo Mw4DGQfMWvWqf+DmRfvqRrwWnyMOwDUHql5gIZc3Ld2zyjps5BDWo7iT7pI5o+6X QFYHsSLzBnnCQLnpGPStzzO8zrBYs4mhjIMG0Oo3DtZ2bwBModcIKlWkCKD/+8c= =Z5Nz -----END PGP SIGNATURE----- From jerry at opendnssec.org Mon Jul 2 14:37:24 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Mon, 2 Jul 2012 16:37:24 +0200 Subject: [Opendnssec-develop] Database conversion tool Message-ID: <-6822765467657535135@unknownmsgid> I'm going to make a small perl script to convert between SQLite and MySQL and I wonder if there is anything specific to think about like do we use utf8 in zone name etc? /Jerry From sion at nominet.org.uk Tue Jul 3 08:31:12 2012 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Tue, 3 Jul 2012 09:31:12 +0100 Subject: [Opendnssec-develop] Database conversion tool In-Reply-To: <-6822765467657535135@unknownmsgid> References: <-6822765467657535135@unknownmsgid> Message-ID: <4FF2ADD0.5080209@nominet.org.uk> On 02/07/12 15:37, Jerry Lundstr?m wrote: > I'm going to make a small perl script to convert between SQLite and > MySQL and I wonder if there is anything specific to think about like > do we use utf8 in zone name etc? > > /Jerry > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop One thing that I was thinking about is where we have used tinyint or mediumint in the mysql schema but integer in the sqlite schema. However I think there should be no real issues unless someone has more than 127 HSMs or 8,388,607 zones/policies (good luck with that). The other thing is that in sqlite timestamps are stored as varchars; that should not be a problem, just something to be aware of. Sion From jerry at opendnssec.org Tue Jul 3 08:38:29 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Tue, 3 Jul 2012 10:38:29 +0200 Subject: [Opendnssec-develop] Database conversion tool In-Reply-To: <4FF2ADD0.5080209@nominet.org.uk> References: <-6822765467657535135@unknownmsgid> <4FF2ADD0.5080209@nominet.org.uk> Message-ID: On Tue, Jul 3, 2012 at 10:31 AM, Si?n Lloyd wrote: > One thing that I was thinking about is where we have used tinyint or > mediumint in the mysql schema but integer in the sqlite schema. However I > think there should be no real issues unless someone has more than 127 HSMs > or 8,388,607 zones/policies (good luck with that). Oh, maybe we should fix that for 1.4? > The other thing is that in sqlite timestamps are stored as varchars; that > should not be a problem, just something to be aware of. MySQL is good at eating a lot of different timestamps layout but it might not be as easy going from MySQL to SQLite, I'll keep that in mind thanks. /Jerry From jerry at opendnssec.org Tue Jul 3 08:39:39 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Tue, 3 Jul 2012 10:39:39 +0200 Subject: [Opendnssec-develop] Jenkins: All jobs have disappeared In-Reply-To: References: <5943CAED-69D5-4A94-AC66-3F0DD72DA705@sinodun.com> Message-ID: On Mon, Jul 2, 2012 at 12:02 PM, John Dickinson wrote: > It seems we are hitting https://issues.jenkins-ci.org/browse/JENKINS-14273 Nice catch, hope they can fix it soonish. /Jerry From sion at nominet.org.uk Tue Jul 3 08:51:08 2012 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Tue, 3 Jul 2012 09:51:08 +0100 Subject: [Opendnssec-develop] Database conversion tool In-Reply-To: References: <-6822765467657535135@unknownmsgid> <4FF2ADD0.5080209@nominet.org.uk> Message-ID: <4FF2B27C.7010209@nominet.org.uk> On 03/07/12 09:38, Jerry Lundstr?m wrote: > On Tue, Jul 3, 2012 at 10:31 AM, Si?n Lloyd wrote: >> One thing that I was thinking about is where we have used tinyint or >> mediumint in the mysql schema but integer in the sqlite schema. However I >> think there should be no real issues unless someone has more than 127 HSMs >> or 8,388,607 zones/policies (good luck with that). > Oh, maybe we should fix that for 1.4? We have looked at this in the past and decided that the only one we needed to increase was for keys. This is when the script "migrate_id_mysql.pl" was created. (As you can see it is not as simple as just changing the column type; you need to drop and then recreate the FK constraints also.) Does anyone think that these fields need to be increased? > >> The other thing is that in sqlite timestamps are stored as varchars; that >> should not be a problem, just something to be aware of. > MySQL is good at eating a lot of different timestamps layout but it > might not be as easy going from MySQL to SQLite, I'll keep that in > mind thanks. > > /Jerry From matthijs at nlnetlabs.nl Tue Jul 3 09:02:50 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Tue, 03 Jul 2012 11:02:50 +0200 Subject: [Opendnssec-develop] Database conversion tool In-Reply-To: <4FF2B27C.7010209@nominet.org.uk> References: <-6822765467657535135@unknownmsgid> <4FF2ADD0.5080209@nominet.org.uk> <4FF2B27C.7010209@nominet.org.uk> Message-ID: <4FF2B53A.2090201@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/03/2012 10:51 AM, Si?n Lloyd wrote: > On 03/07/12 09:38, Jerry Lundstr?m wrote: >> On Tue, Jul 3, 2012 at 10:31 AM, Si?n Lloyd >> wrote: >>> One thing that I was thinking about is where we have used >>> tinyint or mediumint in the mysql schema but integer in the >>> sqlite schema. However I think there should be no real issues >>> unless someone has more than 127 HSMs or 8,388,607 >>> zones/policies (good luck with that). >> Oh, maybe we should fix that for 1.4? > > We have looked at this in the past and decided that the only one > we needed to increase was for keys. This is when the script > "migrate_id_mysql.pl" was created. (As you can see it is not as > simple as just changing the column type; you need to drop and then > recreate the FK constraints also.) > > Does anyone think that these fields need to be increased? "That ought to be enough for anybody" > >> >>> The other thing is that in sqlite timestamps are stored as >>> varchars; that should not be a problem, just something to be >>> aware of. >> MySQL is good at eating a lot of different timestamps layout but >> it might not be as easy going from MySQL to SQLite, I'll keep >> that in mind thanks. >> >> /Jerry > > > _______________________________________________ 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/ iQEcBAEBAgAGBQJP8rU5AAoJEA8yVCPsQCW5Z58H/3Aiy7RpL7uRxRbfardaM7sp KUtWAkYCfhaivlggBDr2G8sevZG+oVVfU2WtRK6xeK+xMRtYaw5v8oGCRSv76bK1 rnU+iega6xpAgiTX3N2Ye4UU3U4mHcykVVbzZWEXfxVYruJB3q5J5wKVXPC3itg3 SjtPcqS4XDgvQHRxLzm9qC3HSUD/GVl8J6wgcU65+5tZUCu1AB+PXWX7e1GDeGct MryhC6q8PXGI/aqJAQoBapyTVADkWxUJ4prRvDjarnxNiDhMgc1x0g4EJ/FMJnZ8 spkO98bRoZh8zxwEkNV+M2NGNF2zhJWVcEyj7jrhY94FC05Aq7zt5hMhUNrWH+g= =+dyb -----END PGP SIGNATURE----- From jerry at opendnssec.org Wed Jul 4 13:16:15 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Wed, 4 Jul 2012 15:16:15 +0200 Subject: [Opendnssec-develop] Database conversion tool In-Reply-To: <4FF2B53A.2090201@nlnetlabs.nl> References: <-6822765467657535135@unknownmsgid> <4FF2ADD0.5080209@nominet.org.uk> <4FF2B27C.7010209@nominet.org.uk> <4FF2B53A.2090201@nlnetlabs.nl> Message-ID: Hi, Its in trunk now enforcer/util/convert_database.pl, I have tried SQLite->MySQL and it seems to work. Anyone else wanna give it a go? /Jerry -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From Roland.vanRijswijk at surfnet.nl Sun Jul 8 12:55:35 2012 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Sun, 8 Jul 2012 14:55:35 +0200 Subject: [Opendnssec-develop] WARNING: 1.4.0a1 appears in Red Hat Enterprise Linux repositories Message-ID: <4762EEA4-6F7B-4803-9C1F-E4CF82C8837D@surfnet.nl> Hi all, A friendly warning: we are currently dealing with the fall out from what appears to be a stupid mistake by Red Hat. OpenDNSSEC 1.4.0a1 has appeared in repositories that are apparently configured on production systems by default. Consequently, our well-managed 1.3.9 install has been upgraded to 1.4.0a1 and all configuration has been wiped. I don't know which one of you (if any) has contacts at Fedora/Red Hat, but please tell them that 1.4.0 is an alpha that should NEVER end up in production repositories? Cheers, Roland -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From sara at sinodun.com Sun Jul 8 13:04:00 2012 From: sara at sinodun.com (Sara (Sinodun)) Date: Sun, 8 Jul 2012 14:04:00 +0100 Subject: [Opendnssec-develop] Meeting 2012-07-10 Message-ID: All, We have a scheduled team meeting on Tuesday: Date: Tuesday, 10th July 2012 Time: 14:00-15:00 CEST The agenda and outstanding actions can be found here: https://wiki.opendnssec.org/display/OpenDNSSEC/2012-07-10+Meeting Anyone planning on attending the next developer workshop who hasn't filled in the doodle yet could you please do this before the meeting so we can discuss dates and locations: http://www.doodle.com/c36ztcse476hshww I haven't got a alternative PSTN conference option set up yet so we'll use the normal call details. Thanks Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry at opendnssec.org Sun Jul 8 13:22:03 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Sun, 8 Jul 2012 15:22:03 +0200 Subject: [Opendnssec-develop] WARNING: 1.4.0a1 appears in Red Hat Enterprise Linux repositories In-Reply-To: <4762EEA4-6F7B-4803-9C1F-E4CF82C8837D@surfnet.nl> References: <4762EEA4-6F7B-4803-9C1F-E4CF82C8837D@surfnet.nl> Message-ID: Hi, This is the works of Paul Wouters. I have pointed this out to him and posted on EPEL issue (https://bugzilla.redhat.com/show_bug.cgi?id=711899) that this is an ALPHA release and should not be pushed to production. It went unnoticed... opendnssec-1.4.0-0.a1.el6.2 has been pushed to the Fedora EPEL 6 stable repository. opendnssec-1.4.0-0.a1.fc16.2 has been pushed to the Fedora 16 stable repository. opendnssec-1.4.0-0.a1.fc17.2 has been pushed to the Fedora 17 stable repository. /Jerry On Sun, Jul 8, 2012 at 2:55 PM, Roland van Rijswijk - Deij wrote: > Hi all, > > A friendly warning: we are currently dealing with the fall out from what appears to be a stupid mistake by Red Hat. OpenDNSSEC 1.4.0a1 has appeared in repositories that are apparently configured on production systems by default. Consequently, our well-managed 1.3.9 install has been upgraded to 1.4.0a1 and all configuration has been wiped. > > I don't know which one of you (if any) has contacts at Fedora/Red Hat, but please tell them that 1.4.0 is an alpha that should NEVER end up in production repositories? From Roland.vanRijswijk at surfnet.nl Sun Jul 8 13:24:12 2012 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Sun, 8 Jul 2012 15:24:12 +0200 Subject: [Opendnssec-develop] WARNING: 1.4.0a1 appears in Red Hat Enterprise Linux repositories In-Reply-To: References: <4762EEA4-6F7B-4803-9C1F-E4CF82C8837D@surfnet.nl> Message-ID: Hi Jerry, Thanks for the quick action! This REALLY messed up our production signers, I hope Paul & RH take quick action :( Cheers, Roland On 8 jul. 2012, at 15:22, Jerry Lundstr?m wrote: > Hi, > > This is the works of Paul Wouters. > > I have pointed this out to him and posted on EPEL issue > (https://bugzilla.redhat.com/show_bug.cgi?id=711899) that this is an > ALPHA release and should not be pushed to production. > > It went unnoticed... > > opendnssec-1.4.0-0.a1.el6.2 has been pushed to the Fedora EPEL 6 > stable repository. > opendnssec-1.4.0-0.a1.fc16.2 has been pushed to the Fedora 16 stable repository. > opendnssec-1.4.0-0.a1.fc17.2 has been pushed to the Fedora 17 stable repository. > > /Jerry > > On Sun, Jul 8, 2012 at 2:55 PM, Roland van Rijswijk - Deij > wrote: >> Hi all, >> >> A friendly warning: we are currently dealing with the fall out from what appears to be a stupid mistake by Red Hat. OpenDNSSEC 1.4.0a1 has appeared in repositories that are apparently configured on production systems by default. Consequently, our well-managed 1.3.9 install has been upgraded to 1.4.0a1 and all configuration has been wiped. >> >> I don't know which one of you (if any) has contacts at Fedora/Red Hat, but please tell them that 1.4.0 is an alpha that should NEVER end up in production repositories? -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From matthijs at nlnetlabs.nl Mon Jul 9 08:18:29 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Mon, 09 Jul 2012 10:18:29 +0200 Subject: [Opendnssec-develop] Meeting 2012-07-10 In-Reply-To: References: Message-ID: <4FFA93D5.6080505@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am terribly sorry, but I have appeared to schedule a conflict and cannot join tomorrows teleconference. My input for the meeting would have been: * OPENDNSSEC-269: identified the cause of the crash and fixed in trunk. * The two open issues from Rick still remain for 1.3.10. I would be opposed against a release * OPENDNSSEC-261 still remains open for the 1.4.0 beta. Also, I still should start DNS adapter tests. I fear that I have time for that after the IETF. * A request for ods-checkzone passed by on the list: https://issues.opendnssec.org/browse/SUPPORT-31. Do people think this is a good idea. If so, for which version should we schedule it? * Perhaps we should discuss what (more) actions we should do about the EPEL 6 debacle. I have added those things to the agenda on the wiki (in orange, feel free to change the color). Best regards, Matthijs On 07/08/2012 03:04 PM, Sara (Sinodun) wrote: > All, > > We have a scheduled team meeting on Tuesday: > > Date: Tuesday, 10th July 2012 Time: 14:00-15:00 CEST > > The agenda and outstanding actions can be found here: > > https://wiki.opendnssec.org/display/OpenDNSSEC/2012-07-10+Meeting > > Anyone planning on attending the next developer workshop who > hasn't filled in the doodle yet could you please do this before the > meeting so we can discuss dates and locations: > > http://www.doodle.com/c36ztcse476hshww > > I haven't got a alternative PSTN conference option set up yet so > we'll use the normal call details. > > Thanks > > Sara. > > > > _______________________________________________ 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/ iQEcBAEBAgAGBQJP+pPVAAoJEA8yVCPsQCW54dgH/2z2LojrvU/xeCQmF0AusBcG yI13vrdSwP6XYE18LedoaehwuOfHnEJ673TP94O2Ig2mXwSJS84mW7/6yQdkd9rw 7BlSoL+N+wvZ7jO7Of9+Cj9dUHZxQB/I+DJGrxwTTVVPsr4O8D7tTooJpHpAmCv5 Q46jh9YGOoCAOpW6llUKbL/zEcMKsC5gcMa+FaFD6ivoMXJKonlvKZfWvHWmNZSc dkL5jAlLSPY+k7lpbUt3KQTg5bh/TeIB+QEXyg2thXLYNvieCHgCslZQmx14pb/L r8EmCS2nzPuE/Uh+vCZkc2zU6TURbvZSAK4GTqdzHumhqSTNa8qhstem8fKT+pY= =PA12 -----END PGP SIGNATURE----- From jerry at opendnssec.org Mon Jul 9 13:02:24 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Mon, 9 Jul 2012 15:02:24 +0200 Subject: [Opendnssec-develop] Resent timing issues and leap second ? Message-ID: Hi, There has been some reports in the last week about "strange" timing issues with zones and Patrik have had a few problems also with his zones expiring, most have solved it with a restart. It got me thinking of the leap second and maybe it messed with our timings? /Jerry -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From rick at openfortress.nl Tue Jul 10 10:09:38 2012 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 10 Jul 2012 10:09:38 +0000 Subject: [Opendnssec-develop] Making PropagationDelay interactive Message-ID: <20120710100938.GA9544@newphantom.local> Hello Si?n, We're going to automate DS-uploads; as usual we'll be quite public about how this can be done. But I have a question, because we're assuming 2.0-ish behaviour that we'd like to patch into 1.x. We don't know the Enforcer completely, so here are some questions. 1. Are there no exceptions to this KSK maturation path? Generate -> publish DNSKEY -> Ready -> publish DS -> Active 2. Is it possible to set a future time in the "ready" column of dnsseckeys? If we do that, will the key automatically go to the ready state at some time after that setting, and pickup on further actions? We'd prefer not to rely on some magic value of PropagationDelay, but wish to actually check until the authoritatives pickup on a new DNSKEY set, and if it does, report that back to the Enforcer; when that happens, we would want it to wait for TTL(DNSKEY) + PublishSafety before we would be hinted to publish the DS to the parent. This wait could be done by setting the "ready" timestamp to the current time plus the wait time. This enables elegant / simple scripting outside the Enforcer, mostly limited to the details of the local setup, and leave all the timing complexity and generic issues inside the Enforcer. And, it'd be "2.0 ready" scripting, so people can easily upgrade. If you think this makes no sense then please let us know :) Thanks, -Rick From rick at openfortress.nl Tue Jul 10 13:22:07 2012 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 10 Jul 2012 13:22:07 +0000 Subject: [Opendnssec-develop] Meeting notes 2012-07-10 are online Message-ID: <20120710132207.GB9859@newphantom.local> Hello, The notes for our meeting just yet are online. Please correct them if you need to. I will be on holiday soon, and should not be relied upon for an exchange on them for another 3 weeks. Until then, I'll be happily wiggling my toes. https://wiki.opendnssec.org/display/OpenDNSSEC/2012-07-10+Minutes Cheers, -Rick From sara at sinodun.com Tue Jul 10 15:17:15 2012 From: sara at sinodun.com (Sara Dickinson) Date: Tue, 10 Jul 2012 16:17:15 +0100 Subject: [Opendnssec-develop] Making PropagationDelay interactive In-Reply-To: <20120710100938.GA9544@newphantom.local> References: <20120710100938.GA9544@newphantom.local> Message-ID: Hi Rick, Sion is leave at the moment so in the meantime, as looks like something we should investigate, I have created a ticket for it: https://issues.opendnssec.org/browse/OPENDNSSEC-295 Sara. On 10 Jul 2012, at 11:09, Rick van Rein wrote: > Hello Si?n, > > We're going to automate DS-uploads; as usual we'll be quite public > about how this can be done. But I have a question, because we're > assuming 2.0-ish behaviour that we'd like to patch into 1.x. We > don't know the Enforcer completely, so here are some questions. > > 1. Are there no exceptions to this KSK maturation path? > Generate -> publish DNSKEY -> Ready -> publish DS -> Active > > 2. Is it possible to set a future time in the "ready" column of > dnsseckeys? If we do that, will the key automatically go to the > ready state at some time after that setting, and pickup on further > actions? > > We'd prefer not to rely on some magic value of PropagationDelay, but > wish to actually check until the authoritatives pickup on a new DNSKEY > set, and if it does, report that back to the Enforcer; when that > happens, we would want it to wait for TTL(DNSKEY) + PublishSafety > before we would be hinted to publish the DS to the parent. This > wait could be done by setting the "ready" timestamp to the current > time plus the wait time. > > This enables elegant / simple scripting outside the Enforcer, > mostly limited to the details of the local setup, and leave all > the timing complexity and generic issues inside the Enforcer. > And, it'd be "2.0 ready" scripting, so people can easily upgrade. > > > If you think this makes no sense then please let us know :) > > > Thanks, > -Rick > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From sara at sinodun.com Tue Jul 10 16:09:56 2012 From: sara at sinodun.com (Sara Dickinson) Date: Tue, 10 Jul 2012 17:09:56 +0100 Subject: [Opendnssec-develop] Meeting notes 2012-07-10 are online In-Reply-To: <20120710132207.GB9859@newphantom.local> References: <20120710132207.GB9859@newphantom.local> Message-ID: All, I've updated the format to show comments made in the meeting in blue (as Sion did a few weeks ago) as I think this makes it easy to read. I've also summarised the actions at the end and upgraded some comments to actions so they don't get forgotten: Sara: Resend audit recommendation page for review. Sara: Find someone to chair the next meeting Rick: Talk to Roland and see if SURFnet could pick up on the PIN daemon task, to avoid delaying to 1.4.1. Hope everyone is happy with this. Sara. On 10 Jul 2012, at 14:22, Rick van Rein wrote: > Hello, > > The notes for our meeting just yet are online. Please correct them if you need > to. I will be on holiday soon, and should not be relied upon for an exchange > on them for another 3 weeks. Until then, I'll be happily wiggling my toes. > > https://wiki.opendnssec.org/display/OpenDNSSEC/2012-07-10+Minutes > > Cheers, > -Rick > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From rick at openfortress.nl Wed Jul 11 11:50:57 2012 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Jul 2012 11:50:57 +0000 Subject: [Opendnssec-develop] PIN daemon Message-ID: <20120711115057.GA13456@newphantom.local> Hello Sara/others, Roland agreed with me that putting some effort into a code review of the PIN daemon is well spent, especially if that gets it into 1.4.0. I will do that when I'm back (somewhere on/after the 30th of July) so a pointer to the code version to be reviewed is welcome. What are the certainties to chase? I presume it is not leaking the PIN? Cheers, -Rick From sara at sinodun.com Wed Jul 11 12:01:56 2012 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 11 Jul 2012 13:01:56 +0100 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: <20120711115057.GA13456@newphantom.local> References: <20120711115057.GA13456@newphantom.local> Message-ID: <8094F447-5E1C-4961-B162-6EDFF2BFF081@sinodun.com> Hi Rick, This is excellent news - thank you. With luck that will mean it can go in the beta. This development is tracked by: https://issues.opendnssec.org/browse/OPENDNSSEC-130 which has some information and comments on the design. There are two implementations - I believe the branch: branches/OpenDNSSEC-pin2 (r5966) is the one that needs reviewing. Rickard implemented this so if you have specific questions it is probably best to talk to him. Regards Sara. On 11 Jul 2012, at 12:50, Rick van Rein wrote: > Hello Sara/others, > > Roland agreed with me that putting some effort into a code review of the PIN > daemon is well spent, especially if that gets it into 1.4.0. I will do that > when I'm back (somewhere on/after the 30th of July) so a pointer to the code > version to be reviewed is welcome. > > What are the certainties to chase? I presume it is not leaking the PIN? > > Cheers, > -Rick From sara at sinodun.com Wed Jul 11 12:25:07 2012 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 11 Jul 2012 13:25:07 +0100 Subject: [Opendnssec-develop] RE: Audit recommendations for 1.4 Message-ID: <3D18847C-48C7-40E9-9EE0-44977B1C5254@sinodun.com> Hi All, If anyone has time I would appreciate someone looking over/correcting/adding to: https://wiki.opendnssec.org/display/DOCSTRUNK/External+Auditing+of+Zones This is for https://issues.opendnssec.org/browse/OPENDNSSEC-144 Best regards Sara. From sara at sinodun.com Wed Jul 11 14:02:54 2012 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 11 Jul 2012 15:02:54 +0100 Subject: [Opendnssec-develop] RE: Reminder - Enforcer NG telecon this Friday, 13th July 2012 at 14:00 CEST Message-ID: <114FE648-45C7-4467-BC95-6034B04D16C3@sinodun.com> Hi All, A reminder that there is an Enforcer NG telecon this Friday Date: 13th June 2012 Time: 14:00 CEST Suggested agenda is here: https://wiki.opendnssec.org/display/OpenDNSSEC/2012-07-13+-+Enforcer+NG+telecon I'll assume it is OK to use the normal (SURFNet) conference bridge unless I hear otherwise. Regards Sara. From Roland.vanRijswijk at surfnet.nl Wed Jul 11 14:50:51 2012 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Wed, 11 Jul 2012 16:50:51 +0200 Subject: [Opendnssec-develop] RE: Reminder - Enforcer NG telecon this Friday, 13th July 2012 at 14:00 CEST In-Reply-To: <114FE648-45C7-4467-BC95-6034B04D16C3@sinodun.com> References: <114FE648-45C7-4467-BC95-6034B04D16C3@sinodun.com> Message-ID: <6B6A9271-04F5-4CBD-92C2-61D61E666A78@surfnet.nl> Hi Sara, All, On 11 jul. 2012, at 16:02, Sara Dickinson wrote: > Date: 13th June 2012 > Time: 14:00 CEST > > I'll assume it is OK to use the normal (SURFNet) conference bridge unless I hear otherwise. Yes, our conference bridge is available from 14:00h - 15:30h CEST. Cheers, Roland -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From rickard at opendnssec.org Thu Jul 12 07:14:23 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 12 Jul 2012 09:14:23 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: <8094F447-5E1C-4961-B162-6EDFF2BFF081@sinodun.com> References: <20120711115057.GA13456@newphantom.local> <8094F447-5E1C-4961-B162-6EDFF2BFF081@sinodun.com> Message-ID: > This is excellent news - thank you. With luck that will mean it can go in the beta. I have updated the story with some more information and some use cases that you can test. // Rickard From rickard at opendnssec.org Thu Jul 12 07:33:14 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 12 Jul 2012 09:33:14 +0200 Subject: [Opendnssec-develop] RE: Audit recommendations for 1.4 In-Reply-To: <3D18847C-48C7-40E9-9EE0-44977B1C5254@sinodun.com> References: <3D18847C-48C7-40E9-9EE0-44977B1C5254@sinodun.com> Message-ID: On Wed, Jul 11, 2012 at 2:25 PM, Sara Dickinson wrote: > Hi All, > > If anyone has time I would appreciate someone looking over/correcting/adding to: > > https://wiki.opendnssec.org/display/DOCSTRUNK/External+Auditing+of+Zones > > This is for > > https://issues.opendnssec.org/browse/OPENDNSSEC-144 Thank you Sara. This is exactly the text we wanted. // Rickard From matthijs at nlnetlabs.nl Thu Jul 12 08:54:57 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Thu, 12 Jul 2012 10:54:57 +0200 Subject: [Opendnssec-develop] Making PropagationDelay interactive In-Reply-To: <20120710100938.GA9544@newphantom.local> References: <20120710100938.GA9544@newphantom.local> Message-ID: <4FFE90E1.5030300@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/10/2012 12:09 PM, Rick van Rein wrote: > Hello Si?n, > > We're going to automate DS-uploads; as usual we'll be quite public > about how this can be done. But I have a question, because we're > assuming 2.0-ish behaviour that we'd like to patch into 1.x. We > don't know the Enforcer completely, so here are some questions. > > 1. Are there no exceptions to this KSK maturation path? Generate -> > publish DNSKEY -> Ready -> publish DS -> Active Not in the enforcer, it only does KSK Double Signature Rollover. In enforcer NG, there are of course different paths. > 2. Is it possible to set a future time in the "ready" column of > dnsseckeys? If we do that, will the key automatically go to the > ready state at some time after that setting, and pickup on further > actions? > > We'd prefer not to rely on some magic value of PropagationDelay, > but wish to actually check until the authoritatives pickup on a new > DNSKEY set, and if it does, report that back to the Enforcer; when > that happens, we would want it to wait for TTL(DNSKEY) + > PublishSafety before we would be hinted to publish the DS to the > parent. This wait could be done by setting the "ready" timestamp > to the current time plus the wait time. > > This enables elegant / simple scripting outside the Enforcer, > mostly limited to the details of the local setup, and leave all the > timing complexity and generic issues inside the Enforcer. And, it'd > be "2.0 ready" scripting, so people can easily upgrade. > > > If you think this makes no sense then please let us know :) > > > Thanks, -Rick _______________________________________________ > 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/ iQEcBAEBAgAGBQJP/pDhAAoJEA8yVCPsQCW5Hp4IAI+MYQKmm7dxDJEoTlhbBjRo 0pVDp+mDyC2a9BqMsXfN3/Hk/uLz6fAohVv2m6Hi3R8KgEH+XYXo2KR9omZggK+x Edob4mnkV0hMd5Fhj1uanCbZWXHKbB/uogoZ57avKuOMmoZK/dXoaoeQ3YLdS49Q eEo55mkUm3u1EYS6IOK2Kluh9uY4X/ImtiXYKURhGhrH6vJJdnmm4oSWEXdQYHi1 1TAcl7U7yd8mCXqaitLDmPWFwdlAI9DoHeQGIYYmQgLhNgz9wtgbm6m5MMcS8BT2 xdcAQfKSLry0l+iFTTGYWXIBtKJI/mgKnmRYFXeJ05B4ALocwTwze77TewoFQoo= =XXgS -----END PGP SIGNATURE----- From yuri at nlnetlabs.nl Thu Jul 12 09:19:01 2012 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Thu, 12 Jul 2012 11:19:01 +0200 Subject: [Opendnssec-develop] Key pregeneration count Message-ID: <4FFE9685.3010105@nlnetlabs.nl> I took a look at the number of pregenerated keys on setup. This is how the enforcer works: - User can manually issue command to generate keys for duration X. ods-enforcer hsm key gen --duration X It will generate for all policies - at setup keys are pregenerated. Interval is configured in conf.xml P1Y This should be workable however it seems odd that both options are not policy specific. From rick at openfortress.nl Thu Jul 12 09:28:24 2012 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 12 Jul 2012 09:28:24 +0000 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: <20120711115057.GA13456@newphantom.local> <8094F447-5E1C-4961-B162-6EDFF2BFF081@sinodun.com> Message-ID: <20120712092824.GA17016@newphantom.local> Hello Rickard and Sara and others, > > This is excellent news - thank you. With luck that will mean it can go in the beta. > > I have updated the story with some more information and some use cases > that you can test. I found it on https://issues.opendnssec.org/browse/OPENDNSSEC-130 These are tests -- I was under the impression that was holding back the release into beta was a code review? Or are both necessary? If a code review is called for, I'd like to know what requirements should be established -- is it "not leaking the PIN to others than root and the OpenDNSSEC user"? As for the ipcrm, I would expect that to go into a start/stop script, and/or into ods-control. This would be easier to operators, and it seems to make sense, given that the Signer and Enforcer are also switched on/off that way. Also, we may in the future feel a need to wipe the area before ipcrm'ing it (even if only root could harvest it under the assumption of a properly functioning UNIX environment). As for the name "PIN daemon", it should perhaps be rephrased, indeed. What about "PIN service" or "PIN storage" or "PIN memory"? Cheers, -Rick From rickard at opendnssec.org Thu Jul 12 09:40:07 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 12 Jul 2012 11:40:07 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: <20120712092824.GA17016@newphantom.local> References: <20120711115057.GA13456@newphantom.local> <8094F447-5E1C-4961-B162-6EDFF2BFF081@sinodun.com> <20120712092824.GA17016@newphantom.local> Message-ID: Hi Rick > These are tests -- I was under the impression that was holding back the > release into beta was a code review? Or are both necessary? > > If a code review is called for, I'd like to know what requirements should > be established -- is it "not leaking the PIN to others than root and the > OpenDNSSEC user"? You reviewed the design for some time ago. Jakob were support to test the functionality, but a code review is never bad. > As for the ipcrm, I would expect that to go into a start/stop script, > and/or into ods-control. This would be easier to operators, and it > seems to make sense, given that the Signer and Enforcer are also > switched on/off that way. Also, we may in the future feel a need to > wipe the area before ipcrm'ing it (even if only root could harvest > it under the assumption of a properly functioning UNIX environment). The ipcrm is only used now for testing. Just so that we can reset the state. The design is for the PIN to live in the shared memory for the uptime of the server. > As for the name "PIN daemon", it should perhaps be rephrased, indeed. > What about "PIN service" or "PIN storage" or "PIN memory"? Yes, "PIN memory" would be a better name. From jakob at kirei.se Thu Jul 12 10:29:32 2012 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 12 Jul 2012 12:29:32 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: <20120711115057.GA13456@newphantom.local> <8094F447-5E1C-4961-B162-6EDFF2BFF081@sinodun.com> <20120712092824.GA17016@newphantom.local> Message-ID: <9D34867F-F2C2-4B30-8255-FD6E7F1E9927@kirei.se> Or "HSM Credentials Cache" ? -- Sent from my iPhone, hence this mail might be briefer than normal. 12 jul 2012 kl. 11:40 skrev Rickard Bellgrim : > Yes, "PIN memory" would be a better name. From sara at sinodun.com Thu Jul 12 10:57:41 2012 From: sara at sinodun.com (Sara (Sinodun)) Date: Thu, 12 Jul 2012 11:57:41 +0100 Subject: [Opendnssec-develop] RE: Supporting downgrades Message-ID: <3E3CA970-DABD-42AA-9480-5B9B282916E1@sinodun.com> Hi All, The recent discussion on package contents has raised an interesting question - do we plan to provide migration scripts for users to downgrade between *major* versions e.g. 1.4.0 to 1.3.10. It does not appear that historically this has been done for previous releases. What might be other consequences of users downgrading? Sara. From sara at sinodun.com Thu Jul 12 10:58:30 2012 From: sara at sinodun.com (Sara (Sinodun)) Date: Thu, 12 Jul 2012 11:58:30 +0100 Subject: [Opendnssec-develop] RE: Signing back-offs Message-ID: <43CAE993-B2C9-495A-8029-C5E6D700B05D@sinodun.com> Hi All, There seems to be a lot of traffic on the users list about problems with signature expiry dates and signing back-offs for various reasons. Some issues have been traced to: - use of the auditor. (This can be addresses by disabling the auditor.) - configuration issues however there are a couple we haven't been able to get the bottom of, or are still waiting for logs to investigate. I know that Paul, in particular, has a sense that 1.3 is unreliable in this regard. I have opened this thread to tackle the following: 1) Do we think there is an underlying issue and if so can we form a plan to investigate. 2) Paul - please make us aware of any specific issues on this that have been reported but you think merit further investigation. (I believe https://issues.opendnssec.org/browse/SUPPORT-22 is in this category?) We absolutely want to know about and fix issues in 1.3. 3) Can we think of any improvements to tools or monitoring, documentation, etc that would help users detect signing back-off issues earlier? Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard at opendnssec.org Thu Jul 12 11:18:09 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 12 Jul 2012 13:18:09 +0200 Subject: [Opendnssec-develop] RE: Supporting downgrades In-Reply-To: <3E3CA970-DABD-42AA-9480-5B9B282916E1@sinodun.com> References: <3E3CA970-DABD-42AA-9480-5B9B282916E1@sinodun.com> Message-ID: > The recent discussion on package contents has raised an interesting question - do we plan to provide migration scripts for users to downgrade between *major* versions e.g. 1.4.0 to 1.3.10. It does not appear that historically this has been done for previous releases. Yes, that would be useful. A script called something like "migration-1.4.0.sh" where all migration code is gathered in one file for that version. If you do not run it with any arguments then you get some description on what versions you can upgrade from. If you run it with "-a" then you apply the changes. If you run with "-r" then you revert the changes. // Rickard From matthijs at nlnetlabs.nl Thu Jul 12 11:47:11 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Thu, 12 Jul 2012 13:47:11 +0200 Subject: [Opendnssec-develop] RE: Signing back-offs In-Reply-To: <43CAE993-B2C9-495A-8029-C5E6D700B05D@sinodun.com> References: <43CAE993-B2C9-495A-8029-C5E6D700B05D@sinodun.com> Message-ID: <4FFEB93F.1050808@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/12/2012 12:58 PM, Sara (Sinodun) wrote: > Hi All, > > There seems to be a lot of traffic on the users list about problems > with signature expiry dates and signing back-offs for various > reasons. Some issues have been traced to: > > - use of the auditor. (This can be addresses by disabling the > auditor.) - configuration issues > > however there are a couple we haven't been able to get the bottom > of, or are still waiting for logs to investigate. I know that Paul, > in particular, has a sense that 1.3 is unreliable in this regard. I > have opened this thread to tackle the following: > > 1) Do we think there is an underlying issue and if so can we form a > plan to investigate. It is interesting to see that all come reasonably at the same time, and some one suggested it could be related to the leap second story. However, I lack knowledge on that topic at the moment to fully understand how it could interfere with the OpenDNSSEC timings. > > 2) Paul - please make us aware of any specific issues on this that > have been reported but you think merit further investigation. (I > believe https://issues.opendnssec.org/browse/SUPPORT-22 is in this > category?) We absolutely want to know about and fix issues in 1.3. > > 3) Can we think of any improvements to tools or monitoring, > documentation, etc that would help users detect signing back-off > issues earlier? You can run nagios to monitor your zones. It can tell you when a signature is about to expire. I guess that the duration is configurable, so you can set it to equal the Refresh value, so at the moment nagios complains you know that a signature has not been properly refreshed. Best regards, Matthijs > > Sara. > > > > > > _______________________________________________ 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/ iQEcBAEBAgAGBQJP/rk/AAoJEA8yVCPsQCW5nvMIAKpSPP4HZPkH7Hj+lmA/L0BA jCXvLUyq86YBiKoo89ZjxxoK4Mr0QFDA6OOp3B4aQFFd6I8cqGutF59OOmBg6hVJ FVGyuffuZ+qh7Zino9/j18Usj69bzPTkSaHv71lMK6IoE+spi9bv9jyhTw+W9shr hN+E8BT7mTYjQEc+MVGr3OgR4FYQ0eNUwY77VGTI5w52k28EPkoADTIEwC2z/Ojq acjfdJ+HahLmyBDykBWKyq+q8sKnjBAa2vOvhzZahXFBAE2wOxlWWbLV0vjRjsXu 1tQtU6Utx1rLkwCxkTHPEUbqKZqrpVB5bYjhlq8FMNQZDfxt3vEYbI/AheUK3F4= =rv2Z -----END PGP SIGNATURE----- From sara at sinodun.com Fri Jul 13 10:14:02 2012 From: sara at sinodun.com (Sara (Sinodun)) Date: Fri, 13 Jul 2012 11:14:02 +0100 Subject: [Opendnssec-develop] RE: Supporting downgrades In-Reply-To: References: <3E3CA970-DABD-42AA-9480-5B9B282916E1@sinodun.com> Message-ID: <7658F1A2-7F9C-4B6D-86B2-9CA752C314C4@sinodun.com> On 12 Jul 2012, at 12:18, Rickard Bellgrim wrote: >> The recent discussion on package contents has raised an interesting question - do we plan to provide migration scripts for users to downgrade between *major* versions e.g. 1.4.0 to 1.3.10. It does not appear that historically this has been done for previous releases. > > Yes, that would be useful. A script called something like > "migration-1.4.0.sh" where all migration code is gathered in one file > for that version. If you do not run it with any arguments then you get > some description on what versions you can upgrade from. If you run it > with "-a" then you apply the changes. If you run with "-r" then you > revert the changes. I will open a ticket to address this in 1.4. I also want to clarify something with regard to upgrades. 1) AFAIK the db upgrade scripts provided for ODS would normally follow this kind of pattern: 1.3.x -> 1.4.0a1 (for testing) 1.3.x -> 1.4.0a2 (for testing) 1.3.x -> 1.4.0 (supported upgrade path) So - in other words there wouldn't normally be a script provided for e.g. 1.4.0a1 -> 1.4.0 if it were needed. This is a major reason we recommend alphas are not used in production. 2) In practice (and I think this holds for 1.4 so far) this hasn't been a problem because a migration script from an alpha to full release has never been needed. (Sion is best placed to answer this but he is on leave right now.) The reason I ask is that Paul is using 1.4.0a1 in production and it may be the case that it remains in EPEL to be replaced by 1.4.0 when it is available. So, if a script were to be needed, we might need to support users in the specific case of 1.4.0a1 -> 1.4.0. However I want to set expectations correctly in that this is not something we support in general. If anyone disagrees with this approach please let me know. From jerry at opendnssec.org Fri Jul 13 11:40:51 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Fri, 13 Jul 2012 13:40:51 +0200 Subject: [Opendnssec-develop] Supporting downgrades In-Reply-To: <7658F1A2-7F9C-4B6D-86B2-9CA752C314C4@sinodun.com> References: <3E3CA970-DABD-42AA-9480-5B9B282916E1@sinodun.com> <7658F1A2-7F9C-4B6D-86B2-9CA752C314C4@sinodun.com> Message-ID: On Jul 13, 2012, at 12:14 , Sara (Sinodun) wrote: > > On 12 Jul 2012, at 12:18, Rickard Bellgrim wrote: > >>> The recent discussion on package contents has raised an interesting question - do we plan to provide migration scripts for users to downgrade between *major* versions e.g. 1.4.0 to 1.3.10. It does not appear that historically this has been done for previous releases. >> >> Yes, that would be useful. -1 We must realize there is a lot of work supporting downgrades and in most cases it can't be done since there is often new features with new major releases that don't exist in old releases. With my 10+ years sysadmin hat on: it is not common practice to support major version downgrades or even do them, if there is a problem with a software even after testing you do a rollback to a backup of the old version. Having said that, if there is consensus amount developers that this should be done then I feel it should be brought up on the next OpenDNSSEC Architectural Board meeting and decided on what level this should effect the project. It would most likely prolong releases and may impact on feature selection, can we implement features that can't be downgraded etc. Regarding this very special case with 1.4.0a1 in EPEL; it is decided by OAB that distribution packaging should not be done within the project, that responsibility is on the maintainers shoulders. Maybe its time to revise that in order to gain more control over the packages and increase the quality of releases. /Jerry -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From jerry at opendnssec.org Fri Jul 13 11:46:19 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Fri, 13 Jul 2012 13:46:19 +0200 Subject: [Opendnssec-develop] Fwd: [ldns-users] Memory leak in keys.c, ldns_key_new_frm_algorithm References: <20120711101200.205a61dff9fc1684c258b274662bb912.ab31fcea1b.wbe@email00.secureserver.net> Message-ID: <921962D1-58DD-476C-AB03-904957D661C7@opendnssec.org> Hi Matthijs, Do you know if this memory leak affects OpenDNSSEC? /Jerry Begin forwarded message: > > From: Michael Sheldon > Subject: [ldns-users] Memory leak in keys.c, ldns_key_new_frm_algorithm > Date: July 11, 2012 19:12:00 GMT+02:00 > To: "ldns-users at open.nlnetlabs.nl" > > There are two memory leaks in keys.c, ldns_key_new_frm_algorithm > > The issue in the following is that ldns_key_set_rsa_key uses > EVP_PKEY_set1_RSA(), which *copies* the RSA data, thus the original data > must be freed by the calling application. > > 00837 case LDNS_SIGN_RSAMD5: > 00838 case LDNS_SIGN_RSASHA1: > 00839 case LDNS_SIGN_RSASHA1_NSEC3: > 00840 case LDNS_SIGN_RSASHA256: > 00841 case LDNS_SIGN_RSASHA512: > 00842 #ifdef HAVE_SSL > 00843 r = RSA_generate_key((int)size, RSA_F4, > NULL, NULL); > 00844 if(!r) { > 00845 ldns_key_free(k); > 00846 return NULL; > 00847 } > 00848 if (RSA_check_key(r) != 1) { > 00849 ldns_key_free(k); > 00850 return NULL; > 00851 } > 00852 ldns_key_set_rsa_key(k, r); > 00853 #endif /* HAVE_SSL */ > 00854 break; > > The solution is to use RSA_free(r) after line 852. > > The same issue applies in the following code. ldns_key_set_dsa_key uses > EVP_PKEY_set1_DSA(), which *copies* the DSA data, thus the original data > must be freed by the calling application. > > 00855 case LDNS_SIGN_DSA: > 00856 case LDNS_SIGN_DSA_NSEC3: > 00857 #ifdef HAVE_SSL > 00858 d = DSA_generate_parameters((int)size, > NULL, 0, NULL, NULL, NULL, NULL); > 00859 if (!d) { > 00860 ldns_key_free(k); > 00861 return NULL; > 00862 } > 00863 if (DSA_generate_key(d) != 1) { > 00864 ldns_key_free(k); > 00865 return NULL; > 00866 } > 00867 ldns_key_set_dsa_key(k, d); > 00868 #endif /* HAVE_SSL */ > 00869 break; > > The solution is to use DSA_free(d) after line 867. > > An alternative solution is to use EVP_PKEY_assign_RSA and > EVP_PKEY_assign_DSA in place of EVP_PKEY_set1_RSA and EVP_PKEY_set1_DSA. > The problem here is that it changes the existing behaviour of > ldns_key_set_rsa_key and ldns_key_set_dsa_key, which developers may be > calling. > > Michael Sheldon > Dev-DNS Services > GoDaddy.com -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From sara at sinodun.com Fri Jul 13 13:52:49 2012 From: sara at sinodun.com (Sara Dickinson) Date: Fri, 13 Jul 2012 14:52:49 +0100 Subject: [Opendnssec-develop] RE: Reminder - Enforcer NG telecon this Friday, 13th July 2012 at 14:00 CEST In-Reply-To: <114FE648-45C7-4467-BC95-6034B04D16C3@sinodun.com> References: <114FE648-45C7-4467-BC95-6034B04D16C3@sinodun.com> Message-ID: Hi All, Minutes from today's meeting are available here: https://wiki.opendnssec.org/display/OpenDNSSEC/2012-07-13+-+Enforcer+NG+telecon As always - please correct/update as needed. Regards Sara. From sara at sinodun.com Fri Jul 13 14:39:50 2012 From: sara at sinodun.com (Sara Dickinson) Date: Fri, 13 Jul 2012 15:39:50 +0100 Subject: [Opendnssec-develop] RE: Signing back-offs In-Reply-To: References: <43CAE993-B2C9-495A-8029-C5E6D700B05D@sinodun.com> <4FFEB93F.1050808@nlnetlabs.nl> Message-ID: On 12 Jul 2012, at 16:09, Paul Wouters wrote: > I think something more preventive should be done. For example, if signing > has stopped, and running ods-control stop, rm -rf /var/opendnssec/tmp/* > ; ods-control start works around an issue, then I see no reason why ODS > itself cannot perform the equivalent of this, and only leave the current > behaviour of remaining in back-off for developers so they can investigate > the bug causing this. The enduser just wants their zone to remain valid. Matthijs - do you think it would be possible to develop a safe mechanism to try to 'force' a signing for a particular zone through along the lines Paul suggests? I guess it would be the equivalent of the user doing > ods-signer clear > ods-signer sign If so - could we add an option where a user can specify a parameter to control how many failed tries (or how long) the signer waits until it resorts to the force mechanism. Without this parameter defined then, by default, the system would still continue to back off. Sara. From matthijs at nlnetlabs.nl Mon Jul 16 12:08:08 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Mon, 16 Jul 2012 14:08:08 +0200 Subject: [Opendnssec-develop] Fwd: [ldns-users] Memory leak in keys.c, ldns_key_new_frm_algorithm In-Reply-To: <921962D1-58DD-476C-AB03-904957D661C7@opendnssec.org> References: <20120711101200.205a61dff9fc1684c258b274662bb912.ab31fcea1b.wbe@email00.secureserver.net> <921962D1-58DD-476C-AB03-904957D661C7@opendnssec.org> Message-ID: <50040428.9020105@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It does not. OpenDNSSEC does not depend on the openssl parts of ldns. Best regards, Matthijs On 07/13/2012 01:46 PM, Jerry Lundstr?m wrote: > Hi Matthijs, > > Do you know if this memory leak affects OpenDNSSEC? > > /Jerry > > Begin forwarded message: >> >> From: Michael Sheldon Subject: >> [ldns-users] Memory leak in keys.c, ldns_key_new_frm_algorithm >> Date: July 11, 2012 19:12:00 GMT+02:00 To: >> "ldns-users at open.nlnetlabs.nl" >> >> There are two memory leaks in keys.c, ldns_key_new_frm_algorithm >> >> The issue in the following is that ldns_key_set_rsa_key uses >> EVP_PKEY_set1_RSA(), which *copies* the RSA data, thus the >> original data must be freed by the calling application. >> >> 00837 case LDNS_SIGN_RSAMD5: 00838 >> case LDNS_SIGN_RSASHA1: 00839 case >> LDNS_SIGN_RSASHA1_NSEC3: 00840 case >> LDNS_SIGN_RSASHA256: 00841 case >> LDNS_SIGN_RSASHA512: 00842 #ifdef HAVE_SSL 00843 >> r = RSA_generate_key((int)size, RSA_F4, NULL, NULL); 00844 >> if(!r) { 00845 ldns_key_free(k); >> 00846 return NULL; 00847 >> } 00848 if (RSA_check_key(r) != 1) { >> 00849 ldns_key_free(k); 00850 >> return NULL; 00851 } 00852 >> ldns_key_set_rsa_key(k, r); 00853 #endif /* HAVE_SSL */ 00854 >> break; >> >> The solution is to use RSA_free(r) after line 852. >> >> The same issue applies in the following code. >> ldns_key_set_dsa_key uses EVP_PKEY_set1_DSA(), which *copies* the >> DSA data, thus the original data must be freed by the calling >> application. >> >> 00855 case LDNS_SIGN_DSA: 00856 >> case LDNS_SIGN_DSA_NSEC3: 00857 #ifdef HAVE_SSL 00858 >> d = DSA_generate_parameters((int)size, NULL, 0, NULL, NULL, NULL, >> NULL); 00859 if (!d) { 00860 >> ldns_key_free(k); 00861 return >> NULL; 00862 } 00863 >> if (DSA_generate_key(d) != 1) { 00864 >> ldns_key_free(k); 00865 return >> NULL; 00866 } 00867 >> ldns_key_set_dsa_key(k, d); 00868 #endif /* HAVE_SSL */ 00869 >> break; >> >> The solution is to use DSA_free(d) after line 867. >> >> An alternative solution is to use EVP_PKEY_assign_RSA and >> EVP_PKEY_assign_DSA in place of EVP_PKEY_set1_RSA and >> EVP_PKEY_set1_DSA. The problem here is that it changes the >> existing behaviour of ldns_key_set_rsa_key and >> ldns_key_set_dsa_key, which developers may be calling. >> >> Michael Sheldon Dev-DNS Services GoDaddy.com > > > -- 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQBAQlAAoJEA8yVCPsQCW54HoIANMrIofTYQH50drK2qcEWqxb 4t3HJ+IWKsf6O2MGQEuAXx3e5oEEk8FpjLPtMS2tqzN58MTEgqleW1C5n8OVr/hE alOzg1GN1FICYv2jBPzhaMQYQDIZv5si6+0vDhS+7QpU3NFAVaVZO9YF3COZebw4 uSGuN5ocQv5ydY78CWcRxSYRAhlwU5ou1TH/Id+MHhyfXwgBrJBc09aFChJQCPkI 8BgjHv/xaSqsdrJTnccdgvjzY6RzrQDA3h0vKQmyXuZe4UKKE5obrIham/ccNhFf VJVKZzrJCl8j93qyjSHrR3rG5OYb3i4/7Kivl3gBDdthMVjmYxqh5MqR/OsfwBQ= =to9j -----END PGP SIGNATURE----- From sara at sinodun.com Mon Jul 16 12:33:55 2012 From: sara at sinodun.com (Sara Dickinson) Date: Mon, 16 Jul 2012 13:33:55 +0100 Subject: [Opendnssec-develop] Supporting downgrades In-Reply-To: References: <3E3CA970-DABD-42AA-9480-5B9B282916E1@sinodun.com> <7658F1A2-7F9C-4B6D-86B2-9CA752C314C4@sinodun.com> Message-ID: On 13 Jul 2012, at 12:40, Jerry Lundstr?m wrote: > > -1 > > We must realize there is a lot of work supporting downgrades and in most cases it can't be done since there is often new features with new major releases that don't exist in old releases. > > With my 10+ years sysadmin hat on: it is not common practice to support major version downgrades or even do them, if there is a problem with a software even after testing you do a rollback to a backup of the old version. > > Having said that, if there is consensus amount developers that this should be done then I feel it should be brought up on the next OpenDNSSEC Architectural Board meeting and decided on what level this should effect the project. It would most likely prolong releases and may impact on feature selection, can we implement features that can't be downgraded etc. Given the above, I suppose the main reason to support it would be if there were clear use cases where a rollback to a backup of the old version cannot be done for some reason. I am not aware of any for supported upgrade paths. > > Regarding this very special case with 1.4.0a1 in EPEL; it is decided by OAB that distribution packaging should not be done within the project, that responsibility is on the maintainers shoulders. Maybe its time to revise that in order to gain more control over the packages and increase the quality of releases. > > /Jerry Personally, I am hopeful that providing clearer statements recommending how alphas and betas should be used will address this issue in future. Sara. From jerry at opendnssec.org Tue Jul 17 08:01:01 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Tue, 17 Jul 2012 10:01:01 +0200 Subject: [Opendnssec-develop] Jenkins: All jobs have disappeared In-Reply-To: References: <5943CAED-69D5-4A94-AC66-3F0DD72DA705@sinodun.com> Message-ID: Looks like a bugfix is coming with 1.475, should be out any day now. /Jerry From matthijs at nlnetlabs.nl Tue Jul 17 14:13:51 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Tue, 17 Jul 2012 16:13:51 +0200 Subject: [Opendnssec-develop] RE: Signing back-offs In-Reply-To: References: <43CAE993-B2C9-495A-8029-C5E6D700B05D@sinodun.com> <4FFEB93F.1050808@nlnetlabs.nl> Message-ID: <5005731F.7050901@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/13/2012 04:39 PM, Sara Dickinson wrote: > > On 12 Jul 2012, at 16:09, Paul Wouters wrote: > >> I think something more preventive should be done. For example, if >> signing has stopped, and running ods-control stop, rm -rf >> /var/opendnssec/tmp/* ; ods-control start works around an issue, >> then I see no reason why ODS itself cannot perform the equivalent >> of this, and only leave the current behaviour of remaining in >> back-off for developers so they can investigate the bug causing >> this. The enduser just wants their zone to remain valid. > > Matthijs - do you think it would be possible to develop a safe > mechanism to try to 'force' a signing for a particular zone through > along the lines Paul suggests? I guess it would be the equivalent > of the user doing >> ods-signer clear ods-signer sign We can do that, but why make another feature, if that functionality is already there? You can run right now. > > If so - could we add an option where a user can specify a parameter > to control how many failed tries (or how long) the signer waits > until it resorts to the force mechanism. Without this parameter > defined then, by default, the system would still continue to back > off. I think this is good default behavior. Back off couple of times, if after a couple of failed retries just force fresh resign. Could you add the report to jira? Best regards, Matthijs > > Sara. > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQBXMfAAoJEA8yVCPsQCW51QkH/AnNGw+QZ9ranbZVbmBg7riQ d5318tu9YsODCvvPCBAAPO4jigC7/wGVOpBgo4icbsxLXH2VFq/VVfuorXpNA7wP gIbxatQBrTNTIpGduZSMiVNRHQ8SL9mBXvIzob+W6AkeEsLcSkfQf54nh4LsHV25 okIH7YQjUiUyagREiO+SOzx++bixlOz0NQO9JgywVCZIpZOjjn7hdU+ItRG8iSSu nbC4RrpzXFn3KNLYnnwCxnIYmLTALpdc2PhwmQ/QjPBO5gc3ydqEHuM+1R6SNTvP d+gW51N3oWerVRLs5V1ajLTiik8yZKpx1JErAomAxhYuoxR8ylzAlZkhSGYrWwk= =5Nj/ -----END PGP SIGNATURE----- From sara at sinodun.com Wed Jul 18 12:19:01 2012 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 18 Jul 2012 13:19:01 +0100 Subject: [Opendnssec-develop] RE: Signing back-offs In-Reply-To: <5005731F.7050901@nlnetlabs.nl> References: <43CAE993-B2C9-495A-8029-C5E6D700B05D@sinodun.com> <4FFEB93F.1050808@nlnetlabs.nl> <5005731F.7050901@nlnetlabs.nl> Message-ID: <10BBC012-E776-4016-96F4-0C9D75FF3909@sinodun.com> On 17 Jul 2012, at 15:13, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/13/2012 04:39 PM, Sara Dickinson wrote: >> >> On 12 Jul 2012, at 16:09, Paul Wouters wrote: >> >>> I think something more preventive should be done. For example, if >>> signing has stopped, and running ods-control stop, rm -rf >>> /var/opendnssec/tmp/* ; ods-control start works around an issue, >>> then I see no reason why ODS itself cannot perform the equivalent >>> of this, and only leave the current behaviour of remaining in >>> back-off for developers so they can investigate the bug causing >>> this. The enduser just wants their zone to remain valid. >> >> Matthijs - do you think it would be possible to develop a safe >> mechanism to try to 'force' a signing for a particular zone through >> along the lines Paul suggests? I guess it would be the equivalent >> of the user doing >>> ods-signer clear ods-signer sign > > We can do that, but why make another feature, if that functionality is > already there? You can run right now. I meant for internal use in the context below, not another CLI command but I didn't make this clear - sorry. Paul - thanks for this suggestion. > >> >> If so - could we add an option where a user can specify a parameter >> to control how many failed tries (or how long) the signer waits >> until it resorts to the force mechanism. Without this parameter >> defined then, by default, the system would still continue to back >> off. > > I think this is good default behavior. Back off couple of times, if > after a couple of failed retries just force fresh resign. Could you > add the report to jira? https://issues.opendnssec.org/browse/OPENDNSSEC-305 It is assigned to 1.4.1 for now but we can review this. > > Best regards, > Matthijs > >> >> Sara. >> >> >> >> > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJQBXMfAAoJEA8yVCPsQCW51QkH/AnNGw+QZ9ranbZVbmBg7riQ > d5318tu9YsODCvvPCBAAPO4jigC7/wGVOpBgo4icbsxLXH2VFq/VVfuorXpNA7wP > gIbxatQBrTNTIpGduZSMiVNRHQ8SL9mBXvIzob+W6AkeEsLcSkfQf54nh4LsHV25 > okIH7YQjUiUyagREiO+SOzx++bixlOz0NQO9JgywVCZIpZOjjn7hdU+ItRG8iSSu > nbC4RrpzXFn3KNLYnnwCxnIYmLTALpdc2PhwmQ/QjPBO5gc3ydqEHuM+1R6SNTvP > d+gW51N3oWerVRLs5V1ajLTiik8yZKpx1JErAomAxhYuoxR8ylzAlZkhSGYrWwk= > =5Nj/ > -----END PGP SIGNATURE----- From sara at sinodun.com Fri Jul 20 11:32:23 2012 From: sara at sinodun.com (Sara Dickinson) Date: Fri, 20 Jul 2012 12:32:23 +0100 Subject: [Opendnssec-develop] RE: Meeting 2012-07-24 Message-ID: <7747407A-8A47-404D-BF0F-3B75C8F67472@sinodun.com> Hi All, There is a scheduled team meeting next Tuesday: Date: Tuesday 24th July 2012 Time: 14:00-15:00 CEST, 13:00-14:00 BST The proposed agenda and outstanding actions can be found here: http://wiki.opendnssec.org/display/OpenDNSSEC/2012-07-24+Meeting with some comments from me in green. I can't attend as I am on leave but Roland has kindly agreed to chair the meeting. Sara. From jerry at opendnssec.org Mon Jul 23 06:50:34 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Mon, 23 Jul 2012 08:50:34 +0200 Subject: [Opendnssec-develop] Jenkins: All jobs have disappeared In-Reply-To: References: <5943CAED-69D5-4A94-AC66-3F0DD72DA705@sinodun.com> Message-ID: On Tue, Jul 17, 2012 at 10:01 AM, Jerry Lundstr?m wrote: > Looks like a bugfix is coming with 1.475, should be out any day now. 1.475 is available now, can you try it John? /Jerry From sion at nominet.org.uk Mon Jul 23 14:20:49 2012 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Mon, 23 Jul 2012 15:20:49 +0100 Subject: [Opendnssec-develop] Supporting downgrades In-Reply-To: References: <3E3CA970-DABD-42AA-9480-5B9B282916E1@sinodun.com> <7658F1A2-7F9C-4B6D-86B2-9CA752C314C4@sinodun.com> Message-ID: <500D5DC1.705@nominet.org.uk> On 13/07/12 12:40, Jerry Lundstr?m wrote: > On Jul 13, 2012, at 12:14 , Sara (Sinodun) wrote: >> On 12 Jul 2012, at 12:18, Rickard Bellgrim wrote: >> >>>> The recent discussion on package contents has raised an interesting question - do we plan to provide migration scripts for users to downgrade between *major* versions e.g. 1.4.0 to 1.3.10. It does not appear that historically this has been done for previous releases. >>> Yes, that would be useful. > > -1 > > We must realize there is a lot of work supporting downgrades and in most cases it can't be done since there is often new features with new major releases that don't exist in old releases. > > With my 10+ years sysadmin hat on: it is not common practice to support major version downgrades or even do them, if there is a problem with a software even after testing you do a rollback to a backup of the old version. +1 Assuming that the downgrade happens before any key rollover/generation occurs of course. Take the extreme example of the enforcerNG; I'm pretty sure we don't want to build a script to move back to the old enforcer? I'm not sure if all of the new states map back back cleanly even. Sion p.s. Sara, you are correct when you say that we have never needed a script to move between alpha and a full release. From Roland.vanRijswijk at surfnet.nl Tue Jul 24 13:26:00 2012 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Tue, 24 Jul 2012 15:26:00 +0200 Subject: [Opendnssec-develop] Meeting minutes Message-ID: <715AC7C6-6BD9-44B6-A54B-23F53978855B@surfnet.nl> Hi all, The meeting minutes for today's call are online: https://wiki.opendnssec.org/display/OpenDNSSEC/2012-07-24+Minutes Please update/comment if needed. Cheers, Roland -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From sion at nominet.org.uk Thu Jul 26 08:15:23 2012 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Thu, 26 Jul 2012 09:15:23 +0100 Subject: [Opendnssec-develop] Re: Making PropagationDelay interactive In-Reply-To: <20120710100938.GA9544@newphantom.local> References: <20120710100938.GA9544@newphantom.local> Message-ID: <5010FC9B.4060004@nominet.org.uk> On 10/07/12 11:09, Rick van Rein wrote: > Hello Si?n, > > We're going to automate DS-uploads; as usual we'll be quite public > about how this can be done. But I have a question, because we're > assuming 2.0-ish behaviour that we'd like to patch into 1.x. We > don't know the Enforcer completely, so here are some questions. > > 1. Are there no exceptions to this KSK maturation path? > Generate -> publish DNSKEY -> Ready -> publish DS -> Active As Matthijs has pointed out, not in the current enforcer code (apart from standby KSKs). > 2. Is it possible to set a future time in the "ready" column of > dnsseckeys? If we do that, will the key automatically go to the > ready state at some time after that setting, and pickup on further > actions? This is not currently possible as the transition times are recalculated whenever the enforcer runs. One exception is the retire time of a key that was imported... I only mention this to say that there is a (partial) implementation of this which could be extended if it is really needed. It is not a small amount of work though, mostly because of the testing that would be needed. > > We'd prefer not to rely on some magic value of PropagationDelay, but > wish to actually check until the authoritatives pickup on a new DNSKEY > set, and if it does, report that back to the Enforcer; when that > happens, we would want it to wait for TTL(DNSKEY) + PublishSafety > before we would be hinted to publish the DS to the parent. This > wait could be done by setting the "ready" timestamp to the current > time plus the wait time. > > This enables elegant / simple scripting outside the Enforcer, > mostly limited to the details of the local setup, and leave all > the timing complexity and generic issues inside the Enforcer. > And, it'd be "2.0 ready" scripting, so people can easily upgrade. I have thought about this from time to time... "Why guess at the zone propagation when we can actually look for it". My idea was along the lines of "set the propagation delay to zero and ignore the log message indicating that the ds-seen should be issued until we know that it should be from observation". This is possible now, but not nice as you need to deliberately ignore log messages. > If you think this makes no sense then please let us know :) > > I think that a nice, properly integrated, solution is too much work to make the 1.4 release; and so would probably need to wait for the enforcer-ng. If it is really needed for the 1.4 code then we could look at scheduling it for 1.4.X. Hmm, maybe I should have written this on jira rather than email? Oh well. Sion