From berry at nlnetlabs.nl Thu Jul 7 06:14:03 2016 From: berry at nlnetlabs.nl (Berry A.W. van Halderen) Date: Thu, 7 Jul 2016 08:14:03 +0200 Subject: [Opendnssec-maintainers] OpenDNSSEC 2.0.0 released Message-ID: <577DF32B.3030308@nlnetlabs.nl> Dear OpenDNSSEC community, It gives us pleasure to announce the release of OpenDNSSEC 2.0 Download it here: * https://dist.opendnssec.org/source/opendnssec-2.0.0.tar.gz * https://dist.opendnssec.org/source/opendnssec-2.0.0.tar.gz.sig * Checksum SHA256: 3f3087ee1f2dee8b55d823d4b6825dc0212ea5162965382df11b2de36b888b7f OpenDNSSEC got a entire re-write of the enforcer. This part of OpenDNSSEC controls changing signing keys in the right way to perform a roll-over. Before, the enforcer would perform a roll-over according to a strict paradigm. One scenario in which deviations would not be possible. The new enforcer is more aware of the zone changes being propagated in the Internet. It can therefor decide when it is safe to make changes, rather than to rely upon a given scenario. This makes it possible now for OpenDNSSEC to: - Allow changing your TTL values and all other related parameters in your key and signing policy (KASP). OpenDNSSEC will know which outdated records may still be on the Internet due to their TTL and only roll when it is safe. - It is possible to safely roll to an unsigned situation, without going bogus. - Perform a roll-over procedure at any time, even if a roll-over procedure is still in progress, this way you can abort a roll-over and perform emergency roll-overs. - Perform a roll-over to a different signing algorithm. DNSSEC requires the algorithm number of ZSK and KSK to be the same, so a roll-over to a different algorithm requires a different sequence. - Since there is no longer a single scenario, it will become possible to perform other roll-over methods, like a double DS roll-over or a double RRSIG roll-over. These features keep your zone valid even in situations where changing parameters could trap you into a bogus situation. OpenDNSSEC chooses the fastest safe steps to keep (or even heal) your zone. Other features have also been realized in this rewrite: - Shared keys, allowing multiple zones to share the most recent signing key for that policy. Useful when having many zones, and a limited storage in your HSM. - Combined keys, allow KSK and ZSK to be the same key, also limiting the usage of keys, but also simplify key usage. - Also allow zones to pass unsigned. This allows for a chain of software packages where both signed and unsigned zones can follow the same steps in your chain, simplifying the set-up. - And the enforcer no longer requires to be run periodically, but runs as a proper daemon which wakes up at the proper time. - Allow for multiple HSMs, also allowing you to roll to roll your zone from keys in one HSM to another. Or to store KSK and ZSK separately. - This could even be used in set-ups where the key set is signed separately from your zone. - And the enforcer daemon can now be queried and given commands using command line channel. Administratively, there has also been a major change. NLnet Labs has adopted the full development of OpenDNSSEC, where previously it was one of the partners in the project. This ensures a future-safe continued development of OpenDNSSEC. In this respect we will see more features enhancements in quicker release cycles soon. Some heads-up when trying it out after being used to 1.4: - Scripted migration from 1.4 to 2.0 is available, see MIGRATION file; - Use command ods-enforcer-db-setup rather than "ods-ksmutil setup"; - Any other use of ods-ksmutil is replaced with the ods-enforcer command, which at the moment requires the enforcer daemon to be running; - Use ods-enforcer zone add and delete rather than modifying the zonelist.xml file yourself. This file is not kept up-to-date automatically anymore; - to start using OpenDNSSEC, use ods-enforcer policy import instead of update kasp to update your policies; - Getting started at: https://wiki.opendnssec.org/display/DOCS20/Quick+start+guide With kind regards, The OpenDNSSEC Team. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From berry at nlnetlabs.nl Mon Jul 11 13:54:12 2016 From: berry at nlnetlabs.nl (Berry A.W. van Halderen) Date: Mon, 11 Jul 2016 15:54:12 +0200 Subject: [Opendnssec-maintainers] End-of-life OpenDNSSEC 1.3 on 2017-07-11 Message-ID: <5783A504.9000609@nlnetlabs.nl> Dear community. With the release of OpenDNSSEC 2.0 we have reached the point to let go of the support of one of the older, not to say elderly, OpenDNSSEC. We will end the support on OpenDNSSEC 1.3 in accordance with our policy in one year from now. This historic release has long been replaced by most of not all so we regard this notice to be mostly a formal message for most of you. OpenDNSSEC 1.4 has been the de-facto Long Term Support version, and will continue to be the official LTS version. This at least for over a year and until OpenDNSSEC 2.x has matured. This will be the case as soon as it has been around long enough to prove itself. Please note however that we will concentrate our development on the 2.x versions. Features and improvements that are not considered bugs are mostly targeted at that steam of development. We believe OpenDNSSEC 2.0 is already stable to be used. With kind regards, The OpenDNSSEC team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From yuri at nlnetlabs.nl Fri Jul 15 20:29:18 2016 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Fri, 15 Jul 2016 22:29:18 +0200 Subject: [Opendnssec-maintainers] OpenDNSSEC 2.0.0-1 released Message-ID: <5ee6a85c-ebd7-ade5-e756-b6de3897478c@nlnetlabs.nl> Dear community, It came to our attention that the 2.0.0 lacked some scripts essential for migration from 1.4.10. These where available in the original source but due to oversight not included in the release tarball. We included these scripts in 2.0.0-1. There where no code changes whatsoever. * https://dist.opendnssec.org/source/opendnssec-2.0.0-1.tar.gz * https://dist.opendnssec.org/source/opendnssec-2.0.0-1.tar.gz.sig * Checksum SHA256: 37030cec8cb8e2ae8873914f3759fb51808cefaaaa74d1d729e5bb824b01abbb Kind regards, Yuri Schaeffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From pwouters at redhat.com Tue Jul 19 15:17:33 2016 From: pwouters at redhat.com (Paul Wouters) Date: Tue, 19 Jul 2016 17:17:33 +0200 Subject: [Opendnssec-maintainers] OpenDNSSEC 2.0.0-1 released In-Reply-To: <5ee6a85c-ebd7-ade5-e756-b6de3897478c@nlnetlabs.nl> References: <5ee6a85c-ebd7-ade5-e756-b6de3897478c@nlnetlabs.nl> Message-ID: <9834e4dd-cfa6-07e1-c678-fa89c378b9ee@redhat.com> On 07/15/2016 10:29 PM, Yuri Schaeffer wrote: > Dear community, > > It came to our attention that the 2.0.0 lacked some scripts essential for migration from 1.4.10. These where available in the original source but due to > oversight not included in the release tarball. We included these scripts in 2.0.0-1. There where no code changes whatsoever. > > * https://dist.opendnssec.org/source/opendnssec-2.0.0-1.tar.gz * https://dist.opendnssec.org/source/opendnssec-2.0.0-1.tar.gz.sig * Checksum SHA256: > 37030cec8cb8e2ae8873914f3759fb51808cefaaaa74d1d729e5bb824b01abbb using a "-" in a version number upstream is _really_ problematic for us. I am going to ignore that version number and will hope it will never happen again :) For RHEL we do not need to migrate from 1.4.x. For fedora we do and I believe we used scripts for that already, so I'm not entirely sure what was missing? Paul From yuri at nlnetlabs.nl Tue Jul 19 16:52:34 2016 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Tue, 19 Jul 2016 18:52:34 +0200 Subject: [Opendnssec-maintainers] OpenDNSSEC 2.0.0-1 released In-Reply-To: <9834e4dd-cfa6-07e1-c678-fa89c378b9ee@redhat.com> References: <5ee6a85c-ebd7-ade5-e756-b6de3897478c@nlnetlabs.nl> <9834e4dd-cfa6-07e1-c678-fa89c378b9ee@redhat.com> Message-ID: Hi Paul, On 19-07-16 17:17, Paul Wouters wrote: > using a "-" in a version number upstream is _really_ problematic for us. > > I am going to ignore that version number and will hope it will never happen again :) Yeah, I already received a slap on the wrist for that. There are some issues with the migration path though. So depending on the outcome of some tests currently running, I will make a proper 2.0.1 release somewhere between today and Thursday inclusive. > For RHEL we do not need to migrate from 1.4.x. For fedora we do and I believe we > used scripts for that already, so I'm not entirely sure what was missing? The enforcer was completely rewritten between 1.4 and 2.0. This included the database format. But since the two version work very different internally the conversion as a bit complicated. There is an extensive conversion script which in turn calls the database creation script. Though the latter wasn't included in the released tarball. //Yuri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From yuri at nlnetlabs.nl Thu Jul 21 15:02:30 2016 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Thu, 21 Jul 2016 17:02:30 +0200 Subject: [Opendnssec-maintainers] OpenDNSSEC 2.0.1 released Message-ID: <9eaa68f6-99c6-cbe8-6c87-42b6946859c0@nlnetlabs.nl> Dear community, Hereby we announce the OpenDNSSEC 2.0.1 release. This release is primarily focused on ironing out the issues on the migration path from 1.4 to 2.0. Besides that there are no functional changes. Changes: * Fixed crash and linking issue in ods-migrate. * Fixed case where 2.0.0 could not read backup files from 1.4.10. * Fixed bug in migration script where key state in the database wasn't transformed properly. Download: * https://dist.opendnssec.org/source/opendnssec-2.0.1.tar.gz * https://dist.opendnssec.org/source/opendnssec-2.0.1.tar.gz.sig * Checksum SHA256: bf874bbb346699a5b539699f90a54e0c15fff0574df7a3c118abb30938b7b346 Kind regards, The OpenDNSSEC team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From ondrej at sury.org Tue Jul 26 07:11:38 2016 From: ondrej at sury.org (=?UTF-8?Q?Ond=C5=99ej=20Sur=C3=BD?=) Date: Tue, 26 Jul 2016 09:11:38 +0200 Subject: [Opendnssec-maintainers] tar.xz in the future (Re: OpenDNSSEC 2.0.1 released) In-Reply-To: <9eaa68f6-99c6-cbe8-6c87-42b6946859c0@nlnetlabs.nl> References: <9eaa68f6-99c6-cbe8-6c87-42b6946859c0@nlnetlabs.nl> Message-ID: <1469517098.2501144.676867273.000F4C50@webmail.messagingengine.com> Hi Yury, could NLnet Labs start using xz compression for release tarballs in addition to .gz, please? That applies to all NLnet Labs releases, not just OpenDNSSEC. Thanks. Cheers, -- Ond?ej Sur? Knot DNS (https://www.knot-dns.cz/) ? a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) ? secure, privacy-aware, fast DNS(SEC) resolver V?e pro chleba (https://vseprochleba.cz) ? Pot?eby pro pe?en? chleba v?eho druhu On Thu, Jul 21, 2016, at 17:02, Yuri Schaeffer wrote: > Dear community, > > Hereby we announce the OpenDNSSEC 2.0.1 release. This release is > primarily focused on ironing out the issues on the migration path from > 1.4 to 2.0. Besides that there are no functional changes. > > Changes: > > * Fixed crash and linking issue in ods-migrate. > * Fixed case where 2.0.0 could not read backup files from 1.4.10. > * Fixed bug in migration script where key state in the database wasn't > transformed properly. > > Download: > * https://dist.opendnssec.org/source/opendnssec-2.0.1.tar.gz > * https://dist.opendnssec.org/source/opendnssec-2.0.1.tar.gz.sig > * Checksum SHA256: > bf874bbb346699a5b539699f90a54e0c15fff0574df7a3c118abb30938b7b346 > > Kind regards, > The OpenDNSSEC team > > > > _______________________________________________ > Opendnssec-maintainers mailing list > Opendnssec-maintainers at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-maintainers > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) From ondrej at sury.org Tue Jul 26 07:28:08 2016 From: ondrej at sury.org (=?UTF-8?Q?Ond=C5=99ej=20Sur=C3=BD?=) Date: Tue, 26 Jul 2016 09:28:08 +0200 Subject: [Opendnssec-maintainers] Debian - migration path from 1.4.6 to 2.0.x needed and more general remark on OpenDNSSEC database upgrades Message-ID: <1469518088.2503717.676869945.083F9D71@webmail.messagingengine.com> Heya, the stable Debian currently has OpenDNSSEC 1.4.6 and that's not going to change (due to stable release policy). Therefore to upgrade OpenDNSSEC to 2.0.x in next Debian stable release I need a stable path from OpenDNSSEC 1.4.6 to 2.0.x. The only database change I found between 1.4.6 and 1.4.10 (the recommended version) is migrate_1_4_8.{mysql,sqlite3} scripts. As a side note I really think the need for user to run the script is very inconvenient and OpenDNSSEC should keep this hidden from user, performing the database upgrades on first start when it detects the old version of the database schema. Or at least provide a utility that gives the users (and package maintainers) an unified way how to upgrade the database schema by parsing the current configuration and applying the updates to the configured database. Providing a _raw_ SQL scripts or utilities that needs manual configuration (which is almost the same as the raw SQL scripts) is a sure path to botch something. Cheers, -- Ond?ej Sur? Knot DNS (https://www.knot-dns.cz/) ? a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) ? secure, privacy-aware, fast DNS(SEC) resolver V?e pro chleba (https://vseprochleba.cz) ? Pot?eby pro pe?en? chleba v?eho druhu From pwouters at redhat.com Tue Jul 26 08:01:55 2016 From: pwouters at redhat.com (Paul Wouters) Date: Tue, 26 Jul 2016 10:01:55 +0200 Subject: [Opendnssec-maintainers] Debian - migration path from 1.4.6 to 2.0.x needed and more general remark on OpenDNSSEC database upgrades In-Reply-To: <1469518088.2503717.676869945.083F9D71@webmail.messagingengine.com> References: <1469518088.2503717.676869945.083F9D71@webmail.messagingengine.com> Message-ID: On 07/26/2016 09:28 AM, Ond?ej Sur? wrote: > As a side note I really think the need for user to run the script is > very inconvenient and OpenDNSSEC should keep this hidden from user, > performing the database upgrades on first start when it detects the old > version of the database schema. > > Or at least provide a utility that gives the users (and package > maintainers) an unified way how to upgrade the database schema by > parsing the current configuration and applying the updates to the > configured database. I agree. In fedora/rhel policy we cannot ship this sql in the "documentation" when the runtime depends on it, so we have to find some odd directory to store these files in. Paul From jaap at NLnetLabs.nl Tue Jul 26 08:11:12 2016 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 26 Jul 2016 10:11:12 +0200 Subject: [Opendnssec-maintainers] Debian - migration path from 1.4.6 to 2.0.x needed and more general remark on OpenDNSSEC database upgrades In-Reply-To: References: <1469518088.2503717.676869945.083F9D71@webmail.messagingengine.com> Message-ID: <201607260811.u6Q8BCMq072252@bela.nlnetlabs.nl> Paul Wouters writes: > On 07/26/2016 09:28 AM, Ond?ej Sur? wrote: > > > As a side note I really think the need for user to run the script is > > very inconvenient and OpenDNSSEC should keep this hidden from user, > > performing the database upgrades on first start when it detects the old > > version of the database schema. > > > > Or at least provide a utility that gives the users (and package > > maintainers) an unified way how to upgrade the database schema by > > parsing the current configuration and applying the updates to the > > configured database. > > I agree. In fedora/rhel policy we cannot ship this sql in the "documentation" > when the runtime depends on it, so we have to find some odd directory to > store these files in. As far as I know (but I'm not actively involved in this effort), this is already on the "to implemented list". jaap