From owner-dnssec-trac at kirei.se Mon Mar 1 07:17:17 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Mar 2010 07:17:17 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #100: Certificate support + C_Encrypt and C_Decrypt support In-Reply-To: <063.7e7e24c70d6d211c49a31709f23add49@kirei.se> References: <063.7e7e24c70d6d211c49a31709f23add49@kirei.se> Message-ID: <072.472e1e923a39c35a547e9c51189f3b0a@kirei.se> #100: Certificate support + C_Encrypt and C_Decrypt support --------------------------------------+------------------------------------- Reporter: calderon.thomas@? | Owner: rb Type: enhancement | Status: accepted Priority: major | Component: SoftHSM Version: trunk | Keywords: Certificate, C_Encrypt, C_Decrypt --------------------------------------+------------------------------------- Comment(by rb): Thanks for your patch, but we will focus on the development of SoftHSM version 2. It will get certificate support and we are aiming to have a version to test with by late May. The ticket can remain open for others that want certificate support in version 1. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon Mar 1 07:54:46 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 1 Mar 2010 08:54:46 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.0.1 In-Reply-To: <0A2AE627-4878-4406-A096-208D6F691403@kirei.se> References: <7809D36C-4825-4B35-94A5-7E7A75209057@iis.se> <0A2AE627-4878-4406-A096-208D6F691403@kirei.se> Message-ID: <6BDC2369-BE63-4EEB-AC17-5C275C404BD5@iis.se> On 28 feb 2010, at 19.13, Jakob Schlyter wrote: > while moving all common variables to OPENDNSSEC_COMMON, I've discovered the following errors. I suggest we commit this to the 1.0 branch: This means that the zone_fetcher cannot notify the signer and that the startup script for solaris is broken. We should also include: r2859: Broken handling of standby keys r2862: Turn OptOut off by default But how about all the prefix, sbin, bin, etc stuff in the configures? // Rickard From jakob at kirei.se Mon Mar 1 07:58:50 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 1 Mar 2010 08:58:50 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.0.1 In-Reply-To: <6BDC2369-BE63-4EEB-AC17-5C275C404BD5@iis.se> References: <7809D36C-4825-4B35-94A5-7E7A75209057@iis.se> <0A2AE627-4878-4406-A096-208D6F691403@kirei.se> <6BDC2369-BE63-4EEB-AC17-5C275C404BD5@iis.se> Message-ID: <73E90756-8DF3-4D6B-A408-439542359A98@kirei.se> On 1 mar 2010, at 08.54, Rickard Bellgrim wrote: > We should also include: > r2859: Broken handling of standby keys > r2862: Turn OptOut off by default yes, please apply this (in separate commits). jakob From owner-dnssec-trac at kirei.se Mon Mar 1 09:26:43 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Mar 2010 09:26:43 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #107: ksmutil doesn't list pre-generated keys Message-ID: <060.7a77dbdef3e4007d67bb35417cd718bf@kirei.se> #107: ksmutil doesn't list pre-generated keys -----------------------------------+---------------------------------------- Reporter: antti.ristimaki@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: -----------------------------------+---------------------------------------- Running "ods-ksmutil key list" doesn't list the pre-generated keys. The enforcer does seem to use the pre-generated keys to roll keys, though. With "ods-hsmutil list" the generated keys can be listed. Antti -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Mon Mar 1 09:51:18 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 1 Mar 2010 10:51:18 +0100 Subject: [Opendnssec-develop] KSK rollover In-Reply-To: References: Message-ID: <08FBC091-BB96-4C18-A554-00CACD5895C3@kirei.se> On 25 feb 2010, at 12.03, sion at nominet.org.uk wrote: > One further complication... Should we allow different DS_PUBLISHED and > DS_READY times for different zones sharing keys? Currently all times are > stored against the key, rather than the zones instance of a key. (I.e. in > the keypairs table, not the dnsseckeys table for those familiar with the > kasp schema.) I'd expect all timings to be per zone, not per key. if multiple zones are sharing a key they should only share the keypair itself, not any timing parameters associated with a key. so I want to be able to roll a key for one zone in a set of zones sharing keys, but not all of them. but when all of them has rolled key, the key has a "reference count" of 0 and can be released. jakob From jakob at kirei.se Mon Mar 1 10:16:40 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 1 Mar 2010 11:16:40 +0100 Subject: [Opendnssec-develop] EPP-client and libcurl dependency Message-ID: just fyi, the epp client apparently will depend on libcurl for certificate validation. not a problem for me, but we should keep it in mind. jakob From owner-dnssec-trac at kirei.se Mon Mar 1 11:20:28 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Mar 2010 11:20:28 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #107: ksmutil doesn't list pre-generated keys In-Reply-To: <060.7a77dbdef3e4007d67bb35417cd718bf@kirei.se> References: <060.7a77dbdef3e4007d67bb35417cd718bf@kirei.se> Message-ID: <069.81c13112adf0414f9544c5ce2e60b0f5@kirei.se> #107: ksmutil doesn't list pre-generated keys -----------------------------------+---------------------------------------- Reporter: antti.ristimaki@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: -----------------------------------+---------------------------------------- Comment(by St?phane Bortzmeyer ): It seems a duplicate of #97. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 1 11:21:41 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Mar 2010 11:21:41 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #107: ksmutil doesn't list pre-generated keys In-Reply-To: <060.7a77dbdef3e4007d67bb35417cd718bf@kirei.se> References: <060.7a77dbdef3e4007d67bb35417cd718bf@kirei.se> Message-ID: <069.1dbb9a15dacfb37f5f5811c117b3613a@kirei.se> #107: ksmutil doesn't list pre-generated keys -----------------------------------+---------------------------------------- Reporter: antti.ristimaki@? | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: duplicate Keywords: | -----------------------------------+---------------------------------------- Changes (by jakob): * status: new => closed * resolution: => duplicate -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick.zijlker at sidn.nl Mon Mar 1 11:52:51 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Mon, 1 Mar 2010 12:52:51 +0100 Subject: [Opendnssec-develop] Fail to setup database Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86E2@KAEVS1.SIDN.local> Hey guys, Just checked out latest SVN and after installing when I run "ods-ksmutil setup" I get the following message: *WARNING* This will erase all data in the database; are you sure? [y/N] y SQLite database set to: /var/opendnssec/kasp.db sh: /database_create.sqlite3: No such file or directory Could not call db setup command: /usr/local/bin/sqlite3 /var/opendnssec/kasp.db < /database_create.sqlite3 A previous SVN checkout worked fine. It seems as if ODS is searching for a database script in the wrong place. Am I right? How can I fix this? Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Mon Mar 1 12:07:25 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 1 Mar 2010 13:07:25 +0100 Subject: [Opendnssec-develop] Fail to setup database In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86E2@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949014D86E2@KAEVS1.SIDN.local> Message-ID: <79FE5B66-9901-46F8-B3F9-54EF631FC449@iis.se> On 1 mar 2010, at 12.52, Rick Zijlker wrote: A previous SVN checkout worked fine. It seems as if ODS is searching for a database script in the wrong place. Am I right? How can I fix this? Does this work? Index: enforcer/configure.ac =================================================================== --- enforcer/configure.ac (revision 2910) +++ enforcer/configure.ac (working copy) @@ -144,7 +144,7 @@ DB_LIBS=$MYSQL_LIBS AC_DEFINE_UNQUOTED(SQL_BIN, "$MYSQL", [database binary]) - AC_DEFINE_UNQUOTED(SQL_SETUP, "$opendnssecdatadir/database_create.mysql", [database setup script]) + AC_DEFINE_UNQUOTED(SQL_SETUP, "$OPENDNSSEC_DATA_DIR/database_create.mysql", [database setup script]) AC_SUBST(DB_TYPE) AC_SUBST(DB_INCLUDES) @@ -160,7 +160,7 @@ DB_LIBS=$SQLITE3_LIBS AC_DEFINE_UNQUOTED(SQL_BIN, "$SQLITE3", [database binary]) - AC_DEFINE_UNQUOTED(SQL_SETUP, "$opendnssecdatadir/database_create.sqlite3", [database setup script]) + AC_DEFINE_UNQUOTED(SQL_SETUP, "$OPENDNSSEC_DATA_DIR/database_create.sqlite3", [database setup script]) AC_SUBST(DB_TYPE) AC_SUBST(DB_INCLUDES) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick.zijlker at sidn.nl Mon Mar 1 12:25:29 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Mon, 1 Mar 2010 13:25:29 +0100 Subject: [Opendnssec-develop] Fail to setup database References: <850A39016FA57A4887C0AA3C8085F949014D86E2@KAEVS1.SIDN.local> <79FE5B66-9901-46F8-B3F9-54EF631FC449@iis.se> Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86E3@KAEVS1.SIDN.local> Thanks! It works now. Cheers From: Rickard Bellgrim [mailto:rickard.bellgrim at iis.se] Sent: maandag 1 maart 2010 13:07 To: Rick Zijlker Cc: Opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] Fail to setup database On 1 mar 2010, at 12.52, Rick Zijlker wrote: A previous SVN checkout worked fine. It seems as if ODS is searching for a database script in the wrong place. Am I right? How can I fix this? Does this work? Index: enforcer/configure.ac =================================================================== --- enforcer/configure.ac (revision 2910) +++ enforcer/configure.ac (working copy) @@ -144,7 +144,7 @@ DB_LIBS=$MYSQL_LIBS AC_DEFINE_UNQUOTED(SQL_BIN, "$MYSQL", [database binary]) - AC_DEFINE_UNQUOTED(SQL_SETUP, "$opendnssecdatadir/database_create.mysql", [database setup script]) + AC_DEFINE_UNQUOTED(SQL_SETUP, "$OPENDNSSEC_DATA_DIR/database_create.mysql", [database setup script]) AC_SUBST(DB_TYPE) AC_SUBST(DB_INCLUDES) @@ -160,7 +160,7 @@ DB_LIBS=$SQLITE3_LIBS AC_DEFINE_UNQUOTED(SQL_BIN, "$SQLITE3", [database binary]) - AC_DEFINE_UNQUOTED(SQL_SETUP, "$opendnssecdatadir/database_create.sqlite3", [database setup script]) + AC_DEFINE_UNQUOTED(SQL_SETUP, "$OPENDNSSEC_DATA_DIR/database_create.sqlite3", [database setup script]) AC_SUBST(DB_TYPE) AC_SUBST(DB_INCLUDES) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Mon Mar 1 18:49:05 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 1 Mar 2010 19:49:05 +0100 Subject: [Opendnssec-develop] (GOST support) Fwd: [Botan-devel] State of 1.9 Message-ID: <734E9D3C-67F7-4ECE-BFD7-60D8248B9827@iis.se> FYI Vidarebefordrat brev: Fr?n: Jack Lloyd <lloyd at randombit.net> Datum: 1 mars 2010 18.27.35 CET Till: botan dev list <botan-devel at randombit.net> ?mne: [Botan-devel] State of 1.9 Svara till: Botan development list <botan-devel at randombit.net> A quick update on the status of the 1.9 tree. I've merged Ajisai's SSL/TLS implementation into mainline. Currently it relies on a Socket wrapper class (an implementation exists for BSD sockets), which the SSL code interacts with in a blocking manner. In the long view (before 1.10.0), this will change to be event-driven so there are no socket dependencies in the library proper, and so applications can use whatever interprocess method they prefer (BSD sockets, asio, Winsock, libevent, etc). The code is very alpha still, and I know there is a least one bug that causes crashes in the server-side handshake in the current code. I would encourage anyone who is interested to consider hacking on this stuff, there are a number of useful features (including TLS 1.1 and 1.2, TLS extensions, reading SSLv2 client hellos, etc, etc) that could be very nice to have. I've added the GOST 34.10-2001 signature scheme at the request of the OpenDNSSEC/SoftHSM developers, because GOST is in the process of being added to DNSSEC and apparently will be required for use by the Russian security agencies. SIMD optimizations continue with implementations of IDEA (SSE2 only) and Noekeon (SSE2 or Altivec), and now XTS mode and CBC (decryption only; CBC encryption of a single stream requires iterative operation) will process data using SIMD where possible. So using a SIMD-enabled cipher with these modes offers substantial performance improvements. This will also be useful with AES for those with processors that included AES-NI since the AES-NI code in botan does 4 blocks in parallel to hide instruction latencies as recommended by Intel. The ECC code has been substantially modified, in particular removing the use of shared_ptr, because it was causing strange crashes with certain GCC versions on certain processors (for instance on x86-32 but not x86-64 with the primary GCC version I use on my machine) that I was unable to diagnose or understand, even with valgrind's help. On the plus side this change means ECDSA will be available for Windows developers as well. Part of this refactoring included removing many of the Montgomery optimizations that had been included, so currently ECC is substantially slower than it is in 1.8 (and it is not particularly fast there either). My goal with ECC is for ECDSA to be at least 1/2 the speed of OpenSSL's ECDSA by 1.10.0 - since it currently is between 20 and 100 times slower, there is some rather major room for improvement there. A block cipher cascade is now available - for instance "Cascade(Serpent,CAST-128)" is a 128-bit block cipher that encrypts first with Serpent and then with CAST-128 (since CAST-128 is a 64-bit cipher the two halves of the Serpent output are encrypted seperately). Probably more useful is something like "Cascade(Serpent,AES-256)" or (for the uber-paranoid who don't much care about performance) "Cascade(Serpent,Twofish,MARS,RC6,AES-256)". I should add an alias for that last one so it can be called as "AES_Quinfecta". A password hashing scheme (for user authentication, ala crypt(3) or bcrypt) is available. It is a custom scheme based on PBKDF2 called passhash9. I plan on documenting this scheme and providing implementations in C, Python, etc once I have the time (interoperating C and Python implementations are written already but writeup is not). The S2K interface has changed. Instead of the current API where the salt, iteration counts, etc are set with individual calls, followed by derive_key() taking just the passphrase, all arguments are passed to derive_key. This is simpler and easier to deal with in 99% of the use cases I've encountered. Passing --gen-amalgamation to configure.py will create two files, botan_all.cpp and botan_all.h, which can be included in third party projects that don't want to depend on an external library. Just compile the .cpp file into your app and use botan_all.h wherever you included any botan header. The assembly code and a few of the SIMD modules are not available in the amalgamation, but everything else is. The amalgamation only includes configured options so you can create a minimal amalgamation using --no-autoload --enable-modules= Things currently holding up the release: - You still can't create static libraries on VC++. --disable-shared is ignored. Lots of requests for this. - Fixing the SSL handshake crash. Be kind of embarassing to announce adding SSL to the release when servers don't work at all. Things that would be nice to have before 1.9.4: - Adding Montgomery optimizations back to ECC. Clearly using Barrett reduction for this is not going to cut it, performance-wise. - Adding ECDH/ECDSA ciphersuites to the SSL implementation. Maybe even the NSA Suite B CBC suites? (RFC 5430). -Jack _______________________________________________ botan-devel mailing list botan-devel at randombit.net http://lists.randombit.net/mailman/listinfo/botan-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Mar 2 10:34:39 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 2 Mar 2010 11:34:39 +0100 Subject: [Opendnssec-develop] Meeting during IETF in Anaheim In-Reply-To: <4E9171EA-CE1E-40A6-8FC7-F183EC233E6A@iis.se> References: <4E9171EA-CE1E-40A6-8FC7-F183EC233E6A@iis.se> Message-ID: <9C7CC46D-FDB4-490E-907E-036E2BA3226D@iis.se> I suggest that we have an OpenDNSSEC meeting after the dnsext meeting on Tue March 23. Between 15:20 and 17:20. // Rickard On 26 feb 2010, at 09.18, Rickard Bellgrim wrote: > Hi > > We should try to schedule a meeting during the IETF in Anaheim. Please fill in the doodle: > > http://www.doodle.com/yvnnqwzek2wegsxa > > Thanks > // Rickard_______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From rick.zijlker at sidn.nl Tue Mar 2 13:56:23 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Tue, 2 Mar 2010 14:56:23 +0100 Subject: [Opendnssec-develop] RRSIG's mixed up Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86E6@KAEVS1.SIDN.local> Hey guys, We signed a fresh unsigned nl-zone (NSEC3 optout) with 10% DS records in zone and see difference between RRSIG records. I cleaned everything before signing. Empty /tmp and /signed directories, updated configs and restarted engines. At first few domains we see them as expected: test.nl. 7200 IN NS ns1.sidn.nl. test.nl. 7200 IN NS ns2.sidn.nl. test.nl. 7200 IN NS ns3.sidn.nl. test.nl. 7200 IN DS 22922 7 1 f62411de95a5b7bcabe976c0e65034a35a9fa937 ; xutid-gygat-vihop-hutur-sypiv-natos-binah-bytyp-fekyn-zypof-lyxix test.nl. 7200 IN RRSIG DS 7 2 7200 20100309181443 20100302104953 19763 nl. WX6fOSxaHgrb0mjzcBdQ6uK5bfAwYhBCQrZoB+he7O44fnXIovZrYgFb/yC92UN+J90MShRE 93fHlOcgQKnfeyVqv3Inde7NkG5tNiOPvpd4vhGyplQXg0FwhPuvc4nm5YN8EXuFLNNJiYo2 w67kKrcS9O3060IPxBNU6HLIhK0= ;{id = 19763} 000aui1rb6m0jg9ossds01v4esqlrhhg.nl. 3600 IN NSEC3 1 1 5 95c66b1754a40aea 000d8j29h5rgect8v386ctgmntsl4cse NS DS RRSIG ; flags: optout 000aui1rb6m0jg9ossds01v4esqlrhhg.nl. 3600 IN RRSIG NSEC3 7 2 3600 20100309152412 20100302104953 19763 nl. Ej2fatgOImaUGkNYgUMpi3NqIerlqTG1QaRp0T93DSWdM/QMbGIp+lHzRIYWkvtGx/TmhOEJ 0ZDEUjoh1XmQcqJVmIQWzqqQfpyNo4vC8/szkM4uJfxJi+xzBGDDsfTZqMPMkrFFiTrT3C50 CZDNgPjWp49tWaILwE6cLfozE0c= ;{id = 19763} A few domains later it looks like the RRSIG records are incomplete: test2.nl. 7200 IN NS ns3.sidn.nl. test2.nl. 7200 IN NS ns4.sidn.nl. test2.nl. 7200 IN DS 22922 7 1 f62411de95a5b7bcabe976c0e65034a35a9fa937 ; xutid-gygat-vihop-hutur-sypiv-natos-binah-bytyp-fekyn-zypof-lyxix BAmqHGpeiWfEVeWmn/RRKCvQSyD0YAlVXwyxdSUKDWUG2x9AXY5ZNhNoj7KUdjYEgjRsUFQ= ;{id = 19763} 000ffl0k09ookdoophflkd44d7i7v99k.nl. 3600 IN NSEC3 1 1 5 95c66b1754a40aea 000fqll6rdl9ihdj318hrbc95q4putdk NS DS RRSIG ; flags: optout CPB1Ubiw4FpfufE2zuAaa/r6w+uLALMuwsqUasNRCdORvGHwEzR0VfcrLaw8YOv6op/8c4KK pyi28JbCp0= ;{id = 19763} It seems as if there is an incomplete hash instead of RRSIG record. Later there are complete RRSIG records again. Another question, what exactly is the meaning of the "xutid-gygat-vihop...." String in the DS record? I can't find anything in the RFC's explaining this added comment. Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Tue Mar 2 14:08:15 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 02 Mar 2010 15:08:15 +0100 Subject: [Opendnssec-develop] RRSIG's mixed up In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86E6@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949014D86E6@KAEVS1.SIDN.local> Message-ID: <4B8D1BCF.5090907@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rick, I don't understand why it suddenly prints half RRSIG records. Please provide unsigned zonefile and signer configuration for me to investigate. Rick Zijlker wrote: > Another question, what exactly is the meaning of the > ?xutid-gygat-vihop?.? String in the DS record? I can?t find anything in > the RFC?s explaining this added comment. That's bubble babble, makes the DS more easy to pronounce. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLjRvNAAoJEA8yVCPsQCW5n9UH/2IG3dCS6e9Of+kOXZoVEX0w sWAbp5U649tK4b4KnagFQsKjb9zK/GZQ9xEg0NUDsUlwfn10wkTYWyj9fp40Hrgp ze+cx6idMcboHdkF6/k/5tsnKIvbaaI1LIV4Q0fy8HZ3g0mZE+STtfkFEtlF33HC 0HzIOekDDIT/+P/A4BEoO8QsJ6+XBgZLm7njpsekq1kzDjj8HYvqxgSyoWQ1ffXJ kNzdO+kQGgbu1BWRU/wls1YzZCBdSLSQET1cNU7xTZ0c07LhB8YLiGPh2hLbnyyH /dkxzJ5ZfaYDVJIS2ruDlEehmJiZR8oMmaTNcuq+uCcdmCqx35E0u97Ro6diqbo= =+cOL -----END PGP SIGNATURE----- From jakob at kirei.se Tue Mar 2 14:17:41 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 2 Mar 2010 15:17:41 +0100 Subject: [Opendnssec-develop] say hello to eppclient Message-ID: <32DF0B23-BA63-429F-9664-040038E88BCA@kirei.se> hi, I've just imported and automagicized the eppclient into trunk/OpenDNSSEC/plugins/eppclient. Bj?rn will continue coding, but it was now time for eppclient to come out from the closet. jakob From roy at nominet.org.uk Tue Mar 2 16:53:22 2010 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 2 Mar 2010 10:53:22 -0600 Subject: [Opendnssec-develop] RRSIG's mixed up In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86E6@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949014D86E6@KAEVS1.SIDN.local> Message-ID: Rick Zijlker wrote on 03/02/2010 07:56:23 AM: > Another question, what exactly is the meaning of the ?xutid-gygat- > vihop?.? String in the DS record? I can?t find anything in the RFC?s > explaining this added comment. This is bubble babble (http://en.wikipedia.org/wiki/Bubble_Babble ) to allow humans to communicate binary data easily. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick.zijlker at sidn.nl Wed Mar 3 09:33:25 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Wed, 3 Mar 2010 10:33:25 +0100 Subject: [Opendnssec-develop] RRSIG's mixed up - Solved References: <850A39016FA57A4887C0AA3C8085F949014D86E6@KAEVS1.SIDN.local> Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86EB@KAEVS1.SIDN.local> Hey all, I did some more testing this morning. To my surprise I couldn't find any incomplete signatures anymore. Apparently some signatures show up incomplete when using "less" instead of "more". Usually I use "more" combined with "| grep" but to be able to go back and forward in the zone file I used "less" yesterday. I don't understand why "less" would show some of the signatures incomplete though. Maybe because it's starting before the whole file is read, but it's the same incomplete signatures every time and they stay incomplete. Anyhow, the signed zone appears to be fine after all. Just a wise lesson for me. Cheers, Rick From: Roy Arends [mailto:roy at nominet.org.uk] Sent: dinsdag 2 maart 2010 17:53 To: Rick Zijlker Cc: Opendnssec-develop at lists.opendnssec.org; opendnssec-develop-bounces at lists.opendnssec.org Subject: Re: [Opendnssec-develop] RRSIG's mixed up Rick Zijlker wrote on 03/02/2010 07:56:23 AM: > Another question, what exactly is the meaning of the "xutid-gygat- > vihop...." String in the DS record? I can't find anything in the RFC's > explaining this added comment. This is bubble babble (http://en.wikipedia.org/wiki/Bubble_Babble ) to allow humans to communicate binary data easily. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Wed Mar 3 11:19:49 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 3 Mar 2010 11:19:49 +0000 Subject: [Opendnssec-develop] Partial auditor spec and implementation Message-ID: Hi - I've added a spec for the partial auditor here : http://trac.opendnssec.org/wiki/Signer/PartialAuditorRequirements The implementation is now in trunk. To use it, simply add : to the appropriate policy in kasp.xml. You will need the newly released dnsruby-1.44. Please let me know of any issues with either the specification or the implementation. Thanks! Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Wed Mar 3 11:51:09 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 3 Mar 2010 11:51:09 +0000 Subject: [Opendnssec-develop] Any word from Ondrej? Message-ID: <20100303115109.GB14987@phantom.vanrein.org> Hello, Has any of you heard from Ondrej? His packaging work seems to be have suddenly stopped, and he is not responding to direct email. The Debian package repo's only contain RC3 packages for the auditor. I'm surprised by this, as he was so keenly involved. It actually made us choose Debian for our infra, but I'm not so sure about that anymore. Thanks, Rick van Rein for SURFNet.nl From sion at nominet.org.uk Thu Mar 4 10:42:59 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 4 Mar 2010 10:42:59 +0000 Subject: [Opendnssec-develop] DoubleDNSKEY rollover Message-ID: I'm just running tests on DoubleDNSKEY rollovers now. Sorry it's taken a bit longer than I thought, we changed the timings on Friday. (The good news is that we have managed to avoid the extra states for the key so far.) The whole thing now looks like: 1) Pre-publish KSK so that it will enter the ready state before the expected end-of-life of the previous key. 2) When it enters the ready state send the following to the log: Mar 4 10:09:47 sion ods-enforcerd: INFO: Please swap the DS record in the parent of zone sion for the following, #012;KSK DS record (SHA1):#012sion.#0113600#011IN#011DS#01133936 7 1 2df0432924e9d551be1d5cc2b569763822e4bb9a ; xerez-bobad-nunyv-nuhih-cezyc-tylys-ditek-nytif-mimiv-guvun-poxux#012#012;KSK DS record (SHA256):#012sion.#0113600#011IN#011DS#01133936 7 2 e21e207392b2918bf688dcd392fe670f5ad6ea1fe6e14865c089793845792a52 ; xumic-vomyl-figir-digom-rytam-mylet-fygaz-vinub-zukut-kupyc-zoniv-cadyk-hobum-navof-mycol-napih-duxix#012 Mar 4 10:09:47 sion ods-enforcerd: INFO: Once the new DS records are seen in DNS please issue the ds-seen command for zone sion with the following cka_ids, 48e00948d5b67116ee115df7414380e5 (The formatting is a little out; #012 == "\n" and #011 == "\t".) This is where the "DS-SUBMIT" hook will go, when I write it. QUESTION: Is logging with a priority of INFO a good idea? People might not be looking for it. 3) When the "ods-ksmutil key ds-seen" command is sent, move the new key to active, retire the old key and set its dead time (unless a --no-retire flag is used). QUESTION: What should we do differently when the ManualRollover flag is set? Rinse and repeat... I need to test with standby keys and see what happens when we perform unscheduled rollovers. Then DoubleDS should follow quite quickly. Is this looking okay? It conforms (as far as I can tell) to the next draft of the timing paper. Sion From rickard.bellgrim at iis.se Thu Mar 4 12:18:19 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 4 Mar 2010 13:18:19 +0100 Subject: [Opendnssec-develop] DoubleDNSKEY rollover In-Reply-To: References: Message-ID: <1890633A-5E7B-4F10-8570-C12A84EC538B@iis.se> > (The formatting is a little out; #012 == "\n" and #011 == "\t".) > This is where the "DS-SUBMIT" hook will go, when I write it. > > QUESTION: Is logging with a priority of INFO a good idea? People might not > be looking for it. If we have the ds-submit / dnskey-submit hook, then there is no need for this text, right? DNSKEY is a more preferred format, because then you can use that or convert it into a DS. The enforcer should send all the DNSKEYs to the submit hook that it want to publish in the parent zone. > 3) When the "ods-ksmutil key ds-seen" command is sent, move the new key to > active, retire the old key and set its dead time (unless a --no-retire flag > is used). How will the no-retire flag work? An external program does not know which key to retire. It only know which DS that are available in the parent zone. We will be using the same command for the new KSK and the standby KSK. The EPP-client will use the ds-seen once it has successfully synchronized the current set of DS. Then user will then compensate this with setting a higher retire safety. > QUESTION: What should we do differently when the ManualRollover flag is > set? Do we need the ManualRollover for the KSK anymore? It is only useful for the ZSK. KSK-rollover will wait until you give the ds-seen. // Rickard From sion at nominet.org.uk Thu Mar 4 12:37:29 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 4 Mar 2010 12:37:29 +0000 Subject: [Opendnssec-develop] DoubleDNSKEY rollover In-Reply-To: <1890633A-5E7B-4F10-8570-C12A84EC538B@iis.se> References: <1890633A-5E7B-4F10-8570-C12A84EC538B@iis.se> Message-ID: > > (The formatting is a little out; #012 == "\n" and #011 == "\t".) > > This is where the "DS-SUBMIT" hook will go, when I write it. > > > > QUESTION: Is logging with a priority of INFO a good idea? People might not > > be looking for it. > > If we have the ds-submit / dnskey-submit hook, then there is no need > for this text, right? Correct. It would log the command called instead. > DNSKEY is a more preferred format, because then you can use that or > convert it into a DS. The enforcer should send all the DNSKEYs to > the submit hook that it want to publish in the parent zone. Do you prefer DNSKEY in the log message instead of the DS or in addition to? There are obviously a number of replacements that I can make, in the same way as %zone etc. work in the NotifyCommand... I was going to suggest a list when I moved on to that command; but I am thinking along the lines of %dnskey, %ds, %rolloverscheme, %zone. > > 3) When the "ods-ksmutil key ds-seen" command is sent, move the new key to > > active, retire the old key and set its dead time (unless a --no-retire flag > > is used). > > How will the no-retire flag work? An external program does not know > which key to retire. It only know which DS that are available in the > parent zone. We will be using the same command for the new KSK and > the standby KSK. Currently it retires the oldest active key. DS-seen with no-retire will leave multiple keys in the active state. I'm not sure that the standby key should have its DS submitted until we need to roll to it? Its existence really only saves you the time it takes to propagate through the child zone (plus safety margin). > The EPP-client will use the ds-seen once it has successfully > synchronized the current set of DS. Then user will then compensate > this with setting a higher retire safety. > > > QUESTION: What should we do differently when the ManualRollover flag is > > set? > > Do we need the ManualRollover for the KSK anymore? It is only useful > for the ZSK. KSK-rollover will wait until you give the ds-seen. So we could have it so that if ManualRollover is set then no keys are prepublished or removed from the zone without a manual step. Instead we would send log messages warning that this needs to be done. Sion From jakob at kirei.se Thu Mar 4 12:39:11 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 4 Mar 2010 13:39:11 +0100 Subject: [Opendnssec-develop] DoubleDNSKEY rollover In-Reply-To: References: Message-ID: On 4 mar 2010, at 11.42, sion at nominet.org.uk wrote: > This is where the "DS-SUBMIT" hook will go, when I write it. but not using syslog I hope. > QUESTION: Is logging with a priority of INFO a good idea? People might not > be looking for it. yes, INFO is correct. or perhaps NOTICE. > 3) When the "ods-ksmutil key ds-seen" command is sent, move the new key to > active, retire the old key and set its dead time (unless a --no-retire flag > is used). ack. jakob From jakob at kirei.se Thu Mar 4 12:40:32 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 4 Mar 2010 13:40:32 +0100 Subject: [Opendnssec-develop] DoubleDNSKEY rollover In-Reply-To: References: <1890633A-5E7B-4F10-8570-C12A84EC538B@iis.se> Message-ID: On 4 mar 2010, at 13.37, sion at nominet.org.uk wrote: > Do you prefer DNSKEY in the log message instead of the DS or in addition > to? from OpenDNSSEC to its hook, only DNSKEY as we don't know what digest algorithm(s) are to be used. jakob From rickard.bellgrim at iis.se Thu Mar 4 13:22:17 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 4 Mar 2010 14:22:17 +0100 Subject: [Opendnssec-develop] DoubleDNSKEY rollover In-Reply-To: References: <1890633A-5E7B-4F10-8570-C12A84EC538B@iis.se> Message-ID: <420072F8-0B4B-454F-9650-2734247EEC54@iis.se> > Currently it retires the oldest active key. DS-seen with no-retire will > leave multiple keys in the active state. I'm not sure that the standby key > should have its DS submitted until we need to roll to it? Its existence > really only saves you the time it takes to propagate through the child zone > (plus safety margin). My vision is that the rolling of keys are separated from the ds-seen command. The ds-seen command will only mark a key as seen in the parent zone. The enforcer will then by it self determine if it can roll the key, but only if the key has been marked. You can thus mark multiple keys, without enforcing a rollover. Will you not save time by publishing the DS record of the standby key? >> Do we need the ManualRollover for the KSK anymore? It is only useful >> for the ZSK. KSK-rollover will wait until you give the ds-seen. > > So we could have it so that if ManualRollover is set then no keys are > prepublished or removed from the zone without a manual step. Instead we > would send log messages warning that this needs to be done. OpenDNSSEC is a powerful tool, but I think we should keep it as simple as possible. Is there any use case where you want to manually enforce the prepublishing and the removal of the key? There could be arguments that you do not want people to know the public key before I decide to roll the key. But will that do any harm? The ManualRollover was a solution because we did not have the "ds-seen". It is still useful, but only the case of the ZSK. Where you e.g. can use "key rollover" in cron to have fixed rollover date. Or what will happen if you give "key rollover" for KSK if it is waiting for the "ds-seen"? In the case where you want a fixed rollover date for the KSK? // Rickard From sion at nominet.org.uk Thu Mar 4 14:22:49 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 4 Mar 2010 14:22:49 +0000 Subject: [Opendnssec-develop] DoubleDNSKEY rollover In-Reply-To: <420072F8-0B4B-454F-9650-2734247EEC54@iis.se> References: <1890633A-5E7B-4F10-8570-C12A84EC538B@iis.se> <420072F8-0B4B-454F-9650-2734247EEC54@iis.se> Message-ID: > > Currently it retires the oldest active key. DS-seen with no-retire will > > leave multiple keys in the active state. I'm not sure that the standby key > > should have its DS submitted until we need to roll to it? Its existence > > really only saves you the time it takes to propagate through the child zone > > (plus safety margin). > > My vision is that the rolling of keys are separated from the ds-seen > command. The ds-seen command will only mark a key as seen in the > parent zone. The enforcer will then by it self determine if it can > roll the key, but only if the key has been marked. > > You can thus mark multiple keys, without enforcing a rollover. Okay, what I'll do straight away then is I'll reverse the logic so that you need to supply a --retire flag or the old key will be left active. > Will you not save time by publishing the DS record of the standby key? Yes, but then you will have multiple active keys rather than a standby key... I'm not sure if that is what users would expect? > >> Do we need the ManualRollover for the KSK anymore? It is only useful > >> for the ZSK. KSK-rollover will wait until you give the ds-seen. > > > > So we could have it so that if ManualRollover is set then no keys are > > prepublished or removed from the zone without a manual step. Instead we > > would send log messages warning that this needs to be done. > > OpenDNSSEC is a powerful tool, but I think we should keep it as > simple as possible. Is there any use case where you want to manually > enforce the prepublishing and the removal of the key? > > There could be arguments that you do not want people to know the > public key before I decide to roll the key. But will that do any harm? > > The ManualRollover was a solution because we did not have the "ds- > seen". It is still useful, but only the case of the ZSK. Where you > e.g. can use "key rollover" in cron to have fixed rollover date. > > Or what will happen if you give "key rollover" for KSK if it is > waiting for the "ds-seen"? In the case where you want a fixed > rollover date for the KSK? My plan was to repeat the: Mar 4 10:09:47 sion ods-enforcerd: INFO: Once the new DS records are seen in DNS please issue the ds-seen command for zone sion with the following cka_ids, 48e00948d5b67116ee115df7414380e5 log message until it is seen. Issuing a "key rollover" command just says "mark the currently active key as unsafe and schedule its replacement ASAP". Given that for a KSK there is always some "manual" step involved, even if that is farmed out to an automatic process, there seems little that is gained... The one thing that can happen is that a new KSK will enter your zone without your explicit permission. I think that all of this becomes moot when I implement http://www.pivotaltracker.com/story/show/1967265 as then the user can do what they like with keys (within reason). Then you can just use longer lifetimes then you really want and force keys according to your own schedule, losing most of that libksm goodness :( So for now I will ignore the ManualRollover flag when it comes to KSKs, unless anyone objects. Sion From rickard.bellgrim at iis.se Thu Mar 4 14:38:56 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 4 Mar 2010 15:38:56 +0100 Subject: [Opendnssec-develop] DoubleDNSKEY rollover In-Reply-To: References: <1890633A-5E7B-4F10-8570-C12A84EC538B@iis.se> <420072F8-0B4B-454F-9650-2734247EEC54@iis.se> Message-ID: <344348CD-35A0-4877-AA6B-94F3F6D32D42@iis.se> On 4 mar 2010, at 15.22, wrote: >> My vision is that the rolling of keys are separated from the ds-seen >> command. The ds-seen command will only mark a key as seen in the >> parent zone. The enforcer will then by it self determine if it can >> roll the key, but only if the key has been marked. >> >> You can thus mark multiple keys, without enforcing a rollover. > > Okay, what I'll do straight away then is I'll reverse the logic so that you > need to supply a --retire flag or the old key will be left active. > >> Will you not save time by publishing the DS record of the standby key? > > Yes, but then you will have multiple active keys rather than a standby > key... I'm not sure if that is what users would expect? Isn't ok to have a DS record for a KSK that is not active, only pre-published? Isn't that the purpose of the standby key. Just so that you can roll at once, in case of emergency. From rick.zijlker at sidn.nl Thu Mar 4 15:05:51 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Thu, 4 Mar 2010 16:05:51 +0100 Subject: [Opendnssec-develop] ODS signs a zone twice initially Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86F0@KAEVS1.SIDN.local> Hey all, It seems like ODS always signs a zone twice initially. Is that as intended? I didn't expect this. Resign was set to 2 hours, but the signing only took 41 minutes. So that shouldn't be the cause. Mar 4 13:00:26 signer1 ods-signerd: Scheduling task to sign zone nl at 1267704026.4 with resign time 7200 Mar 4 13:00:26 signer1 ods-signerd: Scheduling task to sign zone nl at 1267704026.4 with resign time 7200 Mar 4 13:00:26 signer1 ods-signerd: Zone nl added Mar 4 13:00:26 signer1 ods-signerd: opening socket: /var/run/opendnssec/engine.sock Mar 4 13:00:26 signer1 ods-signerd: Engine running Mar 4 13:00:26 signer1 ods-enforcerd: opendnssec-enforcer starting... Mar 4 13:00:26 signer1 ods-enforcerd: opendnssec-enforcer Parent exiting... Mar 4 13:00:26 signer1 ods-enforcerd: opendnssec-enforcer forked OK... Mar 4 13:00:26 signer1 ods-enforcerd: opendnssec-enforcer started (version 1.0.0rc4-trunk), pid 14500 Mar 4 13:00:26 signer1 ods-enforcerd: HSM opened successfully. Mar 4 13:00:26 signer1 ods-enforcerd: Reading config "/etc/opendnssec/conf.xml" Mar 4 13:00:26 signer1 ods-enforcerd: Reading config schema "/usr/local/share/opendnssec/conf.rng" Mar 4 13:00:26 signer1 ods-enforcerd: Communication Interval: 3600 Mar 4 13:00:26 signer1 ods-enforcerd: SQLite database set to: /var/opendnssec/kasp.db Mar 4 13:00:26 signer1 ods-enforcerd: Log User set to: local0 Mar 4 13:00:26 signer1 ods-enforcerd: Switched log facility to: local0 Mar 4 13:00:26 signer1 ods-enforcerd: Connecting to Database... Mar 4 13:00:26 signer1 ods-enforcerd: Policy default found. Mar 4 13:00:26 signer1 ods-enforcerd: Key sharing is Off. Mar 4 13:00:26 signer1 ods-signerd: Zone action to perform: 3 Mar 4 13:00:26 signer1 ods-signerd: Resorting signed zone: nl Mar 4 13:00:26 signer1 ods-signerd: stderr from sorter: Number of records sorted: 12 Mar 4 13:00:26 signer1 ods-signerd: Preprocessing signed zone: nl Mar 4 13:00:27 signer1 ods-signerd: Sorting zone: nl Mar 4 13:00:29 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated Mar 4 13:00:29 signer1 ods-enforcerd: Created KSK size: 2048, alg: 7 with id: 391bfa8cab90cb650ddc8c804ce78f7d in repository: softHSM and database. Mar 4 13:00:30 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated Mar 4 13:00:30 signer1 ods-enforcerd: Created KSK size: 2048, alg: 7 with id: ad980ec78864e3538fd222f83a6f4592 in repository: softHSM and database. Mar 4 13:00:30 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated Mar 4 13:00:30 signer1 ods-enforcerd: Created ZSK size: 1024, alg: 7 with id: f8a856fa42673a82c04a0a2f028e48d3 in repository: softHSM and database. Mar 4 13:00:30 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated Mar 4 13:00:30 signer1 ods-enforcerd: Created ZSK size: 1024, alg: 7 with id: 7864bffa0e939e7f060b55178a272b56 in repository: softHSM and database. Mar 4 13:00:30 signer1 ods-enforcerd: zonelist filename set to /etc/opendnssec/zonelist.xml. Mar 4 13:00:30 signer1 ods-enforcerd: Zone nl found. Mar 4 13:00:30 signer1 ods-enforcerd: Policy for nl set to default. Mar 4 13:00:30 signer1 ods-enforcerd: Config will be output to /var/opendnssec/signconf/nl.xml. Mar 4 13:00:31 signer1 ods-enforcerd: INFO: Promoting KSK from publish to active as this is the first pass for the zone Mar 4 13:00:31 signer1 ods-enforcerd: WARNING: Making non-backed up KSK active, PLEASE make sure that you know the potential problems of using keys which are not recoverable Mar 4 13:00:31 signer1 ods-enforcerd: INFO: Promoting ZSK from publish to active as this is the first pass for the zone Mar 4 13:00:31 signer1 ods-enforcerd: WARNING: Making non-backed up ZSK active, PLEASE make sure that you know the potential problems of using keys which are not recoverable Mar 4 13:00:31 signer1 ods-signerd: Received command: 'update nl' Mar 4 13:00:31 signer1 ods-signerd: Scheduling task to sign zone nl, zone in progress, scheduling as soon as possible Mar 4 13:00:31 signer1 ods-enforcerd: Could not call signer engine Mar 4 13:00:31 signer1 ods-enforcerd: Will continue: call 'ods-signer update' to manually update zones Mar 4 13:00:31 signer1 ods-enforcerd: Disconnecting from Database... Mar 4 13:00:31 signer1 ods-enforcerd: Sleeping for 3600 seconds. Mar 4 13:00:31 signer1 ods-signerd: Client socket shut down Mar 4 13:06:11 signer1 ods-signerd: stderr from sorter: Number of records sorted: 8807860 Mar 4 13:06:11 signer1 ods-signerd: Nseccing zone: nl Mar 4 13:06:11 signer1 ods-signerd: No information yet for key 391bfa8cab90cb650ddc8c804ce78f7d Mar 4 13:06:11 signer1 ods-signerd: Generating DNSKEY RR for 391bfa8cab90cb650ddc8c804ce78f7d Mar 4 13:06:11 signer1 ods-signerd: Found key 391bfa8cab90cb650ddc8c804ce78f7d Mar 4 13:06:11 signer1 ods-signerd: No information yet for key ad980ec78864e3538fd222f83a6f4592 Mar 4 13:06:11 signer1 ods-signerd: Generating DNSKEY RR for ad980ec78864e3538fd222f83a6f4592 Mar 4 13:06:11 signer1 ods-signerd: Found key ad980ec78864e3538fd222f83a6f4592 Mar 4 13:06:11 signer1 ods-signerd: No information yet for key f8a856fa42673a82c04a0a2f028e48d3 Mar 4 13:06:11 signer1 ods-signerd: Generating DNSKEY RR for f8a856fa42673a82c04a0a2f028e48d3 Mar 4 13:06:11 signer1 ods-signerd: Found key f8a856fa42673a82c04a0a2f028e48d3 Mar 4 13:06:11 signer1 ods-signerd: No information yet for key 7864bffa0e939e7f060b55178a272b56 Mar 4 13:06:11 signer1 ods-signerd: Generating DNSKEY RR for 7864bffa0e939e7f060b55178a272b56 Mar 4 13:06:11 signer1 ods-signerd: Found key 7864bffa0e939e7f060b55178a272b56 Mar 4 13:31:57 signer1 ods-signerd: signer stderr: signer: number of signatures created: 723247 (611 rr/sec) Mar 4 13:31:57 signer1 ods-signerd: Created 723247 new signatures Mar 4 13:32:27 signer1 ods-signerd: Running auditor on zone Mar 4 13:32:28 signer1 ods-auditor[14985]: Auditor started Mar 4 13:32:28 signer1 ods-auditor[14985]: Auditor starting on nl Mar 4 13:32:28 signer1 ods-auditor[14985]: Auditing nl zone : NSEC3 SIGNED Mar 4 13:39:31 signer1 ods-auditor[14985]: SOA differs : from 2009111707 to 1267704734 Mar 4 13:39:42 signer1 ods-auditor[14985]: Key (25673) has gone straight to active use without a prepublished phase Mar 4 13:39:42 signer1 ods-auditor[14985]: Key (63901) has gone straight to active use without a prepublished phase Mar 4 13:39:42 signer1 ods-auditor[14985]: Finished auditing nl zone Mar 4 13:39:42 signer1 ods-signerd: Auditor result: 3 Mar 4 13:39:42 signer1 ods-signerd: Zone action to perform: 3 Mar 4 13:39:42 signer1 ods-signerd: Resorting signed zone: nl Mar 4 13:40:52 signer1 ods-signerd: stderr from sorter: Number of records sorted: 1203193 Mar 4 13:40:52 signer1 ods-signerd: Preprocessing signed zone: nl Mar 4 13:41:47 signer1 ods-signerd: Sorting zone: nl Mar 4 13:47:36 signer1 ods-signerd: stderr from sorter: Number of records sorted: 8807860 Mar 4 13:47:36 signer1 ods-signerd: Nseccing zone: nl Mar 4 14:00:31 signer1 ods-enforcerd: Reading config "/etc/opendnssec/conf.xml" Mar 4 14:00:31 signer1 ods-enforcerd: Reading config schema "/usr/local/share/opendnssec/conf.rng" Mar 4 14:00:31 signer1 ods-enforcerd: Communication Interval: 3600 Mar 4 14:00:31 signer1 ods-enforcerd: SQLite database set to: /var/opendnssec/kasp.db Mar 4 14:00:31 signer1 ods-enforcerd: Log User set to: local0 Mar 4 14:00:31 signer1 ods-enforcerd: Switched log facility to: local0 Mar 4 14:00:31 signer1 ods-enforcerd: Connecting to Database... Mar 4 14:00:31 signer1 ods-enforcerd: Policy default found. Mar 4 14:00:31 signer1 ods-enforcerd: Key sharing is Off. Mar 4 14:00:31 signer1 ods-enforcerd: zonelist filename set to /etc/opendnssec/zonelist.xml. Mar 4 14:00:31 signer1 ods-enforcerd: Zone nl found. Mar 4 14:00:31 signer1 ods-enforcerd: Policy for nl set to default. Mar 4 14:00:31 signer1 ods-enforcerd: Config will be output to /var/opendnssec/signconf/nl.xml. Mar 4 14:00:31 signer1 ods-enforcerd: No change to: /var/opendnssec/signconf/nl.xml Mar 4 14:00:31 signer1 ods-enforcerd: Disconnecting from Database... Mar 4 14:00:31 signer1 ods-enforcerd: Sleeping for 3600 seconds. Mar 4 14:10:24 signer1 ods-signerd: signer stderr: signer: number of signatures created: 723247 (686 rr/sec) Mar 4 14:10:24 signer1 ods-signerd: Created 723247 new signatures Mar 4 14:10:54 signer1 ods-signerd: Running auditor on zone Mar 4 14:10:54 signer1 ods-auditor[15561]: Auditor started Mar 4 14:10:54 signer1 ods-auditor[15561]: Auditor starting on nl Mar 4 14:10:54 signer1 ods-auditor[15561]: Auditing nl zone : NSEC3 SIGNED Mar 4 14:18:28 signer1 ods-auditor[15561]: SOA differs : from 2009111707 to 1267707170 Mar 4 14:18:40 signer1 ods-auditor[15561]: Finished auditing nl zone Mar 4 14:18:40 signer1 ods-signerd: Auditor result: 0 Mar 4 14:18:40 signer1 ods-signerd: Output zone to /var/opendnssec/signed/nl Mar 4 14:18:40 signer1 ods-signerd: Stored output serial: 1267707170 Regards, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Thu Mar 4 15:13:43 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 4 Mar 2010 15:13:43 +0000 Subject: [Opendnssec-develop] ODS signs a zone twice initially In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86F0@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949014D86F0@KAEVS1.SIDN.local> Message-ID: > It seems like ODS always signs a zone twice initially. Is that as > intended? I didn?t expect this. Resign was set to 2 hours, but the > signing only took 41 minutes. So that shouldn?t be the cause. It looks to me like the enforcer is generating new keys and publishing them; however the signer is maybe picking up an old signconf file and using the keys in that. When the enforcer finishes it sees that the signconf has changed and kicks off the signer a second time. Note that running "ods-ksmutil setup" does not remove files from the signconf directory _or_ from softhsm, so the signer will happily run with the old information. Sion From rickard.bellgrim at iis.se Fri Mar 5 07:35:56 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 5 Mar 2010 08:35:56 +0100 Subject: [Opendnssec-develop] New sorter Message-ID: Hi Is it time to introduce the new sorter in trunk? It should just be a drop-in replacement. // Rickard From owner-dnssec-trac at kirei.se Fri Mar 5 07:41:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Mar 2010 07:41:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #105: ./configure support for --disable-sqlite3 In-Reply-To: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> References: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> Message-ID: <064.1f2d899fa54fbc0cdbefe63c8407b831@kirei.se> #105: ./configure support for --disable-sqlite3 ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: rb Type: enhancement | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- Comment(by rb): But we do not link both MySQL and SQLite at the same time. If you enable MySQL then SQLite is not linked. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Mar 5 07:48:56 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Mar 2010 07:48:56 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #98: Few questions and documentation in FR In-Reply-To: <061.7bcb16c95b5cebb5d79044c07d5601ec@kirei.se> References: <061.7bcb16c95b5cebb5d79044c07d5601ec@kirei.se> Message-ID: <070.98919693ded29659fcb9321348feaca2@kirei.se> #98: Few questions and documentation in FR ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: closed Priority: trivial | Component: Unknown Version: | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Mar 5 08:35:00 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Mar 2010 08:35:00 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #90: Extra symbols in libhsm In-Reply-To: <065.d9f2da5f94fdaf6c8aa6909b7138e9ae@kirei.se> References: <065.d9f2da5f94fdaf6c8aa6909b7138e9ae@kirei.se> Message-ID: <074.d32fc345c57b772b17d37ef1aa6f45d4@kirei.se> #90: Extra symbols in libhsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: assigned Priority: minor | Component: libhsm Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): Strange, it does not work for me. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Fri Mar 5 08:54:44 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 5 Mar 2010 09:54:44 +0100 Subject: [Opendnssec-develop] quicksorter moved to trunk Message-ID: I've now moved the quicksorter to trunk. it is still not used (but it is installed). jakob From sion at nominet.org.uk Fri Mar 5 10:09:18 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Fri, 5 Mar 2010 10:09:18 +0000 Subject: [Opendnssec-develop] DoubleDNSKEY rollover In-Reply-To: <344348CD-35A0-4877-AA6B-94F3F6D32D42@iis.se> References: <1890633A-5E7B-4F10-8570-C12A84EC538B@iis.se> <420072F8-0B4B-454F-9650-2734247EEC54@iis.se> <344348CD-35A0-4877-AA6B-94F3F6D32D42@iis.se> Message-ID: > Isn't ok to have a DS record for a KSK that is not active, only pre- > published? Isn't that the purpose of the standby key. Just so that > you can roll at once, in case of emergency. Okay, we can have this. What I'll do is take the standby key out of the normal sequence into a "ds-submitted, ds-ready" state, but reuse the publish and ready timestamp columns (to avoid database schema changes). Then if a rollover is requested we will use a key in the ready state if one exists, otherwise one in the "ds-ready" state, failing that we will promote a key and wait. Does this sound right to people? Sion From rickard.bellgrim at iis.se Fri Mar 5 10:14:04 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 5 Mar 2010 11:14:04 +0100 Subject: [Opendnssec-develop] DoubleDNSKEY rollover In-Reply-To: References: <1890633A-5E7B-4F10-8570-C12A84EC538B@iis.se> <420072F8-0B4B-454F-9650-2734247EEC54@iis.se> <344348CD-35A0-4877-AA6B-94F3F6D32D42@iis.se> Message-ID: On 5 mar 2010, at 11.09, > > wrote: Isn't ok to have a DS record for a KSK that is not active, only pre- published? Isn't that the purpose of the standby key. Just so that you can roll at once, in case of emergency. Okay, we can have this. What I'll do is take the standby key out of the normal sequence into a "ds-submitted, ds-ready" state, but reuse the publish and ready timestamp columns (to avoid database schema changes). Then if a rollover is requested we will use a key in the ready state if one exists, otherwise one in the "ds-ready" state, failing that we will promote a key and wait. Does this sound right to people? Yes Because now we can send all the prepublished, ready, and active keys to the eppclient and it will sync the keys. It can then give an ok back, without enforcing a rollover. // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Fri Mar 5 10:19:20 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 5 Mar 2010 11:19:20 +0100 Subject: [Opendnssec-develop] Proposal for DS submission hook syntax for the Enforcer Message-ID: <36C6BF83-E01E-4EAC-A506-43D5D9C9D45B@kirei.se> I suggest we do something like this: Index: conf/conf.rnc =================================================================== --- conf/conf.rnc (revision 2960) +++ conf/conf.rnc (working copy) @@ -88,7 +88,13 @@ element ManualKeyGeneration { empty }?, # How long before a KSK Rollover should we start warning (optional) - element RolloverNotification { xsd:duration }? + element RolloverNotification { xsd:duration }?, + + # Command to use for submitting new DS records to a parent - + # the command should accept DNSKEY RDATA via STDIN + # + # '%zone' in the string will be replaced by the zone name + element DelegationSignerSubmitCommand { xsd:string }? }, # Configuration parameters for the Signer e.g. with eppclient one would use: /usr/local/sbin/eppclient %zone makes sense? jakob From rickard.bellgrim at iis.se Fri Mar 5 10:22:08 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 5 Mar 2010 11:22:08 +0100 Subject: [Opendnssec-develop] quicksorter moved to trunk In-Reply-To: References: Message-ID: The new quicksorter is now used by the signer. But it fails on some of my zones. I get some extra characters in SSHFP, DS, CERT, TXT. Bj?rn is working on that. The zone_reader also hangs on something. And uses 100% of the CPU. On 5 mar 2010, at 09.54, Jakob Schlyter wrote: > I've now moved the quicksorter to trunk. it is still not used (but it is installed). From rick.zijlker at sidn.nl Fri Mar 5 10:27:12 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Fri, 5 Mar 2010 11:27:12 +0100 Subject: [Opendnssec-develop] Signer hangs.. caused by auditor? Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86F7@KAEVS1.SIDN.local> Hey all, This week I needed to kill processes quite often. It seems like "ods-control stop" command was not stopping the engines properly (even though there is no signing going on) and when restarting them the system kept hanging at: [root at signer1 kasp]# ods-control start Starting signer engine... connecting to /var/run/opendnssec/engine.sock By using ctrl-c this step gets skipped and the enforcer starts but not the signer. I need to kill idle auditor threads which I saw when running "ps -e" and the log would shows me: Mar 5 11:11:04 signer1 ods-signerd: Auditor result: -15 Mar 5 11:11:04 signer1 ods-signerd: close syslog Mar 5 11:11:04 signer1 python: Connection closed by peer After that I can start the engines successfully. The problem is, the auditor wasn't doing anything for hours. It looked like the auditor claimed the signer for nothing but thereby prohibiting it to start. I am using yesterdays trunk checkout and partial auditor. Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at haxx.se Fri Mar 5 14:24:48 2010 From: bjorn at haxx.se (=?iso-8859-1?Q?Bj=F6rn?= Stenberg) Date: Fri, 5 Mar 2010 15:24:48 +0100 Subject: [Opendnssec-develop] quicksorter moved to trunk In-Reply-To: References: Message-ID: <20100305142448.GE22173@giant> Rickard Bellgrim wrote: > The new quicksorter is now used by the signer. But it fails on some of my > zones. I get some extra characters in SSHFP, DS, CERT, TXT. Bj?rn is working > on that. The error was due to a compiler flag that fell off in the move to trunk. Fixed now. -- Bj?rn From Ray.Bellis at nominet.org.uk Fri Mar 5 14:35:00 2010 From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk) Date: Fri, 5 Mar 2010 14:35:00 +0000 Subject: [Opendnssec-develop] quicksorter moved to trunk In-Reply-To: <20100305142448.GE22173@giant> References: <20100305142448.GE22173@giant> Message-ID: > The error was due to a compiler flag that fell off in the move to trunk. Was this the -funsigned-char option, added (presumably) after my code review? If so, I'd have to say that for best portability the correct fix would be to make sure that chars that need to be unsigned are actually declared that way, rather than relying on compiler flags to change the defaults. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray at nominet.org.uk, t: +44 1865 332211 -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrik.wallstrom at iis.se Fri Mar 5 15:02:28 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Fri, 5 Mar 2010 16:02:28 +0100 Subject: [Opendnssec-develop] Proposal for DS submission hook syntax for the Enforcer In-Reply-To: <36C6BF83-E01E-4EAC-A506-43D5D9C9D45B@kirei.se> References: <36C6BF83-E01E-4EAC-A506-43D5D9C9D45B@kirei.se> Message-ID: <735DE471-7AA5-4AD0-B45A-E938AB54BF03@iis.se> On Mar 5, 2010, at 11:19 AM, Jakob Schlyter wrote: > > # How long before a KSK Rollover should we start warning (optional) > - element RolloverNotification { xsd:duration }? > + element RolloverNotification { xsd:duration }?, > + > + # Command to use for submitting new DS records to a parent - > + # the command should accept DNSKEY RDATA via STDIN > + # > + # '%zone' in the string will be replaced by the zone name > + element DelegationSignerSubmitCommand { xsd:string }? Just a clarification. What we need to send is ALL the current keys to the parent (we want to be published), not just new keys. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From Alexd at nominet.org.uk Fri Mar 5 16:22:43 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Fri, 5 Mar 2010 16:22:43 +0000 Subject: [Opendnssec-develop] Signer hangs.. caused by auditor? In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86F7@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949014D86F7@KAEVS1.SIDN.local> Message-ID: > This week I needed to kill processes quite often. It seems like > ?ods-control stop? command was not stopping the engines properly > (even though there is no signing going on) and when restarting them > the system kept hanging at: > > [root at signer1 kasp]# ods-control start > Starting signer engine... > connecting to /var/run/opendnssec/engine.sock > > By using ctrl-c this step gets skipped and the enforcer starts but > not the signer. > I need to kill idle auditor threads which I saw when running ?ps -e" > and the log would shows me: > > Mar 5 11:11:04 signer1 ods-signerd: Auditor result: -15 > Mar 5 11:11:04 signer1 ods-signerd: close syslog > Mar 5 11:11:04 signer1 python: Connection closed by peer > > After that I can start the engines successfully. The problem is, the > auditor wasn?t doing anything for hours. It looked like the auditor > claimed the signer for nothing but thereby prohibiting it to start. > > I am using yesterdays trunk checkout and partial auditor. Sounds like there is an issue with the partial auditor. Is there anything in the logs? I'm on holiday just now, but will be able to look at this next week. In the mean time, try disabling the auditor... Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at haxx.se Mon Mar 8 09:30:04 2010 From: bjorn at haxx.se (=?iso-8859-1?Q?Bj=F6rn?= Stenberg) Date: Mon, 8 Mar 2010 10:30:04 +0100 Subject: [Opendnssec-develop] quicksorter moved to trunk In-Reply-To: References: <20100305142448.GE22173@giant> Message-ID: <20100308093004.GD25019@giant> Ray.Bellis at nominet.org.uk wrote: > I'd have to say that for best portability the correct fix would be > to make sure that chars that need to be unsigned are actually declared > that way, rather than relying on compiler flags to change the defaults. Yes, it's a bit unorthodox. But it's a choice between two evils. I'll explain: It's a little-known fact that C has not two but three distinct char types: signed char, unsigned char and char. All the ANSI C string functions take 'char*' as parameter type. With the strict compiler flags we use, passing an 'unsigned char*' or a 'signed char*' to a parameter that takes a 'char*' produces a compiler warning: passing argument 1 of 'strcpy' differ in signedness. The standard way to silence these warnings is to use typecasts. Lots and lots of typecasts. The disadvantage with flooding the code with typecasts, apart from making it more noisy and hard to read, is that by definition this also disables the static type checking and hence makes the code more susceptible to mistakes and bugs. There are of course other options. We can use the mem* functions instead of str*, if we add some buffer length housekeeping. We can write wrappers for all the standard C functions that hide away the typecasting. Etc. In the end I chose to try and keep the code clean. It's pretty gritty as it is. And since all C compilers I have seen have the equivalent of the -funsigned-char option (due to the sign of 'char' being unspecified), I did not consider it a portability hurdle. If the consensus is that typecasts are preferred over this compiler flag, I'm not going to argue against it. -- Bj?rn From owner-dnssec-trac at kirei.se Mon Mar 8 19:43:05 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 08 Mar 2010 19:43:05 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #105: ./configure support for --disable-sqlite3 In-Reply-To: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> References: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> Message-ID: <064.374a2d1f362ea5af7bb62f3fd1fa8022@kirei.se> #105: ./configure support for --disable-sqlite3 ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: rb Type: enhancement | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- Comment(by peter@?): This was discussed at .SE today. The package must allow explicit control of all optional dependencies. However - is sqlite actually completely optional right now? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 8 19:52:04 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 08 Mar 2010 19:52:04 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #3: Please, really please, drop the Ruby on the floor In-Reply-To: <053.1d9719264068533622d6a3fffe52a6d5@kirei.se> References: <053.1d9719264068533622d6a3fffe52a6d5@kirei.se> Message-ID: <062.6af462361cdb878b44d30d0f016fc6b1@kirei.se> #3: Please, really please, drop the Ruby on the floor ----------------------------+----------------------------------------------- Reporter: ondrej@? | Owner: alex Type: defect | Status: closed Priority: minor | Component: Auditor Version: 1.0a1 | Resolution: wontfix Keywords: | ----------------------------+----------------------------------------------- Comment(by peter@?): One way would be to just go with something else.. Python or Perl would probably both be friendlier. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 8 20:02:01 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 08 Mar 2010 20:02:01 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #26: Signer (or communicated) gets very slow with many zones In-Reply-To: <043.3e06d24187eff497c818ae327e7a67e4@kirei.se> References: <043.3e06d24187eff497c818ae327e7a67e4@kirei.se> Message-ID: <052.957b3aaf175c556afddf0476cc8837c7@kirei.se> #26: Signer (or communicated) gets very slow with many zones -------------------+-------------------------------------------------------- Reporter: pawal | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: | Keywords: -------------------+-------------------------------------------------------- Comment(by peter@?): What kind of queries are hitting SQLite here? Let's talk tomorrow. [wiki:Meetings/Minutes/2010-01-28] mentions looping over many thousand zones in order to detect changes. I would strongly recommend using operating system notification instead; anything based on stat() just will not scale. Linux has had Inotify for a long time and it works very well, the more recent fnotify arguably has a friendlier API but may be less widespread. Systems other than Linux must also offer a similar notification service. I don't think polling the answer. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Mar 9 08:41:56 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 9 Mar 2010 09:41:56 +0100 Subject: [Opendnssec-develop] Reminder of meeting 2010-03-10 (Wednesday) Message-ID: Hi Remember that we have a meeting tomorrow. You can find the agenda here: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-03-10 Date: Wednesday 10 March Time: 14:00-15:00 CET, 13:00-14:00 GMT // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Tue Mar 9 11:19:16 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 9 Mar 2010 12:19:16 +0100 Subject: [Opendnssec-develop] Proposal for DS submission hook syntax for the Enforcer In-Reply-To: <735DE471-7AA5-4AD0-B45A-E938AB54BF03@iis.se> References: <36C6BF83-E01E-4EAC-A506-43D5D9C9D45B@kirei.se> <735DE471-7AA5-4AD0-B45A-E938AB54BF03@iis.se> Message-ID: would it be resonable to alter eppclient so it will read complete RRsets (instead of RDATA) on STDIN and automatically derive the zone basen on that? also, will eppclient automatically derive the parent? would that work with a multi-level registry? (i.e., does it understand that xxx.pp.se is handled by se as well) jakob From owner-dnssec-trac at kirei.se Tue Mar 9 13:35:13 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 09 Mar 2010 13:35:13 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #108: key import strange behaviour Message-ID: <063.773a5689a2a9c2791e12c48b73a8ec71@kirei.se> #108: key import strange behaviour --------------------------------------+------------------------------------- Reporter: vincent.levigneron@? | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: 1.0.0 | Keywords: --------------------------------------+------------------------------------- As I want to keep my KSK which is configured as a trusted key in all my name servers, I import it each Time I try a new ODS from-scratch configuration. These are the commands I use... > softhsm --import ksk.pem --slot 0 --pin 1234 --label Afnic1 --id F1D0 The key appears in the HSM. > ods-hsmutil list Repository ID Type ---------- -- ---- softHSM f1d0 RSA/2048 I use the following command to import the key in ODS: > ods-ksmutil key import --cka_id f1d0 --repository softHSM --zone fr --keytype KSK --bits 2048 --algorithm 7 --keystate ACTIVE --time 20100202 BUT when I list the keys, I have the following output... > ods-ksmutil --verbose key list SQLite database set to: /home/afnicreg/Key_Manager/ODS/var/kasp.db Keys: Zone: Keytype: State: Date of next transition: CKA_ID: Repository: Keytag: fr KSK active xpU? f1d0 softHSM 15858 After several tries, the "Date of next transition" has never been human- readable... -- Ticket URL: OpenDNSSEC OpenDNSSEC From bjorn at haxx.se Tue Mar 9 14:34:20 2010 From: bjorn at haxx.se (=?iso-8859-1?Q?Bj=F6rn?= Stenberg) Date: Tue, 9 Mar 2010 15:34:20 +0100 Subject: [Opendnssec-develop] Proposal for DS submission hook syntax for the Enforcer In-Reply-To: References: <36C6BF83-E01E-4EAC-A506-43D5D9C9D45B@kirei.se> <735DE471-7AA5-4AD0-B45A-E938AB54BF03@iis.se> Message-ID: <20100309143420.GF20884@giant> Jakob Schlyter wrote: > also, will eppclient automatically derive the parent? > would that work with a multi-level registry? (i.e., does it understand that > xxx.pp.se is handled by se as well) Yes. It matches the registry suffixes to the end of the zone name. Hence it can handle for example ".foo.se" and ".bar.se" as different registries. But it cannot handle subset overlaps, such as one registry for ".se" and another for ".foo.se". -- Bj?rn From owner-dnssec-trac at kirei.se Tue Mar 9 14:54:36 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 09 Mar 2010 14:54:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #108: key import strange behaviour In-Reply-To: <063.773a5689a2a9c2791e12c48b73a8ec71@kirei.se> References: <063.773a5689a2a9c2791e12c48b73a8ec71@kirei.se> Message-ID: <072.be2bf4d6e5ab7216c494d38ad985c977@kirei.se> #108: key import strange behaviour --------------------------------------+------------------------------------- Reporter: vincent.levigneron@? | Owner: sion Type: defect | Status: accepted Priority: major | Component: Enforcer Version: 1.0.0 | Keywords: --------------------------------------+------------------------------------- Changes (by sion): * status: new => accepted Comment: Thank you. I see where the issue is and will fix it shortly. Sion -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Mar 9 15:43:21 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 09 Mar 2010 15:43:21 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #108: key import strange behaviour In-Reply-To: <063.773a5689a2a9c2791e12c48b73a8ec71@kirei.se> References: <063.773a5689a2a9c2791e12c48b73a8ec71@kirei.se> Message-ID: <072.c85d9137f64105bcb9f467ffda30b55f@kirei.se> #108: key import strange behaviour --------------------------------------+------------------------------------- Reporter: vincent.levigneron@? | Owner: sion Type: defect | Status: closed Priority: major | Component: Enforcer Version: 1.0.0 | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Changes (by sion): * status: accepted => closed * resolution: => fixed Comment: I've fixed this in trunk (svn r2983). I was not dealing with the optional retire time parameter properly, so random data was being read. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 10 09:39:36 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 10 Mar 2010 09:39:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #105: ./configure support for --disable-sqlite3 In-Reply-To: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> References: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> Message-ID: <064.9ea757cbaa196e437eb68bbeacc5b379@kirei.se> #105: ./configure support for --disable-sqlite3 ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: rb Type: enhancement | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- Comment(by tom@?): I did some more thinking on this. Maybe another option would be to drop the enable- switches and replace them with one new one: --with-database-backend={sqlite3,mysql} This would create several advantages: - much easier code (error checking) in ./configure when more database backends are added in the future (postgres, oracle?) - obvious selection mechanism that shows that only one db backend can be picked. -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Wed Mar 10 10:06:35 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 10 Mar 2010 10:06:35 +0000 Subject: [Opendnssec-develop] Signer hangs.. caused by auditor? In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86F7@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949014D86F7@KAEVS1.SIDN.local> Message-ID: Hi - opendnssec-develop-bounces at lists.opendnssec.org wrote on 05/03/2010 10:27:12: > "Rick Zijlker" > Sent by: opendnssec-develop-bounces at lists.opendnssec.org > This week I needed to kill processes quite often. It seems like > ?ods-control stop? command was not stopping the engines properly > (even though there is no signing going on) and when restarting them > the system kept hanging at: > > [root at signer1 kasp]# ods-control start > Starting signer engine... > connecting to /var/run/opendnssec/engine.sock > > By using ctrl-c this step gets skipped and the enforcer starts but > not the signer. > I need to kill idle auditor threads which I saw when running ?ps -e" > and the log would shows me: > > Mar 5 11:11:04 signer1 ods-signerd: Auditor result: -15 > Mar 5 11:11:04 signer1 ods-signerd: close syslog > Mar 5 11:11:04 signer1 python: Connection closed by peer > > After that I can start the engines successfully. The problem is, the > auditor wasn?t doing anything for hours. It looked like the auditor > claimed the signer for nothing but thereby prohibiting it to start. > > I am using yesterdays trunk checkout and partial auditor. I have had other reports of the auditor failing, which have been withdrawn after recent fixes to the quick sorter. Is is possible that updating these changes fixes your problem? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Wed Mar 10 11:08:55 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 10 Mar 2010 12:08:55 +0100 Subject: [Opendnssec-develop] Performance Message-ID: <4E7D1B82-8A21-43C6-98BC-659C5BFD8090@iis.se> Hi The new code for v1.1 also makes the .se-zone faster: V1: Start 00:00 sorter (2095915 RR) 01:00 zone_reader 02:03 nseccer (38828 rr/sec) 02:26 signer (1529 rr/sec) 12:11 finalizer 12:20 V1.1: start 00:00 quicksorter 00:05 zone_reader 01:01 signer (1540 rr/sec) 10:42 finalizer 10:51 The nseccer is now part of the zone_reader. The next step would be parallel signing, and then the signing speed would become up to 8 times faster. // Rickard From rickard.bellgrim at iis.se Wed Mar 10 14:54:38 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 10 Mar 2010 15:54:38 +0100 Subject: [Opendnssec-develop] Release of v1.1 Message-ID: <997E986C-9CCB-4F68-9C06-44B2FBDFA9C1@iis.se> Hi The release of 1.1 is getting closer and we still have a lot of things to do. The solution to this was to check what we actually need for 1.1. * Increase the speed for signing large zones (Status: Done) * Clarification to the KSK rollover process (Status: In progress) * Partial auditor (Status: Done) * EPP-client (Status: Done) * Sending keys to the EPP-client (Status: Not started) So we have now moved the support for large number of zones to v1.2. The website and Pivotal has been updated to reflect this. We also need: * Updated user documentation to reflect the changes * Testing Hopefully can have we the coding finished during next week. And the just focus on testing and documentation. // Rickard From rick at openfortress.nl Wed Mar 10 15:25:29 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 10 Mar 2010 15:25:29 +0000 Subject: [Opendnssec-develop] Meeting notes 2010-03-10 Message-ID: <20100310152529.GA1852@phantom.vanrein.org> Hello, I published the meeting notes of 2010-2-24. I think I heard mention of August as a date for v1.2, but I may have misheard, so I didn't note it in the minutes. Let me know if it ought to have been included in relation to the remarks about support for large numbers of zones. Best wishes, -Rick From rickard.bellgrim at iis.se Wed Mar 10 15:33:03 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 10 Mar 2010 16:33:03 +0100 Subject: [Opendnssec-develop] Meeting notes 2010-03-10 In-Reply-To: <20100310152529.GA1852@phantom.vanrein.org> References: <20100310152529.GA1852@phantom.vanrein.org> Message-ID: On 10 mar 2010, at 16.25, Rick van Rein wrote: > I think I heard mention of August as a date for v1.2, but I may > have misheard, so I didn't note it in the minutes. It should be May. From jakob at kirei.se Wed Mar 10 15:45:59 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 10 Mar 2010 16:45:59 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics Message-ID: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> The semantics of "jitter" differs between BIND9 and OpenDNSSEC: BIND9 does expiration' = expiration - (rnd % jitter) OpenDNSSEC does expiration' = expiration + (rnd % jitter) one might also consider doing expiration' = expiration - jitter + (rnd % (jitter * 2)) I kind of like to BIND9 semantics, not only because I designed it but also because it's the most conservative approach (ie. the expiration is the longest possible signature validity and decreased slightly by jitter). Anyway, we need to fix this - both for 1.1 and for 1.0. and make sure it is properly documented. jakob ref: http://www.pivotaltracker.com/story/show/2744296 From sion at nominet.org.uk Wed Mar 10 16:19:01 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 10 Mar 2010 16:19:01 +0000 Subject: [Opendnssec-develop] Meeting notes 2010-03-10 In-Reply-To: References: <20100310152529.GA1852@phantom.vanrein.org> Message-ID: > > I think I heard mention of August as a date for v1.2, but I may > > have misheard, so I didn't note it in the minutes. > > It should be May. I think that the August date was when we are predicted to complete the work, based on the current velocity. So nothing to worry about :) From rickard.bellgrim at iis.se Wed Mar 10 16:34:27 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 10 Mar 2010 17:34:27 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> Message-ID: Does the same thing apply to the inception offset? So that the validity in the configuration is the maximum possible. // Rickard On 10 mar 2010, at 16.45, Jakob Schlyter wrote: > > The semantics of "jitter" differs between BIND9 and OpenDNSSEC: > > BIND9 does expiration' = expiration - (rnd % jitter) > OpenDNSSEC does expiration' = expiration + (rnd % jitter) > > one might also consider doing expiration' = expiration - jitter + (rnd % (jitter * 2)) > > > I kind of like to BIND9 semantics, not only because I designed it but also because it's the most conservative approach (ie. the expiration is the longest possible signature validity and decreased slightly by jitter). > > Anyway, we need to fix this - both for 1.1 and for 1.0. and make sure it is properly documented. > > > jakob > > ref: http://www.pivotaltracker.com/story/show/2744296 > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From owner-dnssec-trac at kirei.se Wed Mar 10 16:50:58 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 10 Mar 2010 16:50:58 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #105: ./configure support for --disable-sqlite3 In-Reply-To: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> References: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> Message-ID: <064.58f474a8aa25b001d74e76be1dbbbdb0@kirei.se> #105: ./configure support for --disable-sqlite3 ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: rb Type: enhancement | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- Comment(by peter@?): Replying to [comment:3 tom@?]: > - obvious selection mechanism that shows that only one db backend can be picked. Is that true though? Can OpenDNSSEC operate completely without SQLite? -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Wed Mar 10 22:05:56 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 10 Mar 2010 23:05:56 +0100 Subject: [Opendnssec-develop] --with-database-backend={sqlite3,mysql} Message-ID: <75F07467-9D65-410B-82F8-09DC6472F201@kirei.se> regarding http://trac.opendnssec.org/ticket/105, I really like the --with-database-backend={sqlite3,mysql} approach. should we do that? jakob From jakob at kirei.se Wed Mar 10 22:15:56 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 10 Mar 2010 23:15:56 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> Message-ID: <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> On 10 mar 2010, at 17.34, Rickard Bellgrim wrote: > Does the same thing apply to the inception offset? the effective inception seems to be calculated as the the current timestamp - inception offset. as far as I can see, no other checks are made. jakob From rickard.bellgrim at iis.se Wed Mar 10 22:46:29 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 10 Mar 2010 23:46:29 +0100 Subject: [Opendnssec-develop] --with-database-backend={sqlite3,mysql} In-Reply-To: <75F07467-9D65-410B-82F8-09DC6472F201@kirei.se> References: <75F07467-9D65-410B-82F8-09DC6472F201@kirei.se> Message-ID: <10254CC3-768D-427D-A992-C6FC581CCB21@iis.se> +1 10 mar 2010 kl. 23.06 skrev "Jakob Schlyter" : > regarding http://trac.opendnssec.org/ticket/105, I really like the -- > with-database-backend={sqlite3,mysql} approach. should we do that? > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From rickard.bellgrim at iis.se Thu Mar 11 08:43:43 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 11 Mar 2010 09:43:43 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> Message-ID: <31627039-D8A0-488A-BEB3-BADD065CCF1B@iis.se> On 10 mar 2010, at 16.45, Jakob Schlyter wrote: > Anyway, we need to fix this - both for 1.1 and for 1.0. and make sure it is properly documented. We decided that we should not do a 1.0.1 // Rickard From rickard.bellgrim at iis.se Thu Mar 11 08:49:31 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 11 Mar 2010 09:49:31 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> Message-ID: <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> On 10 mar 2010, at 23.15, Jakob Schlyter wrote: >> Does the same thing apply to the inception offset? > > the effective inception seems to be calculated as the the current timestamp - inception offset. > as far as I can see, no other checks are made. What I mean is that currently we do this: Inception = now - offset Expiration = now + validity period + jitter Total validity = offset + validity period + jitter You are suggesting: Inception = now - offset Expiration = now + validity period - jitter Total validity = offset + validity period - jitter But if we want to truly use the validity period as the maximum, then do this: Inception = now - offset Expiration = now + validity period - jitter - offset Total validity = validity period - jitter // Rickard From jakob at kirei.se Thu Mar 11 09:09:37 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Mar 2010 10:09:37 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> Message-ID: <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> On 11 mar 2010, at 09.49, Rickard Bellgrim wrote: > What I mean is that currently we do this: > > Inception = now - offset > Expiration = now + validity period + jitter > Total validity = offset + validity period + jitter correct. > You are suggesting: > > Inception = now - offset > Expiration = now + validity period - jitter > Total validity = offset + validity period - jitter right, and this gives: min(total validity) = offset + validity period - max(jitter) max(total validity) = offset + validity period so signatures will effectivly expire between now + validity - max(jitter) and now + validity > But if we want to truly use the validity period as the maximum, then do this: > > Inception = now - offset > Expiration = now + validity period - jitter - offset > Total validity = validity period - jitter the offset is a safe guard against time error, so I would not include that in the the calculation of the signature expiration. jakob From matthijs at NLnetLabs.nl Thu Mar 11 09:39:55 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 11 Mar 2010 10:39:55 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> Message-ID: <4B98BA6B.8070400@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am not too happy about decreasing the validity period with jitter, instead of increasing it. This might allow people to shoot in their own foot (by configuring stupid values for signature validity and jitter). I understand that we want to avoid confusion and thus would like to have the same behavior as other DNSSEC implementations. I don't like the reasoning "because Bind does it". Matthijs Jakob Schlyter wrote: > On 11 mar 2010, at 09.49, Rickard Bellgrim wrote: > >> What I mean is that currently we do this: >> >> Inception = now - offset >> Expiration = now + validity period + jitter >> Total validity = offset + validity period + jitter > > correct. > > >> You are suggesting: >> >> Inception = now - offset >> Expiration = now + validity period - jitter >> Total validity = offset + validity period - jitter > > right, and this gives: > > min(total validity) = offset + validity period - max(jitter) > max(total validity) = offset + validity period > > so signatures will effectivly expire between > now + validity - max(jitter) > and > now + validity > > >> But if we want to truly use the validity period as the maximum, then do this: >> >> Inception = now - offset >> Expiration = now + validity period - jitter - offset >> Total validity = validity period - jitter > > the offset is a safe guard against time error, so I would not include that in the the calculation of the signature expiration. > > > jakob > > _______________________________________________ > 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLmLppAAoJEA8yVCPsQCW5dQ8IANiBBVw9oP7+pLeWT+88k14c BaFQS98+q0X6tq4gJewM7lEQL8o/6FhyluacMM8vJFJCo37dsqENK93EjRzPt58Q aKoLbA2oMobAJxx8vIZ5bDIlAwALHJoNgVQ5WsbnDOmaZcNyPH9OIqZE333KAlOK nyR/fmBjMjynqpd436tdSGk9inqOs9Jo+uCUSsuEFrlBaiGqFUkfCc1si9dl2/MF V7d1XrGPWLjOeH0xBBpzCLMMXuXV4oM1SRM9zg9Uan72mL2Ue0uAFoNmbRkGNV5m /0hWr9LYb0BHfdRXTYRdbQQPCN33Vgn2mFY2e/geagYYC6f6avXAYlxpDoNR81E= =8w95 -----END PGP SIGNATURE----- From jakob at kirei.se Thu Mar 11 09:42:36 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Mar 2010 10:42:36 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <4B98BA6B.8070400@nlnetlabs.nl> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> <4B98BA6B.8070400@nlnetlabs.nl> Message-ID: On 11 mar 2010, at 10.39, Matthijs Mekking wrote: > I am not too happy about decreasing the validity period with jitter, > instead of increasing it. This might allow people to shoot in their own > foot (by configuring stupid values for signature validity and jitter). this question is if we want to say "the validity period is no longer than X" or "the validity period is at least Y". I kind of like my 3rd jitter semantics, i.e. jitter AROUND the validity period - but I understand may just confuse people even more. jakob From jakob at kirei.se Thu Mar 11 10:30:35 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Mar 2010 11:30:35 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> <4B98BA6B.8070400@nlnetlabs.nl> Message-ID: <5109F95B-F051-45F6-B347-3BE6A14EA543@kirei.se> after some discussion with my colleague, I suggest we change the implementation to do jitter as it should have been done in the first place (and how jitter is actually defined): expiration' = expiration - jitter + (rnd % (jitter * 2)) i.e., the jitter is the absolute maximum expiration variance. giving: - max(effective validity) = offset + expiration + jitter/2 - min(effective validity) = offset + expiration - jitter/2 jakob From Stephen.Morris at nominet.org.uk Thu Mar 11 10:38:21 2010 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Thu, 11 Mar 2010 10:38:21 +0000 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> <4B98BA6B.8070400@nlnetlabs.nl> Message-ID: Jakob Schlyter wrote on 11/03/2010 09:42:36: > On 11 mar 2010, at 10.39, Matthijs Mekking wrote: > > > I am not too happy about decreasing the validity period with jitter, > > instead of increasing it. This might allow people to shoot in their own > > foot (by configuring stupid values for signature validity and jitter). People will always be able to configure stupid values. We can mitigate that in several ways: * providing something that people can run to check the parameters (e.g. ods-kaspcheck) * providing a parameter editor (even if it just links something like "vi" with the check program, i.e. something like "crontab -e") * hard-code limits e.g. jitter must always be <= 20% of the validity period ... but ultimately it's down to the user. We can only do so much. > I kind of like my 3rd jitter semantics, i.e. jitter AROUND the validity period > - but I understand may just confuse people even more. I would have thought that's the most logical and least confusing description - a signature's validity period will lie in the interval (defined validity period +/- jitter). The only thing we would need to make clear is that there is a uniform distribution of validity periods in this interval, not a normal distribution. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Thu Mar 11 11:07:39 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 11 Mar 2010 12:07:39 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> <4B98BA6B.8070400@nlnetlabs.nl> Message-ID: <01C6B3DD-173C-4150-A98E-DEE4467B2A9A@iis.se> People will always be able to configure stupid values. We can mitigate that in several ways: ... but ultimately it's down to the user. We can only do so much. I agree. There are many ways of screwing up the configuration. We do have the ods-kaspcheck, that we need to revisit in the future. And see how it can be used. > I kind of like my 3rd jitter semantics, i.e. jitter AROUND the validity period > - but I understand may just confuse people even more. I would have thought that's the most logical and least confusing description - a signature's validity period will lie in the interval (defined validity period +/- jitter). The only thing we would need to make clear is that there is a uniform distribution of validity periods in this interval, not a normal distribution. Ok, so lets go with +/- jitter/2. I think it should just be a one-liner in the Signer. We also need to update the picture in the documentation. The Auditor should be fine with this as well, right? Or does it check that the validity period of the signature is within limits of the KASP. If so, then it also needs to be updated. // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Thu Mar 11 11:10:28 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Mar 2010 12:10:28 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <01C6B3DD-173C-4150-A98E-DEE4467B2A9A@iis.se> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> <4B98BA6B.8070400@nlnetlabs.nl> <01C6B3DD-173C-4150-A98E-DEE4467B2A9A@iis.se> Message-ID: <3B8C9D69-CBBD-4AEC-83C0-AFAB7F393964@kirei.se> On 11 mar 2010, at 12.07, Rickard Bellgrim wrote: > Ok, so lets go with +/- jitter/2. I think it should just be a one-liner in the Signer. We also need to update the picture in the documentation. actually it is: expiration' = expiration - jitter + (rnd % (jitter * 2)) stories added and assigned. jakob From patrik.wallstrom at iis.se Thu Mar 11 12:50:47 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Thu, 11 Mar 2010 13:50:47 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <3B8C9D69-CBBD-4AEC-83C0-AFAB7F393964@kirei.se> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> <4B98BA6B.8070400@nlnetlabs.nl> <01C6B3DD-173C-4150-A98E-DEE4467B2A9A@iis.se> <3B8C9D69-CBBD-4AEC-83C0-AFAB7F393964@kirei.se> Message-ID: On Mar 11, 2010, at 12:10 PM, Jakob Schlyter wrote: > On 11 mar 2010, at 12.07, Rickard Bellgrim wrote: > >> Ok, so lets go with +/- jitter/2. I think it should just be a one-liner in the Signer. We also need to update the picture in the documentation. > > actually it is: expiration' = expiration - jitter + (rnd % (jitter * 2)) > > stories added and assigned. I like the jitter parameter much better now, with this solution. Can we convince ISC to change jitter to this as well? -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jelte at isc.org Thu Mar 11 13:27:14 2010 From: jelte at isc.org (Jelte Jansen) Date: Thu, 11 Mar 2010 14:27:14 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> <4B98BA6B.8070400@nlnetlabs.nl> <01C6B3DD-173C-4150-A98E-DEE4467B2A9A@iis.se> <3B8C9D69-CBBD-4AEC-83C0-AFAB7F393964@kirei.se> Message-ID: <4B98EFB2.7060808@isc.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/11/2010 01:50 PM, Patrik Wallstr?m wrote: > > On Mar 11, 2010, at 12:10 PM, Jakob Schlyter wrote: > >> On 11 mar 2010, at 12.07, Rickard Bellgrim wrote: >> >>> Ok, so lets go with +/- jitter/2. I think it should just be a one-liner in the Signer. We also need to update the picture in the documentation. >> >> actually it is: expiration' = expiration - jitter + (rnd % (jitter * 2)) >> >> stories added and assigned. > > I like the jitter parameter much better now, with this solution. Can we convince ISC to change jitter to this as well? > hey looky, i'm still on this list :) I personally think that +-jitter/2 is the worst pick of the three, it gives you the disadvantage of both +jitter and -jitter obviously i prefer +jitter since i wrote that line :p (less room for fatal error, i think longer expiration than expected contains less potential problems than shorter expiration than expected) of course the setting for any of these choices can be directly translated into any other by modifying your validity time accordingly, and hence it mostly comes down to correct documentation, and perhaps a big fat error&fail if there is a potential problem. i do agree that it would be nice to sync this up between implementations, though i'm not entirely sure how willing the bind9 team is to change an existing definition Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuY77IACgkQ4nZCKsdOncUfqwCglXQSCpRvHjDEJo8Te66mdZ/v cwcAn0IPzosGRMCnuEcqmp961YGan0ZB =o1q0 -----END PGP SIGNATURE----- From jakob at kirei.se Thu Mar 11 13:29:50 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Mar 2010 14:29:50 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <4B98EFB2.7060808@isc.org> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> <4B98BA6B.8070400@nlnetlabs.nl> <01C6B3DD-173C-4150-A98E-DEE4467B2A9A@iis.se> <3B8C9D69-CBBD-4AEC-83C0-AFAB7F393964@kirei.se> <4B98EFB2.7060808@isc.org> Message-ID: <931DAF44-4688-468E-A2A7-533539F03EC6@kirei.se> On 11 mar 2010, at 14.27, Jelte Jansen wrote: > i do agree that it would be nice to sync this up between > implementations, though i'm not entirely sure how willing the bind9 team > is to change an existing definition hey, I wrote that code for bind9 - don't I have a say in this? :-) jakob From matthijs at NLnetLabs.nl Thu Mar 11 13:31:15 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 11 Mar 2010 14:31:15 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <4B98EFB2.7060808@isc.org> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> <4B98BA6B.8070400@nlnetlabs.nl> <01C6B3DD-173C-4150-A98E-DEE4467B2A9A@iis.se> <3B8C9D69-CBBD-4AEC-83C0-AFAB7F393964@kirei.se> <4B98EFB2.7060808@isc.org> Message-ID: <4B98F0A3.2050409@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jelte Jansen wrote: > obviously i prefer +jitter since i wrote that line :p (less room for > fatal error, i think longer expiration than expected contains less > potential problems than shorter expiration than expected) +1 fwiw (shooting foot issue) Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLmPChAAoJEA8yVCPsQCW511EIAIqGW+Ur4cLPXUsnzSG6BjkE vSG8rBkEwNzrXnHvZExSQ6cMlb8Y+gw4vgjgHqaUfPzytUBbLCwV0/IUqnuMYtLp tUnwVxss7rS+sAWWlPuRgVMPGckATdoEBaYYm/o523EzmusKxGVATURYIGBMWtJj MW0lV8SBlWx/wjYA5wOJNWF0qBexVv8hTE7cw0gUt0hdqkcln3nawkEStxuYJ5JS SHju7LUUYca4o2KYFbDaA4VzsMiZpceKCeolIgLYQF2QJ37+5WIoY5OXrSBKgYA6 fbaQQ1R0wRKjhbah2wGwnfR0r1MLI3rvWndb9TLE5JLDAATP5wdZjpSVkdL8P2c= =kV+8 -----END PGP SIGNATURE----- From jakob at kirei.se Thu Mar 11 13:33:01 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Mar 2010 14:33:01 +0100 Subject: [Opendnssec-develop] Erroneous jitter semantics In-Reply-To: <4B98EFB2.7060808@isc.org> References: <50806474-E14C-4259-8E54-F47EC6465379@kirei.se> <7AB05D35-F803-4419-A443-65BAE3BBA357@kirei.se> <340D31A9-5C88-4763-A514-B826B3BEA463@iis.se> <6701D02E-E7C4-4E13-ABC9-473C36A0F747@kirei.se> <4B98BA6B.8070400@nlnetlabs.nl> <01C6B3DD-173C-4150-A98E-DEE4467B2A9A@iis.se> <3B8C9D69-CBBD-4AEC-83C0-AFAB7F393964@kirei.se> <4B98EFB2.7060808@isc.org> Message-ID: <27CC51D6-9C1D-4B5E-815C-695C92DD38FB@kirei.se> jittering on one only one side of the mean value has always problems and this gives us a bit of both. if you don't want jitter, don't do it. but if you want to jitter - it should be very clear what we do. j From matthijs at NLnetLabs.nl Thu Mar 11 14:57:23 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 11 Mar 2010 15:57:23 +0100 Subject: [Opendnssec-develop] Meeting notes 2010-03-10 In-Reply-To: <20100310152529.GA1852@phantom.vanrein.org> References: <20100310152529.GA1852@phantom.vanrein.org> Message-ID: <4B9904D3.7020806@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rick van Rein wrote: > Hello, > > I published the meeting notes of 2010-2-24. Shouldn't that be 2010-03-10? I don't see them on the wiki (I do see 2010-02-24). Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLmQTRAAoJEA8yVCPsQCW5KIYH/jbMMj4uVWeRuPL470pzLcdO jwDE5adCqTFf710EWlETdBj8rv3uWbHUNJtWk5v6x7mSM8NsRSMDSVr8vg6a0Ujd oEpUK1wboC8wnzCu+RC7bO5849s8avPx3PxC1m/qi9s+I33g6NEdfWm+TO2HcJnh PjB+6BA5uAl7Zdts3vf49a78alSmjgsrgU7DEcINs94Ukw08nYtKa43g1V1uwPmo OTAj7PNXW8q+2n/08L1zn9bIwCPCLEnXiiBFdFfOAx5fpNrF2v+irmR9EUQRywUL ZGitrkWkYlDgqEZXeOg2f9iXtvuTgU5tJnpzIQddxx4FvrxOkpbP3Xk0W6akEs0= =W+CJ -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Mar 11 15:44:37 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Mar 2010 15:44:37 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #105: ./configure support for --disable-sqlite3 In-Reply-To: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> References: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> Message-ID: <064.7a765922aa14b7108ddf7ec97619dd14@kirei.se> #105: ./configure support for --disable-sqlite3 ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: jakob Type: enhancement | Status: assigned Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- Changes (by jakob): * owner: rb => jakob * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Mar 11 15:44:56 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Mar 2010 15:44:56 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #105: ./configure support for --disable-sqlite3 In-Reply-To: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> References: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> Message-ID: <064.7da1a3403de1f47d782d5bc6d28efe46@kirei.se> #105: ./configure support for --disable-sqlite3 ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: jakob Type: enhancement | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by jakob): * status: assigned => closed * resolution: => fixed Comment: --with-database-backend={sqlite3|mysql} implemented in r3018. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at openfortress.nl Thu Mar 11 16:31:38 2010 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 11 Mar 2010 16:31:38 +0000 Subject: [Opendnssec-develop] Meeting notes 2010-03-10 In-Reply-To: <4B9904D3.7020806@nlnetlabs.nl> References: <20100310152529.GA1852@phantom.vanrein.org> <4B9904D3.7020806@nlnetlabs.nl> Message-ID: <20100311163138.GC31501@phantom.vanrein.org> Hi, > > I published the meeting notes of 2010-2-24. > > Shouldn't that be 2010-03-10? Of course. I wanted to edit it after sending, but some application named "SMTP" claimed that transactions are final, once committed. > I don't see them on the wiki (I do see 2010-02-24). Careless me! Forgot to add it to the list of meeting notes. Fixed. -Rick From rickard.bellgrim at iis.se Thu Mar 11 20:44:34 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 11 Mar 2010 21:44:34 +0100 Subject: [Opendnssec-develop] New zone reader In-Reply-To: <4B7A7AE5.8040303@nlnetlabs.nl> References: <4B7A7AE5.8040303@nlnetlabs.nl> Message-ID: <3A46A74E-BC70-4944-8D02-8E1EF60AD620@iis.se> > I would be grateful if you could test it. It works great with the .se-zone. I get around 11000 rows in the optout-file. This looks ok, since we have around that number of glue for the nameserver. We have more nameserver, but they serve under other TLDs. // Rickard From jakob at kirei.se Thu Mar 11 22:06:41 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Mar 2010 23:06:41 +0100 Subject: [Opendnssec-develop] --with-database-backend={sqlite3,mysql} In-Reply-To: <10254CC3-768D-427D-A992-C6FC581CCB21@iis.se> References: <75F07467-9D65-410B-82F8-09DC6472F201@kirei.se> <10254CC3-768D-427D-A992-C6FC581CCB21@iis.se> Message-ID: <2FAC8DC9-1E6B-40EF-ACE6-E4AE09FBDDCC@kirei.se> On 10 mar 2010, at 23.46, Rickard Bellgrim wrote: > +1 implemented in r3015 and r3018 - http://trac.opendnssec.org/changeset/3018 - http://trac.opendnssec.org/changeset/3015 j From rickard.bellgrim at iis.se Thu Mar 11 22:20:22 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 11 Mar 2010 23:20:22 +0100 Subject: [Opendnssec-develop] Auditor performance Message-ID: <9E101791-739D-4DAD-A193-CD0FE5D35683@iis.se> Hi I have now compared the old auditor with the new partial auditor. rickardb at dnssecsigner:/var/opendnssec$ time sudo ods-auditor Auditor started Auditor starting on se 6: Auditing se zone : NSEC SIGNED 6: Finished auditing se zone Auditor found no errors real 58m30.846s user 59m39.910s sys 2m55.800s rickardb at dnssecsigner:/var/opendnssec$ time sudo ods-auditor Auditor started Auditor starting on se 6: Auditing se zone : NSEC SIGNED 6: Finished auditing se zone Auditor found no errors real 4m29.920s user 5m1.950s sys 0m8.850s >From 59 minutes to 5 minutes. Great work! Is it possible to have some documentation in the user guide to show what the difference is between the two options? E.g. what tests you have and not have. // Rickard From owner-dnssec-trac at kirei.se Thu Mar 11 22:25:25 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Mar 2010 22:25:25 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #26: Signer (or communicated) gets very slow with many zones In-Reply-To: <043.3e06d24187eff497c818ae327e7a67e4@kirei.se> References: <043.3e06d24187eff497c818ae327e7a67e4@kirei.se> Message-ID: <052.76334e636ea79cee37147ddc6650f3dd@kirei.se> #26: Signer (or communicated) gets very slow with many zones -------------------+-------------------------------------------------------- Reporter: pawal | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: | Keywords: -------------------+-------------------------------------------------------- Comment(by rb): We loop through the data in the database. -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Fri Mar 12 07:21:35 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Fri, 12 Mar 2010 07:21:35 +0000 Subject: [Opendnssec-develop] Auditor performance In-Reply-To: <9E101791-739D-4DAD-A193-CD0FE5D35683@iis.se> References: <9E101791-739D-4DAD-A193-CD0FE5D35683@iis.se> Message-ID: > Is it possible to have some documentation in the user guide to show > what the difference is between the two options? E.g. what tests you > have and not have. Yes. This currently exists in the wiki. I'll add some documentation to the deliverable as well. Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Fri Mar 12 08:16:20 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 12 Mar 2010 09:16:20 +0100 Subject: [Opendnssec-develop] --with-database-backend={sqlite3,mysql} In-Reply-To: <2FAC8DC9-1E6B-40EF-ACE6-E4AE09FBDDCC@kirei.se> References: <75F07467-9D65-410B-82F8-09DC6472F201@kirei.se> <10254CC3-768D-427D-A992-C6FC581CCB21@iis.se> <2FAC8DC9-1E6B-40EF-ACE6-E4AE09FBDDCC@kirei.se> Message-ID: <845FF32F-F91A-451F-A40C-6207F94D1000@iis.se> On 11 mar 2010, at 23.06, Jakob Schlyter wrote: > implemented in r3015 and r3018 > - http://trac.opendnssec.org/changeset/3018 > - http://trac.opendnssec.org/changeset/3015 It works and the documentation is updated to reflect the change. // Rickard From matthijs at NLnetLabs.nl Fri Mar 12 08:40:45 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 12 Mar 2010 09:40:45 +0100 Subject: [Opendnssec-develop] Meeting notes 2010-03-10 In-Reply-To: <20100311163138.GC31501@phantom.vanrein.org> References: <20100310152529.GA1852@phantom.vanrein.org> <4B9904D3.7020806@nlnetlabs.nl> <20100311163138.GC31501@phantom.vanrein.org> Message-ID: <4B99FE0D.3030403@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks! Edited the notes: threaded finder -> threaded signer. Matthijs Rick van Rein wrote: > Hi, > >>> I published the meeting notes of 2010-2-24. >> Shouldn't that be 2010-03-10? > > Of course. I wanted to edit it after sending, but some application > named "SMTP" claimed that transactions are final, once committed. > >> I don't see them on the wiki (I do see 2010-02-24). > > Careless me! Forgot to add it to the list of meeting notes. Fixed. > > -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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLmf4LAAoJEA8yVCPsQCW5BqgIAJahbU50Jr1W5B6TBNWFLVKW PMnf23wGpXLBslYbjglY6imNbQnRfa2ZPBZOPYg+TxRu59CcuDLtQWOBn4crA5qA PYTjaJJ4xnm+Wk6EAzfW6hTRfsKRdhke3cMIhs5wu6sh8rZk1uy4cyTXm4aYX5Hj RTl1Gco2ddaSaJMIwpfoZ9PmOYAG3d5xC5JkhUis4WyTxojHvdLilKB8wrHYKWm9 r7h7pl7McDrz0uEFv8HI2ymlXBT9rR2t/VtF01ZiGfgEGWarRA84Fdc6LOa1inMK xg/52JK4oOf2GOplclvAjcCHY1Fpr/5DyWtgxNE8efkYlxjbLMigyjXAuJE2/H0= =yaic -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Fri Mar 12 13:58:39 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 12 Mar 2010 13:58:39 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #109: ods-ksmutil key import does not allow RSASHA1 Message-ID: <063.382044f4c2e736cba45426ef528d9320@kirei.se> #109: ods-ksmutil key import does not allow RSASHA1 --------------------------------------+------------------------------------- Reporter: jaroslav.benkovsky@? | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: 1.0.0 | Keywords: --------------------------------------+------------------------------------- I use version 1.0.0, with Sun sca6000 HSM. {{{ # ods-ksmutil key import --cka_id 59cf3f08f5e9b1f9bc5156602eed4080 -r sca6000 -z cz -b 1024 -g RSASHA1 --keystate generated --keytype ZSK --time '2010-03-12 14:00:00' SQLite database set to: /var/opendnssec/kasp.db Error: Key algorithm RSASHA1 not supported; try one of RSASHA1, RSASHA1-NSEC3-SHA1 or RSASHA256 }}} The reason seems to be that there are methods rsasha1 and rsasha1-nsec3-sha1 in keywords and the logic of StrKeywordSearch ensures that search for rsasha1 only returns an error. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Mar 12 14:25:49 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 12 Mar 2010 14:25:49 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #110: ods-ksmutilkey import puts binary garbage to database Message-ID: <063.f5c224b381179530f0a6683dc914ec06@kirei.se> #110: ods-ksmutilkey import puts binary garbage to database --------------------------------------+------------------------------------- Reporter: jaroslav.benkovsky@? | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: 1.0.0 | Keywords: --------------------------------------+------------------------------------- I have imported key with {{{ ods-ksmutil key import --cka_id 59cf3f08f5e9b1f9bc5156602eed4080 -r sca6000 -z cz -b 1024 -g RSASHA256 --keystate generated --keytype ZSK --time '2010-03-12 14:00:00' }}} Now the record in the database contains some garbage in keypairs.retire field -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Fri Mar 12 15:12:30 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 12 Mar 2010 16:12:30 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY Message-ID: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> so, as some of you have noticed Patrik and I decided to add a parameter for specifying a separate validity for signatures over DNSKEY. I've implemented this in the signer, but the enforcer and auditor needs more work. matthijs; please review my signer changes. jakob From owner-dnssec-trac at kirei.se Fri Mar 12 15:50:29 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 12 Mar 2010 15:50:29 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #111: Missing sanity check in hsm_get_dnskey() Message-ID: <063.736ed46d6fc3275c8d248b3afb6e5f47@kirei.se> #111: Missing sanity check in hsm_get_dnskey() --------------------------------------+------------------------------------- Reporter: jaroslav.benkovsky@? | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: 1.0.0 | Keywords: --------------------------------------+------------------------------------- If a HSM has a private key but not a public key, and the key was imported with ods-ksmutil key import, ods-ksmutil key list -verbose propagates error to ldns where it aborts with a meaningless assert: {{{ # ods-ksmutil key list --verbose SQLite database set to: /var/opendnssec/kasp.db Keys: Zone: Keytype: State: Date of next transition: CKA_ID: Repository: Keytag: .... ods-ksmutil: rdata.c:26: ldns_rdf_size: Assertion `rd != ((void *)0)' failed. cz ZSK publish 2010-03-13 04:00:00 Aborted }}} One culprit is in hsm_get_dnskey() in libhsm, as it does not check return code from hsm_get_key_rdata(). {{{ 2301 ldns_rr_push_rdf(dnskey, hsm_get_key_rdata(ctx, session, key)); }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Fri Mar 12 16:49:38 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 12 Mar 2010 17:49:38 +0100 Subject: [Opendnssec-develop] Problem importing keys to SCA6K Message-ID: Hi I managed to link the softhsm tool with SCA6K library, with some modifications. I did this because I wanted to import a key pair using the CreateObject functionality in PKCS#11. And I did not want to spend time on writing a separate program. I was able to import the key pair, but there are some problems with the SCA6K card. It does not set the CKA_MODULUS_BITS, which is used by ods-hsmutil. It thus show RSA/0 and not RSA/1024. According to PKCS#11, this attribute must not be used when creating an object, but should be added by the HSM itself. It do work if the user do provide this attribute in the template. But when I start to sign with this key I get "WARNING: HSM returned BOGUS signature! Abort signing, retry on next resign". The import functionality do work on SoftHSM. So something is seriously broken in the SCA6000 card. // Rickard From owner-dnssec-trac at kirei.se Mon Mar 15 07:04:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 15 Mar 2010 07:04:08 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #104: Linking conf.xml to softhsm pkcs#11 lib on mac In-Reply-To: <043.c7d913a6b74d94cd59e500d185fc64e2@kirei.se> References: <043.c7d913a6b74d94cd59e500d185fc64e2@kirei.se> Message-ID: <052.f2340acd04a4c1da0dfb35691788d926@kirei.se> #104: Linking conf.xml to softhsm pkcs#11 lib on mac ------------------------+--------------------------------------------------- Reporter: pawal | Owner: jakob Type: enhancement | Status: closed Priority: minor | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by jakob): * status: assigned => closed * resolution: => fixed Comment: MacOSX .dylib is a shared library, not a loadable module. It turns out that we where missing some options to libtool and I hope I've managed to fix this in r3011 and r3012. Please restest. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 15 07:12:15 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 15 Mar 2010 07:12:15 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #90: Extra symbols in libhsm In-Reply-To: <065.d9f2da5f94fdaf6c8aa6909b7138e9ae@kirei.se> References: <065.d9f2da5f94fdaf6c8aa6909b7138e9ae@kirei.se> Message-ID: <074.8c9cbc439b162a8d6988bca53109121b@kirei.se> #90: Extra symbols in libhsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: closed Priority: minor | Component: libhsm Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by jakob): * status: assigned => closed * resolution: => fixed Comment: Patch applied in r3046. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 15 09:49:54 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 15 Mar 2010 09:49:54 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #110: ods-ksmutilkey import puts binary garbage to database In-Reply-To: <063.f5c224b381179530f0a6683dc914ec06@kirei.se> References: <063.f5c224b381179530f0a6683dc914ec06@kirei.se> Message-ID: <072.231162dbef9be7f7bb65ccff47d75817@kirei.se> #110: ods-ksmutilkey import puts binary garbage to database --------------------------------------+------------------------------------- Reporter: jaroslav.benkovsky@? | Owner: sion Type: defect | Status: closed Priority: minor | Component: Enforcer Version: 1.0.0 | Resolution: duplicate Keywords: | --------------------------------------+------------------------------------- Changes (by sion): * status: new => closed * resolution: => duplicate Comment: This is the same as ticket #108 and is fixed in trunk (svn r2983) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 15 10:00:35 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 15 Mar 2010 10:00:35 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #109: ods-ksmutil key import does not allow RSASHA1 In-Reply-To: <063.382044f4c2e736cba45426ef528d9320@kirei.se> References: <063.382044f4c2e736cba45426ef528d9320@kirei.se> Message-ID: <072.44c86c4af2962507a66bcd87fdd04c70@kirei.se> #109: ods-ksmutil key import does not allow RSASHA1 --------------------------------------+------------------------------------- Reporter: jaroslav.benkovsky@? | Owner: sion Type: defect | Status: closed Priority: major | Component: Enforcer Version: 1.0.0 | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Changes (by sion): * status: new => closed * resolution: => fixed Comment: Thank you. I have patched trunk to stop this from happening. In the mean-time you can also specify the algorithm by its numeric value, which will get you running hopefully. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon Mar 15 10:04:36 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Mar 2010 11:04:36 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> Message-ID: What about the refresh-tag? This simple change, now implies a lot of changes. Just before a release.... On 12 mar 2010, at 16.12, Jakob Schlyter wrote: > so, as some of you have noticed Patrik and I decided to add a parameter for specifying a separate validity for signatures over DNSKEY. I've implemented this in the signer, but the enforcer and auditor needs more work. > > matthijs; please review my signer changes. > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From jakob at kirei.se Mon Mar 15 10:08:44 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 15 Mar 2010 11:08:44 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> Message-ID: <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> On 15 mar 2010, at 11.04, Rickard Bellgrim wrote: > What about the refresh-tag? the refresh tag doesn't matter - it was an internal signer setting that has been taken care of. > This simple change, now implies a lot of changes. Just before a release.... yup. we better test it then - that's why we have a feature freeze this week, and release later. j From matthijs at NLnetLabs.nl Mon Mar 15 10:08:34 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 15 Mar 2010 11:08:34 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> Message-ID: <4B9E0722.60904@nlnetlabs.nl> There is no specific refresh tag for Denial as well. To calculate the refresh time for Keys, it's basically a copy code of the refresh_denial, same behavior. Matthijs Rickard Bellgrim wrote: > What about the refresh-tag? > > This simple change, now implies a lot of changes. Just before a release.... > > On 12 mar 2010, at 16.12, Jakob Schlyter wrote: > >> so, as some of you have noticed Patrik and I decided to add a parameter for specifying a separate validity for signatures over DNSKEY. I've implemented this in the signer, but the enforcer and auditor needs more work. >> >> matthijs; please review my signer changes. >> >> jakob >> >> _______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From rickard.bellgrim at iis.se Mon Mar 15 10:20:40 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Mar 2010 11:20:40 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> Message-ID: <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> On 15 mar 2010, at 11.08, Jakob Schlyter wrote: > On 15 mar 2010, at 11.04, Rickard Bellgrim wrote: > >> What about the refresh-tag? > > the refresh tag doesn't matter - it was an internal signer setting that has been taken care of. You probably do not want to share the refresh interval between the ZSK and KSK, if you are splitting the validity. E.g.: KSK - validity 30 days. ZSK - validity 7 days. Refresh KSK RRSIG when it is 15 days until it expires. Refresh ZSK RRSIG when it is 4 days until it expires. // Rickard From jakob at kirei.se Mon Mar 15 10:22:47 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 15 Mar 2010 11:22:47 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> Message-ID: <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> On 15 mar 2010, at 11.20, Rickard Bellgrim wrote: > On 15 mar 2010, at 11.08, Jakob Schlyter wrote: > >> On 15 mar 2010, at 11.04, Rickard Bellgrim wrote: >> >>> What about the refresh-tag? >> >> the refresh tag doesn't matter - it was an internal signer setting that has been taken care of. > > You probably do not want to share the refresh interval between the ZSK and KSK, if you are splitting the validity. > > E.g.: > > KSK - validity 30 days. > ZSK - validity 7 days. > > Refresh KSK RRSIG when it is 15 days until it expires. > Refresh ZSK RRSIG when it is 4 days until it expires. when we support offline KSK this may be interesting, but as of now when we require the KSK to be online it really doesn't matter. jakob From matthijs at NLnetLabs.nl Mon Mar 15 10:24:31 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 15 Mar 2010 11:24:31 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> Message-ID: <4B9E0ADF.6030602@nlnetlabs.nl> Rickard Bellgrim wrote: > Refresh KSK RRSIG when it is 15 days until it expires. > Refresh ZSK RRSIG when it is 4 days until it expires. What is a KSK RRSIG? What is a ZSK RRSIG? I do know of a RRSIG record that covers the type DNSKEY... Matthijs From jakob at kirei.se Mon Mar 15 10:25:32 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 15 Mar 2010 11:25:32 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <4B9E0ADF.6030602@nlnetlabs.nl> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <4B9E0ADF.6030602@nlnetlabs.nl> Message-ID: On 15 mar 2010, at 11.24, Matthijs Mekking wrote: > Rickard Bellgrim wrote: >> Refresh KSK RRSIG when it is 15 days until it expires. >> Refresh ZSK RRSIG when it is 4 days until it expires. > > What is a KSK RRSIG? What is a ZSK RRSIG? > > I do know of a RRSIG record that covers the type DNSKEY... I take it Rickard mean a RRSIG over DNSKEY (by KSK) or RRSIG over anything-else (by ZSK). j From rickard.bellgrim at iis.se Mon Mar 15 10:29:20 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Mar 2010 11:29:20 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <4B9E0ADF.6030602@nlnetlabs.nl> Message-ID: <68511D7F-7231-4F52-BA02-64A70D5C9977@iis.se> I take it Rickard mean a RRSIG over DNSKEY (by KSK) or RRSIG over anything-else (by ZSK). Yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Mon Mar 15 10:32:15 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Mar 2010 11:32:15 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> Message-ID: <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> >> You probably do not want to share the refresh interval between the ZSK and KSK, if you are splitting the validity. >> >> E.g.: >> >> KSK - validity 30 days. >> ZSK - validity 7 days. >> >> Refresh KSK RRSIG when it is 15 days until it expires. >> Refresh ZSK RRSIG when it is 4 days until it expires. > > when we support offline KSK this may be interesting, but as of now when we require the KSK to be online it really doesn't matter. So what is the idea of separating the validity period, if you cannot guarantee a higher minimum validity, which is determined by the refresh period. I my example, you can set the refresh to 15 days, but the you will always create new signatures with the ZSK. // Rickard From matthijs at NLnetLabs.nl Mon Mar 15 10:35:32 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 15 Mar 2010 11:35:32 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <4B9E0ADF.6030602@nlnetlabs.nl> Message-ID: <4B9E0D74.7010609@nlnetlabs.nl> Makes more sense:) Added a pivotal story for this as a reminder. Matthijs Jakob Schlyter wrote: > On 15 mar 2010, at 11.24, Matthijs Mekking wrote: > >> Rickard Bellgrim wrote: >>> Refresh KSK RRSIG when it is 15 days until it expires. >>> Refresh ZSK RRSIG when it is 4 days until it expires. >> What is a KSK RRSIG? What is a ZSK RRSIG? >> >> I do know of a RRSIG record that covers the type DNSKEY... > > I take it Rickard mean a RRSIG over DNSKEY (by KSK) or RRSIG over anything-else (by ZSK). > > j > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From jakob at kirei.se Mon Mar 15 10:40:10 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 15 Mar 2010 11:40:10 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> Message-ID: <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> On 15 mar 2010, at 11.32, Rickard Bellgrim wrote: > >>> You probably do not want to share the refresh interval between the ZSK and KSK, if you are splitting the validity. >>> >>> E.g.: >>> >>> KSK - validity 30 days. >>> ZSK - validity 7 days. >>> >>> Refresh KSK RRSIG when it is 15 days until it expires. >>> Refresh ZSK RRSIG when it is 4 days until it expires. >> >> when we support offline KSK this may be interesting, but as of now when we require the KSK to be online it really doesn't matter. > > So what is the idea of separating the validity period, if you cannot guarantee a higher minimum validity, which is determined by the refresh period. the idea is if you put the KSK and the ZSK is separate repositories, you could handle a KSK loss easier if you have a longer signature validity by the KSK. in case of a KSK loss, you would increase the refresh and survive a bit longer. at least in theory. > I my example, you can set the refresh to 15 days, but the you will always create new signatures with the ZSK. which is not a problem. j From rickard.bellgrim at iis.se Mon Mar 15 10:48:57 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Mar 2010 11:48:57 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> Message-ID: <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> the idea is if you put the KSK and the ZSK is separate repositories, you could handle a KSK loss easier if you have a longer signature validity by the KSK. in case of a KSK loss, you would increase the refresh and survive a bit longer. at least in theory. Yes, so you do want to have the possibility to set a higher minimum validity period for the signatures over the DNSKEY RRset. But if you increase the refresh period, then this also affects the signatures from the ZSK. I my example, you can set the refresh to 15 days, but the you will always create new signatures with the ZSK. which is not a problem. It is, if you have a large zone. We do not want to create a complete new set of signatures every second hour. If we are going to do this for this release, then we should do it correctly from the beginning. And not patch it up for the next release. // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Mon Mar 15 10:55:22 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 15 Mar 2010 11:55:22 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> Message-ID: <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> On 15 mar 2010, at 11.48, Rickard Bellgrim wrote: >> >> the idea is if you put the KSK and the ZSK is separate repositories, you could handle a KSK loss easier if you have a longer signature validity by the KSK. in case of a KSK loss, you would increase the refresh and survive a bit longer. at least in theory. > > Yes, so you do want to have the possibility to set a higher minimum validity period for the signatures over the DNSKEY RRset. > > But if you increase the refresh period, then this also affects the signatures from the ZSK. but you would only increase the refresh when you've lost your KSK. I'm not saying this is the final way we want to do this, but this change would help for users that want to be able to recover from a lost KSK. with this change, they only have their normal validity and that's not long enough. jakob From rickard.bellgrim at iis.se Mon Mar 15 11:03:17 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Mar 2010 12:03:17 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> Message-ID: > but you would only increase the refresh when you've lost your KSK. I'm not saying this is the final way we want to do this, but this change would help for users that want to be able to recover from a lost KSK. with this change, they only have their normal validity and that's not long enough. Isn't already too late if you have lost your KSK? You cannot create a new signature with a higher validity if the KSK is lost. If we have the higher validity from the beginning, then you have more time to distribute the new trust anchor. To get this windows, you also have to increase the refresh period. // Rickard From jakob at kirei.se Mon Mar 15 11:10:10 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 15 Mar 2010 12:10:10 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> Message-ID: On 15 mar 2010, at 12.03, Rickard Bellgrim wrote: > >> but you would only increase the refresh when you've lost your KSK. I'm not saying this is the final way we want to do this, but this change would help for users that want to be able to recover from a lost KSK. with this change, they only have their normal validity and that's not long enough. > > Isn't already too late if you have lost your KSK? You cannot create a new signature with a higher validity if the KSK is lost. > > If we have the higher validity from the beginning, then you have more time to distribute the new trust anchor. To get this windows, you also have to increase the refresh period. no, you can have a high validity for the DNSKEY RRSIGs (by KSK) and a low refresh. if you loose your KSK, you can increase the refresh (remember, increasing refresh does not change existing sigs - it will just let them stay put longer). jakob From rickard.bellgrim at iis.se Mon Mar 15 12:04:17 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Mar 2010 13:04:17 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> Message-ID: >> Isn't already too late if you have lost your KSK? You cannot create a new signature with a higher validity if the KSK is lost. >> >> If we have the higher validity from the beginning, then you have more time to distribute the new trust anchor. To get this windows, you also have to increase the refresh period. > > no, you can have a high validity for the DNSKEY RRSIGs (by KSK) and a low refresh. if you loose your KSK, you can increase the refresh (remember, increasing refresh does not change existing sigs - it will just let them stay put longer). I wouldn't rely on the best case (validity period). I would rely on the worst case (refresh period). Lets say that you have 30 days validity and 4 days refresh. It is now 5 days until the signature expires and you loose your KSK. Raising the refresh period will not save you. It is still 5 days until the signature expires, the expire timestamp is already in the signature. You signatures are valid between 30 and 4 days into the future with this refresh period. You will reuse your signature up to that day. And if you loose your KSK just before we decide to refresh, than you cannot fix it with a higher refresh period. My conclusion: We must also have separate refresh period, so that you do not need to recreate the signatures from the ZSK all the time. Thus having the possibility to always have a high refresh period for the DNSKEY signatures. // Rickard From matthijs at NLnetLabs.nl Mon Mar 15 12:58:31 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 15 Mar 2010 13:58:31 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> Message-ID: <4B9E2EF7.6060903@nlnetlabs.nl> For the signer engine, it is not that hard to implement separate refresh for keys. If we are going to do this, I suggest this change in the kasp configuration: # the signatures are reused for a period of time # how long time before the expiration of the signature # should it be refreshed? - element Refresh { xsd:duration }, + element Refresh { + element Default { xsd:duration }, + element Keys { xsd:duration }? + }, Imo, it is cleaner than adding an element RefreshKeys. However, this is not compatible with the current kasp.rnc Matthijs Rickard Bellgrim wrote: >>> Isn't already too late if you have lost your KSK? You cannot create a new signature with a higher validity if the KSK is lost. >>> >>> If we have the higher validity from the beginning, then you have more time to distribute the new trust anchor. To get this windows, you also have to increase the refresh period. >> no, you can have a high validity for the DNSKEY RRSIGs (by KSK) and a low refresh. if you loose your KSK, you can increase the refresh (remember, increasing refresh does not change existing sigs - it will just let them stay put longer). > > I wouldn't rely on the best case (validity period). I would rely on the worst case (refresh period). > > Lets say that you have 30 days validity and 4 days refresh. It is now 5 days until the signature expires and you loose your KSK. Raising the refresh period will not save you. It is still 5 days until the signature expires, the expire timestamp is already in the signature. > > You signatures are valid between 30 and 4 days into the future with this refresh period. You will reuse your signature up to that day. And if you loose your KSK just before we decide to refresh, than you cannot fix it with a higher refresh period. > > My conclusion: We must also have separate refresh period, so that you do not need to recreate the signatures from the ZSK all the time. Thus having the possibility to always have a high refresh period for the DNSKEY signatures. > > // Rickard _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From owner-dnssec-trac at kirei.se Mon Mar 15 16:01:06 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 15 Mar 2010 16:01:06 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #112: ods-ksmutil calling 'killall' on Solaris Message-ID: <094.eb76492f0e486f4eda276cd5ad3e80b5@kirei.se> #112: ods-ksmutil calling 'killall' on Solaris ---------------------------------------------------------------------+------ Reporter: Thomas Egrelius | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: 1.0.0 | Keywords: ---------------------------------------------------------------------+------ When performing a key rollover with ods-ksmutil, 'killall -HUP ods- enforcerd' is called at the end. In Solaris, the killall command is not the correct choice as it is being used by shutdown to kill *all* processes on the system. On Solaris systems, '/usr/bin/pkill -HUP ods-enforcerd' should be used instead. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 15 21:29:17 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 15 Mar 2010 21:29:17 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #112: ods-ksmutil calling 'killall' on Solaris In-Reply-To: <094.eb76492f0e486f4eda276cd5ad3e80b5@kirei.se> References: <094.eb76492f0e486f4eda276cd5ad3e80b5@kirei.se> Message-ID: <103.25cbee3a21fef4891360de76cc3ae8f7@kirei.se> #112: ods-ksmutil calling 'killall' on Solaris ---------------------------------------------------------------------+------ Reporter: Thomas Egrelius | Owner: jakob Type: defect | Status: assigned Priority: minor | Component: Unknown Version: 1.0.0 | Keywords: ---------------------------------------------------------------------+------ Changes (by jakob): * owner: rb => jakob * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 15 21:33:02 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 15 Mar 2010 21:33:02 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #112: ods-ksmutil calling 'killall' on Solaris In-Reply-To: <094.eb76492f0e486f4eda276cd5ad3e80b5@kirei.se> References: <094.eb76492f0e486f4eda276cd5ad3e80b5@kirei.se> Message-ID: <103.066ffd4bef3d859b4016ec03f873f96d@kirei.se> #112: ods-ksmutil calling 'killall' on Solaris ---------------------------------------------------------------------+------ Reporter: Thomas Egrelius | Owner: jakob Type: defect | Status: closed Priority: minor | Component: Unknown Version: 1.0.0 | Resolution: fixed Keywords: | ---------------------------------------------------------------------+------ Changes (by jakob): * status: assigned => closed * resolution: => fixed Comment: Likely fixed in r3054 + r3055. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Mon Mar 15 21:38:32 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 15 Mar 2010 22:38:32 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <4B9E2EF7.6060903@nlnetlabs.nl> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> <4B9E2EF7.6060903@nlnetlabs.nl> Message-ID: On 15 mar 2010, at 13.58, Matthijs Mekking wrote: > For the signer engine, it is not that hard to implement separate refresh for keys. > > If we are going to do this, I suggest this change in the kasp configuration: > > # the signatures are reused for a period of time > # how long time before the expiration of the signature > # should it be refreshed? > - element Refresh { xsd:duration }, > + element Refresh { > + element Default { xsd:duration }, > + element Keys { xsd:duration }? > + }, > > Imo, it is cleaner than adding an element RefreshKeys. However, this is not compatible with the current kasp.rnc if we need this we should almost as above, but we can actually still be backwards compatible if we want to. jakob From sion at nominet.org.uk Tue Mar 16 11:50:50 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 16 Mar 2010 11:50:50 +0000 Subject: [Opendnssec-develop] Finally... KSK rollover Message-ID: I am about to check in the KSK rollover code. In this first iteration there is only one scheme (DoubleDNSKEY) and there is no setting to change this. The process is slightly different to how it appears in the documentation, it now looks something like: Scheduled Rollover: 1) Pre publish key in zone 2) when key is ready, prompt for DS to be submitted (currently a message to syslog) 3) wait for DS-Seen either 3a) old key retired in same command (--retire-current) or 4) ksk-retire used later Emergency rollover: 1) key rollover --keytype KSK issued; old key retired and marked as "compromised" 2a) if there is a key in the ready state use it or 2b) if there is a standby key waiting, publish it or 2c) publish a new key into the zone 3) when the successor key is ready (which might involve the DS publication / ds-seen stuff from above) complete the rollover. The new command "ods-ksmutil ksk-retire" takes the zone and optionally some key identifiers as arguments. If no key identifiers are supplied then it retires the oldest key in the zone. It will fail if there is only one active key though. The logic also now accounts for the first key in the zone, and does not request the DS record to be published until the child propagation period is over. I'll update the wiki documentation to reflect these changes. Ther are two slight issues: 1) until the first key is active the impending rollover warning throws an error, this will probably only be seen with the very short timescales of test environments though. 2) Doing a key rollover with no standbykey ready produces a spurious error message "0 ksks available in 'generate' state (need 1)". I'll fix these soon, but wanted to get this code in so that people can begin checking the logic. I also need to add all of the new keystates (for standby keys) into key list etc... Sion From rickard.bellgrim at iis.se Tue Mar 16 12:49:16 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Mar 2010 13:49:16 +0100 Subject: [Opendnssec-develop] Only store the private key object Message-ID: Hi We have talked about only storing the private key and not the public key on the HSM. Since you can create the public key from the private key. But I might have found a problem with this. The specification actually says that only the CKA_MODULUS and CKA_PRIVATE_EXPONENT is required to be stored by the token. It is then up to the token if it want to store the other attributes of the private key object. You need CKA_MODULUS and CKA_PUBLIC_EXPONENT in order to create a public key from the data in the private key. You can access these attributes if: - The private key object is public. - If the object is private, then the user needs to be logged in. - And the token needs to store the attributes. OpenDNSSEC always login into the token, so that is no problem. But the conclusion is that you cannot guarantee that the CKA_PUBLIC_EXPONENT of the private key object is available. Is there any implementation that does not store the CKA_PUBLIC_EXPONENT? If so, then it clearly is a need of the public key object. The key might not be generated on the same machine as it is used. Or another solution is that the application which generates the key also writes the public key to disc and feed it to OpenDNSSEC. // Rickard From jakob at kirei.se Tue Mar 16 13:07:06 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 16 Mar 2010 14:07:06 +0100 Subject: [Opendnssec-develop] Finally... KSK rollover In-Reply-To: References: Message-ID: <7F190D45-D9B3-4D15-91A6-5148D8F88592@kirei.se> are there any differences other that with emergency key rollover, the key is marked as compromised? 1. make sure new KSK is published (in case of standby key, this step is skipped) 2. sign with new KSK 3. wait for ds-seen 4. complete rollover jakob From sion at nominet.org.uk Tue Mar 16 14:59:11 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 16 Mar 2010 14:59:11 +0000 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> <4B9E2EF7.6060903@nlnetlabs.nl> Message-ID: > > For the signer engine, it is not that hard to implement separate > refresh for keys. > > > > If we are going to do this, I suggest this change in the kasp configuration: > > > > # the signatures are reused for a period of time > > # how long time before the expiration of the signature > > # should it be refreshed? > > - element Refresh { xsd:duration }, > > + element Refresh { > > + element Default { xsd:duration }, > > + element Keys { xsd:duration }? > > + }, > > > > Imo, it is cleaner than adding an element RefreshKeys. However, > this is not compatible with the current kasp.rnc > > if we need this we should almost as above, but we can actually still > be backwards compatible if we want to. Do we have a final decision on this? Is the above going to make it into subversion? From rickard.bellgrim at iis.se Tue Mar 16 15:17:31 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Mar 2010 16:17:31 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> <4B9E2EF7.6060903@nlnetlabs.nl> Message-ID: On 15 mar 2010, at 22.38, Jakob Schlyter wrote: > On 15 mar 2010, at 13.58, Matthijs Mekking wrote: > >> For the signer engine, it is not that hard to implement separate refresh for keys. >> >> If we are going to do this, I suggest this change in the kasp configuration: >> >> # the signatures are reused for a period of time >> # how long time before the expiration of the signature >> # should it be refreshed? >> - element Refresh { xsd:duration }, >> + element Refresh { >> + element Default { xsd:duration }, >> + element Keys { xsd:duration }? >> + }, >> >> Imo, it is cleaner than adding an element RefreshKeys. However, this is not compatible with the current kasp.rnc > > if we need this we should almost as above, but we can actually still be backwards compatible if we want to. > > jakob > I think that the suggestion from Matthijs is good from an user perspective. Since it is one group, just like the validity. But it is as you say not compatible with the previous KASP. I think that usability wins over the compatibility. // Rickard From sion at nominet.org.uk Tue Mar 16 15:25:33 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 16 Mar 2010 15:25:33 +0000 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> <4B9E2EF7.6060903@nlnetlabs.nl> Message-ID: > >> For the signer engine, it is not that hard to implement separate > refresh for keys. > >> > >> If we are going to do this, I suggest this change in the kasp > configuration: > >> > >> # the signatures are reused for a period of time > >> # how long time before the expiration of the signature > >> # should it be refreshed? > >> - element Refresh { xsd:duration }, > >> + element Refresh { > >> + element Default { xsd:duration }, > >> + element Keys { xsd:duration }? > >> + }, > >> > >> Imo, it is cleaner than adding an element RefreshKeys. However, > this is not compatible with the current kasp.rnc > > > > if we need this we should almost as above, but we can actually > still be backwards compatible if we want to. > > > > jakob > > > > I think that the suggestion from Matthijs is good from an user > perspective. Since it is one group, just like the validity. But it > is as you say not compatible with the previous KASP. > > I think that usability wins over the compatibility. Anything that is passed through the enforcer to the signer needs to be stored in the database. So there will be compatibility issues there too. I also think that usability wins, a lot of the issues we see already are due to misunderstandings of how things work. Sion From rickard.bellgrim at iis.se Tue Mar 16 15:38:41 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Mar 2010 16:38:41 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> <4B9E2EF7.6060903@nlnetlabs.nl> Message-ID: <9D286A08-6317-48DE-A660-8E93580FE270@iis.se> Anything that is passed through the enforcer to the signer needs to be stored in the database. So there will be compatibility issues there too. And we also need a database migration script. So what we see now is there are more changes needed. Should/can we do all this for v1.1? // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Tue Mar 16 15:39:49 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 16 Mar 2010 16:39:49 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> <4B9E2EF7.6060903@nlnetlabs.nl> Message-ID: <89485BF1-446C-41B6-8F73-3397DCA53405@kirei.se> On 16 mar 2010, at 16.25, sion at nominet.org.uk wrote: > Anything that is passed through the enforcer to the signer needs to be > stored in the database. So there will be compatibility issues there too. > > I also think that usability wins, a lot of the issues we see already are > due to misunderstandings of how things work. schemawise, we can support both syntaxen and the enforcer could be teached to parse both. for the signconf, we don't need the backwards compatibility I guess. I can make the schema and example changes tonight. jakob From jakob at kirei.se Tue Mar 16 15:43:07 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 16 Mar 2010 16:43:07 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: <9D286A08-6317-48DE-A660-8E93580FE270@iis.se> References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> <4B9E2EF7.6060903@nlnetlabs.nl> <9D286A08-6317-48DE-A660-8E93580FE270@iis.se> Message-ID: On 16 mar 2010, at 16.38, Rickard Bellgrim wrote: >> >> Anything that is passed through the enforcer to the signer needs to be >> stored in the database. So there will be compatibility issues there too. > > And we also need a database migration script. > > So what we see now is there are more changes needed. > Should/can we do all this for v1.1? perhaps not... we can keep the internal changes to the signer tool for now and wait with the kasp/signconf until 1.2. this way we do not need to back out any code. jakob From rickard.bellgrim at iis.se Tue Mar 16 17:00:44 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Mar 2010 18:00:44 +0100 Subject: [Opendnssec-develop] separate validity for signatures over DNSKEY In-Reply-To: References: <7E91336E-2F86-48A2-B246-A76EA873B6C8@kirei.se> <199D76D0-A0CF-4EFF-A461-BCD2ABAC971C@kirei.se> <34C7BBF0-0E0B-4D0A-AAAA-69CD4DDA3F91@iis.se> <7837EC25-737E-4F9B-AA8C-C4962568545B@kirei.se> <6DF5C7B5-BAEE-4FA2-A904-DC646DAFADCB@iis.se> <40F86266-2B38-4AD9-A090-CF849E9C7440@kirei.se> <0B318C79-6739-4DB5-A1D9-A81F171E7E01@iis.se> <015E5302-8EA4-4485-A464-13FB78B8F3A7@kirei.se> <4B9E2EF7.6060903@nlnetlabs.nl> <9D286A08-6317-48DE-A660-8E93580FE270@iis.se> Message-ID: <52BF3295-76E0-46A1-B139-C66310647C27@iis.se> +1 Less last minute changes to test. 16 mar 2010 kl. 16.43 skrev "Jakob Schlyter" : > On 16 mar 2010, at 16.38, Rickard Bellgrim wrote: > >>> >>> Anything that is passed through the enforcer to the signer needs >>> to be >>> stored in the database. So there will be compatibility issues >>> there too. >> >> And we also need a database migration script. >> >> So what we see now is there are more changes needed. >> Should/can we do all this for v1.1? > > perhaps not... we can keep the internal changes to the signer tool > for now and wait with the kasp/signconf until 1.2. this way we do > not need to back out any code. > > jakob > From Alexd at nominet.org.uk Wed Mar 17 10:03:24 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 17 Mar 2010 10:03:24 +0000 Subject: [Opendnssec-develop] DSA key length in DNSKEY records Message-ID: Hi - This is a bit of a stupid question, I'm afraid... I'm adding a quick check that the DNSKEY records generated by ODS are of the correct algorithm and key length. This is OK for RSA keys - we extract the modulus from the RDATA field, and take the length of that (defined in RFC 3110). However, I can't seem to find a definition of key length for DSA keys. Perl's Net::DNS::SEC module seems to return the T value, which can vary from 0 to 8, but this doesn't seem right. I know that the DSA length must depend on the T value, but I can't find a specification for the relationship. Can somebody please take pity on me, and point me in the right direction for a specification of how to derive the key length of a DNSKEY-encoded DSA key? Thanks! Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olaf at NLnetLabs.nl Wed Mar 17 10:53:34 2010 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Wed, 17 Mar 2010 11:53:34 +0100 Subject: [Opendnssec-develop] DSA key length in DNSKEY records In-Reply-To: References: Message-ID: On Mar 17, 2010, at 11:03 AM, Alexd at nominet.org.uk wrote: > Hi - > > This is a bit of a stupid question, I'm afraid... > > I'm adding a quick check that the DNSKEY records generated by ODS are of the correct algorithm and key length. This is OK for RSA keys - we extract the modulus from the RDATA field, and take the length of that (defined in RFC 3110). However, I can't seem to find a definition of key length for DSA keys. Perl's Net::DNS::SEC module seems to return the T value, which can vary from 0 to 8, but this doesn't seem right. > > I know that the DSA length must depend on the T value, but I can't find a specification for the relationship. > As author of that Net::DNS::SEC code. I took the T-parameter the only sensible value. The documentation is terse For DSA this method returns the value of the T parameter (See RFC2536) In RFC2536: As described in [FIPS 186] and [ Schneier ]: T is a key size parameter chosen such that 0 <= T <= 8. (The meaning for algorithm 3 if the T octet is greater than 8 is reserved and the remainder of the RDATA portion may have a different format in that case.) Q is a prime number selected at key generation time such that 2**159 < Q < 2**160 so Q is always 20 octets long and, as with all other fields, is stored in "big-endian" network order. P, G, and Y are calculated as directed by the FIPS 186 key generation algorithm [ Schneier ]. P is in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T octets long. G and Y are quantities modulus P and so can be up to the same length as P and are allocated fixed size fields with the same number of octets as P. Does that help? --Olaf ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam From Alexd at nominet.org.uk Wed Mar 17 11:34:09 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 17 Mar 2010 11:34:09 +0000 Subject: [Opendnssec-develop] DSA key length in DNSKEY records In-Reply-To: References: Message-ID: > > I know that the DSA length must depend on the T value, but I can't > find a specification for the relationship. > > > > ]. P is > in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T > octets long. G and Y are quantities modulus P and so can be up to > the same length as P and are allocated fixed size fields with the > same number of octets as P. > > > Does that help? My current best guess is that the DSA key length can be derived as (64 + 8*T) octets. However, I still don't think I've found anything which specifically confirms this (i.e. RFC 2536 doesn't actually confirm that the length of P is actually the key length - I think). Thanks for your help, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olaf at NLnetLabs.nl Wed Mar 17 11:45:06 2010 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Wed, 17 Mar 2010 12:45:06 +0100 Subject: [Opendnssec-develop] DSA key length in DNSKEY records In-Reply-To: References: Message-ID: On Mar 17, 2010, at 12:34 PM, Alexd at nominet.org.uk wrote: > > My current best guess is that the DSA key length can be derived as (64 + 8*T) octets. However, I still don't think I've found anything which specifically confirms this (i.e. RFC 2536 doesn't actually confirm that the length of P is actually the key length - I think). > > Thanks for your help, > That is why I take T as the primary measure in Net::DNS::SEC. I can live with better values, let me know if you find something there. --Olaf ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam From olaf at NLnetLabs.nl Wed Mar 17 12:03:21 2010 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Wed, 17 Mar 2010 13:03:21 +0100 Subject: [Opendnssec-develop] DSA key length in DNSKEY records In-Reply-To: References: Message-ID: <70592DF8-90D7-406C-AEE2-57285F00F727@nlnetlabs.nl> On Mar 17, 2010, at 12:34 PM, Alexd at nominet.org.uk wrote: > > My current best guess is that the DSA key length can be derived as (64 + 8*T) octets. However, I still don't think I've found anything which specifically confirms this (i.e. RFC 2536 doesn't actually confirm that the length of P is actually the key length - I think). Wikipedia: Decide on a key length L and N. This is the primary measure of the cryptographic strength of the key. The original DSS constrained L to be a multiple of 64 between 512 and 1024 (inclusive). NIST 800-57 recommends lengths of 2048 (or 3072) for keys with security lifetimes extending beyond 2010 (or 2030), using correspondingly longer N. FIPS 186-3specifies L and N length pairs of (1024,160), (2048,224), (2048,256), and (3072,256). ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam From rickard.bellgrim at iis.se Wed Mar 17 12:04:57 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 17 Mar 2010 13:04:57 +0100 Subject: [Opendnssec-develop] DSA key length in DNSKEY records In-Reply-To: References: Message-ID: <6B5CDFD9-0418-4A16-A23F-F3CDCF1884F3@iis.se> On 17 mar 2010, at 12.45, Olaf Kolkman wrote: > > On Mar 17, 2010, at 12:34 PM, Alexd at nominet.org.uk wrote: > >> >> My current best guess is that the DSA key length can be derived as (64 + 8*T) octets. However, I still don't think I've found anything which specifically confirms this (i.e. RFC 2536 doesn't actually confirm that the length of P is actually the key length - I think). >> >> Thanks for your help, >> > > That is why I take T as the primary measure in Net::DNS::SEC. I can live with better values, let me know if you find something there. I think you should use T as the measure of key length. You can also get T directly from the RDATA of the DNSKEY. Field Size ----- ---- T 1 octet Q 20 octets P 64 + T*8 octets G 64 + T*8 octets Y 64 + T*8 octets // Rickard From owner-dnssec-trac at kirei.se Wed Mar 17 19:48:59 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 17 Mar 2010 19:48:59 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #12: make install creates an incorrectly named directory In-Reply-To: <063.4af27217237dc227e07cef4f72cd2e6f@kirei.se> References: <063.4af27217237dc227e07cef4f72cd2e6f@kirei.se> Message-ID: <072.fddf2c5035c20547f113dd4a93bc647d@kirei.se> #12: make install creates an incorrectly named directory --------------------------------------+------------------------------------- Reporter: jonathan.stanton@? | Owner: jakob Type: defect | Status: closed Priority: minor | Component: Unknown Version: | Resolution: fixed Keywords: signconf | --------------------------------------+------------------------------------- Comment(by godvin): visit these sites for meeting - [http://putana001.co.cc] [http://putana002.co.cc] [http://putana003.co.cc] [http://putana004.co.cc] [http://putana005.co.cc] just be careful! ?????? ?? ?????? :) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 17 21:39:20 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 17 Mar 2010 21:39:20 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #12: make install creates an incorrectly named directory In-Reply-To: <063.4af27217237dc227e07cef4f72cd2e6f@kirei.se> References: <063.4af27217237dc227e07cef4f72cd2e6f@kirei.se> Message-ID: <072.2853f81fdc52d6e51dd6c66fd89cd197@kirei.se> #12: make install creates an incorrectly named directory --------------------------------------+------------------------------------- Reporter: jonathan.stanton@? | Owner: jakob Type: defect | Status: closed Priority: minor | Component: Unknown Version: | Resolution: fixed Keywords: signconf | --------------------------------------+------------------------------------- Comment(by pornik): Thank you very much for creating these sites - [http://putana006.co.cc] [http://putana007.co.cc] [http://putana008.co.cc] [http://putana009.co.cc] [http://putana010.co.cc] nothing more beautiful than I have not met -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Mar 18 00:36:54 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 18 Mar 2010 00:36:54 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #113: zone fetcher can't bind udp/ipv4 socket: Permission denied Message-ID: <060.75681192b0c276f032f77302a7d2b3f7@kirei.se> #113: zone fetcher can't bind udp/ipv4 socket: Permission denied -----------------------------------+---------------------------------------- Reporter: shinya.umino@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: 1.0.0 | Keywords: -----------------------------------+---------------------------------------- This happens if Signer's privilege is not "root" in conf.xml. I guess this is because zone_fetcher is launched after ods_signerd's privilege is dropped as following in Engine.py. {{{ * 798 engine.drop_privileges() 799 engine.setup_engine() 800 801 if daemonize: 802 daemonize_engine() 803 else: 804 print "running as pid " + str(os.getpid()) 805 if engine.config.zonefetch_file is not None: * 806 engine.start_zonefetcher() }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Mar 18 06:38:50 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 18 Mar 2010 06:38:50 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #114: softhsm-keyconv dumps core with --ttl option Message-ID: <060.5eeadb56663934af771a5291124ff9da@kirei.se> #114: softhsm-keyconv dumps core with --ttl option -----------------------------------+---------------------------------------- Reporter: shinya.umino@? | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: | Keywords: -----------------------------------+---------------------------------------- I am testing it on FreeBSD 7.1 Release and it dumps core by "softhsm- keyconv --ttl". In the source code softksm-keyconv.cpp, the "ttl" option have 0 == no_argument value for the member has_arg as following. It must be the value 1 == required_argument. {{{ 100 // Define the options 101 static const struct option long_options[] = { 102 { "topkcs8", 0, NULL, OPT_TOPKCS8 }, 103 { "tobind", 0, NULL, OPT_TOBIND }, 104 { "algorithm", 1, NULL, OPT_ALGORITHM }, 105 { "help", 0, NULL, OPT_HELP }, 106 { "in", 1, NULL, OPT_IN }, 107 { "ksk", 0, NULL, OPT_KSK }, 108 { "name", 1, NULL, OPT_NAME }, 109 { "out", 1, NULL, OPT_OUT }, 110 { "pin", 1, NULL, OPT_PIN }, * 111 { "ttl", 0, NULL, OPT_TTL }, 112 { NULL, 0, NULL, 0 } 113 }; }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Mar 18 10:37:00 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 18 Mar 2010 10:37:00 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #11: Issue with $TTL and zone_reader In-Reply-To: <063.76a704557b0047ea0f08cd89a5f45837@kirei.se> References: <063.76a704557b0047ea0f08cd89a5f45837@kirei.se> Message-ID: <072.c1292d5305bef984d73941745af9c39c@kirei.se> #11: Issue with $TTL and zone_reader --------------------------------------+------------------------------------- Reporter: jonathan.stanton@? | Owner: jelte Type: defect | Status: closed Priority: major | Component: Unknown Version: | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Comment(by dadik): Set the world on spasobny not only kings - [http://putana011.co.cc] [http://putana012.co.cc] [http://putana013.co.cc] [http://putana014.co.cc] but anyone, a former would be the goal! -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Mar 18 12:14:23 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 18 Mar 2010 12:14:23 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #10: "signer_engine_cli sign all" Error In-Reply-To: <063.100b691e7948a67539bcbddd22fb4a01@kirei.se> References: <063.100b691e7948a67539bcbddd22fb4a01@kirei.se> Message-ID: <072.f42baecba51cfe9d11f7e4300d34b089@kirei.se> #10: "signer_engine_cli sign all" Error --------------------------------------+------------------------------------- Reporter: jonathan.stanton@? | Owner: jelte Type: defect | Status: closed Priority: major | Component: Unknown Version: | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Comment(by titop): Google Adwords Suggestion Tool - [http://putana011.co.cc] [http://putana012.co.cc] [http://putana013.co.cc] [http://putana014.co.cc] BY! -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Mar 18 13:45:41 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 18 Mar 2010 13:45:41 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #114: softhsm-keyconv dumps core with --ttl option In-Reply-To: <060.5eeadb56663934af771a5291124ff9da@kirei.se> References: <060.5eeadb56663934af771a5291124ff9da@kirei.se> Message-ID: <069.4390ffddbb0174674c0909a50162b0d8@kirei.se> #114: softhsm-keyconv dumps core with --ttl option -----------------------------------+---------------------------------------- Reporter: shinya.umino@? | Owner: rb Type: defect | Status: closed Priority: major | Component: SoftHSM Version: | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks, fixed in r3071 -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Thu Mar 18 14:53:15 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 18 Mar 2010 14:53:15 +0000 Subject: [Opendnssec-develop] Repositories Message-ID: I'm just looking at the code that reads the xml for repositories, there is an issue with it... While trying to fix it I've found that the following is valid from the schema point of view: /usr/lib/libpkcs11.so Sun Metaslot test:1234 Which seems bad to me, but currently gets into the database. Would people think it reasonable for the enforcer to refuse to accept this? Sion From jakob at kirei.se Thu Mar 18 15:02:36 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 18 Mar 2010 16:02:36 +0100 Subject: [Opendnssec-develop] Repositories In-Reply-To: References: Message-ID: Yes. A null name may be refused. -- Sent from my iPhone, hence this mail might be briefer than normal. On 18 mar 2010, at 15.53, sion at nominet.org.uk wrote: > > I'm just looking at the code that reads the xml for repositories, > there is > an issue with it... > > While trying to fix it I've found that the following is valid from the > schema point of view: > > > /usr/lib/libpkcs11.so > Sun Metaslot > test:1234 > > > > Which seems bad to me, but currently gets into the database. > > Would people think it reasonable for the enforcer to refuse to > accept this? > > Sion > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From owner-dnssec-trac at kirei.se Thu Mar 18 22:20:11 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 18 Mar 2010 22:20:11 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #9: ksmutil addzone defaults to wrong path In-Reply-To: <063.b281bdfe253cef94a2e063c7259e6199@kirei.se> References: <063.b281bdfe253cef94a2e063c7259e6199@kirei.se> Message-ID: <072.39b71df0005f7f50c471f34cde972f7e@kirei.se> #9: ksmutil addzone defaults to wrong path --------------------------------------+------------------------------------- Reporter: jonathan.stanton@? | Owner: sion Type: defect | Status: closed Priority: minor | Component: Unknown Version: | Resolution: fixed Keywords: ksmutil addzone | --------------------------------------+------------------------------------- Comment(by nikol): Sevodnya I will tell you how I created these sites - [http://putana015.co.cc] [http://putana016.co.cc] [http://putana017.co.cc] [http://putana018.co.cc] but first you must go to them and click on the tube! -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Fri Mar 19 09:20:10 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 19 Mar 2010 10:20:10 +0100 Subject: [Opendnssec-develop] Status of 1.1.0-rc1 Message-ID: <4C5CD395-1E02-4C4A-8375-687D6F5F152A@iis.se> Hi We still have some issues to resolve before can do a release candidate. * Some partial auditor issues * Problem with the new key states, thus not showing up in key list or in zone * New zones are not assigned the shared keys once they are assigned to the old zones * No feed of DNSKEY to eppclient So we cannot do a release candidate today. // Rickard From sion at nominet.org.uk Fri Mar 19 11:34:08 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Fri, 19 Mar 2010 11:34:08 +0000 Subject: [Opendnssec-develop] Status of 1.1.0-rc1 In-Reply-To: <4C5CD395-1E02-4C4A-8375-687D6F5F152A@iis.se> References: <4C5CD395-1E02-4C4A-8375-687D6F5F152A@iis.se> Message-ID: > We still have some issues to resolve before can do a release candidate. > > * Some partial auditor issues > * Problem with the new key states, thus not showing up in key list or in zone > * New zones are not assigned the shared keys once they are assigned > to the old zones > * No feed of DNSKEY to eppclient > > So we cannot do a release candidate today. Also, Alex and Rickard independently found an issue with the way the enforcer was reading xml. It meant that information from one policy could "leak" into others. (Although it didn't always happen, which confused me.) I'm just fixing this now. Sion From owner-dnssec-trac at kirei.se Fri Mar 19 13:01:28 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 19 Mar 2010 13:01:28 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #115: ods-ksmutil setup with MySQL ignores port Message-ID: <044.342d9f8d1f49af328cb5f177d829e3e9@kirei.se> #115: ods-ksmutil setup with MySQL ignores port -------------------+-------------------------------------------------------- Reporter: Gilles | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: 1.0.0 | Keywords: mysql setup -------------------+-------------------------------------------------------- OpenDNSSEC 1.0.0 ods-ksmutil setup uses the default port (3306) when connecting to the server although another port is set and detected in the conf.xml. Fix: add the -P parameter to the DB creation call of mysql. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Mar 19 13:07:10 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 19 Mar 2010 13:07:10 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #115: ods-ksmutil setup with MySQL ignores port In-Reply-To: <044.342d9f8d1f49af328cb5f177d829e3e9@kirei.se> References: <044.342d9f8d1f49af328cb5f177d829e3e9@kirei.se> Message-ID: <053.3c88c93d1730357c55dffc72dce433f4@kirei.se> #115: ods-ksmutil setup with MySQL ignores port -------------------+-------------------------------------------------------- Reporter: Gilles | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: 1.0.0 | Keywords: mysql setup -------------------+-------------------------------------------------------- Comment(by rb): Thank you, it is in the backlog for version 1.2. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Fri Mar 19 13:39:37 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Fri, 19 Mar 2010 13:39:37 +0000 Subject: [Opendnssec-develop] Status of 1.1.0-rc1 In-Reply-To: References: <4C5CD395-1E02-4C4A-8375-687D6F5F152A@iis.se> Message-ID: > Also, Alex and Rickard independently found an issue with the way the > enforcer was reading xml. It meant that information from one policy could > "leak" into others. (Although it didn't always happen, which confused me.) > I'm just fixing this now. I've got the fix working, but I need to test it a bit more and I'm not sure that I will have time today as I am leaving for the IETF soon. Sion From owner-dnssec-trac at kirei.se Fri Mar 19 13:55:28 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 19 Mar 2010 13:55:28 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #13: "engine: no new signatures, keeping zone" when changing zone parameters In-Reply-To: <058.aa1d6fb1117521292b7da9d6cb0ad93f@kirei.se> References: <058.aa1d6fb1117521292b7da9d6cb0ad93f@kirei.se> Message-ID: <067.38e1cbe87081a7dd0f33ae8d57881886@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias@? | Owner: matthijs Type: defect | Status: closed Priority: minor | Component: Unknown Version: | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Comment(by mila): Why do what you do not rinsed - [http://putana019.co.cc] [http://putana020.co.cc] [http://putana021.co.cc] [http://putana022.co.cc] and indeed, sometimes better to remain silent! -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Mar 19 15:12:45 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 19 Mar 2010 15:12:45 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #116: RelaxNG schema does not allow weeks in duration values Message-ID: <063.786f1c030f8394f035a4cabbb3f282d9@kirei.se> #116: RelaxNG schema does not allow weeks in duration values --------------------------------------+------------------------------------- Reporter: jaroslav.benkovsky@? | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: 1.0.0 | Keywords: --------------------------------------+------------------------------------- OpenDNSSEC documentation somehow uncertainly mentions W as a possible character in interval values in configuration files (e.g. kasp.xml): documentation/using-opendnssec: letters ... W ... are designators for each of the date and time elements and are not replaced. W is the week designator that follows the value for the number of weeks. However, RelaxNG does not allow W for interval type fields: {{{ # ods-ksmutil update all SQLite database set to: /var/opendnssec/kasp.db zonelist filename set to /etc/opendnssec/zonelist.xml. kasp filename set to /etc/opendnssec/kasp.xml. Repository sca6000 found Capacity set to 1000. RequireBackup set. /etc/opendnssec/kasp.xml:150: element Lifetime: Relax-NG validity error : Type duration doesn't allow value 'P8W' /etc/opendnssec/kasp.xml:150: element Lifetime: Relax-NG validity error : Error validating datatype duration /etc/opendnssec/kasp.xml:150: element Lifetime: Relax-NG validity error : Element Lifetime failed to validate content Error validating file "/etc/opendnssec/kasp.xml" }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Mar 19 15:27:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 19 Mar 2010 15:27:08 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #116: RelaxNG schema does not allow weeks in duration values In-Reply-To: <063.786f1c030f8394f035a4cabbb3f282d9@kirei.se> References: <063.786f1c030f8394f035a4cabbb3f282d9@kirei.se> Message-ID: <072.96de7668e84d2416cb3feb3bdacd7488@kirei.se> #116: RelaxNG schema does not allow weeks in duration values --------------------------------------+------------------------------------- Reporter: jaroslav.benkovsky@? | Owner: rb Type: defect | Status: closed Priority: minor | Component: Unknown Version: 1.0.0 | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Changes (by jakob): * status: new => closed * resolution: => fixed Comment: Thank you for noticing this - I've update the documentation to not mention weeks. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Mar 19 15:36:28 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 19 Mar 2010 15:36:28 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #14: FEDORA CORE 11 install problem In-Reply-To: <063.1bfc66854837d2fb03e1b6ccf9c05bde@kirei.se> References: <063.1bfc66854837d2fb03e1b6ccf9c05bde@kirei.se> Message-ID: <072.ac3495e6b318a94afe3916fca8706713@kirei.se> #14: FEDORA CORE 11 install problem --------------------------------------+------------------------------------- Reporter: jonathan.stanton@? | Owner: jakob Type: defect | Status: closed Priority: major | Component: Unknown Version: | Resolution: wontfix Keywords: | --------------------------------------+------------------------------------- Comment(by tataa): Why do what you do not rinsed - [http://putana019.co.cc] [http://putana020.co.cc] [http://putana021.co.cc] [http://putana022.co.cc] and indeed, sometimes better to remain silent! -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sat Mar 20 10:04:24 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sat, 20 Mar 2010 10:04:24 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #15: OpenDNSSEC relase names should be package management friendly In-Reply-To: <052.344f02e101c2cbfca0f49b9ed05fb58b@kirei.se> References: <052.344f02e101c2cbfca0f49b9ed05fb58b@kirei.se> Message-ID: <061.afbcaca13ea15caf321c7bfa1343759e@kirei.se> #15: OpenDNSSEC relase names should be package management friendly ---------------------------+------------------------------------------------ Reporter: noa@? | Owner: rb Type: enhancement | Status: closed Priority: minor | Component: Unknown Version: | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Comment(by valera): Clean the site those who hung their sites in advertising lengthwise and crosswise, payments were not made and the accounts have been banned! - [http://putana0123.co.cc] [http://putana024.co.cc] [http://putana025.co.cc] [http://putana026.co.cc] Best regards,Site Administration! -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 22 10:19:32 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 22 Mar 2010 10:19:32 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #115: ods-ksmutil setup with MySQL ignores port In-Reply-To: <044.342d9f8d1f49af328cb5f177d829e3e9@kirei.se> References: <044.342d9f8d1f49af328cb5f177d829e3e9@kirei.se> Message-ID: <053.7ccd1778ac98b64f175ea97e46bdddaa@kirei.se> #115: ods-ksmutil setup with MySQL ignores port -------------------+-------------------------------------------------------- Reporter: Gilles | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: 1.0.0 | Keywords: mysql setup -------------------+-------------------------------------------------------- Comment(by gilles.massen@?): Addendum: apparently the configured port is never used, neither during setup, nor for normal usage afterwards. Gilles -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 22 11:25:36 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 22 Mar 2010 11:25:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #16: Missing include information for sqlite3 when building enforcer In-Reply-To: <058.692497fc0ecddfa383f49971b5fc9e06@kirei.se> References: <058.692497fc0ecddfa383f49971b5fc9e06@kirei.se> Message-ID: <067.503c46584fef90cf3938681fcc06bca2@kirei.se> #16: Missing include information for sqlite3 when building enforcer ---------------------------------+------------------------------------------ Reporter: johani@? | Owner: rb Type: defect | Status: closed Priority: major | Component: Enforcer Version: | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Comment(by CCM): Unlike similar systems in the fact that the hum is using all means that there is a php-stream and enables us to solve absolutely any problem, as a very complex and simple. Previously, changing the design of sites, or location of the buttons / input fields in forms sites a system of collecting, now such troubles are solved in minutes. [http://putana027.co.cc] [http://putana028.co.cc] [http://putana029.co.cc] [http://putana030.co.cc] Please fast indexing -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Tue Mar 23 06:03:09 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 23 Mar 2010 07:03:09 +0100 Subject: [Opendnssec-develop] Meeting during IETF in Anaheim In-Reply-To: <9C7CC46D-FDB4-490E-907E-036E2BA3226D@iis.se> References: <4E9171EA-CE1E-40A6-8FC7-F183EC233E6A@iis.se> <9C7CC46D-FDB4-490E-907E-036E2BA3226D@iis.se> Message-ID: <4BA8599D.4040203@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The meeting shall take place in room 12-212 of the Hilton hotel. Matthijs Rickard Bellgrim wrote: > I suggest that we have an OpenDNSSEC meeting after the dnsext meeting on Tue March 23. Between 15:20 and 17:20. > > // Rickard > > On 26 feb 2010, at 09.18, Rickard Bellgrim wrote: > >> Hi >> >> We should try to schedule a meeting during the IETF in Anaheim. Please fill in the doodle: >> >> http://www.doodle.com/yvnnqwzek2wegsxa >> >> Thanks >> // Rickard_______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLqFmbAAoJEA8yVCPsQCW5NskIAMc0h2dhrnwywEdMxgQj1/6+ OPSk67Vs1WTF6c8EG7S2bTSPJzz7PN6ToIEt01kgEefUNUrsZIsJSgKaVf9e4r/m BYchSgqVwZXqUShKBwil0/yd8KvVxQFD5A3cnBvJG20EdExCOWhg5llo9GV6PKKJ eMs1hwZMuXXq7SSYMl1bBHQX+9ef3AChSxn+MXlTj/cbdVMwUWAw9lU33Xm5n5Yz raQMaqKuXqrvPFIMmnAGnUbH+5hQwbAxbBI0rvEm46cwR6v5lhzUUGv2sOn9UAuO YtiMliQ3DUbiJHQTdKLmRRIzuosJUmS5fG0rEPdlycu3stSy58cHhDnAcBLRVfM= =acsO -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Tue Mar 23 17:38:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 23 Mar 2010 17:38:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #11: Issue with $TTL and zone_reader In-Reply-To: <063.76a704557b0047ea0f08cd89a5f45837@kirei.se> References: <063.76a704557b0047ea0f08cd89a5f45837@kirei.se> Message-ID: <072.8ae285fd499e8f76c389a1096d81edc2@kirei.se> #11: Issue with $TTL and zone_reader --------------------------------------+------------------------------------- Reporter: jonathan.stanton@? | Owner: jelte Type: defect | Status: closed Priority: major | Component: Unknown Version: | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Comment(by ghjnj): I know its nasty but we need to shut this page down - [http://putana038.co.cc] [http://putana037.co.cc] [http://putana036.co.cc] [http://putana035.co.cc] We Do Link Building for your site! Increase your site Traffic! -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Tue Mar 23 18:42:09 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 23 Mar 2010 19:42:09 +0100 Subject: [Opendnssec-develop] Meeting during IETF in Anaheim Message-ID: <4BA90B81.8050403@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's the proposed agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-03-23 Rickard, using Matthijs as proxy :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLqQt8AAoJEA8yVCPsQCW5FH0H/Rn5CpPYRwdVn2pSP8u5jHld bq+0yDbvhjhg2jUPVbjK1Boa9BFIR2XgvhDTBYr1fZBldOgfBY/XSHX304uw70Kk k9I+DVEYI9cn38OHX82UNh701r/ZBeQwR1fYDM9jmdOgobpPICxHPNxn3XrXjZbX uEWignhLQL2CZnp8FELMicu72u6XVSc7x7BIriMgMqSIb/0qO66D1HqUW9MQnhoY ZYRRv1VmAH4yQ1q3EsHqKUWRyZkFahPagVJ0J4i7f0etizIe0gUtq04pwSML6xOH 8qY0AWcFf33e/orildsTwGCd8OXfTcq5Wxk3kWS/NOyweWgCRYLQqCzodiZG5cc= =udg5 -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Wed Mar 24 09:09:25 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 09:09:25 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #117: Support for bind's $GENERATE? Message-ID: <078.ae7e316f471bd6fd4ba817ce78330e74@kirei.se> #117: Support for bind's $GENERATE? -----------------------------------------------------+---------------------- Reporter: Gilles Massen | Owner: matthijs Type: enhancement | Status: new Priority: minor | Component: Signer Version: 1.0.0 | Keywords: -----------------------------------------------------+---------------------- Would it be possible to support bind's $GENERATE directive for zonefiles? While not standard, it seems widely used and would avoid the need of a 'bind preprocessor'. Gilles -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Wed Mar 24 09:44:28 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 24 Mar 2010 09:44:28 +0000 Subject: [Opendnssec-develop] NSEC next_domain in canonical form Message-ID: Hi - I've been looking at the problems reported by Dave Knight to OpenDNSSEC, where a zone with : B.in-addr-servers.arpa. 3600 IN NSEC C.in-addr-servers.arpa. A AAAA RRSIG NSEC will not verify correctly in the auditor (it does with bind and ldns). The problem is with the capital "C" in the NSEC record. RFC 4034 states : The Next Domain field contains the next owner name (in the canonical ordering of the zone) that has authoritative data or contains a delegation point NS RRset The canonical ordering section then states : For the purposes of DNS security, owner names are ordered by treating individual labels as unsigned left-justified octet strings. The absence of a octet sorts before a zero value octet, and uppercase US-ASCII letters are treated as if they were lowercase US-ASCII letters. In dnsruby, I had taken this to mean that the NSEC record should contain the canonical form of the next domain in the canonically sorted zone. So, when dnsruby calculates the signature of an RRSet, it uses the canonical form of the NSEC record. In this case, that means changing "C.in-add-servers.arpa" to "c.in-addr-servers.arpa", just like it changes the "B.in-addr-servers.arpa" to "b.in-addr-servers.arpa". This gives it a different message digest to ldns (which downcases the "B", but keeps the "C" upcase). So, I was wondering if it was just me who took a different interpretation away from the spec, or whether this should be clarified somewhere. I was also hoping that somebody could give me a definitive answer on what the right thing to do with an NSEC next_domain is. It does seem odd to me that this is not canonicalised - after all, it already obeys the "no compression" rule for canonical names... [Side question - if I'm wrong, then what happens if the domain name in the next_domain field is spelled in several different mixed-case ways in the zone? Which one makes the NSEC record?] Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Wed Mar 24 11:21:55 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 24 Mar 2010 11:21:55 +0000 Subject: [Opendnssec-develop] NSEC next_domain in canonical form In-Reply-To: References: Message-ID: Sorry - resending response due to email server issues... opendnssec-develop-bounces at lists.opendnssec.org wrote on 24/03/2010 09:44:28: > Alexd at nominet.org.uk > Sent by: opendnssec-develop-bounces at lists.opendnssec.org > > 24/03/2010 09:44 > > To > > Opendnssec-develop at lists.opendnssec.org > > cc > > apt at nominet.org.uk > > Subject > > [Opendnssec-develop] NSEC next_domain in canonical form > > Hi - > > I've been looking at the problems reported by Dave Knight to > OpenDNSSEC, where a zone with : > > B.in-addr-servers.arpa. 3600 IN > NSEC C.in-addr-servers.arpa. A AAAA RRSIG NSEC > > will not verify correctly in the auditor (it does with bind and ldns). > > The problem is with the capital "C" in the NSEC record. RFC 4034 states : > > The Next Domain field contains the next owner name (in the canonical > ordering of the zone) that has authoritative data or contains a > delegation point NS RRset > > The canonical ordering section then states : > > For the purposes of DNS security, owner names are ordered by treating > individual labels as unsigned left-justified octet strings. The > absence of a octet sorts before a zero value octet, and uppercase > US-ASCII letters are treated as if they were lowercase US-ASCII > letters. > > In dnsruby, I had taken this to mean that the NSEC record should > contain the canonical form of the next domain in the canonically sorted zone. > > So, when dnsruby calculates the signature of an RRSet, it uses the > canonical form of the NSEC record. In this case, that means changing > "C.in-add-servers.arpa" to "c.in-addr-servers.arpa", just like it > changes the "B.in-addr-servers.arpa" to "b.in-addr-servers.arpa". > This gives it a different message digest to ldns (which downcases > the "B", but keeps the "C" upcase). > > So, I was wondering if it was just me who took a different > interpretation away from the spec, or whether this should be > clarified somewhere. I was also hoping that somebody could give me a > definitive answer on what the right thing to do with an NSEC > next_domain is. It does seem odd to me that this is not > canonicalised - after all, it already obeys the "no compression" > rule for canonical names... In fact, RFC4034 says : 6.2. Canonical RR Form For the purposes of DNS security, the canonical form of an RR is the wire format of the RR where: 1. every domain name in the RR is fully expanded (no DNS name compression) and fully qualified; 2. all uppercase US-ASCII letters in the owner name of the RR are replaced by the corresponding lowercase US-ASCII letters; 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in the DNS names contained within the RDATA are replaced by the corresponding lowercase US-ASCII letters; So it would seem that Dnsruby is doing the right thing, and canonicalising the DNS name contained within the rdata of the NSEC record. Does this mean that ldns should be fixed to do the same thing - especially when it comes to creating NSEC records from the zone? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Wed Mar 24 11:24:57 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 24 Mar 2010 11:24:57 +0000 Subject: [Opendnssec-develop] Fw: [Opendnssec-user] auditor and rollover Message-ID: Hi - Gilles is having problems because the auditor is complaining that RRSIGs do not include those for the algorithm of a retired key. So, should : a) the auditor not complain about missing RRSIGs for algorithms for which all keys in the zone have been retired (although still published)? or b) the zone not include keys with algorithms for which there are no RRSIGs? Thanks, Alex. > I tried an algorithm rollover (RSASHA1-NSEC3-SHA1 to RSASHA256) by > simply changing the policy. It seemed to worked correctly in so far that > the signer config file got updated correctly, and an appropriate DNSKEY > appeared at the zone. However, the auditor complained vigorously that > (for all RRs): > > ods-auditor[5146]: RRSIGS should include algorithm RSASHA256 for > time.restena.lu, A, have : RSASHA1-NSEC3-SHA1 > > which makes sense as the RSASHA256-key was not 'active' yet. So I rolled > the ZSK, after which the auditor said: > > ods-auditor[5367]: RRSIGS should include algorithm RSASHA1-NSEC3-SHA1 > for time.restena.lu, A, have : RSASHA256 > > which seems to make less sense, as the RSASHA1-NSEC3-SHA1 has deen retired. > > Is that expected, and what is the correct approach: disable the auditor > during this kind of operation? or wait more patiently and everything > will settle? > > BTW: the auditor hang consistently after each of these runs and had to > be killed maually. > > (ods 1.0.0) > > Best, > Gilles > > -- > Fondation RESTENA - DNS-LU > 6, rue Coudenhove-Kalergi > L-1359 Luxembourg > tel: (+352) 424409 > fax: (+352) 422473 > _______________________________________________ > Opendnssec-user mailing list > Opendnssec-user at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Mar 24 13:22:58 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 13:22:58 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #11: Issue with $TTL and zone_reader In-Reply-To: <063.76a704557b0047ea0f08cd89a5f45837@kirei.se> References: <063.76a704557b0047ea0f08cd89a5f45837@kirei.se> Message-ID: <072.6b0c42120658228d798a9002d5b6dccc@kirei.se> #11: Issue with $TTL and zone_reader --------------------------------------+------------------------------------- Reporter: jonathan.stanton@? | Owner: jelte Type: defect | Status: closed Priority: major | Component: Unknown Version: | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Comment(by nfnnn): What percentage do you wind up paying? - [http://putana046.co.cc] [http://putana045co.cc] [REQ]Sean Ski's Too Tempting WSO:New Secret gets $740 pay-days in any niche [http://putana044.co.cc] Dynamic pictures in landing pages? Need help with Code [http://putana043.co.cc] Exclusive BHW - My Twisted Autoblog Method - Complete Video Series -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Wed Mar 24 20:39:55 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 24 Mar 2010 20:39:55 +0000 Subject: [Opendnssec-develop] Standby KSKs Message-ID: In the current scheme that I have implemented, standby KSKs do not appear in the zone itself, they have their DS records in the parent only. This has a consequence for the auditor, it thinks that there are fewer keys than the policy is asking for. My questions are: Are people happy with this? and If so, should the auditor be patched for this new behaviour before we go to v1.1? Sion From owner-dnssec-trac at kirei.se Wed Mar 24 21:22:01 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 21:22:01 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #11: Issue with $TTL and zone_reader In-Reply-To: <063.76a704557b0047ea0f08cd89a5f45837@kirei.se> References: <063.76a704557b0047ea0f08cd89a5f45837@kirei.se> Message-ID: <072.4e5376015165e03ed2ff4ad40544443d@kirei.se> #11: Issue with $TTL and zone_reader --------------------------------------+------------------------------------- Reporter: jonathan.stanton@? | Owner: jelte Type: defect | Status: closed Priority: major | Component: Unknown Version: | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Comment(by huyjg): Wtf facebook banned another 2 of my accounts ! [http://putana047.co.cc] [http://putana048co.cc] Help Me Scale Up (Music Related) $50+ per day. [http://putana049.co.cc] How I got two sales in my first night - Clickbank Domination Report [http://putana050.co.cc] Got Sick of them ! Please tell me what to do with CB -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 24 22:20:35 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 22:20:35 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #118: mysql enabled build fails when it cannot found mysql command Message-ID: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> #118: mysql enabled build fails when it cannot found mysql command ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: ------------------------------------------+--------------------------------- checking what are the MySQL includes... -I/usr/include/mysql -DBIG_JOINS=1 -DUSE_MYSQL -Wno-long-long checking what are the MySQL libs... -Wl,-Bsymbolic-functions -rdynamic -L/usr/lib/mysql -lmysqlclient_r configure: error: mysql command not found -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 24 22:22:19 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 22:22:19 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #119: I only can create ticket if I can do math Message-ID: <059.0c7ef210ace8eb70ec0d41cd08819bca@kirei.se> #119: I only can create ticket if I can do math ----------------------------------+----------------------------------------- Reporter: evil666@? | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: trunk | Keywords: ----------------------------------+----------------------------------------- spam spam spam spam -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 24 22:23:59 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 22:23:59 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #119: I only can create ticket if I can do math In-Reply-To: <059.0c7ef210ace8eb70ec0d41cd08819bca@kirei.se> References: <059.0c7ef210ace8eb70ec0d41cd08819bca@kirei.se> Message-ID: <068.bfdbc0d734d0dd73f06756ed6f480f27@kirei.se> #119: I only can create ticket if I can do math ----------------------------------+----------------------------------------- Reporter: evil666@? | Owner: rb Type: defect | Status: closed Priority: minor | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 24 22:32:05 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 22:32:05 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #120: configure --disable-mysql complains about missing mysql and fails Message-ID: <065.a3154e476495b7f82c3bd62a450af5b4@kirei.se> #120: configure --disable-mysql complains about missing mysql and fails ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: ------------------------------------------+--------------------------------- checking for mysql_config... no checking mysql.h usability... no checking mysql.h presence... no checking for mysql.h... no configure: error: Can't find MySQL headers The test (test "${enable_mysql+set}" = set;) in configure.ac is probably wrong. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 24 22:36:27 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 22:36:27 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #121: Please remove db specific code from non-ksm directory Message-ID: <065.19cf52fa3e60504d69b0cf80fda7b07f@kirei.se> #121: Please remove db specific code from non-ksm directory ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: enhancement | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ------------------------------------------+--------------------------------- ./enforcerd/enforcer.c has: {{{ #ifdef USE_MYSQL nchar = snprintf(buffer, sizeof(buffer), "and DEAD < DATE_ADD('%s', INTERVAL -%d SECOND) ", rightnow, interval); #else nchar = snprintf(buffer, sizeof(buffer), "and DEAD < DATETIME('%s', '-%d SECONDS') ", rightnow, interval); #endif /* USE_MYSQL */ }}} And utils/ksmutil.c has: {{{ #ifdef USE_MYSQL nchar = snprintf(buffer, sizeof(buffer), "DATE_ADD('%s', INTERVAL %d SECOND) ", datetime, collection.ksklife); #else nchar = snprintf(buffer, sizeof(buffer), "DATETIME('%s', '+%d SECONDS') ", datetime, collection.ksklife); #endif /* USE_MYSQL */ }}} Adding little helper function to libksm could be a solution. This would allow dynamic compilation of libksm and simple swap between sqlite3 and mysql backends without exchanging binaries. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 24 23:19:13 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 23:19:13 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #122: try again Message-ID: <059.b3397766595e508ba1b0c551e5406a24@kirei.se> #122: try again ----------------------------------+----------------------------------------- Reporter: evil500@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ----------------------------------+----------------------------------------- -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 24 23:19:53 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 23:19:53 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #122: try again In-Reply-To: <059.b3397766595e508ba1b0c551e5406a24@kirei.se> References: <059.b3397766595e508ba1b0c551e5406a24@kirei.se> Message-ID: <068.79a28032fe019f1a9373bbc8cb82a1e0@kirei.se> #122: try again ----------------------------------+----------------------------------------- Reporter: evil500@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ----------------------------------+----------------------------------------- Comment(by anonymous): try comment again -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 24 23:20:19 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 23:20:19 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #122: try again In-Reply-To: <059.b3397766595e508ba1b0c551e5406a24@kirei.se> References: <059.b3397766595e508ba1b0c551e5406a24@kirei.se> Message-ID: <068.5c2e20fea72c6b76c57c6123af5e5263@kirei.se> #122: try again ----------------------------------+----------------------------------------- Reporter: evil500@? | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 24 23:36:11 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 23:36:11 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #118: mysql enabled build fails when it cannot found mysql command In-Reply-To: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> References: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> Message-ID: <074.da6265a64f40d4f25bcd65e0fc7c544f@kirei.se> #118: mysql enabled build fails when it cannot found mysql command ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): You need the command in order to setup the database, right? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 24 23:38:50 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Mar 2010 23:38:50 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #120: configure --disable-mysql complains about missing mysql and fails In-Reply-To: <065.a3154e476495b7f82c3bd62a450af5b4@kirei.se> References: <065.a3154e476495b7f82c3bd62a450af5b4@kirei.se> Message-ID: <074.ac22d8794f6fe76df0d3888aa52f760d@kirei.se> #120: configure --disable-mysql complains about missing mysql and fails ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: defect | Status: closed Priority: major | Component: Enforcer Version: trunk | Resolution: invalid Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid Comment: Trunk now uses --with-database-backend Select database backend (sqlite3|mysql) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Mar 25 00:43:24 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 25 Mar 2010 00:43:24 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #118: mysql enabled build fails when it cannot found mysql command In-Reply-To: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> References: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> Message-ID: <074.5cf6894993b00e031bcb574a518259c8@kirei.se> #118: mysql enabled build fails when it cannot found mysql command ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): But not when building the code, right? :) The build machine could be separate from production machine, and also production machine could be separate from database machine. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Thu Mar 25 01:47:05 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 25 Mar 2010 02:47:05 +0100 Subject: [Opendnssec-develop] Fw: [Opendnssec-user] auditor and rollover In-Reply-To: References: Message-ID: > Gilles is having problems because the auditor is complaining that RRSIGs do not include those for the algorithm of a retired key. So, should : > > a) the auditor not complain about missing RRSIGs for algorithms for which all keys in the zone have been retired (although still published)? or > b) the zone not include keys with algorithms for which there are no RRSIGs? RFC4035 - Section 2.2 ---- There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. ---- Does this mean the following?: * Rolling to a new ZSK algorithm: The prepublished ZSK must sign the DNSKEY RRset until we can sign the rest of the zone with the ZSK, once it is ready. * We cannot roll both the KSK and ZSK to a new algorithm at the same time (retiring them at the same time), since the old KSK algorithm must sign the DNSKEY RRset until the old ZSK does not need to be postpublished. // Rickard From rickard.bellgrim at iis.se Thu Mar 25 01:56:50 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 25 Mar 2010 02:56:50 +0100 Subject: [Opendnssec-develop] Standby KSKs In-Reply-To: References: Message-ID: Are people happy with this? and If so, should the auditor be patched for this new behaviour before we go to v1.1? +1 But the only problem is that some needs the DNSKEY in the zone in order to upload the DS RR using its registrar. One example is our own registrar .SE Direkt. They pull DNSKEY data and present the information to the user, who then choose which DS to upload. The standby keys can thus not be uploaded to .SE using our own registrar. This behavior in .SE Direkt could be treated as broken. And I will discuss this with our developers. There should also be an option to add DS RR to which there is to corresponding DNSKEY in the zone. // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Thu Mar 25 02:01:36 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 25 Mar 2010 03:01:36 +0100 Subject: [Opendnssec-develop] NSEC next_domain in canonical form In-Reply-To: References: Message-ID: <42212660-143A-4984-9375-E70E8938CBCE@iis.se> So, when dnsruby calculates the signature of an RRSet, it uses the canonical form of the NSEC record. In this case, that means changing "C.in-add-servers.arpa" to "c.in-addr-servers.arpa", just like it changes the "B.in-addr-servers.arpa" to "b.in-addr-servers.arpa". This gives it a different message digest to ldns (which downcases the "B", but keeps the "C" upcase). So, I was wondering if it was just me who took a different interpretation away from the spec, or whether this should be clarified somewhere. I was also hoping that somebody could give me a definitive answer on what the right thing to do with an NSEC next_domain is. It does seem odd to me that this is not canonicalised - after all, it already obeys the "no compression" rule for canonical names... [Side question - if I'm wrong, then what happens if the domain name in the next_domain field is spelled in several different mixed-case ways in the zone? Which one makes the NSEC record?] Matthijs, what do you say? // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Thu Mar 25 07:51:31 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 25 Mar 2010 07:51:31 +0000 Subject: [Opendnssec-develop] NSEC next_domain in canonical form In-Reply-To: <42212660-143A-4984-9375-E70E8938CBCE@iis.se> References: <42212660-143A-4984-9375-E70E8938CBCE@iis.se> Message-ID: opendnssec-develop-bounces at lists.opendnssec.org wrote on 25/03/2010 02:01:36: > Rickard Bellgrim > Sent by: opendnssec-develop-bounces at lists.opendnssec.org > > 25/03/2010 02:01 > > To > > " " > > cc > > "Opendnssec-develop at lists.opendnssec.org" develop at lists.opendnssec.org>, "apt at nominet.org.uk" > > Subject > > Re: [Opendnssec-develop] NSEC next_domain in canonical form > > So, when dnsruby calculates the signature of an RRSet, it uses the > canonical form of the NSEC record. In this case, that means changing > "C.in-add-servers.arpa" to "c.in-addr-servers.arpa", just like it > changes the "B.in-addr-servers.arpa" to "b.in-addr-servers.arpa". > This gives it a different message digest to ldns (which downcases > the "B", but keeps the "C" upcase). > > So, I was wondering if it was just me who took a different > interpretation away from the spec, or whether this should be > clarified somewhere. I was also hoping that somebody could give me a > definitive answer on what the right thing to do with an NSEC > next_domain is. It does seem odd to me that this is not > canonicalised - after all, it already obeys the "no compression" > rule for canonical names... I think ldns has signed this wrong (and also that BIND verifies it wrong). RFC 4034 states : 6.2. Canonical RR Form For the purposes of DNS security, the canonical form of an RR is the wire format of the RR where: 1. every domain name in the RR is fully expanded (no DNS name compression) and fully qualified; 2. all uppercase US-ASCII letters in the owner name of the RR are replaced by the corresponding lowercase US-ASCII letters; 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in the DNS names contained within the RDATA are replaced by the corresponding lowercase US-ASCII letters; which hasn't been the case here. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Thu Mar 25 15:57:20 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 25 Mar 2010 16:57:20 +0100 Subject: [Opendnssec-develop] No RRSIG in .signed.sorted Message-ID: Hi Is it correct that there should be no RRSIG in the .signed.sorted? Or isn't this file used for reuse of signatures? Because it looks like these are dropped. // Rickard From matthijs at NLnetLabs.nl Thu Mar 25 16:12:50 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 25 Mar 2010 17:12:50 +0100 Subject: [Opendnssec-develop] No RRSIG in .signed.sorted In-Reply-To: References: Message-ID: <4BAB8B82.8070404@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes. The sorter drops RRSIGs and NSEC(3)s. Perhaps we should add a flag to the quicksorter that it should only drop these records when the flag isn't set? Beware of the zone reader, it expects RRSIGs always to be *after* the corresponding RRset Matthijs Rickard Bellgrim wrote: > Hi > > Is it correct that there should be no RRSIG in the .signed.sorted? Or isn't this file used for reuse of signatures? Because it looks like these are dropped. > > // 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLq4uAAAoJEA8yVCPsQCW5XecH/i3ECouViIl37UzFmjTT5jD7 ECXPrWV+lvIyONwAlVTt9GU1dAnFXVv8nvlKfMmPKbGadSk66B/wi5g0ERUFBhYa 3LoS1MCLH4ioNq7dcBiQKDIwEjI3s527WtrrxyKYuHWoLGnsfGoeCtNfFRTC1mdx OeGQh9yINpgD06AqR284EvcQxdcaUQcX/BLsUkFUsu/E162e6GqVmm0CbveFkIYj NODhz0fIRU/HY8Zj+r+wNdsb4w8UNJZtFiV1goX+7OAPQmuHlCbLsNa1T/6G1TJN jZRUv4qBbYL5sMiYXvB2iuOnGCSoVp+QrWecrBRwwTS2170kkWtFMAwmKGSaSVI= =YLgx -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Thu Mar 25 16:20:00 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 25 Mar 2010 17:20:00 +0100 Subject: [Opendnssec-develop] No RRSIG in .signed.sorted In-Reply-To: <4BAB8B82.8070404@nlnetlabs.nl> References: <4BAB8B82.8070404@nlnetlabs.nl> Message-ID: <3027AC7E-6600-47D6-88E7-15F25044CE98@iis.se> > Yes. The sorter drops RRSIGs and NSEC(3)s. Perhaps we should add a flag > to the quicksorter that it should only drop these records when the flag > isn't set? Hmm, but this is the same behavior as in v1.0. That there is no RRSIG in .signed.sorted > Beware of the zone reader, it expects RRSIGs always to be *after* the > corresponding RRset The RRSIG is not always after the corresponding RRset. If the quicksorter would not drop the signatures, then any RR with a higher RR type number would get sorted after the RRSIG. // Rickard From rickard.bellgrim at iis.se Thu Mar 25 16:33:10 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 25 Mar 2010 17:33:10 +0100 Subject: [Opendnssec-develop] No RRSIG in .signed.sorted In-Reply-To: <3027AC7E-6600-47D6-88E7-15F25044CE98@iis.se> References: <4BAB8B82.8070404@nlnetlabs.nl> <3027AC7E-6600-47D6-88E7-15F25044CE98@iis.se> Message-ID: <398BEA50-0353-45A4-B696-F634B5EAB4AF@iis.se> > Hmm, but this is the same behavior as in v1.0. That there is no RRSIG in .signed.sorted Does this imply that we will drop all signatures each month when we roll the ZSK? And each year when we roll the KSK? And when the old ZSK is not postpublished? ... Essentially every time when the DNSKEY RRset changes? http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/signer/signer_engine/ZoneConfig.py#L94 // Rickard From matthijs at NLnetLabs.nl Thu Mar 25 16:57:41 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 25 Mar 2010 17:57:41 +0100 Subject: [Opendnssec-develop] No RRSIG in .signed.sorted In-Reply-To: <3027AC7E-6600-47D6-88E7-15F25044CE98@iis.se> References: <4BAB8B82.8070404@nlnetlabs.nl> <3027AC7E-6600-47D6-88E7-15F25044CE98@iis.se> Message-ID: <4BAB9605.2010807@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bellgrim wrote: >> Yes. The sorter drops RRSIGs and NSEC(3)s. Perhaps we should add a flag >> to the quicksorter that it should only drop these records when the flag >> isn't set? > > Hmm, but this is the same behavior as in v1.0. That there is no RRSIG in .signed.sorted Ah ok, than indeed we don't keep signature when the policy changed. > >> Beware of the zone reader, it expects RRSIGs always to be *after* the >> corresponding RRset > > The RRSIG is not always after the corresponding RRset. > > If the quicksorter would not drop the signatures, then any RR with a higher RR type number would get sorted after the RRSIG. Yes, so if we go down that path, we must take that into account (either change the zone_reader or adapt the sorting in the quicksorter) Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLq5YDAAoJEA8yVCPsQCW5+fYH/ifZLIu0uWLU28EaVwATIR+o xQkXTK202kT1F/iDNxWyKKlj7CAQo0yqqsGbobhDbFs3D7JseW8fplRKliSOuVzm 0KBzZI1yfFM6OC27Nii2Po6Qkb+i+6I3tqfFrXhNUNKcq3qd1dxzZOgW9qFo8Mzc 3tdiHLLBWpzu44Jc9pZty3FVsLwC46WKp3TLhHKMUhQJfqEIFYja4CXn9q17Awuv 1UdYCH8FXvOrzdfApmLY4K3TSB5pRICJTAPzAzCwzJ/hT0OAIsjOdAwjOHlvf45Z U9tBAEf95T44ricUX1peCbMyhyop3LceTfiMAHC5zNphVdR2n/WNAA1yyj9LVvU= =U2u4 -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Thu Mar 25 17:02:00 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 25 Mar 2010 18:02:00 +0100 Subject: [Opendnssec-develop] No RRSIG in .signed.sorted In-Reply-To: <398BEA50-0353-45A4-B696-F634B5EAB4AF@iis.se> References: <4BAB8B82.8070404@nlnetlabs.nl> <3027AC7E-6600-47D6-88E7-15F25044CE98@iis.se> <398BEA50-0353-45A4-B696-F634B5EAB4AF@iis.se> Message-ID: <4BAB9708.40103@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bellgrim wrote: >> Hmm, but this is the same behavior as in v1.0. That there is no RRSIG in .signed.sorted > > Does this imply that we will drop all signatures each month when we roll the ZSK? And each year when we roll the KSK? And when the old ZSK is not postpublished? ... Essentially every time when the DNSKEY RRset changes? > > http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/signer/signer_engine/ZoneConfig.py#L94 > > // Rickard Yes. This however can be changed easily in the upcoming C engine. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLq5cGAAoJEA8yVCPsQCW5Zi8H/0S3ti4/dxRU9ItCzEtK/2v0 oEdpqALqJt6Qx7McmhizDaieKloWgWHgYJGmYr3CwbYdxFhHvJAyVO/rnkPPH7TJ HX5ejL4n+pynZIcxfEI0tVrzzsgBZW6Wm8qkn9TaW/ey+QjBhv/mMQNNyQjBfukG GOemXGlVYyExStLcMmHn0geUlqnH9O4W1Jgd/+HlRTN+FxVHTpE6ITeUZLk5jDOT zZFFpx2ydq+b2AGOHhlgl0dDdgbANu4iKtoNF6NPKbtkMbMvoEMe5WjhnLRGaIij jPegcRENtwHGZV3us7a1E/xlMe4v/AgVTLsIRtANtcJJIgUafa9GaRp8Q9vEr6g= =Xl/n -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Thu Mar 25 21:24:22 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 25 Mar 2010 22:24:22 +0100 Subject: [Opendnssec-develop] NSEC next_domain in canonical form In-Reply-To: References: Message-ID: <4BABD486.4030205@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I tried a zone on my machine, with mixed uppercase/lowercase domain names. The signer creates nicely NSEC records, with lower case domain names on the right side. Could it be that a local setting on your machine ignores the effect of lowercasing (tolower) ? Best regards, Matthijs Alexd at nominet.org.uk wrote: > Hi - > > I've been looking at the problems reported by Dave Knight to OpenDNSSEC, > where a zone with : > > B.in-addr-servers.arpa. 3600 IN NSEC > C.in-addr-servers.arpa. A AAAA RRSIG NSEC > > will not verify correctly in the auditor (it does with bind and ldns). > > The problem is with the capital "C" in the NSEC record. RFC 4034 states : > > The Next Domain field contains the next owner name (in the canonical > ordering of the zone) that has authoritative data or contains a > delegation point NS RRset > > The canonical ordering section then states : > > For the purposes of DNS security, owner names are ordered by treating > individual labels as unsigned left-justified octet strings. The > absence of a octet sorts before a zero value octet, and uppercase > US-ASCII letters are treated as if they were lowercase US-ASCII > letters. > > In dnsruby, I had taken this to mean that the NSEC record should contain > the canonical form of the next domain in the canonically sorted zone. > > So, when dnsruby calculates the signature of an RRSet, it uses the > canonical form of the NSEC record. In this case, that means changing > "C.in-add-servers.arpa" to "c.in-addr-servers.arpa", just like it > changes the "B.in-addr-servers.arpa" to "b.in-addr-servers.arpa". This > gives it a different message digest to ldns (which downcases the "B", > but keeps the "C" upcase). > > So, I was wondering if it was just me who took a different > interpretation away from the spec, or whether this should be clarified > somewhere. I was also hoping that somebody could give me a definitive > answer on what the right thing to do with an NSEC next_domain is. It > does seem odd to me that this is not canonicalised - after all, it > already obeys the "no compression" rule for canonical names... > > [Side question - if I'm wrong, then what happens if the domain name in > the next_domain field is spelled in several different mixed-case ways in > the zone? Which one makes the NSEC record?] > > Thanks, > > > Alex. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLq9SAAAoJEA8yVCPsQCW5i90H/0nsgkRlYLeu9JIhnfEx0ET4 Ke8VEedZTedmDr8oM1v75UHzmRAgAwZDKlbn7cDy0wVZHTR4MJk7+U9/yAK/jDiv oXyt+n7g4RibBuJ5hOuWJUpESysFPGX0P+aVXd6IgzNLV26dY2id/FvZ/Zr0d1c6 5o7EbJvdv2Bao11Wso95NLFsw8zJCWLxg6PLi3CYd3cSBQs57FAwjtdoRbaRbRub QVAHNKPYvbCqwkPY4P2/4q+akfRg0EJUvtpmj7sOxdFcjuiM+kQ4iNGeWlgz/8im lE/alv3h/z8opR91xFRtuJKsjWSpyuDNCuL/Bl0j4kafoBD9XYbH90nU6X6kL7A= =B2fC -----END PGP SIGNATURE----- From Alexd at nominet.org.uk Fri Mar 26 06:59:53 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Fri, 26 Mar 2010 06:59:53 +0000 Subject: [Opendnssec-develop] NSEC next_domain in canonical form In-Reply-To: <4BABD486.4030205@nlnetlabs.nl> References: <4BABD486.4030205@nlnetlabs.nl> Message-ID: > I tried a zone on my machine, with mixed uppercase/lowercase domain > names. The signer creates nicely NSEC records, with lower case domain > names on the right side. > > Could it be that a local setting on your machine ignores the effect of > lowercasing (tolower) ? The thing is that Dave reports that BIND/LDNS both verify the zone (which has been signed with uppercase NSEC rdata). Dnsruby fails it, as it downcases the rdata, as specified by RFC4034. Regardless of how the zone has been created, these libraries should *not* verify the zone. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Fri Mar 26 11:59:40 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Fri, 26 Mar 2010 11:59:40 +0000 Subject: [Opendnssec-develop] Fw: [Opendnssec-user] auditor and rollover In-Reply-To: References: Message-ID: > > Gilles is having problems because the auditor is complaining that > RRSIGs do not include those for the algorithm of a retired key. So, should : > > > > a) the auditor not complain about missing RRSIGs for algorithms > for which all keys in the zone have been retired (although still > published)? or > > b) the zone not include keys with algorithms for which there are no RRSIGs? > > RFC4035 - Section 2.2 > ---- > There MUST be an RRSIG for each RRset using at least one DNSKEY of > each algorithm in the zone apex DNSKEY RRset. > ---- > > Does this mean the following?: > > * Rolling to a new ZSK algorithm: The prepublished ZSK must sign > the DNSKEY RRset until we can sign the rest of the zone with the > ZSK, once it is ready. > > * We cannot roll both the KSK and ZSK to a new algorithm at the > same time (retiring them at the same time), since the old KSK > algorithm must sign the DNSKEY RRset until the old ZSK does not need > to be postpublished. Anyone? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Fri Mar 26 16:38:15 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 26 Mar 2010 17:38:15 +0100 Subject: [Opendnssec-develop] Fw: [Opendnssec-user] auditor and rollover In-Reply-To: References: Message-ID: <4BACE2F7.9090604@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexd at nominet.org.uk wrote: >> > Gilles is having problems because the auditor is complaining that >> RRSIGs do not include those for the algorithm of a retired key. So, > should : >> > >> > a) the auditor not complain about missing RRSIGs for algorithms >> for which all keys in the zone have been retired (although still >> published)? or >> > b) the zone not include keys with algorithms for which there are no > RRSIGs? >> >> RFC4035 - Section 2.2 >> ---- >> There MUST be an RRSIG for each RRset using at least one DNSKEY of >> each algorithm in the zone apex DNSKEY RRset. >> ---- RFC 4035 also says: The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). >> Does this mean the following?: >> >> * Rolling to a new ZSK algorithm: The prepublished ZSK must sign >> the DNSKEY RRset until we can sign the rest of the zone with the >> ZSK, once it is ready. If you roll a new ZSK algorithm, you actually might need to make it a signing, non-published key first, in order to propagate its signatures to the cache resolvers. I believe the DNSKEY RRset itself does not have to be signed by any of the ZSKs, as long as it is signed with each of the algorithms signalled by the DS RRset in the parent. Though there was some dispute about that, one and a half year ago on the dnsop ml (search for: [DNSOP] suggestion for 4641bis: key algorithm rollover section). >> * We cannot roll both the KSK and ZSK to a new algorithm at the >> same time (retiring them at the same time), since the old KSK >> algorithm must sign the DNSKEY RRset until the old ZSK does not need >> to be postpublished. So, with that additional quote from rfc4035, I think you can roll algorithms for KSK and ZSK independently. > > Anyone? > Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLrOLyAAoJEA8yVCPsQCW53HcH/R6/RQzPrGVUuZOpHDgKpKmm ftpUz1ftB9x5yubc74eJUxno2scf7kXoCyIE9jrkie5j1roLIQscAL43eLU62CQj yJaT2sKHkFHjEADhQxYp7WM9NMVRvuW1PhtJ6LsiuxgvfODpafMGs7DCTscl8WoX vv6AY7WJIoHJ2cA3Iaf583ulFbr4EUiWEc247VrQjqVms04dIIiJRUQHaFU74hlk ZyMqbuscIOfUYFJ5/PDJ04bxXEO4Z5p0bodEx7y0lANtadGFiQI+7DlOgzIhy3Es Ho5ZEPhfAwAn+VTp1dwtgFWGYnuPY+nbhHgGaJ+MDRRdLQCk3nK/Hxeu1N+CoTw= =ydVk -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Fri Mar 26 16:45:16 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 26 Mar 2010 17:45:16 +0100 Subject: [Opendnssec-develop] Fw: [Opendnssec-user] auditor and rollover In-Reply-To: <4BACE2F7.9090604@nlnetlabs.nl> References: <4BACE2F7.9090604@nlnetlabs.nl> Message-ID: <3769BA78-D3F4-4664-B543-C66BBD79A8B1@iis.se> So, with that additional quote from rfc4035, I think you can roll algorithms for KSK and ZSK independently. So is the conclusion that the Enforcer should handle algorithm rollovers different from key rollovers? Which would be a headache for Sion, and thereby something for v1.X. Please update KNOWN_ISSUES // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Fri Mar 26 17:45:47 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 26 Mar 2010 18:45:47 +0100 Subject: [Opendnssec-develop] Status of 1.1.0-rc1 In-Reply-To: References: <4C5CD395-1E02-4C4A-8375-687D6F5F152A@iis.se> Message-ID: Hi This is the current status: Open issues: * Auditor complains about DNSKEY from unsigned zone if it does not match the policy. * What about the other Auditor issues? * Have to verify the fix of the NSEC issue * Zonefetcher port bindings Issues that will be known in v1.1: * Upload of DNSKEY/DS to parent is experimental / untested * Problems adding zones when sharing keys * Dropping RRSIGs when rolling keys * Problem rolling algorithm Is there something more? How to you feel of an upcoming RC1 or beta? // Rickard From Alexd at nominet.org.uk Fri Mar 26 17:47:27 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Fri, 26 Mar 2010 17:47:27 +0000 Subject: [Opendnssec-develop] Status of 1.1.0-rc1 In-Reply-To: References: <4C5CD395-1E02-4C4A-8375-687D6F5F152A@iis.se> Message-ID: > * What about the other Auditor issues? It needs a default working directory. I can do both of these next week. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Fri Mar 26 17:48:06 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 26 Mar 2010 17:48:06 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #118: mysql enabled build fails when it cannot found mysql command In-Reply-To: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> References: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> Message-ID: <074.471c883c4391bfe8bbd63dc173efd2db@kirei.se> #118: mysql enabled build fails when it cannot found mysql command ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): But we need to find the path to the binary -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Fri Mar 26 17:54:48 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 26 Mar 2010 18:54:48 +0100 Subject: [Opendnssec-develop] Status of 1.1.0-rc1 In-Reply-To: References: <4C5CD395-1E02-4C4A-8375-687D6F5F152A@iis.se> Message-ID: <4BACF4E8.9050601@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * MacOSX malloc error in zone_reader. I did some small memory management changes in the code, though I still have troubles triggering this error. Rickard Bellgrim wrote: > Hi > > This is the current status: > > Open issues: > * Have to verify the fix of the NSEC issue This issue is a 1.0.0 error and it did not affect the trunk. Though I added ldns_rr2canonical in the zone_reader, I believe the quicksorter already canonicalized the RRs. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLrPTlAAoJEA8yVCPsQCW51WIIAJcnytOTnFVtF1KQpOF9jpFa PPuQMeu73snUvQ2m758FIxPbZGglr3cVe6iH8Wre0Lf1I9tBY7JMKcGuUGQUzaYv kACZWd/uBcK0HEw/uveQFByaibveL00IWEX1R6uN7gYA3bmT/vX0qnojuymylEuu XjJLHKZZkFknNR/NumIDVHM8v6xWnkgJLKU4CShQ0D4K/WSlR6lhVmiaxcO3MJQp PwS91QIiDu23al6nb95X3Q1/hReIFGDVW/PbDi+fM03LdZACwELswajMUo83n8Hu PIAIwZiEEvVGZyC/W1+g9zgEjrJT5tunOFraV0btKYWclOAYgJyuWtFVaAsc1+c= =ft8b -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Fri Mar 26 18:19:32 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 26 Mar 2010 18:19:32 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #118: mysql enabled build fails when it cannot found mysql command In-Reply-To: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> References: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> Message-ID: <074.8a7394dc761774e653097b224d5a25a5@kirei.se> #118: mysql enabled build fails when it cannot found mysql command ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Replying to [comment:3 rb]: > But we need to find the path to the binary Ah, I see, it was hidden under SQL_BIN macro, that's why I didn't discovered it on first try. Ok, makes sense. Please mark this bug as invalid. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Mar 26 18:28:39 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 26 Mar 2010 18:28:39 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #118: mysql enabled build fails when it cannot found mysql command In-Reply-To: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> References: <065.07aa2578cdd7eac38cb4f3e616fb9b9c@kirei.se> Message-ID: <074.1aad815c42cdc6bd589a536bb5367ad4@kirei.se> #118: mysql enabled build fails when it cannot found mysql command ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: defect | Status: closed Priority: major | Component: Enforcer Version: trunk | Resolution: invalid Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Mon Mar 29 09:54:50 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 29 Mar 2010 11:54:50 +0200 Subject: [Opendnssec-develop] drop ods-signer restart Message-ID: <4BB078EA.9090600@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On bugreport #113: zone fetcher can't bind udp/ipv4 socket: Permission denied. During IEFT77, we have talked about that this is not only an issue when starting the engine, but also with restarting. Several believed that restart should actually be stop and start. There are a couple of nasty hacks I can do in order to check if we have the right privileges to restart (so that we don't successfully stop the daemon, but are unable to start it again). With this knowledge, I want to propose to drop the restart command, as this is cleaner in code, and there is no loss in functionality because you can do the same with stop && start. Any objections? Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLsHjoAAoJEA8yVCPsQCW5G5cH/2UKbj5NJ8bbqQiF1vNA8pwB z3KVdtDFhO8iEcskreb7H+zQqNlzYdE1uWHZCdrCRBTSNSLzVsLcPvL+6BOMWnA3 jTJno7R05DxqYSsPCfORPhJDQ5/nmUnuP7RVDMkaStFLyyzG729jOQ7Tw3or4WQu DiiTYbW9eP12ujIEQ16+LI0GVZ4odxJGO1jMFsmqzMTENiO3WHMnces4BRKT7Sq+ R36UuXKMSYcGwzd+b5rswy40+v70kFBX41Y1L2eRorzR16G/+Oetn81phEwxi//c DyBQrgDf95JPrOFMDdHZXLlhPqaWaKT935xX+lIxnXt7f79OYpj5vuEXjgLeblw= =2Tpp -----END PGP SIGNATURE----- From patrik.wallstrom at iis.se Mon Mar 29 09:56:09 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Mon, 29 Mar 2010 11:56:09 +0200 Subject: [Opendnssec-develop] drop ods-signer restart In-Reply-To: <4BB078EA.9090600@nlnetlabs.nl> References: <4BB078EA.9090600@nlnetlabs.nl> Message-ID: <0241D495-0A72-4F5C-8B6F-0E150EC043DE@iis.se> On Mar 29, 2010, at 11:54 AM, Matthijs Mekking wrote: > Hi, > > On bugreport #113: zone fetcher can't bind udp/ipv4 socket: Permission > denied. > > During IEFT77, we have talked about that this is not only an issue when > starting the engine, but also with restarting. Several believed that > restart should actually be stop and start. There are a couple of nasty > hacks I can do in order to check if we have the right privileges to > restart (so that we don't successfully stop the daemon, but are unable > to start it again). > > With this knowledge, I want to propose to drop the restart command, as > this is cleaner in code, and there is no loss in functionality because > you can do the same with stop && start. > > Any objections? No, this is better. Then it is up to the package maintainer to implement restart using stop and start in the init-scripts if he wants to. -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From owner-dnssec-trac at kirei.se Mon Mar 29 10:18:30 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 29 Mar 2010 10:18:30 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #113: zone fetcher can't bind udp/ipv4 socket: Permission denied In-Reply-To: <060.75681192b0c276f032f77302a7d2b3f7@kirei.se> References: <060.75681192b0c276f032f77302a7d2b3f7@kirei.se> Message-ID: <069.dabd286a174fd8e02dfd023d37c61663@kirei.se> #113: zone fetcher can't bind udp/ipv4 socket: Permission denied -----------------------------------+---------------------------------------- Reporter: shinya.umino@? | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: 1.0.0 | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed Comment: Fixed in trunk by starting the zone fetcher before dropping privileges. Soon in next release. Thanks for the report! -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Mar 29 10:21:23 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 29 Mar 2010 10:21:23 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #117: Support for bind's $GENERATE? In-Reply-To: <078.ae7e316f471bd6fd4ba817ce78330e74@kirei.se> References: <078.ae7e316f471bd6fd4ba817ce78330e74@kirei.se> Message-ID: <087.1cde0189ac339ef6b974386946324afc@kirei.se> #117: Support for bind's $GENERATE? -----------------------------------------------------+---------------------- Reporter: Gilles Massen | Owner: matthijs Type: enhancement | Status: closed Priority: minor | Component: Signer Version: 1.0.0 | Resolution: wontfix Keywords: | -----------------------------------------------------+---------------------- Changes (by matthijs): * status: new => closed * resolution: => wontfix Comment: Imho, I believe this is feature creep. You can use any preprocessor you want for this, does not necessarily need a complete BIND for this. A shell script will also be able to get the desired result. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Mar 30 13:00:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 30 Mar 2010 13:00:55 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #123: unable to handle zone views Message-ID: <057.543743b33fc7d55b716158d73c0001fa@kirei.se> #123: unable to handle zone views --------------------------------+------------------------------------------- Reporter: gotenxiao@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: zone views --------------------------------+------------------------------------------- The tools cannot handle multiple zones with the same origin (as used in a traditional BIND view setup). For example: internal/example.com: {{{ $ORIGIN example.com. $TTL 86400 @ IN SOA ns hostmaster.example.com. ( 2010300300 604800 86400 2419200 86400 ) @ IN NS ns ns IN A 10.0.0.1 router IN A 10.0.0.1 @ IN A 10.0.0.110 privateserver IN A 10.0.0.10 publicserver IN A 10.0.0.110 }}} external/example.com: {{{ $ORIGIN example.com. $TTL 86400 @ IN SOA ns hostmaster.example.com. ( 2010300300 604800 86400 2419200 86400 ) @ IN NS ns @ IN A 192.0.32.10 ns IN A 192.0.32.10 publicserver IN A 192.0.32.10 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Mar 31 05:26:00 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 31 Mar 2010 05:26:00 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #123: unable to handle zone views In-Reply-To: <057.543743b33fc7d55b716158d73c0001fa@kirei.se> References: <057.543743b33fc7d55b716158d73c0001fa@kirei.se> Message-ID: <066.cfd21c2484af395d1778e61d39808a72@kirei.se> #123: unable to handle zone views --------------------------------+------------------------------------------- Reporter: gotenxiao@? | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: wontfix Keywords: zone views | --------------------------------+------------------------------------------- Changes (by jakob): * status: new => closed * resolution: => wontfix Comment: Yes, this is currently a limitation of OpenDNSSEC and we do not, at this time, have plans for handling views. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Wed Mar 31 09:24:22 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 31 Mar 2010 10:24:22 +0100 Subject: [Opendnssec-develop] v1.1 RC1 Message-ID: Morning, Do we have a clear idea of what we are now waiting for before releasing 1.1 rc1? Can we move the rejected stories in pivotal to below the 1.1 release marker? Sion From rickard.bellgrim at iis.se Wed Mar 31 09:41:12 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 31 Mar 2010 11:41:12 +0200 Subject: [Opendnssec-develop] v1.1 RC1 In-Reply-To: References: Message-ID: Do we have a clear idea of what we are now waiting for before releasing 1.1 rc1? Yes * Still have an issue with the auditor not accepting DNSKEY in the unsigned zone which does not correspond to the policy. * Could someone test that the privdrop for the zonefetcher works? * We are still struggling with dropped signatures during key rollover. Can we move the rejected stories in pivotal to below the 1.1 release marker? Done. // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Wed Mar 31 10:07:40 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 31 Mar 2010 12:07:40 +0200 Subject: [Opendnssec-develop] v1.1 RC1 In-Reply-To: References: Message-ID: <4BB31EEC.6020707@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Rickard Bellgrim wrote: > * We are still struggling with dropped signatures during key rollover. Currently a key rollover is done this way: 1. K1[a] -> K1[ac], K2[p] -> K1[p], K2[a] -> K2[a] Where a is active and p is publish. 2. If such a change happens in the enforcer, the signer will be notified: ods-signer update 3. The signer will resign when there is a change in the key set. 4. Because the signer has no knowledge of key rollovers, it just follows orders that are given in the signconf file, it will drop all signatures when K1 transitions to published state. It will create all new signatures with K2, because it just became active. I hear that there is a need between a smooth transition between step 2 and 3 of the key rollover process. However, this requires a new state: 'publish, but pre-generate signatures with this key if there are no fresh signatures for current active keys, but don't publish those signatures yet'. This will replace the publish state in the above situation. When the old key becomes inactive (but still is post-published), I think we should drop all old signatures, regardless of the freshness of these signatures, as they should not be propagated anymore towards the caches. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLsx7pAAoJEA8yVCPsQCW5hWQIAIaCeunaG3psgHE8DXhIfdq6 G2K8irCYgmGevS4NLKhEpz2AVrs7X7/ZvaT9xTPB/rC0ksp4z7r/1Jg7NQVoKrHP +OWsFB7/x3HkezYAriAmcFwFH8Jm1/BpsBixKaVKl13RL6AlgHhYGGmdPzn39qHR pfyzH6SgdlLHyfB6CvJm5eDtd2MkcNX0RIFcFtHob1yMPvssnYhuhWK0uIfhZ+n4 QKHvyhBHO2wbB32/yhfsnwGUXz6It/lxInkIu/YhL6vlAF3kQQ3tCojUIiPqDeW4 d59HDJfXn59XSYpmMU8k5lX65mwI1/Lss+7CBx3RyORdVQ6Xn4L02XUSq0+VbpQ= =JPyW -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Wed Mar 31 12:23:38 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 31 Mar 2010 14:23:38 +0200 Subject: [Opendnssec-develop] v1.1 RC1 In-Reply-To: <4BB31EEC.6020707@nlnetlabs.nl> References: <4BB31EEC.6020707@nlnetlabs.nl> Message-ID: Rickard Bellgrim wrote: * We are still struggling with dropped signatures during key rollover. I hear that there is a need between a smooth transition between step 2 and 3 of the key rollover process. However, this requires a new state: 'publish, but pre-generate signatures with this key if there are no fresh signatures for current active keys, but don't publish those signatures yet'. This will replace the publish state in the above situation. I just thought that this was what we were doing. Should this be considered as a known issue? Then only thing left before an RC1 is to test the privdrops for zonefetcher. // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Wed Mar 31 12:35:27 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 31 Mar 2010 14:35:27 +0200 Subject: [Opendnssec-develop] v1.1 RC1 In-Reply-To: References: <4BB31EEC.6020707@nlnetlabs.nl> Message-ID: <4BB3418F.6040708@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'll add it to the known issues then, since we cannot fix this before 1.1. Matthijs Rickard Bellgrim wrote: >> >> Rickard Bellgrim wrote: >>> * We are still struggling with dropped signatures during key rollover. >> >> I hear that there is a need between a smooth transition between step 2 >> and 3 of the key rollover process. However, this requires a new state: >> 'publish, but pre-generate signatures with this key if there are no >> fresh signatures for current active keys, but don't publish those >> signatures yet'. This will replace the publish state in the above >> situation. > > I just thought that this was what we were doing. Should this be > considered as a known issue? > > Then only thing left before an RC1 is to test the privdrops for zonefetcher. > > // 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLs0GNAAoJEA8yVCPsQCW5+PcH/3FYgDi3aWL7/nN/asIS2970 CfRlac0buja0k/K+CpM93L8OwXbDQpr/QFtaVDz1NJ1PHGMjGPPOnSdq1QdDZpQE WETeicNzwSeMDVf7ZGvHdxBsquexYWfrnIIvMd/Sjx5J1jU92ZnWU04nsAfs6BYN iHzTUS8T/JpYk7aVivYtHV09ZWeuQEQbbuqpsN9q44+T9T6aHUrVYh1XkTsZCBcl /hRldSg+YIWiQS9gMU/8eT7M4iga6sjxMtO4PgF17PWchXM9WRjflkRXWTdv2LaI crVeIj0/UkFIxw/GGxugR9SXm616kJsCycrdbxhTeaPhIXSH59wtH1npqO7vgaY= =pYyY -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Wed Mar 31 12:45:01 2010 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Wed, 31 Mar 2010 13:45:01 +0100 Subject: [Opendnssec-develop] v1.1 RC1 In-Reply-To: <4BB31EEC.6020707@nlnetlabs.nl> References: <4BB31EEC.6020707@nlnetlabs.nl> Message-ID: Matthijs Mekking wrote on 31/03/2010 11:07:40: > Rickard Bellgrim wrote: > > * We are still struggling with dropped signatures during key rollover. > > Currently a key rollover is done this way: > > 1. K1[a] -> K1[ac], K2[p] -> K1[p], K2[a] -> K2[a] > > Where a is active and p is publish. To avoid confusion, can I suggest that we use the term "retired" when a key is replaced. The sequence then becomes: 1. K1[a] -> K1[a], K2[p] -> K1[r], K2[a] -> K2[a] Where a is active, p is publish and r is retired. When a key moves to the retired state, no new signatures are created with it; it is only published in the zone to cope with RRSIGs created by it that may still be in the zone file or in caches. > > 2. If such a change happens in the enforcer, the signer will be > notified: ods-signer update > > 3. The signer will resign when there is a change in the key set. > > 4. Because the signer has no knowledge of key rollovers, it just follows > orders that are given in the signconf file, it will drop all > signatures when K1 transitions to published state. It will create all > new signatures with K2, because it just became active. The key timing draft ( http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02) take this into account by stating that the old key needs to be retained in the zone for a period of time equal to: Dsgn + Dprp + TTLsig ... where Dsgn is the time taken to re-sign the zone, i.e. the interval between the time the new key becomes active and the time that the last signature created with the old key is replaced. Dprp is the propagation delay, the time taken for any change to the zone to reach all slave servers. TTLsig is the TTL of the RRSIG record, the time taken for an RRSIG to expire from a resolver cache. In step 4 above, when a new key becomes active, the next run of the signer drops all RRSIGs created by the old key and replaces them with RRSIGs created with the new key. This is effectively setting Dsgn to 0; the old key needs to be retained for as long as it takes for the new signatures to reach all slave servers and then replace any cached signatures. > I hear that there is a need between a smooth transition between step 2 > and 3 of the key rollover process. However, this requires a new state: > 'publish, but pre-generate signatures with this key if there are no > fresh signatures for current active keys, but don't publish those > signatures yet'. This will replace the publish state in the above situation. The drawback of replacing signatures all at once is that if it is a large zone with a lot of signatures, the time taken to re-sign the zone may become significant. This can be overcome by creating the signatures over a period of time. The obvious approach being to replace the signatures only as they approach their expiry time. This fits in with the existing algorithm: in this case, Dsgn (the time taken to re-sign the zone) is non-zero, being equal to (signature validity period - refresh interval). The penalty is that the second key, K2, is in the zone for longer than it would otherwise be. However, implementation of this option may be simpler than the option suggested above, i.e. generating (but not publishing) signatures when the new key appears. > When the old key becomes inactive (but still is post-published), I think > we should drop all old signatures, regardless of the freshness of these > signatures, as they should not be propagated anymore towards the caches. If we can do this within time constraints, this is simpler still. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Wed Mar 31 13:17:43 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 31 Mar 2010 15:17:43 +0200 Subject: [Opendnssec-develop] v1.1 RC1 In-Reply-To: References: <4BB31EEC.6020707@nlnetlabs.nl> Message-ID: <4BB34B77.5050601@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen.Morris at nominet.org.uk wrote: > Matthijs Mekking wrote on 31/03/2010 11:07:40: > >> Rickard Bellgrim wrote: >> > * We are still struggling with dropped signatures during key rollover. >> >> Currently a key rollover is done this way: >> >> 1. K1[a] -> K1[ac], K2[p] -> K1[p], K2[a] -> K2[a] >> >> Where a is active and p is publish. > > To avoid confusion, can I suggest that we use the term "retired" when a > key is replaced. The sequence then becomes: > > 1. K1[a] -> K1[a], K2[p] -> K1[r], K2[a] -> K2[a] > > Where a is active, p is publish and r is retired. > > When a key moves to the retired state, no new signatures are created > with it; it is only published in the zone to cope with RRSIGs created by > it that may still be in the zone file or in caches. > >> >> 2. If such a change happens in the enforcer, the signer will be >> notified: ods-signer update >> >> 3. The signer will resign when there is a change in the key set. >> >> 4. Because the signer has no knowledge of key rollovers, it just follows >> orders that are given in the signconf file, it will drop all >> signatures when K1 transitions to published state. It will create all >> new signatures with K2, because it just became active. > > The key timing draft > (http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02) > take this into account by stating that the old key needs to be retained > in the zone for a period of time equal to: > > Dsgn + Dprp + TTLsig > > ... where > > Dsgn is the time taken to re-sign the zone, i.e. the interval between > the time the new key becomes active and the time that the last signature > created with the old key is replaced. > > Dprp is the propagation delay, the time taken for any change to the zone > to reach all slave servers. > > TTLsig is the TTL of the RRSIG record, the time taken for an RRSIG to > expire from a resolver cache. > > In step 4 above, when a new key becomes active, the next run of the > signer drops all RRSIGs created by the old key and replaces them with > RRSIGs created with the new key. This is effectively setting Dsgn to 0; > the old key needs to be retained for as long as it takes for the new > signatures to reach all slave servers and then replace any cached > signatures. Yes. and this is what we currently do within OpenDNSSEC, I believe. >> I hear that there is a need between a smooth transition between step 2 >> and 3 of the key rollover process. However, this requires a new state: >> 'publish, but pre-generate signatures with this key if there are no >> fresh signatures for current active keys, but don't publish those >> signatures yet'. This will replace the publish state in the above > situation. > > The drawback of replacing signatures all at once is that if it is a > large zone with a lot of signatures, the time taken to re-sign the zone > may become significant. This can be overcome by creating the signatures > over a period of time. The obvious approach being to replace the > signatures only as they approach their expiry time. This fits in with > the existing algorithm: in this case, Dsgn (the time taken to re-sign > the zone) is non-zero, being equal to (signature validity period - > refresh interval). > The penalty is that the second key, K2, is in the zone for longer than > it would otherwise be. However, implementation of this option may be > simpler than the option suggested above, i.e. generating (but not > publishing) signatures when the new key appears. However, the signer cannot distinguish between a published or a retired key. What I get from this is that you propose to change the meaning of published with respect to the signer, that is: this key is published and should also replace signatures of other keys that are about to expire (should the current active key also create a signature over the same RRset). We need a new state, retired, that means: just publish this key, don't use it for signing (the current definition of publish). We really should think over what the signer should do in different use cases. As we will introduce algorithm rollover, I foresee new states in which the signer should not be published, but does need to publish signatures. >> When the old key becomes inactive (but still is post-published), I think >> we should drop all old signatures, regardless of the freshness of these >> signatures, as they should not be propagated anymore towards the caches. > > If we can do this within time constraints, this is simpler still. This is not an alternative, I think it is a requirement. Although if we have a state were the new key will pre-generate signatures, this switch is not that hard (computationally). Matthijs > > ------------------------------------------------------------------------ > > _______________________________________________ > 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLs0t1AAoJEA8yVCPsQCW5v/QIAKySTazITO45UuB1RMU6F24O 7o51LGVdzVsrnbXW1e4ZlRZJHHFNnOLFmoa0qZVU5t33fScOX9eZtM0IHG5sywQq 5ZAWmkTL5PH2cUistucMZ+Trz/pm4umOxBrtL/T1LKw69myGP9TRLxe+v8BDFwvb SVsfnwWiccyBw1mZszQq+qpa0yvFPgveWCl/Dyc1eNWwnb5cbbxWJe7b2v5Iwnmh r9lFLpCMO6XONQytGBB77yhvma/6qssRwg/25t8jkPfHJEaokCP7s3K/LoOgqZ45 rgc5z5CHCSaAyxCLPN/5rxvgGfrj+rz9KW9QS2Ofq2ych4t0AVRyKmCqY5G5X94= =p18e -----END PGP SIGNATURE-----