From owner-dnssec-trac at kirei.se Mon Nov 2 10:23:06 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 02 Nov 2009 10:23:06 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #34: Softhsm +lib In-Reply-To: <061.47f61d576ede9063deccf51eb68338e5@kirei.se> References: <061.47f61d576ede9063deccf51eb68338e5@kirei.se> Message-ID: <070.32b322656c4e113e8b134de24f8fab80@kirei.se> #34: Softhsm +lib ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: closed Priority: critical | Component: SoftHSM Version: trunk | Resolution: worksforme Keywords: | ------------------------------------+--------------------------------------- Changes (by rb): * status: assigned => closed * resolution: => worksforme -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon Nov 2 11:11:04 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 2 Nov 2009 12:11:04 +0100 Subject: [Opendnssec-develop] Deactivating old KSK Message-ID: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Am I correct if I say that old KSK are currently automatically deactivated in accordance with the rollover algorithm? It should only be deactivated once the user has had the chance to publish the new DS to its parent. Shouldn't the rollover process be a two-step rocket? First make a new key active. And then deactivate the old key on the command by the user (or any script running on the machine) when the new DS is published. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSu6+SOCjgaNTdVjaAQgeSQf+MGLbbmOPo1FsQPRJFVrEIIXDWmaoe0Kz Be/yDPb9dogQzsQB+Ovs8GjShqDrvpXp06R0oN1LYE/q4cbRhBLIjDjCrFmAN5m5 aqwp148qY45r2+96I4NFFHoJ+mCBcws/+FzyxOt5+tZ+z3bwfGAPZlwkAduJOzja bgUBQqhYTAeNchHUk15B0Z3/Y5C1MOVBKge7iam1CWiIxaHIUm0Wo7Z7Gio8NKxy ro1kdGAC4aR9zlMpHbwiu0R0vyegYYXTxm0uS9vUf65AedOg6flByOK+AzQIlEUu iwUWl0qUITYs0mux0/lMr05GtB9j2yW0LDTu216vKfvOYZ6h2Kym+g== =yiVo -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sion.Lloyd at nominet.org.uk Mon Nov 2 12:03:37 2009 From: Sion.Lloyd at nominet.org.uk (Sion.Lloyd at nominet.org.uk) Date: Mon, 2 Nov 2009 12:03:37 +0000 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> Message-ID: > Am I correct if I say that old KSK are currently automatically > deactivated in accordance with the rollover algorithm? > > It should only be deactivated once the user has had the chance to > publish the new DS to its parent. Shouldn't the rollover process be > a two-step rocket? > > First make a new key active. > > And then deactivate the old key on the command by the user (or any > script running on the machine) when the new DS is published. There are 3 strategies for ksk rollover described in draft-morris-dnsop-dnssec-key-timing-01 ( http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-01#section-4.3) . Should it be a configurable option as to which one the user wants? Sion From jakob at kirei.se Mon Nov 2 12:10:51 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 2 Nov 2009 13:10:51 +0100 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> Message-ID: <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> On 2 nov 2009, at 13.03, Sion.Lloyd at nominet.org.uk wrote: > There are 3 strategies for ksk rollover described in > draft-morris-dnsop-dnssec-key-timing-01 ( > http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-01#section-4.3 > ) if we do anything semi-automatic, it should be double KSK - i.e. when the new KSK is published, we have to wait for the operator to ack before removing the old KSK. double DS requires the operator to upload the DS of a not yet publish KSK to the parent, which might be a bit difficult for most operators to understand. so, I hope we do double KSK with manual confirm before removing the old KSK. jakob From Stephen.Morris at nominet.org.uk Tue Nov 3 10:22:13 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 3 Nov 2009 10:22:13 +0000 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> Message-ID: Jakob Schlyter wrote on 02/11/2009 12:10:51: > On 2 nov 2009, at 13.03, Sion.Lloyd at nominet.org.uk wrote: > > > There are 3 strategies for ksk rollover described in > > draft-morris-dnsop-dnssec-key-timing-01 ( > > http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-01#section-4.3 > > ) > > if we do anything semi-automatic, it should be double KSK - i.e. when > the new KSK is published, we have to wait for the operator to ack > before removing the old KSK. double DS requires the operator to upload > the DS of a not yet publish KSK to the parent, which might be a bit > difficult for most operators to understand. > > so, I hope we do double KSK with manual confirm before removing the > old KSK. > > jakob The draft actually suggests the "double RRset", which minimises the key rollover time. In this method the new KSK is added to the zone and the associated DS record submitted to the parent. After a suitable interval, the old DS record and KSK can be removed. However, that does separate the addition of the new DS record to the parent and the removal of the old one. The double KSK, although taking longer, requires only one communication with the parent when changing the DS record. What do people think - do the advantages of a single change to the parent zone outweigh the disadvantages of a longer rollover? I agree about the manual confirm bit. The earlier -00 version of the draft included an algorithm for doing a KSK rollover. (It was removed from the -01 version because it made the document too long and took the focus away from the timing issues). This algorithm noted that you can't assume that the DS record will appear in the parent, a check needs to be made for it. It does strike me that we need to get this sorted out fast though (i.e. before 1.0). In particular, the documentation should describe the steps involved in doing a KSK rollover. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Nov 3 10:33:52 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 3 Nov 2009 11:33:52 +0100 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> Message-ID: <983F17705339E24699AA251B458249B51F19447451@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > It does strike me that we need to get this sorted out fast though (i.e. > before 1.0). In particular, the documentation should describe the > steps involved in doing a KSK rollover. I was having a look on the documentation for the KSK rollover. You can issue to command but there is more to it. We are lacking the possibility to notify the system that it is safe to deactivate the old KSK. So my statement is that there is no fully automatic solution for KSK rollover. Since we need interaction with our parent. Or in the case of the root, you need to distribute the new trust anchor. Before we can deactivate the old KSK. But OpenDNSSEC do act as if there KSK process is fully automatic... I think that you never can solve this by using a timer. E.g. a configurable time interval for the DS distribution. We need a command for this. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvAHEOCjgaNTdVjaAQgNVAgApxTtibhTDsU8FuO+TM2IXs5R1r+cHwWH PRoTCT+1cSUfucTnudxFTaYIv2diGY5/OjgBnNbzg3+DPplFPbiBS7RNNSMrJFi/ NFA4bjUSydE+x2xvLTg/N2Kx6Nkl9fCvxLmqDG9Wp542QOYMaKcseDoANFilm0kC osm/0sPhIhBMD0HNW0zkQS4sF5L3CWekyTiN3i07pc5gRXG6l7saOKheVR6ZRDRT fx/Fyc+/XmbbMUER3p5YWpZr0h2zxzLXQCQceFnmcoT9nW3rebaOf5+TNJ1pdbdA /gEBMRKYJ9nXw9UK6Uu7yaRqo2Ey8FusVn30qEal7pPNmI+/CyFasg== =H3UV -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Morris at nominet.org.uk Tue Nov 3 12:04:13 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 3 Nov 2009 12:04:13 +0000 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: <983F17705339E24699AA251B458249B51F19447451@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> <983F17705339E24699AA251B458249B51F19447451@EXCHANGE2K7.office.nic.se> Message-ID: Rickard Bellgrim wrote on 03/11/2009 10:33:52: > > It does strike me that we need to get this sorted out fast though (i.e. > > before 1.0). In particular, the documentation should describe the > > steps involved in doing a KSK rollover. > > I was having a look on the documentation for the KSK rollover. You can issue > to command but there is more to it. We are lacking the possibility to notify > the system that it is safe to deactivate the old KSK. > > So my statement is that there is no fully automatic solution for KSK rollover. > Since we need interaction with our parent. Or in the case of the root, you > need to distribute the new trust anchor. Before we can deactivate the old KSK. > > But OpenDNSSEC do act as if there KSK process is fully automatic... > > I think that you never can solve this by using a timer. E.g. a configurable > time interval for the DS distribution. > > We need a command for this. > > // Rickard The problem with a fully-automated system here is that although OpenDNSSEC can start publishing the new KSK in the zone, it has no way of knowing whether the DS record has been submitted to the parent (or even that the KSK rollover has been noticed by the operator). I would suggest that the following requires a minimum amount of work to the enforcer: a) New KSK is introduced into the zone automatically and messages appears in the logs. (This already happens.) b) At some time, the new key moves into the "active" state and the old key into a "retire" state. In these states, both keys continue to be published. However, the enforcer is altered so as to set the amount of time the KSK stays in the "retire" state to some very large value. c) The operator is required to acknowledge that the DS record has appeared in the parent. This new command resets the retire time of the KSK to: max(TTL of record in parent zone + estimate of propagation delay through parent zone, TTL of record in this zone + estimate of propagation delay through this zone) + safety margin d) The old KSK is not removed until the retire time has expired. (In other words, we protect the user by keeping the old KSK in the zone for long enough to guarantee that the old DS and DNSKEY RRsets have expired from all validators.) (Note that step (c) may occur before step (b), in which case step (b) should not reset the retire time.) Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Tue Nov 3 12:06:27 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 3 Nov 2009 13:06:27 +0100 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> Message-ID: <03DC174E-85B4-495F-B6EF-B885E0E0805A@kirei.se> On 3 nov 2009, at 11.22, Stephen.Morris at nominet.org.uk wrote: > The draft actually suggests the "double RRset", which minimises the > key rollover time. In this method the new KSK is added to the zone > and the associated DS record submitted to the parent. After a > suitable interval, the old DS record and KSK can be removed. > However, that does separate the addition of the new DS record to the > parent and the removal of the old one. The double KSK, although > taking longer, requires only one communication with the parent when > changing the DS record. What do people think - do the advantages of > a single change to the parent zone outweigh the disadvantages of a > longer rollover? a single interaction with the parent seems easiest to me and involves few manual steps. jakob From Stephen.Morris at nominet.org.uk Tue Nov 3 12:26:17 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 3 Nov 2009 12:26:17 +0000 Subject: [Opendnssec-develop] Speaking at the IEPG Message-ID: Just to let you know that following our teleconference last Friday, I managed to get a slot at the IEPG meeting in Hiroshima to talk about OpenDNSSEC. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Nov 3 13:28:38 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 3 Nov 2009 14:28:38 +0100 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> <983F17705339E24699AA251B458249B51F19447451@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B51F194474B6@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > The problem with a fully-automated system here is that although > OpenDNSSEC can start publishing the new KSK in the zone, it has no way > of knowing whether the DS record has been submitted to the parent (or > even that the KSK rollover has been noticed by the operator). > > I would suggest that the following requires a minimum amount of work to > the enforcer: > > a) New KSK is introduced into the zone automatically and messages > appears in the logs. (This already happens.) > b) At some time, the new key moves into the "active" state and the old > key into a "retire" state. In these states, both keys continue to be > published. However, the enforcer is altered so as to set the amount of > time the KSK stays in the "retire" state to some very large value. > c) The operator is required to acknowledge that the DS record has > appeared in the parent. This new command resets the retire time of the > KSK to: > > max(TTL of record in parent zone + estimate of propagation delay > through parent zone, > TTL of record in this zone + estimate of propagation delay > through this zone) + > safety margin > > d) The old KSK is not removed until the retire time has expired. (In > other words, we protect the user by keeping the old KSK in the zone for > long enough to guarantee that the old DS and DNSKEY RRsets have expired > from all validators.) > > (Note that step (c) may occur before step (b), in which case step (b) > should not reset the retire time.) +1 So we are missing step c (and the large value part of b) in OpenDNSSEC. Which I think we need before v1.0. Should I create a Pivotal story about this? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvAwBuCjgaNTdVjaAQjRSgf+MOoK0cbLUJYjvoN90DVMLkKeRWnsCsCn g+hY1Yn1Rr5A2nkM6C3YYo0mCaX54IIie6SBxjpponLBph56T/Q1d/2tmYNcuqZR Tltmk2+GU9z/+g9rCMf8iJnJeccOwjNb9LY3za9pNXuleOy5lAbRkJGIRGPR9Uog d2yOLhhrdZWhgUXFP/9rcJ9Z0p2mTI7X5msCI7DBURx2V3dc6Z9kKVnXcAtpczCF /yKnO2hS53H9hlD7iTldKkKSrdv8qPYGeRFNblWsoPRpNfnzCEiglI5Tw4eVn1t4 afe22W1rgtDmDJp/GNyvA0YVpPjOBh3fHKx7izcVMRT5Ys0xbWdnkA== =iJZ7 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Thu Nov 5 06:03:53 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 5 Nov 2009 06:03:53 +0000 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: <983F17705339E24699AA251B458249B51F194474B6@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> <983F17705339E24699AA251B458249B51F19447451@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B51F194474B6@EXCHANGE2K7.office.nic.se> Message-ID: > So we are missing step c (and the large value part of b) in > OpenDNSSEC. Which I think we need before v1.0. So this is what I am going to do: 1) Change the default time that a KSK is in the retire state to INT_MAX - 1 2) Create an ods-ksmutil command ("ds removed --zone "? do we need a --policy version?) this will set the dead time to: "now" + max(TTL of record in parent zone + estimate of propagation delay through parent zone, TTL of record in this zone + estimate of propagation delay through this zone) + safety margin Note that all of these variables are already part of the kasp.xml. I'm assuming that if a key is rolled manually then "ods-ksmutil ds removed" will still be called at some point. If anything here surprises you, or if you think that I have left anything out then please let me know. Sion From rickard.bellgrim at iis.se Thu Nov 5 06:28:00 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 5 Nov 2009 07:28:00 +0100 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> <983F17705339E24699AA251B458249B51F19447451@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B51F194474B6@EXCHANGE2K7.office.nic.se> Message-ID: <55E7815F-A5CC-47C2-BA44-2276B7F6F859@iis.se> I think we also need a policy version for those with many zones. What will happen if you roll the key and there is no ready-key? The user takes the prepublished key and add this as a ds. Gives the ds command before the new key is ready. Will it still work? Just so that the algorithm works as intended. And that we retire the old key when we should do it and not prematurely. 5 nov 2009 kl. 07.05 skrev "sion at nominet.org.uk" : >> So we are missing step c (and the large value part of b) in >> OpenDNSSEC. Which I think we need before v1.0. > > So this is what I am going to do: > > 1) Change the default time that a KSK is in the retire state to > INT_MAX - 1 > 2) Create an ods-ksmutil command ("ds removed --zone "? do we > need a > --policy version?) > this will set the dead time to: > > "now" + max(TTL of record in parent zone + estimate of propagation > delay > through parent zone, TTL of record in this zone + estimate of > propagation > delay through this zone) + safety margin > > Note that all of these variables are already part of the kasp.xml. > > I'm assuming that if a key is rolled manually then "ods-ksmutil ds > removed" > will still be called at some point. > > If anything here surprises you, or if you think that I have left > anything > out then please let me know. > > Sion > From sion at nominet.org.uk Thu Nov 5 07:24:40 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 5 Nov 2009 07:24:40 +0000 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: <55E7815F-A5CC-47C2-BA44-2276B7F6F859@iis.se> References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> <983F17705339E24699AA251B458249B51F19447451@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B51F194474B6@EXCHANGE2K7.office.nic.se> <55E7815F-A5CC-47C2-BA44-2276B7F6F859@iis.se> Message-ID: > I think we also need a policy version for those with many zones. > > What will happen if you roll the key and there is no ready-key? The > user takes the prepublished key and add this as a ds. Gives the ds > command before the new key is ready. > > Will it still work? Just so that the algorithm works as intended. And > that we retire the old key when we should do it and not prematurely. Should we allow them to "remove" the ds record of an active key? If we are asked to retire a key and there is no ready key to take over what we do now is set the retire time to be now, but it will not actually move until there is a key in the ready state. So we could make the dead time equal to the ready time of the replacement key + max(...) + safety? Or we could throw an error. If "ds remove" is called on a zone with no retired key should I take that as an instruction to roll the key? From rickard.bellgrim at iis.se Thu Nov 5 13:44:07 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 5 Nov 2009 14:44:07 +0100 Subject: [Opendnssec-develop] Deactivating old KSK In-Reply-To: References: <983F17705339E24699AA251B458249B51F1944728C@EXCHANGE2K7.office.nic.se> <989CE768-E9F9-4A4F-8A48-240B79ECA000@kirei.se> <983F17705339E24699AA251B458249B51F19447451@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B51F194474B6@EXCHANGE2K7.office.nic.se> <55E7815F-A5CC-47C2-BA44-2276B7F6F859@iis.se> Message-ID: <983F17705339E24699AA251B458249B51F19447881@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Should we allow them to "remove" the ds record of an active key? If we > are > asked to retire a key and there is no ready key to take over what we do > now > is set the retire time to be now, but it will not actually move until > there > is a key in the ready state. I did not read the last message so closely, but shouldn't the command be about notifying that you have added the new ds and not removed the old one? Because you want to have a chain-of-trust with the new ds. It does not matter that you have an old ds that do not have the corresponding ksk in the zone, right? > So we could make the dead time equal to the ready time of the > replacement > key + max(...) + safety? Or we could throw an error. > > If "ds remove" is called on a zone with no retired key should I take > that > as an instruction to roll the key? The algorithm you proposed earlier: "now" + max(TTL of record in parent zone + estimate of propagation delay through parent zone, TTL of record in this zone + estimate of propagation delay through this zone) + safety margin You should also have: If "ready time" > "now" then use "ready time" in the algo above. This will happen if you say to the system that you have added the new ds before the new key is ready. Correct me if I am wrong... // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvLWp+CjgaNTdVjaAQhkDggAnQhVrYRBWmmyTN8oYHPlV1Hw07q9iMYZ hwmDKBM7ny7peVwi2F1W2CtqOC4PWPAHgQcsTZJYEZfGs3metzl91TVKaSo9ZA2b w45F8Svzv+jSIdRfZVV1Sw05Hq41dV6IPJw7yBwJPNKeOEiD/E3vDr8aWJY785Qt RofQpvHmmkWyQGqsSQ8oBJrRL8Edk2sjGR0L5Gz8O8GeKs7UJGd/sUD86L4H/Kyz y4L5ur+/z8ADky9pgeAh7W8YB1kYNcB9Op7RUM1tFC9WUg3NQY81Sk2l5excv5UB 6hPPRm6Ljh9jiV0F/PSljvD5wNYPW6czUWHfhAO/PmjFRbIBit7AbA== =4QsE -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Mon Nov 9 06:12:17 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 9 Nov 2009 06:12:17 +0000 Subject: [Opendnssec-develop] KSK rollover - current plan Message-ID: Stephen and I have come up with this plan for KSK rollover. We can add alternate schemes post version 1... Replacement key is pre-published as before. When we see that a key is about to retire, provided that there is one key in the ready state issue the "submit DS" message. Keep issuing this message until the "DS seen" command is issued. At this time move the ready key to active, the active key to retired and schedule the dead time of the retired key. Rollover if standby key is ready just sets estimated retire time to now, rollover if standby key is not ready sets estimated retire time to now, but nothing happens until the ready time of new key... just as it does now. DS seen command will look like: ods-ksmutil key ds-seen --keytag (if keys are shared then we will ask if it has been seen in parents of all zones that use the key [y/N] ) Then, provided that the keytag supplied matches a KSK in the ready state then the process can continue. I'm going to go ahead and start writing this in so can you give any feedback ASAP please? Sion From rickard.bellgrim at iis.se Mon Nov 9 09:49:48 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 9 Nov 2009 10:49:48 +0100 Subject: [Opendnssec-develop] KSK rollover - current plan In-Reply-To: References: Message-ID: <983F17705339E24699AA251B458249B51F19447B71@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Stephen and I have come up with this plan for KSK rollover. We can add > alternate schemes post version 1... > > > Replacement key is pre-published as before. > > When we see that a key is about to retire, provided that there is one > key > in the ready state issue the "submit DS" message. > > Keep issuing this message until the "DS seen" command is issued. > > At this time move the ready key to active, the active key to retired > and > schedule the dead time of the retired key. > > > Rollover if standby key is ready just sets estimated retire time to > now, > rollover if standby key is not ready sets estimated retire time to now, > but > nothing happens until the ready time of new key... just as it does now. Algorithm looks ok. > DS seen command will look like: > > ods-ksmutil key ds-seen --keytag > > (if keys are shared then we will ask if it has been seen in parents of > all > zones that use the key [y/N] ) > > Then, provided that the keytag supplied matches a KSK in the ready > state > then the process can continue. > > > I'm going to go ahead and start writing this in so can you give any > feedback ASAP please? Do you need to use the keytag? Won't the system know which keys we are talking about when using either --zone or --policy? If we must use the keytag, can we handle keytag collisions? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvflvOCjgaNTdVjaAQjzzAf/X7vZHXxfwj8r4x084VCFvcr2755gjeH7 YwNni2sHAm7xqKIdUZPA5dTq8I387w3JC+phy5ltEx5Nf/fgXxTiCbS83Jq9TrQp Z+vIPH+1Z1BxKI41vl0Ah4EM7Ayl6hn2jc9nbazWw3eAqaEEYQPNLiArXQOK92Ti 8nFSNIM00Jh2N4GgdGRkOETauCVXHN5xvvjTqqJPrJt62rfR/sbrTWpXVTk9qWF7 khGBi392osfeRDMrCTU6QnP20J3fvnebW2Wp6QcVhwt4u3W8PIKm8RIooKsH/b0g sfagMLbAZqF/gDmUVmwa73MtLin71Xv0IkuUCxnO0I1rQje2r9YPSw== =rZkv -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Mon Nov 9 14:40:33 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 9 Nov 2009 15:40:33 +0100 Subject: [Opendnssec-develop] Fwd: GOST support Message-ID: <983F17705339E24699AA251B458249B51F19447C60@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Here are some info from the Botan developer: > > I will be starting with version 2 of SoftHSM in the beginning of > > next year. My question is regarding your view on GOST support in > > Botan. Is there any possibility to have this within 5 months? > > This definitely seems possible. The GOST block cipher and hash > function are already implemented in 1.8, so the remaining piece is the > signature algorithm. There is an i-d that partially specifies it > (draft-dolmatov-cryptocom-gost34102001-05.txt) though it is missing > the method of key generation; presumably I can reverse engineer that > portion from the GOST 34.10 code in OpenSSL, which was also written by > Cryptocom IIRC. > > I'm not certain if it will be viable to introduce 34.10-2001 support > in the existing 1.8 stable version; for instance if adding support for > it requires changing something in a way that would break the ABI. So > it may be the case that it would only be available in the 1.9 > development releases. On the other hand it may be reasonable to > release a new stable tree as 1.10 around April-May of next year > anyway. > > -Jack -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvgp4eCjgaNTdVjaAQjuBwgAnMGQo95OMDhoEdSVhnZX5jPbFhi2QV8m h6AxeYeoPQc5zKS19VkY1YN+HysPdmit1+YoY68pAt855SHP34ZzfdMmGGZDvorF LI1Cok1MZUh11dBOvN7op/9kdi5wJTYQI8hpGA9lbCt8YTJZ96cb6BRI+nDe4YED ugcOvyycTU592dpcck3FPxrk70PdxzPK5wDD6QDc/GHYL+69sMhK5Sjgu+eHI5Vo b0HMRyadtSu46/hqzwkFoTHXXb741no85SwoLqTh8zSdRNVD2BWUzWaWU/vN4o4S GLqB38uM+tGtxZ86M7n/ka/4al69qVmRNb9sir93tt2+6QGgHfElVQ== =eeYC -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Mon Nov 9 14:55:27 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 09 Nov 2009 14:55:27 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #56: NSEC signatures created with algorithm 7 instead of 5 Message-ID: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> #56: NSEC signatures created with algorithm 7 instead of 5 -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: -------------------------------+-------------------------------------------- I'm not sure if this is a bug and it's a only cosmetic really - if NSEC signatures are used the algorithm in the zonefile is stated as being 7 and not 5... www2.tom-nsec. 3600 IN NSEC www3.tom-nsec. A RRSIG NSEC www2.tom-nsec. 3600 IN RRSIG NSEC 7 2 3600 20091109145859 20091109144345 32504 tom-nsec. jz773JcEeCqi0IUR---snip--- ;{id = 32504} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Nov 9 15:03:49 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 09 Nov 2009 15:03:49 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #56: NSEC signatures created with algorithm 7 instead of 5 In-Reply-To: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> References: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> Message-ID: <065.692fda20a4096f90fadaa287d9af961b@kirei.se> #56: NSEC signatures created with algorithm 7 instead of 5 -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Comment(by rb): What does your KASP say? Have a look under -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Tue Nov 10 00:28:04 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 10 Nov 2009 00:28:04 +0000 Subject: [Opendnssec-develop] KSK rollover - current plan In-Reply-To: <983F17705339E24699AA251B458249B51F19447B71@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F19447B71@EXCHANGE2K7.office.nic.se> Message-ID: > Do you need to use the keytag? Won't the system know which keys we > are talking about when using either --zone or --policy? > > If we must use the keytag, can we handle keytag collisions? I was thinking that there may be more than one key in the ready state for any given zone/policy... If there is a keytag collision then I was going to report back with the cka_ids involved and give the option of either one? Sion From sion at nominet.org.uk Tue Nov 10 06:33:04 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 10 Nov 2009 06:33:04 +0000 Subject: [Opendnssec-develop] KSK rollover - current plan In-Reply-To: References: <983F17705339E24699AA251B458249B51F19447B71@EXCHANGE2K7.office.nic.se> Message-ID: One extra question about this new scheme. Should there be any difference in behaviour between KSK rollovers if the policy is marked with the tag? Sion From jakob at kirei.se Tue Nov 10 07:24:57 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 10 Nov 2009 16:24:57 +0900 Subject: [Opendnssec-develop] KSK rollover - current plan In-Reply-To: References: <983F17705339E24699AA251B458249B51F19447B71@EXCHANGE2K7.office.nic.se> Message-ID: <65F039FA-575B-4D08-9586-E49471B3646D@kirei.se> On 10 nov 2009, at 15.33, sion at nominet.org.uk wrote: > One extra question about this new scheme. > > Should there be any difference in behaviour between KSK rollovers if > the > policy is marked with the tag? could you redescribe what happens now when you do a KSK rollover? what is logged, what happens when you do 'ods-ksmutil key rollover --zone foo --keytype KSK' etc. jakob From rickard.bellgrim at iis.se Tue Nov 10 08:31:25 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 10 Nov 2009 09:31:25 +0100 Subject: [Opendnssec-develop] KSK rollover - current plan In-Reply-To: References: <983F17705339E24699AA251B458249B51F19447B71@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B51F19447D9E@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > Do you need to use the keytag? Won't the system know which keys we > > are talking about when using either --zone or --policy? > > > > If we must use the keytag, can we handle keytag collisions? > > I was thinking that there may be more than one key in the ready state > for > any given zone/policy... If there is a keytag collision then I was > going to > report back with the cka_ids involved and give the option of either > one? > > Sion Sounds reasonable. This means that the user is handling the key and not the zone. The user must thus make sure that it has uploaded the DS records for all of the zones that are sharing this key before giving this command. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvkk3eCjgaNTdVjaAQhuwQgAg3nXItJsmrmeDITLGaKIXtW9PGIBgOw+ 5F6O5XT6Zbf/hR3fc5ZLbyxxox3x7QrSR1WqcgSmCxKxdGYpTlK3Vs5967/SVYVA a+d47omUMF6O6cxbj0iLc/p3rInZurGkp9FGtEMpb4xnMKU2X7TbWrUtqVN/yI7I UXk5gvb/8fz3ChAIqBOxQrqGgsF1bR+SIo2QD4diUeXZcDUyNCN/vvF7gi4HS9Ok RZ2wGUGo9KyBNCqgruRXlo/aaQzLAc/z9JrffvZcxY6gJRuuZ3zlp6Y6Z2KlX5uN XvgiO4ahTtLzKxqhlEog1IBdctOYznWXMI8ZIy/KDLZlvOsINDWFQw== =8DRs -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Nov 10 09:27:12 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 10 Nov 2009 10:27:12 +0100 Subject: [Opendnssec-develop] KSK rollover - current plan In-Reply-To: References: <983F17705339E24699AA251B458249B51F19447B71@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B51F19447E00@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > One extra question about this new scheme. > > Should there be any difference in behaviour between KSK rollovers if > the > policy is marked with the tag? Both the manual and automatic KSK rollover requires the DS command. The only difference when you have is that the user must give the "key rollover" command and then the DS command. The introduction of the DS command will do the same action as the for the KSK. When we introduce the need for the DS command, then the rollover process will stop at the same point as when we have the in the policy of the KSK. Right? The tag is still useful if you e.g. want to roll the ZSK the first of each month by using a cronjob. But the question is if is useful anymore for the KSK? Scenario: The rollover is initiated today, but we were not able to give the DS command until one week later. We still want the rollover to happen on the same date next year, and not shifted one week. Expected result: The rollover date will be one week later next year, because our policy said that a key is valid one year. Scenario next year: If we only use the DS command, then the rollover will be completed one week late. But if we first give the "key rollover" command on the expected date. Then we are able to complete the rollover with the DS command on the expected date. So my question: Can you safely give the "key rollover" command even though OpenDNSSEC has automatically initiated the rollover? Or is this the case when you should have the for the KSK, so that you won't get a double rollover? Another question: Shouldn't it be possible to give the DS command even though the key is only published and not ready? OpenDNSSEC gets the notification from the user, but will wait until it is ready and then complete the rollover process. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvkx8OCjgaNTdVjaAQjTVQgAhSbWye4rwzHVSnAB8A0r3u9zZCEF/YSq MAQOEnm8qHLrJI3EN4ML0+oTkud/+lJ7j9bfdd9YtTZkSxzPYr2D9u9/HOjHmAee XKZUyxEpFNF/0+GMwow3ffWJzg4jbuNmQ/CM4XAFeG09oF1x4dmth61b+auPJWvb U/GT0AJZaGeM/vNfVRJdhnNNq3VgXXvhFsdr04lIgenzwvATrcnfSPkQkMmag4RM bdkij2+XOTbnUY0OtGdWesnBweskF8OtM5wfKZLyfrhNNSgoFWhXj0vYCl8qT84k UawJ/9e86J9tcpGrvefGJ5UdMw7ljLO9yeVJ+pU6LUzUDs/NUxNXUg== =8LxA -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Nov 10 10:35:17 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 10 Nov 2009 11:35:17 +0100 Subject: [Opendnssec-develop] Release of 1.0 Message-ID: <983F17705339E24699AA251B458249B51F19447E6C@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi We are getting closer to our release date. We fixed the stability issues, but then it popped up some problems with RR being dropped. We also have the KSK rollover process that needs to be complemented. How do you feel? Can we do this? Do we have time to fix these issues this week? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBUAwUBSvlB5eCjgaNTdVjaAQjzHgf44PoZppb6L9HX6+5SGV5vdmU4pIryAJXS 8PLOa0CvqvyEpjseugxc9BZor5fSpJfcoa5VgoZ5xMfdPwTOZyGrUGnkhYjKcku9 kieMtryrHKyEHbgSv3eRtyA0+XOBlErd8s7HVdfA41/MdW9+AXP6jd7tOsSCcOCx 1SSFci1j847HdhoZjVI2VG6rPFniGy+16SE8Y5svkmeoHjoelNdQ7XvzcM2/ujQC xMy75k0Foo6jhzbHSaDXLlXODwMDWx9NdGd9WPYT/tIFyUhW3+lYfgUy62FnsCud E70A9kcMmiXCMsiCIhVeWYDi/5NCXcmU+nZmbOtQ2EVjvX6masFO =xoKd -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Tue Nov 10 13:49:32 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Nov 2009 13:49:32 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.d43c44451e43d0d8031106fe4d08a44c@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by matthijs): I have made the RRset comparing hash-aware. I believe this solves your issue. Could you please try r2434? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 10 13:53:41 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Nov 2009 13:53:41 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #56: NSEC signatures created with algorithm 7 instead of 5 In-Reply-To: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> References: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> Message-ID: <065.f6d1cb5d9d989820bd3a91607061c5ba@kirei.se> #56: NSEC signatures created with algorithm 7 instead of 5 -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: matthijs Type: defect | Status: accepted Priority: minor | Component: Signer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Changes (by matthijs): * status: new => accepted Comment: And RRSIGs over other RRsets are created with 5? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 10 14:47:38 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Nov 2009 14:47:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #56: NSEC signatures created with algorithm 7 instead of 5 In-Reply-To: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> References: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> Message-ID: <065.8036cf80c22d6f298437cdfee984ce95@kirei.se> #56: NSEC signatures created with algorithm 7 instead of 5 -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: matthijs Type: defect | Status: accepted Priority: minor | Component: Signer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Comment(by matthijs): By the way, I would be happy to see the unsigned zone and the signconf file attached. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 10 15:27:20 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Nov 2009 15:27:20 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #56: NSEC signatures created with algorithm 7 instead of 5 In-Reply-To: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> References: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> Message-ID: <065.479a3d08df4c740c5013e63b848f57a7@kirei.se> #56: NSEC signatures created with algorithm 7 instead of 5 -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: matthijs Type: defect | Status: accepted Priority: minor | Component: Signer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Comment(by tom@?): Ok, my ZSK was using 7 (and all other RRSIGs are 7 too). It seems that the change to the policy was being ignored by 'ksmutil update' - I have to do a 'ksmutil setup'. Maybe this is a silly thing to do though. Feel free to close if you think this is user-error. Tom -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 10 15:39:33 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Nov 2009 15:39:33 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #56: NSEC signatures created with algorithm 7 instead of 5 In-Reply-To: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> References: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> Message-ID: <065.c4dec838198ce8b5701de4c159db9bed@kirei.se> #56: NSEC signatures created with algorithm 7 instead of 5 -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: matthijs Type: defect | Status: accepted Priority: minor | Component: Signer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Comment(by rb): "ods-ksmutil update" do update the algorithm number. But you still have you old keys, which will be used until the next rollover. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 10 15:42:09 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Nov 2009 15:42:09 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #56: NSEC signatures created with algorithm 7 instead of 5 In-Reply-To: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> References: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> Message-ID: <065.f588f4e6b15c66370d8b1318c16ce588@kirei.se> #56: NSEC signatures created with algorithm 7 instead of 5 -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: matthijs Type: defect | Status: accepted Priority: minor | Component: Signer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Comment(by rb): And if you have standby keys, then they also have to be rolled out before you get a key with this new algorithm. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Tue Nov 10 21:52:29 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Nov 2009 06:52:29 +0900 Subject: [Opendnssec-develop] Release of 1.0 In-Reply-To: <983F17705339E24699AA251B458249B51F19447E6C@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F19447E6C@EXCHANGE2K7.office.nic.se> Message-ID: <62ACF129-D2C0-415D-9B94-594BCA6FECBD@kirei.se> On 10 nov 2009, at 19.35, Rickard Bellgrim wrote: > We are getting closer to our release date. We fixed the stability > issues, but then it popped up some problems with RR being dropped. > We also have the KSK rollover process that needs to be complemented. > > How do you feel? Can we do this? Do we have time to fix these issues > this week? I strongly recommend we have one full week of no critical bugs before we release 1.0 (I want one month, by I guess that is not an option at this point...). When I look at the tracker right, it doesn't look good. jakob From roland.vanrijswijk at surfnet.nl Wed Nov 11 09:09:46 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 11 Nov 2009 10:09:46 +0100 Subject: [Opendnssec-develop] Release of 1.0 In-Reply-To: <62ACF129-D2C0-415D-9B94-594BCA6FECBD@kirei.se> References: <983F17705339E24699AA251B458249B51F19447E6C@EXCHANGE2K7.office.nic.se> <62ACF129-D2C0-415D-9B94-594BCA6FECBD@kirei.se> Message-ID: <4AFA7F5A.1090800@surfnet.nl> +1 And kudos to you all for all the hard work, very impressive! (looking from the sideline) I got some really positive feedback from people in the Terena community! Cheers, Roland Jakob Schlyter wrote: > On 10 nov 2009, at 19.35, Rickard Bellgrim wrote: > >> We are getting closer to our release date. We fixed the stability >> issues, but then it popped up some problems with RR being dropped. We >> also have the KSK rollover process that needs to be complemented. >> >> How do you feel? Can we do this? Do we have time to fix these issues >> this week? > > I strongly recommend we have one full week of no critical bugs before we > release 1.0 (I want one month, by I guess that is not an option at this > point...). When I look at the tracker right, it doesn't look good. > > 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 owner-dnssec-trac at kirei.se Wed Nov 11 09:29:54 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 11 Nov 2009 09:29:54 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #56: NSEC signatures created with algorithm 7 instead of 5 In-Reply-To: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> References: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> Message-ID: <065.abc277e259a4af8fb64d64f7fce13f32@kirei.se> #56: NSEC signatures created with algorithm 7 instead of 5 -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: sion Type: defect | Status: assigned Priority: minor | Component: Signer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Changes (by matthijs): * owner: matthijs => sion * status: accepted => assigned Comment: Replying to [comment:4 tom@?]: > Ok, my ZSK was using 7 (and all other RRSIGs are 7 too). It seems that the change to the policy was being ignored by 'ksmutil update' - I have to do a 'ksmutil setup'. Maybe this is a silly thing to do though. > > Feel free to close if you think this is user-error. > > Tom I leave it up to sion if he thinks this is a ksmutil bug or user error;) -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Wed Nov 11 10:14:32 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 11 Nov 2009 11:14:32 +0100 Subject: [Opendnssec-develop] 5000 zones - almost possible Message-ID: <983F17705339E24699AA251B458249B51F1960082B@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Have done some testing with 5000 zones and the default policy + shared keys + NSEC. Using the ods-ksmutil to add zones. The first 1000 zones are quickly added, but then it gets slower and slower. When you get to the 5000th zone, you can add around 1-2 zone per second. When I have added the zones, I first start the Signer Engine. This takes around 3 seconds before I can type the next command. And then I start the Enforcer. The Enforcer creates the KSK and ZSK + standby keys (total 4 keys). And after this, it start creating the zone configurations. But the Enforcer freezes on the first zone with this as the last line in the syslog "Config will be output to /home/rickard/opendnssec/config/1suffix.org.xml". Then after a minute or so, it starts to write the zone configurations. First, only 10 configurations are created. Probably because the Signer Engine is stealing some CPU. But after a moment more are continuously created. I am running MySQL, and the ods-ksmutil is very responsive. Even though the Enforcer is working with the zones. Which is great! I forgot to disable the Auditor. So it was used before outputting the signed zones. This locked all of the worker threads and the auditor just eat up memory and CPU. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 24787 rickard 20 0 108m 105m 1476 R 25 10.4 4:14.19 ods-auditor 24948 rickard 20 0 108m 105m 1476 R 25 10.4 4:09.29 ods-auditor 24810 rickard 20 0 108m 105m 1476 R 25 10.4 4:13.12 ods-auditor 24852 rickard 20 0 108m 105m 1476 R 25 10.4 4:11.65 ods-auditor 24879 rickard 20 0 108m 105m 1476 R 25 10.4 4:11.55 ods-auditor 24902 rickard 20 0 108m 105m 1476 R 25 10.4 4:11.18 ods-auditor 24925 rickard 20 0 108m 105m 1476 R 25 10.4 4:10.52 ods-auditor 24856 rickard 20 0 108m 105m 1476 R 25 10.4 4:11.92 ods-auditor Stop everything and restart with the Auditor disabled. All of the configurations are created after 40 minutes. And the Signer Engine is not so far behind, only 1 minute. What I also can see is that ods-enforcerd is eating more and more memory. Memory leaks? From a small program to 526 MB in the memory. Ok, now we have done the first round of generating zone configurations. Then the second round. It goes through the zones one by one. This takes around 4 minutes. But the memory usage was doubled to 1 GB. What I can see is that OpenDNSSEC v1.0.0 is not suitable for handling a large number of zone, because of the time scales and memory problems. Conclusions: * MySQL makes the ods-ksmutil more responsive. * The auditor should not be used when signing a large number of zones. * ods-enforcerd has some problems with memory leaks. * OpenDNSSEC v1.0.0 cannot be used for signing a large number of zones. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvqOiOCjgaNTdVjaAQjfhwf/dY/X59PRODEAWqAAsLlueQV0yGmWkz80 bljjEocK3a9ldhbFCMhBPEhRNReYHEOnHaNY2oQnM8EP1cw3hKMcvtgTRhRlmbvE SNt2RX2Au8/pqj85bURa0Y0hd5d9CPb+QtOt8zS87znbA1fvKeV8moNfodhpLWSd 87W3brEdVDTGfwhNHFDlmegAA327dGlKxJgY504wollH+bAuyb/1OAgnZXOar++W gSw1CfeMXKx5B54Z6GskxGZoL0wfL8IBWKpVV71xMGiWXClsUtpGlgTPWhdbuBlJ R5BT2oCXR1SeevLMrkZyTeoibzfCL0bhztuA3hZ6s2PpUErfL6N8Pw== =qOOv -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Wed Nov 11 10:31:59 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 11 Nov 2009 10:31:59 +0000 Subject: [Opendnssec-develop] 5000 zones - almost possible In-Reply-To: <983F17705339E24699AA251B458249B51F1960082B@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F1960082B@EXCHANGE2K7.office.nic.se> Message-ID: > I forgot to disable the Auditor. So it was used before outputting > the signed zones. This locked all of the worker threads and the > auditor just eat up memory and CPU. Currently, one instance of the auditor is started per zone by the signer engine. This results in a new Ruby VM for each zone. The auditor was written to audit all the zones in the zonelist.xml (sequentially) in one Ruby VM. I'd have thought that this would help the resource problem quite considerably. I'm not sure how easy it would be to change the system to call the auditor on a batch of zones (rather than on single zones). Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Nov 11 12:21:22 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 11 Nov 2009 12:21:22 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.5ff5c6af43ae2ab2252c6c6f72d65ae2@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by tom@?): I'm still seeing similar issues (although it does seem to have improved). I've attached my zonefile. My current config uses the following hash.... 1 5 a2e1ebfb9da0e46a When I sign this zone and then remove www3, www4 and www5 I see errors. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 11 12:38:13 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 11 Nov 2009 12:38:13 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.d77f1fcd4c6672f925253f1c816652ec@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by matthijs): Works for me: less tom | grep -v RRSIG | grep -v NSEC ; Signed on 2009-11-11 13:33:56 tom. 3600 IN SOA bubbles.tom.tom. root.bubbles.tom.tom. 1257942836 604800 86400 2419200 3600 www.tom. 86400 IN A 10.5.1.100 www2.tom. 86400 IN A 10.5.1.101 www6.tom. 86400 IN A 10.5.1.103 tom. 86400 IN NS bubbles.tom. tom. 3600 IN DNSKEY 257 3 7 AwEAAct5xWb2Lc4imHk9R4TTqgTos7Qh8ZNAJP20teGWdKWVrTB0eYCARTLOzYwy6PeuSoMetSIYPTCnVsbYWr41BbCqs3J6qtlJ9ym16lpj1GBNyM/Pf0rYZ/JWw/cel1XPd56zGInY8R4lL6CiTcRNL5ezQHyJvKqhoi9D5kcmltZt ;{id = 27543 (ksk), size = 1024b} ; Last refresh stats: existing: 6, removed 1, created 6 I am currently using OpenDNSSEC r2438 and ldns trunk r3115. What errors do you get? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 11 14:49:06 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 11 Nov 2009 14:49:06 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.057c754186cad3968d565d743b123fe8@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by tom@?): I am running the same versions from trunk. The auditor correctly reports that.... ods-auditor[14107]: Output zone does not contain non-DNSSEC RRSet : A, bubbles.tom.#01186400#011IN#011A#01110.5.1.110 After completely refreshing my working directory the problem went away - even with my hash. It still breaks on my large zone (now attached). If I delete any three consecutive records I hit problems. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Wed Nov 11 14:56:33 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 11 Nov 2009 15:56:33 +0100 Subject: [Opendnssec-develop] How to migrate a signed zone to OpenDNSSEC Message-ID: <983F17705339E24699AA251B458249B51F1960090F@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I am writing some text on how to migrate a signed zone to OpenDNSSEC. I believe that there are three alternatives. 1. Export the keys 2. Prepublish DNSKEY record 3. Unsign and start fresh (4. More alternative?) Does anyone of you have a good description on how to do the prepublishing method? Where you start signing the zone on a new server. Take the DNSKEY records and put them in the old name server. Etc. http://trac.opendnssec.org/wiki/Signer/Using/Migrating Thanks // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvrQoeCjgaNTdVjaAQjjlwf+KHL62SV8mSl89lxjKdrox/4vOmzMLsAH hWEBp2P2mpKOBpDSDQt2ONDxPqGtSYb4PRy2VZTT3or0M3iMcgapGk9rxisMoveK gTXQTGLIRaZrNhah+2D7lD9GL/lItMG4mO/WFIRaUN6D6N79IliVngbhBmHTuE2W xXeTRV6WKlkybxQlIqkLYvF4L/baF2JHy1gQR27yjtPmmED7Zb9Q2cHdmUotXcV1 LZg+NBXw1xE/Y6jEpA31NxKDSTGcvEM0itTpYx2tR0dZr/4gwtQ39jVxrTDP+5Tl q4SDGnQut13YoMgx/WkcS7A6bMHkEZkV9j57QVgAv2+MUJxWtJWRWg== =GnNP -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Nov 11 14:57:52 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 11 Nov 2009 14:57:52 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.1cd99eeb8bf2b0214c265012988e6bb7@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by matthijs): same signer configuration, I presume? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 11 15:09:35 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 11 Nov 2009 15:09:35 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.f3b56860327e7514917e73f5a0e0a6e1@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by tom@?): Yes, same configuration. The second attachment was rejected as spam, so I've emailed it directly. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Thu Nov 12 00:53:48 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 12 Nov 2009 00:53:48 +0000 Subject: [Opendnssec-develop] KSK rollover - current plan In-Reply-To: <983F17705339E24699AA251B458249B51F19447E00@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F19447B71@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B51F19447E00@EXCHANGE2K7.office.nic.se> Message-ID: > Both the manual and automatic KSK rollover requires the DS command. > The only difference when you have is that the > user must give the "key rollover" command and then the DS command. not _must_; it makes no real difference. > The introduction of the DS command will do the same action as the > for the KSK. When we introduce the need for the > DS command, then the rollover process will stop at the same point as > when we have the in the policy of the KSK. Right? Exactly. > The tag is still useful if you e.g. want to roll > the ZSK the first of each month by using a cronjob. But the question > is if is useful anymore for the KSK? > > Scenario: > The rollover is initiated today, but we were not able to give the DS > command until one week later. We still want the rollover to happen > on the same date next year, and not shifted one week. > > Expected result: > The rollover date will be one week later next year, because our > policy said that a key is valid one year. > > Scenario next year: > If we only use the DS command, then the rollover will be completed > one week late. > But if we first give the "key rollover" command on the expected > date. Then we are able to complete the rollover with the DS command > on the expected date. > > So my question: > Can you safely give the "key rollover" command even though > OpenDNSSEC has automatically initiated the rollover? Or is this the > case when you should have the for the KSK, so > that you won't get a double rollover? Up to the point at which you issue "ds-seen" then no key states will change, so the rollover command will apply to the current active key. _After_ you issue the ds-seen then keystates will change at some point in the future determined by your policy. I would have to think a bit more about what _will_ happen if a rollover is issued at this time, and what _should_ happen. > Another question: > Shouldn't it be possible to give the DS command even though the key > is only published and not ready? OpenDNSSEC gets the notification > from the user, but will wait until it is ready and then complete the > rollover process. Yes, I believe that this will work, it will schedule the event for some time in the future like: max(expected ready time, parent propagation etc) Sion From sion at nominet.org.uk Thu Nov 12 01:03:15 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 12 Nov 2009 01:03:15 +0000 Subject: [Opendnssec-develop] Release of 1.0 In-Reply-To: <4AFA7F5A.1090800@surfnet.nl> References: <983F17705339E24699AA251B458249B51F19447E6C@EXCHANGE2K7.office.nic.se> <62ACF129-D2C0-415D-9B94-594BCA6FECBD@kirei.se> <4AFA7F5A.1090800@surfnet.nl> Message-ID: > >> We are getting closer to our release date. We fixed the stability > >> issues, but then it popped up some problems with RR being dropped. We > >> also have the KSK rollover process that needs to be complemented. > >> > >> How do you feel? Can we do this? Do we have time to fix these issues > >> this week? > > > > I strongly recommend we have one full week of no critical bugs before we > > release 1.0 (I want one month, by I guess that is not an option at this > > point...). When I look at the tracker right, it doesn't look good. + (as many votes as I am allowed to cast) We are still fairly new to testing of the whole system, and testing by people other than the developers. Sion From sion at nominet.org.uk Thu Nov 12 01:31:11 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 12 Nov 2009 01:31:11 +0000 Subject: [Opendnssec-develop] 5000 zones - almost possible In-Reply-To: <983F17705339E24699AA251B458249B51F1960082B@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F1960082B@EXCHANGE2K7.office.nic.se> Message-ID: > What I can see is that OpenDNSSEC v1.0.0 is not suitable for > handling a large number of zone, because of the time scales and > memory problems. > > Conclusions: > * MySQL makes the ods-ksmutil more responsive. This is expected, not just because of blocking issues either, it is just faster. > * The auditor should not be used when signing a large number of zones. > * ods-enforcerd has some problems with memory leaks. I'll look into these as soon as I finish the KSK stuff; realistically this will be next week. > * OpenDNSSEC v1.0.0 cannot be used for signing a large number of zones. I have done no optimisation for large numbers of zones. A very simple one for shared keys would be to write out essentially the same file (just tweak it) for all zones. (Note that it is also doing all the timing calculations again.) Also there are no indexes on the tables, this should help. The real fun comes when you do not share keys. Sion From rickard.bellgrim at iis.se Thu Nov 12 08:15:07 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 12 Nov 2009 09:15:07 +0100 Subject: [Opendnssec-develop] 5000 zones - almost possible In-Reply-To: References: <983F17705339E24699AA251B458249B51F1960082B@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B51F196009D7@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > * ods-enforcerd has some problems with memory leaks. > > I'll look into these as soon as I finish the KSK stuff; realistically > this > will be next week. I suggest that this goes into v1.0.0, since it has to do with the stability of the system. > > * OpenDNSSEC v1.0.0 cannot be used for signing a large number of > zones. > > I have done no optimisation for large numbers of zones. A very simple > one > for shared keys would be to write out essentially the same file (just > tweak > it) for all zones. (Note that it is also doing all the timing > calculations > again.) Also there are no indexes on the tables, this should help. I suggest that this goes into v1.1.0, since we currently are ok with handling a few zones. > The real fun comes when you do not share keys. And this needs some rework of the architecture => v2.0.0 -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvvEC+CjgaNTdVjaAQgeBwf9FvuM8bqVZ5HtU2hNEYtOyJExzqK9sABq TTqmUlExJT15HZG8io+d5SKvrUSSTQkAsWSvtPi7XV7dZ7QssmJQzDfiRSrjDNGP YRbyKKcrQio/togdY7ARWk6TStNpkyTzzbKO0E8FmLsTLTOfDmx9OX50RL1nQ39X Nl5dxHrjocJ815gSX+V6pnHNKZ+f94WbCutC3VBjMEdKeYAYErd5YyGo2Xwzxu9n t6KowCX+0FDhHTrMyttMkfoanKpFE6/kg6d3my5I2RqSAam9GsgC7jLHC7yCCp0b A6x1ZxLL3ZkI62yLhUr9LtdOXnjzrxza7TpVHrMQptQOAo+nO9wELA== =pFiT -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Thu Nov 12 09:05:01 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 12 Nov 2009 09:05:01 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.4efe7eea6ab83084b28a778e3d1fa2c6@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by matthijs): Could not reproduce... I signed the large zone, removed the three aborigin* records and re-signed and that works. Did I miss something? Have you refreshed the working directory for the large zone as well (ods- signer clear tom.tld)? -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Thu Nov 12 09:51:16 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 12 Nov 2009 10:51:16 +0100 Subject: [Opendnssec-develop] Meeting 20091117 Message-ID: <983F17705339E24699AA251B458249B51F19600A5B@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Date: Tuesday 17 October Time: 11:00-12:00 CET, 10:00-11:00 GMT Draft agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2009-11-17 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvvalOCjgaNTdVjaAQiY3AgAm7Yr5M9vPme2myroBl+c0eNmWNIdcGlM Kx+okN71Zh99BBA07tLB8UUycw4chyxJuJK59/HfxC/KA34MOZyyDDk29l0JbXum RB2PhgH6V1x+v+IqJR/crMsdgYAlf+pioaBzQ58V5vNbBIsFU93ZUmKOga11k/m7 DbGfnSbYhg26sbH49u2IYIqNmw8LEFJbCZJWzso+VRltBJFzZsBCHOhQ2qnGL9z1 lwEhIDJ96H71m0HNX/Ik2dDyT6hXX65e0TUgDfLy0fpBu/6lWtl4ZY+Mhw4L2tKZ 7Uut7t7SQd0yvrGkqrxxMk//KAHC/Iq0cCOtGFs4i6kAzAm6uIU6EQ== =wBbV -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Thu Nov 12 09:58:23 2009 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 12 Nov 2009 09:58:23 +0000 Subject: [Opendnssec-develop] Meeting 20091117 In-Reply-To: <983F17705339E24699AA251B458249B51F19600A5B@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F19600A5B@EXCHANGE2K7.office.nic.se> Message-ID: <20091112095823.GA7856@phantom.vanrein.org> Hi, > Date: Tuesday 17 October > Time: 11:00-12:00 CET, 10:00-11:00 GMT November, of course :) -Rick From rickard.bellgrim at iis.se Thu Nov 12 09:58:57 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 12 Nov 2009 10:58:57 +0100 Subject: [Opendnssec-develop] Re: Meeting 20091117 In-Reply-To: <983F17705339E24699AA251B458249B51F19600A5B@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F19600A5B@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B51F19600A6D@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Sorry, not October but November. > Date: Tuesday 17 October > Time: 11:00-12:00 CET, 10:00-11:00 GMT > > Draft agenda: > http://trac.opendnssec.org/wiki/Meetings/Agenda/2009-11-17 > > // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSvvcYeCjgaNTdVjaAQi40wgAqCC62JeXvbMUD45zvgcnRYr0fUfTowQ9 GT2OdhhuA0usENEC7kkG6p2EXyvVDeoVMtaf8yTpBNM0KO68ijrxx6H0v7mF2/n9 9HPzEg8TdREAd7Q+QU8AJeqTcvNIATIWA7YiAinmwXWBq1/kgFk8OuuUSlp7jjHy WOR9y+wL97ZROWx5n5cimn8Q+d0V/ITiuMPK6fawjRLVmUc2cX8UwtyLpygW1lD8 35bYHX75G1O6uvyOD9HmN3xgZAQQjD2+uN02OGjVtj7Vd5BurCqIwVs7TZ151vys 8xC+m2I5YP90IsfNtlw5ozuCzcx6bVvYDN5D5pWiQHjWl9CZGndcLA== =+XnH -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Thu Nov 12 12:08:58 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 12 Nov 2009 12:08:58 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.ea7ecf67538a889b1b20d55c5761982a@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by alexd): I think Tom said that the problem resolved if he issued an explicit "ods- signer sign ..." command, or the signer re-signed it twice. It was just the first automatic re-sign after removing the records that failed. Are you perhaps issuing a re-sign command when trying to reproduce the problem? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Nov 12 12:34:02 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 12 Nov 2009 12:34:02 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.069215dfd0ed64682ce1bc002ff1f81c@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by matthijs): I do: > ods-signer clear tom > ods-signer sign tom - remove three records from unsigned/tom > ods-signer sign tom -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Nov 13 07:31:39 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 13 Nov 2009 07:31:39 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.a1994f2a362f0d39cde91ebe55cf6bdf@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by alexd): I have reproduced the problem on both Ubuntu and OSX, using both Tom's zone and the se. zone. I uses opendnssec 2442 and ldns 3122 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Nov 13 07:33:33 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 13 Nov 2009 07:33:33 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.3b599ec532c45be76a6a2e76abeb588d@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by matthijs): Please tell me how -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Nov 16 15:17:08 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 16 Nov 2009 15:17:08 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.37c4eff8495ce9799801aac9eb87e4e6@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by matthijs): r2462 OpenDNSSEC and r3127 LDNS does not give me any errors anymore when performing: ods-signer sign tom; - remove three records from unsigned/tom; ods-signer sign tom; No missing records, No invalid NSEC3 chain. I made a slight adaptation in the compare_list_rrset() function. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon Nov 16 16:07:01 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 16 Nov 2009 17:07:01 +0100 Subject: [Opendnssec-develop] Backup of OpenDNSSEC Message-ID: <983F17705339E24699AA251B458249B51F19601187@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The only thing you need to backup for OpenDNSSEC is the Enforcer database, right? Since the other files are static information or could be reproduced by the Enforcer once the database is restored. Is each operation from the Enforcer to the database atomic? So that you can just simple do a copy of the database with cp-command? The other thing is that your HSM needs to be backed up. E.g. with SCA6000 do you need to copy these files: /var/opt/sca/keydata/keystore-name.serial-number.{keystore-id}.conf /var/opt/sca/keydata/keystore-name.serial-number.{keystore-id}/object.db /var/opt/sca/keydata/keystore-name.serial-number.{keystore-id}/user.db But these are Berkeley DB files. Can you just copy these as well? Did try the db4.6_hotbackup command, but it could not find the db files although they are present. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSwF4peCjgaNTdVjaAQhoXAgAmvjK0aaPZFDP5TcE1sB8uCOjFIzl0Gv6 U3HGzSEn0U9ejl2WeJ1RBcNnKSg01SKdjH8Y/vUNfc1Mff8yn0s0te78X2iq4h7V ouCcD4/uKEZJ8TG/HLGxLEcT0J63kOVVuZTCR4crZpUf5PLjzHL9Eq3VAUx39OQa C2oVm0vpsRA3yCcJwInST3phDWW0NQc1jzqsQCuo/hrzJObsHtcduuduXOjcH3xt L8pfVRzVteZA4Vwnzc2ivISUoIHmpoGZhnNWZkjUl1vRkHvJeD7JNcTyYq2CIvbc vajAyiCDrtF4jWRu3kL2QxFiu+16jxIbg28r0g9ItMpL/tFApt10Bg== =Eu1y -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Tue Nov 17 08:57:38 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 17 Nov 2009 08:57:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.b0cf8388193606c248bbc341019984ee@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by tom@?): That last change seems to now work on my zonefiles. Unfortunately, I am now seeing errors when adding records to a zonefile! This started happening before this last commit... Can't follow NSEC3 loop from 9mqsojlcgp82rjugkis1r9pc9ambi6dk.tom to b2ar1uk0l6kpc45tp748bdrmn3q6lua8.tom I'll attach the zonefile as 'tom.2'. After signing this zone, I un-comment all records and I get three errors. (Using no salt and 0 iterations) -- Ticket URL: OpenDNSSEC OpenDNSSEC From Antoin.Verschuren at sidn.nl Tue Nov 17 11:27:10 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Tue, 17 Nov 2009 12:27:10 +0100 Subject: [Opendnssec-develop] How to migrate a signed zone to OpenDNSSEC References: <983F17705339E24699AA251B458249B51F1960090F@EXCHANGE2K7.office.nic.se> Message-ID: <850A39016FA57A4887C0AA3C8085F9490154FA10@KAEVS1.SIDN.local> I would say this would be excactly the same as the transfer issue from a different DNS-operator. Just feed the (signed) zone to opendnssec, and roll the key using the same process as when the zone is transferred, i.e. pre-publish. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ > -----Original Message----- > From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec- > develop-bounces at lists.opendnssec.org] On Behalf Of Rickard Bellgrim > Sent: Wednesday, November 11, 2009 3:57 PM > To: opendnssec-develop at lists.opendnssec.org > Subject: [Opendnssec-develop] How to migrate a signed zone to OpenDNSSEC > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi > > I am writing some text on how to migrate a signed zone to OpenDNSSEC. I > believe that there are three alternatives. > > 1. Export the keys > 2. Prepublish DNSKEY record > 3. Unsign and start fresh > (4. More alternative?) > > Does anyone of you have a good description on how to do the prepublishing > method? Where you start signing the zone on a new server. Take the DNSKEY > records and put them in the old name server. Etc. > > http://trac.opendnssec.org/wiki/Signer/Using/Migrating > > Thanks > // Rickard > > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBSvrQoeCjgaNTdVjaAQjjlwf+KHL62SV8mSl89lxjKdrox/4vOmzMLsAH > hWEBp2P2mpKOBpDSDQt2ONDxPqGtSYb4PRy2VZTT3or0M3iMcgapGk9rxisMoveK > gTXQTGLIRaZrNhah+2D7lD9GL/lItMG4mO/WFIRaUN6D6N79IliVngbhBmHTuE2W > xXeTRV6WKlkybxQlIqkLYvF4L/baF2JHy1gQR27yjtPmmED7Zb9Q2cHdmUotXcV1 > LZg+NBXw1xE/Y6jEpA31NxKDSTGcvEM0itTpYx2tR0dZr/4gwtQ39jVxrTDP+5Tl > q4SDGnQut13YoMgx/WkcS7A6bMHkEZkV9j57QVgAv2+MUJxWtJWRWg== > =GnNP > -----END PGP SIGNATURE----- > > From owner-dnssec-trac at kirei.se Tue Nov 17 11:40:25 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 17 Nov 2009 11:40:25 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.126b1c0fed4bc973795c97d6bbeff6f1@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by matthijs): Yes, I see. I think I fixed this in r2463. The signer did not expect NSEC3 RRs after added records. (tested with tom.tld) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 17 11:52:28 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 17 Nov 2009 11:52:28 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.5cb99d2e5468b98ba42a26ca7fe3cca8@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by tom@?): Excellent. Nearly all of my zone files are working now... ...nearly :-) Signing tom.31 and then signing tom.32 (uncommented lots of NS records) misses two NS records. Output zone does not contain non-DNSSEC RRSet : NS, elroy.tom.#01186400#011IN#011NS#011ns1.nominet.org.uk (as before, no salt and 0 iterations) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 17 12:09:18 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 17 Nov 2009 12:09:18 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.fdfb9016f33f84fc3c5956aba290cce0@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by matthijs): Probably you syslog says: No new signatures, keeping old zone. ? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 17 12:14:49 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 17 Nov 2009 12:14:49 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.324c6104e8c73a0767dce2e41e24ac74@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by tom@?): Oops! I lied about my NSEC3 config... 1 5 a25e3f9753c6606e -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 17 14:30:42 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 17 Nov 2009 14:30:42 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.5b22572b8e3f59f6b113d89f147b3a72@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by matthijs): Ok, r2465 seems to work with tom.tld (removing and adding aborig*) and with switching between tom.{31/32} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 17 15:37:03 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 17 Nov 2009 15:37:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.b51dfef1110dee773a356b9857c94b4c@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: trunk | Keywords: -------------------+-------------------------------------------------------- Comment(by tom@?): All my zones now work :-D Thanks! -- Ticket URL: OpenDNSSEC OpenDNSSEC From Stephen.Morris at nominet.org.uk Tue Nov 17 18:15:47 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 17 Nov 2009 18:15:47 +0000 Subject: [Opendnssec-develop] Minutes of teleconference, 2009-11-17 Message-ID: Meetings from today's meeting is available on the wiki: http://trac.opendnssec.org/wiki/Meetings/Minutes/2009-11-17 Notes from the meeting in Hiroshima can be found at: http://trac.opendnssec.org/wiki/Meetings/Minutes/2009-11-12 Please let me know of any errors or omissions. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Nov 18 07:54:33 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 18 Nov 2009 07:54:33 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #46: Vanishing records In-Reply-To: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> References: <042.a41e53f6fb5e272058ea3d3b82de95b1@kirei.se> Message-ID: <051.b74c5b35a12fc13c0629821ea7de10c2@kirei.se> #46: Vanishing records -------------------+-------------------------------------------------------- Reporter: sion | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: trunk | Resolution: fixed Keywords: | -------------------+-------------------------------------------------------- Changes (by matthijs): * status: accepted => closed * resolution: => fixed Comment: You're very welcome. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Nov 19 08:16:30 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 19 Nov 2009 08:16:30 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #56: NSEC signatures created with algorithm 7 instead of 5 In-Reply-To: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> References: <056.0f09b49874e921b2acccc330916c98eb@kirei.se> Message-ID: <065.253f77bea72d3a55486cd6fe7e19b592@kirei.se> #56: NSEC signatures created with algorithm 7 instead of 5 -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: sion Type: defect | Status: closed Priority: minor | Component: Signer Version: trunk | Resolution: wontfix Keywords: | -------------------------------+-------------------------------------------- Changes (by rb): * status: assigned => closed * resolution: => wontfix -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Thu Nov 19 10:32:36 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 19 Nov 2009 10:32:36 +0000 Subject: [Opendnssec-develop] KSK rollover Message-ID: I have just committed the new KSK rollover code, please test it if you have any time. It works for some simple cases with one zone or 2 zones sharing keys but I have not tested with all variations of issuing " key rollover" commands while it is prompting the user to issue the ds-seen command etc. Sion From patrik.wallstrom at iis.se Thu Nov 19 15:13:57 2009 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Thu, 19 Nov 2009 16:13:57 +0100 Subject: [Opendnssec-develop] too many new signatures? Message-ID: <51E3B1DD-5FEB-4DD4-B877-DACA910763D9@iis.se> This is how it currently looks in my .SE test environment. 2 day signatures with 6h jitter. It should not look like this after a couple of days signing: Nov 19 07:17:12 dnssecsigner ods-signerd: Created 237163 new signatures Nov 19 07:25:08 dnssecsigner ods-signerd: Created 882734 new signatures Nov 19 09:25:39 dnssecsigner ods-signerd: Created 882842 new signatures Nov 19 11:17:12 dnssecsigner ods-signerd: Created 160163 new signatures Nov 19 11:25:02 dnssecsigner ods-signerd: Created 882988 new signatures Nov 19 13:25:39 dnssecsigner ods-signerd: Created 883109 new signatures I am running trunk revision 2470. From the last run: ; Last refresh stats: existing: 0, removed 0, created 883109 This is the content of the tmp-dir: -rw-r--r-- 1 opendnssec pkcs11 144844591 2009-11-19 13:17 se.nsecced -rw-r--r-- 1 opendnssec pkcs11 92338975 2009-11-19 13:17 se.processed -rw-r--r-- 1 opendnssec pkcs11 383978634 2009-11-19 13:25 se.signed -rw-r--r-- 1 opendnssec pkcs11 91727158 2009-11-18 18:02 se.signed.sorted -rw-r--r-- 1 opendnssec pkcs11 92252223 2009-11-19 13:16 se.sorted -rw-r--r-- 1 opendnssec pkcs11 109717100 2009-11-19 13:15 se.unsorted So it seems that it cannot reuse the old signatures. Yes, I move the signed zone file from signed/ when I see it and deliver it to my destination. Anybody else seen this or who has any ideas? -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From owner-dnssec-trac at kirei.se Thu Nov 19 18:31:02 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 19 Nov 2009 18:31:02 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #57: Auditor + ZoneReader (NameError) Message-ID: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> #57: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: alex Type: defect | Status: new Priority: trivial | Component: Auditor Version: | Keywords: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Hi all, auditor (Beta 7) answer with many message without a specifiq zone : (wihtout) ods-auditor --zone --signed Auditor started Auditor starting on archi.amt /usr/local/lib/opendnssec/kasp_auditor/preparser.rb:54:in `initialize': uninitialized constant Dnsruby::ZoneReader (NameError) from /usr/local/lib/opendnssec/kasp_auditor.rb:179:in `new' from /usr/local/lib/opendnssec/kasp_auditor.rb:179:in `normalise_and_sort' from /usr/local/lib/opendnssec/kasp_auditor.rb:133:in `run_with_syslog' from /usr/local/lib/opendnssec/kasp_auditor.rb:112:in `each' from /usr/local/lib/opendnssec/kasp_auditor.rb:112:in `run_with_syslog' from /usr/local/lib/opendnssec/kasp_auditor.rb:85:in `run' from /usr/local/lib/opendnssec/kasp_auditor.rb:83:in `open' from /usr/local/lib/opendnssec/kasp_auditor.rb:83:in `run' from /usr/local/bin/ods-auditor:112 And correct now : root at portable:/mnt/Compilation/opendnssec-1.0.0b7/auditor# ods-auditor --zone --signed 1.168.192.in-addr.arpa Best regards -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Nov 19 20:18:36 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 19 Nov 2009 20:18:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #57: Auditor + ZoneReader (NameError) In-Reply-To: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> References: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> Message-ID: <070.b2f9c0f1d4ca3a17cc0eb7bf7ae81bad@kirei.se> #57: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: alex Type: defect | Status: accepted Priority: trivial | Component: Auditor Version: | Keywords: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Changes (by alex): * status: new => accepted Old description: > Hi all, auditor (Beta 7) answer with many message without a specifiq zone > : > (wihtout) > ods-auditor --zone --signed > Auditor started > Auditor starting on archi.amt > /usr/local/lib/opendnssec/kasp_auditor/preparser.rb:54:in `initialize': > uninitialized constant Dnsruby::ZoneReader (NameError) > from /usr/local/lib/opendnssec/kasp_auditor.rb:179:in `new' > from /usr/local/lib/opendnssec/kasp_auditor.rb:179:in > `normalise_and_sort' > from /usr/local/lib/opendnssec/kasp_auditor.rb:133:in > `run_with_syslog' > from /usr/local/lib/opendnssec/kasp_auditor.rb:112:in `each' > from /usr/local/lib/opendnssec/kasp_auditor.rb:112:in > `run_with_syslog' > from /usr/local/lib/opendnssec/kasp_auditor.rb:85:in `run' > from /usr/local/lib/opendnssec/kasp_auditor.rb:83:in `open' > from /usr/local/lib/opendnssec/kasp_auditor.rb:83:in `run' > from /usr/local/bin/ods-auditor:112 > > And correct now : > > root at portable:/mnt/Compilation/opendnssec-1.0.0b7/auditor# ods-auditor > --zone --signed 1.168.192.in-addr.arpa > > Best regards New description: Hi all, auditor (Beta 7) answer with many message without a specifiq zone : (wihtout) ods-auditor --zone --signed Auditor started Auditor starting on archi.amt /usr/local/lib/opendnssec/kasp_auditor/preparser.rb:54:in `initialize': uninitialized constant Dnsruby::ZoneReader (NameError) from /usr/local/lib/opendnssec/kasp_auditor.rb:179:in `new' from /usr/local/lib/opendnssec/kasp_auditor.rb:179:in `normalise_and_sort' from /usr/local/lib/opendnssec/kasp_auditor.rb:133:in `run_with_syslog' from /usr/local/lib/opendnssec/kasp_auditor.rb:112:in `each' from /usr/local/lib/opendnssec/kasp_auditor.rb:112:in `run_with_syslog' from /usr/local/lib/opendnssec/kasp_auditor.rb:85:in `run' from /usr/local/lib/opendnssec/kasp_auditor.rb:83:in `open' from /usr/local/lib/opendnssec/kasp_auditor.rb:83:in `run' from /usr/local/bin/ods-auditor:112 And correct now : root at portable:/mnt/Compilation/opendnssec-1.0.0b7/auditor# ods-auditor --zone --signed 1.168.192.in-addr.arpa Best regards -- Comment: Hi - This version of the auditor requires version 1.40 of dnsruby (as noted in the NEWS file). Upgrading should fix this issue. Thanks, Alex. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Nov 19 21:22:39 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 19 Nov 2009 21:22:39 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #57: Auditor + ZoneReader (NameError) In-Reply-To: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> References: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> Message-ID: <070.622ee7722f7afecfb53a5f4900024404@kirei.se> #57: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: alex Type: defect | Status: accepted Priority: trivial | Component: Auditor Version: | Keywords: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Comment(by archi.laurent@?): Many thanks for your answer, and sorry for the versioning of dnsruby, but now i can do this : ( 3 tests and it's just for your information, my auditor is ok with "-- zone --signed" ods-auditor Auditor started Auditor starting on archi.amt 6: SOA differs : from 2009111901 to 1258665103 6: Auditing archi.amt zone : NSEC3 SIGNED 6: Finished auditing archi.amt zone Auditor starting on 1.168.192.in-addr.arpa ERROR parsing line 19 : ) ; key id = 17154 '''/usr/local/lib/opendnssec/kasp_auditor/preparser.rb:108:in `prepare': undefined method `index' for nil:NilClass (NoMethodError) from /usr/local/lib/opendnssec/kasp_auditor/preparser.rb:80:in `normalise_zone_and_add_prepended_names' from /usr/local/lib/opendnssec/kasp_auditor/preparser.rb:73:in `foreach' from /usr/local/lib/opendnssec/kasp_auditor/preparser.rb:73:in `normalise_zone_and_add_prepended_names' from /usr/local/lib/opendnssec/kasp_auditor/preparser.rb:71:in `open' from /usr/local/lib/opendnssec/kasp_auditor/preparser.rb:71:in `normalise_zone_and_add_prepended_names' from /usr/local/lib/opendnssec/kasp_auditor.rb:185:in `normalise_and_sort' from /usr/local/lib/opendnssec/kasp_auditor.rb:184:in `fork' from /usr/local/lib/opendnssec/kasp_auditor.rb:184:in `normalise_and_sort' from /usr/local/lib/opendnssec/kasp_auditor.rb:135:in `run_with_syslog' from /usr/local/lib/opendnssec/kasp_auditor.rb:112:in `each' from /usr/local/lib/opendnssec/kasp_auditor.rb:112:in `run_with_syslog' from /usr/local/lib/opendnssec/kasp_auditor.rb:85:in `run' from /usr/local/lib/opendnssec/kasp_auditor.rb:83:in `open' from /usr/local/lib/opendnssec/kasp_auditor.rb:83:in `run' from /usr/local/bin/ods-auditor:112 Auditor found errors - check log for details''' ---- root at portable:/tmp# ods-auditor '''--zone --signed''' 1.168.192.in- addr.arpa Auditor started '''Auditor found no errors''' ---- root at portable:/tmp# ods-auditor '''--zone --signed''' archi.amt Auditor started '''Auditor found no errors''' Best regards -- Ticket URL: OpenDNSSEC OpenDNSSEC From Stephen.Morris at nominet.org.uk Thu Nov 19 22:02:29 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Thu, 19 Nov 2009 22:02:29 +0000 Subject: [Opendnssec-develop] KSK Rollovers Message-ID: Following the last telephone meeting, I said that I would put something on the list about KSK rollover for people to check the logic. The timing diagram for such a rollover is: |1| |2| |3| |4| |5| | | | | | Key N - - -------------------------->|<--------->| | | est retired dead | | retire | | | | time | | | | | | | Key N+1 |<--------->|<-------------->|<--------- - - - published ready | active | | | "submit DS" "DS seen" ------- Time -----> (This should be displayed correctly in a fixed-width font.) The numbers above each line correspond to an event described below. 1) At least child propagation time + child zone TTL + safety margin ... before the current KSK reaches the end of its scheduled lifetime, we introduce the new KSK into the zone. The DNSKEY RRset is signed with both KSKs, and the new KSK is placed in the "published" state. ("child propagation time" is the time taken for an RR introduced at the child's master nameserver to have reached all nameservers serving the child zone. "child zone TTL" is the TTL of RRs in the child zone, in particular the TTL of the DNSKEY RRs. "safety margin" is as its name suggests, an additional time period added so that we are _completely_ sure that the record has propagated.) The interval is such that at the point that the current KSK reaches the end of its scheduled lifetime, any validator that has cached the DNSKEY RRset will have a copy that contains [and is signed by] both the old and new KSKs. 2) At some later time, the new KSK is "ready". That is, all validators that have the DNSKEY RRset in their cache have a copy of both keys. This will be at or before the current KSK reaches its estimated retire time, depending on exactly when the new KSK was introduced. 3) When the current KSK reaches its estimated retire time, the KASP enforcer starts outputting messages that the DS record in the parent must be changed. The messages should indicate what the new key is, and there has to be some way to extract the DS record for transmission to the parent. 4) At some later time, the new DS record is seen in the parent zone and the old one removed. (At this point, as all validators that have cached the DNSKEY RRset have both KSKs in their cache, it doesn't matter whether a validator checks against the new DS record or the old one (having retrieved the old one just before it was removed from the parent); at least one of the KSKs will match.) The operator issues the "ds-seen" command to tell KASP about this. This command moves the old KSK into the "retired" state and the new KSK into the "active" state. The scheduled dead time for the old KSK is set to: active time + parent propagation time + parent zone TTL + safety margin (As we have no way of knowing when the DS record actually appeared in the parent, we assume the worst. The interval allows for the ds-seen command being issued the moment the DS record appears at the primary server of the parent zone: after (parent propagation time + parent zone TTL + safety margin), any validator that contains the DS RRset will have a copy of the RRset containing the new DS record. As, at this point, the validator will also have the DNSKEY RRset containing the new KSK, it will able to validate the zone with the new KSK and DS records. The old KSK is now redundant.) 5) At the first run of the signer after the old KSK reaches its scheduled dead time, the old KSK can be removed. Caveats: If the operator issues the ds-seen command, the command MUST be ignored unless the DS record corresponds to that of a key in the ready state. Otherwise we run the risk that the old KSK is removed before all validators have received a copy of the new DS record, leading to a KSK-DS mismatch and the zone being declared bogus. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Thu Nov 19 22:12:58 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 19 Nov 2009 23:12:58 +0100 Subject: [Opendnssec-develop] too many new signatures? In-Reply-To: <51E3B1DD-5FEB-4DD4-B877-DACA910763D9@iis.se> References: <51E3B1DD-5FEB-4DD4-B877-DACA910763D9@iis.se> Message-ID: <4B05C2EA.1010406@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did made a fix which had as side effect the signatures from the .signed file were not checked, but I reverted in r2466. - From the logs I see that the number of created signatures differ. Do you now why that could be? Providing the signconf.xml (partially) could give more insight. Thanks, Matthijs Patrik Wallstr?m wrote: > This is how it currently looks in my .SE test environment. 2 day > signatures with 6h jitter. It should not look like this after a couple > of days signing: > > Nov 19 07:17:12 dnssecsigner ods-signerd: Created 237163 new signatures > Nov 19 07:25:08 dnssecsigner ods-signerd: Created 882734 new signatures > Nov 19 09:25:39 dnssecsigner ods-signerd: Created 882842 new signatures > Nov 19 11:17:12 dnssecsigner ods-signerd: Created 160163 new signatures > Nov 19 11:25:02 dnssecsigner ods-signerd: Created 882988 new signatures > Nov 19 13:25:39 dnssecsigner ods-signerd: Created 883109 new signatures > > I am running trunk revision 2470. From the last run: > > ; Last refresh stats: existing: 0, removed 0, created 883109 > > This is the content of the tmp-dir: > > -rw-r--r-- 1 opendnssec pkcs11 144844591 2009-11-19 13:17 se.nsecced > -rw-r--r-- 1 opendnssec pkcs11 92338975 2009-11-19 13:17 se.processed > -rw-r--r-- 1 opendnssec pkcs11 383978634 2009-11-19 13:25 se.signed > -rw-r--r-- 1 opendnssec pkcs11 91727158 2009-11-18 18:02 > se.signed.sorted > -rw-r--r-- 1 opendnssec pkcs11 92252223 2009-11-19 13:16 se.sorted > -rw-r--r-- 1 opendnssec pkcs11 109717100 2009-11-19 13:15 se.unsorted > > So it seems that it cannot reuse the old signatures. > > Yes, I move the signed zone file from signed/ when I see it and > deliver it to my destination. > > Anybody else seen this or who has any ideas? > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLBcLkAAoJEA8yVCPsQCW5Vr4IANFkIr0/r2fzJo5CcmcJuwxf ngagZ7hVDkUpRC5Eq8S4YiVArVm/aAwF8VXYt1wleq7MGM4DkyzOE2TBh8ft2gSH yvXX/2C0K3rRiXUXO0X7VP9RjqU93csI2ROt0HPbm4qhz1BcoJ9eCb0NT0jpkUiU VejXr+4U1eXZJgvm/BTh7qokpZbwOMDMfxDnjbPZLg7J6Zjexwh6EcFHf0t6vRb2 ckE45wvI1qkALMfciwHvqzRv3B1heL/pzaa4BBFAedf9Xi6r8DdRWpFauHHMxEA1 Uqq8g2c1ECLcbLACMSAD+/wZYL+dJ2OYF7hAZwXR9w+oRMSkvMojMc7k3i2fZ1o= =7nmO -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Fri Nov 20 07:14:52 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 20 Nov 2009 07:14:52 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #57: Auditor + ZoneReader (NameError) In-Reply-To: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> References: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> Message-ID: <070.af80d873d82ea1a8bb27b44abdc005c1@kirei.se> #57: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: alex Type: defect | Status: accepted Priority: trivial | Component: Auditor Version: | Keywords: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Comment(by alex): Can you please send the unsigned zone file which is producing this error? -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Fri Nov 20 11:01:06 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 20 Nov 2009 12:01:06 +0100 Subject: [Opendnssec-develop] Zonelist Message-ID: <983F17705339E24699AA251B458249B51F196791FF@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi We now recommend users to not manually edit zonelist.xml, because the Enforcer might get confused. I think we should thus disable the parsing of the zonelist when doing "ods-ksmutil update" and removing the example from the installed zonelist.xml. Comments? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSwZ28uCjgaNTdVjaAQjQ5AgAjOAxIPCZgZGWD+/o+pc6n7DiK/o6PMtL 1aZkGpClxQXTJs4SbisXcTFumu4XGuRC7AhzISzPZDxAYZOQTDoTOtm38yr+EWkw dsB0W+pX5gw22JQVKLha7a+NslAWJwDfm913GfgKaOQl/zQpqi7vSF/nukFtXDDE alhycC/gJ0XXcDZNlfEmtU+QmLZ0HiebywhE/Fdk9VRdiOxellLvZKuPKmTlk0kP 8AAks3oAhbjrthTI69qtQ/nHJJeEl8YKAOP3d0Gj0wvQ004NB5rvCS53wfEEcACY 0C2RtU5Akhe6y3n/xRYLkTFTiyUmiaQB4EOqk3fOZpMdQtGIBhITww== =RkQ1 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Fri Nov 20 11:07:40 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Fri, 20 Nov 2009 11:07:40 +0000 Subject: [Opendnssec-develop] Zonelist In-Reply-To: <983F17705339E24699AA251B458249B51F196791FF@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F196791FF@EXCHANGE2K7.office.nic.se> Message-ID: > We now recommend users to not manually edit zonelist.xml, because > the Enforcer might get confused. I think we should thus disable the > parsing of the zonelist when doing "ods-ksmutil update" and removing > the example from the installed zonelist.xml. > > Comments? There is one situation where this works. That is if you edit the zonelist before running ksmutil setup. I agree about the update command; for version 1.1 I can put this back in, but for now it might be best to do everything via zone add/delete. Sion From jakob at kirei.se Fri Nov 20 12:43:49 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 20 Nov 2009 13:43:49 +0100 Subject: [Opendnssec-develop] Zonelist In-Reply-To: <983F17705339E24699AA251B458249B51F196791FF@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F196791FF@EXCHANGE2K7.office.nic.se> Message-ID: <28DD1957-BA9E-42A9-A15B-A78D753193FE@kirei.se> On 20 nov 2009, at 12.01, Rickard Bellgrim wrote: > We now recommend users to not manually edit zonelist.xml, because the Enforcer might get confused. I think we should thus disable the parsing of the zonelist when doing "ods-ksmutil update" and removing the example from the installed zonelist.xml. the design was that zonelist.xml is the master copy of the zonelist and it's synced into the kasp database upon update, just as the KASP. the alternate, i.e. you update via the kasp database and then export zonelist.xml and kasp.xml was the exception. I'm note I like to change this. I do see the benefit of having the command line tools add zones and dump what's added to the zonelist.xml, but changing the "master" is IMHO not good when it comes to integration with other tools (like Men&Mice). jakob From owner-dnssec-trac at kirei.se Fri Nov 20 17:35:32 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 20 Nov 2009 17:35:32 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #57: Auditor + ZoneReader (NameError) In-Reply-To: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> References: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> Message-ID: <070.dc9aa8135c7f42273b55926efe219b00@kirei.se> #57: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: alex Type: defect | Status: accepted Priority: trivial | Component: Auditor Version: | Keywords: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Comment(by archi.laurent@?): Hi and thank for your answer, you can see my factice unsigned zone here (archi.amt). Best regards and good week-end $TTL 2H[[BR]] @ IN SOA portable.archi.amt. dnsmaster.archi.amt. ([[BR]] 2009111901 ; serial[[BR]] 2H ; refresh[[BR]] 1H ; retry[[BR]] 2H ; expiry[[BR]] 1H ) ; minimum[[BR]] @ IN NS portable.archi.amt.[[BR]] @ IN NS serveur.archi.amt.[[BR]] serveur IN A 192.168.1.11[[BR]] archi.amt. IN MX 10 serveur.archi.amt.[[BR]] www IN CNAME serveur.archi.amt.[[BR]] wpad IN CNAME serveur.archi.amt.[[BR]] ftp IN A 192.168.1.11[[BR]] portable IN A 192.168.1.203[[BR]] --END -- And it's good with this command : opendnssec-1.0.0b7/auditor# ods-auditor --zone --signed archi.amt[[BR]] Auditor started[[BR]] Auditor found no errors[[BR]] -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Nov 20 18:47:24 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 20 Nov 2009 18:47:24 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #57: Auditor + ZoneReader (NameError) In-Reply-To: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> References: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> Message-ID: <070.0c517b7d43770f19fc79d84482a011a6@kirei.se> #57: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: alex Type: defect | Status: accepted Priority: trivial | Component: Auditor Version: | Keywords: Auditor + ZoneReader (NameError) ------------------------------------+--------------------------------------- Comment(by rb): There are two things here: 1. The auditor crashes when the option is missing an argument. 2. The command line should look like: "ods-auditor --zone [ZONE_NAME] --signed [PATH_TO_SIGNED_FILE]" or "ods-auditor -z [ZONE_NAME] -s [PATH_TO_SIGNED_FILE]" The auditor can be started in three ways: "ods-auditor" * Will audit all of your zones and the unsigned and signed zone files are stored in the location indicated in the zonelist.xml "ods-auditor -z [ZONE_NAME]" * Will audit a single zone. And uses the paths given in the zonelist.xml "ods-auditor -z [ZONE_NAME] -s [PATH_TO_SIGNED_FILE]" * Audit a single zone and use the signed zone given in this path rather than that one given in the zonelist.xml If you have the tag in the kasp.xml, then the auditor will be started automatic by the signer. Thus stopping the zone distribution if something is wrong. You can run the auditor yourself by using these commands, to see what it is saying. The reason why we have the option to override the signed zone file location, is so that the signer can audit the zone before it is written to the signed directory. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Nov 23 08:59:20 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 23 Nov 2009 08:59:20 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #57: Auditor + ZoneReader (NameError) In-Reply-To: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> References: <061.b62d3884e1d747d23788c86a341ff6a5@kirei.se> Message-ID: <070.bd725078392a7e5843f7336e0452a5c1@kirei.se> #57: Auditor + ZoneReader (NameError) ---------------------------------------------+------------------------------ Reporter: archi.laurent@? | Owner: alex Type: defect | Status: closed Priority: trivial | Component: Auditor Version: | Resolution: worksforme Keywords: Auditor + ZoneReader (NameError) | ---------------------------------------------+------------------------------ Changes (by alex): * status: accepted => closed * resolution: => worksforme Comment: I can't reproduce this problem. The zone is signed and audited with no problem on my machine. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon Nov 23 09:26:56 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 23 Nov 2009 10:26:56 +0100 Subject: [Opendnssec-develop] Zonelist In-Reply-To: <28DD1957-BA9E-42A9-A15B-A78D753193FE@kirei.se> References: <983F17705339E24699AA251B458249B51F196791FF@EXCHANGE2K7.office.nic.se> <28DD1957-BA9E-42A9-A15B-A78D753193FE@kirei.se> Message-ID: <983F17705339E24699AA251B458249B51F196793B4@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > the design was that zonelist.xml is the master copy of the zonelist and > it's synced into the kasp database upon update, just as the KASP. the > alternate, i.e. you update via the kasp database and then export > zonelist.xml and kasp.xml was the exception. Yes > I'm note I like to change this. I do see the benefit of having the > command line tools add zones and dump what's added to the zonelist.xml, > but changing the "master" is IMHO not good when it comes to integration > with other tools (like Men&Mice). But there are some bugs in the Enforcer which sometimes confuses it when zones are added/removed by doing manual editing of the zonelist. So the quick solution for 1.0 is to disable this functionality in the update command. And fix this for v1.1. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSwpVYOCjgaNTdVjaAQj1egf9FRru7/jTmZb3N2nf/fQmqONiaww3bKb/ +jGPtQOt5hknqlZWYnW4gFp/UYPfNFd0DBey/+v4c9xG4A7d7Dt4++4YqjH5l1RC M278MM8TbuQsdirf1C5JBewl1C2Vty9oQ9HrrN2TJ1PuTdIz6QmjHrgTvzzkmfdj r3RxWOxkhZxDMpyxydDTWzdse/3Cr1QkCOeO4k/6vUEc+NRRVRwdTb33ZWEHt6O2 e/tzNS+a+8c7H3+INtE7N/t/mLiFFUOd3oclglCrOow+xVp79uwVrsEqJr1MFXvM z7n42sivDODU1cdekvKTYu8Mr/XcBCuHUz4ukLagjqOExanbaA5Byw== =saXF -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Mon Nov 23 09:51:23 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 23 Nov 2009 09:51:23 +0000 Subject: [Opendnssec-develop] Zonelist In-Reply-To: <983F17705339E24699AA251B458249B51F196793B4@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F196791FF@EXCHANGE2K7.office.nic.se> <28DD1957-BA9E-42A9-A15B-A78D753193FE@kirei.se> <983F17705339E24699AA251B458249B51F196793B4@EXCHANGE2K7.office.nic.se> Message-ID: > > I'm note I like to change this. I do see the benefit of having the > > command line tools add zones and dump what's added to the zonelist.xml, > > but changing the "master" is IMHO not good when it comes to integration > > with other tools (like Men&Mice). > > But there are some bugs in the Enforcer which sometimes confuses it > when zones are added/removed by doing manual editing of the > zonelist. So the quick solution for 1.0 is to disable this > functionality in the update command. And fix this for v1.1. The fix to add a zone using manual editing followed by "update" is not too bad (maybe 1 point). Removing zones is a _bit_ more complicated. I can certainly fix adding for v1.0 if that is desired, remove is more involved, but the bug is less of an issue too. Sion From rickard.bellgrim at iis.se Mon Nov 23 10:39:52 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 23 Nov 2009 11:39:52 +0100 Subject: [Opendnssec-develop] How to migrate a signed zone to OpenDNSSEC In-Reply-To: <850A39016FA57A4887C0AA3C8085F9490154FA10@KAEVS1.SIDN.local> References: <983F17705339E24699AA251B458249B51F1960090F@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F9490154FA10@KAEVS1.SIDN.local> Message-ID: <983F17705339E24699AA251B458249B51F19679401@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I would say this would be excactly the same as the transfer issue from > a different DNS-operator. > Just feed the (signed) zone to opendnssec, and roll the key using the > same process as when the zone is transferred, i.e. pre-publish. Isn't it a little bit more complicated than that? 1. Feed unsigned zone and DNSKEY RRset to new nameserver and start signing with new keys 2. Prepublished the new DNSKEYs in the old nameserver 3. Publish new DS 4. Publish new NS and remove old NS 5. Remove old DS 6. Remove old DNSKEYs With appropriate timing between each step. Am I missing any step? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSwpmeOCjgaNTdVjaAQiqBAf/ajYYWq+KLf+fBIuq5X/3fP3cvSiw//Tf DaEpIkjLZgnKy19V3SGIiUgkwnIur5vhvGf/KlECcHzeOdMoUxYDsndAPbFcHH28 26Il4bKBJdygGOYdpGzNFmls0DTat7U+8E7cO3+ssEu2dgZEF0lD0f9owoFV4ct1 XbOW6/HyVkB2vMQA8D6xN7YRSJNrj5vOByCAR3TiO/1ZQgKxYoz3g8uQq2l8M9q7 ea19zg56snompdQR5uq1efGkqc5vX22KqbaaCytHEdbTHptl5nt+3hZredy/8n+f 0S44gtgtgzKjiBHEZSgSWqKgD7Gt1nrx9bRBQJiRZFWmuhxwNziANA== =Zjex -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Nov 24 08:28:10 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 24 Nov 2009 09:28:10 +0100 Subject: [Opendnssec-develop] Make the keys extractable from HSM? Message-ID: <983F17705339E24699AA251B458249B51F19679601@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I remember a discussion we had in Utrecht regarding the wrapping functions in PKCS#11. If a key is marked as extractable, you can export the key encrypted and then import it into another HSM. You must first have a shared symmetric key in each HSM. We currently have the extractable attribute set to false. http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/libhsm/src/libhsm.c#L1907 We should still have the keys marked as sensitive, so that the key material cannot be revealed in plain text. But my question is whether we should have the key extractable or not? Just want to discuss this topic, so that we do not lock the user down. Or is it better to protect against a potential threat of leaking keys? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSwuZGuCjgaNTdVjaAQjbigf/UyfK5CREMaadbbUKapbQD9EaDZUXW/Vi rcmxxCxSs22T3/pQK2SlXVilJOFrf3moBGsJcgdEnlUYCq4s+91ys0Y86hHOb0dX hri3mx/vT1ONcJP9P0HwnxjCvgqxDnLTEQPtERg8cxWzD1w2vCmMuc8Lztt2/8HS 5mhv+BPDP+TjBFvH0W8qNVDiwZEq0/3tn37VGAbhSEpYZtMdKCchfwNgwPRUFOoy PryLzGL4C4AL4hmlhewJsdunpehszZM6cRYkiwwTB6rXuPnhknMO4QPsTcLW6B6Q HT4DTpV1zUDvcR3UnsdV7T20qN0R25fvQ13XJZOxMSkBdXt2S0p1Kg== =2j7/ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy at nominet.org.uk Tue Nov 24 08:40:05 2009 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 24 Nov 2009 08:40:05 +0000 Subject: [Opendnssec-develop] Make the keys extractable from HSM? In-Reply-To: <983F17705339E24699AA251B458249B51F19679601@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F19679601@EXCHANGE2K7.office.nic.se> Message-ID: Rickard Bellgrim wrote on 11/24/2009 08:28:10 AM: > Hi > > I remember a discussion we had in Utrecht regarding the wrapping > functions in PKCS#11. If a key is marked as extractable, you can > export the key encrypted and then import it into another HSM. You > must first have a shared symmetric key in each HSM. > > We currently have the extractable attribute set to false. > http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/libhsm/src/libhsm.c#L1907 > > We should still have the keys marked as sensitive, so that the key > material cannot be revealed in plain text. But my question is > whether we should have the key extractable or not? By default, no. Default should be to have it not exportable. Flipping the 'exportable bit' must also be a one way function. You can switch from exportable to not exportable, but not from not-exportable to exportable. In general, keys only need to be exportable when an HSM roll is due. By that time, a key can be generated that is exportable. > Just want to discuss this topic, so that we do not lock the user > down. Or is it better to protect against a potential threat of leaking keys? IMHO it is not a mutual exclusive choice. We need to protect against a potential threat of leaking keys all the time, but only enable the user to export the key as an explicit conscious choice. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Nov 24 08:54:22 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 24 Nov 2009 09:54:22 +0100 Subject: [Opendnssec-develop] Make the keys extractable from HSM? In-Reply-To: References: <983F17705339E24699AA251B458249B51F19679601@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B51F19679621@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > By default, no. Default should be to have it not exportable. Flipping > the 'exportable bit' must also be a one way function. You can switch > from exportable to not exportable, but not from not-exportable to > exportable. Yeah. This is something that can only be done when you are creating the key (setting the key to extractable). > In general, keys only need to be exportable when an HSM roll is due. By > that time, a key can be generated that is exportable. > > > Just want to discuss this topic, so that we do not lock the user > > down. Or is it better to protect against a potential threat of > leaking keys? > > IMHO it is not a mutual exclusive choice. We need to protect against a > potential threat of leaking keys all the time, but only enable the user > to export the key as an explicit conscious choice. Ok, sounds like a feature for version 2.0. The HSMs are probably not going to be rolled in this time frame. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBUAwUBSwufPuCjgaNTdVjaAQieawf4iOwJ8vkb4ieLjt6weF4wVKe0eJgkVpZO G7v5bC3hDBSTNrGl7IoTK/j3sF7Y3YkRFqco0YONWAxeP2k76qDuN4PaWv6s9AJB 2d8vNH2qXs8W6cdJX4xOvVREbUxLF2rTxPCMh7CUhYxpfsO/YaXDZqseJs8VyuLM P+JHZa7GnfST2h0cNm7BkwT1T8QMGufoiKvZ73H+jYKoLOaDs755IV6A11Mduq1Y 2Uan6cw6Awba4bx4aU9FMsl2kUrIT4w+TKmD4vQVgvKFCPZOojGlQyMH3fZB4AmA 5ZMCt6XansaivN27CAOjCtdfFY2VfjsSydQl3o7wOmkpCJR6TlnS =48AN -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Tue Nov 24 09:06:04 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 24 Nov 2009 09:06:04 +0000 Subject: [Opendnssec-develop] ds-seen details Message-ID: There has been a bit of a discussion on pivotal about the details of how the ds-seen command. As I imagine that not so many people are keeping up with it I'll summarise it here in case anyone has any ideas... what it comes down to is when we think the ds-seen command should be issued. I have implemented a command that should be run when you want the KSK to roll, so what happens is: 1) Key reaches retirement, and the system starts prompting (via syslog) for the DS record of the new key to be submitted. 2) When the DS is submitted and seen in the DNS the rollover happens in response to the "ds-seen" command. The alternative is that: 1) The user issues the ds-seen command at any time, on any key. This marks the key as having been "seen". 2) When the current key reaches retirement, provided that there is a key in the ready state that has been marked as "seen", then the rollover will continue automatically. This second scheme requires maybe one days work to write and test a bit. So my question is which scheme do people prefer? What we could do is rename the current command as "ksk-roll" which is a more accurate description of what it does, and add the alternate scheme for v1.1. This way you can work with either scheme. Sion From roy at nominet.org.uk Tue Nov 24 09:06:39 2009 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 24 Nov 2009 09:06:39 +0000 Subject: [Opendnssec-develop] Make the keys extractable from HSM? In-Reply-To: <983F17705339E24699AA251B458249B51F19679621@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F19679601@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B51F19679621@EXCHANGE2K7.office.nic.se> Message-ID: Rickard Bellgrim wrote on 11/24/2009 08:54:22 AM: > > By default, no. Default should be to have it not exportable. Flipping > > the 'exportable bit' must also be a one way function. You can switch > > from exportable to not exportable, but not from not-exportable to > > exportable. > > Yeah. This is something that can only be done when you are creating > the key (setting the key to extractable). Cool! > > In general, keys only need to be exportable when an HSM roll is due. By > > that time, a key can be generated that is exportable. > > > > > Just want to discuss this topic, so that we do not lock the user > > > down. Or is it better to protect against a potential threat of > > leaking keys? > > > > IMHO it is not a mutual exclusive choice. We need to protect against a > > potential threat of leaking keys all the time, but only enable the user > > to export the key as an explicit conscious choice. > > Ok, sounds like a feature for version 2.0. The HSMs are probably not > going to be rolled in this time frame. As for replication of the keystore (backup, fallback, failover purposes), some HSMs have functionality for that, independent of applications that are using the HSM. (as an example, 'scamgr backup' provides this for Sun's SCA6000). As for rolling to a new HSM, that can be done without exporting keys, by aligning a key-roll with hsm-roll. So, I concur. This feature is not needed for version 1.0, but lets make sure that by default, the keys that are generated are not exportable. Thanks, Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Nov 24 09:49:53 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 24 Nov 2009 10:49:53 +0100 Subject: [Opendnssec-develop] ds-seen details In-Reply-To: References: Message-ID: <983F17705339E24699AA251B458249B51F19679686@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > 1) Key reaches retirement, and the system starts prompting (via syslog) > for > the DS record of the new key to be submitted. > 2) When the DS is submitted and seen in the DNS the rollover happens in > response to the "ds-seen" command. What I saw was that you could not do this on a standby key without forcing a rollover. But maybe this was not a requirement. > The alternative is that: > > 1) The user issues the ds-seen command at any time, on any key. This > marks > the key as having been "seen". > 2) When the current key reaches retirement, provided that there is a > key in > the ready state that has been marked as "seen", then the rollover will > continue automatically. Remembering the discussion about having a tool which synchronizes DS records in the parent with the KSK key set. This scheme would be a good interface for such a tool. > This second scheme requires maybe one days work to write and test a > bit. So > my question is which scheme do people prefer? I would prefer the second scheme, but as you say, it require some more changes to the code. > What we could do is rename the current command as "ksk-roll" which is a > more accurate description of what it does, and add the alternate scheme > for > v1.1. This way you can work with either scheme. Just so it is clear for the user on how to do a KSK rollover (if we are going to keep the first schema). E.g. ods-ksmutil key rollover --zone example.com --keytype KSK (upload new DS to parent) ods-ksmutil key ksk-roll --zone example.com --keytag 12345 Just to remember: The key rollovers are something that OpenDNSSEC should be good at. Maybe so important that it must be solved before v1.0. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSwusQeCjgaNTdVjaAQiq1wf/QKCkp6Dlw9eaBShWs6m0YboXarcnhNJx wX2tE/qOc458bSiUnhhC7Av1TnVnxcxaylUgI4boS26TewSafp4uAVte9K/82fwq Sp5Uevwj/7VhbwbqyM5ttJXdVsoNZ7wfSA+pRwCN7f12eCGqxxu89MIlzNH2jkB/ 61/Z7tC8BNgdedUYj4t0bbcMVI73MqaNCm2XGV2OhbviG2EJQYZRdDzjjAYJw5bc 0g9MN+31g7cv6nEf5oOQxs3VyBpa3Pm7LpPO1nWsHJ+EMgnvxnybJV9ae/3T1k3e 7czBF+o9fnDQzSJ2HJqk8sn62QpXnZdug7MdHTv8mIfMce3tcnYCzg== =quPj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Nov 24 12:01:26 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 24 Nov 2009 13:01:26 +0100 Subject: [Opendnssec-develop] Meeting 20091125 Message-ID: <983F17705339E24699AA251B458249B51F19679716@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi We have a meeting tomorrow. Date: Wednesday 25 November Time: 11:00-12:00 CET, 10:00-11:00 GMT Please update agenda, if you have more topics: http://trac.opendnssec.org/wiki/Meetings/Agenda/2009-11-25 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSwvLFuCjgaNTdVjaAQhkLwf/aGOnFRNcNwWNdqI61cMjRcA+h01TYb+i vvzbCt6MkZHyx06pP86T+dKxugjmmQxybOnZ5iz8UfG6fuciRNy0NGDsv2V8q27a EmcRVE3O2HSb07hxJx+m1ATLIIIWrYLQxBNWE9L9u6JYLYYxxxD1yFHlcJhN0kfQ cjFu7+MtNLRMKNtBl2UWZHCg7h/S19D98Uod0Mm3SK2cSOShhhrVwpXSDbiC/IPy cZgbm4vrZBTc/MEuLG8ui3eDBn2ANt3CSVptCT/w/2l/Ky37Q/vZMyzSq43gQPJ+ gPz7JYm1swvg6ZEt/9MUfhZS8Dhys0LE2lobe5BuYFW6ZhNExiIjbg== =9YGm -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Tue Nov 24 12:05:43 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 24 Nov 2009 13:05:43 +0100 Subject: [Opendnssec-develop] Make the keys extractable from HSM? In-Reply-To: References: <983F17705339E24699AA251B458249B51F19679601@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B51F19679621@EXCHANGE2K7.office.nic.se> Message-ID: On 24 nov 2009, at 10.06, Roy Arends wrote: > So, I concur. This feature is not needed for version 1.0, but lets make sure that by default, the keys that are generated are not exportable. > +1 jakob From owner-dnssec-trac at kirei.se Tue Nov 24 13:51:18 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 24 Nov 2009 13:51:18 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #58: Schema for kasp.xml does not allow 0 values for salt and iterations Message-ID: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> #58: Schema for kasp.xml does not allow 0 values for salt and iterations -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: -------------------------------+-------------------------------------------- The following NSEC3 configuration produces schema errors.... P100D 1 0 element Iterations: Relax-NG validity error : Type positiveInteger doesn't allow value '0' element Salt: Relax-NG validity error : Type positiveInteger doesn't allow value '0' -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 24 13:56:18 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 24 Nov 2009 13:56:18 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #59: Problem starting ods-signer on 64-bit systems Message-ID: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> #59: Problem starting ods-signer on 64-bit systems ---------------------------------+------------------------------------------ Reporter: andyh@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: ---------------------------------+------------------------------------------ ods-signerd has a variable hard coded: ENGINE_LOC=/usr/lib/opendnssec/signer This breaks when building 64-bit versions as they default to using --libdir=/usr/lib64 in the configure and when I start using ods-control: Starting signer engine... connecting to /var/run/opendnssec/engine.sock /usr/bin/python: can't open file '/usr/lib/opendnssec/signer/Engine.py': [Errno 2] No such file or directory Starting enforcer... OpenDNSSEC ods-enforcerd started (version 1.0.0b8), pid 15296 -- Ticket URL: OpenDNSSEC OpenDNSSEC From roland.vanrijswijk at surfnet.nl Tue Nov 24 14:30:18 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 24 Nov 2009 15:30:18 +0100 Subject: [Opendnssec-develop] Make the keys extractable from HSM? In-Reply-To: References: <983F17705339E24699AA251B458249B51F19679601@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B51F19679621@EXCHANGE2K7.office.nic.se> Message-ID: <4B0BEDFA.7080606@surfnet.nl> Jakob Schlyter wrote: > On 24 nov 2009, at 10.06, Roy Arends wrote: >> So, I concur. This feature is not needed for version 1.0, but lets make sure that by default, the keys that are generated are not exportable. >> > > +1 +1 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 Tue Nov 24 15:21:01 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 24 Nov 2009 15:21:01 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #59: Problem starting ods-signer on 64-bit systems In-Reply-To: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> References: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> Message-ID: <067.6100f9caf8ed947e376b2400746b90c7@kirei.se> #59: Problem starting ods-signer on 64-bit systems ---------------------------------+------------------------------------------ Reporter: andyh@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: ---------------------------------+------------------------------------------ Comment(by matthijs): ods-signerd is generated from ods-signerd.in, which has no hard coded ENGINE_LOC. But it's current value is @prefix@/lib/opendnssec/signer. I believe it should go in @opendnsseclibdir at . (see r2497) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 24 21:14:29 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 24 Nov 2009 21:14:29 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #58: Schema for kasp.xml does not allow 0 values for salt and iterations In-Reply-To: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> References: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> Message-ID: <065.c790da4b6379590ad4861b25707fa659@kirei.se> #58: Schema for kasp.xml does not allow 0 values for salt and iterations -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: jakob Type: defect | Status: assigned Priority: major | Component: Enforcer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Changes (by jakob): * owner: sion => jakob * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 24 21:17:13 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 24 Nov 2009 21:17:13 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #58: Schema for kasp.xml does not allow 0 values for salt and iterations In-Reply-To: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> References: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> Message-ID: <065.a3077244a7fa5bc4e98d02203f99ee5e@kirei.se> #58: Schema for kasp.xml does not allow 0 values for salt and iterations -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: sion Type: defect | Status: assigned Priority: major | Component: Enforcer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Changes (by jakob): * owner: jakob => sion Comment: Schema fixed in r2499 and r2500. Might need more work so I'll pass this ticket to sion (and then to matthijs) for further investigation. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 25 08:07:03 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 25 Nov 2009 08:07:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #59: Problem starting ods-signer on 64-bit systems In-Reply-To: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> References: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> Message-ID: <067.bb306c4fab5af2297fb09124d65da601@kirei.se> #59: Problem starting ods-signer on 64-bit systems ---------------------------------+------------------------------------------ Reporter: andyh@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: ---------------------------------+------------------------------------------ Comment(by matthijs): Forgot to commit the configure.ac file: try r2502 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 25 08:55:29 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 25 Nov 2009 08:55:29 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #59: Problem starting ods-signer on 64-bit systems In-Reply-To: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> References: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> Message-ID: <067.9b05b30d06c3e83d533645974fabd873@kirei.se> #59: Problem starting ods-signer on 64-bit systems ---------------------------------+------------------------------------------ Reporter: andyh@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: ---------------------------------+------------------------------------------ Comment(by andyh@?): I'm no developer, but should the first change not be @opendnsseclibdir@/signer? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 25 09:41:33 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 25 Nov 2009 09:41:33 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #58: Schema for kasp.xml does not allow 0 values for salt and iterations In-Reply-To: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> References: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> Message-ID: <065.4f719380169a790c5428ba48eac4b326@kirei.se> #58: Schema for kasp.xml does not allow 0 values for salt and iterations -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: matthijs Type: defect | Status: assigned Priority: major | Component: Enforcer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Changes (by sion): * owner: sion => matthijs Comment: The enforcer is fine with this; the only side-effect is that it tries to regenerate the salt every time it runs (as it sees that the salt is NULL). Unless you have thousands of policies this should not be a problem. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 25 09:44:21 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 25 Nov 2009 09:44:21 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #59: Problem starting ods-signer on 64-bit systems In-Reply-To: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> References: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> Message-ID: <067.5374f62669f50a2fe5b718eb29a1f575@kirei.se> #59: Problem starting ods-signer on 64-bit systems ---------------------------------+------------------------------------------ Reporter: andyh@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.0.0b8 | Keywords: ---------------------------------+------------------------------------------ Changes (by sion): * version: trunk => 1.0.0b8 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 25 11:55:01 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 25 Nov 2009 11:55:01 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #59: Problem starting ods-signer on 64-bit systems In-Reply-To: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> References: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> Message-ID: <067.4d5bc6724410356775755642dc59a4be@kirei.se> #59: Problem starting ods-signer on 64-bit systems ---------------------------------+------------------------------------------ Reporter: andyh@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.0.0b8 | Keywords: ---------------------------------+------------------------------------------ Comment(by matthijs): you are right, could you try latest trunk? -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Wed Nov 25 12:02:56 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 25 Nov 2009 12:02:56 +0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #58: Schema for kasp.xml does not allow 0 values for salt and iterations In-Reply-To: <4B0D1BCB.3050206@nlnetlabs.nl> References: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> <065.4f719380169a790c5428ba48eac4b326@kirei.se> <4B0D1BCB.3050206@nlnetlabs.nl> Message-ID: > > Hi, > > I think I missed the point why it was reassigned to me. What seems to be > the issue? > > Matthijs I think that the signer needs to be tested to check that it can cope with a NULL salt and 0 iterations? Then pass it on to Alex to check the auditor? Sion From matthijs at NLnetLabs.nl Wed Nov 25 12:05:43 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 25 Nov 2009 13:05:43 +0100 Subject: [Opendnssec-develop] Serial from working directory Message-ID: <4B0D1D97.4080809@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We had a discussion of where to get the current outputted serial from. This is needed to calculate the new outputted serial. Currently, it fetches that serial from the outputted signed zonefile. However, if the signed zonefile is moved to a different location, we cannot always calculate the new serial (datecounter and counter). So we need to fetch it from our internal storage. There are two suggested solutions to fix this: 1 Instead of moving the .finalized file to the output/signed directory, leave a copy and fetch the serial from there. Pro: Easiest, Con: Requires another copy of the zonefile on disk. 2 Write out a .serial file which contains the latest outputted serial. Pro: (Much) less disk storage. Con: Slightly more difficult. First question: Is this something that *needs* to be done before the rc? Imo, yes. Second question: What is the preferred method to do this? Imo, 2. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLDR2VAAoJEA8yVCPsQCW5Ef0H/0wxXhyLWepfze72mgB9VQUC 7eeAdt3zuWcfhmX5xrWXPGIk0j39sWw6ggDUHAHy3+/7MN5Zy2eBDKQvZ3CbIK2X wppoA4PWy6thR3wnqJIAv9ZURU5Z3/Bu2VhcFesrJ+0TLQHLKIOisFiLaqxunqeK bY7FZCvb9vb5o3g54y2tze3uCmAid0ICeTG11rt13PEgXtsZVwze36MwQIrY/YxL jP4WTnLdvvnQq/aXJs3hNolCweVFlha0htBnclKOeeKXrj5QF6WpDEo+mMImkslM IyCLE3QZUAb3Az7VhqVtwoM7k1qy6XRoBBnkSVaMajBCgXmF0MntQpBHGkHCrGw= =lIlL -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Wed Nov 25 12:17:46 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 25 Nov 2009 12:17:46 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #58: Schema for kasp.xml does not allow 0 values for salt and iterations In-Reply-To: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> References: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> Message-ID: <065.32b0112e42932ee587163b3745214a30@kirei.se> #58: Schema for kasp.xml does not allow 0 values for salt and iterations -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: alex Type: defect | Status: assigned Priority: major | Component: Enforcer Version: trunk | Keywords: -------------------------------+-------------------------------------------- Changes (by matthijs): * owner: matthijs => alex -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Wed Nov 25 12:39:10 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 25 Nov 2009 12:39:10 +0000 Subject: [Opendnssec-develop] Serial from working directory In-Reply-To: <4B0D1D97.4080809@nlnetlabs.nl> References: <4B0D1D97.4080809@nlnetlabs.nl> Message-ID: > We had a discussion of where to get the current outputted serial from. > This is needed to calculate the new outputted serial. > > Currently, it fetches that serial from the outputted signed zonefile. > However, if the signed zonefile is moved to a different location, we > cannot always calculate the new serial (datecounter and counter). So we > need to fetch it from our internal storage. > > There are two suggested solutions to fix this: > 1 Instead of moving the .finalized file to the output/signed directory, > leave a copy and fetch the serial from there. Pro: Easiest, Con: > Requires another copy of the zonefile on disk. > > 2 Write out a .serial file which contains the latest outputted serial. > Pro: (Much) less disk storage. Con: Slightly more difficult. Just FYI, the Auditor currently stores the last seen SOA in the /tracker folder. Not that it helps this problem... Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Wed Nov 25 12:41:28 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 25 Nov 2009 12:41:28 +0000 Subject: [Opendnssec-develop] Serial from working directory In-Reply-To: <4B0D1D97.4080809@nlnetlabs.nl> References: <4B0D1D97.4080809@nlnetlabs.nl> Message-ID: > We had a discussion of where to get the current outputted serial from. > This is needed to calculate the new outputted serial. > > Currently, it fetches that serial from the outputted signed zonefile. > However, if the signed zonefile is moved to a different location, we > cannot always calculate the new serial (datecounter and counter). So we > need to fetch it from our internal storage. > > There are two suggested solutions to fix this: > 1 Instead of moving the .finalized file to the output/signed directory, > leave a copy and fetch the serial from there. Pro: Easiest, Con: > Requires another copy of the zonefile on disk. > > 2 Write out a .serial file which contains the latest outputted serial. > Pro: (Much) less disk storage. Con: Slightly more difficult. > > > First question: > Is this something that *needs* to be done before the rc? > Imo, yes. > > Second question: > What is the preferred method to do this? > Imo, 2. I agree, yes and 2... Storing the whole zone seems excessive; also, is the .finalised file removed when the ods-signer clear ZONE command is issued? Sion From jakob at kirei.se Wed Nov 25 12:43:28 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 25 Nov 2009 13:43:28 +0100 Subject: [Opendnssec-develop] Serial from working directory In-Reply-To: <4B0D1D97.4080809@nlnetlabs.nl> References: <4B0D1D97.4080809@nlnetlabs.nl> Message-ID: <0AEDC139-0019-4592-9C77-D42B820F3F26@kirei.se> On 25 nov 2009, at 13.05, Matthijs Mekking wrote: > First question: > Is this something that *needs* to be done before the rc? > Imo, yes. > > Second question: > What is the preferred method to do this? > Imo, 2. I agree. /var/opendnssec/signed/zone.serial containing the last serial number only seems fair. jakob From rickard.bellgrim at iis.se Wed Nov 25 12:46:11 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 25 Nov 2009 13:46:11 +0100 Subject: [Opendnssec-develop] Meeting next week Message-ID: <983F17705339E24699AA251B458249B51F196799B6@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Are you ok with a meeting next Wednesday at 14 CET (13 GMT)? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSw0nE+CjgaNTdVjaAQgKXgf/bt1A1QxD+WnC3rXYgpZtWpASeItqJvvr apgXtPPyYxdYqPJ8x7n2WsqSq6UMnVz2vVT3kWn0BSxmpWtyvAMlNapwm2kbd4KA +G3S4kszcgwwYB3DYWejrftcsTHMj1GAJdSioAeeIBCvZlI0v8zb1j6M8mf3qs0M ZemNDxTS8g5R6vscUKQd4jyL4rH6ajNgUwJYgb+7xmlaxErJOIONmVYYk6I4Is2g KTlHHVowVcH6ZmzjKf9jICyULOsDXKEQHCZfe9ZSNm8G3F83eIRCPI05BjU19bfP xj3tKa13dwec8T1WIyYoO9EuWafDLOCb9ol8rwR+L1RvTX9N2gyuDQ== =xeAn -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Wed Nov 25 12:49:02 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 25 Nov 2009 13:49:02 +0100 Subject: [Opendnssec-develop] Meeting next week In-Reply-To: <983F17705339E24699AA251B458249B51F196799B6@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F196799B6@EXCHANGE2K7.office.nic.se> Message-ID: <4CD29047-7783-4A33-83CB-122ACEC1340E@kirei.se> On 25 nov 2009, at 13.46, Rickard Bellgrim wrote: > Are you ok with a meeting next Wednesday at 14 CET (13 GMT)? yes. perhaps we can schedule december 9 as well while we're at it? j From matthijs at NLnetLabs.nl Wed Nov 25 12:49:48 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 25 Nov 2009 13:49:48 +0100 Subject: [Opendnssec-develop] Serial from working directory In-Reply-To: References: <4B0D1D97.4080809@nlnetlabs.nl> Message-ID: <4B0D27EC.4070102@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 sion at nominet.org.uk wrote: > > I agree, yes and 2... Storing the whole zone seems excessive; also, is the > .finalised file removed when the ods-signer clear ZONE command is issued? Yes, are you suggesting that the .serial file should not be cleared on this command? Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLDSfqAAoJEA8yVCPsQCW5TzkIALo6hzphjC9RrT6BPMSf1XPw wHIPIboGPWS1iKnMPZuvh7/eafGbStSenVCgtKus0+CwXWdFIp4yyOcKPd8Tsjr8 uF4CJZ3Oo2dZ4+340+SUaO6Ou2YQRkfUy4yjt7uWCrM3IrZA80OPC6UJm51ywkl+ F2u9CwLZBzUF7sVBnfvKiSxDfi8b3YZ8cmvHkiDhntMFuDdsgCzdY3BRPHe2ehQ9 q2yVkytrbEywQaELdkcNaqKw/G/fsZGZpie3DIpohpchhPFDqLe/OmF1M0HUiFAL zjbiWgprFm6Dwd+7o6yfZeWNiGcCt/M4NAwK+nDQjSiD9ER4OmzsWPTASTFFQXo= =8OXy -----END PGP SIGNATURE----- From jakob at kirei.se Wed Nov 25 12:51:46 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 25 Nov 2009 13:51:46 +0100 Subject: [Opendnssec-develop] Serial from working directory In-Reply-To: <4B0D27EC.4070102@nlnetlabs.nl> References: <4B0D1D97.4080809@nlnetlabs.nl> <4B0D27EC.4070102@nlnetlabs.nl> Message-ID: On 25 nov 2009, at 13.49, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > sion at nominet.org.uk wrote: >> >> I agree, yes and 2... Storing the whole zone seems excessive; also, is the >> .finalised file removed when the ods-signer clear ZONE command is issued? > > Yes, are you suggesting that the .serial file should not be cleared on > this command? right, clear should not reset the serial number. perhaps a "reset" command could do that? jakob From matthijs at NLnetLabs.nl Wed Nov 25 13:19:21 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 25 Nov 2009 14:19:21 +0100 Subject: [Opendnssec-develop] Serial from working directory In-Reply-To: References: <4B0D1D97.4080809@nlnetlabs.nl> <4B0D27EC.4070102@nlnetlabs.nl> Message-ID: <4B0D2ED9.7080709@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm not too fond about adding a new command that does clear and clear the serial. Why shouldn't 'clear' clear the serial file? Isn't clear already meant to be 'start from scratch'? Matthijs Jakob Schlyter wrote: > On 25 nov 2009, at 13.49, Matthijs Mekking wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> sion at nominet.org.uk wrote: >>> I agree, yes and 2... Storing the whole zone seems excessive; also, is the >>> .finalised file removed when the ods-signer clear ZONE command is issued? >> Yes, are you suggesting that the .serial file should not be cleared on >> this command? > > right, clear should not reset the serial number. perhaps a "reset" command could do that? > > jakob > > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLDS7WAAoJEA8yVCPsQCW5bBcH/ioeX2XfeT8UXqZiLH4JkYEO nuyMTWTishVoger5xhdZT/6+jdJm17A/OGwrD4xzh+L1ZCBSOdk4f2IbhmagvIut dfR4lqhl5Kk2fte6rDpWixL5ZlwR7qDh5/YHMS1ZvXJDrxAjbB1nMcfx+RXZxurk QGE3Wra2uXzo45PM67JH37737XHHoi1d6AHhGsXoDGLI3FJMXLgNQB5olVlvMVne AiixekP86NWj+TSNMbRPmqDZML+O/+Kzn46WTV4Wyt8YVn+HCh+i+6UM3+ZpLReh MCcM/s69xwPCBQNjaoTQ34XotYlpa2q6wQviCZ8Rd6tTvvAxb1xptnbJ3W84T/U= =yxfj -----END PGP SIGNATURE----- From jakob at kirei.se Wed Nov 25 13:28:56 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 25 Nov 2009 14:28:56 +0100 Subject: [Opendnssec-develop] Serial from working directory In-Reply-To: <4B0D2ED9.7080709@nlnetlabs.nl> References: <4B0D1D97.4080809@nlnetlabs.nl> <4B0D27EC.4070102@nlnetlabs.nl> <4B0D2ED9.7080709@nlnetlabs.nl> Message-ID: <910D15D4-AF9D-43E0-A5BC-39B2C14ADE86@kirei.se> On 25 nov 2009, at 14.19, Matthijs Mekking wrote: > I'm not too fond about adding a new command that does clear and clear > the serial. Why shouldn't 'clear' clear the serial file? 'cause the serial might go backwards unless you keep state. > Isn't clear already meant to be 'start from scratch'? it could. or it could mean that you want to reissue all signatures. jakob From sion at nominet.org.uk Wed Nov 25 13:30:37 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 25 Nov 2009 13:30:37 +0000 Subject: [Opendnssec-develop] Serial from working directory In-Reply-To: <4B0D2ED9.7080709@nlnetlabs.nl> References: <4B0D1D97.4080809@nlnetlabs.nl> <4B0D27EC.4070102@nlnetlabs.nl> <4B0D2ED9.7080709@nlnetlabs.nl> Message-ID: > I'm not too fond about adding a new command that does clear and clear > the serial. Why shouldn't 'clear' clear the serial file? > > Isn't clear already meant to be 'start from scratch'? I've interpreted it as "throw away cached DNSSEC data", e.g. regenerate all signatures and NSEC information. We might routinely do this for .uk for instance, as we don't care about optimisation for such a small zone. I don't see rememering the SOA serial as an optimisation. This is just my interpretation of a command that I have not used very much though. Sion From matthijs at NLnetLabs.nl Wed Nov 25 13:47:07 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 25 Nov 2009 14:47:07 +0100 Subject: [Opendnssec-develop] Serial from working directory In-Reply-To: References: <4B0D1D97.4080809@nlnetlabs.nl> <4B0D27EC.4070102@nlnetlabs.nl> <4B0D2ED9.7080709@nlnetlabs.nl> Message-ID: <4B0D355B.2050202@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, then I propose to not remove the .serial file on clear and if people really want to reset their zone to rm -f stuff. Perhaps later we can find a better way to clear non-DNSSEC internal storage. Matthijs sion at nominet.org.uk wrote: >> I'm not too fond about adding a new command that does clear and clear >> the serial. Why shouldn't 'clear' clear the serial file? >> >> Isn't clear already meant to be 'start from scratch'? > > I've interpreted it as "throw away cached DNSSEC data", e.g. regenerate all > signatures and NSEC information. We might routinely do this for .uk for > instance, as we don't care about optimisation for such a small zone. I > don't see rememering the SOA serial as an optimisation. > > This is just my interpretation of a command that I have not used very much > though. > > Sion > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLDTVZAAoJEA8yVCPsQCW5VGQIANmAubXMPgSn+cNITZwZdIdB CBzEBaBYRe/6bjt9srCFgHUi47vu5Ioq2qyWwuct/8l5wWbo62N+jaF6lyjFbABy x6iiVIvpH/qiXppstdoAa1yreRwLubbY2w2mhcUI5sPOdE7skjGFlgSFGz0BW+Th OEW/3PKl7xvcdiPIkhM/4alS59CNfgtrWn6A3W8FDxBa1ZBUCee4zvgcaSk25K+g v9nFZmRpn17mezaHJfBbqvUuxmsBN1Pb9RBw+c9jV8mQtjogdUlvzbtXdKQHcz9T LwDnlc8QxVFwSP8id19ZjWO84V0BcwRpEO4X6FYPTRDWNRmY/nQcws6/ISvkyIo= =boxa -----END PGP SIGNATURE----- From roland.vanrijswijk at surfnet.nl Wed Nov 25 21:08:57 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 25 Nov 2009 22:08:57 +0100 Subject: [Opendnssec-develop] Updated requirements for SoftHSM v2 Message-ID: <4B0D9CE9.3080605@surfnet.nl> Hi all, I've updated the SoftHSM requirements on the Wiki for SoftHSM v2 based on the discussions we had last week in Utrecht. http://trac.opendnssec.org/wiki/SoftHSM/Requirements Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Thu Nov 26 07:32:50 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 26 Nov 2009 08:32:50 +0100 Subject: [Opendnssec-develop] Updated requirements for SoftHSM v2 In-Reply-To: <4B0D9CE9.3080605@surfnet.nl> References: <4B0D9CE9.3080605@surfnet.nl> Message-ID: <603E1BAD-9776-41EF-8333-5EF2880AE7C8@kirei.se> On 25 nov 2009, at 22.08, Roland van Rijswijk wrote: > I've updated the SoftHSM requirements on the Wiki for SoftHSM v2 based > on the discussions we had last week in Utrecht. > > http://trac.opendnssec.org/wiki/SoftHSM/Requirements some questions and comments: #4, can we require 4096-bits as well? or make 4096 a should. #8, why is it a "MUST NOT" to export in BIND format? if softhsm-keyconv is not available as a separate program, we need something to convert to/from PKCS#8 and BIND format. do we have any relative performance requirements? like scale linear with multiple keys. jakob From owner-dnssec-trac at kirei.se Thu Nov 26 11:09:36 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 26 Nov 2009 11:09:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #58: Schema for kasp.xml does not allow 0 values for salt and iterations In-Reply-To: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> References: <056.cb6ed2a711f153a23aba826441e54105@kirei.se> Message-ID: <065.64a62ec4f6a576d842f45f4851a7645e@kirei.se> #58: Schema for kasp.xml does not allow 0 values for salt and iterations -------------------------------+-------------------------------------------- Reporter: tom@? | Owner: alex Type: defect | Status: closed Priority: major | Component: Enforcer Version: trunk | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Changes (by alex): * status: assigned => closed * resolution: => fixed Comment: The enforcer and signer have been fixed to read/write empty salt as "-" to the SignerConfiguration file (as per NSEC3 presentation format). I've successfully signed and audited a zone using empty salt. -- Ticket URL: OpenDNSSEC OpenDNSSEC From roland.vanrijswijk at surfnet.nl Thu Nov 26 11:54:34 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 26 Nov 2009 12:54:34 +0100 Subject: [Opendnssec-develop] Updated requirements for SoftHSM v2 In-Reply-To: <603E1BAD-9776-41EF-8333-5EF2880AE7C8@kirei.se> References: <4B0D9CE9.3080605@surfnet.nl> <603E1BAD-9776-41EF-8333-5EF2880AE7C8@kirei.se> Message-ID: <4B0E6C7A.4020200@surfnet.nl> Hi Jakob, Jakob Schlyter wrote: > some questions and comments: > > #4, can we require 4096-bits as well? or make 4096 a should. I think we can add 4096-bits as a should. Realistically, the key size is probably not going to be limited by the SoftHSM implementation, and we specifically did not want to specify an upper limit which is why we chose the wording "2048-bits or more" > #8, why is it a "MUST NOT" to export in BIND format? if > softhsm-keyconv is not available as a separate program, we need > something to convert to/from PKCS#8 and BIND format. The rationale behind this requirements is the following: we would like to use one tool in stead of two. Also, the tool will be based on PKCS #11 operations so it can also work with 'real' HSMs and not just SoftHSM. That one tool must support import of keys in BIND format, but we reasoned that it should not support key export in BIND format for two reasons: - Exporting keys in BIND format would lower the security level because the keys would then be exported in the clear; this becomes especially relevant if you use the tool with a real HSM - We support import of BIND formatted keys; if someone would like to switch from OpenDNSSEC to BIND, we argued that in that case BIND should support import of OpenDNSSEC (= PKCS #8) formatted keys. > do we have any relative performance requirements? like scale linear > with multiple keys. No not yet, but suggestions like this one are welcome. Thanks for your feedback! Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Thu Nov 26 12:08:51 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 26 Nov 2009 13:08:51 +0100 Subject: [Opendnssec-develop] Updated requirements for SoftHSM v2 In-Reply-To: <4B0E6C7A.4020200@surfnet.nl> References: <4B0D9CE9.3080605@surfnet.nl> <603E1BAD-9776-41EF-8333-5EF2880AE7C8@kirei.se> <4B0E6C7A.4020200@surfnet.nl> Message-ID: <5409DA28-550A-4EE9-AC1B-C357B553AF77@kirei.se> On 26 nov 2009, at 12.54, Roland van Rijswijk wrote: > - Exporting keys in BIND format would lower the security level because > the keys would then be exported in the clear; this becomes especially > relevant if you use the tool with a real HSM I'm all for not exporting keys in BIND format, but the key conversion tool should probably be around somehow. perhaps it is better suited to be included in BIND though. jakob From roland.vanrijswijk at surfnet.nl Thu Nov 26 12:22:15 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 26 Nov 2009 13:22:15 +0100 Subject: [Opendnssec-develop] Updated requirements for SoftHSM v2 In-Reply-To: <5409DA28-550A-4EE9-AC1B-C357B553AF77@kirei.se> References: <4B0D9CE9.3080605@surfnet.nl> <603E1BAD-9776-41EF-8333-5EF2880AE7C8@kirei.se> <4B0E6C7A.4020200@surfnet.nl> <5409DA28-550A-4EE9-AC1B-C357B553AF77@kirei.se> Message-ID: <4B0E72F7.4080406@surfnet.nl> Perhaps we could keep a stripped down version of the current tool in a 'contrib' folder (i.e. non-supported)? Cheers, Roland Jakob Schlyter wrote: > On 26 nov 2009, at 12.54, Roland van Rijswijk wrote: > >> - Exporting keys in BIND format would lower the security level because >> the keys would then be exported in the clear; this becomes especially >> relevant if you use the tool with a real HSM > > I'm all for not exporting keys in BIND format, but the key conversion tool should probably be around somehow. perhaps it is better suited to be included in BIND though. > > jakob > -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From Alexd at nominet.org.uk Thu Nov 26 12:22:36 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 26 Nov 2009 12:22:36 +0000 Subject: [Opendnssec-develop] ods-control start Message-ID: Hi - I have a problem with "ods-control start" on OSX. The call "ods-signer start" (which is made by the "ods-control start" command) does not work on OSX - it complains about pthread_cond_wait invalid arguments (possibly some sort of Python artefact?). Fixing "ods-signer start" would be ideal. However, in the absence of a fix for this, what do people think to changing the "ods-control start" command to start ods-signerd, rather than call "ods-signer start"? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Thu Nov 26 13:12:19 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 26 Nov 2009 14:12:19 +0100 Subject: [Opendnssec-develop] Knowing what processes hangs on. Message-ID: <983F17705339E24699AA251B458249B51F19679BE9@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Is there a way to know what e.g. the signer program hangs on? To dump its stack. Because I think there might be a dead lock situation in the SoftHSM. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSw5+s+CjgaNTdVjaAQjsugf/cWOChpXuZpJN/uW4jHB20pZzVDdoD+L9 5vLHLoivbG0ZRcqI/8x7H0XLiKrtE2bW8a7zpx1+pevjNQopKvi4L0PeX2IWI7N0 DyBv+dOvCBuG02xZMGcP2o88Cq7hQUkHLnbWFOuOv6M1VyvaSDBqoNVbeQ9wXSM7 rzBmBsv1p5rskIDK/uxLIM06LMBTmK1M7CWV3izky8ohL1CqqnzpYCfx1QkLv7l8 lhS5RvseGXXSiUD7C+p0kqQSvlX1REMYPcmDijlrTN+3q2an81ZCfLtk46bbQiMb K0Mb6y9JJWuBsNi1DphE5HDNyy4Op2KDcL7EPlSXPOT3vBZZzryDIg== =SxyZ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrik.wallstrom at iis.se Thu Nov 26 14:25:17 2009 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Thu, 26 Nov 2009 15:25:17 +0100 Subject: [Opendnssec-develop] new theme on opendnssec.org Message-ID: The new theme is live now. http://www.opendnssec.org/ -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From matthijs at NLnetLabs.nl Thu Nov 26 15:17:37 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 26 Nov 2009 16:17:37 +0100 Subject: [Opendnssec-develop] new theme on opendnssec.org In-Reply-To: References: Message-ID: <4B0E9C11.4030508@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a minor note: Could the description in the rss feed change from "Just another WordPress weblog" into something more useful? Matthijs Patrik Wallstr?m wrote: > The new theme is live now. > http://www.opendnssec.org/ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLDpwPAAoJEA8yVCPsQCW5NOMH/2xIQvnz+keqB9FUGN6e0Yeq jlMfb8lNybOcOlDryDmZ/1PMzLAptqjdItYYESgyQWCRM1jaRhyLjNJWfFhtvWph fK0RzQT9c8b9m5+bq+XyB38OViqpZYhOEUsvYSWZm2WKyWhxw18bIeITHbNfj5Tt zuke0cjVzNm9IkSalkGiRqw2C6eqGB2N9BaVNRM68ZZAOPF4Zj+kV1pgoOS2sKTE 92UdD/n9DnBjiziu4wD4eJ2HaJiq0kVLnnTQOMkAKeTr/qmbW7DZ0mOkxP1omtuX njUWPbLho2NiFEqujfAgc6U7/TyTOaGI0jt1YKJzzhKq3q1OdDONcjl8QXVBhi0= =VNiF -----END PGP SIGNATURE----- From patrik.wallstrom at iis.se Thu Nov 26 17:15:57 2009 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Thu, 26 Nov 2009 18:15:57 +0100 Subject: [Opendnssec-develop] new theme on opendnssec.org In-Reply-To: <4B0E9C11.4030508@nlnetlabs.nl> References: <4B0E9C11.4030508@nlnetlabs.nl> Message-ID: <11A81707-2370-44A1-B811-92E4A2C87DAD@iis.se> On Nov 26, 2009, at 4:17 PM, Matthijs Mekking wrote: > Just a minor note: > > Could the description in the rss feed change from "Just another > WordPress weblog" into something more useful? Fixed! -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From jakob at kirei.se Thu Nov 26 19:06:12 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 26 Nov 2009 20:06:12 +0100 Subject: [Opendnssec-develop] new theme on opendnssec.org In-Reply-To: References: Message-ID: On 26 nov 2009, at 15.25, Patrik Wallstr?m wrote: > The new theme is live now. > http://www.opendnssec.org/ nice work! and kudos to M?ns at .SE for all the work on the theme. jakob From owner-dnssec-trac at kirei.se Fri Nov 27 07:52:39 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 27 Nov 2009 07:52:39 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #59: Problem starting ods-signer on 64-bit systems In-Reply-To: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> References: <058.f6ce0673eba532dc4248848eef949a98@kirei.se> Message-ID: <067.b8681fba5f01caa61f0a541af8b92ebc@kirei.se> #59: Problem starting ods-signer on 64-bit systems ---------------------------------+------------------------------------------ Reporter: andyh@? | Owner: matthijs Type: defect | Status: closed Priority: minor | Component: Signer Version: 1.0.0b8 | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Changes (by matthijs): * status: new => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Fri Nov 27 08:07:42 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 27 Nov 2009 09:07:42 +0100 Subject: [Opendnssec-develop] Re: [Opendnssec-commits] [keihatsu.kirei.se/svn/dnssec] r2525 - trunk/OpenDNSSEC In-Reply-To: <20091127075904.004316BDE0@mail.kirei.se> References: <20091127075904.004316BDE0@mail.kirei.se> Message-ID: <08CBB54F-AA06-4CBD-83A7-48FC6FF50944@kirei.se> On 27 nov 2009, at 08.59, Matthijs Mekking wrote: > +* Signer Engine: verifies signature after creation. what is the performance penalty on this? is verification done using PKCS#11 or locally? jakob From matthijs at NLnetLabs.nl Fri Nov 27 08:40:05 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 27 Nov 2009 09:40:05 +0100 Subject: [Opendnssec-develop] Re: [Opendnssec-commits] [keihatsu.kirei.se/svn/dnssec] r2525 - trunk/OpenDNSSEC In-Reply-To: <08CBB54F-AA06-4CBD-83A7-48FC6FF50944@kirei.se> References: <20091127075904.004316BDE0@mail.kirei.se> <08CBB54F-AA06-4CBD-83A7-48FC6FF50944@kirei.se> Message-ID: <4B0F9065.1000800@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakob Schlyter wrote: > On 27 nov 2009, at 08.59, Matthijs Mekking wrote: > >> +* Signer Engine: verifies signature after creation. > > what is the performance penalty on this? > is verification done using PKCS#11 or locally? > > jakob > For a 416K tld alike zone, the initial signing time increased from 1m25 to 1m42 on my Ubuntu desktop machine. Verification is done locally with ldns_verify_rrsig_keylist. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLD5BjAAoJEA8yVCPsQCW51wAIAJx44LSh2CV7ecRvsG0A8RBG rTnLNbFg/fJYJXJ1EAD7K1kuLRMOry4pZt3mXnDXh6RhLv+hmyzfonkKWVkfSq4o Xw8GDHzX8i8Kc6jve49RCU2vyU+FL7Mb6XilxvoE/UZfAaSVACb+gT6YNmdTbiwd d1cRFIC6nt9MsfnX92ZVF/6Nwbbt+n4c2djom/NWQ8IIHc/Af1WUmScs6P6VRjOb upOMeNP4v3fc8x/psd623o3KXsUkstEBzumwseabv5wQWKitf0F9fiQ17FqDPGNl GJRYYKDig1WP8oa3gwgqRcEoFe+lFjyND9J/lyF/84kvocdZapSqXqB7DTswBf4= =ftAc -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Fri Nov 27 08:51:35 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 27 Nov 2009 09:51:35 +0100 Subject: [Opendnssec-develop] Re: [Opendnssec-commits] [keihatsu.kirei.se/svn/dnssec] r2525 - trunk/OpenDNSSEC In-Reply-To: <4B0F9065.1000800@nlnetlabs.nl> References: <20091127075904.004316BDE0@mail.kirei.se> <08CBB54F-AA06-4CBD-83A7-48FC6FF50944@kirei.se> <4B0F9065.1000800@nlnetlabs.nl> Message-ID: <4B0F9317.7020909@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Perhaps some more useful statistics: With verification: ods-signerd: signer stderr: signer: number of signatures created: 20005 (196 rr/sec) Without verification: ods-signerd: signer stderr: signer: number of signatures created: 20005 (235 rr/sec) Matthijs Mekking wrote: > Jakob Schlyter wrote: >> On 27 nov 2009, at 08.59, Matthijs Mekking wrote: > >>> +* Signer Engine: verifies signature after creation. >> what is the performance penalty on this? >> is verification done using PKCS#11 or locally? > >> jakob > > > For a 416K tld alike zone, the initial signing time increased from 1m25 > to 1m42 on my Ubuntu desktop machine. > > Verification is done locally with ldns_verify_rrsig_keylist. > > 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 iQEcBAEBAgAGBQJLD5MSAAoJEA8yVCPsQCW5nigH/j2prat09R2tzzoAc8rR7sYk awvvYX//3uLmORloDs7v6kkOmrkslBqqM/wsM0Odndrk2bRSwr+7WD3WSEzy97im vM2LmSlYtI2Fo4BSRaN3odmW3HqXvg3DxtDUzGGvk7o3uaTvYSIxtYvIX4RAQ1ks JJbj+E7iXwFjIc6lkTsCUvtceiTVlOmosCyXzzO/rLpzmK8wy1bS48Tf8IqDXdRz KBQEjCgwEtVe4Y8U3rVJR7x6vGl69doQYbRQfnp9AxddHQUTN6QXwSZHbp/8OVkA UrMB9Sg6oRBpyoAMBfHtdDjIK8XAr+zrXR8XlohDy2jFsW3VzF9ZeuF8D5LPOLk= =OM0G -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Fri Nov 27 11:20:02 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 27 Nov 2009 12:20:02 +0100 Subject: [Opendnssec-develop] signature verification Message-ID: <4B0FB5E2.5010307@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We have discovered that the signer with softHSM sometimes can output an invalid signature. In order to prevent this ending up in the signed zonefile, we should audit the signatures. Of course, we have the auditor, but we discourage people to turn it off for large zones. So, I have added a signature check in the signer, right after libhsm returned it. This option adds about 19% latency on signature creation. Thus, we should make this option configurable. I'm not sure where this option should go, build or run time? We could also add a third signature check in the softHSM. Imo, that could facilitate debugging, assuming that the bug is in Botan. Any thoughts? Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLD7XaAAoJEA8yVCPsQCW5uooH/2f79qdwil3w7V09fYpHe9KJ gX1ADooCsqRaW3tagIIiuuhUCDRPcOpLJ0YdvOXr3rMeX0IL8jXz9xyF2CpajLtM WhQ/+YiiWl+uGVaiam56kwELDqMkL5Zin04ZFm4W6K1wXAcQM4o/5iO+1yKp5TwV oKBpQvHAnS/vBXvCHfrs9Rr5z4axLrnccFVNZ2SqK4kxxWAUqNaZB5pp9kpjguKG YRQefFYz3sUYN8jvhr2rpzItjmCdJ73auIabk6T0KtuBpjwGJ5lrf816S88tL9IJ aqh9GJ6tt/tDaOJkFOggFMXO+IrW2/+Wy59togEtpOeVUGRWQV0V3DBVQLC0pkk= =qMfF -----END PGP SIGNATURE----- From Alexd at nominet.org.uk Fri Nov 27 11:23:37 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Fri, 27 Nov 2009 11:23:37 +0000 Subject: [Opendnssec-develop] signature verification In-Reply-To: <4B0FB5E2.5010307@nlnetlabs.nl> References: <4B0FB5E2.5010307@nlnetlabs.nl> Message-ID: > So, I have added a signature check in the signer, right after libhsm > returned it. This option adds about 19% latency on signature creation. > Thus, we should make this option configurable. I think, while there is a known bug in the signer which causes bad signatures to be returned, that this check should ALWAYS be on. Otherwise, OpenDNSSEC may sign zones with invalid signatures - and if the auditor is not enabled, then this will not be caught. Of course, if the auditor is enabled, then the check is redundant. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Fri Nov 27 14:25:51 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Fri, 27 Nov 2009 14:25:51 +0000 Subject: [Opendnssec-develop] RC1 Message-ID: Hi - As discussed at the teleconference last week, Nominet has committed to signing the uk zone in January 2010. This means that we need to start the formal testing of the signing system very soon. To do this, we would really like to have an OpenDNSSEC RC1 release (we are uncomfortable signing uk in production with a beta release). ISTR that people weren't overjoyed with this idea, but were prepared to agree, given that the outstanding Pivotal issues were resolved. The major one of these was the Invalid Signature bug, which has been worked around for now (and a real solution is likely to take a long time). There are also some ZoneFetcher issues which really should be fixed. Other than that, I think most issues are resolved. So... If we can fix the ZoneFetcher issues in time, how do people feel about labelling a release candidate 1 after the teleconference on Wednesday 2nd? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Fri Nov 27 14:27:00 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 27 Nov 2009 15:27:00 +0100 Subject: [Opendnssec-develop] RC1 In-Reply-To: References: Message-ID: On 27 nov 2009, at 15.25, Alexd at nominet.org.uk wrote: > If we can fix the ZoneFetcher issues in time, how do people feel about labelling a release candidate 1 after the teleconference on Wednesday 2nd? given that we resolve those issues, I'd be fine with tagging rc1 next week. j From roland.vanrijswijk at surfnet.nl Fri Nov 27 15:42:03 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Fri, 27 Nov 2009 16:42:03 +0100 Subject: [Opendnssec-develop] signature verification In-Reply-To: <4B0FB5E2.5010307@nlnetlabs.nl> References: <4B0FB5E2.5010307@nlnetlabs.nl> Message-ID: <4B0FF34B.6020803@surfnet.nl> Hi Matthijs, IMHO this is a blocking issue, right? It is not acceptable if the signatures output by the signer are invalid because of a bug in either softHSM or Botan. I assume that Rickard is checking out what causes this? If this cannot be fixed at short notice we should consider a 'plan B' so the release of OpenDNSSEC does not have to be postponed because of a bug in either softHSM or Botan. BTW, is it a reproducable bug -- i.e. will it consistently output a wrong signature given the same input data or is the problem intermittent? (the latter would be far worse than the former) Cheers, Roland Matthijs Mekking wrote: > Hi, > > We have discovered that the signer with softHSM sometimes can output an > invalid signature. > > In order to prevent this ending up in the signed zonefile, we should > audit the signatures. Of course, we have the auditor, but we discourage > people to turn it off for large zones. > > So, I have added a signature check in the signer, right after libhsm > returned it. This option adds about 19% latency on signature creation. > Thus, we should make this option configurable. > > I'm not sure where this option should go, build or run time? > > We could also add a third signature check in the softHSM. Imo, that > could facilitate debugging, assuming that the bug is in Botan. > > > Any thoughts? > > > Matthijs _______________________________________________ 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 rickard.bellgrim at iis.se Fri Nov 27 19:07:05 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 27 Nov 2009 20:07:05 +0100 Subject: [Opendnssec-develop] signature verification In-Reply-To: <4B0FF34B.6020803@surfnet.nl> References: <4B0FB5E2.5010307@nlnetlabs.nl> <4B0FF34B.6020803@surfnet.nl> Message-ID: <166E8038-8953-417D-9628-6514B26F0A4E@iis.se> Sorry. I have been visiting SWITCH for two days. Will start Monday morning to start testing and see if it can be reproduced in Botan. 27 nov 2009 kl. 16.43 skrev "Roland van Rijswijk" : > Hi Matthijs, > > IMHO this is a blocking issue, right? It is not acceptable if the > signatures output by the signer are invalid because of a bug in either > softHSM or Botan. I assume that Rickard is checking out what causes > this? If this cannot be fixed at short notice we should consider a > 'plan > B' so the release of OpenDNSSEC does not have to be postponed > because of > a bug in either softHSM or Botan. > > BTW, is it a reproducable bug -- i.e. will it consistently output a > wrong signature given the same input data or is the problem > intermittent? (the latter would be far worse than the former) > > Cheers, > > Roland > > Matthijs Mekking wrote: >> Hi, >> >> We have discovered that the signer with softHSM sometimes can >> output an >> invalid signature. >> >> In order to prevent this ending up in the signed zonefile, we should >> audit the signatures. Of course, we have the auditor, but we >> discourage >> people to turn it off for large zones. >> >> So, I have added a signature check in the signer, right after libhsm >> returned it. This option adds about 19% latency on signature >> creation. >> Thus, we should make this option configurable. >> >> I'm not sure where this option should go, build or run time? >> >> We could also add a third signature check in the softHSM. Imo, that >> could facilitate debugging, assuming that the bug is in Botan. >> >> >> Any thoughts? >> >> >> Matthijs > _______________________________________________ > 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 > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From roy at nominet.org.uk Fri Nov 27 19:48:26 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 27 Nov 2009 19:48:26 +0000 Subject: [Opendnssec-develop] signature verification In-Reply-To: <4B0FF34B.6020803@surfnet.nl> References: <4B0FB5E2.5010307@nlnetlabs.nl> <4B0FF34B.6020803@surfnet.nl> Message-ID: Roland van Rijswijk wrote on 11/27/2009 03:42:03 PM: > Hi Matthijs, > > IMHO this is a blocking issue, right? It is not acceptable if the > signatures output by the signer are invalid because of a bug in either > softHSM or Botan. I assume that Rickard is checking out what causes > this? At the moment it is unknown if the bug is in softhsm/botan or the signer. The work-around is to verify signatures immediately in two places: softhsm/botan and the signer and when a signature fails, log it, regenerate it immediately, check it, etc. > If this cannot be fixed at short notice we should consider a 'plan > B' so the release of OpenDNSSEC does not have to be postponed because of > a bug in either softHSM or Botan. We don't know where the bug is, as it might just as well be in opendnssec part, and I don't want to assume anything right now. The 'plan b' is the work-around above. That work-around guarantees that there will not be any false signatures due to this specific bug. > BTW, is it a reproducable bug -- i.e. will it consistently output a > wrong signature given the same input data or is the problem > intermittent? (the latter would be far worse than the former) The latter. It only occurred once. On 2009-11-23 12:52:08. We haven't been able to reproduce it. We're going to soak-test it, starting monday. Continuous signing loop on softhsm without the ods signer. Continuous signing loop on an sca6000 using OpenDNSSEC. There are a few coincidences. 1) The first 52 characters (40 bytes) of the bad signature are correct. The presentation format causes a wrap after 26 characters. So the first two lines of the presentation format are correct. This might be a complete coincidence, but worth checking out. (this is the signer part). 2) Additionally, 40 bytes is a multiple of 20 bytes, which is exactly the size of the output of SHA1. This is even more far fetched, but I'm just thinking out loud. (this is botan/softhsm). Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy at nominet.org.uk Fri Nov 27 20:42:55 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 27 Nov 2009 21:42:55 +0100 Subject: [Opendnssec-develop] signature verification In-Reply-To: References: <4B0FB5E2.5010307@nlnetlabs.nl> <4B0FF34B.6020803@surfnet.nl> Message-ID: Roy Arends wrote on 11/27/2009 08:48:26 PM: > 1) The first 52 characters (40 bytes) of the bad signature are That should be 54 characters (40 bytes) > correct. The presentation format causes a wrap after 26 characters. That should be 27 characters. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Fri Nov 27 20:46:18 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 27 Nov 2009 21:46:18 +0100 Subject: [Opendnssec-develop] RC1 In-Reply-To: References: Message-ID: <0D13061E-E824-4172-AC82-365CA0B43769@iis.se> +1 27 nov 2009 kl. 15.27 skrev "Jakob Schlyter" : > On 27 nov 2009, at 15.25, Alexd at nominet.org.uk wrote: > >> If we can fix the ZoneFetcher issues in time, how do people feel >> about labelling a release candidate 1 after the teleconference on >> Wednesday 2nd? > > given that we resolve those issues, I'd be fine with tagging rc1 > next week. > > j > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From roy at nominet.org.uk Fri Nov 27 20:48:55 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 27 Nov 2009 21:48:55 +0100 Subject: [Opendnssec-develop] RC1 In-Reply-To: <0D13061E-E824-4172-AC82-365CA0B43769@iis.se> References: <0D13061E-E824-4172-AC82-365CA0B43769@iis.se> Message-ID: Rickard Bellgrim wrote on 11/27/2009 09:46:18 PM: > +1 > > 27 nov 2009 kl. 15.27 skrev "Jakob Schlyter" : > > > On 27 nov 2009, at 15.25, Alexd at nominet.org.uk wrote: > > > >> If we can fix the ZoneFetcher issues in time, how do people feel > >> about labelling a release candidate 1 after the teleconference on > >> Wednesday 2nd? > > > > given that we resolve those issues, I'd be fine with tagging rc1 > > next week. +1 Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.vanrijswijk at surfnet.nl Sat Nov 28 12:18:58 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Sat, 28 Nov 2009 13:18:58 +0100 Subject: [Opendnssec-develop] signature verification In-Reply-To: References: <4B0FB5E2.5010307@nlnetlabs.nl> <4B0FF34B.6020803@surfnet.nl> Message-ID: <4B111532.8020801@surfnet.nl> Hi Roy, Roy Arends wrote: > Roland van Rijswijk wrote on 11/27/2009 03:42:03 PM: > > At the moment it is unknown if the bug is in softhsm/botan or the > signer. The work-around is to verify signatures immediately in two > places: softhsm/botan and the signer and when a signature fails, log it, > regenerate it immediately, check it, etc. OK, I read in Matthijs report that it seemed to be in softHSM/Botan but of course it might just as well be in the signer. > We don't know where the bug is, as it might just as well be in > opendnssec part, and I don't want to assume anything right now. The > 'plan b' is the work-around above. That work-around guarantees that > there will not be any false signatures due to this specific bug. OK, but I'm sure you agree that can't be a permanent solution right? If debugging shows that the problem is in the signer then this would block release of a final 1.0 in my opinion; if - on the other hand - it turns out to be a bug in either SoftHSM or Botan then I don't think this bug should block release of OpenDNSSEC, right? >> BTW, is it a reproducable bug -- i.e. will it consistently output a >> wrong signature given the same input data or is the problem >> intermittent? (the latter would be far worse than the former) > > The latter. It only occurred once. On 2009-11-23 12:52:08. We haven't > been able to reproduce it. Hmmm... that's nasty. > We're going to soak-test it, starting monday. Continuous signing loop on > softhsm without the ods signer. Continuous signing loop on an sca6000 > using OpenDNSSEC. OK, we're going to start test with the Safenet Luna HSM that I received yesterday starting next Friday, so if it has still not been found by then, let me know if we can assist with a different HSM brand. > There are a few coincidences. > > 1) The first 52 characters (40 bytes) of the bad signature are correct. > The presentation format causes a wrap after 26 characters. So the first > two lines of the presentation format are correct. This might be a > complete coincidence, but worth checking out. (this is the signer part). > 2) Additionally, 40 bytes is a multiple of 20 bytes, which is exactly > the size of the output of SHA1. This is even more far fetched, but I'm > just thinking out loud. (this is botan/softhsm). Coincidence number 1 could be caused by some arcane bug in output code, although one would expect it to be more consistent in that case. Coincidence number 2 must be purely a coincidence. There is no relation between the signature size and data and the hash size from the RSA operation perspective; the signature creation data (= padding + algo-id + hash) is simply treated as an n-bit big integer (where n = modulus length) so there should be no relation here... 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 Sat Nov 28 12:22:07 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Sat, 28 Nov 2009 13:22:07 +0100 Subject: [Opendnssec-develop] Updated requirements for SoftHSM v2 In-Reply-To: <603E1BAD-9776-41EF-8333-5EF2880AE7C8@kirei.se> References: <4B0D9CE9.3080605@surfnet.nl> <603E1BAD-9776-41EF-8333-5EF2880AE7C8@kirei.se> Message-ID: <4B1115EF.7070403@surfnet.nl> Hi Jakob, > #4, can we require 4096-bits as well? or make 4096 a should. I've added a should for 4096-bits. > do we have any relative performance requirements? like scale linear with multiple keys. I'm not sure I understand what you mean with the scaling remark; are you talking about RSA signature computation performance? Or about the number of keys that SoftHSM stores? Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Sat Nov 28 21:30:03 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Sat, 28 Nov 2009 22:30:03 +0100 Subject: [Opendnssec-develop] Updated requirements for SoftHSM v2 In-Reply-To: <4B1115EF.7070403@surfnet.nl> References: <4B0D9CE9.3080605@surfnet.nl> <603E1BAD-9776-41EF-8333-5EF2880AE7C8@kirei.se> <4B1115EF.7070403@surfnet.nl> Message-ID: <00D1A039-69DC-49DF-9C45-34554A693D12@kirei.se> On 28 nov 2009, at 13.22, Roland van Rijswijk wrote: >> do we have any relative performance requirements? like scale linear with multiple keys. > > I'm not sure I understand what you mean with the scaling remark; are you > talking about RSA signature computation performance? Or about the number > of keys that SoftHSM stores? I was more thinking about a large amount of keys with consistent access speed. the current SoftHSM doesn't scale that good when it comes to key count. jakob From roland.vanrijswijk at surfnet.nl Sun Nov 29 14:46:02 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Sun, 29 Nov 2009 15:46:02 +0100 Subject: [Opendnssec-develop] Updated requirements for SoftHSM v2 In-Reply-To: <00D1A039-69DC-49DF-9C45-34554A693D12@kirei.se> References: <4B0D9CE9.3080605@surfnet.nl> <603E1BAD-9776-41EF-8333-5EF2880AE7C8@kirei.se> <4B1115EF.7070403@surfnet.nl> <00D1A039-69DC-49DF-9C45-34554A693D12@kirei.se> Message-ID: <4B12892A.7080802@surfnet.nl> Hi Jakob, OK, I'll add that requirement. The new design we have in mind should cope better in that respect. Cheers, Roland Jakob Schlyter wrote: > On 28 nov 2009, at 13.22, Roland van Rijswijk wrote: > >>> do we have any relative performance requirements? like scale linear with multiple keys. >> I'm not sure I understand what you mean with the scaling remark; are you >> talking about RSA signature computation performance? Or about the number >> of keys that SoftHSM stores? > > I was more thinking about a large amount of keys with consistent access speed. the current SoftHSM doesn't scale that good when it comes to key count. > > jakob > -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From patrik.wallstrom at iis.se Mon Nov 30 06:57:11 2009 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Mon, 30 Nov 2009 07:57:11 +0100 Subject: [Opendnssec-develop] Updated requirements for SoftHSM v2 In-Reply-To: <00D1A039-69DC-49DF-9C45-34554A693D12@kirei.se> References: <4B0D9CE9.3080605@surfnet.nl> <603E1BAD-9776-41EF-8333-5EF2880AE7C8@kirei.se> <4B1115EF.7070403@surfnet.nl> <00D1A039-69DC-49DF-9C45-34554A693D12@kirei.se> Message-ID: On Nov 28, 2009, at 10:30 PM, Jakob Schlyter wrote: > On 28 nov 2009, at 13.22, Roland van Rijswijk wrote: > >>> do we have any relative performance requirements? like scale linear with multiple keys. >> >> I'm not sure I understand what you mean with the scaling remark; are you >> talking about RSA signature computation performance? Or about the number >> of keys that SoftHSM stores? > > I was more thinking about a large amount of keys with consistent access speed. the current SoftHSM doesn't scale that good when it comes to key count. I suspect this is only due to some INDEX missing in the database design. If somebody have the time to test SoftHSM v1 properly, we could hunt it down. I did it when I created a couple of thousand keys some months ago, and fixed the most serious one. Don't know what is left though. -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From rickard.bellgrim at iis.se Mon Nov 30 10:57:07 2009 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 30 Nov 2009 11:57:07 +0100 Subject: [Opendnssec-develop] Meeting 20091202 Message-ID: <983F17705339E24699AA251B458249B51F196DBB10@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Next meeting is on: Date: Wednesday 2 December Time: 14:00-15:00 CET, 13:00-14:00 GMT Please update the agenda if you have any more topics: http://trac.opendnssec.org/wiki/Meetings/Agenda/2009-12-02 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSxOlA+CjgaNTdVjaAQhQLwf+Mw7/pYQUGi7os6mAB6RWec64MXBmKscM l4N2cOdWCKGF1ZgNJ45HvIDmi73E3pdy6S3l9py+2n0uZohHDwI8Z2wwOu3GMr4a FhI0FymqU/bRJcZUyXmi5gkTulifoNL6QvJgeGyCxxnIp0vzHpJnDwgoykDSGduZ LGSnPCOm4izUjCqL3eZnNTnoKQc2E178rS42hb2vZlTpmJNu6cV1MTs6d5sfNyMu wtp1H00pSSe9XS4GOLbXlUUsyaXXwWPLJ8aaifj7Q3cg6jT7bVNa/IoUnkiz9BDr 2/xK9cUpi0744PdQd/EdjbCYJtxvLu/DUgA4I0XNAqINC6rh+2i45A== =5uh9 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: