From owner-dnssec-trac at kirei.se Mon Aug 3 07:23:39 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 03 Aug 2009 07:23:39 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #2: Can not compile 1.0a1, problem with SoftHSM In-Reply-To: <058.9abe7503590c8a5934ab958506bad933@kirei.se> References: <058.9abe7503590c8a5934ab958506bad933@kirei.se> Message-ID: <067.3c7688eed5bfc7f03acdf4ae22919eef@kirei.se> #2: Can not compile 1.0a1, problem with SoftHSM ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: defect | Status: closed Priority: major | Component: SoftHSM Version: 1.0a1 | Resolution: fixed Keywords: SoftDatabase | ---------------------------------+------------------------------------------ Changes (by rb): * status: new => closed * resolution: => fixed Comment: Fixed in trunk. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 3 12:42:15 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 03 Aug 2009 12:42:15 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #5: Incorrect libksm install script, make install fails Message-ID: <058.7daea88ed9b35c1b2216d0054e708bee@kirei.se> #5: Incorrect libksm install script, make install fails ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: sion Type: defect | Status: new Priority: major | Component: libksm Version: 1.0a1 | Keywords: ---------------------------------+------------------------------------------ When running "make install" it fails at libksm: {{{ Making install in libksm make[1]: Entering directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm' Making install in src make[2]: Entering directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm/src' Making install in include make[3]: Entering directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm/src/include' Making install in ksm make[4]: Entering directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm/src/include/ksm' make install-am make[5]: Entering directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm/src/include/ksm' make[6]: Entering directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm/src/include/ksm' make[6]: Nothing to be done for `install-exec-am'. test -z "/usr/local/opendnssec/include/ksm" || /bin/mkdir -p "/usr/local/opendnssec/include/ksm" /usr/bin/install -c -m 644 config.h database.h database_statement.h datetime.h db_fields.h dbsdef.h dbsmsg.h debug.h kmedef.h kmemsg.h ksmdef.h ksm.h ksm_internal.h ksmutil.h ksm_version.h memory.h message.h parser.h string_util2.h string_util.h system_includes.h ./config.h ./database.h ./database_statement.h ./datetime.h ./db_fields.h ./dbsdef.h ./dbsmsg.h ./debug.h ./kmedef.h ./kmemsg.h ./ksmdef.h ./ksm.h ./ksm_internal.h ./ksmutil.h ./ksm_version.h ./memory.h ./message.h ./parser.h ./string_util2.h '/usr/local/opendnssec/include/ksm' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/config.h' with `./config.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/database.h' with `./database.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/database_statement.h' with `./database_statement.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/datetime.h' with `./datetime.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/db_fields.h' with `./db_fields.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/dbsdef.h' with `./dbsdef.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/dbsmsg.h' with `./dbsmsg.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/debug.h' with `./debug.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/kmedef.h' with `./kmedef.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/kmemsg.h' with `./kmemsg.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/ksmdef.h' with `./ksmdef.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/ksm.h' with `./ksm.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/ksm_internal.h' with `./ksm_internal.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/ksmutil.h' with `./ksmutil.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/ksm_version.h' with `./ksm_version.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/memory.h' with `./memory.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/message.h' with `./message.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/parser.h' with `./parser.h' /usr/bin/install: will not overwrite just-created `/usr/local/opendnssec/include/ksm/string_util2.h' with `./string_util2.h' make[6]: *** [install-ksmincludeHEADERS] Error 1 make[6]: Leaving directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm/src/include/ksm' make[5]: *** [install-am] Error 2 make[5]: Leaving directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm/src/include/ksm' make[4]: *** [install] Error 2 make[4]: Leaving directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm/src/include/ksm' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm/src/include' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm/src' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/mattias/opendnssec/build/OpenDNSSEC/libksm' make: *** [install-recursive] Error 1 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Mon Aug 3 12:58:10 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 3 Aug 2009 14:58:10 +0200 Subject: [Opendnssec-develop] linking libksm & libhsm statically Message-ID: I got some feedback that we might consider linking statically with libksm and libhsm for the ease of use. and not installing libraries nor headers. I think this is a good way to proceed for now. jakob From owner-dnssec-trac at kirei.se Mon Aug 3 13:30:17 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 03 Aug 2009 13:30:17 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #5: Incorrect libksm install script, make install fails In-Reply-To: <058.7daea88ed9b35c1b2216d0054e708bee@kirei.se> References: <058.7daea88ed9b35c1b2216d0054e708bee@kirei.se> Message-ID: <067.a08fc06ed799adda1833e4ae22538a3f@kirei.se> #5: Incorrect libksm install script, make install fails ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: defect | Status: accepted Priority: major | Component: libksm Version: 1.0a1 | Resolution: Keywords: | ---------------------------------+------------------------------------------ Changes (by rb): * owner: sion => rb * status: new => accepted Comment: Will revision 1448 from trunk work better for you? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 3 13:35:31 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 03 Aug 2009 13:35:31 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #5: Incorrect libksm install script, make install fails In-Reply-To: <058.7daea88ed9b35c1b2216d0054e708bee@kirei.se> References: <058.7daea88ed9b35c1b2216d0054e708bee@kirei.se> Message-ID: <067.23a1f6d84502683e683011735de76b01@kirei.se> #5: Incorrect libksm install script, make install fails ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: defect | Status: accepted Priority: major | Component: libksm Version: 1.0a1 | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by rb): It will not work, when I look at it now. Will send a new revision shortly. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 3 13:51:20 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 03 Aug 2009 13:51:20 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #5: Incorrect libksm install script, make install fails In-Reply-To: <058.7daea88ed9b35c1b2216d0054e708bee@kirei.se> References: <058.7daea88ed9b35c1b2216d0054e708bee@kirei.se> Message-ID: <067.690fb6791bcc30d3619d1b1e55860779@kirei.se> #5: Incorrect libksm install script, make install fails ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: defect | Status: accepted Priority: major | Component: libksm Version: 1.0a1 | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by rb): Revision 1449 should now fix your problem. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 3 20:43:14 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 03 Aug 2009 20:43:14 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #5: Incorrect libksm install script, make install fails In-Reply-To: <058.7daea88ed9b35c1b2216d0054e708bee@kirei.se> References: <058.7daea88ed9b35c1b2216d0054e708bee@kirei.se> Message-ID: <067.e0ad883962266d72cded775d202e1aad@kirei.se> #5: Incorrect libksm install script, make install fails ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: defect | Status: closed Priority: major | Component: libksm Version: 1.0a1 | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Changes (by jakob): * status: accepted => closed * resolution: => fixed Comment: User confirmed fixed. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 4 07:13:02 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 04 Aug 2009 07:13:02 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #6: softHSM install some files in unexpeted places Message-ID: <058.9a7b56f4df1a5d4f82767f4e6da96574@kirei.se> #6: softHSM install some files in unexpeted places ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: enhancement | Status: new Priority: trivial | Component: SoftHSM Version: | Keywords: ---------------------------------+------------------------------------------ ./configure \ --prefix=/usr/local/opendnssec \ --sysconfdir=/etc \ --localstatedir=/var "make install" puts some files in unexpected(?) places. /etc/softhsm.conf - wouldn't it make more sense to put it in /etc/opendnssec like the rest of the files? /var/softhsm/ - same here, wouldn't /var/opendnssec/softhsm make more sense? Yes, I told it to use /etc and /var but did not assume it would do it literaly since the other components use a subdirectory(opendnssec). -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 4 07:58:46 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 04 Aug 2009 07:58:46 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #7: softHSM links libsoftHSM to build directory Message-ID: <058.a0a898de9e47cea3b282182c283d387c@kirei.se> #7: softHSM links libsoftHSM to build directory ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: 1.0a1 | Keywords: ---------------------------------+------------------------------------------ {{{ [root at gozo ~]# ldd /usr/local/opendnssec/bin/softhsm linux-gate.so.1 => (0x00355000) libsofthsm.so.1 => /home/mattias/opendnssec/build/OpenDNSSEC/softHSM/src/lib/.libs/libsofthsm.so.1 (0x00ca1000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x04ebd000) libbotan-1.8.2.so => /usr/lib/libbotan-1.8.2.so (0x006e5000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x05508000) libm.so.6 => /lib/libm.so.6 (0x0062f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x003cd000) libc.so.6 => /lib/libc.so.6 (0x004b4000) libpthread.so.0 => /lib/libpthread.so.0 (0x00659000) /lib/ld-linux.so.2 (0x00490000) libbz2.so.1 => /lib/libbz2.so.1 (0x0511a000) libcrypto.so.8 => /usr/lib/libcrypto.so.8 (0x04d1d000) libgmp.so.3 => /usr/lib/sse2/libgmp.so.3 (0x00bf1000) librt.so.1 => /lib/librt.so.1 (0x006ab000) libz.so.1 => /lib/libz.so.1 (0x00676000) libdl.so.2 => /lib/libdl.so.2 (0x00628000) }}} libsofthsm.so.1 should be linked against your install directory (/usr/local/opendnssec/lib/libsofthsm.so.1) -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Tue Aug 4 08:03:54 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Tue, 4 Aug 2009 09:03:54 +0100 Subject: [Opendnssec-develop] Config question Message-ID: Hi - I've been looking at Pivotal issue 1018973. I have some questions regarding the system configuration - sorry if the answers are written down; I couldn't find them. Currently, the auditor uses zonelist.xml to find the .xml files for each zone, and do the auditing. This is apparently not good. So, I can look at conf.xml, kasp.xml and zonelist.xml, and get most of the info from there. However, these files do not specify the salt - this is potentially added from the DB, and not stored anywhere other than . So, I don't think it's possible to write the auditor without checking this file, unless the salt is queried directly from the DB. Should the auditor be checking the DB? Should the salt be stored somewhere the auditor can get it? Or should that be the only information lifted from ? Thanks! Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Tue Aug 4 08:18:37 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 04 Aug 2009 08:18:37 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #6: softHSM install some files in unexpeted places In-Reply-To: <058.9a7b56f4df1a5d4f82767f4e6da96574@kirei.se> References: <058.9a7b56f4df1a5d4f82767f4e6da96574@kirei.se> Message-ID: <067.e54cf2ebe1a918b4c7982aabd2f97c2f@kirei.se> #6: softHSM install some files in unexpeted places ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: enhancement | Status: closed Priority: trivial | Component: SoftHSM Version: | Resolution: wontfix Keywords: | ---------------------------------+------------------------------------------ Changes (by jakob): * status: new => closed * resolution: => wontfix Comment: Since SoftHSM is a more-or-less standalone package, we've choosen to put its configuration file directly under /etc. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Tue Aug 4 08:23:08 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 4 Aug 2009 10:23:08 +0200 Subject: [Opendnssec-develop] Config question In-Reply-To: References: Message-ID: <774171EA-48F7-4658-B1EA-43AC3928203F@kirei.se> On 4 aug 2009, at 10.03, Alexd at nominet.org.uk wrote: > I've been looking at Pivotal issue 1018973. I have some questions > regarding the system configuration - sorry if the answers are > written down; I couldn't find them. > > Currently, the auditor uses zonelist.xml to find the > .xml files for each zone, and do the auditing. This is > apparently not good. > > So, I can look at conf.xml, kasp.xml and zonelist.xml, and get most > of the info from there. However, these files do not specify the salt > - this is potentially added from the DB, and not stored anywhere > other than . So, I don't think it's possible to > write the auditor without checking this file, unless the salt is > queried directly from the DB. > > Should the auditor be checking the DB? > > Should the salt be stored somewhere the auditor can get it? Or > should that be the only information lifted from ? hmmm, you are correct. the salt is only to be found in the SignerConfiguration... as long as the policy is authoritative, I have no problem with looking at the SignerConfiguration. i.e., only parameters that are not to be found in the policy may be read from the SignerConfiguration. does this make sense? jakob From rickard.bondesson at iis.se Tue Aug 4 08:20:20 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 4 Aug 2009 10:20:20 +0200 Subject: [Opendnssec-develop] Config question In-Reply-To: References: Message-ID: <69830D4127201D4EBD146B9041199718E1E85E@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Hi - > > I've been looking at Pivotal issue 1018973. I have some > questions regarding the system configuration - sorry if the > answers are written down; I couldn't find them. > > Currently, the auditor uses zonelist.xml to find the > .xml files for each zone, and do the auditing. > This is apparently not good. The path to the zonelist.xml should come from conf.xml, because the location of zonelist.xml may be on another place than the conf.xml directory. > So, I can look at conf.xml, kasp.xml and zonelist.xml, and > get most of the info from there. However, these files do not > specify the salt - this is potentially added from the DB, and > not stored anywhere other than . So, I don't > think it's possible to write the auditor without checking > this file, unless the salt is queried directly from the DB. > > Should the auditor be checking the DB? No > Should the salt be stored somewhere the auditor can get it? > Or should that be the only information lifted from ? kasp.rnc says: - --- # The actual salt is generated by the Enforcer # Note: the enforcer may decide to store the # current salt in the DB and so it could be exported # here. xsd:string? - --- Is Enforcer doing this? Then it should just be to parse the kasp.xml // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSnfvQ+CjgaNTdVjaAQjrJwf+I+YOQPYqxu+1VqTsOM481ZH3c77TicvB 91+m05ax+HmmFaPjfCFdMthrudt6hI2jQ9EsVDoI9Q5LrRK6LPLw+pCMS2jcleqe fmOOKBGx42T8EW1HqYqB63ieMOyCXeshI2O5uS/vKHKazO7XTOuIu3h0dwSKwFUN k+iyXsZCdqFnEQUxS0ZfUZPgUXIZLtiNlqkL2O9ydmDVel7KJBZKi9zYZBXIy+d7 nn+oi19TDkB7ktzQW1Hx88dsIXcU8/OpCT6IzQxI8gVK9FfD7J6hZcWEDVTwaWK3 enA/IGLsHXtBcTaTmZB3csiz6eT78dn8ABtWLTE6uFmVvXc5tE05TA== =pe4u -----END PGP SIGNATURE----- From sion at nominet.org.uk Tue Aug 4 08:32:26 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 4 Aug 2009 09:32:26 +0100 Subject: [Opendnssec-develop] Config question In-Reply-To: <69830D4127201D4EBD146B9041199718E1E85E@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718E1E85E@EXCHANGE.office.nic.se> Message-ID: > > Should the salt be stored somewhere the auditor can get it? > > Or should that be the only information lifted from ? > > kasp.rnc says: > - --- > # The actual salt is generated by the Enforcer > # Note: the enforcer may decide to store the > # current salt in the DB and so it could be exported > # here. > xsd:string? > - --- > > Is Enforcer doing this? Then it should just be to parse the kasp.xml The enforcer doesn't write to the kasp.xml currently; might people monitor this file for changes to make sure that no-one is altering their policy? Or even revoke write permissions on it? If neither of these is an issue then I can change the enforcer. Sion From rickard.bondesson at iis.se Tue Aug 4 08:28:40 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 4 Aug 2009 10:28:40 +0200 Subject: [Opendnssec-develop] Config question In-Reply-To: <69830D4127201D4EBD146B9041199718E1E85E@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718E1E85E@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B9041199718E1E860@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > Should the salt be stored somewhere the auditor can get it? > > Or should that be the only information lifted from > ? > > kasp.rnc says: > --- > # The actual salt is generated by the Enforcer # Note: the > enforcer may decide to store the # current salt in the DB and > so it could be exported # here. > xsd:string? > --- > > Is Enforcer doing this? Then it should just be to parse the kasp.xml But to simplify stuff, then do as Jakob just described. And then the Enforcer do not need to output the salt to kasp.xml and only to the zone configuration as it is doing now. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSnfxOOCjgaNTdVjaAQhxKAf8CIm4pb+D1ETeJ9wre0vWQDOlEVgc9Bi3 V5bTCGN8tDLf7FW8tlGbp/iEiRJkz4tzPv36Ae5o05MmHAVRsacRwfYUajXcRRdk 2+WHXmqtCi6Q4UAWZBOP0gXunBW1wiyyzFk6z4qXfH16Pf9fDT0S2bBrUsHFvxDL RSnQcpmQjZBY/RNwXdxWdOXvsCGtU3q6IsAmr4NGWy0BwPNApCrtTjFNnwNQ+Ujb 0fpbjChhdPPjb+ypmHJe/NQDEbzt/309O7zolTuxZpRqLeGSsd2709qUzJ30wNq1 fyNH5gBcX6nDniWKXxn6r17W5z1goKjK47wZGEWVaelRCvhgnMJZfA== =Xain -----END PGP SIGNATURE----- From jakob at kirei.se Tue Aug 4 08:33:25 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 4 Aug 2009 10:33:25 +0200 Subject: [Opendnssec-develop] Config question In-Reply-To: <69830D4127201D4EBD146B9041199718E1E85E@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718E1E85E@EXCHANGE.office.nic.se> Message-ID: <0A9C276F-3E75-46C3-BE0A-FBD21264B3A8@kirei.se> On 4 aug 2009, at 10.20, Rickard Bondesson wrote: > kasp.rnc says: > - --- > # The actual salt is generated by the Enforcer > # Note: the enforcer may decide to store the > # current salt in the DB and so it could be exported > # here. > xsd:string? > - --- > > Is Enforcer doing this? Then it should just be to parse the kasp.xml it may store it here at export, but it should normally not be here (as it is generated by the Enforcer). we'll just let the Auditor read the SignerConfiguration for the salt. jakob From sion at nominet.org.uk Tue Aug 4 09:01:10 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 4 Aug 2009 10:01:10 +0100 Subject: [Opendnssec-develop] Config question In-Reply-To: <0A9C276F-3E75-46C3-BE0A-FBD21264B3A8@kirei.se> References: <69830D4127201D4EBD146B9041199718E1E85E@EXCHANGE.office.nic.se> <0A9C276F-3E75-46C3-BE0A-FBD21264B3A8@kirei.se> Message-ID: > > kasp.rnc says: > > - --- > > # The actual salt is generated by the Enforcer > > # Note: the enforcer may decide to store the > > # current salt in the DB and so it could be exported > > # here. > > xsd:string? > > - --- > > > > Is Enforcer doing this? Then it should just be to parse the kasp.xml > > it may store it here at export, but it should normally not be here (as > it is generated by the Enforcer). > we'll just let the Auditor read the SignerConfiguration for the salt. Should we ever look to store the salt in the kasp.xml, either on export or not? As it changes its value then you could argue that it is not really part of the policy. My slight concern here is that we have a value in kasp.xml that doesn't change and so gets out of sync with the SignerConfiguration. A slight aside, any salt in the kasp.xml is ignored by ksmutil; so there is no way to set an initial value. This means that you will have trouble importing an existing NSEC3 zone without some database hacking. (I can add a "ksmutil setsalt salt [policy]" command to overcome this.) Sion From owner-dnssec-trac at kirei.se Tue Aug 4 09:25:54 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 04 Aug 2009 09:25:54 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #8: softhsm --init -token hangs after entering PINs Message-ID: <058.853183f29282ffd46779ff62e22e6576@kirei.se> #8: softhsm --init -token hangs after entering PINs ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: 1.0a1 | Keywords: ---------------------------------+------------------------------------------ {{{ [root at gozo ~]# /usr/local/opendnssec/bin/softhsm --init-token --slot 0 --label OpenDNSSEC The SO PIN must have a length between 4 and 255 characters. Enter SO PIN: The user PIN must have a length between 4 and 255 characters. Enter user PIN: }}} process hangs infinitiv running {{{ strace /usr/local/opendnssec/bin/softhsm --init-token --slot 0 --label OpenDNSSEC ... lstat64("/proc/kmsg", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0 open("/proc/kmsg", O_RDONLY|O_NOCTTY) = 8 read(8, }}} resolves problem reading /proc/kmsg SELinux is disabled. (Standard 32-bit FC11 system) -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Tue Aug 4 14:28:49 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 4 Aug 2009 16:28:49 +0200 Subject: [Opendnssec-develop] libksm integrated into the enforcer In-Reply-To: References: Message-ID: <81737A61-7F97-4F82-A9B1-44A94C3C7E8A@kirei.se> hi, after discussions with sion, jelte and rickard; I've now integrated libksm into the enforcer and yet another separate library and associated headers bits the dust. libhsm is still separate and due to its rather low complexity, I'd like to keep it that way for now. jakob From jakob at kirei.se Tue Aug 4 14:34:43 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 4 Aug 2009 16:34:43 +0200 Subject: [Opendnssec-develop] Config question In-Reply-To: References: <69830D4127201D4EBD146B9041199718E1E85E@EXCHANGE.office.nic.se> <0A9C276F-3E75-46C3-BE0A-FBD21264B3A8@kirei.se> Message-ID: <953B43DA-D876-4FA9-AEE4-08D5C9FBE1FD@kirei.se> On 4 aug 2009, at 11.01, sion at nominet.org.uk wrote: > Should we ever look to store the salt in the kasp.xml, either on > export or > not? As it changes its value then you could argue that it is not > really > part of the policy. probably not. say the magic work and I'll kill it. > My slight concern here is that we have a value in kasp.xml that > doesn't > change and so gets out of sync with the SignerConfiguration. I agree. jakob From owner-dnssec-trac at kirei.se Wed Aug 5 07:03:01 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 05 Aug 2009 07:03:01 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #8: softhsm --init -token hangs after entering PINs In-Reply-To: <058.853183f29282ffd46779ff62e22e6576@kirei.se> References: <058.853183f29282ffd46779ff62e22e6576@kirei.se> Message-ID: <067.475f32a8a08eb2cc7179866e2d3fb587@kirei.se> #8: softhsm --init -token hangs after entering PINs ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: defect | Status: closed Priority: major | Component: SoftHSM Version: 1.0a1 | Resolution: worksforme Keywords: | ---------------------------------+------------------------------------------ Changes (by rb): * status: new => closed * resolution: => worksforme Old description: > {{{ > [root at gozo ~]# /usr/local/opendnssec/bin/softhsm --init-token --slot 0 > --label OpenDNSSEC > The SO PIN must have a length between 4 and 255 characters. > Enter SO PIN: > The user PIN must have a length between 4 and 255 characters. > Enter user PIN: > > }}} > process hangs infinitiv > > running > > {{{ > strace /usr/local/opendnssec/bin/softhsm --init-token --slot 0 --label > OpenDNSSEC > > ... > lstat64("/proc/kmsg", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0 > open("/proc/kmsg", O_RDONLY|O_NOCTTY) = 8 > read(8, > > }}} > resolves problem reading /proc/kmsg > > SELinux is disabled. > (Standard 32-bit FC11 system) New description: {{{ [root at gozo ~]# /usr/local/opendnssec/bin/softhsm --init-token --slot 0 --label OpenDNSSEC The SO PIN must have a length between 4 and 255 characters. Enter SO PIN: The user PIN must have a length between 4 and 255 characters. Enter user PIN: }}} process hangs infinitiv running {{{ strace /usr/local/opendnssec/bin/softhsm --init-token --slot 0 --label OpenDNSSEC ... lstat64("/proc/kmsg", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0 open("/proc/kmsg", O_RDONLY|O_NOCTTY) = 8 read(8, }}} resolves problem reading /proc/kmsg SELinux is disabled. (Standard 32-bit FC11 system) -- Comment: The problem was in Botan 1.8.2 and had to do with the polling of entropy. Fixed in Botan 1.8.3. Will add this to the documentation. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 5 09:58:15 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 05 Aug 2009 09:58:15 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #4: zone_reader (signer) does not read zone files in standard bind format In-Reply-To: <058.c72187a0f7ff001a55c0cb58d778bbe4@kirei.se> References: <058.c72187a0f7ff001a55c0cb58d778bbe4@kirei.se> Message-ID: <067.61927586f8a5172d15be07ce6b627517@kirei.se> #4: zone_reader (signer) does not read zone files in standard bind format ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: jelte Type: defect | Status: closed Priority: minor | Component: Signer Version: 1.0a1 | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Changes (by jelte): * status: new => closed * resolution: => fixed Comment: should be fixed in trunk rev. 1486 -- Ticket URL: OpenDNSSEC OpenDNSSEC From patrik.wallstrom at iis.se Wed Aug 5 10:05:37 2009 From: patrik.wallstrom at iis.se (Patrik Wallstrom) Date: Wed, 5 Aug 2009 12:05:37 +0200 Subject: [Opendnssec-develop] First draft of the user documentation in the wiki Message-ID: <82358823-4120-4ADB-9B5D-67339755E1E1@iis.se> I just added the user documentation to the wiki. Some things to do before this is ok is to add the picture and double check all the markup (there are some bad things in there). After this is ok, copy & paste to the wordpress site should be easy, but I don't know for sure yet. http://trac.opendnssec.org/wiki/Signer/Using -------------- 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 Wed Aug 5 10:37:47 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 5 Aug 2009 11:37:47 +0100 Subject: [Opendnssec-develop] More configuration for signer and auditor Message-ID: Hi - I have the following bug report for the auditor (which really involves communication between the signer and the auditor) : "Signer engine wants to audit the .signed file in the temp directory before outputing it to the final destination. But the auditor is looking for the signed zone at the given location in the zonelist.xml. The signer engine should somehow tell the auditor where it can find the temporary file, since the signer engine is not writing the final file until it has been audited." We could do this in a number of ways : a) Naming by convention - the signer will always write the temporary file to the working directory with a particular prefix, so the auditor will always know where to find it b) XML configuration - the config will specify where to write the temporary file, so the signer and auditor will be told where to put/find it c) Command line parameter - the signer will tell the auditor where to find the file when it starts it up. Any preferences? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Wed Aug 5 10:54:38 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 5 Aug 2009 11:54:38 +0100 Subject: [Opendnssec-develop] Configuration paths Message-ID: Good morning/afternoon, You may have noticed that the conf.xml has been expanded so that now all of the other paths/files can be specified in it (zonelist, kasp and signer configuration directory). The question is whether we want to: a) make these optional (and use a default if they are not provided) or b) make them mandatory, so that all the paths used are explicitly stated in conf.xml (apart from the path to conf.xml itself of course) My preference is for (b); does anyone have any views/other ideas on this? Sion From jakob at kirei.se Wed Aug 5 11:02:00 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 5 Aug 2009 13:02:00 +0200 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: References: Message-ID: On 5 aug 2009, at 12.37, Alexd at nominet.org.uk wrote: > We could do this in a number of ways : > > a) Naming by convention - the signer will always write the temporary > file to the working directory with a particular prefix, so the > auditor will always know where to find it > b) XML configuration - the config will specify where to write the > temporary file, so the signer and auditor will be told where to put/ > find it > c) Command line parameter - the signer will tell the auditor where > to find the file when it starts it up. > > Any preferences? I'd very much prefer (c), so that the auditor always audits what's in the zonelist normally, but can be overridden by command line options. jakob From jakob at kirei.se Wed Aug 5 11:03:06 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 5 Aug 2009 13:03:06 +0200 Subject: [Opendnssec-develop] Configuration paths In-Reply-To: References: Message-ID: <3C11E131-3343-4844-9A8F-6511A3A790B7@kirei.se> On 5 aug 2009, at 12.54, sion at nominet.org.uk wrote: > You may have noticed that the conf.xml has been expanded so that now > all of > the other paths/files can be specified in it (zonelist, kasp and > signer > configuration directory). although the signer configuration directory shouldn't be there, my bad (thanks rickard!). > The question is whether we want to: > > a) make these optional (and use a default if they are not provided) > or > b) make them mandatory, so that all the paths used are explicitly > stated in > conf.xml (apart from the path to conf.xml itself of course) > > My preference is for (b); does anyone have any views/other ideas on > this? (b) jakob From rickard.bondesson at iis.se Wed Aug 5 11:02:30 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 5 Aug 2009 13:02:30 +0200 Subject: [Opendnssec-develop] Configuration paths In-Reply-To: References: Message-ID: <69830D4127201D4EBD146B9041199718E1E921@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Good morning/afternoon, > > You may have noticed that the conf.xml has been expanded so > that now all of the other paths/files can be specified in it > (zonelist, kasp and signer configuration directory). > > The question is whether we want to: > > a) make these optional (and use a default if they are not provided) or > b) make them mandatory, so that all the paths used are > explicitly stated in conf.xml (apart from the path to > conf.xml itself of course) > > My preference is for (b); does anyone have any views/other > ideas on this? +1 And then if you want to specify the path to the conf.xml file then you can give the full path /home/user/opendnssec/configuration.xml Thus not appending conf.xml to the given path string. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSnlmxuCjgaNTdVjaAQgVjgf/Rt1XMkp/X///O4n4S9j5/Eet42ptnzIa qIem7TvlGkTOpprSJHfySbMfla9JkqyF/IR0ys1z867ClL02wHBTNqbza/E6LC3O lL+bVl00Bs9P0q4HCmw0pcfZHB1HqBsbAk9/ShlgMXeP8lKv1dn93Zsf2yuaxJHI wftLoaG96lMNAZaZ24bmG2jnfrUkvKVGObRB5U6VFAQFVbbSv365P3BlQFKRuUEI 32fGR6vFczylvHFJ/Q7AqKHgfkPuJykDDWj3ZVY1oUDLfVA/u9M/sUod2tVdDKBh 5nn8ZwKyDqLwVgCcpBVpkbNZm2OuDf2aMSTzPB+FWKXG4imi3ZxP1w== =BLwZ -----END PGP SIGNATURE----- From jakob at kirei.se Wed Aug 5 12:24:57 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 5 Aug 2009 14:24:57 +0200 Subject: [Opendnssec-develop] request for a one-change-per-commit-policy Message-ID: hi, even though I know it generates a bit more work, I'd humbly request that we commit one fix/feature/... per commit. it makes it so much easier to track changes and bugs, instead of a gazillion small tweeks in one single commit. jakob From Alexd at nominet.org.uk Wed Aug 5 13:24:37 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 5 Aug 2009 14:24:37 +0100 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: References: Message-ID: > > a) Naming by convention - the signer will always write the temporary > > file to the working directory with a particular prefix, so the > > auditor will always know where to find it > > b) XML configuration - the config will specify where to write the > > temporary file, so the signer and auditor will be told where to put/ > > find it > > c) Command line parameter - the signer will tell the auditor where > > to find the file when it starts it up. > > > > Any preferences? > > I'd very much prefer (c), so that the auditor always audits what's in > the zonelist normally, but can be overridden by command line options. Of course, there could be many zones in the zonelist. So the command line options would need to map individual zones in the zonelist to individual temporary files. This could get quite messy. If the auditor knew where the signer placed the temporary files ( e.g. zone.file -> /zone.file.tmp ), it could take a command line switch to mean "Don't look for the output files in the zonelist - instead, look for where you know the signer will have placed the temporary files". Just a thought. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bondesson at iis.se Wed Aug 5 13:31:18 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 5 Aug 2009 15:31:18 +0200 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: References: Message-ID: <69830D4127201D4EBD146B9041199718E1E956@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > If the auditor knew where the signer placed the temporary > files ( e.g. zone.file -> /zone.file.tmp > ), it could take a command line switch to mean "Don't look > for the output files in the zonelist - instead, look for > where you know the signer will have placed the temporary files". > > Just a thought. +1 Since the signer engine is always writing the temporary signed file at /(zone name).signed -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSnmJpeCjgaNTdVjaAQgD7Qf/fNKKW/h92Re0p/q/uTuNyG0TwkQ9BHL1 glgA8LFnojOMVOetq2YvYXEyVPZ/Mvw/3Y50VfrrMc092ALCsGXjz5cTmFtNHkXL FVR1zru1Ty/qHz0QcSIBeDq1joQDgDcZJ/YoBCNOK3V2cWeY9fQivPYbwpEF/yfl 0wqEdk46UWRdbVgoNDUfe4d8daFV0Rp6pSIj+XGcRj7yJnuABKR9RLB32YI4uDqn BKl1ycP4qDmSbwLBB6XQ2Rt46kpKTSuhgBQzjX/i10P4el6q63F97JrVdRPpSBWQ DKcj0+tVouxrmwtA5PkobKMtedgxFih7Gw4wFIfA2R51007QmDdelA== =qWkc -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Wed Aug 5 13:35:22 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 05 Aug 2009 13:35:22 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #7: softHSM links libsoftHSM to build directory In-Reply-To: <058.a0a898de9e47cea3b282182c283d387c@kirei.se> References: <058.a0a898de9e47cea3b282182c283d387c@kirei.se> Message-ID: <067.c6a032639c06b1875ccb51a6ef65c219@kirei.se> #7: softHSM links libsoftHSM to build directory ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: rb Type: defect | Status: closed Priority: minor | Component: SoftHSM Version: 1.0a1 | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Changes (by rb): * status: new => closed * resolution: => fixed Old description: > {{{ > [root at gozo ~]# ldd /usr/local/opendnssec/bin/softhsm > linux-gate.so.1 => (0x00355000) > libsofthsm.so.1 => > /home/mattias/opendnssec/build/OpenDNSSEC/softHSM/src/lib/.libs/libsofthsm.so.1 > (0x00ca1000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x04ebd000) > libbotan-1.8.2.so => /usr/lib/libbotan-1.8.2.so (0x006e5000) > libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x05508000) > libm.so.6 => /lib/libm.so.6 (0x0062f000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x003cd000) > libc.so.6 => /lib/libc.so.6 (0x004b4000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00659000) > /lib/ld-linux.so.2 (0x00490000) > libbz2.so.1 => /lib/libbz2.so.1 (0x0511a000) > libcrypto.so.8 => /usr/lib/libcrypto.so.8 (0x04d1d000) > libgmp.so.3 => /usr/lib/sse2/libgmp.so.3 (0x00bf1000) > librt.so.1 => /lib/librt.so.1 (0x006ab000) > libz.so.1 => /lib/libz.so.1 (0x00676000) > libdl.so.2 => /lib/libdl.so.2 (0x00628000) > > }}} > > libsofthsm.so.1 should be linked against your install directory > (/usr/local/opendnssec/lib/libsofthsm.so.1) New description: {{{ [root at gozo ~]# ldd /usr/local/opendnssec/bin/softhsm linux-gate.so.1 => (0x00355000) libsofthsm.so.1 => /home/mattias/opendnssec/build/OpenDNSSEC/softHSM/src/lib/.libs/libsofthsm.so.1 (0x00ca1000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x04ebd000) libbotan-1.8.2.so => /usr/lib/libbotan-1.8.2.so (0x006e5000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x05508000) libm.so.6 => /lib/libm.so.6 (0x0062f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x003cd000) libc.so.6 => /lib/libc.so.6 (0x004b4000) libpthread.so.0 => /lib/libpthread.so.0 (0x00659000) /lib/ld-linux.so.2 (0x00490000) libbz2.so.1 => /lib/libbz2.so.1 (0x0511a000) libcrypto.so.8 => /usr/lib/libcrypto.so.8 (0x04d1d000) libgmp.so.3 => /usr/lib/sse2/libgmp.so.3 (0x00bf1000) librt.so.1 => /lib/librt.so.1 (0x006ab000) libz.so.1 => /lib/libz.so.1 (0x00676000) libdl.so.2 => /lib/libdl.so.2 (0x00628000) }}} libsofthsm.so.1 should be linked against your install directory (/usr/local/opendnssec/lib/libsofthsm.so.1) -- Comment: Fixed in revision 1499 -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Wed Aug 5 13:51:22 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 5 Aug 2009 15:51:22 +0200 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: References: Message-ID: On 5 aug 2009, at 15.24, alexd at nominet.org.uk wrote: > Of course, there could be many zones in the zonelist. So the command > line options would need to map individual zones in the zonelist to > individual temporary files. This could get quite messy. so I suggest you execute the auditor a) for all zone in the zonelist b) for a single zone in the zone list for (b) it should be possible to override filenames for the unsigned and signed version of the zone. for both (a) and (b) it should be possible to override the policy file. the signer engine can use (b) and point to temporary (unaudited) signed file. no need for the auditor to know about the signer's working directory. jakob From Alexd at nominet.org.uk Wed Aug 5 13:59:42 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 5 Aug 2009 14:59:42 +0100 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: References: Message-ID: > so I suggest you execute the auditor > > a) for all zone in the zonelist > b) for a single zone in the zone list This is the current implementation. > for (b) it should be possible to override filenames for the unsigned > and signed version of the zone. > for both (a) and (b) it should be possible to override the policy file. This does seem more complicated than the convention solution, but I'll happily implement it if required. ? > the signer engine can use (b) and point to temporary (unaudited) > signed file. no need for the auditor to know about the signer's > working directory. The auditor currently uses the Signer/WorkingDirectory to store its own temporary files. Should an Auditor/WorkingDirectory be defined? If so, then I suppose the convention solution isn't really appropriate. Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Wed Aug 5 14:09:51 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 5 Aug 2009 16:09:51 +0200 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: References: Message-ID: <51F17EF0-2A9F-487A-97BC-3554B700D898@kirei.se> On 5 aug 2009, at 15.59, Alexd at nominet.org.uk wrote: > The auditor currently uses the Signer/WorkingDirectory to store its > own temporary files. Should an Auditor/WorkingDirectory be defined? > If so, then I suppose the convention solution isn't really > appropriate. yes, I'd prefer if the auditor had its own WorkingDirectory. I'll set one up in the confs. jakob From jakob at kirei.se Wed Aug 5 14:13:02 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 5 Aug 2009 16:13:02 +0200 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: References: Message-ID: On 5 aug 2009, at 15.59, Alexd at nominet.org.uk wrote: > > so I suggest you execute the auditor > > > > a) for all zone in the zonelist > > b) for a single zone in the zone list > > This is the current implementation. good. > > for (b) it should be possible to override filenames for the unsigned > > and signed version of the zone. > > for both (a) and (b) it should be possible to override the policy > file. > > This does seem more complicated than the convention solution, but > I'll happily implement it if required. ? I'd prefer this to the convention, as it is possibly more apparent to the user what's going to happen. convention can sometimes turn into magic, which is usally bad. jakob From Alexd at nominet.org.uk Thu Aug 6 11:13:46 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 6 Aug 2009 12:13:46 +0100 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: References: Message-ID: > so I suggest you execute the auditor > > a) for all zone in the zonelist > b) for a single zone in the zone list > for (b) it should be possible to override filenames for the unsigned > and signed version of the zone. > for both (a) and (b) it should be possible to override the policy > file. how about : kasp_auditor [--path to/opendnssec] [--kasp kasp.file] [--zone name [--signed path/to/temp.signed.zonefile]] (with -p, -k, -z, -s as abbreviations) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Thu Aug 6 11:23:39 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 6 Aug 2009 13:23:39 +0200 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: References: Message-ID: <37F77643-A01F-42F1-902F-FE72BBB43CCA@kirei.se> On 6 aug 2009, at 13.13, Alexd at nominet.org.uk wrote: > > so I suggest you execute the auditor > > > > a) for all zone in the zonelist > > b) for a single zone in the zone list > > > for (b) it should be possible to override filenames for the unsigned > > and signed version of the zone. > > for both (a) and (b) it should be possible to override the policy > > file. > > how about : > > kasp_auditor [--path to/opendnssec] [--kasp kasp.file] [--zone name > [--signed path/to/temp.signed.zonefile]] > (with -p, -k, -z, -s as abbreviations) not sure what --path would give you, better to provide full paths for all files. other than that it seems fair. jakob From rickard.bondesson at iis.se Thu Aug 6 11:31:50 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 6 Aug 2009 13:31:50 +0200 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: <37F77643-A01F-42F1-902F-FE72BBB43CCA@kirei.se> References: <37F77643-A01F-42F1-902F-FE72BBB43CCA@kirei.se> Message-ID: <69830D4127201D4EBD146B9041199718E1EA11@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > not sure what --path would give you, better to provide full > paths for all files. other than that it seems fair. - --path would be the full path to conf.xml (e.g. /home/rickard/opendnssec/configuration.file), if not given then it defaults to the installed path of conf.xml. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSnq/JuCjgaNTdVjaAQivEQf/UEWYNwXGc4sUYDHhg/NHJozU9+BJH1yV YUXWdE+qR2hGV+cR4o45iCQ0yFwglSkURCn6I2fj0NmV6GtKrgkWfIc440EURdyE sbm8cRyBc93q+jfwt9JhB2ssH0q3ImH1Kr9gwhg5fXgTyXJbFmR195sKLalZuUE3 EYTRW9h5maqfJ3p5hc8MRaY3JDhh1Q70/6qXyLMK01w2HzX7JKT8n2WO/4evOTE+ UNrafhEmmDNnx2/y5QYxBaIMESBZHQdajbGpsoy+Qf09pO6xpQUbVWlnnBdxkeJN miIRazz+cOk14cbwDm9Y0/l2eiEbFAWLAIqSQ1tMJilLBgQUkgJ9YQ== =lfPC -----END PGP SIGNATURE----- From jakob at kirei.se Thu Aug 6 11:38:12 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 6 Aug 2009 13:38:12 +0200 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: <69830D4127201D4EBD146B9041199718E1EA11@EXCHANGE.office.nic.se> References: <37F77643-A01F-42F1-902F-FE72BBB43CCA@kirei.se> <69830D4127201D4EBD146B9041199718E1EA11@EXCHANGE.office.nic.se> Message-ID: <4BB442E8-18A2-4936-9F33-3941D59C02A6@kirei.se> On 6 aug 2009, at 13.31, Rickard Bondesson wrote: > - --path would be the full path to conf.xml (e.g. /home/rickard/ > opendnssec/configuration.file), if not given then it defaults to the > installed path of conf.xml. in that case it should say --config and the argument is the full path to the configuration file. not the directory. jakob From Alexd at nominet.org.uk Thu Aug 6 11:41:04 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 6 Aug 2009 12:41:04 +0100 Subject: [Opendnssec-develop] More configuration for signer and auditor In-Reply-To: <4BB442E8-18A2-4936-9F33-3941D59C02A6@kirei.se> References: <37F77643-A01F-42F1-902F-FE72BBB43CCA@kirei.se> <69830D4127201D4EBD146B9041199718E1EA11@EXCHANGE.office.nic.se> <4BB442E8-18A2-4936-9F33-3941D59C02A6@kirei.se> Message-ID: > > - --path would be the full path to conf.xml (e.g. /home/rickard/ > > opendnssec/configuration.file), if not given then it defaults to the > > installed path of conf.xml. > > in that case it should say --config and the argument is the full path > to the configuration file. not the directory. Great! I'll do that, and stop pestering everyone ;-) Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Thu Aug 6 12:51:17 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Aug 2009 12:51:17 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #9: ksmutil addzone defaults to wrong path Message-ID: <063.b281bdfe253cef94a2e063c7259e6199@kirei.se> #9: ksmutil addzone defaults to wrong path --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jakob Type: defect | Status: new Priority: minor | Component: Unknown Version: | Keywords: ksmutil addzone --------------------------------------+------------------------------------- When calling ksmutil addzone with just the zone name it sets the path to the config and zonefiles to the wrong location (prepends \usr\local). The zone mcd.coop was added manually and has the correct location. {{{ opensndsec1:/var/opendnssec/unsigned# ksmutil addzone test.coop zonelist filename set to /etc/opendnssec/zonelist.xml. SQLite database set to: /var/opendnssec/kasp.db Imported zone: test.coop opensndsec1:/var/opendnssec/unsigned# cat /etc/opendnssec/zonelist.xml default /var/opendnssec/config/mcd.coop.xml /var/opendnssec/unsigned/mcd.coop /var/opendnssec/signed/mcd.coop default /usr/local/var/opendnssec/config/test.coop.xml /usr/local/var/opendnssec/unsigned/test.coop /usr/local/var/opendnssec/signed/test.coop }}} This was tested against the trunk (1522). Running Debian GNU/Linux squeeze/sid Configured with: ./configure --prefix=/usr/local --sysconfdir=/etc --localstatedir=/var --with-sqlite3=/usr --with-ldns=/usr --with- libxml2=/usr --with-botan=/usr --with- pkcs11-softhsm=/usr/local/lib/libsofthsm.so -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 6 12:55:15 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Aug 2009 12:55:15 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #10: "signer_engine_cli sign all" Error Message-ID: <063.100b691e7948a67539bcbddd22fb4a01@kirei.se> #10: "signer_engine_cli sign all" Error --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jakob Type: defect | Status: new Priority: major | Component: Unknown Version: | Keywords: --------------------------------------+------------------------------------- {{{ opensndsec1:/usr/src/opendnssec# signer_engine_cli sign all connecting to /var/run/opendnssec/engine.sock Error handling command: 'NoneType' object has no attribute 'signatures_resign_time'Traceback (most recent call last): File "/usr/local/lib/opendnssec/signer/Engine.py", line 291, in handle_command self.schedule_signing(zone) File "/usr/local/lib/opendnssec/signer/Engine.py", line 567, in schedule_signing str(zone.zone_config.signatures_resign_time)) AttributeError: 'NoneType' object has no attribute 'signatures_resign_time' }}} This was tested against the trunk (1522). Running Debian GNU/Linux squeeze/sid Configured with: ./configure --prefix=/usr/local --sysconfdir=/etc --localstatedir=/var --with-sqlite3=/usr --with- ldns=/usr --with- libxml2=/usr --with-botan=/usr --with- pkcs11-softhsm=/usr/local/lib/libsofthsm.so -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 6 13:17:42 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Aug 2009 13:17:42 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #11: Issue with $TTL and zone_reader Message-ID: <063.76a704557b0047ea0f08cd89a5f45837@kirei.se> #11: Issue with $TTL and zone_reader --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jakob Type: defect | Status: new Priority: major | Component: Unknown Version: | Keywords: --------------------------------------+------------------------------------- I have a zonefile as follows with a default TTL of 3 hours {{{ $TTL 3h $ORIGIN mcd.coop. @ IN SOA ns0.pandanet.co.uk. admin.ns0.pandanet.co.uk. (2006113014 10800 3600 604800 86400 ) @ NS ns0.pandanet.co.uk. @ A 217.10.159.116 @ MX 20 smtp.cit.coop. @ MX 10 smtp1.cit.coop. www CNAME mcd.coop. }}} when passing through zone_reader with {{{ /usr/local/libexec/opendnssec/zone_reader -f /var/opendnssec/unsigned/mcd.coop -o mcd.coop }}} I get the following result with the default TTL of 3 seconds! {{{ mcd.coop. 3 IN A 217.10.159.116 mcd.coop. 3 IN NS ns0.pandanet.co.uk. mcd.coop. 3 IN SOA ns0.pandanet.co.uk. admin.ns0.pandanet.co.uk. 2006113014 10800 3600 604800 86400 mcd.coop. 3 IN MX 10 smtp1.cit.coop. mcd.coop. 3 IN MX 20 smtp.cit.coop. www.mcd.coop. 3 IN CNAME mcd.coop. }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 6 13:43:34 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Aug 2009 13:43:34 -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.97a33518f23f9d4f00f8453cf6d28126@kirei.se> #10: "signer_engine_cli sign all" Error --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jelte Type: defect | Status: assigned Priority: major | Component: Unknown Version: | Resolution: Keywords: | --------------------------------------+------------------------------------- Changes (by jelte): * owner: jakob => jelte * status: new => assigned Comment: ok apparently for one reason or the other it appears the specific zone's configuration wasn't there or had disappeared. This patch reloads it and gracefully errors if it still has no config after that (presumably with what actually goes wrong) could you please try it? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 6 14:11:26 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Aug 2009 14:11:26 -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.0ecc7043bc79e507f67383ed3285506e@kirei.se> #11: Issue with $TTL and zone_reader --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jelte Type: defect | Status: assigned Priority: major | Component: Unknown Version: | Resolution: Keywords: | --------------------------------------+------------------------------------- Changes (by jelte): * owner: jakob => jelte * status: new => assigned Comment: above attachment should fix this issue; the directive handler expected an integer instead of a duration-like value -- Ticket URL: OpenDNSSEC OpenDNSSEC From jelte at NLnetLabs.nl Thu Aug 6 14:21:20 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Thu, 06 Aug 2009 16:21:20 +0200 Subject: [Opendnssec-develop] getting information from the system Message-ID: <4A7AE6E0.2010501@NLnetLabs.nl> Hi, apart from that there can be some very interesting failures that aren't directly reported back (a missing communicated process can be quite annoying, i've been told, but apparently the only effect one sees in the end is that the engine whines about missing configurations), an administrator will really want to know when the next rollover is. Has this feature been planned yet? (sounds like something that could be added to ksmutil) If not, please do, and plan it before the release :) Jelte From olaf at NLnetLabs.nl Thu Aug 6 14:34:44 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Thu, 6 Aug 2009 16:34:44 +0200 Subject: [Opendnssec-develop] getting information from the system In-Reply-To: <4A7AE6E0.2010501@NLnetLabs.nl> References: <4A7AE6E0.2010501@NLnetLabs.nl> Message-ID: <195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl> On 6 aug 2009, at 16:21, Jelte Jansen wrote: > > apart from that there can be some very interesting failures that > aren't directly reported back (a missing communicated process can be > quite annoying, i've been told, but apparently the only effect one > sees in the end is that the engine whines about missing > configurations), an administrator will really want to know when the > next rollover is. Has this feature been planned yet? (sounds like > something that could be added to ksmutil) If not, please do, and > plan it before the release :) The administrator asking for this was me :-) The somewhat longer version of the above: Over the last two days I installed opendnssec and while it was somewhat of a rough ride the tiny that I ran in where committed faster than I could compile (good stuff). 1. As a zone maintainer I want to be sure that when a (KSK) rollover happens, I am around and can take action. In fact I want to be able to plan in advance (on absolute dates, rather than periods) that I would like to initiate a rollover and send a set of keys of to the registry. That way I can go on vacation whenever I want :-) Currently it is hard to see what the chains of events are, and it is hard to configure. If it comes to usability knowing what happens when would be a good thing. 2. I added zones to the zonefilelist and ran ksmutil update. The signer engine complained about missing config files. That turned out to be due to a missing comunicated process. I would think a small wrapper program/script that would start/restart/ stop all other deamons and act as a watchdog would be handy. --Olaf --Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 235 bytes Desc: This is a digitally signed message part URL: From owner-dnssec-trac at kirei.se Thu Aug 6 14:34:58 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Aug 2009 14:34:58 -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.85bc699267dc6e45aa07b0e7e3136740@kirei.se> #9: ksmutil addzone defaults to wrong path --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: sion Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: ksmutil addzone | --------------------------------------+------------------------------------- Changes (by rb): * owner: jakob => sion * status: new => assigned Comment: Passing this to Sion. Will get back there is a fix. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Thu Aug 6 14:43:45 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 6 Aug 2009 16:43:45 +0200 Subject: [Opendnssec-develop] getting information from the system In-Reply-To: <195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl> References: <4A7AE6E0.2010501@NLnetLabs.nl> <195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl> Message-ID: On 6 aug 2009, at 16.34, Olaf Kolkman wrote: > I would think a small wrapper program/script that would start/ > restart/stop all other deamons and act as a watchdog would be handy. this is planned, but not for 1.0. perhaps we can write a simpler version as a start? http://www.pivotaltracker.com/story/show/841390 jakob From owner-dnssec-trac at kirei.se Thu Aug 6 14:56:09 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Aug 2009 14:56:09 -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.280812aeb33dba599ab297b33ae2ef57@kirei.se> #9: ksmutil addzone defaults to wrong path --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: sion Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: ksmutil addzone | --------------------------------------+------------------------------------- Comment(by rb): fixed in r1531 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 6 14:57:05 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Aug 2009 14:57:05 -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.af345bb3c6381121a53a07e1a3b3f6e6@kirei.se> #9: ksmutil addzone defaults to wrong path --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: sion Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: ksmutil addzone | --------------------------------------+------------------------------------- Comment(by rb): and in r1534 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 6 17:56:38 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Aug 2009 17:56:38 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #12: make install creates an incorrectly named directory Message-ID: <063.4af27217237dc227e07cef4f72cd2e6f@kirei.se> #12: make install creates an incorrectly named directory --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jakob Type: defect | Status: new Priority: minor | Component: Unknown Version: | Keywords: signconf --------------------------------------+------------------------------------- When you run "make install" the script makes a directory called "/var/opendnssec/signconf" to contain the zone configs. However the ksmutil sets the default directory for these files to be in "/var/opendnssec/config" when it generates the /etc/opendnssec/zonefile.xml file. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Aug 7 07:18:16 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 07 Aug 2009 07:18:16 -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.d2588ee5f5e64884785503d8e9f8b273@kirei.se> #12: make install creates an incorrectly named directory --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jakob Type: defect | Status: closed Priority: minor | Component: Unknown Version: | Resolution: fixed Keywords: signconf | --------------------------------------+------------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Fixed in r1537 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Aug 7 07:18:46 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 07 Aug 2009 07:18:46 -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.bdcfe52f29b458be683e637dd21d9d73@kirei.se> #9: ksmutil addzone defaults to wrong path --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: sion Type: defect | Status: closed Priority: minor | Component: Unknown Version: | Resolution: fixed Keywords: ksmutil addzone | --------------------------------------+------------------------------------- Changes (by rb): * status: assigned => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bondesson at iis.se Fri Aug 7 10:01:24 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Fri, 7 Aug 2009 12:01:24 +0200 Subject: [Opendnssec-develop] Key rollover date Message-ID: <69830D4127201D4EBD146B9041199718E1EAB1@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Is there a problem if the key rollover date is not fixed in time? E.g: My system does automatic rollover in March every year. In August I perform an emergency rollover, but now will my system perform the automatic rollover in August every year. This is because each key is valid for one year in this case, and the emergency rollover shifted the usual rollover date. Are there some use cases where you want to roll the key at a specific date and time. E.g. I want to roll my ZSK:s on the first of each months. Then there is also a problem that P1M (one month) does not equal the same amount in seconds every month. So you get a shift by this also. Olaf, you mentioned something about this. Would repeating intervals from ISO 8601 solve your problems? http://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals How important is this feature? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSnv7dOCjgaNTdVjaAQjEcwf/bBFsDmcTaB1B4rcQjno1s125KcidHwYM 64BvxfW+tZ+bH2YQiIuOrq+9A2KfZ0sNePtWFxNWjSkswsnK6ZTFK47b2yCSQf1t s8Yp2YjqWPyDyoWN9YbvwXiRAJgc00NhQBQSz7kVnFQ94FsO5x8E6JY0PGR+CPpM 2fRb613XJq0q8SbwtA0Pv7Y3v1QGq+3jun275k/yv//hwg2qXxkqp7zJntWA4vas qKJi/PUIuIpI5rx9458d+i8MRWilkvI+VJNvoLWes+IDl7vTr6WcXt6gEqLRFgB1 z8QI+ynOHrVSlspN1vVH/eA69fbmDiVGiUsFsf/SjCTKYzr0LzSm3A== =O3QK -----END PGP SIGNATURE----- From olaf at NLnetLabs.nl Fri Aug 7 10:15:49 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 7 Aug 2009 12:15:49 +0200 Subject: [Opendnssec-develop] Key rollover date In-Reply-To: <69830D4127201D4EBD146B9041199718E1EAB1@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718E1EAB1@EXCHANGE.office.nic.se> Message-ID: <62C75D8B-BB92-462C-AB67-E566274759D4@NLnetLabs.nl> On 7 aug 2009, at 12:01, Rickard Bondesson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi > > Is there a problem if the key rollover date is not fixed in time? > > E.g: My system does automatic rollover in March every year. In > August I perform an emergency rollover, but now will my system > perform the automatic rollover in August every year. > I can imagine many managerial/operational reasons why you would like to determine the time during which a key-rollover takes place. e.g: - You want to roll the key shortly before or after billing - You want to make sure your key staff is not on vacation or on a conference In other words a KSK rollover is an event one would like to plan. Since there are interactions with humans/3rd parties I also would like to get a warning (either by polling the system on when I may expect the next KSK roll, or by a hook that sends me mail or another push) > This is because each key is valid for one year in this case, and the > emergency rollover shifted the usual rollover date. Are there some > use cases where you want to roll the key at a specific date and > time. E.g. I want to roll my ZSK:s on the first of each months. > For the ZSK I think being able to specify the date exactly is less of an issue, as ZSK rolls should not involve any human interaction. > Then there is also a problem that P1M (one month) does not equal the > same amount in seconds every month. So you get a shift by this also. > Nah... if no human interaction/3rd party reliance is there I do not think that is a big deal. > Olaf, you mentioned something about this. Would repeating intervals > from ISO 8601 solve your problems? http://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals > Its probably close... So suppose I had an emergency roll in August and I would like to configure the system to do the next role in july, how would I express that? > How important is this feature? I think it is important. The reason why I (as early deployer) am nervous about turning on opendnssec on my system is that I know I will forget when I initiated the KSK and I have no idea on when its going to happen and how to make sure I get a warning when it does. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 235 bytes Desc: This is a digitally signed message part URL: From rickard.bondesson at iis.se Fri Aug 7 11:10:57 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Fri, 7 Aug 2009 13:10:57 +0200 Subject: [Opendnssec-develop] Key rollover date In-Reply-To: <62C75D8B-BB92-462C-AB67-E566274759D4@NLnetLabs.nl> References: <69830D4127201D4EBD146B9041199718E1EAB1@EXCHANGE.office.nic.se> <62C75D8B-BB92-462C-AB67-E566274759D4@NLnetLabs.nl> Message-ID: <69830D4127201D4EBD146B9041199718E1EAC2@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > Then there is also a problem that P1M (one month) does not > equal the > > same amount in seconds every month. So you get a shift by this also. > > > > Nah... if no human interaction/3rd party reliance is there I do not > think that is a big deal. So for the ZSK, we can assume that the period is most important rather than the exact date. And that the current solution is working as intended. > > Olaf, you mentioned something about this. Would repeating > intervals > > from ISO 8601 solve your problems? > http://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals > > > > Its probably close... > > So suppose I had an emergency roll in August and I would like to > configure the system to do the next role in july, how would I > express > that? The next question is then: Should the retire date of the KSK that was manually rolled be set to the same value as the previous key? No, not when you intend to always roll your KSK manually. That would mean that you eventually will come to a time where the key is rolled automatically. A fast solution would be to remove the tag for the KSK, so that you always need to roll the KSK manually. Because, as you say, it always involves contact with a third party (which is not standardized). Or should the be present in the kasp.xml, but the system only send a reminder to the admin and does not perform the rollover automatically. "It is time to roll the key within two weeks. Issue 'ksmutil rollzone se KSK' when you are ready". > > How important is this feature? > > > I think it is important. > > The reason why I (as early deployer) am nervous about turning on > opendnssec on my system is that I know I will forget when I > initiated > the KSK and I have no idea on when its going to happen and > how to make > sure I get a warning when it does. For now you have to set the KSK lifetime to a big value and do the rollover manually: "ksmutil rollzone se KSK" // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSnwLweCjgaNTdVjaAQioHwf/X6+epbxwoMbdi9DrJLApjBFtSMEckz+N Um2bn7oOFEpsbeTspQ0fcNLfdodO2xZQ8IhLX9b/1/RaVImysYEQIeOaS2+MuBD9 BR8LhW0VmRsKYm9cxcTD4a9qXpdV1d60ppUu70uH1mpEuILeT283Hud51IbZw5Tf cdFcc8RNTX1kUTsrU+MAZN0M69rYgqIVYSbB38rqgXlufoecSpnn8OwJZ+cvRv7t IN6jGTouNURUAsHbCF8aSnQkzrpEFjTRbnS+QfWBtP45LyszressFnVNSz/+rntF lyNWvDShtcFepANm2OJLSSFlf3lbsCEOmbtgBE014U19FuSao4nfIg== =l1HW -----END PGP SIGNATURE----- From sion at nominet.org.uk Mon Aug 10 08:49:51 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 10 Aug 2009 09:49:51 +0100 Subject: [Opendnssec-develop] getting information from the system In-Reply-To: <195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl> References: <4A7AE6E0.2010501@NLnetLabs.nl> <195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl> Message-ID: > > an administrator will really want to know when the > > next rollover is. Has this feature been planned yet? (sounds like > > something that could be added to ksmutil) If not, please do, and > > plan it before the release :) So http://www.pivotaltracker.com/story/show/879875 sort of covers it; I've added a comment for a more explicit command that will list rollovers, by zone if specified. > 1. As a zone maintainer I want to be sure that when a (KSK) rollover > happens, I am around and can take action. In fact I want to be able to > plan in advance (on absolute dates, rather than periods) that I would > like to initiate a rollover and send a set of keys of to the registry. > That way I can go on vacation whenever I want :-) > > Currently it is hard to see what the chains of events are, and it is > hard to configure. If it comes to usability knowing what happens when > would be a good thing. So we need a way to override the key timings and set a retire date[time]. Would you like to see this in the policy itself, so that the key "lifetime" is expressed as a recurring event. Something like "1st of every month" or "1st March every year". The alternative is that you override it via a command to ksmutil, I guess that ultimately we need both? What about lifetime == infinite (while I am thinking about it); for people who only want emergency rollovers. Is this required for v1.0? Sion From rickard.bondesson at iis.se Mon Aug 10 08:58:40 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 10 Aug 2009 10:58:40 +0200 Subject: [Opendnssec-develop] getting information from the system In-Reply-To: References: <4A7AE6E0.2010501@NLnetLabs.nl><195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl> Message-ID: <69830D4127201D4EBD146B9041199718E1EB50@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > What about lifetime == infinite (while I am thinking about > it); for people who only want emergency rollovers. > > Is this required for v1.0? Or how about having a lifetime for the KSK, but the rollovers are not happening automaticly within libksm. The KSK rollovers can only happen when you issue the command. The KSK lifetime in the policy is then an indication on how often the operator should issue the KSK-roll-command. The KSK lifetime is then used by the auditor to notify the operator that it should now (within two weeks, one week, 3 days, or 1 day) issue the KSK-roll-command to be able to follow the given policy. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBUAwUBSn/hQOCjgaNTdVjaAQjGQAf4i7o9cgBCpB8p02IFARb1vpHks8h1CflR YPbyz6DXu/g28lWLdTghjCL2A60WZEfzc9MWQV8IsPRbrq1qrSNUJaY69XAzHZu9 NS+hKAQ0lFfC6iQLt+zch1O0olrn2osLj5+NvwM8A7LyH3PSnXNK0HiPO3mAni4D uGxV3LJM3qto4VwwKsJGHhIJsgkiZk+ca1v4HnfwfR0IZx92XWCrACE1wkzxr8kG FWxShdmwwfAyxtxJSj220kslZGZ/ggkfMLWNxY3gWukL2QDtTIswFZFLqnZyvaz9 sYa4n7Hf1Q6MbAyTyIUYcgx2WTYU2PbF8clQAlvXGlkkm6u5+Dsh =veVA -----END PGP SIGNATURE----- From sion at nominet.org.uk Mon Aug 10 09:25:14 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 10 Aug 2009 10:25:14 +0100 Subject: [Opendnssec-develop] getting information from the system In-Reply-To: <69830D4127201D4EBD146B9041199718E1EB50@EXCHANGE.office.nic.se> References: <4A7AE6E0.2010501@NLnetLabs.nl><195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718E1EB50@EXCHANGE.office.nic.se> Message-ID: > > What about lifetime == infinite (while I am thinking about > > it); for people who only want emergency rollovers. > > > > Is this required for v1.0? > > Or how about having a lifetime for the KSK, but the rollovers are > not happening automaticly within libksm. The KSK rollovers can only > happen when you issue the command. The KSK lifetime in the policy is > then an indication on how often the operator should issue the KSK- > roll-command. > > The KSK lifetime is then used by the auditor to notify the operator > that it should now (within two weeks, one week, 3 days, or 1 day) > issue the KSK-roll-command to be able to follow the given policy. So a flag in the policy "Automatic Rollovers" yes/no. That sounds like a good idea. With the warnings, what we have agreed in the past is that we will write a particular message to the log which some other process will pick up to issue the notification. We will though need some idea about how far in advance these should be sent, something else to add to the policy. Unless anyone objects I will write these messages whether automatic rollovers is/are turned on or not, possibly with some extra text based on this option. It seems to me that both of these policy items should be in the KSK/ZSK sections so that they could be different for each. Sion From jakob at kirei.se Mon Aug 10 10:02:18 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 10 Aug 2009 12:02:18 +0200 Subject: [Opendnssec-develop] getting information from the system In-Reply-To: References: <4A7AE6E0.2010501@NLnetLabs.nl><195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718E1EB50@EXCHANGE.office.nic.se> Message-ID: <090583A2-8563-423E-B094-9C651573BE55@kirei.se> I see a couple possible problems here that we need to sort out before going any further. - What we are talking about here is semi-automatic key rollovers, so things like generating and pre-publishing a key (where applicable) is done automatically? - Do we also want to support manual key rollovers and key management? (and if so, why?) jakob From rickard.bondesson at iis.se Mon Aug 10 11:21:16 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 10 Aug 2009 13:21:16 +0200 Subject: [Opendnssec-develop] getting information from the system In-Reply-To: <090583A2-8563-423E-B094-9C651573BE55@kirei.se> References: <4A7AE6E0.2010501@NLnetLabs.nl><195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl><69830D4127201D4EBD146B9041199718E1EB50@EXCHANGE.office.nic.se> <090583A2-8563-423E-B094-9C651573BE55@kirei.se> Message-ID: <69830D4127201D4EBD146B9041199718E1EB6C@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > - What we are talking about here is semi-automatic key > rollovers, so things like generating and pre-publishing a key > (where applicable) is done automatically? Yeah, I do not see any problem of always automatically generating the key and pre-publishing the key. But you only make the KSK active on the command by the operator. There are no default automatic publication of the KSK, so the rollover should never happen automatically now, right? > - Do we also want to support manual key rollovers and key > management? > (and if so, why?) We never want manual key management once in operation, only when you want to add keys from a previous system. We do want the possibility for manual key rollover, e.g. emergency rollover or planned rollover (but faster than the policy is saying). // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoACrOCjgaNTdVjaAQgQWAf/RyaZeLmlwpXAcA8EeppCity5ysBgwZDE nKjrsxZte3JGF0f7BBCk0bcjIukdjtsUxJF+hDxURgTpXv+XBrglS+XnTLGKfS2g hr5SJkDn/D5zMSdEgbtDx+Q6j27W8Qlk2P0yiy5SUNUHZi9eUOY3OJWy8FiHFjbJ UHwIdb6a50UOYClrXH8+uLi50Uk9e8L2jpdp9+ffVV1VDT/i4XuYZOMbnTfF5+iL k6XEXC2awCKWOWkkuC8LBdrhvescN576Bg4DOmAnOOjYeMHrUbCmhooQK2oNRyDr 7292uSZO8gj/I8aFax0L9ctkh0lVOnsKAWX0pn7NHWVuCoA8Hokd5A== =99ZP -----END PGP SIGNATURE----- From sion at nominet.org.uk Mon Aug 10 13:00:55 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 10 Aug 2009 14:00:55 +0100 Subject: [Opendnssec-develop] getting information from the system In-Reply-To: <69830D4127201D4EBD146B9041199718E1EB6C@EXCHANGE.office.nic.se> References: <4A7AE6E0.2010501@NLnetLabs.nl><195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl><69830D4127201D4EBD146B9041199718E1EB50@EXCHANGE.office.nic.se> <090583A2-8563-423E-B094-9C651573BE55@kirei.se> <69830D4127201D4EBD146B9041199718E1EB6C@EXCHANGE.office.nic.se> Message-ID: > > - What we are talking about here is semi-automatic key > > rollovers, so things like generating and pre-publishing a key > > (where applicable) is done automatically? > > Yeah, I do not see any problem of always automatically generating > the key and pre-publishing the key. > > But you only make the KSK active on the command by the operator. > There are no default automatic publication of the KSK, so the > rollover should never happen automatically now, right? Yes, so long as all of the other settings in the policy are reasonable then the rest of the timings should work as they do currently. All we are talking about (I hope) is setting/ignoring the retire time of the key in question. (Setting to a particular point in time, ignoring if rollovers are turned off so all that happens is the warning messages.) Other things will still work, e.g. rollover will be held up if there are no suitable published keys to take over. The worries I have are things like "what do we do if someone switches a policy from one type to another". > > - Do we also want to support manual key rollovers and key > > management? > > (and if so, why?) > > We never want manual key management once in operation, only when you > want to add keys from a previous system. We do want the possibility > for manual key rollover, e.g. emergency rollover or planned rollover > (but faster than the policy is saying). So is it unreasonable to think that someone may want to use ksm only to help decide when it is safe to use a newly generated key and keep track of what keys they have? I'm not suggesting implementing this sort of thing in the near future, but if we say "never" then I'd like to be sure that we mean it. Sion From jakob at kirei.se Mon Aug 10 17:59:11 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 10 Aug 2009 19:59:11 +0200 Subject: [Opendnssec-develop] 1.0a2 late this week?! Message-ID: <069DCC3A-A945-41BB-ABA4-1F05330DD174@kirei.se> hi, I'm considering to cut a 1.0a2 at the end of this week (sunday). the current "release" marker for 1.0a2 in PivotalTrack is to be considered advisory only, so don't take it to serious. jakob -- Jakob Schlyter Kirei AB - www.kirei.se From rickard.bondesson at iis.se Tue Aug 11 07:12:36 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 11 Aug 2009 09:12:36 +0200 Subject: [Opendnssec-develop] 1.0a2 late this week?! In-Reply-To: <069DCC3A-A945-41BB-ABA4-1F05330DD174@kirei.se> References: <069DCC3A-A945-41BB-ABA4-1F05330DD174@kirei.se> Message-ID: <69830D4127201D4EBD146B9041199718E1EBD6@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > hi, > > I'm considering to cut a 1.0a2 at the end of this week (sunday). > the current "release" marker for 1.0a2 in PivotalTrack is to > be considered advisory only, so don't take it to serious. +1 -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoEZ5OCjgaNTdVjaAQjBGwf+OVHta/akGeH9YJT80+9hI5zrRrkFEaVX jajzLpMGrIqxY/4eJ2hrTTpt+Tj8FTgkNc+XyBTCdWwbGP4+KWE/LIZRutN2ABg9 wsDYuQcO4C8uhaEIB0B9EPkvouGsN6aYNwzngNhH39rF36Udq2nGFqoRAn8xypMu P8UEvSoH46XNMP7SM0/iFw0TeAVNQzvTBiCBUYusTVf0g0YtJkZh2rDsL4gSQEo7 NBHH91SWmkKm/Wz7zv8+6wmqC1VWcUivFOd1MIUQ7aFcqiMHXhpZEujdS71D9Hxb al55+n8DTX8NO3a7/KIEWdapvLpV46XJiJrOUHwYqkawrH5TSpDNDg== =/03+ -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Tue Aug 11 11:06:27 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 11 Aug 2009 13:06:27 +0200 Subject: [Opendnssec-develop] NotifyCommand Message-ID: <69830D4127201D4EBD146B9041199718E1EC19@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Shouldn't the be an optional part of the tag in the zonelist.xml? The user can then decided what command to use per zone. And the notify command will only be used when you have file out. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoFQs+CjgaNTdVjaAQgWcgf/WVy+2BhIXf01JnYCRB5liAiZUFGdnXLc UzETJnqR46NZMgqdiWjR+m95AuMFdJAl9Wdn3Vm9bPXKo8e2hAz4yuVHXAsSqCA3 tuQQI1NDY8W5MB2PghdcORJ3Yv1oFJHKV6D4qud31wg/p4ZQsacZZ6D7GS2YwRi9 yAg5Uy7CeSPt24KemFLXe0oWVp7n1/e42ZsvK2YQCDgMkyG9ign5eV4PqjlkeMmM ChWC0nSRUejPE6VuGKjw+lzfQ1wQdi6Kui43tzZDI8xNAM9onBiEG4vHrnIt4faF 7wtXqKRZX2jLIEV54yc2eQ583dipkN9MrUmGtKaupvbgBqszLFe4NQ== =YBAp -----END PGP SIGNATURE----- From jakob at kirei.se Tue Aug 11 11:32:17 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 11 Aug 2009 13:32:17 +0200 Subject: [Opendnssec-develop] NotifyCommand In-Reply-To: <69830D4127201D4EBD146B9041199718E1EC19@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718E1EC19@EXCHANGE.office.nic.se> Message-ID: <6DAADE80-F453-4FFE-8751-84C007F304A0@kirei.se> On 11 aug 2009, at 13.06, Rickard Bondesson wrote: > Shouldn't the be an optional part of the > tag in the zonelist.xml? but the command will most likely be same for all zones? > The user can then decided what command to use per zone. And the > notify command will only be used when you have file out. why would use different commands based on zone? I can think of cases when I want a notiy command even with AXFR. jakob From rickard.bondesson at iis.se Tue Aug 11 11:42:42 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 11 Aug 2009 13:42:42 +0200 Subject: [Opendnssec-develop] NotifyCommand In-Reply-To: <6DAADE80-F453-4FFE-8751-84C007F304A0@kirei.se> References: <69830D4127201D4EBD146B9041199718E1EC19@EXCHANGE.office.nic.se> <6DAADE80-F453-4FFE-8751-84C007F304A0@kirei.se> Message-ID: <69830D4127201D4EBD146B9041199718E1EC21@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > Shouldn't the be an optional part of the > > tag in the zonelist.xml? > > but the command will most likely be same for all zones? > > > The user can then decided what command to use per zone. And > the notify > > command will only be used when you have file out. > > why would use different commands based on zone? > > I can think of cases when I want a notiy command even with AXFR. > > jakob Ok, just thinking if you are using multiple name servers or if you have file out for one zone and axfr for another zone. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoFZMuCjgaNTdVjaAQgtyggAnO3Qe0ANSJVRbqTnGKKx1U2Sq1AD1sz2 DC5TqyIJ+4kArTEyLTbW6QYhZI3oQjoZONAOdWCaV255dLKkCo4k6jxYOKLweGRz gBdTlsJhSRjEaSkXlghI9RmOF4deT50KuDgbHnS1REnYIvrmJlrbnqCHdpWIZ0WX 1wwc8WJkwhlQmHvGcecp5rIoWx0nKuYUgLk/a7/XIeqjr71zZOFkaCsV8qQEK3Z0 H8Keo2RCIg80Cp2TGgIpk0OlF6BcO5+D03rroWtrEPZhAN087cPvXSckoiHrVEVv uxnNQjIl/kYRBLr9LRMnmqwxQNwuX1cA/VhsjMhJlGc3ONGc+z5aVA== =IBSQ -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Tue Aug 11 11:49:23 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Tue, 11 Aug 2009 13:49:23 +0200 Subject: [Opendnssec-develop] NotifyCommand In-Reply-To: <69830D4127201D4EBD146B9041199718E1EC21@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718E1EC19@EXCHANGE.office.nic.se> <6DAADE80-F453-4FFE-8751-84C007F304A0@kirei.se> <69830D4127201D4EBD146B9041199718E1EC21@EXCHANGE.office.nic.se> Message-ID: <4A815AC3.40904@NLnetLabs.nl> Rickard Bondesson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >>> Shouldn't the be an optional part of the >>> tag in the zonelist.xml? >> but the command will most likely be same for all zones? >> >>> The user can then decided what command to use per zone. And >> the notify >>> command will only be used when you have file out. >> why would use different commands based on zone? >> >> I can think of cases when I want a notiy command even with AXFR. >> >> jakob > > Ok, just thinking if you are using multiple name servers or if you have file out for one zone and axfr for another zone. yeah, that would make sense; although you would get lots of duplicates now, later you will probably want to have AXFR master and ACLS per zone in the adapter config. btw was already in the release, just not in the .rnc. And it currently does not append the zone name to the command Jelte From Alexd at nominet.org.uk Tue Aug 11 12:41:18 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Tue, 11 Aug 2009 13:41:18 +0100 Subject: [Opendnssec-develop] Policy configuration checker Message-ID: Hi - At the get-together in Amsterdam, it was suggested that we needed a policy configuration checker. This would check the (presumably syntactically correct) configuration files to make sure that they were semantically correct. Stuff like : InceptionOffset < Validity Jitter < Validity (InceptionOffset + Jitter) < Validity Algorithm type consistent with NSEC3 etc... I'd propose to make this part of the auditor, with a simple '-p' / '--process' switch to run the policy checker (with a similar system or error code returns and logging for communication). I wasn't clear when (or by what) it would be called. Are there any other useful checks which should be performed? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Tue Aug 11 13:00:16 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 11 Aug 2009 15:00:16 +0200 Subject: [Opendnssec-develop] Policy configuration checker In-Reply-To: References: Message-ID: <4A816B60.5050807@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was thinking of adding a check keep implies no continuously resigning. Things will break if you allow this combination. I think it fits perfectly in the policy configuration checker. Matthijs Alexd at nominet.org.uk wrote: > Are there any other useful checks which should be performed? > > 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 iQEcBAEBAgAGBQJKgWteAAoJEA8yVCPsQCW5/0IH/ji+TuiO1JbPj+/n5kVh8tkC erqMIMgC2P/VEKz6T+HPSesDfTzL20OH3blmO9mOnViU+OyoF7RgQIovDNjSSvDA idACJxkbPNZpH9XeXKsyMTnVXTG1ntXlJaBW+JAAue4hfkfvXmkNWUPxWzUvsSiB wXN5Wbn8CQq+siY4l9W53rq8Z2+UMwaztqScK3OZsG1wMa/T120F9vEpkJAkL9KQ vr8oaM99JXfrTrYCD4+7mZoQZddAOf1peWeDM2mNHJW2WniclH3FkNHk/sOlXOb5 XqHoaxR9dK5+BpbdHI2QWIp8WqF6amJsvDX6u8yPgA7fstqMuNPsX9ESd6bYMuw= =NlOb -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Tue Aug 11 13:11:15 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 11 Aug 2009 15:11:15 +0200 Subject: [Opendnssec-develop] Policy configuration checker In-Reply-To: <4A816B60.5050807@nlnetlabs.nl> References: <4A816B60.5050807@nlnetlabs.nl> Message-ID: <69830D4127201D4EBD146B9041199718E1EC3C@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I was thinking of adding a check > keep implies no continuously > resigning. Things will break if you allow this combination. > > I think it fits perfectly in the policy configuration checker. > > Matthijs You do want continuously signing when using keep. It is just that the signer can not output anything if it has not got a zone with a new serial. I want my zone to be resigned every 5th minute, but a new zone will only arrive every second hour. Thus will only a new signed zone be created every second hour, and it has the same serial as the zone that arrived. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoFt8+CjgaNTdVjaAQh9tgf9G6ahsmXOviM9nZPxjV/fwe6woBvFdL1V EYWUwJ8zaIYudX7XqZhbg62ZjzueW9jp4r4uWwj069sR2YXpq67DzFWsWB98lDc8 DzFsx3kCixieu4WICitJvjqHeFgSuD78v2IcOULcJh0HeCuSWxtxmB81bY4ePZBg aAvDmzpGLL/A+VldPNECW+jTQp/bJ93FemthHJgZyuOfIsHT0u2SspOxcW8LyJMi cvWn8LPgRRLDH9XpJiPJ1xU8SG8lZPWYMrCqLZLg9800RHn9AkeVlaUeaQmiI7hi IW5sB075bmn5CDAYT+8htViCK3am4SOgQRCgDE2IN5hUEXEIty5nYw== =Epor -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Tue Aug 11 13:16:17 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 11 Aug 2009 15:16:17 +0200 Subject: [Opendnssec-develop] Policy configuration checker In-Reply-To: <69830D4127201D4EBD146B9041199718E1EC3C@EXCHANGE.office.nic.se> References: <4A816B60.5050807@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC3C@EXCHANGE.office.nic.se> Message-ID: <4A816F21.3080100@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 But why waste resign resources if you are not going to output it anyway? In this example, you can save 23 times resigning that will be unnoticed. Matthijs Rickard Bondesson wrote: >> I was thinking of adding a check >> keep implies no continuously >> resigning. Things will break if you allow this combination. > >> I think it fits perfectly in the policy configuration checker. > >> Matthijs > > You do want continuously signing when using keep. It is just that the signer can not output anything if it has not got a zone with a new serial. > > I want my zone to be resigned every 5th minute, but a new zone will only arrive every second hour. > > Thus will only a new signed zone be created every second hour, and it has the same serial as the zone that arrived. > > // 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 iQEcBAEBAgAGBQJKgW8eAAoJEA8yVCPsQCW5TYQIANrxCJ+ZndpuuDGrxODRpRU5 nU0dK9E9doWUb7XsggCaIU8lpTxuYwj/Gwlcy5Ft4WSiPx5fdrZNfXY4+eWlVmxl ABS7fFR5DZDWITRRp9pK6O7P/vnkJc3LswVATvV9qlJXZfPNWuii47mpsfxG4qbp 09W+EBNJ8dYn8uyV8Mk06HD8EWj96PO6czZrBk5cVdlu+W2Dw9WQrIk0EWclkxEb XoRgn/LDt2IMjE3sdJ0G542Z7YCXCM+TvrSAvjlRapZtlIZVYkpZnX7eNinSbVwc SEhi4Dz1gNztft48JOz0YlO7c9Jtw0LLgA45PbISrkJOEOvD4M6b8lUQ2zDC4+E= =W5H9 -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Tue Aug 11 13:33:15 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 11 Aug 2009 15:33:15 +0200 Subject: [Opendnssec-develop] Policy configuration checker In-Reply-To: <4A816F21.3080100@nlnetlabs.nl> References: <4A816B60.5050807@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC3C@EXCHANGE.office.nic.se> <4A816F21.3080100@nlnetlabs.nl> Message-ID: <69830D4127201D4EBD146B9041199718E1EC47@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > But why waste resign resources if you are not going to output > it anyway? > In this example, you can save 23 times resigning that will be > unnoticed. > > Matthijs But the signer should not do anything if the old signed file has the same soa as the unsigned file (and you have keep). Thus not wasting so much cpu. if (soa_serial_type == keep && signed_zone_soa == unsigned_zone_soa) { break_out_and_sleep_for_5_min(); } do_resign(); // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoFzGuCjgaNTdVjaAQhRsAf+J2kZuAvfReoYjz2TpVq5t+TTFGpQCZmh I67WkvWYvjK293i3uX6TXY/VuuJKTKeH9fjthT8LItPMw3h4aUOoNU9NDj7vLitC IaNueOq+3GqIAIF2Uvs9JpL0QlRVo5hNcwQwTWNleLbFhy+gvVvyGr1A3/1THDnm +a5dn9Cg2mjJbVKYIuEK0cEuFKA5qpTVnErdpdQwc3LQ7rBIkh8vjBQgKZe+PuGy 7UWA6zkVOdpgCJWLoZIDT0rccddje3ueZycOA+U9+kMxlaUePY5ESYQzo4wQ1qni 1so+V27AuL1TUCnMwSidbtBCJXQ7RhMIVyUVPiLmBdntmv8DCMwfbA== =Kl6q -----END PGP SIGNATURE----- From jakob at kirei.se Tue Aug 11 15:55:55 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 11 Aug 2009 17:55:55 +0200 Subject: [Opendnssec-develop] NotifyCommand In-Reply-To: <69830D4127201D4EBD146B9041199718E1EC21@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718E1EC19@EXCHANGE.office.nic.se> <6DAADE80-F453-4FFE-8751-84C007F304A0@kirei.se> <69830D4127201D4EBD146B9041199718E1EC21@EXCHANGE.office.nic.se> Message-ID: <87AC7829-A8F4-475A-BEDC-79A15185B7CE@kirei.se> On 11 aug 2009, at 13.42, Rickard Bondesson wrote: > Ok, just thinking if you are using multiple name servers or if you > have file out for one zone and axfr for another zone. we can always add a zone-specific NotifyCommand later I guess. jakob From sion at nominet.org.uk Wed Aug 12 08:38:02 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 12 Aug 2009 09:38:02 +0100 Subject: [Opendnssec-develop] Key (HSM) backup Message-ID: Morning, we have a requirement that we do not use keys until they are backed up (this is currently not implemented). To deal with this we have the concept of a "backup delay" in conf.xml; in theory the time that might pass before a key can be considered to be backed up. This has a number of issues, so I have a task to add a "backup done" call to ksmutil which can be called as part of any backup routine. My question is, does this remove the need for the backup delay parameter? Or do we want a system where a key is considered to be backed up either if that period of time has passed, or if we have been explicitly told that the backup has happened? My preference is to remove the "backup delay" and force use of "ksmutil backup done". Sion p.s. If a key has not been backed up is it still okay to prepublish it? I was only going to stop it from becoming active, please tell me if this is wrong. From rickard.bondesson at iis.se Wed Aug 12 09:39:39 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 12 Aug 2009 11:39:39 +0200 Subject: [Opendnssec-develop] Alteration of DNS data Message-ID: <69830D4127201D4EBD146B9041199718E1ECB0@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Is it ok for OpenDNSSEC to alter the DNS data of non-DNSSEC RR? Unsigned: label6.zone1.org. 3600 IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334 Signed: label6.zone1.org. 3600 IN AAAA 2001:db8:85a3::8a2e:370:7334 Shouldn't the data field (in this case the IP address) be kept in the original format? Even though the two data strings represent the same information? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoKN2+CjgaNTdVjaAQgVngf+MGnmLwHOUQZ7hfb3V9vbboVdJra0ZFF9 k+9uqK0jbPsoYNtEpjoLGOEobTC4KhEMs/Mo0ffYjoIo/eR9h6wwVh+5AwgT01Cp sbQkC2EtNNJ0hNO3/pXMrRD+1GjJPQ2K+H0uKOwVKzRxrwHlW7wH+8U5KbKK+G2p cho8XAUtwv4kxHGgzAyoVg20PeOXSuf6Imw6SyI0y06LKbUew9HJ17O49onJIW08 LGw2iSER2AJ//jeP07mAZrW2cfys11UVchd7CGbzogs2LxELSd6IZatCp/NYAzVh nO6/2TB4r5dESWDJ+eGOuOYQVFeDwf2OjaJPVEzaoNqUBTGcY55X3g== =GIwQ -----END PGP SIGNATURE----- From jakob at kirei.se Wed Aug 12 09:46:59 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 12 Aug 2009 11:46:59 +0200 Subject: [Opendnssec-develop] Alteration of DNS data In-Reply-To: <69830D4127201D4EBD146B9041199718E1ECB0@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718E1ECB0@EXCHANGE.office.nic.se> Message-ID: <013288C3-8DF7-4425-9E60-B0E9AE600C01@kirei.se> On 12 aug 2009, at 11.39, Rickard Bondesson wrote: > Is it ok for OpenDNSSEC to alter the DNS data of non-DNSSEC RR? data, no - formatting yes. > Unsigned: > label6.zone1.org. 3600 IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334 > > Signed: > label6.zone1.org. 3600 IN AAAA 2001:db8:85a3::8a2e: > 370:7334 > > Shouldn't the data field (in this case the IP address) be kept in > the original format? no. jakob From sion at nominet.org.uk Wed Aug 12 11:19:03 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 12 Aug 2009 12:19:03 +0100 Subject: [Opendnssec-develop] enforcer database changes Message-ID: In getting the first part of the key backup done I have added a new column to a table in the enforcer database. If you need to migrate an existing database then there are some scripts (even though the change is trivial) in "enforcer/utils". So, for a sqlite DB run something like: sqlite3 < migrate_090812_1.sqlite3 (This will become more important when I commit the rest of the work on backups.) Would folk be happier with a ksmutil command to run these migration scripts? (Assuming that there will be more in the future.) Sion p.s. If you are running the full setup command then this migration is not needed. From rickard.bondesson at iis.se Wed Aug 12 11:24:03 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 12 Aug 2009 13:24:03 +0200 Subject: [Opendnssec-develop] enforcer database changes In-Reply-To: References: Message-ID: <69830D4127201D4EBD146B9041199718E1ECC7@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > In getting the first part of the key backup done I have added > a new column to a table in the enforcer database. > > If you need to migrate an existing database then there are > some scripts (even though the change is trivial) in "enforcer/utils". > > So, for a sqlite DB run something like: > > sqlite3 < migrate_090812_1.sqlite3 > > (This will become more important when I commit the rest of the work on > backups.) > > Would folk be happier with a ksmutil command to run these > migration scripts? (Assuming that there will be more in the future.) > > Sion > > p.s. If you are running the full setup command then this > migration is not needed. Will the user get a warning if it is using the new libksm on an old database? Are you using a database scheme version number? So the user will know in what order it should apply future migration scripts. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoKmU+CjgaNTdVjaAQjVKgf/eqYmj6ESh7/Rk0LieY8+3hG6f9lSJAV4 F5+RiBEsVnsto/XtuZUqbDTaG3e8/1OyVOXyNNnc38v/lUha1ww+dXzaH68gfE2O blYMqpLS5SKcOaFbZv1Snxbu0VnBDZC/rP+8K9TgFAOiVcOdrmSfHZyQDuj87nqg 6dgvicMVEbyuzkmTeLSg7GUrY2K3RGg9EM4nFEXb7hNFBEbv6Vlg05sRO3nJ3j+h BPjkLfdHIe38IWmQ0aAZXdeW1udTtZtFRY7d48BEGJ7yW+4AfPEGsbfg7vtWrpjB zqBEmGT6R0ZARrocNhyB/jvxaWtoDZjjdyra5aGjvFBJ6lq0R54PtA== =S02d -----END PGP SIGNATURE----- From jakob at kirei.se Wed Aug 12 12:16:06 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 12 Aug 2009 14:16:06 +0200 Subject: [Opendnssec-develop] Key (HSM) backup In-Reply-To: References: Message-ID: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> On 12 aug 2009, at 10.38, sion at nominet.org.uk wrote: > My preference is to remove the "backup delay" and force use of > "ksmutil > backup done". ++ do we need an option to turn this off? I believe so. > p.s. If a key has not been backed up is it still okay to prepublish > it? I > was only going to stop it from becoming active, please tell me if > this is > wrong. dunno. Rickard? jakob From rickard.bondesson at iis.se Wed Aug 12 12:32:46 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 12 Aug 2009 14:32:46 +0200 Subject: [Opendnssec-develop] Key (HSM) backup In-Reply-To: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> References: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> Message-ID: <69830D4127201D4EBD146B9041199718E1ECD2@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > My preference is to remove the "backup delay" and force use of > > "ksmutil backup done". > > ++ > > do we need an option to turn this off? I believe so. +1 Yeah, have a tag similar to The reason to have a negative tag is because you want to opt-in the security features. Is this tag then for Or > > p.s. If a key has not been backed up is it still okay to > prepublish > > it? I > > was only going to stop it from becoming active, please tell me if > > this is > > wrong. > > dunno. Rickard? +1 No problem of prepublishing the key, since the key is not in use. If the key is lost then you will not break anything. The only thing is that it would take somewhat longer to roll the current key after it has been restored, since you have no prepublished key in the backup. But that is not an issue. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoK2buCjgaNTdVjaAQjb+wf/QpOiHonImHkEMuqs98DeZRrMImAm9g19 7p4Z/zVr8ftmCWFVBgSH/VkftX4lTBHdQMoDsTB9f9YY9wBqbRAY/SWvUDxaDuB6 c327fCn8ehpLWcjNzl/jMmGnbjcG2HGYeKICjb9JLhWVx/SJ54wzSuZY/Sa0L++b YFsXuvf+pvRrylIqiajEkpAbGKeq8/PRISDGF6vEeo5+XFGM5VkS7hiZqav2iWKg tkmMNbdtrRBt8aAAMGgrSH/hol19a3gtVbGa0on1LiGZqmdFNYdGr1cO5353NtCp MT4T1zaxDYq8f5LI2a2SCmWwgMe4axj0wZ8ybtMSMVfApjhdy60AIQ== =goBK -----END PGP SIGNATURE----- From sion at nominet.org.uk Wed Aug 12 12:46:27 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 12 Aug 2009 13:46:27 +0100 Subject: [Opendnssec-develop] Key (HSM) backup In-Reply-To: <69830D4127201D4EBD146B9041199718E1ECD2@EXCHANGE.office.nic.se> References: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> <69830D4127201D4EBD146B9041199718E1ECD2@EXCHANGE.office.nic.se> Message-ID: > Yeah, have a tag similar to > The reason to have a negative tag is because you want to opt-in the > security features. > > Is this tag then for > > > > Or > > Or even a property of the repository? From jakob at kirei.se Wed Aug 12 20:23:53 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 12 Aug 2009 22:23:53 +0200 Subject: [Opendnssec-develop] Key (HSM) backup In-Reply-To: References: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> <69830D4127201D4EBD146B9041199718E1ECD2@EXCHANGE.office.nic.se> Message-ID: On 12 aug 2009, at 14.46, sion at nominet.org.uk wrote: >> Yeah, have a tag similar to >> The reason to have a negative tag is because you want to opt-in the >> security features. >> >> Is this tag then for >> >> >> >> Or >> >> > > Or even a property of the repository? yes, that makes sense. perhaps something like this: Configuration/RepositoryList/Repository/RequireBackup (empty element) it is a feature you turn on. most people will assume that they don't have to flag keys as backed up so the default should be off IMHO. jakob From sion at nominet.org.uk Thu Aug 13 07:25:04 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 13 Aug 2009 08:25:04 +0100 Subject: [Opendnssec-develop] Key (HSM) backup In-Reply-To: References: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> <69830D4127201D4EBD146B9041199718E1ECD2@EXCHANGE.office.nic.se> Message-ID: > >> Yeah, have a tag similar to > >> The reason to have a negative tag is because you want to opt-in the > >> security features. > >> > >> Is this tag then for > >> > >> > >> > >> Or > >> > >> > > > > Or even a property of the repository? > > yes, that makes sense. perhaps something like this: > > Configuration/RepositoryList/Repository/RequireBackup (empty element) > > it is a feature you turn on. most people will assume that they don't > have to flag keys as backed up so the default should be off IMHO. So the default is to be able to use keys that are not backed up? I thought that this was the less desirable option... Anyway, I'll make sure that a suitably apocalyptic message is logged if a non-backed up key becomes active. Sion From jakob at kirei.se Thu Aug 13 07:29:06 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 13 Aug 2009 09:29:06 +0200 Subject: [Opendnssec-develop] Key (HSM) backup In-Reply-To: References: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> <69830D4127201D4EBD146B9041199718E1ECD2@EXCHANGE.office.nic.se> Message-ID: On 13 aug 2009, at 09.25, sion at nominet.org.uk wrote: > So the default is to be able to use keys that are not backed up? I > thought > that this was the less desirable option... in theory yes, but for any practical use no. so I vote for the default to use keys before backup (and clearly state in the default config file how to enable backup checking) > Anyway, I'll make sure that a suitably apocalyptic message is logged > if a > non-backed up key becomes active. right! j From rickard.bondesson at iis.se Thu Aug 13 07:43:35 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 13 Aug 2009 09:43:35 +0200 Subject: [Opendnssec-develop] Key (HSM) backup In-Reply-To: References: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> <69830D4127201D4EBD146B9041199718E1ECD2@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B9041199718E1ED56@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > So the default is to be able to use keys that are not backed up? I > > thought that this was the less desirable option... > > in theory yes, but for any practical use no. so I vote for > the default to use keys before backup (and clearly state in > the default config file how to enable backup checking) > > > Anyway, I'll make sure that a suitably apocalyptic message > is logged > > if a non-backed up key becomes active. > > right! Do we also want to have a backup-hook? So OpenDNSSEC can run a command when a backup should be done according to the system. Maybe the user wants a backup script to be run. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoPEJ+CjgaNTdVjaAQhDMgf+JQMvbAYlkcyCCkewV6W0A2/usEfYNbv6 wJCsA3R8KZTmzv321hyeST9lJzG3QlnzuLNT7Tvq8PrEDjIwKsFkizia8FotprK1 63RNOkUOKTi9qet/C+TEZCgpQr1CfdE8SDO2z82mHPBJgiJaSCefBhzT4FV5VXFn uUu82xMTF8AqNFdgXesl2YrR+FhY+V0fFOIavZy9BQSWw7K3AvoKOiFnB+73vrfI P3CSNH4v3G0LGwPodMCX26t2TtEbhSLG5vCz9n1ifcuFHGUxuKVki2v7RW9kQP1Z KSGcM/mmuV/n+JlL0Y7ksVl7w7YvB5H414ziL85XwDRvQaPMoqURbA== =y+wY -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Aug 13 09:41:03 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 13 Aug 2009 09:41:03 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #13: "engine: no new signatures, keeping zone" when changing zone parameters Message-ID: <058.aa1d6fb1117521292b7da9d6cb0ad93f@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: jakob Type: defect | Status: new Priority: minor | Component: Unknown Version: | Keywords: ---------------------------------+------------------------------------------ Hi, I'm not sure if this is a bug or me doing something wrong. But I have obsrevered on several occations the message "engine: no new signatures, keeping zone" i the logg when I have expected a new zone to be generated. This seams to happen when you don't really change any RRs. The changes I have done to the zone then could have been either just changing the zone serial in the SOA or zone encryption parameters in kasp.xml. Neither of thoose two changes have resulted in a new zone even thou I would expect them to. The work around for me was to clean the zone reletad files i /var/opendnssec/tmp/ and then run the sign command one again. Maybe this is two bugs? Perhaps ksmutil update should clean tmp if it detects changes for a zone(?is this how it works?) and maybe sign_engine should consider zoneserial in unsigned zone as a change, even thou it generates its own serial in signed zone. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 13 11:13:22 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 13 Aug 2009 11:13:22 -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.1e4e559049747e1f86b2a3b05969f3a0@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: jelte Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: | ---------------------------------+------------------------------------------ Changes (by jakob): * owner: jakob => jelte * status: new => assigned Comment: It seems as the engine doesn't resign even though the SignerConfiguration has changed. On the other hand it could be difficult to detect when you absolutely has to resign, maybe we should require that one forces a resign using the signer_engine_cli when the policy has changed? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 13 11:30:32 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 13 Aug 2009 11:30:32 -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.3820f02c2ae9060b256df849590a6238@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: jelte Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by jelte): but if no data in the output has changed, what do you want signed then? or do you want a full resign of every rr? -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Thu Aug 13 12:42:08 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 13 Aug 2009 13:42:08 +0100 Subject: [Opendnssec-develop] Auditor daemon Message-ID: Hi - I'm just looking at daemonizing the auditor. Then I realised I wasn't quite sure what was meant to happen... How often is the auditor meant to run in daemon form? Is this configurable? What should happen if the auditor daemon encounters errors in the signed zone? Is this configurable? Thanks! Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Thu Aug 13 13:10:07 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 13 Aug 2009 13:10:07 -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.7904e66306d21826ccfc0797efbfb9ea@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: jelte Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by mattias at nonetwork.se): Maybe I was not clear, but I meant to say that this happens even when I wish to do a manual resign with signer_engine_cli. If I manually update the zone version number in the unsigned zone and do a manual resign I at least would expect a updated SOA record with new version number even in the signed zone, triggering a reload of the zone on my slave servers. If I change the zone signing parameters i kasp.xml for instance changing signing algorithm I would then expect a resign of all records in the zone. /Mattias -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 13 13:17:50 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 13 Aug 2009 13:17:50 -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.ba5002470b658b133b2f9c06d4a200ef@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: jelte Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by rb): A signature is refreshed when (Now > (Expiration - Refresh)) Even if you roll key algorithm the signatures are still valid for a time. New signatures will be produced with the your new algorithm. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 13 13:20:09 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 13 Aug 2009 13:20:09 -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.327e147ce8a8698ca68591f460d26c1b@kirei.se> #10: "signer_engine_cli sign all" Error --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jelte Type: defect | Status: closed Priority: major | Component: Unknown Version: | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Changes (by rb): * status: assigned => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 13 13:20:24 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 13 Aug 2009 13:20:24 -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.fd013e1fcc25c1f1dc971dfcf1bf8f86@kirei.se> #11: Issue with $TTL and zone_reader --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jelte Type: defect | Status: closed Priority: major | Component: Unknown Version: | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Changes (by rb): * status: assigned => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 13 13:24:15 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 13 Aug 2009 13:24:15 -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.6ee4e00191ee13416f0ca3a810203e59@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: jelte Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by mattias at nonetwork.se): Yes, I understand this and that is fine. But at as I see it it would at least be handy to have the option to resign it at once. That would not break anything, would it? -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Thu Aug 13 13:38:11 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 13 Aug 2009 15:38:11 +0200 Subject: [Opendnssec-develop] dropping privs Message-ID: <6B100A64-A3FF-48DB-A86B-EF513DFC7267@kirei.se> until we have better support for dropping privs (as we would be using privsep), Jelte & I just agreed to: 1. write pid 2. chroot 3. drop privs 4. create any sockets we can always try to unlink the pid-file upon exit(), but in case we're chrooted that will fail. jakob From sion at nominet.org.uk Thu Aug 13 15:27:42 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 13 Aug 2009 16:27:42 +0100 Subject: [Opendnssec-develop] Another day, another database change... Message-ID: Hi there, I've got another change to the enforcer database (svn r1614), like yesterdays it is trivial and I have provided a migration script so run: sqlite3 < enforcer/utils/migrate_090813_1.sqlite3 (You will also need to run yesterdays script if you have not already; or nuke your database with ksmutil setup.) Unlike yesterday this one is needed to run the latest communicated and possibly ksmutil [setup|update] (it depends on your conf.xml). This commit adds a check for keys being backed up and warns or throws an error depending on how your repository is set up. If you use the migration script then RequireBackup will be set to "true" by default for any existing repositories; run ksmutil update to sync your db with your conf.xml if this is not what you want. So the new messages are: ERROR: Trying to make non-backed up [KSK|ZSK] active when RequireBackup flag is set Signconf not written for [ZONE] and WARNING: Making non-backed up [KSK|ZSK] active, PLEASE make sure that you know the potential problems of using keys which are not recoverable Sion From jad at jadickinson.co.uk Thu Aug 13 15:42:26 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 13 Aug 2009 16:42:26 +0100 Subject: [Opendnssec-develop] dropping privs In-Reply-To: <6B100A64-A3FF-48DB-A86B-EF513DFC7267@kirei.se> References: <6B100A64-A3FF-48DB-A86B-EF513DFC7267@kirei.se> Message-ID: Is this just for a network exposed XFR capable signer or all server processes? In other words are we worried about local exploits as well? I did think of removing the priv dropping from the enforcer daemon code I nicked from NSD since for most stuff there is no need to ever run as root in the first place. John On 13 Aug 2009, at 14:38, Jakob Schlyter wrote: > until we have better support for dropping privs (as we would be > using privsep), Jelte & I just agreed to: > > 1. write pid > 2. chroot > 3. drop privs > 4. create any sockets > > we can always try to unlink the pid-file upon exit(), but in case > we're chrooted that will fail. > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From jakob at kirei.se Thu Aug 13 15:49:54 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 13 Aug 2009 17:49:54 +0200 Subject: [Opendnssec-develop] dropping privs In-Reply-To: References: <6B100A64-A3FF-48DB-A86B-EF513DFC7267@kirei.se> Message-ID: <4E6FC435-EA96-441C-9EE8-2731504A2921@kirei.se> On 13 aug 2009, at 17.42, John Dickinson wrote: > Is this just for a network exposed XFR capable signer or all server > processes? for both the enforcer daemons and the signer engine. > In other words are we worried about local exploits as well? I did > think of removing the priv dropping from the enforcer daemon code I > nicked from NSD since for most stuff there is no need to ever run as > root in the first place. right, I'm not sure we should keep chroot for the release - perhaps drop privs is enough for now? if so, we should probably just drop privs, then write pid and sockets and whatnot. jakob From sion at nominet.org.uk Fri Aug 14 07:48:23 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Fri, 14 Aug 2009 08:48:23 +0100 Subject: [Opendnssec-develop] Key (HSM) backup In-Reply-To: <69830D4127201D4EBD146B9041199718E1ED56@EXCHANGE.office.nic.se> References: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> <69830D4127201D4EBD146B9041199718E1ECD2@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B9041199718E1ED56@EXCHANGE.office.nic.se> Message-ID: > Do we also want to have a backup-hook? So OpenDNSSEC can run a > command when a backup should be done according to the system. > > Maybe the user wants a backup script to be run. Maybe we should write an example script which would backup the softHSM and then call ksmutil; just to show the process? We could also add something to the keygend that can call a script after every run, so that keys can be backed up as they are generated. Is that what you had in mind? Sion From jad at jadickinson.co.uk Fri Aug 14 08:59:55 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Fri, 14 Aug 2009 09:59:55 +0100 Subject: [Opendnssec-develop] Key (HSM) backup In-Reply-To: References: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> <69830D4127201D4EBD146B9041199718E1ECD2@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B9041199718E1ED56@EXCHANGE.office.nic.se> Message-ID: <2299E2C7-5DCD-4803-BCEF-3EAF84723BD9@jadickinson.co.uk> On 14 Aug 2009, at 08:48, sion at nominet.org.uk wrote: >> Do we also want to have a backup-hook? So OpenDNSSEC can run a >> command when a backup should be done according to the system. >> >> Maybe the user wants a backup script to be run. > > Maybe we should write an example script which would backup the > softHSM and > then call ksmutil; just to show the process? > The process will be completely different for every HSM. Usually (I expect) it will be totally out of band and a script will be able to do nothing. IMHO a syslog message that can be parsed by a monitoring system like nagios is all we should do. If we want OpenDNSSEC to be more "pro- active" then send a SNMP trap. (If we want to future proof it then NETCONF it :) ). We could also write a net-snmp agent extension or nagios plugin to do the monitoring if so desired. We should not develop a whole notification system with emails/pages being sent out. That is a problem already solved by snmp/netconf/ nagios etc. John From jakob at kirei.se Fri Aug 14 11:34:30 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 14 Aug 2009 13:34:30 +0200 Subject: [Opendnssec-develop] Key (HSM) backup In-Reply-To: <2299E2C7-5DCD-4803-BCEF-3EAF84723BD9@jadickinson.co.uk> References: <1EC74F1B-FB43-46B6-82A9-C5F76293F759@kirei.se> <69830D4127201D4EBD146B9041199718E1ECD2@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B9041199718E1ED56@EXCHANGE.office.nic.se> <2299E2C7-5DCD-4803-BCEF-3EAF84723BD9@jadickinson.co.uk> Message-ID: On 14 aug 2009, at 10.59, John Dickinson wrote: > The process will be completely different for every HSM. Usually (I > expect) it will be totally out of band and a script will be able to > do nothing. I agree completely. > IMHO a syslog message that can be parsed by a monitoring system like > nagios is all we should do. If we want OpenDNSSEC to be more "pro- > active" then send a SNMP trap. (If we want to future proof it then > NETCONF it :) ). > > We could also write a net-snmp agent extension or nagios plugin to > do the monitoring if so desired. > > We should not develop a whole notification system with emails/pages > being sent out. That is a problem already solved by snmp/netconf/ > nagios etc. ++ j From sion at nominet.org.uk Fri Aug 14 11:38:51 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Fri, 14 Aug 2009 12:38:51 +0100 Subject: [Opendnssec-develop] "ksmutil list keys" Message-ID: Good afternoon, What do people want to see when they type "ksmutil list keys" ? Just the keys that have been allocated to zones? And what information for each key? zone, state, keytype, date of next state transition? where to find the key? Should it show dead keys? There are probably many use cases for this command, but I need to make a start somewhere; so how about: ksmutil list keys [zone] giving an output something like: Zone: Keytype: State: Date of next state transition: my.zone KSK ACTIVE 2009-08-14 18:07:51 my.zone KSK PUBLISHED 2009-08-14 18:07:51 my.zone ZSK ACTIVE 2009-08-14 18:07:51 my.zone ZSK PUBLISHED 2009-08-14 18:07:51 >From which we can add options? Sion From rickard.bondesson at iis.se Fri Aug 14 11:52:17 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Fri, 14 Aug 2009 13:52:17 +0200 Subject: [Opendnssec-develop] "ksmutil list keys" In-Reply-To: References: Message-ID: <69830D4127201D4EBD146B9041199718F7605B@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > ksmutil list keys [zone] > > giving an output something like: > > Zone: Keytype: State: Date of next state transition: > my.zone KSK ACTIVE 2009-08-14 18:07:51 > my.zone KSK PUBLISHED 2009-08-14 18:07:51 > my.zone ZSK ACTIVE 2009-08-14 18:07:51 > my.zone ZSK PUBLISHED 2009-08-14 18:07:51 And perhaps the key id (keypairs->HSMkey_id) and repository (securitymodules->name). -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoVP8eCjgaNTdVjaAQjmkggAi+FR78eGO+DXK1rnLNtXDfcQZwSNJwZ1 sbXShxW50We4tqP2SFyssFQCR4Y8MfA2cccdYRlyZRURnrO/QXlRqyASRy9Jp/sc 2jeuXxo99hU2/KsgpcedSG25Bx5JKqSrQKtEGNenOtWQj3RUF7cYa6LgRF80uJUV glnDcUDTHlRs0dfZ5Ypxt+AeHyVpaSKjz5h1sBcfiK1+5nVHewvcnleg/bYrmx9w fd7AgS8wa43ghHAI82mQ3Ce7+yUIA+6TTA1L9oCsz7pG3PK6McUTLDO1auBbckqp Ivjp7GtXrZjeI3E6rhe2p1TI6LJBzbSCz4i2Ti84A6mQRQOFPjaQVw== =pTvr -----END PGP SIGNATURE----- From jakob at kirei.se Fri Aug 14 12:01:39 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 14 Aug 2009 14:01:39 +0200 Subject: [Opendnssec-develop] "ksmutil list keys" In-Reply-To: <69830D4127201D4EBD146B9041199718F7605B@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718F7605B@EXCHANGE.office.nic.se> Message-ID: <17657AD3-943A-4005-8B1C-6AB806AF22F4@kirei.se> On 14 aug 2009, at 13.52, Rickard Bondesson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >> ksmutil list keys [zone] >> >> giving an output something like: >> >> Zone: Keytype: State: Date of next state transition: >> my.zone KSK ACTIVE 2009-08-14 18:07:51 >> my.zone KSK PUBLISHED 2009-08-14 18:07:51 >> my.zone ZSK ACTIVE 2009-08-14 18:07:51 >> my.zone ZSK PUBLISHED 2009-08-14 18:07:51 > > And perhaps the key id (keypairs->HSMkey_id) and repository > (securitymodules->name). yes, but perhaps hidden until you do 'ksmutil -v list keys [zone]' ? j From jakob at kirei.se Fri Aug 14 13:00:22 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 14 Aug 2009 15:00:22 +0200 Subject: [Opendnssec-develop] FYI: chroot dropped for now In-Reply-To: <4E6FC435-EA96-441C-9EE8-2731504A2921@kirei.se> References: <6B100A64-A3FF-48DB-A86B-EF513DFC7267@kirei.se> <4E6FC435-EA96-441C-9EE8-2731504A2921@kirei.se> Message-ID: <9CCFA089-3BAC-4B95-ADD7-75A18AD9C7F9@kirei.se> On 13 aug 2009, at 17.49, Jakob Schlyter wrote: > right, I'm not sure we should keep chroot for the release - perhaps > drop privs is enough for now? if so, we should probably just drop > privs, then write pid and sockets and whatnot. at today's informal jabber chat we just decided to drop chroot for now. it may be resurrected later. jakob From owner-dnssec-trac at kirei.se Fri Aug 14 13:39:25 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 14 Aug 2009 13:39:25 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #14: FEDORA CORE 11 install problem Message-ID: <063.1bfc66854837d2fb03e1b6ccf9c05bde@kirei.se> #14: FEDORA CORE 11 install problem --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jakob Type: defect | Status: new Priority: major | Component: Unknown Version: | Keywords: --------------------------------------+------------------------------------- When installing, via the regression/linux path, it complains when trying to configure the enforcer as it can not find the libraries from libhsm. e.g. {{{ cd regression/linux make # make errors cd obj/enforcer make && make install cd ../.. make && make install }}} This then works. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Aug 14 13:53:43 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 14 Aug 2009 13:53:43 -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.2b575d2be2f17227fe31d824d5c5daf1@kirei.se> #14: FEDORA CORE 11 install problem --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jakob Type: defect | Status: closed Priority: major | Component: Unknown Version: | Resolution: wontfix Keywords: | --------------------------------------+------------------------------------- Changes (by rb): * status: new => closed * resolution: => wontfix Comment: Ahh. This one is for Ubuntu and internal use. Please use the main configure script in trunk. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Fri Aug 14 14:34:29 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Fri, 14 Aug 2009 15:34:29 +0100 Subject: [Opendnssec-develop] "ksmutil list keys" In-Reply-To: <17657AD3-943A-4005-8B1C-6AB806AF22F4@kirei.se> References: <69830D4127201D4EBD146B9041199718F7605B@EXCHANGE.office.nic.se> <17657AD3-943A-4005-8B1C-6AB806AF22F4@kirei.se> Message-ID: > > > > And perhaps the key id (keypairs->HSMkey_id) and repository > > (securitymodules->name). > > yes, but perhaps hidden until you do 'ksmutil -v list keys [zone]' ? Okay, I've added a story in pivotal for the -v flag. The spec for ksmutil list in general was slightly lacking, so I implemented some stuff that seemed reasonable to me. If you see anything which is not to your liking then please let me know. E.g. listing policies only lists their names and description... is that enough? There are a couple of undocumented features of the command too. Type "ksmutil list" on its own to go through all of the functionality. You only need to specify the first 3 letters of the subcommand for it to run. (As a consequence "ksmutil list reptile" will list repositories, I can tighten this up if it is a problem.) Sion From rickard.bondesson at iis.se Fri Aug 14 14:40:14 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Fri, 14 Aug 2009 16:40:14 +0200 Subject: [Opendnssec-develop] Telephone meeting 18 August Message-ID: <69830D4127201D4EBD146B9041199718F760EF@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Next meeting is on 18th August Date: Tuesday 18 August Time: 14:00-16:00 CEST Please update the agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2009-08-18 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoV3TuCjgaNTdVjaAQgFcAf+Ov3dZSjkB48EVbluiznyHfESK0wqgayw qzujpFOMqYbn/jy2TrABev18mVw8c2Si2YhE2DH4R3x7dFSABqoAWWnjosVziJSq HbS0jRRMY6ylhY3Qei3li9po1IyiYbQf12YiOfsh+yr285+gBZ27ORLf/hSXic0f FEUKhEN0GP0OJ5OIjD3I+xxMKQ2U/8iNzbTf1vntwshOmEcag19wVJyvZa0SH/R6 PRSG4IcRFQ/tGV+IbU6HHQ8sDiFH03/mCHrR0Wc0246rYOoQPEYiO1XuY1UmIggq 4qdqrhGl98jlHq7jeKZbmhJYRsVTPEslAd7fqxQAMJwxTcMAW3RHhA== =2W1J -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Fri Aug 14 15:34:21 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 14 Aug 2009 15:34:21 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #15: OpenDNSSEC relase names should be package management friendly Message-ID: <052.344f02e101c2cbfca0f49b9ed05fb58b@kirei.se> #15: OpenDNSSEC relase names should be package management friendly ---------------------------+------------------------------------------------ Reporter: noa at resare.com | Owner: jakob Type: enhancement | Status: new Priority: minor | Component: Unknown Version: | Keywords: ---------------------------+------------------------------------------------ I just noted on twitter and elsewhere that OpenDNSSEC 1.0a2 has been released. Assuming that there will be an 1.0 release in the future this is exactly the kind of release naming that software distribution efforts such as Linux distributions frown upon. Release names can tell you a lot of things, but one of the more important things are which package is older and which one is newer. If at all possible, I think that it should be considered to move to a release naming scheme that uses dot separated integer parts that increase from release to release. That way it is not only easy for humans to determine which version is newer and which one is older, but it also works neatly with systems doing automatic package management such as rpm/yum or apt-get. If you want do indicate that a release is alpha/beta/release candidate, that could be done by appending such labels after the numeric part (see for example the Tor project). That way 0.99.4.beta is obviously a beta, but can be sorted with 0.99.6.rc in a straight forward way. I understand that moving to a release naming scheme with numeric part < 1.0 now that 1.0a2 has been released could be somewhat counter intuitive. Because of this a switch in naming perhaps should be done after the 1.0 release, but please consider this change. Also, to indicate releases that lead up to a specific release, you can use the .90 notation used by some projects. That way the releases leading up to 1.4 can be named 1.3.90.1 1.3.90.2 1.3.90.3 and so on, a method that has nice sorting properties. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 17 08:33:04 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 17 Aug 2009 08:33:04 -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.4740f4072ab2e342fea15c659bc201a8@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: jelte Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by rb): There is a command "signer_engine_cli clear ", which deletes the internal storage of the given zone name. All signatures will be regenerated on the next re-sign. Would that work for you? What SOA format have you configured in your kasp.xml? ("counter" | "unixtime" | "datecounter" | "keep") -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 17 08:45:49 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 17 Aug 2009 08:45:49 -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.8d95d99bc807f4361a0a3809d3b5d650@kirei.se> #15: OpenDNSSEC relase names should be package management friendly ---------------------------+------------------------------------------------ Reporter: noa at resare.com | Owner: rb Type: enhancement | Status: accepted Priority: minor | Component: Unknown Version: | Resolution: Keywords: | ---------------------------+------------------------------------------------ Changes (by rb): * owner: jakob => rb * status: new => accepted Comment: Thank you, will remember to fix this after that we have released 1.0 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 17 08:55:51 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 17 Aug 2009 08:55:51 -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.114299c025ff4067f986d0f757bf1891@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: jelte Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by mattias at nonetwork.se): I use datecounter SOA format. Yes, I guess signer_engine_cli clear would work. Guess I missed that option, I did delete and then add, but if I remember correct then there where still files in the tmp dir which I had to remove. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at openfortress.nl Tue Aug 18 08:14:27 2009 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 18 Aug 2009 08:14:27 +0000 Subject: [Opendnssec-develop] Re: hsmbully considered harmful? In-Reply-To: References: Message-ID: <20090818081427.GA14761@phantom.vanrein.org> Hey Jakob, > when I ran hsmbully on the Sun SCA6000, it crashed the machine... > kaboom! Ehm? That is not only surprising, but it's also very little information for me to work on. I certainly do my best to test thoroughly, but I would not imagine any commercial HSM to "go kaboom", regardless of what that means, when spoken to over its PKCS #11 interface. If it does, it almost certainly qualifies as a bad implementation. > I think we should add a note telling people that running hsmbully can > be harmful. That's as good as saying "don't use this tool". If there is any problem we should specify in detail what it is, rather than use subjective scary terms. > to be honest, I'm not sure I'm ready to ship this tool just yet. of > course it shouldn't crash, but IMHO if people want to test if their > HSM is OpenDNSSEC compliant they better just try the libhsm > speedtester for now (btw, should we install that by default?). Has the speedtester been designed as an exhaustive PKCS #11 test? If so, we have duplicate code and one can go. If not, then there is an added value for hsmbully. If an HSM cracks on any PKCS #11 call, it's a bad implementation, it's as simple as that. I know it's human nature, and often correct, to blame the new code, but really, this sounds to me like a broken HSM. I make no bypass calls to anything that is not PKCS #11, after all. People should be warned about those instead of about a tool testing it? > panic[cpu1]/thread=ffffffff8f3d8140: BAD TRAP: type=e (#pf Page fault) > rp=fffffe800098e730 addr=b8 occurred in module "unix" due to a NULL > pointer dereference > > hsmbully: #pf Page fault > Bad kernel fault at addr=0xb8 > pid=788, pc=0xfffffffffb836c8b, sp=0xfffffe800098e828, eflags=0x10246 > cr0: 80050033 cr4: 6f0 > cr2: b8 cr3: 11dc25000 cr8: c > rdi: b8 rsi: 0 rdx: > ffffffff8f3d8140 > rcx: fffffe800098e838 r8: ffffffff8f4e3f40 r9: > ffffffff8f54a240 > rax: 0 rbx: 0 rbp: > fffffe800098e850 > r10: fffffe800098ec78 r11: ffffffff8f4e3f40 > r12: b8 > r13: 4 r14: 4 r15: > ffffffff8a2d8000 > fsb: ffffffff80000000 gsb: ffffffff89d66800 > ds: 43 > es: 43 fs: 0 gs: > 1c3 > trp: e err: 2 rip: > fffffffffb836c8b > cs: 28 rfl: 10246 rsp: > fffffe800098e828 > ss: 30 > > fffffe800098e640 unix:die+da () > fffffe800098e720 unix:trap+5e6 () > fffffe800098e730 unix:_cmntrap+140 () > fffffe800098e850 unix:mutex_enter+b () > fffffe800098e8c0 mca:mca_setpass+d3 () > fffffe800098eb40 mca:set_pin+16e () > fffffe800098eba0 kcf:common_submit_request+1842 () > fffffe800098ebf0 kcf:process_req_hwp+cf () > fffffe800098ec30 kcf:kcf_submit_request+2c7 () > fffffe800098ed70 crypto:set_pin+26a () > fffffe800098ed80 crypto:crypto_ioctl+59 () > fffffe800098ed90 genunix:cdev_ioctl+1d () > fffffe800098edb0 specfs:spec_ioctl+50 () > fffffe800098ede0 genunix:fop_ioctl+25 () > fffffe800098eec0 genunix:ioctl+ac () > fffffe800098ef10 unix:brand_sys_syscall32+1a3 () > -- cut -- These are calls inside the PKCS #11 implementation, right? You --cut-- so I cannot be sure, but these labels are not mine. The Initiation Test surely is a devious one, trying to bypass loging in and such. I am getting the impression that we bypassed a thing that is not welcomed by this PKCS #11 implementation. This is not new to me, by the way (except for the boldness of actually crashing). PKCS #11 implementations rarely live up to spec. I'd hoped that HSM's (from Sun) would be better. Could I have access to this machine, and try myself? -Rick From jakob at kirei.se Tue Aug 18 08:31:06 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 18 Aug 2009 10:31:06 +0200 Subject: [Opendnssec-develop] Re: hsmbully considered harmful? In-Reply-To: <20090818081427.GA14761@phantom.vanrein.org> References: <20090818081427.GA14761@phantom.vanrein.org> Message-ID: On 18 aug 2009, at 10.14, Rick van Rein wrote: > That's as good as saying "don't use this tool". If there is any > problem > we should specify in detail what it is, rather than use subjective > scary > terms. of course. > Has the speedtester been designed as an exhaustive PKCS #11 test? no, it has been designed to test the parts of PKCS#11 that OpenDNSSEC use currently. > If so, we have duplicate code and one can go. If not, then there > is an added value for hsmbully. there is definately value for hsmbully. however, if a HSM doesn't work with hsmbully doesn't mean it doesn't work with OpenDNSSEC. for OpenDNSSEC, the hsmutil code might be better. > If an HSM cracks on any PKCS #11 call, it's a bad implementation, > it's as simple as that. I know it's human nature, and often correct, > to blame the new code, but really, this sounds to me like a broken > HSM. the sca6000 is broken as you should never be able to crash a machine from userland. still, it is a very widespread and well known HSM. > I make no bypass calls to anything that is not PKCS #11, after all. > People should be warned about those instead of about a tool testing > it? We've all weard the joke; Hey Doc, it hurts when I do this. and the doctor says; Then don't do that! having said that, we should of course report this bug to Sun so it can be fixed. > These are calls inside the PKCS #11 implementation, right? You -- > cut-- so > I cannot be sure, but these labels are not mine. ack. > The Initiation Test surely is a devious one, trying to bypass loging > in > and such. I am getting the impression that we bypassed a thing that > is not > welcomed by this PKCS #11 implementation. probably. > This is not new to me, by the way (except for the boldness of actually > crashing). PKCS #11 implementations rarely live up to spec. I'd > hoped > that HSM's (from Sun) would be better. > > Could I have access to this machine, and try myself? the problem is that when it crashes it reboots, so I'd rather not continue testing on this machine - it is the main development machine for the project. I think we should let Sun debug this for us. jakob From rick at openfortress.nl Tue Aug 18 09:13:52 2009 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 18 Aug 2009 09:13:52 +0000 Subject: [Opendnssec-develop] Re: hsmbully considered harmful? In-Reply-To: References: <20090818081427.GA14761@phantom.vanrein.org> Message-ID: <20090818091352.GE14761@phantom.vanrein.org> Hi, > We've all weard the joke; Hey Doc, it hurts when I do this. and the > doctor says; Then don't do that! Of course. But the idea of the initiation test is to ensure security, which implies running tests out of the ordinary. It's easy of course to make this an optional test and add a note about it in the man page. It sounds like a topic for this afternoon's phone meeting. > having said that, we should of course report this bug to Sun so it can > be fixed. Absolutely. Will you talk to them, or shall I? I don't own their HSM, so it might be a bit weird if I'd do it. Just pass on the code of hsmbully to them, I'd propose. > the problem is that when it crashes it reboots, so I'd rather not > continue testing on this machine - it is the main development machine > for the project. I think we should let Sun debug this for us. Uck -- that's bad. Understood, let Sun worry about it. -Rick From Antoin.Verschuren at sidn.nl Tue Aug 18 10:46:10 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Tue, 18 Aug 2009 12:46:10 +0200 Subject: [Opendnssec-develop] Policy configuration checker References: <4A816B60.5050807@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC3C@EXCHANGE.office.nic.se> <4A816F21.3080100@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC47@EXCHANGE.office.nic.se> Message-ID: <850A39016FA57A4887C0AA3C8085F9494DCE54@KAEVS1.SIDN.local> Do you mean to say here that a zone with very static data never needs to be resigned, like f.e. a key rollover ? I think a static zone needs regular resigning as well, and there are simply 3 situations: -Zone changes occur faster than resigning, and faster than publishing -Zone changes occur faster than resigning, but slower than publishing -Resigning occurs faster than zone changes There are situations where changes to a zone are accepted, but not resigned because it's not publishing time yet. I think that's the parameter to play with. Signing only needs to be done when it's publishing time, or when a rollover is sceduled. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/ -----Oorspronkelijk bericht----- Van: opendnssec-develop-bounces at lists.opendnssec.org namens Rickard Bondesson Verzonden: di 2009-08-11 15:33 Aan: Matthijs Mekking CC: Opendnssec-develop at lists.opendnssec.org; Alexd at nominet.org.uk Onderwerp: Re: [Opendnssec-develop] Policy configuration checker -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > But why waste resign resources if you are not going to output > it anyway? > In this example, you can save 23 times resigning that will be > unnoticed. > > Matthijs But the signer should not do anything if the old signed file has the same soa as the unsigned file (and you have keep). Thus not wasting so much cpu. if (soa_serial_type == keep && signed_zone_soa == unsigned_zone_soa) { break_out_and_sleep_for_5_min(); } do_resign(); // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoFzGuCjgaNTdVjaAQhRsAf+J2kZuAvfReoYjz2TpVq5t+TTFGpQCZmh I67WkvWYvjK293i3uX6TXY/VuuJKTKeH9fjthT8LItPMw3h4aUOoNU9NDj7vLitC IaNueOq+3GqIAIF2Uvs9JpL0QlRVo5hNcwQwTWNleLbFhy+gvVvyGr1A3/1THDnm +a5dn9Cg2mjJbVKYIuEK0cEuFKA5qpTVnErdpdQwc3LQ7rBIkh8vjBQgKZe+PuGy 7UWA6zkVOdpgCJWLoZIDT0rccddje3ueZycOA+U9+kMxlaUePY5ESYQzo4wQ1qni 1so+V27AuL1TUCnMwSidbtBCJXQ7RhMIVyUVPiLmBdntmv8DCMwfbA== =Kl6q -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bondesson at iis.se Tue Aug 18 11:10:51 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 18 Aug 2009 13:10:51 +0200 Subject: [Opendnssec-develop] Policy configuration checker In-Reply-To: <850A39016FA57A4887C0AA3C8085F9494DCE54@KAEVS1.SIDN.local> References: <4A816B60.5050807@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC3C@EXCHANGE.office.nic.se> <4A816F21.3080100@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC47@EXCHANGE.office.nic.se> <850A39016FA57A4887C0AA3C8085F9494DCE54@KAEVS1.SIDN.local> Message-ID: <69830D4127201D4EBD146B9041199718F76529@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Do you mean to say here that a zone with very static data > never needs to be resigned, like f.e. a key rollover ? > I think a static zone needs regular resigning as well, and > there are simply 3 situations: > -Zone changes occur faster than resigning, and faster than > publishing -Zone changes occur faster than resigning, but > slower than publishing -Resigning occurs faster than zone changes > > There are situations where changes to a zone are accepted, > but not resigned because it's not publishing time yet. > I think that's the parameter to play with. Signing only needs > to be done when it's publishing time, or when a rollover is sceduled. > > Antoin Verschuren What I mean is that a zone should not be published if we have not received a new serial (since the last signing) when we are in the "SOA keep"-mode. Refreshed signatures may be created but not published in this case. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoqMO+CjgaNTdVjaAQjTPwf/el/0PpZE7+6ILlUjB591oB6Yo9Sibi7n XL9WWmzGWx78Dy0z4AQU0BBrOuOvKBCW145QMtq6/r0GSIpD3lYnUsJAV0Nm7xwi g0sR6xhIM1CfmtLAKrC9EuXIHr++Wf/scH6OrZr941mJ1bVLU4srVRVvr+1Ifgyi FJw1xXXkwYszfRTYjQQ0IX29xAD7HXK1DUMm/fhW1MlxLWA4D+a7b6zuxFv9B7Lj R4oIPlUoNfqKmwRu6+Kh+L2k7ETqMD2xNKuigi1Km60pO48VEhdeCXg/g5bO332+ gairTaNvGT1D9HBf85Aq4PBpJttLAve2Hg2Ce1OZeA8iU8EsBsYmOA== =Z3dY -----END PGP SIGNATURE----- From roy at nominet.org.uk Tue Aug 18 11:23:09 2009 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 18 Aug 2009 13:23:09 +0200 Subject: [Opendnssec-develop] Policy configuration checker In-Reply-To: <69830D4127201D4EBD146B9041199718F76529@EXCHANGE.office.nic.se> References: <4A816B60.5050807@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC3C@EXCHANGE.office.nic.se> <4A816F21.3080100@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC47@EXCHANGE.office.nic.se> <850A39016FA57A4887C0AA3C8085F9494DCE54@KAEVS1.SIDN.local> <69830D4127201D4EBD146B9041199718F76529@EXCHANGE.office.nic.se> Message-ID: Rickard Bondesson wrote on 08/18/2009 01:10:51 PM: > > Do you mean to say here that a zone with very static data > > never needs to be resigned, like f.e. a key rollover ? > > I think a static zone needs regular resigning as well, and > > there are simply 3 situations: > > -Zone changes occur faster than resigning, and faster than > > publishing -Zone changes occur faster than resigning, but > > slower than publishing -Resigning occurs faster than zone changes > > > > There are situations where changes to a zone are accepted, > > but not resigned because it's not publishing time yet. > > I think that's the parameter to play with. Signing only needs > > to be done when it's publishing time, or when a rollover is sceduled. > > > > Antoin Verschuren > > What I mean is that a zone should not be published if we have not > received a new serial (since the last signing) when we are in the > "SOA keep"-mode. Refreshed signatures may be created but not > published in this case. The SOA serial number has one purpose, and one purpose only... to indicate to secondary (or slave) servers that a newer version of the zone is available. That means it is only of value if your primary to secondary replication mechanism is using AXFR or IXFR. That might not always be the case. Several implementations exist where the source of data is a database, or where the replication of data between servers occur via filetransfer. So far the theory. In practise, I would not require a re-sign to be a re-publish. Note that re-publish might be far more costly than a re-sign, if you have to pay secondary services for transit. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bondesson at iis.se Tue Aug 18 11:41:19 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 18 Aug 2009 13:41:19 +0200 Subject: [Opendnssec-develop] Policy configuration checker In-Reply-To: References: <4A816B60.5050807@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC3C@EXCHANGE.office.nic.se><4A816F21.3080100@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC47@EXCHANGE.office.nic.se><850A39016FA57A4887C0AA3C8085F9494DCE54@KAEVS1.SIDN.local> <69830D4127201D4EBD146B9041199718F76529@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B9041199718F76533@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > In practise, I would not require a re-sign to be a > re-publish. Note that re-publish might be far more costly > than a re-sign, if you have to pay secondary services for transit. > > Roy > Do I say that? ... Re-sign will not require re-publish. Re-publishing of the signed zone will only happen when the unsigned zone has been assigned a new SOA serial. E.g. the unsigned zone will be updated every second hour with new content and SOA serial. The signer continuously run, but will only be able to re-publish the zone every second hour, because we are in the "SOA serial keep"-mode. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSoqTX+CjgaNTdVjaAQgokgf/UtqtueXITSyXYB43kJPBML//pt2TJsZg 64QkY9NH6guamhEbZyX44OuyrpZUJ8jzKuUc5ZJss9bflXkMqX+XGOhQ06xYxMqd MO1TKvJ1zt0Rlt2utZvbeR7LdWOMrg6vUWBvzRPVjzr5xRu227hP2WgtAQ3JgetR ENaEe+EIALB1WpLCC64+aRKID4RPjH97yAyrVSg2bVDPLh1PNzSTv1ztJGGPcFER DciOsV4w9vWGdrKTkHFe2hJ7iaoSa0bo1spNiI3txZpAzmZvdCQKb0F1Jpj+9YNJ B3Yf0MrtkGiheqmeM9xuY08XChnLjZSfK4ptG3pmqClvJhjY++gjPg== =yDtV -----END PGP SIGNATURE----- From roy at nominet.org.uk Tue Aug 18 11:54:03 2009 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 18 Aug 2009 13:54:03 +0200 Subject: [Opendnssec-develop] Policy configuration checker In-Reply-To: <69830D4127201D4EBD146B9041199718F76533@EXCHANGE.office.nic.se> References: <4A816B60.5050807@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC3C@EXCHANGE.office.nic.se><4A816F21.3080100@nlnetlabs.nl> <69830D4127201D4EBD146B9041199718E1EC47@EXCHANGE.office.nic.se><850A39016FA57A4887C0AA3C8085F9494DCE54@KAEVS1.SIDN.local> <69830D4127201D4EBD146B9041199718F76529@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B9041199718F76533@EXCHANGE.office.nic.se> Message-ID: "Rickard Bondesson" wrote on 08/18/2009 01:41:19 PM: > > In practise, I would not require a re-sign to be a > > re-publish. Note that re-publish might be far more costly > > than a re-sign, if you have to pay secondary services for transit. > > > > Roy > > > > Do I say that? ... I was not arguing for or against any statement made, but wanted to speak my mind about intent. But to answer your question: No. I think we are in violent agreement. You said "a zone should not be published if we have not received a new serial". Note that a zone is either published or not. The soa serial number is interesting for _secondary_ servers, not primary servers. I just wanted to make sure folks understand the premise of the serial number in an SOA. > Re-sign will not require re-publish. Yes. > Re-publishing of the signed > zone will only happen when the unsigned zone has been assigned a new > SOA serial. > > E.g. the unsigned zone will be updated every second hour with new > content and SOA serial. The signer continuously run, but will only > be able to re-publish the zone every second hour, because we are in > the "SOA serial keep"-mode. Exactly. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Tue Aug 18 14:44:15 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 18 Aug 2009 15:44:15 +0100 Subject: [Opendnssec-develop] getting information from the system In-Reply-To: References: <4A7AE6E0.2010501@NLnetLabs.nl> <195C9A16-891B-420D-AC28-55DD87FF6572@NLnetLabs.nl> Message-ID: The discussion under this subject threw up a number of possible requirements; some of which were not in pivotal (my fault). I've added the following into the icebox: Specify rollover by date. Infinite key lifetime. Turn off automatic rollover. With estimates for how long each will take me (assuming it doesn't become much more complicated than the simple description that I've given each). Does anyone have a strong opinion on whether they are more important than the currently scheduled work, or where in the list of priorities they should sit? If not I'll slot them in just below "Running with manual key generation". Sion From rick at openfortress.nl Wed Aug 19 07:25:30 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 19 Aug 2009 07:25:30 +0000 Subject: [Opendnssec-develop] Sharing PIN through POSIX message queues Message-ID: <20090819072530.GA14314@phantom.vanrein.org> Hello, During the phone conversation yesterday I proposed to use IPC for sharing PIN codes, because it has a special security potential: it can verify the process ID of the party requesting the PIN. I made a small test program, which comes attached. Basically, this is a PIN server (make start / make stop) with a client query that can be run as often as you like (make query). The client prints what getpid() returns, and the server prints the PID from which the request comes in, to make it testable. This functionality is part of the POSIX standard, as far as I can tell. The code contains a few pointers on making more secure code. I won't mind developing that, but first I'd like you to have a look at this. Don't ask me why SSH doesn't use this, it makes no sense to me to use a file socket for this sort of thing. Cheers, -Rick -------------- next part -------------- A non-text attachment was scrubbed... Name: msgqueue-pin.tgz Type: application/x-gtar Size: 1810 bytes Desc: Demonstration code for PIN sharing URL: From rickard.bondesson at iis.se Wed Aug 19 11:03:02 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 19 Aug 2009 13:03:02 +0200 Subject: [Opendnssec-develop] Audit key rollovers Message-ID: <69830D4127201D4EBD146B9041199718F76601@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I have a suggestion for some additional requirements for the auditor. Do you have any additional requirements? *********************** 3.6 Key rollover Checks For each signed zone chosen for verification, the KA should: 1. Keep a record of what keys have been used in the zone, from the KA point-of-view. a. When it was pre-published (added to the zone). b. When it was made active. c. When it was retired d. When it was made dead (removed from the zone). e. The information about the key may be dropped once the key is dead. 2. Give a warning if the KSK is active longer than the period specified in the KASP. 3. Give a warning if the ZSK is active longer than the period specified in the KASP. 4. Give a warning if the number of pre-published KSK:s are less than the number of emergency KSK:s specified in the KASP. 5. Give a warning if the number of pre-published ZSK:s are less than the number of emergency ZSK:s specified in the KASP. *********************** A comment: There are not enough of emergency keys right after an emergancy rollover, since that rollover made one of those active. So should the KA still give a warning about this? A new key will be added on the next run by keygend and communicated. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSovb5uCjgaNTdVjaAQijxgf/dUMHyxmlbX/vWiuqBL/IFG3KHH/6u4xC wvt764o3gZnnqXaCThLlBpmRhJq7zUdSmb99Q4whsSAwaZqHgCjocHxCdqhoGmSD KdgUTllzXZEI7QjCUGlceVIpdAZNyyPXd1gGWwXargNRFsSqivBQlC7J1A8OOGEY iO2ZDZESveb6DwSNxRD4I+rtk+kzF7XmIJgSIO6m2kkqaCUsqFiAd4Wf5ko4dd52 z259iYnKGtZ+16z20Dt4jjYSdlN3CIiPpUrbnp75qyr+GbLhfUufjPkjz5dfEVvT tEHWy131/FgiY5KkxgNiYhHIoymLx3pf2Sd+uU3R4vhKmeY56Ocs4g== =lvpn -----END PGP SIGNATURE----- From sion at nominet.org.uk Wed Aug 19 12:33:26 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 19 Aug 2009 13:33:26 +0100 Subject: [Opendnssec-develop] Audit key rollovers In-Reply-To: <69830D4127201D4EBD146B9041199718F76601@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718F76601@EXCHANGE.office.nic.se> Message-ID: > 3.6 Key rollover Checks > > For each signed zone chosen for verification, the KA should: > > 1. Keep a record of what keys have been used in the zone, from > the KA point-of-view. > a. When it was pre-published (added to the zone). > b. When it was made active. > c. When it was retired > d. When it was made dead (removed from the zone). > e. The information about the key may be dropped once the > key is dead. > 2. Give a warning if the KSK is active longer than the period > specified in the KASP. > 3. Give a warning if the ZSK is active longer than the period > specified in the KASP. > 4. Give a warning if the number of pre-published KSK:s are less > than the number of emergency KSK:s specified in the KASP. > 5. Give a warning if the number of pre-published ZSK:s are less > than the number of emergency ZSK:s specified in the KASP. > > *********************** > > A comment: > There are not enough of emergency keys right after an emergancy > rollover, since that rollover made one of those active. So should > the KA still give a warning about this? A new key will be added on > the next run by keygend and communicated. another comment: The timings for 2 and 3 will need to be "lifetime from kasp + run interval of communicated" to avoid false warnings. It could give a warning if the number of emergency keys is 0, this might indicate that emergency keys should be increased in the policy? Sion From Stephen.Morris at nominet.org.uk Wed Aug 19 16:25:20 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Wed, 19 Aug 2009 17:25:20 +0100 Subject: [Opendnssec-develop] Audit key rollovers In-Reply-To: References: <69830D4127201D4EBD146B9041199718F76601@EXCHANGE.office.nic.se> Message-ID: "Rickard Bondesson" wrote on 19/08/2009 13:33:26: > > A comment: > > There are not enough of emergency keys right after an emergancy > > rollover, since that rollover made one of those active. So should > > the KA still give a warning about this? A new key will be added on > > the next run by keygend and communicated. It should give a warning. The auditor is checking the assertion "number of emergency keys in file == number of emergency keys in policy" and this condition violates it. I think this is one of those cases where knowledge of what has happened is sufficient to allow a user to disregard the warning. We expect emergency roll-overs to be rare and (presumably) the documentation will include a description of what to do should one be required. That documentation could include a note to the effect that a warning about insufficient emergency keys will be output until new keys have been in the zone file for long enough. And, quite apart from anything else, it simplifies the auditor. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bondesson at iis.se Thu Aug 20 14:12:28 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 20 Aug 2009 16:12:28 +0200 Subject: [Opendnssec-develop] Meeting in Utrecht Message-ID: <69830D4127201D4EBD146B9041199718F7671E@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Date: 27th August Location: SURFnet's office, Utrecht Time: 0930-1800 CEST Please add suggestions on topics to the agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2009-08-27 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSo1ZzOCjgaNTdVjaAQhJUAf/cfeY6KbhZMYLYYIUz8xe7vi31ttlYLvJ Iru9piMituJr8guZZj4NeqyHm2ibC6uv0Tw9ofUsUKw22gDQmSgYG+a9pgwlpcLn FmYYxyRB4PnOh+QTJyUI2qSlYxLbkVRNBREmEyoj+A0OND6RtyS2YXwm6nQyDnQa xxfnDZ2TKMWb7NnOqrzAKWg7kkzaDmR1cpY1ltCgl4TRbWs6H0tf+9230ALECBDW NGTx6Nje/yAR8STOCuox9oK6B0AjU4okMxtper0nypsx2EnX62fvsqp5/hKb1fNh cBcU2IWttmsMLxikRa/ftm88Wr1LozRbo/vRMWLeWUqormsG9mD6iQ== =Fe/D -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Aug 20 14:13:31 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 20 Aug 2009 14:13:31 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #16: Missing include information for sqlite3 when building enforcer Message-ID: <058.692497fc0ecddfa383f49971b5fc9e06@kirei.se> #16: Missing include information for sqlite3 when building enforcer ---------------------------------+------------------------------------------ Reporter: johani at autonomica.se | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: | Keywords: ---------------------------------+------------------------------------------ I had to add @SQLITE3_INCLUDES@ to enforcer/*/Makefile.am to get it to compile, but I suspect the correct fix shouldn't be sqlite3-specific. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Thu Aug 20 14:34:09 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 20 Aug 2009 15:34:09 +0100 Subject: [Opendnssec-develop] New column Message-ID: Hi there, I've got another change to the enforcer database (svn r1665), a migration script is provided so run: sqlite3 < enforcer/utils/migrate_090820_1.sqlite3 This allows for the "ksmutil import key" function, which can add a key into the ksm database and attach it to zones... enjoy. Note that there are issues if you add an active key when there is one already; it works but the rolling of the keys is not quite right. This will be fixed when I work on pivotal story 1060474 "Overlapping KSKs". Sion From roland.vanrijswijk at surfnet.nl Thu Aug 20 14:48:30 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 20 Aug 2009 16:48:30 +0200 Subject: [Opendnssec-develop] Meeting in Utrecht In-Reply-To: <69830D4127201D4EBD146B9041199718F7671E@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718F7671E@EXCHANGE.office.nic.se> Message-ID: <4A8D623E.9030206@surfnet.nl> Hi Rickard, Can you please scrap the company name from my second point for the agenda? Cheers, Roland Rickard Bondesson wrote: > Hi > > Date: 27th August > Location: SURFnet's office, Utrecht > Time: 0930-1800 CEST > > Please add suggestions on topics to the agenda: > > http://trac.opendnssec.org/wiki/Meetings/Agenda/2009-08-27 > > // Rickard ------------------------------------------------------------------------ _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From roland.vanrijswijk at surfnet.nl Thu Aug 20 14:51:07 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 20 Aug 2009 16:51:07 +0200 Subject: [Opendnssec-develop] Meeting in Utrecht In-Reply-To: <4A8D623E.9030206@surfnet.nl> References: <69830D4127201D4EBD146B9041199718F7671E@EXCHANGE.office.nic.se> <4A8D623E.9030206@surfnet.nl> Message-ID: <4A8D62DB.4070907@surfnet.nl> Never mind, I've done it myself ;-) Roland van Rijswijk wrote: > Hi Rickard, > > Can you please scrap the company name from my second point for the agenda? > > Cheers, > > Roland > > Rickard Bondesson wrote: >> Hi >> >> Date: 27th August >> Location: SURFnet's office, Utrecht >> Time: 0930-1800 CEST >> >> Please add suggestions on topics to the agenda: >> >> http://trac.opendnssec.org/wiki/Meetings/Agenda/2009-08-27 >> >> // Rickard > > ------------------------------------------------------------------------ > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > > -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From owner-dnssec-trac at kirei.se Thu Aug 20 14:52:30 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 20 Aug 2009 14:52:30 -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.875ee8f3d8d80000efae6ded36ae735e@kirei.se> #16: Missing include information for sqlite3 when building enforcer ---------------------------------+------------------------------------------ Reporter: johani at autonomica.se | Owner: rb Type: defect | Status: accepted Priority: major | Component: Enforcer Version: | Resolution: Keywords: | ---------------------------------+------------------------------------------ Changes (by rb): * owner: sion => rb * status: new => accepted Comment: Did r1666 fix your problem? -- Ticket URL: OpenDNSSEC OpenDNSSEC From roland.vanrijswijk at surfnet.nl Thu Aug 20 15:05:49 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 20 Aug 2009 17:05:49 +0200 Subject: [Opendnssec-develop] How to arrive at SURFnet's offices next week Message-ID: <4A8D664D.6050307@surfnet.nl> Hi guys, Just some more information on how to get to us for next week's meeting: from Amsterdam's Schiphol airport you can take any intercity train travelling to Utrecht. There are four direct trains per hour at the following times: at the hour (:00) from platform 3 at 14min past (:14) from platform 1 or 2 (same platform) at 30min past (:30) from platform 3 at 44min past (:44) from platform 1 or 2 (same platform) Trains take about half an hour to get to Utrecht. A return ticket (2nd class) costs just under 15 euros, there are NS (Dutch railways) ticket vending machines in the arrivals hall at Schiphol airport, they accept credit cards. When you arrive in Utrecht, follow the instructions on our website (http://www.surfnet.nl/en/pages/contact.aspx) under the heading "By public transport". If you leave the railway station into the shopping centre, keep to the left of the corridor. Once you've passed three connected foodstalls called "Boterham Express", "Bram Ladage" and "Sap Express", the entrance to our office is directly to the left. Our logo is on the door, so it should be easy to find. Walk down the corridor, entrance is the first door to your right. If for some reason you can't find the entrance, give me a call. If any of you want/need to stay overnight, let me know, I can ask our reception to find you a hotel. See you all next week! Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From sion at nominet.org.uk Fri Aug 21 09:02:28 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Fri, 21 Aug 2009 10:02:28 +0100 Subject: [Opendnssec-develop] -a vs --all Message-ID: I hesitate to start this discussion as it has caused small wars in the past... We have a number of components that take command line arguments, and I think that we should be consistent in both style and meaning of flags. I wouldn't expect -v to mean verbose in one place and version in another; similarly I wouldn't expect to have to type -v in one place and --version in another. So, do we need a central list of what options we have used, and what they mean? And do we need to decide between short and long options (or decide that we want both to always work?) I'm happy with either type, so long as we are consistent. Or you can tell me that I am worrying about nothing. Sion From roy at nominet.org.uk Fri Aug 21 09:35:13 2009 From: roy at nominet.org.uk (roy at nominet.org.uk) Date: Fri, 21 Aug 2009 11:35:13 +0200 Subject: [Opendnssec-develop] -a vs --all In-Reply-To: References: Message-ID: Sion wrote on 08/21/2009 11:02:28 AM: > I hesitate to start this discussion as it has caused small wars in the > past... > > We have a number of components that take command line arguments, and I > think that we should be consistent in both style and meaning of flags. I > wouldn't expect -v to mean verbose in one place and version in another; > similarly I wouldn't expect to have to type -v in one place and --version > in another. > > So, do we need a central list of what options we have used, and what they > mean? And do we need to decide between short and long options (or decide > that we want both to always work?) > > I'm happy with either type, so long as we are consistent. Or you can tell > me that I am worrying about nothing. +1 for consistency across cmd line options for all tools. I think we do indeed need a reference on the wiki that specifies command line options. Maybe via a manual page (man/nroff style) in html on the wiki? As for choices, no prefs either way, so let me just choose something arbitrary, and go from there: -v --verbose -V --version -d --debug -h --help (shows version as well) etc. Roy From jakob at kirei.se Fri Aug 21 13:24:22 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 21 Aug 2009 15:24:22 +0200 Subject: [Opendnssec-develop] Re: Sharing PIN through POSIX message queues In-Reply-To: <20090819072530.GA14314@phantom.vanrein.org> References: <20090819072530.GA14314@phantom.vanrein.org> Message-ID: <14270671-2612-436E-B123-120A83E32433@kirei.se> On 19 aug 2009, at 09.25, Rick van Rein wrote: > This functionality is part of the POSIX standard, as far as I can > tell. do you have any information on what operating systems has implemented this API? jakob From Stephen.Morris at nominet.org.uk Fri Aug 21 14:49:18 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Fri, 21 Aug 2009 15:49:18 +0100 Subject: [Opendnssec-develop] Unified Control Program (was -a vs --all) In-Reply-To: References: Message-ID: sion at nominet.org.uk wrote on 21/08/2009 10:02:28: > I hesitate to start this discussion as it has caused small wars in the > past... > > We have a number of components that take command line arguments, and I > think that we should be consistent in both style and meaning of flags. I > wouldn't expect -v to mean verbose in one place and version in another; > similarly I wouldn't expect to have to type -v in one place and --version > in another. > > So, do we need a central list of what options we have used, and what they > mean? And do we need to decide between short and long options (or decide > that we want both to always work?) > > I'm happy with either type, so long as we are consistent. Or you can tell > me that I am worrying about nothing. No, you are not worrying about nothing. This is something I have been considering in drawing up requirements for a unified control program. I think consistency is very important - as well as making the software easier to use, it makes it look more professional. (In particular, it makes it look as though the authors have talked to one another :-) I haven't yet entered the story for the control program as I wanted to get some idea of what it should do first. My initial thoughts are listed below. Comments? Stephen === First Draft of Uniform Control Program Requirements === Integrated Command Language Interpreter Background ========== A tool (or set of tools) to effectively manage OpenDNSSEC requires the following capabilities: * Able to display information about the system (e.g. display the zones being signed and the signing schedule) * Able to control the system (e.g. start and stop the system) * Able to configure the system (e.g. able to set signing policy parameters) At present, the alpha version of OpenDNSSEC has a set of command-line programs (ksmutil, signer_engine_cli, etc.), each providing part of this functionality. To improve usability, a single, integrated control program is required. For simplicity, and to ensure that it works on as many systems as possible with relatively little development effort (as well as allowing it to be integrated into users' scripts), the system should be command-line based. The document describes the functionality of such an application (called, for the purposes of this document, "odctl" [OpenDNSSEC Control]). Scope ===== As noted above, a management program requires the ability to configure the system. In the current version of OpenDNSSEC, configuration options are held in three files: kasp.xml: this describes signing policies. At present, it must be hand-edited. zonelist.xml: list of zones to be signed together with the policies associated with the zones and the location of the signed and unsigned files. This is produced by the user (or user's systems); when changed, it is imported into the system via the "update" command. Note that the zonelist.xml is the master list of zones being signed by the system. In environments where zones are frequently added and removed, it is expected that zonelist file will be maintained by the user's own systems. conf.xml: contains parameters for the daemons (how they run, where they log, etc.) At present, it must be hand-edited. For the first release, it is proposed that odctl does not include any ability to configure the system. This is for several reasons: a) It is possible to edit the configuration files by hand. For small files, this is feasible, especially as it is unlikely that the configurations will be frequently changed. Larger files are more difficult to edit and a tool would be useful. However, this entails addition work and effort, whilst the first production version of the software is being developed, is better targeted elsewhere. c) It is not clear that a CLI is the best way to edit the structured data in the configuration files - a GUI may be a better option, although this will entail much more work. b) The configuration files are still being altered as development proceeds. It will be better to wait until the format and contents have settled down. CLI Basics ========== It is suggested that any form of CLI be available in both single-command mode and subsystem mode. In subsystem mode, running the CLI enters a command subsystem which prompts the user for commands, e.g. % odctl [command switches] odctl> list odctl> : odctl> quit % Single command mode is of the form: % odctl [command switches] list ... which will invoke the odctl program, run the command (in this case, "addzone") and exit odctl, returning control to the shell prompt. In practice, odctl will be a thin layer over functions in the OpenDNSSEC libraries; there should be little (if anything) that odctl does that cannot be done by calling one of the library functions (this will facilitate the creation of a GUI interface). Functions ========= a) Starting odctl ----------------- The control program is started by the command: % odctl [-c ] [command] where: -c Specifies the name of the directory holding the conf.xml file. If not specified, the default installation directory is assumed. [command] Optional command. If specified, the command is executed and the program terminates. Otherwise it prompts at the command terminal. b) Commands Related to odctl Itself ----------------------------------- odctl> quit Exits the program. odctl> help Lists a summary of the commands. Help for each command is obtained by issuing the command with the "-h" switch, e.g. "addzone -h" gives help for the "addzone" command. odctl> source Reads and executes odctl commands from the given file. (The commands should be echoed to stdout before execution.) c) Commands Related to The Whole System --------------------------------------- c.1) Information Some command to instantly see the current status of the system is needed - we should not require the user to do a "ps" and search for the various daemons. odctl> status [-s] [-k] ... Prints out the status of the system. If no switches are specified, all are assumed. The listing comprises various sections: -r: Lists the key repositories in the system -s: Displays status of the running system. Outputs something along the lines of: Signer: Running Enforcer: Running Auditor: Running : : -k: Displays the status of keys in the system. [TBD - more details from the ksmutil listing] -q: Displays the signer's task queue -z: Lists all zones known to the system. c.2) Starting and Stopping the System Given that some systems use the "init" style to start daemon processes and others (such as OS/X and Solaris) use operating system-specific tools, a common interface simplifies operation. Possible commands are: odctl> start [-p hsm_password] [component] Starts the system. If the HSM password is not supplied, prompts the user. The optional "component" parameter (something like "signer", "auditor" etc.) allows single components to be started in isolation. odctl> stop [component] Stops all the daemon processes in a controlled fashion but, if there is no response from a process, executes a "kill -9" on it. The optional "component" parameter allows single components to be halted. odctl> restart [component] Executes a "stop" and, when everything has halted, executes a "start". The optional "component" parameter allows single components to be restarted. (Using "restart" - rather than "stop" and "start" means that the password does not have to be re-entered.) d) Component-Related Commands ----------------------------- As the system comprises different components, each with its own functions, inevitably each component will require a set of component-specific commands. The CLI includes functions currently handled by separate programs, but ensuring syntax and semantic consistency. d.1) Enforcer Commands This is basically the set of commands available via ksmutil and sets up the policy database: odctl> dbinit [-f] The equivalent of the "setup" command. I suggest "dbinit" as that implies initialization and is more associated with wiping the current contents of something than the command "setup". The command should prompt for confirmation before taking the action, unless "-f" (force) is given. It both wipes the current data from the database and initializes the tables, i.e. it does a "DROP TABLE IF EXISTS..." before executing a "CREATE TABLE" command. odctl> update Updates the database from the configuration directory. (This should be called by the users' systems whenever zonelist.xml is altered.) odctl> dbexport [-o file] Export all policies [or named policy] to xml (in kasp.xml format). If the output file is not specified, the XML is listed to stdout. odctl> roll -z [-t ksk | -t zsk] odctl> roll -p [-t ksk | -t zsk] Rolls the keys on a zone (with "roll -z") or on a policy (with "roll -p"). The "-t ksk" or "-t zsk" switches specify the type of key to roll. Both are rolled if nothing is specified. After running the rollover the communicator will be woken up so that the signer can be sent the new information. If an attempt is made to roll a zone for which keys are shared, a warning will be output that all zones on the policy should be rolled and the operation is abandoned. A backup of the sqlite DB file is made (if appropriate). odctl> bckdone [-d date] [repository] Sets the most recent backup date for keys in the repository (all repositories if no repository is listed) for which no backup has been performed to the specified date, or to the current date if no date is specified. odctl> purge [zone] Removes dead keys from the database for the specified zone (all zones if nothing given). d.2) Signer Commands These are the functions available from the signer_engine_cli. Note that the "queue" command has been subsumed into odctl "list" command. odctl> sign [zone] Schedules the zone (all zones if no parameter given) for immediate signing. d.3) HSM Commands All HSM access is done by the components through library functions. Initializing the HSM and other maintenance tasks will be done with HSM-specific control programs. d.4) Auditor Commands --------------------- odctl> audit [zone] Sets the auditing level for a zone (or all zones if no zone is given). ranges between 0 (disabling the auditor) and 100 (fully-enabling it). [To be completed] List of Command Flags ===================== -d: Date -f: "Force" -h: Help -k: Key -o: Output file -p: Policy -q: Queue -r: Repository -s: Status -t: Key type -z: Zone -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Fri Aug 21 16:02:48 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 21 Aug 2009 16:02:48 +0000 Subject: [Opendnssec-develop] Re: Sharing PIN through POSIX message queues In-Reply-To: <14270671-2612-436E-B123-120A83E32433@kirei.se> References: <20090819072530.GA14314@phantom.vanrein.org> <14270671-2612-436E-B123-120A83E32433@kirei.se> Message-ID: <20090821160248.GA31080@phantom.vanrein.org> Hi Jakob/others, > > [IPC is part of POSIX] > do you have any information on what operating systems has implemented > this API? AFAIK it is commonly implemented. It was introduced with SysV, so a long time ago. I've done a quick look for pages mentioning msgget in relation to various OS's and found them (usually in man pages) for all that I tried: - Linux - FreeBSD - OpenBSD - NetBSD - SunOS / Solaris / OpenSolaris - HP-UX - Cygwin - AIX The calls are quite common AFAIK, except that UNIX programmers don't quickly think of them. If you have any doubts, we can always test my little app on various platforms, but it looks to me like it'll work everywhere. Cheers, -Rick From jakob at kirei.se Sat Aug 22 10:48:34 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Sat, 22 Aug 2009 12:48:34 +0200 Subject: [Opendnssec-develop] Re: Sharing PIN through POSIX message queues In-Reply-To: <20090821160248.GA31080@phantom.vanrein.org> References: <20090819072530.GA14314@phantom.vanrein.org> <14270671-2612-436E-B123-120A83E32433@kirei.se> <20090821160248.GA31080@phantom.vanrein.org> Message-ID: <52FB8FDB-08BB-4DBF-93FC-D6D4B224AEE4@kirei.se> POSIX message queues are not the save as SysV message queues, but I assume you know that (msgget() and friends are used in SySV, where mq_* are used in POSIX). having said that, I propose that we use standard UNIX sockets for our IPC. sockets are, as you wrote as well, more well known; so is how to use them and how to protect them for unauthorized use. - simple file system protection is used for access control, so the administrator can easily see what user(s) may access a socket. - the IPC (socket) identifier is a standard UNIX path,instead of a pre- allocated numerical queue ID, thus more easy to customize. I'm not saying SysV or POSIX message queues would not work (your example shows they would), but given the arguments above I say we use sockets. thank you for bringing up an alternative and writing example code - it was most useful. jakob From jakob at kirei.se Mon Aug 24 06:37:55 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 24 Aug 2009 08:37:55 +0200 Subject: [Opendnssec-develop] Auditor daemon In-Reply-To: References: Message-ID: On 13 aug 2009, at 14.42, alexd at nominet.org.uk wrote: > I'm just looking at daemonizing the auditor. Then I realised I > wasn't quite sure what was meant to happen... > > How often is the auditor meant to run in daemon form? Is this > configurable? > > What should happen if the auditor daemon encounters errors in the > signed zone? Is this configurable? currently we have the following directories for the file adapter: /var/opendnssec/ (i.e. @localstatedir@/opendnssec) unsigned/ the unsigned zone signed/ the signed zone would it perhaps make sense to add an audited/ directory and let the daemonized auditor move files from signed/ to audited/ when a zone has bee audited? this would perhaps change how we call the auditor from the signed engine as well, just making in a signer configuration tell the signer engine to run the signer explicitly on the file in signed/ when the zone has been signed? (making the auditor run explicitly rather than in batch) jakob From jakob at kirei.se Mon Aug 24 06:40:50 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 24 Aug 2009 08:40:50 +0200 Subject: [Opendnssec-develop] -a vs --all In-Reply-To: References: Message-ID: <1E12EF3E-02D6-4552-AC66-BE29E3ACC30B@kirei.se> On 21 aug 2009, at 11.35, roy at nominet.org.uk wrote: > +1 for consistency across cmd line options for all tools. I think we > do > indeed need a reference on the wiki that specifies command line > options. > Maybe via a manual page (man/nroff style) in html on the wiki? As for > choices, no prefs either way, so let me just choose something > arbitrary, > and go from there: > > -v --verbose > -V --version > -d --debug > -h --help (shows version as well) +1 a wiki page as an index to the command line tools make sense to me. jakob From jelte at NLnetLabs.nl Mon Aug 24 07:42:42 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Mon, 24 Aug 2009 09:42:42 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-user] Signer Engine? In-Reply-To: <69830D4127201D4EBD146B9041199718F76720@EXCHANGE.office.nic.se> References: <5c494b510908190242i7f91be70u1d9dc9514371286e@mail.gmail.com> <69830D4127201D4EBD146B9041199718F76720@EXCHANGE.office.nic.se> Message-ID: <4A924472.2070006@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bondesson wrote: >> Hi, > >> I'm experiencing exactly the same error on our test server >> running RHEL5. The signer engine starts only if I give option "-d". > >> Antti > > Matthijs, could you have a look at this? > just as an fyi, this error is printed on a general uncaught exception, and the exception message is printed as well, but apparently the exception message is empty here. It may be a better idea to simply re-raise the exception that is caught, so you can actually see what's happening in the full stack trace. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqSRHIACgkQ4nZCKsdOncXg6gCaA2+NFD37XT6OG7A1PcTLJqCL CYoAoL41nKPkXjlAd95yVMOpQuSBAybX =iy9F -----END PGP SIGNATURE----- From sion at nominet.org.uk Mon Aug 24 09:01:47 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 24 Aug 2009 10:01:47 +0100 Subject: [Opendnssec-develop] Rollover warnings Message-ID: Morning, I've written the code to issue warnings of impending rollovers. However we do not currently have any way of saying how far in advance we want a warning, if at all. I think that we need a tag in the kasp.xml KSK or ZSK sections, so that it can be different or turned off based on the keytype. Also, do we want to warn every time the communicator runs (until the rollover is performed) or just once? Or should this be configurable too? Sion From jakob at kirei.se Mon Aug 24 09:30:12 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 24 Aug 2009 11:30:12 +0200 Subject: [Opendnssec-develop] 1.0a3 pending bugfixes Message-ID: <734A5241-2F65-4055-936C-8633FB5E6A42@kirei.se> hi, as soon as all current bugs (see tracker) are fixed, I'm about to release 1.0a3. hopefully we can do this before thursday. jakob From patrik.wallstrom at iis.se Mon Aug 24 09:53:44 2009 From: patrik.wallstrom at iis.se (Patrik Wallstrom) Date: Mon, 24 Aug 2009 11:53:44 +0200 Subject: [Opendnssec-develop] Auditor daemon In-Reply-To: References: Message-ID: <630CFEC4-066C-4FAD-95F0-C5CC35846A88@iis.se> On Aug 24, 2009, at 8:37 AM, Jakob Schlyter wrote: > On 13 aug 2009, at 14.42, alexd at nominet.org.uk wrote: > >> I'm just looking at daemonizing the auditor. Then I realised I >> wasn't quite sure what was meant to happen... >> >> How often is the auditor meant to run in daemon form? Is this >> configurable? >> >> What should happen if the auditor daemon encounters errors in the >> signed zone? Is this configurable? > > currently we have the following directories for the file adapter: > > /var/opendnssec/ (i.e. @localstatedir@/opendnssec) > unsigned/ the unsigned zone > signed/ the signed zone > > would it perhaps make sense to add an audited/ directory and let the > daemonized auditor move files from signed/ to audited/ when a zone > has bee audited? > > this would perhaps change how we call the auditor from the signed > engine as well, just making in a signer configuration tell > the signer engine to run the signer explicitly on the file in > signed/ when the zone has been signed? (making the auditor run > explicitly rather than in batch) I think this can be a bit confusing for the user. The Audit flag is in the KASP, but the directories are configured per zone. I still believe that the Audit flag belongs to the policy though, so having those directories configured per zone is not very clear if you add or remove the Audit from the policy. I hope you follow my reasoning here - because in the Audit case the signed directory is only a temp directory, and if not auditing is done it is the final destination. Perhaps the chain always would be like this instead: unsigned -> (audit) -> signed. Then you always know the process. -------------- 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 jakob at kirei.se Mon Aug 24 09:57:37 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 24 Aug 2009 11:57:37 +0200 Subject: [Opendnssec-develop] Auditor daemon In-Reply-To: <630CFEC4-066C-4FAD-95F0-C5CC35846A88@iis.se> References: <630CFEC4-066C-4FAD-95F0-C5CC35846A88@iis.se> Message-ID: <84F8EC61-1ABC-48AA-BE63-888FC0A769FE@kirei.se> On 24 aug 2009, at 11.53, Patrik Wallstrom wrote: > Perhaps the chain always would be like this instead: unsigned -> > (audit) -> signed. Then you always know the process. I agree, but in this case the auditor never has to run as a daemon, right? jakob From rickard.bondesson at iis.se Mon Aug 24 10:08:32 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 24 Aug 2009 12:08:32 +0200 Subject: [Opendnssec-develop] Auditor daemon In-Reply-To: <84F8EC61-1ABC-48AA-BE63-888FC0A769FE@kirei.se> References: <630CFEC4-066C-4FAD-95F0-C5CC35846A88@iis.se> <84F8EC61-1ABC-48AA-BE63-888FC0A769FE@kirei.se> Message-ID: <69830D4127201D4EBD146B9041199718F768AF@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > Perhaps the chain always would be like this instead: unsigned -> > > (audit) -> signed. Then you always know the process. > > I agree, but in this case the auditor never has to run as a > daemon, right? Wasn't the idea to use the auditor in two modes? One mode where it is called by the Signer Engine to check the zone before sending it out from the system. This depends if you have in the KASP. If : unsigned -> Signer Engine -> Auditor -> signed If not : unsigned -> Signer Engine -> signed So that auditor can stop the zone distribution in this case. The other case was an auditor daemon that runs regularly and checks the zones. It can only give warnings (to syslog or whatever), but not be able to stop the zone distribution. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSpJmoOCjgaNTdVjaAQi+swf+Lgiz/4ef2YGAm7Sf6c0c2I/RVUl8jLBL XQSEMAQtik8zyv8lBMiwgUigO1RUkfTEfYu3e6XfaPqkYiscqVld2vhVReodCf8h C0UTLZuM3He/JoNE88gXBcHNYtAh6cTUwDzhOJDi6FhBxnqoE2eXeUCW/4QXakI5 n8hkUToLe/Sm7ZIJHChBoH1cZqSpda3ZvPsOU4gv1YHtM2JDmjdbWSkGwc4KXc7f XJKU3mEzC/1q+4Hk91acQJrbGOvYG8gr2fwYy6RnCZ8BU7EcFcvjMDUQiyqXBdjv qU6M7c1fMhklYLdBJjqXzASbGGBbIKp6l0uFlfbJnU4wRw4It6tEeA== =xOTs -----END PGP SIGNATURE----- From Alexd at nominet.org.uk Mon Aug 24 10:14:00 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Mon, 24 Aug 2009 11:14:00 +0100 Subject: [Opendnssec-develop] Auditor daemon In-Reply-To: <69830D4127201D4EBD146B9041199718F768AF@EXCHANGE.office.nic.se> References: <630CFEC4-066C-4FAD-95F0-C5CC35846A88@iis.se> <84F8EC61-1ABC-48AA-BE63-888FC0A769FE@kirei.se> <69830D4127201D4EBD146B9041199718F768AF@EXCHANGE.office.nic.se> Message-ID: > The other case was an auditor daemon that runs regularly and checks > the zones. It can only give warnings (to syslog or whatever), but > not be able to stop the zone distribution. This is currently implemented : kasp_auditor -d [normal config] It currently runs once an hour, as there is no configuration specified for it. It runs on the specified zones, with the specified config, and logs any issues to syslog. I thought that some basic configuration for the daemon could be useful (e.g. frequency). I could easily add this to the command line, if we didn't want to clutter up the config any more (or I could just run it once a day). I'm not sure which component is meant to start the auditor daemon? Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Morris at nominet.org.uk Mon Aug 24 10:42:35 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Mon, 24 Aug 2009 11:42:35 +0100 Subject: [Opendnssec-develop] Auditor daemon In-Reply-To: <630CFEC4-066C-4FAD-95F0-C5CC35846A88@iis.se> References: <630CFEC4-066C-4FAD-95F0-C5CC35846A88@iis.se> Message-ID: Patrik Wallstrom wrote on 24/08/2009 10:53:44: > > this would perhaps change how we call the auditor from the signed > > engine as well, just making in a signer configuration tell > > the signer engine to run the signer explicitly on the file in > > signed/ when the zone has been signed? (making the auditor run > > explicitly rather than in batch) > > I think this can be a bit confusing for the user. The Audit flag is in > the KASP, but the directories are configured per zone. I still believe > that the Audit flag belongs to the policy though, so having those > directories configured per zone is not very clear if you add or remove > the Audit from the policy. I hope you follow my reasoning here - > because in the Audit case the signed directory is only a temp > directory, and if not auditing is done it is the final destination. > > Perhaps the chain always would be like this instead: unsigned -> > (audit) -> signed. Then you always know the process. IMHO, the easiest way to handle this would be for the signer to always write the signed file to the auditor's directory and to always invoke the auditor. If the audit flag is absent, the auditor just moves the file from the auditor directory to the output directory. It (marginally) simplifies the signer and means that only the auditor has to interpret the auditor-related elements of the configuration file. "Rickard Bondesson" wrote on 24/08/2009 11:08:32: > Wasn't the idea to use the auditor in two modes? > > One mode where it is called by the Signer Engine to check the zone before > sending it out from the system. This depends if you have in the KASP. > If : unsigned -> Signer Engine -> Auditor -> signed > If not : unsigned -> Signer Engine -> signed > > So that auditor can stop the zone distribution in this case. > > The other case was an auditor daemon that runs regularly and checks the zones. > It can only give warnings (to syslog or whatever), but not be able to stop the > zone distribution. The original idea was to have the auditor daemon run from a box able to look at the zone being published via production nameservers. It should be able to warn about problems such as the signing process having failed or that the distribution from the primary had stopped (both of which result in published signatures approaching their expiration date). Stephen From jakob at kirei.se Mon Aug 24 11:28:26 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 24 Aug 2009 13:28:26 +0200 Subject: [Opendnssec-develop] Auditor daemon In-Reply-To: References: <630CFEC4-066C-4FAD-95F0-C5CC35846A88@iis.se> Message-ID: <6DF8E955-A135-4536-8FB9-036A4DEA517E@kirei.se> > IMHO, the easiest way to handle this would be for the signer to always > write the signed file to the auditor's directory and to always > invoke the > auditor. If the audit flag is absent, the auditor just moves the file > from the auditor directory to the output directory. It (marginally) > simplifies the signer and means that only the auditor has to > interpret the > auditor-related elements of the configuration file. since the auditor is optional, I don't think this a good way forward. I'd prefer the signer writes to signed/ and then notifies a running auditor if required. The auditor would audit the file and move it (or copy?) it to audited/ (configurable of course) if it passes the audit. if it doesn't get any notification from the signer it will scan for newly signed files anyway (since you cannot trust the signer to request auditing). I'm just mapping how things works in the real work. you don't call your auditor, they appear from time to time and do their work. you might want to give them a hint you have new stuff to audit, but they still knock on your door as required by the policy. at the same time, if you do not require auditing - you're not required to have an auditor for justing moving stuff. we can discuss his more thursday perhaps, jakob From owner-dnssec-trac at kirei.se Tue Aug 25 07:53:12 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 25 Aug 2009 07:53:12 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #17: pthread and libhsm Message-ID: <063.4e721b91415c03ff4747f5438a1f8b0e@kirei.se> #17: pthread and libhsm --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jelte Type: defect | Status: new Priority: major | Component: libhsm Version: | Keywords: --------------------------------------+------------------------------------- When compiling the libhsm from trunk on FC11 I am getting the following errors {{{ undefined reference to `pthread_create' undefined reference to `pthread_join' }}} I believe this is because you the complier flag for pthreads is missing. I added it to the Makefile in OpenDNSSEC/libhsm/src and it compiled fine. {{{ CFLAGS = -g -O2 -pedantic -Wall -Wextra -lpthread }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 25 07:56:26 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 25 Aug 2009 07:56:26 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #17: pthread and libhsm In-Reply-To: <063.4e721b91415c03ff4747f5438a1f8b0e@kirei.se> References: <063.4e721b91415c03ff4747f5438a1f8b0e@kirei.se> Message-ID: <072.4281af4a78b2701a5142889c2d619d25@kirei.se> #17: pthread and libhsm --------------------------------------+------------------------------------- Reporter: jonathan.stanton at cit.coop | Owner: jelte Type: defect | Status: closed Priority: major | Component: libhsm Version: | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks, fixed in r1680 -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Tue Aug 25 09:35:09 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 25 Aug 2009 11:35:09 +0200 Subject: [Opendnssec-develop] hsmutil test implemented Message-ID: hi, as we discussed last week, I've now committed some test code for hsmutil. example run: -- cut -- > hsmutil test sca6000 Testing repository: sca6000 Generating 512-bit RSA key... OK Extracting key identifier... OK, dfd950fc75624c34f44efad4e092a218 Signing with key... OK Deleting key... OK Generating 768-bit RSA key... OK Extracting key identifier... OK, 58447b5cd68d37689f50f8c5ea58821c Signing with key... OK Deleting key... OK Generating 1024-bit RSA key... OK Extracting key identifier... OK, 1f5c45ec0ba0521e2a81bc7348dae1a9 Signing with key... OK Deleting key... OK Generating 1536-bit RSA key... OK Extracting key identifier... OK, 1e9a74323934c5c7ccc27c9e19da7c37 Signing with key... OK Deleting key... OK Generating 2048-bit RSA key... OK Extracting key identifier... OK, 160b38b15f68ac50fc4f14572a533beb Signing with key... OK Deleting key... OK Generating 4096-bit RSA key... Failed Error: generate key pair (CKR_KEY_SIZE_RANGE) Generating 1024 bytes of random data... OK Generating 32-bit random data... 1673817854 Generating 64-bit random data... 3612757625826565657 -- cut -- -- Jakob Schlyter Kirei AB - http://www.kirei.se/ From rick at openfortress.nl Tue Aug 25 09:40:36 2009 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 25 Aug 2009 09:40:36 +0000 Subject: [Opendnssec-develop] hsmutil test implemented In-Reply-To: References: Message-ID: <20090825094036.GA30004@phantom.vanrein.org> Hi, > Generating 1024 bytes of random data... OK > Generating 32-bit random data... 1673817854 > Generating 64-bit random data... 3612757625826565657 Testing randomness is a novell idea, and it can be done with tools like ent. How serious is this test, and inhowfar would it be useful to have one as part of hsmbully? -Rick From jakob at kirei.se Tue Aug 25 09:50:04 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 25 Aug 2009 11:50:04 +0200 Subject: [Opendnssec-develop] hsmutil test implemented In-Reply-To: <20090825094036.GA30004@phantom.vanrein.org> References: <20090825094036.GA30004@phantom.vanrein.org> Message-ID: <20C086FB-9D33-4F69-BB3E-9C5AC6345B83@kirei.se> On 25 aug 2009, at 11.40, Rick van Rein wrote: > Testing randomness is a novell idea, and it can be done with tools > like > ent. How serious is this test, and inhowfar would it be useful to > have > one as part of hsmbully? I test it since we use the hsm_random{32,64} functions in other parts of the software. jakob From roland.vanrijswijk at surfnet.nl Tue Aug 25 09:55:27 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 25 Aug 2009 11:55:27 +0200 Subject: [Opendnssec-develop] hsmutil test implemented In-Reply-To: <20C086FB-9D33-4F69-BB3E-9C5AC6345B83@kirei.se> References: <20090825094036.GA30004@phantom.vanrein.org> <20C086FB-9D33-4F69-BB3E-9C5AC6345B83@kirei.se> Message-ID: <4A93B50F.4030906@surfnet.nl> If you want to have really good, really nasty randomness test, have a look at diehard (http://en.wikipedia.org/wiki/Diehard_tests) Cheers, Roland Jakob Schlyter wrote: > On 25 aug 2009, at 11.40, Rick van Rein wrote: > >> Testing randomness is a novell idea, and it can be done with tools like >> ent. How serious is this test, and inhowfar would it be useful to have >> one as part of hsmbully? > > I test it since we use the hsm_random{32,64} functions in other parts of > the software. > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Tue Aug 25 09:56:42 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 25 Aug 2009 11:56:42 +0200 Subject: [Opendnssec-develop] hsmutil test implemented In-Reply-To: <4A93B50F.4030906@surfnet.nl> References: <20090825094036.GA30004@phantom.vanrein.org> <20C086FB-9D33-4F69-BB3E-9C5AC6345B83@kirei.se> <4A93B50F.4030906@surfnet.nl> Message-ID: <38BE8E33-3B2C-4D6C-8F59-CE585186B822@kirei.se> On 25 aug 2009, at 11.55, Roland van Rijswijk wrote: > If you want to have really good, really nasty randomness test, have a > look at diehard (http://en.wikipedia.org/wiki/Diehard_tests) we're not testing random number quality, just that emits numbers as expected. the quality is checked as part of any certification process (e.g. FIPS 140-2). I guess there are stuff talking PKCS#11 that does not provide any random numbers. jakob From roland.vanrijswijk at surfnet.nl Tue Aug 25 10:04:20 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 25 Aug 2009 12:04:20 +0200 Subject: [Opendnssec-develop] hsmutil test implemented In-Reply-To: <38BE8E33-3B2C-4D6C-8F59-CE585186B822@kirei.se> References: <20090825094036.GA30004@phantom.vanrein.org> <20C086FB-9D33-4F69-BB3E-9C5AC6345B83@kirei.se> <4A93B50F.4030906@surfnet.nl> <38BE8E33-3B2C-4D6C-8F59-CE585186B822@kirei.se> Message-ID: <4A93B724.4040206@surfnet.nl> Hi Jakob, Jakob Schlyter wrote: > we're not testing random number quality, just that emits numbers as > expected. the quality is checked as part of any certification process > (e.g. FIPS 140-2). Yes and no. Beware of vendors that implement C_GenerateRandom in software only. The randomness checks for the certification may only apply to the internal RNG in the HSM or token that is used for key generation. Especially smart card and token vendors sometimes implement C_GenerateRandom in software (although most of them are sensible enough to use a common implementation, e.g. OpenSSL). > I guess there are stuff talking PKCS#11 that does not provide any random > numbers. Yep, see above. I agree with you, though, that testing RNGs on HSMs is out of scope and maybe a bit too paranoid ;-) Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From roland.vanrijswijk at surfnet.nl Tue Aug 25 10:06:01 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 25 Aug 2009 12:06:01 +0200 Subject: [Opendnssec-develop] hsmutil test implemented In-Reply-To: <4A93B724.4040206@surfnet.nl> References: <20090825094036.GA30004@phantom.vanrein.org> <20C086FB-9D33-4F69-BB3E-9C5AC6345B83@kirei.se> <4A93B50F.4030906@surfnet.nl> <38BE8E33-3B2C-4D6C-8F59-CE585186B822@kirei.se> <4A93B724.4040206@surfnet.nl> Message-ID: <4A93B789.6090907@surfnet.nl> Having said the below, what do you actually use the random data for? I suppose for salting in NSEC3? Cheers, Roland Roland van Rijswijk wrote: > Hi Jakob, > > Jakob Schlyter wrote: >> we're not testing random number quality, just that emits numbers as >> expected. the quality is checked as part of any certification process >> (e.g. FIPS 140-2). > > Yes and no. Beware of vendors that implement C_GenerateRandom in > software only. The randomness checks for the certification may only > apply to the internal RNG in the HSM or token that is used for key > generation. Especially smart card and token vendors sometimes implement > C_GenerateRandom in software (although most of them are sensible enough > to use a common implementation, e.g. OpenSSL). > >> I guess there are stuff talking PKCS#11 that does not provide any random >> numbers. > > Yep, see above. > > I agree with you, though, that testing RNGs on HSMs is out of scope and > maybe a bit too paranoid ;-) > > Cheers, > > Roland > -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Tue Aug 25 10:09:58 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 25 Aug 2009 12:09:58 +0200 Subject: [Opendnssec-develop] hsmutil test implemented In-Reply-To: <4A93B789.6090907@surfnet.nl> References: <20090825094036.GA30004@phantom.vanrein.org> <20C086FB-9D33-4F69-BB3E-9C5AC6345B83@kirei.se> <4A93B50F.4030906@surfnet.nl> <38BE8E33-3B2C-4D6C-8F59-CE585186B822@kirei.se> <4A93B724.4040206@surfnet.nl> <4A93B789.6090907@surfnet.nl> Message-ID: <2FE672FC-8FA2-4DD9-8B26-6684D8D5E3CA@kirei.se> On 25 aug 2009, at 12.06, Roland van Rijswijk wrote: > Having said the below, what do you actually use the random data for? I > suppose for salting in NSEC3? > find . -type f -name '*.c' | xargs grep 'hsm_random' ./enforcer/ksm/ksm_policy.c: status = hsm_random_buffer(ctx, newsalt, policy->denial->saltlength); yes :-) and only that. jakob From roland.vanrijswijk at surfnet.nl Tue Aug 25 10:23:32 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 25 Aug 2009 12:23:32 +0200 Subject: [Opendnssec-develop] hsmutil test implemented In-Reply-To: <2FE672FC-8FA2-4DD9-8B26-6684D8D5E3CA@kirei.se> References: <20090825094036.GA30004@phantom.vanrein.org> <20C086FB-9D33-4F69-BB3E-9C5AC6345B83@kirei.se> <4A93B50F.4030906@surfnet.nl> <38BE8E33-3B2C-4D6C-8F59-CE585186B822@kirei.se> <4A93B724.4040206@surfnet.nl> <4A93B789.6090907@surfnet.nl> <2FE672FC-8FA2-4DD9-8B26-6684D8D5E3CA@kirei.se> Message-ID: <4A93BBA4.6030300@surfnet.nl> Hi Jakob, Jakob Schlyter wrote: > On 25 aug 2009, at 12.06, Roland van Rijswijk wrote: > >> Having said the below, what do you actually use the random data for? I >> suppose for salting in NSEC3? > >> find . -type f -name '*.c' | xargs grep 'hsm_random' > ./enforcer/ksm/ksm_policy.c: status = > hsm_random_buffer(ctx, newsalt, policy->denial->saltlength); > > yes :-) > > and only that. :-D I guess a note somewhere in the documentation or perhaps in the HSM Buyer's Guide? Perhaps a criterium should be: implements C_GenerateRandom -- CKF_RNG set in the CK_TOKEN_INFO structure returned by C_GetTokenInfo and C_GenerateRandom does not return CKR_RANDOM_NO_RNG. And maybe a note about the quality of random data etc. would be useful. IMHO it's completely out of scope to test the quality of the RNG we use when using an external PKCS #11 module. Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From owner-dnssec-trac at kirei.se Wed Aug 26 07:35:05 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 26 Aug 2009 07:35:05 -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.b0173e7ac4215a57fe32a7bfaa3e3a33@kirei.se> #16: Missing include information for sqlite3 when building enforcer ---------------------------------+------------------------------------------ Reporter: johani at autonomica.se | Owner: rb Type: defect | Status: closed Priority: major | Component: Enforcer Version: | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Changes (by rb): * status: accepted => closed * resolution: => fixed Comment: Closing this one. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Thu Aug 27 08:54:30 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 27 Aug 2009 09:54:30 +0100 Subject: [Opendnssec-develop] ksmutil export Message-ID: I've added export of keys and ds records to ksmutil, the export command now looks like: usage: ksmutil [-f config] export [policy|keys|ds] <[policy_name]|zone_name> [keytype] policy: export all policies [or named policy] to xml keys: export dnskey RRs for named zone [KSK unless ZSK specified] ds: export ds RRs for named zone [KSK unless ZSK specified] I don't think that it is quite right yet, but the exact functionality can be tweaked as needed... E.g. currently only active keys are exported, but I guess that "ready" (I.e. emergency) keys should be too? Should it indicate which is active in this case? If you don't specify a zone then you get all zones; I'll change this to require a -a flag instead. Should we allow DS from ZSK? Is that ever useful? If anyone wants to suggest refinements then please either add them to pivotal or email me. Cheers, Sion From roy at nominet.org.uk Thu Aug 27 09:02:19 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 27 Aug 2009 11:02:19 +0200 Subject: [Opendnssec-develop] ksmutil export In-Reply-To: References: Message-ID: Sion wrote on 08/27/2009 10:54:30 AM: > I've added export of keys and ds records to ksmutil, the export command now > looks like: > > usage: ksmutil [-f config] export [policy|keys|ds] > <[policy_name]|zone_name> [keytype] > policy: export all policies [or named policy] to xml > keys: export dnskey RRs for named zone [KSK unless ZSK specified] > ds: export ds RRs for named zone [KSK unless ZSK specified] > > I don't think that it is quite right yet, but the exact functionality can > be tweaked as needed... > > E.g. currently only active keys are exported, but I guess that "ready" > (I.e. emergency) keys should be too? Should it indicate which is active in > this case? Or maybe allow selection by possible states [ready|active|.....|....] as well? > If you don't specify a zone then you get all zones; I'll change this to > require a -a flag instead. > > Should we allow DS from ZSK? Is that ever useful? I think it is useful. > If anyone wants to suggest refinements then please either add them to > pivotal or email me. Thanks Sion, Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Fri Aug 28 07:49:03 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 28 Aug 2009 07:49:03 +0000 Subject: [Opendnssec-develop] Unified Control Program (was -a vs --all) In-Reply-To: References: Message-ID: <20090828074903.GA9210@phantom.vanrein.org> Hi Stephen, Sorry for missing your command description at first, I only glanced at the message on top and mistook it for the entire message. > The document describes the functionality of such an application (called, > for the purposes of this document, "odctl" [OpenDNSSEC Control]). "odXXX[d]" could very well be the consistent naming format that I was thinking about during the meeting. For example, odsignd odkeygend odkaspd odauditd and either odhsmutil -or- hsmutil odksmutil -or- ksmutil odsigutil -or- sigutil (With the latter three combined in one, the "od" prefix shouldn't be a nuisance to the user.) It'll also make it easier to do stuff like ps ax | grep ^od The false positives of the latter are pretty much limited to people making octal dumps of files I suppose :-) > As noted above, a management program requires the ability to configure the > system. I don't think of it being a requirement of odctl to edit config files, but it definately is a bonus that helps to demonstrate what the use of a strictly formatted configfile is (for example in XML). > c) It is not clear that a CLI is the best way to edit the structured data > in the configuration files - a GUI may be a better option, although this > will entail much more work. We have a basis of comparison for that. The postconf command edits the setup of Postfix, and I've heard people being enthousiastic about it. I also find it much nicer during automated installs -- I'd much rather specify "postconf relayhost=xx.yy.zz" than "echo something_crummy | ed /etc/postfix/main.conf". In other words, there are certainly good sides to such CLI edits of configfiles, most notably surrounding automation. > b) The configuration files are still being altered as development > proceeds. It will be better to wait until the format and contents have > settled down. Unless you'd use the DTD to somehow be able to generically do the work (or find a pre-existing library to do it for you). > In subsystem mode, [...] > Single command mode [...] Looks sensible to me. > ... which will invoke the odctl program, run the command (in this case, > "addzone") and exit odctl, returning control to the shell prompt. I assume if "addzone" involves informing a number of daemons, setting up configfiles, notifying daemons and such, that it will all be taken care of? And once a sanity check on the config is in place, that it will run that too, a bit like apachectl checking on configfile syntax before it fails on it during a restart? > In practice, odctl will be a thin layer over functions in the OpenDNSSEC > libraries; In theory I think :) I'm sure this program too will start to lead a life of its own. Remember, always if you act on DNS, you open a can of worms. > there should be little (if anything) that odctl does that > cannot be done by calling one of the library functions (this will > facilitate the creation of a GUI interface). If however it can smoothe the path such that a single command arranges all that needs to be done throughout OpenDNSSEC, it will do much more than being a shell: it will uplift OpenDNSSEC to a user-friendly platform! It could be the "single button" that we all hope to press one day. > Functions It could be the "single button" that we all hope to press one day. It could be the "single button" that we all hope to press one day. > odctl> source > Reads and executes odctl commands from the given file. (The commands > should be echoed to stdout before execution.) Yeah, it really looks like a simple thin layer when you add includes ;-) > odctl> start [-p hsm_password] [component] > odctl> stop [component] > odctl> restart [component] Sometimes, there also is a use for "reload" which, at minimum, does the same as "restart" but, ideally, reloads updated configuration without any downtime. Short downtimes aren't an issue for OpenDNSSEC but you could still decide to honour this practice. Of course, apachectl only supports "restart" but does a "reload" whenever possible. > List of Command Flags > ===================== Long options as well? Thanks, Stephen. -Rick From rick at openfortress.nl Fri Aug 28 10:45:08 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 28 Aug 2009 10:45:08 +0000 Subject: [Opendnssec-develop] Embedded scripts can replace syslog() Message-ID: <20090828104508.GA11966@phantom.vanrein.org> Hello Stephen and others, Attached is a small demonstration program that I set up to enable more flexible (and more reliable) logging than through ssyslog(). This is a drop-in replacement for syslog() calls, with just a single extra call for opening a Python script with a user-settable odlog() function. The rest of the code diverts the syslog()-replacing odlog() calls to Python. I tried using a setup with embedded Ruby, but Ruby does not seem to be mature enough to have such a facility. So I used Python instead, apologising for emphasising that (build-time) dependency. The use is simple enough, only the log script path should be set with an option like --logscript. Example use: int main (int argc, char *argv []) { odlog (LOG_INFO, "This appears through syslog"); odlogscript ("demolog"); odopenlog ("odlogdemo", LOG_NDELAY, LOG_DAEMON); odlog (LOG_INFO, "Now the Python script has started to work"); odlog (LOG_EMERG, "All Hell Just Broke Loose"); odcloselog (); odlog (LOG_INFO, "And now we're back to plain syslog behaviour"); } Further code is attached. Just make, set PYTHONPATH=. and run ./odlogdemo A build requirement is a python-devel package of some kind. Works on Linux. Enjoy, -Rick -------------- next part -------------- A non-text attachment was scrubbed... Name: syslog-embedded.tgz Type: application/x-gtar Size: 3197 bytes Desc: not available URL: From owner-dnssec-trac at kirei.se Fri Aug 28 11:11:55 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 28 Aug 2009 11:11:55 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #18: nsec3er fails with large zones Message-ID: <059.cd367cacafc3f1265622b4f2c54c4b70@kirei.se> #18: nsec3er fails with large zones ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: jelte Type: defect | Status: new Priority: major | Component: Signer Version: | Keywords: ----------------------------------+----------------------------------------- There is a design flaw on the create_nsec3_records function in nsec3er.c. If the input file has more than MAX_LINE_LEN effective lines (excluding comments) before reaching the SOA record, the line 'pre_soa_lines[pre_count] = strdup(line);' goes beyond allocation causing a SEGFAULT. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Aug 28 11:13:01 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 28 Aug 2009 11:13:01 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #18: nsec3er fails with large zones In-Reply-To: <059.cd367cacafc3f1265622b4f2c54c4b70@kirei.se> References: <059.cd367cacafc3f1265622b4f2c54c4b70@kirei.se> Message-ID: <068.3b7ee4331b8dc554122228ebd9bed06c@kirei.se> #18: nsec3er fails with large zones ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: defect | Status: assigned Priority: major | Component: Signer Version: | Resolution: Keywords: | ----------------------------------+----------------------------------------- Changes (by jakob): * owner: jelte => matthijs * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Aug 28 11:13:30 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 28 Aug 2009 11:13:30 -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.f65a0dd3d639fb49c0ea52dde52e44a1@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: matthijs Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: | ---------------------------------+------------------------------------------ Changes (by jakob): * owner: jelte => matthijs -- Ticket URL: OpenDNSSEC OpenDNSSEC From roland.vanrijswijk at surfnet.nl Fri Aug 28 11:42:56 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Fri, 28 Aug 2009 13:42:56 +0200 Subject: [Opendnssec-develop] Meeting minutes 2009-08-27 (Utrecht) available Message-ID: <4A97C2C0.3070604@surfnet.nl> Hi guys, I've created the meeting minutes on the wiki: http://trac.opendnssec.org/wiki/Meetings/Minutes/2009-08-27 Those of you who had break-out session, please feel free to add a summary of what you discussed at the end of the minutes. Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From Stephen.Morris at nominet.org.uk Fri Aug 28 12:46:11 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Fri, 28 Aug 2009 13:46:11 +0100 Subject: [Opendnssec-develop] Role of the Auditor Message-ID: Following up from our discussion about the auditor yesterday, this is a description of what I think it should be doing: a. The auditor is an quality check in the OpenDNSSEC signing process to ensure that incorrect or out of date signed data is not inadvertently loaded into production nameservers. It is run by the signer engine once the zone file has been signed and checks the signed file against the unsigned file (and against the policy) to ensure that the signer has done its work correctly. If the auditor does not detect a problem, the signed zone file can be loaded. To ensure that the process is a proper quality check, the auditor has been coded by a different programmer to that of the signer and in a different language. However, both the signer and the auditor have a dependency on the OpenSSL library. The auditor is an optional component of OpenDNSSEC and the configuration file can specify that it not be run. If the auditor _is_ configured to run, the signer writes its output to an auditor directory and the auditor, on successful completion of the audit, moves it to the "signed" directory. If the auditor _is not_ configured to run, the signer writes its output directly to the "signed" directory. Notes: i) The writing of the output file by the signer should be a two-stage process - write to a temporary file then rename. Such a scheme ensure that a valid signed file is not replaced by an incomplete one should the signer fail. ii) Can we agree to rename "signer engine" to something like the "scheduler"? As it is responsible for initiating the auditor, I think the name is more accurate and will lead to less confusion. b. The monitor is a daemon that runs on a system that can see the public nameservers for the zone and does consistency checks on the data retrieved from them. As such, it shares much of the code of the auditor and has been referred to as the "auditor daemon" (a name I think we should no longer use). Its primary purpose is to check signature lifetimes to see if any are approaching their expiration date - if some are, it could indicate that either the signer is not running or that the distribution of zone data to the secondaries has been interrupted. It should also do other consistency checks (e.g. checking that the KSK has a DS record in the parent zone), which may include extensive checking of zone data should it have a copy of the input zone file or list of names in the zone. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Fri Aug 28 12:51:51 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 28 Aug 2009 14:51:51 +0200 Subject: [Opendnssec-develop] Role of the Auditor In-Reply-To: References: Message-ID: <27C7F46C-8E2B-4559-84F0-09C598F66547@kirei.se> On 28 aug 2009, at 14.46, Stephen.Morris at nominet.org.uk wrote: > a. The auditor is an quality check in the OpenDNSSEC signing process > to ensure that incorrect or out of date signed data is not > inadvertently loaded into production nameservers. It is run by the > signer engine once the zone file has been signed and checks the > signed file against the unsigned file (and against the policy) to > ensure that the signer has done its work correctly. If the auditor > does not detect a problem, the signed zone file can be loaded. To > ensure that the process is a proper quality check, the auditor has > been coded by a different programmer to that of the signer and in a > different language. I agree. > However, both the signer and the auditor have a dependency on the > OpenSSL library. no, they don't - the signer does not use code from OpenSSL. the auditor does though. > The auditor is an optional component of OpenDNSSEC and the > configuration file can specify that it not be run. If the auditor > _is_ configured to run, the signer writes its output to an auditor > directory and the auditor, on successful completion of the audit, > moves it to the "signed" directory. If the auditor _is not_ > configured to run, the signer writes its output directly to the > "signed" directory. ack. > Notes: > i) The writing of the output file by the signer should be a two- > stage process - write to a temporary file then rename. Such a > scheme ensure that a valid signed file is not replaced by an > incomplete one should the signer fail. > ii) Can we agree to rename "signer engine" to something like the > "scheduler"? As it is responsible for initiating the auditor, I > think the name is more accurate and will lead to less confusion. the signer engine is the component that drives the signing process - see http://svn.opendnssec.org/docs/dnssec-signer-arch-detail.png. I have some more diagrams how this will look in v2 when we integrate adapters, signer engine and all its components - will post them to the repo shortly. > b. The monitor is a daemon that runs on a system that can see the > public nameservers for the zone and does consistency checks on the > data retrieved from them. As such, it shares much of the code of > the auditor and has been referred to as the "auditor daemon" (a name > I think we should no longer use). Its primary purpose is to check > signature lifetimes to see if any are approaching their expiration > date - if some are, it could indicate that either the signer is not > running or that the distribution of zone data to the secondaries has > been interrupted. It should also do other consistency checks (e.g. > checking that the KSK has a DS record in the parent zone), which may > include extensive checking of zone data should it have a copy of the > input zone file or list of names in the zone. yes, and the monitor has not yet been written. jakob From roy at nominet.org.uk Fri Aug 28 13:04:49 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 28 Aug 2009 15:04:49 +0200 Subject: [Opendnssec-develop] Role of the Auditor In-Reply-To: References: Message-ID: Stephen Morris wrote on 08/28/2009 02:46:11 PM: > Stephen.Morris at nominet.org.uk > Sent by: opendnssec-develop-bounces at lists.opendnssec.org > > 08/28/2009 02:46 PM > > To > > opendnssec-develop at lists.opendnssec.org > > cc > > Subject > > [Opendnssec-develop] Role of the Auditor > > Following up from our discussion about the auditor yesterday, this > is a description of what I think it should be doing: > > a. The auditor is an quality check in the OpenDNSSEC signing process > to ensure that incorrect or out of date signed data is not > inadvertently loaded into production nameservers. It is run by the > signer engine once the zone file has been signed and checks the > signed file against the unsigned file (and against the policy) to > ensure that the signer has done its work correctly. If the auditor > does not detect a problem, the signed zone file can be loaded. To > ensure that the process is a proper quality check, the auditor has > been coded by a different programmer to that of the signer and in a > different language. However, both the signer and the auditor have a > dependency on the OpenSSL library. I assume that the signer depends on a (soft)HSM which have its own dependency (on Botan in the case of softHSM). So there should not be a mutual dependency on cryptolibs. As for the language, I still do not see the language difference as an asset, but more a complexity. (I understand the reason _why_ there are different languages used here, but code diversity wasn't one). > The auditor is an optional component of OpenDNSSEC and the > configuration file can specify that it not be run. If the auditor > _is_ configured to run, the signer writes its output to an auditor > directory and the auditor, on successful completion of the audit, > moves it to the "signed" directory. If the auditor _is not_ > configured to run, the signer writes its output directly to the > "signed" directory. Would it be an option to state in the signed file, commented out and in the top of the file, if the file was audited? In general, more state can be dumped as comments into the signed/audited file. During development of the NSEC3 testbed, this turned out to be extremely useful. > Notes: > i) The writing of the output file by the signer should be a two- > stage process - write to a temporary file then rename. Such a > scheme ensure that a valid signed file is not replaced by an > incomplete one should the signer fail. > ii) Can we agree to rename "signer engine" to something like the > "scheduler"? As it is responsible for initiating the auditor, I > think the name is more accurate and will lead to less confusion. I think we should submit all the daemons to a naming policy. Communicated/keygend/signer_engine all could use a od_ prefix, like Rick mentioned in his mail. > b. The monitor is a daemon that runs on a system that can see the > public nameservers for the zone and does consistency checks on the > data retrieved from them. As such, it shares much of the code of > the auditor and has been referred to as the "auditor daemon" (a name > I think we should no longer use). Its primary purpose is to check > signature lifetimes to see if any are approaching their expiration > date - if some are, it could indicate that either the signer is not > running or that the distribution of zone data to the secondaries has > been interrupted. It should also do other consistency checks (e.g. > checking that the KSK has a DS record in the parent zone), which may > include extensive checking of zone data should it have a copy of the > input zone file or list of names in the zone. It is likely that secure deployment requires that the system with the attached hsm, and thus the signing engine, is severely limited, on even completely prohibited, in communication with anything that can be found on the public internet, including all the secondaries. Also, it would make sense to have the monitor completely separated from OpenDNSSEC systems and part of the generic health monitoring system of all systems. However, I'd really welcome such code. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Fri Aug 28 14:43:21 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 28 Aug 2009 14:43:21 +0000 Subject: [Opendnssec-develop] Embedded scripts can replace syslog() In-Reply-To: <20090828104508.GA11966@phantom.vanrein.org> References: <20090828104508.GA11966@phantom.vanrein.org> Message-ID: <20090828144321.GA16292@phantom.vanrein.org> Hi, Relativating my own democode, I see the inclusion of a complete Python interpreter as a potential problem: * as a static library, it makes programs larger * as a dynamic library, it adds a dependency (on python-devel) Another approach, with a similar drop-in-place approach, could be to use an exec() call to invoke the "logger" utility or another (shell) script with the same options as used to logger(1), NAME logger - a shell command interface to the syslog(3) system log module SYNOPSIS logger [-isd] [-f file] [-p pri] [-t tag] [-u socket] [message ...] Having said that, I'm interested in hearing your thoughts on the trade-offs. Best, -Rick From owner-dnssec-trac at kirei.se Sun Aug 30 22:44:12 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 30 Aug 2009 22:44:12 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #18: nsec3er fails with large zones In-Reply-To: <059.cd367cacafc3f1265622b4f2c54c4b70@kirei.se> References: <059.cd367cacafc3f1265622b4f2c54c4b70@kirei.se> Message-ID: <068.07e09846bc240a6853cd70b70ca1e71f@kirei.se> #18: nsec3er fails with large zones ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: defect | Status: assigned Priority: major | Component: Signer Version: | Resolution: Keywords: | ----------------------------------+----------------------------------------- Comment(by sebastian at nzrs.net.nz): I just attached a simple patch to fix the bug. After finding the SOA record, goes to the beginning of the file and do the normal processing. I tested on my Ubuntu systems, I don't know how portable is the rewind/fseek call. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 31 03:02:17 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 31 Aug 2009 03:02:17 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #19: finalizer fails with larger zones Message-ID: <059.f7d9a37a4c231833a497fe7685043487@kirei.se> #19: finalizer fails with larger zones ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: jelte Type: defect | Status: new Priority: trivial | Component: Signer Version: 1.0a1 | Keywords: finalizer bug large zones ----------------------------------+----------------------------------------- This is completely related to bug #18, because is the same bug. finalizer tries to save the lines before the SOA record on a fixed size array. If the number of lines is larger than the allocated space, a SEGFAULT is received. Attached is a patch that solves the problem by scanning the file, finding the SOA record and print it. Then starts from the beginning of the input file, skipping the line where the SOA record was. May be it would be useful to print the SOA record and the corresponding RRSIG record(s) together, will test that later. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 31 08:29:53 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 31 Aug 2009 08:29:53 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #19: finalizer fails with larger zones In-Reply-To: <059.f7d9a37a4c231833a497fe7685043487@kirei.se> References: <059.f7d9a37a4c231833a497fe7685043487@kirei.se> Message-ID: <068.c7f8d6938e07c74b4df264b1beefdf29@kirei.se> #19: finalizer fails with larger zones --------------------------------------+------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: defect | Status: assigned Priority: trivial | Component: Signer Version: 1.0a1 | Resolution: Keywords: finalizer bug large zones | --------------------------------------+------------------------------------- Changes (by rb): * owner: jelte => matthijs * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Mon Aug 31 08:57:34 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 31 Aug 2009 10:57:34 +0200 Subject: [Opendnssec-develop] Embedded scripts can replace syslog() In-Reply-To: <20090828144321.GA16292@phantom.vanrein.org> References: <20090828104508.GA11966@phantom.vanrein.org> <20090828144321.GA16292@phantom.vanrein.org> Message-ID: <0D6A38B7-ED04-4087-A65A-8BB222AC3B61@kirei.se> On 28 aug 2009, at 16.43, Rick van Rein wrote: > Relativating my own democode, I see the inclusion of a complete Python > interpreter as a potential problem: > * as a static library, it makes programs larger > * as a dynamic library, it adds a dependency (on python-devel) > > Another approach, with a similar drop-in-place approach, could be to > use an exec() call to invoke the "logger" utility or another (shell) > script with the same options as used to logger(1), for each and every log line? that's something I would encourage my competitors do do. > Having said that, I'm interested in hearing your thoughts on the > trade-offs. for version 1, which is our focus currently - I say we do syslog only. jakob From owner-dnssec-trac at kirei.se Mon Aug 31 09:58:43 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 31 Aug 2009 09:58:43 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #18: nsec3er fails with large zones In-Reply-To: <059.cd367cacafc3f1265622b4f2c54c4b70@kirei.se> References: <059.cd367cacafc3f1265622b4f2c54c4b70@kirei.se> Message-ID: <068.96316a51cd3e3179259e059cfeccaca0@kirei.se> #18: nsec3er fails with large zones ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Changes (by matthijs): * status: assigned => closed * resolution: => fixed Comment: Hi Sebastian, Thanks for your patch. rewind is C89, C99 compatible, so that is alright. The nseccer and nsec3er seems to work now on large files. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Mon Aug 31 10:06:29 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 31 Aug 2009 12:06:29 +0200 Subject: [Opendnssec-develop] s/Emergency/Standby/ ? Message-ID: <16BB809A-F481-45D9-BFC9-ACC093CDAC1A@kirei.se> at the meeting last week we decided to rename Emergency Keys to Standy Keys, right? does this make sense and can someone remind me why we want to do this? should the terminology in draft-morris-dnsop-dnssec-key-timing-00.txt also change? jakob From owner-dnssec-trac at kirei.se Mon Aug 31 10:42:14 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 31 Aug 2009 10:42:14 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #19: finalizer fails with larger zones In-Reply-To: <059.f7d9a37a4c231833a497fe7685043487@kirei.se> References: <059.f7d9a37a4c231833a497fe7685043487@kirei.se> Message-ID: <068.a7560111d1d8d942bb919357844cbc88@kirei.se> #19: finalizer fails with larger zones --------------------------------------+------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: defect | Status: closed Priority: trivial | Component: Signer Version: 1.0a1 | Resolution: fixed Keywords: finalizer bug large zones | --------------------------------------+------------------------------------- Changes (by matthijs): * status: assigned => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Mon Aug 31 13:17:19 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 31 Aug 2009 15:17:19 +0200 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #13: "engine: no new signatures, keeping zone" when changing zone parameters In-Reply-To: <067.f65a0dd3d639fb49c0ea52dde52e44a1@kirei.se> References: <058.aa1d6fb1117521292b7da9d6cb0ad93f@kirei.se> <067.f65a0dd3d639fb49c0ea52dde52e44a1@kirei.se> Message-ID: <4A9BCD5F.8090609@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Picking op this ticket. Not sure what to do. The report is two-fold. 1. What to do if the signer engine is presented a new SignerConfiguration but no new signatures need to be created. Should we keep the old zone or should we force a new output zone? In my point of view, we should only output a new zone if new signatures where created. So, for example an increased signature refresh value does not necessarily result in a new output zone. 2. What to do when signer_engine_cli sign is called. Should we force a new output zone or only if new signatures are created? In my point of view, again, we should only output a new zone if new signatures are created. If the SOA serial changed, we should only output a new zone if the SOA/Serial is equal to "keep". Is this ok? Matthijs OpenDNSSEC wrote: > #13: "engine: no new signatures, keeping zone" when changing zone parameters > ---------------------------------+------------------------------------------ > Reporter: mattias at nonetwork.se | Owner: matthijs > Type: defect | Status: assigned > Priority: minor | Component: Unknown > Version: | Resolution: > Keywords: | > ---------------------------------+------------------------------------------ > Changes (by jakob): > > * owner: jelte => 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 iQEcBAEBAgAGBQJKm81GAAoJEA8yVCPsQCW5bCYIAJF7B4p2wyrpgjZQpO6lE2xa ryQ2LWv1jqeyUTBpZMokJG1t5yvGqKPh4OdaUOXMSexBxW/KS7TGMY7YS4xJTV2W Us4oCU4OMh4lPVVGCID98VIbuAefD/ZtoXDM73L+XE9o3nYbOv/CwX6PvDrbkonh fnMMhfOtk2oL5pn+aKVKd9F/x6+BNdnsZSCbNF3l8cTSRNwJi1nYBAA5Y0iNwRcm rljwxhTktieWPzE1jsqmU0cdRtPqejlYB9VuLgrhpBKqrUG5MCidbAs9AxUVC2NB k+1DxmwBMpKcTDpOUoKBzUYaKDYKq+hchJZGku/HiXyUVyucACWa2lE8/W1RR7M= =K2ai -----END PGP SIGNATURE----- From rick at openfortress.nl Mon Aug 31 13:50:47 2009 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 31 Aug 2009 13:50:47 +0000 Subject: [Opendnssec-develop] s/Emergency/Standby/ ? In-Reply-To: <16BB809A-F481-45D9-BFC9-ACC093CDAC1A@kirei.se> References: <16BB809A-F481-45D9-BFC9-ACC093CDAC1A@kirei.se> Message-ID: <20090831135047.GF20572@phantom.vanrein.org> Hi, > at the meeting last week we decided to rename Emergency Keys to Standy > Keys, right? Yes, I think so. > does this make sense and can someone remind me why we want to do this? Because we also use them from cron scripts that enforce rollover dates and in general to just rollover in a non-emergency situation. -Rick From owner-dnssec-trac at kirei.se Mon Aug 31 14:19:52 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 31 Aug 2009 14:19:52 -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.2d418a99697423ac16ed899997314159@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: matthijs Type: defect | Status: assigned Priority: minor | Component: Unknown Version: | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by matthijs): Replying to [comment:7 mattias at nonetwork.se]: > I use datecounter SOA format. > > Yes, I guess signer_engine_cli clear would work. Guess I missed that option, I did delete and then add, but if I remember correct then there where still files in the tmp dir which I had to remove. That issue has been resolved now. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bondesson at iis.se Mon Aug 31 15:05:03 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 31 Aug 2009 17:05:03 +0200 Subject: [Opendnssec-develop] Upcoming meeting dates Message-ID: <69830D4127201D4EBD146B90411997180101912C@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi These are the upcoming meeting dates Telephone meetings: 2009-09-09 from 13:00h-15:00h CET (12:00h-14:00h BST) 2009-09-23 from 13:00h-15:00h CET (12:00h-14:00h BST) Face-to-face: When: 29 September - 2 October (4 days) Where: Gothenburg Start: Around 9:30-10:30 CET on Tuesday depending on when people can arrive End: Perhaps little earlier on Friday so that you can come home at a decent time. Code sprint meeting to finish version one of OpenDNSSEC. Please indicate if you will be present at the location (green), available via internet (yellow), not available (red). http://www.doodle.com/q4wrcawkit8gsemy -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBUAwUBSpvmn+CjgaNTdVjaAQj40Af3V5b071ibG+VE0190KdGFflL2z+2tYp3a h4ULvc31LumFxeyc2juxmjmXgtg+vT8kG6I9DSQWr21BkajNbSmntRMEU78rmXn5 s1c3l5G6Kc8yiAO4kxgCY3Aa2bA7alNfwnaBVyt+4s/RhwOYwgTajcCNT+QdeicY MG1d57UhhQQY7KPyg064dybHlhdULlmX1w7Nyrq/iPoMLcVvr8HoKCLeA94gKjEW vWEFbb6PgoFDDKqvprh0Yj7qKMW/othe/lI3UJsaTxeLLnQDmCbtq/XbWMAwoXhR zwU9JCTySV7menQD1MwBvzELRpIl+5SlirhlF+Qm7DBin/gnkxwj =Nr08 -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Mon Aug 31 23:29:38 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 31 Aug 2009 23:29:38 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #20: Added generation statistics for nseccer, nsec3er and signer Message-ID: <059.6dc553c3ddb0e93ee9e0308360446ab8@kirei.se> #20: Added generation statistics for nseccer, nsec3er and signer ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: jelte Type: enhancement | Status: new Priority: minor | Component: Signer Version: 1.0a1 | Keywords: enhancement generation rate ----------------------------------+----------------------------------------- To provide some level of feedback about the signing system I'm testing is working, I added the generation rate for the nseccer, nsec3er and signer program. For all I keep a counter with the number of elements (NSEC/NSEC3/RRSIG) generated and the time elapsed, in order to provide the generation rate. The values are printed to stderr (which Engine.py prints to the log file). -- Ticket URL: OpenDNSSEC OpenDNSSEC