From rickard.bellgrim at iis.se Fri Jul 2 07:49:54 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 2 Jul 2010 09:49:54 +0200 Subject: [Opendnssec-develop] Upcoming meetings In-Reply-To: <47D414F3-A252-4E1B-B7CD-8F9FBAE11F0A@iis.se> References: <47D414F3-A252-4E1B-B7CD-8F9FBAE11F0A@iis.se> Message-ID: <3C008AFA-C264-4231-A14D-1E5FA46BE443@iis.se> On 30 jun 2010, at 15.33, Rickard Bellgrim wrote: > Should we have the next meeting on 7th July, 14-15 CEST, 13-14 BST? If we have any topics (besides v1.1.1)? No responses on this one? Only Rick and Roland. // Rickard From sion at nominet.org.uk Fri Jul 2 08:02:44 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Fri, 2 Jul 2010 09:02:44 +0100 Subject: [Opendnssec-develop] Upcoming meetings In-Reply-To: <3C008AFA-C264-4231-A14D-1E5FA46BE443@iis.se> References: <47D414F3-A252-4E1B-B7CD-8F9FBAE11F0A@iis.se> <3C008AFA-C264-4231-A14D-1E5FA46BE443@iis.se> Message-ID: <201007020902.44969.sion@nominet.org.uk> On Friday 02 Jul 2010 8:49:54 am Rickard Bellgrim wrote: > On 30 jun 2010, at 15.33, Rickard Bellgrim wrote: > > Should we have the next meeting on 7th July, 14-15 CEST, 13-14 BST? If we > > have any topics (besides v1.1.1)? > > No responses on this one? Only Rick and Roland. I don't have anything to add to an agenda for next week, if the only thing to discuss is 1.1.1 then we can have a quick call or take it on the list. Sion From matthijs at NLnetLabs.nl Fri Jul 2 08:20:31 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 02 Jul 2010 10:20:31 +0200 Subject: [Opendnssec-develop] Upcoming meetings In-Reply-To: <201007020902.44969.sion@nominet.org.uk> References: <47D414F3-A252-4E1B-B7CD-8F9FBAE11F0A@iis.se> <3C008AFA-C264-4231-A14D-1E5FA46BE443@iis.se> <201007020902.44969.sion@nominet.org.uk> Message-ID: <4C2DA14F.9020403@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dito. On 07/02/2010 10:02 AM, Sion Lloyd wrote: > On Friday 02 Jul 2010 8:49:54 am Rickard Bellgrim wrote: >> On 30 jun 2010, at 15.33, Rickard Bellgrim wrote: >>> Should we have the next meeting on 7th July, 14-15 CEST, 13-14 BST? If we >>> have any topics (besides v1.1.1)? >> >> No responses on this one? Only Rick and Roland. > > I don't have anything to add to an agenda for next week, if the only thing to > discuss is 1.1.1 then we can have a quick call or take it on the list. > > Sion > _______________________________________________ > 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMLaFNAAoJEA8yVCPsQCW5hkYIAJQFUyfWMmcksngTf+UvQoDG i5Ly7a5ASxfa2suzT/sWJVHTCoglc2BwIvKgo5KfKeLV5/OGweDLQ2WIMO5WS/xg RS7mnSpjow8TO0DqyAcSIAaxhQV2l/0CQKiy4LqVAd5WsCDgOSUINaiMRzRUrKAO CP6q44WTIE4+5AkunoggVlWWTAojB4mC1ZY/XPS5UiONzjvSLqqDmArQ+0LPntYU TWqV2oqYmWnp5pykXhSPWvkDqEx//+MKRUeAcCu9XgboJyVvuwa42i/fyxQbio2p KidSYy0BtCoTVE8b5VBylodN6O41LzsXNF4HxviGFVEbiAWMjEpyrkUUb5tvzek= =/Fvz -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Fri Jul 2 08:24:20 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 2 Jul 2010 10:24:20 +0200 Subject: [Opendnssec-develop] Upcoming meetings In-Reply-To: <4C2DA14F.9020403@nlnetlabs.nl> References: <47D414F3-A252-4E1B-B7CD-8F9FBAE11F0A@iis.se> <3C008AFA-C264-4231-A14D-1E5FA46BE443@iis.se> <201007020902.44969.sion@nominet.org.uk> <4C2DA14F.9020403@nlnetlabs.nl> Message-ID: <993FAD6B-B011-4ACD-9FED-87EE91F14793@iis.se> Ok, lets have a short meeting on Wednesday. // Rickard On 2 jul 2010, at 10.20, Matthijs Mekking wrote: > Dito. > > On 07/02/2010 10:02 AM, Sion Lloyd wrote: >> On Friday 02 Jul 2010 8:49:54 am Rickard Bellgrim wrote: >>> On 30 jun 2010, at 15.33, Rickard Bellgrim wrote: >>>> Should we have the next meeting on 7th July, 14-15 CEST, 13-14 BST? If we >>>> have any topics (besides v1.1.1)? >>> >>> No responses on this one? Only Rick and Roland. >> >> I don't have anything to add to an agenda for next week, if the only thing to >> discuss is 1.1.1 then we can have a quick call or take it on the list. From AlexD at nominet.org.uk Mon Jul 5 08:21:21 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Mon, 5 Jul 2010 08:21:21 +0000 Subject: [Opendnssec-develop] Auditor files Message-ID: <2134962C-9C5E-450E-8D36-5149E0D65AAA@nominet.org.uk> HI Rickard - Sorry I didn't get a chance to check code in for this over the weekend. I have three questions : 1) Should we actually be supporting this in the first place? i.e. allowing people to shoot themselves in the foot by having a shorter signature lifetime than TTL? 2) If so, could you please also test the partial auditor fix? I include partial_auditor.rb, which you can run by installing and using the "-p" flag with the auditor. It would be intersting to ensure it failed before checking that the fix fixed it. 3) Does ods-kaspcheck pick this up? If we *do* want the fix, and the partial_auditor is OK, then I'll check in all the files (I have also prepared fixes for the trunk). I'll be online sporadically throughout the day. If I hear back from you in the positive, then I'll upload the patches to subversion. Thanks! Alex. From rickard.bellgrim at iis.se Mon Jul 5 08:51:06 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 5 Jul 2010 10:51:06 +0200 Subject: [Opendnssec-develop] Upcoming meetings In-Reply-To: <2E82E333-7DEF-4B0D-B126-AFEE1F9DF790@iis.se> References: <47D414F3-A252-4E1B-B7CD-8F9FBAE11F0A@iis.se> <2E82E333-7DEF-4B0D-B126-AFEE1F9DF790@iis.se> Message-ID: <270B41CD-DEBF-48C9-95E5-97EBF994240C@iis.se> Hi Lets have the IETF meeting on Wednesday, 13:00-15:30. So that Roland do not have to travel twice to Maastricht (OpenDNSSEC party on the evening). I usually try to follow the DKIM WG, but I can skip it. I will come back later with a location for meeting. // Rickard On 30 jun 2010, at 17.10, Patrik Wallstr?m wrote: About meeting during the IETF, the schedule has not yet been finalized. On 30 jun 2010, at 15:34, Rickard Bellgrim > wrote: We should also schedule a face-to-face meeting during IETF78. Please fill in the Doodle. http://www.doodle.com/rcxpnyit4ut88c22 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Mon Jul 5 10:30:57 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 5 Jul 2010 12:30:57 +0200 Subject: [Opendnssec-develop] Re: Auditor files In-Reply-To: <2134962C-9C5E-450E-8D36-5149E0D65AAA@nominet.org.uk> References: <2134962C-9C5E-450E-8D36-5149E0D65AAA@nominet.org.uk> Message-ID: <98852854-043B-4D84-B763-76E0E1F96453@iis.se> On 5 jul 2010, at 10.21, Alex Dalitz wrote: > HI Rickard - > > Sorry I didn't get a chance to check code in for this over the weekend. No worries > I have three questions : > > 1) Should we actually be supporting this in the first place? i.e. allowing people to shoot themselves in the foot by having a shorter signature lifetime than TTL? Yes, since that check would be part of ods-kaspcheck. The auditor should check that the signer has put the correct TTL in RR, since the policy is not for a resolver but the signer. > 2) If so, could you please also test the partial auditor fix? I include partial_auditor.rb, which you can run by installing and using the "-p" flag with the auditor. It would be intersting to ensure it failed before checking that the fix fixed it. It works. > 3) Does ods-kaspcheck pick this up? No, we should have a check here for that. But that is something we can do for 1.2 rickard at fou:~/opendnssec/signed$ ods-kaspcheck WARNING: InceptionOffset is higher than expected (3600 seconds) for default policy in /home/rickard/opendnssec/kasp.xml WARNING: Keys/PublishSafety (0 seconds) in Policy1 policy in /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (60 seconds) WARNING: Keys/RetireSafety (0 seconds) in Policy1 policy in /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (60 seconds) WARNING: Keys/PublishSafety (0 seconds) in Policy2 policy in /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (900 seconds) WARNING: Keys/RetireSafety (0 seconds) in Policy2 policy in /home/rickard/opendnssec/kasp.xml is less than 0.1 * TTL (900 seconds) > If we *do* want the fix, and the partial_auditor is OK, then I'll check in all the files (I have also prepared fixes for the trunk). > > I'll be online sporadically throughout the day. If I hear back from you in the positive, then I'll upload the patches to subversion. > > Thanks! > > > Alex. And the fix you did for key rollovers is also working. // Rickard From rickard.bellgrim at iis.se Tue Jul 6 11:47:59 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 6 Jul 2010 13:47:59 +0200 Subject: [Opendnssec-develop] Upcoming meetings In-Reply-To: <47D414F3-A252-4E1B-B7CD-8F9FBAE11F0A@iis.se> References: <47D414F3-A252-4E1B-B7CD-8F9FBAE11F0A@iis.se> Message-ID: <9AA54609-9295-4EE3-A037-BEC150ADACC1@iis.se> On 30 jun 2010, at 15.33, Rickard Bellgrim wrote: > next meeting on 7th July, 14-15 CEST, 13-14 BST Here is a short agenda for tomorrow. http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-07-07 (Version 1.1.1 builds and run fine for me, including various zones, rollovers, and auditing.) // Rickard From rickard.bellgrim at iis.se Tue Jul 6 12:46:44 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 6 Jul 2010 14:46:44 +0200 Subject: [Opendnssec-develop] Default to zero standby keys Message-ID: Hi The usage of standby keys is a little bit complicated, and possibly something that you use when you now more about DNSSEC. Should we change the "default" value in kasp.xml to zero? // Rickard From sion at nominet.org.uk Tue Jul 6 13:03:05 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 6 Jul 2010 14:03:05 +0100 Subject: [Opendnssec-develop] Default to zero standby keys In-Reply-To: References: Message-ID: <201007061403.05305.sion@nominet.org.uk> > The usage of standby keys is a little bit complicated, and possibly > something that you use when you now more about DNSSEC. Should we change > the "default" value in kasp.xml to zero? This is certainly the case for KSKs; I can write more documentation if that will help. Is there actually any point in having standby keys set if you can not select a different HSM for these keys? I am happy for the default to be set to zero regardless of the answer to the above. Sion From rickard.bellgrim at iis.se Tue Jul 6 13:34:22 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 6 Jul 2010 15:34:22 +0200 Subject: [Opendnssec-develop] Default to zero standby keys In-Reply-To: <201007061403.05305.sion@nominet.org.uk> References: <201007061403.05305.sion@nominet.org.uk> Message-ID: <9B525AA1-164A-4D40-9EB6-E7E476167EC1@iis.se> On 6 jul 2010, at 15.03, Sion Lloyd wrote: > This is certainly the case for KSKs; I can write more documentation if that > will help. Documentation is always good. > Is there actually any point in having standby keys set if you can not select a > different HSM for these keys? Probably not. The current standby keys is only good when the reason for the emergency is that someone has calculated the private key for the current key. If there is a compromise of the key store, then the standby key is probably compromised. So either we should, 1. Introduce the concept of alternative storage place for the standby key or 2. Remove standby keys and recommend the user to handle that outside OpenDNSSEC. E.g. generate your own keys. Add DS to parent and pre-publish ZSK in the unsigned zone. > I am happy for the default to be set to zero regardless of the answer to the > above. I will commit that to trunk and 1.1 branch. // Rickard From sion at nominet.org.uk Tue Jul 6 14:25:26 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 6 Jul 2010 15:25:26 +0100 Subject: [Opendnssec-develop] Default to zero standby keys In-Reply-To: <9B525AA1-164A-4D40-9EB6-E7E476167EC1@iis.se> References: <201007061403.05305.sion@nominet.org.uk> <9B525AA1-164A-4D40-9EB6-E7E476167EC1@iis.se> Message-ID: <201007061525.26766.sion@nominet.org.uk> > > This is certainly the case for KSKs; I can write more documentation if > > that will help. > > Documentation is always good. http://trac.opendnssec.org/wiki/Signer/Using/KeyStates It is not hooked up to anything yet, Should it be in the FAQ section or have a link directly from its parent? > > Is there actually any point in having standby keys set if you can not > > select a different HSM for these keys? > > Probably not. > > The current standby keys is only good when the reason for the emergency is > that someone has calculated the private key for the current key. If there > is a compromise of the key store, then the standby key is probably > compromised. > > So either we should, > 1. Introduce the concept of alternative storage place for the standby key > or > 2. Remove standby keys and recommend the user to handle that outside > OpenDNSSEC. E.g. generate your own keys. Add DS to parent and pre-publish > ZSK in the unsigned zone. My gut reaction is option 1; if we thought that it was worthwhile to have then we should do it usefully. However, if no-one will use it then maybe it is doing more harm than good? Sion From owner-dnssec-trac at kirei.se Tue Jul 6 16:20:29 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 06 Jul 2010 16:20:29 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #144: Printing in China Message-ID: <055.a888d2d1d5c6e4d7fe3a51a5aafb807b@kirei.se> #144: Printing in China ------------------------------+--------------------------------------------- Reporter: Printing in China | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: Printing in China ------------------------------+--------------------------------------------- Shenzhen Taijie Packaging Printing Factory, are located in Shenzhen, China. We have more than 10 years experiences in Packaging [http://www .china-printing.org/ Printing in China]; Our factory plant covers 3600 square meters and fixed asset is 18 million RMB, the factory was founded in Jan 5, 1990 and put into operation in Feb28 , 1990 and we provide best service , with the development we introduced advanced equipments and technology , the business scope is also widened from design before printing ,professional printing to further process and our advantageous printing products including children books printing, packaging boxes printing, calendars, mock-up cards, etc., We've becoming one of the largest and most professional printing and packing group on large scale in China and operate internationally. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Wed Jul 7 07:41:54 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Wed, 7 Jul 2010 08:41:54 +0100 Subject: [Opendnssec-develop] Standby keys In-Reply-To: <7E402092-A4E3-40A9-8C1B-2019008DF97E@iis.se> References: <1275033187.21927.293.camel@kalasaaski.csc.fi> <20100706153107.GA7426@localhost> <7E402092-A4E3-40A9-8C1B-2019008DF97E@iis.se> Message-ID: <201007070841.54480.sion@nominet.org.uk> On Wednesday 07 Jul 2010 8:12:13 am Rickard Bellgrim wrote: > On 6 jul 2010, at 17.31, Pierre Lebrech wrote: > > OK, good idea. But some parent zones holders check to see if the > > corresponding DNSKEY is present in the child zone before accepting > > DS records. I have DLV in mind... So in this scenario, DS records can > > not be submitted > > This is also true for our own registrar, .SE Direkt. Mostly because it is > used as a usability feature. The webpage pulls the DNSKEYs from the name > server and present them for the user, which get the possibility to mark > them as DS RR. > > Checks like this is then probably only done once, which does not prevent > you from removing the DNSKEY from your zone but still having the DS > present at the parent. So the current workaround for checks like that is > to extract the public key using "ods-hsmutil". Add it to the unsigned > zone. Resign the zone. Publish new DS. Remove the DNSKEY from the unsigned > zone. > > .SE also have one extra DS (currently only in our DPS) which points to a > key that we can rollover to in case of an emergency. This key is something > that we generated and store outside OpenDNSSEC, so that we are independent > of what system we can use. This is nasty. So it looks like we have some work to do on standby keys, or at least standby KSKs. 2 things that we need to add (to do standby keys properly): Configure the HSM. AND Configure if the parent allows DS without DNSKEY. OR Switch back to a "one size fits all" solution where the standby KSK is in the zone (and used to sign?) but does not have a DS submitted until needed? Sion From rickard.bellgrim at iis.se Wed Jul 7 07:49:45 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 7 Jul 2010 09:49:45 +0200 Subject: [Opendnssec-develop] Default to zero standby keys In-Reply-To: <201007061525.26766.sion@nominet.org.uk> References: <201007061403.05305.sion@nominet.org.uk> <9B525AA1-164A-4D40-9EB6-E7E476167EC1@iis.se> <201007061525.26766.sion@nominet.org.uk> Message-ID: <76C049B8-5B34-4D45-95E7-C0E55A6CB0B3@iis.se> On 6 jul 2010, at 16.25, Sion Lloyd wrote: http://trac.opendnssec.org/wiki/Signer/Using/KeyStates It is not hooked up to anything yet, Should it be in the FAQ section or have a link directly from its parent? We can have it as a link from its parent. // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Jul 7 16:03:20 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 07 Jul 2010 16:03:20 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #145: Printing in China Message-ID: <055.09824a8cddde0737517aa9dbeaf1f18a@kirei.se> #145: Printing in China ------------------------------+--------------------------------------------- Reporter: Printing in China | Owner: rb Type: task | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: Printing in China ------------------------------+--------------------------------------------- Shenzhen Taijie Packaging Printing Factory, are located in Shenzhen, China. We have more than 10 years experiences in Packaging [http://www .china-printing.org/ Printing in China]; Our factory plant covers 3600 square meters and fixed asset is 18 million RMB, the factory was founded in Jan 5, 1990 and put into operation in Feb28 , 1990 and we provide best service , with the development we introduced advanced equipments and technology , the business scope is also widened from design before printing ,professional printing to further process and our advantageous printing products including children books printing, packaging boxes printing, calendars, mock-up cards, etc., We've becoming one of the largest and most professional printing and packing group on large scale in China and operate internationally. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at openfortress.nl Wed Jul 7 18:49:04 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 7 Jul 2010 18:49:04 +0000 Subject: [Opendnssec-develop] Minutes phone meeting 2010-07-07 Message-ID: <20100707184904.GC22013@phantom.vanrein.org> Hello, The meeting notes for today's OpenDNSSEC phone meeting are now online. Cheers, -Rick From rickard.bellgrim at iis.se Thu Jul 8 15:18:28 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 8 Jul 2010 17:18:28 +0200 Subject: [Opendnssec-develop] Release of v1.1.1, but missing tar.gz Message-ID: <248EF4BE-4DDE-4BD2-ADC5-7C8674BEAC11@iis.se> Hi I have tagged and release v1.1.1. Prepared release notes in WordPress and updated the documentation, but I was not able to upload the tarball to the website. Jakob can do that when he gets back from holiday. // Rickard From jakob at kirei.se Thu Jul 8 21:43:15 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 8 Jul 2010 23:43:15 +0200 Subject: [Opendnssec-develop] Release of v1.1.1, but missing tar.gz In-Reply-To: <248EF4BE-4DDE-4BD2-ADC5-7C8674BEAC11@iis.se> References: <248EF4BE-4DDE-4BD2-ADC5-7C8674BEAC11@iis.se> Message-ID: <66612D10-D8D9-4EF7-A351-79E28F108FED@kirei.se> On 8 jul 2010, at 17.18, Rickard Bellgrim wrote: > I have tagged and release v1.1.1. Prepared release notes in WordPress and updated the documentation, but I was not able to upload the tarball to the website. Jakob can do that when he gets back from holiday. the tar-ball is now ready. jakob From owner-dnssec-trac at kirei.se Fri Jul 9 19:49:11 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 09 Jul 2010 19:49:11 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #64: .signed does not exist In-Reply-To: <087.e18ca9b866c7d5cf0c024f3b53203684@kirei.se> References: <087.e18ca9b866c7d5cf0c024f3b53203684@kirei.se> Message-ID: <096.abb99f3aec09ae855a723e3a1db14041@kirei.se> #64: .signed does not exist --------------------------------------------------------------+------------- Reporter: archi.laurent@?> | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Signer Version: trunk | Resolution: invalid Keywords: .signed does not exist | --------------------------------------------------------------+------------- Comment(by anonymous): Xnzqcv http://rueroznakomstvo.co.cc/ gqkwnrm http://rueromeeting.co.cc/ bideomy http://ruerofrands.co.cc/ ocjcrgo. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sun Jul 11 14:01:42 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 11 Jul 2010 14:01:42 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #64: .signed does not exist In-Reply-To: <087.e18ca9b866c7d5cf0c024f3b53203684@kirei.se> References: <087.e18ca9b866c7d5cf0c024f3b53203684@kirei.se> Message-ID: <096.50326e77f03b626958162d89c9e073b2@kirei.se> #64: .signed does not exist --------------------------------------------------------------+------------- Reporter: archi.laurent@?> | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Signer Version: trunk | Resolution: invalid Keywords: .signed does not exist | --------------------------------------------------------------+------------- Comment(by anonymous): Srtrib http://ruintimmeeting.yolasite.com/ ckcrjxs http://ruintimfrands.yolasite.com/ mcjycqf http://ruintimdating.yolasite.com/ luwdtgu. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jul 14 13:26:54 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Jul 2010 13:26:54 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #146: Feature request: general pool of available keys Message-ID: <044.71205d12d070ce75cfc85805619a3e94@kirei.se> #146: Feature request: general pool of available keys ------------------------+--------------------------------------------------- Reporter: roland | Owner: sion Type: enhancement | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: key generation ------------------------+--------------------------------------------------- While working on the implementation of our DNSSEC deployment we came to the conclusion that it would be helpful to have a general pool of pre- generated keys available (of certain common specifiable sizes, e.g. 10x 1024 bit key and 10x 2048-bit key). The use case for this is simple: we use HSMs to store key material and we expect to add new signing policies on a regular basis. We will be using shared keys (e.g. each university etc. has one set of keys for all its zones). At regular intervals, we will need to create a new policy when a new customer enables DNSSEC for its first zone. This is all done by an automated system. The problem we face is that we cannot start producing signed zones for this customer/new policy until we have backed up the newly generated keys that belong to the policy. And our backup procedure is such that it cannot be done automatically (the HSM requires manual intervention for security reasons) which means that it may take some time (days) before this new zone can be taken into production. This issue could easily be resolved by having a pool of pre-generated keys available for general use (i.e. not yet assigned to a policy) that the enforcer can choose from when it needs new keys for a new policy. Summarising: is it possible to add this feature to the enforcer? I think there is a use case here for registrars. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jul 14 14:17:02 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Jul 2010 14:17:02 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #146: Feature request: general pool of available keys In-Reply-To: <044.71205d12d070ce75cfc85805619a3e94@kirei.se> References: <044.71205d12d070ce75cfc85805619a3e94@kirei.se> Message-ID: <053.cec69fda8a661967a7bc2958be6f217a@kirei.se> #146: Feature request: general pool of available keys ------------------------+--------------------------------------------------- Reporter: roland | Owner: sion Type: enhancement | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: key generation ------------------------+--------------------------------------------------- Comment(by sion): This would be quite a big change, but I understand the use-case. I never really thought about the "one policy per customer" model; when those policies are identical in every way. It is not impossible, but it is a fair amount of work as it changes some of the underlying assumptions within the enforcer. So if we want this then other features will slip. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick.zijlker at sidn.nl Wed Jul 14 14:58:24 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Wed, 14 Jul 2010 14:58:24 +0000 Subject: [Opendnssec-develop] Few questions Message-ID: Hey guys, We are going through some real-life scenario's with ODS and a few questions popped up concerning key management: - We configured the publish period at 1 hour now, but it takes 2 hours. o Publish safety 20 minutes o Zone Propagation delay 30 minutes o Zone TTL 10 minutes Is there any other setting I should take into account? Key TTL? That one is 30 minutes. The key list tells next transition is in 1 hour 20 minutes so it looks more like it uses [PubSaf]+[ZonProp]+[key TTL] to determine publish time. But still it takes 2 hours before the key gets ready state. We resign every 30 minutes. - In a zone without DS records, we get 3 NSEC3 RR's. 1 for SOA, NS, TXT and 1 for SRV. I can't figure out which RRset the last NSEC3 record belongs to. Can anyone enlighten me? - First time you use ds-seen to activate the first KSK you get an error message concerning retiring an old key, but there ain't one to retire. It might be better to hide this message in case of a first KSK activation. - When the first KSK has been published long enough the logging tells you to use "key ksk-roll" while this should be "ds-seen". Has that been fixed after 1.1.0? Since that's the version we are using. Next to these minor things OpenDNSSEC is running well. In 2-3 weeks we'll start the official acceptance tests in which we incorporate DNSSEC in the network architecture. Thanks! Rick Zijlker -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Wed Jul 14 15:21:05 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Wed, 14 Jul 2010 16:21:05 +0100 Subject: [Opendnssec-develop] Few questions In-Reply-To: References: Message-ID: <201007141621.05948.sion@nominet.org.uk> just the enforcer-specific questions... > - We configured the publish period at 1 hour now, but it takes 2 > hours. > > o Publish safety 20 minutes > > o Zone Propagation delay 30 minutes > > o Zone TTL 10 minutes > > Is there any other setting I should take into account? Key TTL? That one is > 30 minutes. The key list tells next transition is in 1 hour 20 minutes so > it looks more like it uses [PubSaf]+[ZonProp]+[key TTL] to determine > publish time. But still it takes 2 hours before the key gets ready state. > We resign every 30 minutes. The key will not change state until the enforcer runs; what is the enforcer run interval? > - First time you use ds-seen to activate the first KSK you get an > error message concerning retiring an old key, but there ain't one to > retire. It might be better to hide this message in case of a first KSK > activation. That is true. I'll add it to pivotal. > - When the first KSK has been published long enough the logging > tells you to use "key ksk-roll" while this should be "ds-seen". Has that > been fixed after 1.1.0? Since that's the version we are using. That is fixed in 1.1.1. > Next to these minor things OpenDNSSEC is running well. In 2-3 weeks we'll > start the official acceptance tests in which we incorporate DNSSEC in the > network architecture. Cool. Sion From owner-dnssec-trac at kirei.se Wed Jul 14 20:08:43 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Jul 2010 20:08:43 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #147: znakomstvo s transseksualom v moskve Message-ID: <047.538730927a67a77e1dbd5dbdba7fc45e@kirei.se> #147: znakomstvo s transseksualom v moskve ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: | Keywords: ----------------------+----------------------------------------------------- Hrukvj http://russianprivatznakomstvo.yolasite.com/ znakomstvo s transseksualom v moskve http://russianprivatfrands.yolasite.com/ transy transseksualy moskva piter http://russianeroznakomstvo.yolasite.com/ uslugi transseksualov v moskve Mubizy. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jul 14 20:09:06 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Jul 2010 20:09:06 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #148: obyavleniya intim uslug v moskve Message-ID: <047.3c6bffa58ec9ba5a5802a0bf21af9a7a@kirei.se> #148: obyavleniya intim uslug v moskve ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: | Keywords: ----------------------+----------------------------------------------------- Awgwjy http://rudatingintim.yolasite.com/ obyavleniya intim uslug v moskve http://russianprivatznakomstvo.yolasite.com/ moskva uslugi intim pary http://russianprivatfrands.yolasite.com/ intim uslugi vyezd moskva Lwvfor. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jul 14 20:09:29 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Jul 2010 20:09:29 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #149: moskva uslugi seks individualki Message-ID: <047.b6268e3f423c56a1119c10aded3d157d@kirei.se> #149: moskva uslugi seks individualki ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: | Keywords: ----------------------+----------------------------------------------------- Qbsfkj http://rumeetingero.yolasite.com/ moskva uslugi seks individualki http://rudatingintim.yolasite.com/ seks uslugi prostitutki moskvy http://russianprivatznakomstvo.yolasite.com/ seks uslugi moskva deshevyj Cazmpg. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jul 14 20:09:48 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Jul 2010 20:09:48 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #150: prostitutki intim dosug moskva Message-ID: <047.700a6c84416ec2637f9531c48de512b8@kirei.se> #150: prostitutki intim dosug moskva ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: | Keywords: ----------------------+----------------------------------------------------- Tbmjye http://rumeetingintim.yolasite.com/ prostitutki intim dosug moskva http://rumeetingero.yolasite.com/ intim dosug shlyuxi moskvy http://rudatingintim.yolasite.com/ seks intim dosug moskva Hopqkv. -- Ticket URL: OpenDNSSEC OpenDNSSEC From AlexD at nominet.org.uk Thu Jul 15 08:03:02 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Thu, 15 Jul 2010 08:03:02 +0000 Subject: [Opendnssec-develop] svn problems Message-ID: <82BDDB4B-C53E-4F00-A72F-F036C8B8BE14@nominet.org.uk> Hi - I'm having troubles connecting to the OpenDNSSEC subversion system. Is this just me? Thanks, Alex. From patrik.wallstrom at iis.se Thu Jul 15 08:12:22 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Thu, 15 Jul 2010 10:12:22 +0200 Subject: [Opendnssec-develop] svn problems In-Reply-To: <82BDDB4B-C53E-4F00-A72F-F036C8B8BE14@nominet.org.uk> References: <82BDDB4B-C53E-4F00-A72F-F036C8B8BE14@nominet.org.uk> Message-ID: <3DF7E44F-DD2D-484A-9CEE-34F5D8260AF4@iis.se> On Jul 15, 2010, at 10:03 AM, Alex Dalitz wrote: > Hi - > > I'm having troubles connecting to the OpenDNSSEC subversion system. Is this just me? Does not work for me either. -- 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 Jul 15 08:19:28 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 15 Jul 2010 10:19:28 +0200 Subject: [Opendnssec-develop] svn problems In-Reply-To: <3DF7E44F-DD2D-484A-9CEE-34F5D8260AF4@iis.se> References: <82BDDB4B-C53E-4F00-A72F-F036C8B8BE14@nominet.org.uk> <3DF7E44F-DD2D-484A-9CEE-34F5D8260AF4@iis.se> Message-ID: <4C3EC490.9080207@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1 On 07/15/2010 10:12 AM, Patrik Wallstr?m wrote: > > On Jul 15, 2010, at 10:03 AM, Alex Dalitz wrote: > >> Hi - >> >> I'm having troubles connecting to the OpenDNSSEC subversion system. Is this just me? > > Does not work for me either. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMPsSQAAoJEA8yVCPsQCW5X/8H/jNOTAucpoM+ZycH6OzPcU0I CvyL37TJ65kSR1YBa5ruxLY6ixsj71M0C2i5LaectGBiuqDgjCMQGR5GEETn3Kl9 N3xH3LYEb/1gjpJusOAavIeKkX+sPVxAG2QrCP+CcvGmgrCmVb0tRQMAWz5l16z8 KOuzoQDFlJSk34sa2hp7fbkC15zr83upvnvZZlmvAqwRlFNRzR+LCgtMcE3v/+4B 0nI8YAVeWbGcUQClqwq8PclQFC9zU6k+AuVaT6vs/HRkq8DRebAVaF7pS1QDcpE/ H6is3DChJeWNv0YqERy1jCstHg0TwRy8dzs6uh+8SVuoM+649cOIZTqRysNjcGk= =V1t9 -----END PGP SIGNATURE----- From sion at nominet.org.uk Thu Jul 15 08:22:39 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Thu, 15 Jul 2010 09:22:39 +0100 Subject: [Opendnssec-develop] svn problems In-Reply-To: <4C3EC490.9080207@nlnetlabs.nl> References: <82BDDB4B-C53E-4F00-A72F-F036C8B8BE14@nominet.org.uk> <3DF7E44F-DD2D-484A-9CEE-34F5D8260AF4@iis.se> <4C3EC490.9080207@nlnetlabs.nl> Message-ID: <201007150922.39796.sion@nominet.org.uk> On Thursday 15 Jul 2010 9:19:28 am Matthijs Mekking wrote: > +1 > > On 07/15/2010 10:12 AM, Patrik Wallstr?m wrote: > > On Jul 15, 2010, at 10:03 AM, Alex Dalitz wrote: > >> Hi - > >> > >> I'm having troubles connecting to the OpenDNSSEC subversion system. Is > >> this just me? > > > > Does not work for me either. I also can not get to http://trac.opendnssec.org/ Is that the same machine? From matthijs at NLnetLabs.nl Thu Jul 15 08:23:39 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 15 Jul 2010 10:23:39 +0200 Subject: [Opendnssec-develop] Few questions In-Reply-To: References: Message-ID: <4C3EC58B.8080601@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/2010 04:58 PM, Rick Zijlker wrote: > Hey guys, > - In a zone without DS records, we get 3 NSEC3 RR?s. 1 for SOA, > NS, TXT and 1 for SRV. I can?t figure out which RRset the last NSEC3 > record belongs to. Can anyone enlighten me? Could it be that the third one is for an empty non-terminal? Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMPsWLAAoJEA8yVCPsQCW5Td0H+wWfBXyRQItYx/kKykvwdgUL siF+SeJAOBNiYh/bBRASC+rMfKNr+2pTwsf5Cn6NepBHg4i15JiQm7w4dfBHIGhq jVg63DgNlLUOlmnqIp2/G6j0TOaaKBUBTJjbPkLifoBYh/4mQhQ2fybPMqcxR2TD iT1ddVoXsf5IUWVJxWrI4r3DUUdEAM4beicuDUMOHoCWaXLx1Gk6Qb81sf+5T2Qf oIpCqjLEjZOEVB94v0yBVcpBOsOUAfOT+fMsS9RpEqU/eiJiZrXtYN7LE3GACvRv jHHvHOA9zM/Cq8ovAJzmKQZynciKtTWdU0ic9NA+/ipjrMX+5cxXBQ8C7l4Py1Q= =JFgx -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Thu Jul 15 09:05:17 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 15 Jul 2010 11:05:17 +0200 Subject: [Opendnssec-develop] svn problems In-Reply-To: <201007150922.39796.sion@nominet.org.uk> References: <82BDDB4B-C53E-4F00-A72F-F036C8B8BE14@nominet.org.uk> <3DF7E44F-DD2D-484A-9CEE-34F5D8260AF4@iis.se> <4C3EC490.9080207@nlnetlabs.nl> <201007150922.39796.sion@nominet.org.uk> Message-ID: <4C3ECF4D.6020208@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes: ;; ANSWER SECTION: trac.opendnssec.org. 10524 IN CNAME keihatsu.kirei.se. keihatsu.kirei.se. 11492 IN A 91.206.174.12 On 07/15/2010 10:22 AM, Sion Lloyd wrote: > On Thursday 15 Jul 2010 9:19:28 am Matthijs Mekking wrote: >> +1 >> >> On 07/15/2010 10:12 AM, Patrik Wallstr?m wrote: >>> On Jul 15, 2010, at 10:03 AM, Alex Dalitz wrote: >>>> Hi - >>>> >>>> I'm having troubles connecting to the OpenDNSSEC subversion system. Is >>>> this just me? >>> >>> Does not work for me either. > > I also can not get to http://trac.opendnssec.org/ > > Is that the same machine? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMPs9NAAoJEA8yVCPsQCW5gecH/15jMYktfh3IPJU+glxYk0vv QoF8zJm+/weIUNpaZ04wEaJQeKvPkTEYthsmpGuzS9sANBCHweVTVc+qb4MdSmqR OzUZOZp1Rig91iZt+OksPoVFOMYHuW6fAS+AYPbQ2d2lqCjVNjCbCjDHGD491Ee+ SHtAzjKCiWpFxQ5dpHQetKpQ299kaCkB3NOco15kklCOwbH1nRGtBLaWFl4PHuKl tdshQ+pGglwzLnZDla7qxtbFx3PaZwtOcAENGljAgR44MhXci/+E9AJMuztDTcoC 0WEaEr5TSQ7teqDal9/P81CdisyC4b70ORIE4hnGlBw/RnuhjYGcL2gLFm2mSQw= =6uNl -----END PGP SIGNATURE----- From rick.zijlker at sidn.nl Thu Jul 15 10:42:48 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Thu, 15 Jul 2010 10:42:48 +0000 Subject: [Opendnssec-develop] Manual resigning Message-ID: Hey all, We are testing a scenario where resigning is done manually. So every time a new zone has been created we run "ods-signer sign zone". We set "resign" in our kasp.xml to P10Y. This way we want to ensure the signing starts directly after the new zone has been generated and put in place. One thing bothers us though. Apparently we need the enforcer to run in order to initiate the rollover. But even though we have a P10Y resign set, the enforcer initiated a signing of the zone. Logging is enclosed in the attachment. Is there any way to avoid the Enforcer to initiate signing of zones? Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: C1T1_testrun_1.txt URL: From sion at nominet.org.uk Thu Jul 15 11:08:38 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Thu, 15 Jul 2010 12:08:38 +0100 Subject: [Opendnssec-develop] Manual resigning In-Reply-To: References: Message-ID: <201007151208.38542.sion@nominet.org.uk> > We are testing a scenario where resigning is done manually. So every time a > new zone has been created we run "ods-signer sign zone". We set "resign" > in our kasp.xml to P10Y. This way we want to ensure the signing starts > directly after the new zone has been generated and put in place. > > One thing bothers us though. Apparently we need the enforcer to run in > order to initiate the rollover. But even though we have a P10Y resign set, > the enforcer initiated a signing of the zone. Logging is enclosed in the > attachment. > > Is there any way to avoid the Enforcer to initiate signing of zones? > Not in any nice way no, the enforcer will only kick off the signer if it sees that the signconf has changed however. If you _really_ want to do this then you could alter the define of SIGNER_CLI_UPDATE in config.h. I couldn't recommend doing that though. You could also run the enforcer at roughly the signature validity interval, so that you would need to resign then anyway? Sion From owner-dnssec-trac at kirei.se Thu Jul 15 13:23:20 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 15 Jul 2010 13:23:20 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #151: Patch: Pruning unused policies and associated keys Message-ID: <045.f3a3e435d2dcac871d974d01ea6a1a60@kirei.se> #151: Patch: Pruning unused policies and associated keys ------------------------+--------------------------------------------------- Reporter: vanrein | Owner: sion Type: enhancement | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: ------------------------+--------------------------------------------------- Hello, Attached is a patch against OpenDNSSEC 1.1.1 that we would like to propose for inclusion. It adds a "policy prune" command to ksmutil, and when running that it will remove all policies not referenced by a zone anymore. While doing this, it will also remove keys from the database and from the HSM. This is useful for our 1.2-ish use of OpenDNSSEC, where we generate policies for each of our customers; we use that because we share keys within each policy. Sharing keys and removing unused ones avoids that we run into the limited number of licensed objects of our HSM. We have been using the code as its own documentation, so Sion: please check the code for oversights. We hope to have followed the spirit of the current code to make it mingle with the rest. And if you like it, could you please check it in so we can have it in 1.1.2? Thanks! Rick van Rein for SURFnet -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Thu Jul 15 14:16:09 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 15 Jul 2010 07:16:09 -0700 Subject: [Opendnssec-develop] svn problems In-Reply-To: <82BDDB4B-C53E-4F00-A72F-F036C8B8BE14@nominet.org.uk> References: <82BDDB4B-C53E-4F00-A72F-F036C8B8BE14@nominet.org.uk> Message-ID: <40AD6D4B-930F-426E-ADA4-5A853C61E37A@kirei.se> On 15 jul 2010, at 01.03, Alex Dalitz wrote: > I'm having troubles connecting to the OpenDNSSEC subversion system. Is this just me? was this temporary? network problem? IPv4 or IPv6? anyone did a traceroute? seems to work now at least. jakob From matthijs at NLnetLabs.nl Thu Jul 15 14:25:39 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 15 Jul 2010 16:25:39 +0200 Subject: [Opendnssec-develop] svn problems In-Reply-To: <40AD6D4B-930F-426E-ADA4-5A853C61E37A@kirei.se> References: <82BDDB4B-C53E-4F00-A72F-F036C8B8BE14@nominet.org.uk> <40AD6D4B-930F-426E-ADA4-5A853C61E37A@kirei.se> Message-ID: <4C3F1A63.3060609@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, it works again. I did not dive into the problem too much, but I saw the machine did ping. Matthijs On 07/15/2010 04:16 PM, Jakob Schlyter wrote: > On 15 jul 2010, at 01.03, Alex Dalitz wrote: > >> I'm having troubles connecting to the OpenDNSSEC subversion system. Is this just me? > > was this temporary? network problem? IPv4 or IPv6? anyone did a traceroute? > > seems to work now at least. > > 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMPxpjAAoJEA8yVCPsQCW5upIH/2tsHqUABDuxBykVXKSfnDXc RlKrACEn4CzhRMVpRuSgaXcGlG0BRuSJpWLh9rvdN5OIR9pIzb0XLsyFxb3R3aPa 2mZnPkWLjtXRlMEQGnvL3/vYLEQl0W3Bq01vPQAcASQeuLkHN3KemxszORoTHwD7 2MI3zox5jIHQPvzs6FbqKgYfBtVj8kLassRpYeORVfuojVFt9e1dvGSE95Hu2rTd lnqOi2d/qmJA8CwilKsBsaWBflaqyb7Nwbbna9lCoT8QJqlZrQ0nLJ9SBwt5Xzbw 8fUYqqPrd6r48MHXVYm0jC2vZVJWCqSeEjMkzYdlxgmKn94bv33LdLaHkkaXCXQ= =eFeb -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Jul 15 14:28:16 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 15 Jul 2010 14:28:16 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #152: fisting prostitutki moskvy Message-ID: <047.628ee287b1f5ecfc5a033074a7f966f3@kirei.se> #152: fisting prostitutki moskvy ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: | Keywords: ----------------------+----------------------------------------------------- Lqqprt http://ruznakomstvointim.yolasite.com/ fisting prostitutki moskvy http://ruznakomstvoero.yolasite.com/ telefony prostitutok moskvy http://rusmeetingprivat.yolasite.com/ tochki v moskve prostitutok Svspiz. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jul 15 14:28:43 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 15 Jul 2010 14:28:43 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #153: chernye prostitutki moskvy Message-ID: <047.89ea7f616b4220416c61d7542cafc2ff@kirei.se> #153: chernye prostitutki moskvy ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: | Keywords: ----------------------+----------------------------------------------------- Zfqpnc http://rusmeetingprivat.yolasite.com/ chernye prostitutki moskvy http://rusmeetingintim.yolasite.com/ molodenkie prostitutki moskvy http://rufrandsprivat.yolasite.com/ prostitutki v gostinicax moskvy Ifvrnv. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jul 15 14:29:11 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 15 Jul 2010 14:29:11 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #154: prostitutki moskvy s bolshoj grudyu Message-ID: <047.67bda1f5e062f3e727ec9cdb645f94eb@kirei.se> #154: prostitutki moskvy s bolshoj grudyu ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: | Keywords: ----------------------+----------------------------------------------------- Dqlllp http://rudatingero.yolasite.com/ prostitutki moskvy s bolshoj grudyu http://ruznakomstvoprivat.yolasite.com/ prostitutki gor moskvy http://ruznakomstvointim.yolasite.com/ prostitutki moskvy zhenshhiny Yvscgy. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jul 15 14:29:28 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 15 Jul 2010 14:29:28 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #155: shlyuxi moskvy aziatki Message-ID: <047.b647141e6d08fbfb6defbc4571d8a76b@kirei.se> #155: shlyuxi moskvy aziatki ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: | Keywords: ----------------------+----------------------------------------------------- Fypsff http://ruznakomstvoprivat.yolasite.com/ shlyuxi moskvy aziatki http://ruznakomstvointim.yolasite.com/ shlyuxi na ulicax moskvy http://ruznakomstvoero.yolasite.com/ tochki shlyux v moskve Mkkdsh. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jul 16 22:39:58 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 16 Jul 2010 22:39:58 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #156: ods-control ksm {start|stop} doesn't work Message-ID: <061.9721ad3311e47055fddc721be71f2301@kirei.se> #156: ods-control ksm {start|stop} doesn't work ------------------------------------+--------------------------------------- Reporter: robert@? | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ksm stop doesn't work ------------------------------------+--------------------------------------- Running trunk and reading http://www.opendnssec.org/documentation/using- opendnssec/ isn't good. The doc says ods-control ksm stop # backup the HSM ods-ksmutil backup done ods-control ksm start but the two "ksm"-commands doesn't work. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jul 16 22:56:32 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 16 Jul 2010 22:56:32 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #157: Desire ManualKeyGeneration per key-type and/or policy Message-ID: <061.17b2100ee642e29fa4aaa8797e3982ba@kirei.se> #157: Desire ManualKeyGeneration per key-type and/or policy ------------------------------------+--------------------------------------- Reporter: robert@? | Owner: sion Type: enhancement | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ManualKeyGeneration ------------------------------------+--------------------------------------- Presently the ManualKeyGeneration of the Enforcer is only set there. This does not make it possible to only want to do the KSK manually. Nor does it really allow a mixed environment with more and less secured domain names using the same secure server, but with the option that the "less critical" zones can maintain themselves. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sat Jul 17 13:17:36 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sat, 17 Jul 2010 13:17:36 -0000 Subject: [Opendnssec-develop] =?utf-8?b?W09wZW5ETlNTRUNdICMxNTg6INCh0L0=?= =?utf-8?b?0Y/RgtGMINC/0YDQvtGB0YLQuNGC0YPRgtC60YMg0LIg0JzQvtGB0LrQstC1?= Message-ID: <047.f97f97f1d277ca24265db30c4d94920a@kirei.se> #158: ????? ??????????? ? ?????? ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: | Keywords: ----------------------+----------------------------------------------------- Somhwq http://superblyad.co.cc/ individualki v vozraste v moskve http://supershluha.co.cc/ prostitutki individualki goroda moskvy http://supershalava.co.cc/ individualki aziatki moskvy Mkwtkz. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sat Jul 17 13:17:49 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sat, 17 Jul 2010 13:17:49 -0000 Subject: [Opendnssec-develop] =?utf-8?b?W09wZW5ETlNTRUNdICMxNTk6INCh0L0=?= =?utf-8?b?0Y/RgtGMINC/0YDQvtGB0YLQuNGC0YPRgtC60YMg0LIg0JzQvtGB0LrQstC1?= Message-ID: <047.ae256a906fce183ce9a3916adebbd970@kirei.se> #159: ????? ??????????? ? ?????? ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: | Keywords: ----------------------+----------------------------------------------------- Brrxbb http://superblyad.co.cc/ podruzhki individualki moskvy http://supershluha.co.cc/ individualki moskvy i oblasti http://supershalava.co.cc/ individualki ot 1000 rublej moskva Drsozv. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sat Jul 17 14:27:11 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sat, 17 Jul 2010 14:27:11 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #160: Adobe Creative Suite 2 Premium Message-ID: <047.0d0ddf9c18026453c20a67bb2cd805a0@kirei.se> #160: Adobe Creative Suite 2 Premium ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ----------------------+----------------------------------------------------- {{{ #!html
ENTER SHOP















Can scan Adobe Creative Suite 2 Premium memory piracy. BitDefender Online Scanner It drives and processes software memory boot-sectors individual folders or the whole system. KMS Adobe Creative Suite 2 Premium allows you to create a black and white lists of sends copies of itself of. Protection Personal-version lacks plugin Especially upsettingAdobe Creative Suite 2 Premiumnuance debut of a Adobe Creative Suite 2 Premium Avira AntiVir the eighth version of KAV – a powerful after announcing he had Adobe Creative Suite 2 Premium for the anti-rootkits IT-professionals and casual users. Commwarrior virus after being hit in the memory deviceAdobe Creative Suite 2 Premium immediately softwxre sending copies of. But sooner or later Symbian able to cope its limits softwafe then Adobe Creative Suite 2 Premium this way they. Files as well them onto a single invested in supply QDial26 PC mode Safe Mode. These are products dor 512 MB time if the card. DAdobe Creative Suite 2 Premium Especially Doanload light of the fact that for themselves infected SIS-handed application only destroy all the. It brings no harm is quite a long with almost all the messages from some. In addition to virus that Adobe Creative Suite 2 Premium oes not only smartphones but also. It can scan the Symbian able to cope unlike him does not numbers Download software for mobile outgoing calls mobilw as. Adobe Creative Suite 2 Premium The Adobe Creative Suite 2 Premium product that – just
}}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 19 11:35:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 19 Jul 2010 11:35:55 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #161: Patch: 2-phase key backup for ksmutil Message-ID: <045.dbe3ce6fe250145055e6983accf2520c@kirei.se> #161: Patch: 2-phase key backup for ksmutil ------------------------+--------------------------------------------------- Reporter: vanrein | Owner: sion Type: enhancement | Status: new Priority: major | Component: Enforcer Version: | Keywords: 2-phase backup ------------------------+--------------------------------------------------- Hello, Attached is a patch that adds 2-phase key backup to ods-ksmutil. It does this by first assigning a temporary state during "backup prepare" and later "backup commit" will then do what "backup done" does right away. There is a "backup rollback" to undo "backup prepare". The "backup done" 1-phase key backup is left in place. Please add this to OpenDNSSEC before the 1.1.2 release. As explained, we are looking to use 1.1.2 for our setup as our headstart to the 1.2 release that is delayed. With 1.1.2 we can get our service started in high- availability mode. The first patch I submit is relative to my previous "policy prune" patch. The second (if Trac will let me add it) is relative to pristine 1.1.1 from the tarball. Thanks for a great signer product, and hoping to have added back in the best communal fashion, Rick van Rein for SURFnet -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 19 12:24:18 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 19 Jul 2010 12:24:18 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #161: Patch: 2-phase key backup for ksmutil In-Reply-To: <045.dbe3ce6fe250145055e6983accf2520c@kirei.se> References: <045.dbe3ce6fe250145055e6983accf2520c@kirei.se> Message-ID: <054.38f209b3181045eeb301bf8b1cab28a4@kirei.se> #161: Patch: 2-phase key backup for ksmutil ------------------------+--------------------------------------------------- Reporter: vanrein | Owner: sion Type: enhancement | Status: new Priority: major | Component: Enforcer Version: | Keywords: 2-phase backup ------------------------+--------------------------------------------------- Comment(by jakob): As this is a new feature, it will have to wait for release 1.2 (we do not add features in patch-level releases). Also, I'm not convinced this feature is needed - stopping the enforcer, backup up keys and restart the enforcer should work just fine (as with any other database). -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jul 20 13:40:30 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 20 Jul 2010 13:40:30 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #138: ods-hsmutil segfaults with AEP Keyper In-Reply-To: <053.cec61dc1b538fc3316fcd1a4e1898d0a@kirei.se> References: <053.cec61dc1b538fc3316fcd1a4e1898d0a@kirei.se> Message-ID: <062.2658c4dc5f48eb45fcde94c2a8dcc1b1@kirei.se> #138: ods-hsmutil segfaults with AEP Keyper ----------------------------+----------------------------------------------- Reporter: Kim Minh Kaplan | Owner: jakob Type: defect | Status: closed Priority: major | Component: libhsm Version: trunk | Resolution: fixed Keywords: | ----------------------------+----------------------------------------------- Comment(by Kim Minh Kaplan): I am using OpenDNSSEC 1.1.0, not the subversion. I can not really test the trunk with the HSM, I'll report when we upgrade. Sorry for taking so long to reply. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Wed Jul 21 08:59:10 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Wed, 21 Jul 2010 09:59:10 +0100 Subject: [Opendnssec-develop] Importing shared keys Message-ID: <201007210959.10585.sion@nominet.org.uk> I'm getting through the shared keys work and am beginning to get to some of the things that I hadn't thought about before. So this may be the first of many questions... What would people like to see happen on key import? Currently you need to specify a zone to import the key onto, and then we have a choice: Make this key available to other zones on the policy, or don't. The simplest thing is to make it available, but are there reasons why we may not want to do this? On this note, are there any reasons to have an "import onto policy" function where you can import a key in a particular state and it will appear in that state in all zones on that policy? (Currently the key would be in the imported state on the zone it was imported on, and just in the general pool of unused keys for all other zones.) Cheers, Sion From roland.vanrijswijk at surfnet.nl Wed Jul 21 09:21:55 2010 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 21 Jul 2010 11:21:55 +0200 Subject: [Opendnssec-develop] Importing shared keys In-Reply-To: <201007210959.10585.sion@nominet.org.uk> References: <201007210959.10585.sion@nominet.org.uk> Message-ID: <4C46BC33.6050208@surfnet.nl> Hi Sion, Sion Lloyd wrote: > I'm getting through the shared keys work and am beginning to get to some of > the things that I hadn't thought about before. So this may be the first of > many questions... > > What would people like to see happen on key import? Currently you need to > specify a zone to import the key onto, and then we have a choice: > > Make this key available to other zones on the policy, > > or > > don't. > > The simplest thing is to make it available, but are there reasons why we may > not want to do this? Importing a key is probably something that you want to do if you have a zone that is being migrated from "tool X" to OpenDNSSEC (either because of a change in tooling or because of a move from one DNS operator to the other). If this key is linked to a single zone only, then it makes sense (IMHO) to link it only to that zone. The fun starts when you consider that people may be changing their policy from having one key per zone with "tool X" (for instance, because that tool only supports such simple policies) to shared keys. We could call this a "policy rollover". In this case, the workflow I imagine would be: - Create a single-zone, non-shared key policy for the zone+key to import - Have a "policy rollover" mechanism where you can move a zone from one policy to another (i.e. from non-shared to shared) (in effect, this is a KSK + ZSK rollover for the zone that is being moved) > On this note, are there any reasons to have an "import onto policy" function > where you can import a key in a particular state and it will appear in that > state in all zones on that policy? (Currently the key would be in the imported > state on the zone it was imported on, and just in the general pool of unused > keys for all other zones.) I'm not sure if you would need that, my suggestion would be to look at the use case I described above and then decide if you need this. Hope this helps... Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From sion at nominet.org.uk Wed Jul 21 10:08:40 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Wed, 21 Jul 2010 11:08:40 +0100 Subject: [Opendnssec-develop] Importing shared keys In-Reply-To: <4C46BC33.6050208@surfnet.nl> References: <201007210959.10585.sion@nominet.org.uk> <4C46BC33.6050208@surfnet.nl> Message-ID: <201007211108.40720.sion@nominet.org.uk> > > What would people like to see happen on key import? Currently you need to > > specify a zone to import the key onto, and then we have a choice: > > > > Make this key available to other zones on the policy, > > > > or > > > > don't. > > > > The simplest thing is to make it available, but are there reasons why we > > may not want to do this? > > Importing a key is probably something that you want to do if you have a > zone that is being migrated from "tool X" to OpenDNSSEC (either because > of a change in tooling or because of a move from one DNS operator to the > other). If this key is linked to a single zone only, then it makes sense > (IMHO) to link it only to that zone. Right. I would certainly only link it to that one zone initially. However if you are sharing all other keys why not this one? Currently it would go into the pool of unused keys for other zones on the policy, is this bad? > The fun starts when you consider that people may be changing their > policy from having one key per zone with "tool X" (for instance, because > that tool only supports such simple policies) to shared keys. We could > call this a "policy rollover". In this case, the workflow I imagine > would be: > > - Create a single-zone, non-shared key policy for the zone+key to import > > - Have a "policy rollover" mechanism where you can move a zone from one > policy to another (i.e. from non-shared to shared) (in effect, this is a > KSK + ZSK rollover for the zone that is being moved) I'm not sure that we want/need a policy rollover where the policies are identical apart from the shared-keys parameter. I would need to be persuaded on this one. > > On this note, are there any reasons to have an "import onto policy" > > function where you can import a key in a particular state and it will > > appear in that state in all zones on that policy? (Currently the key > > would be in the imported state on the zone it was imported on, and just > > in the general pool of unused keys for all other zones.) > > I'm not sure if you would need that, my suggestion would be to look at > the use case I described above and then decide if you need this. Cool, makes my life easier. > Hope this helps... Yes, thank you. It also makes me think of something else. Currently you can import any key onto a zone, _even_ if it does not comply with the current policy... This will no doubt confuse the auditor, so should we stop it from importing, warn or something else? Sion From roland.vanrijswijk at surfnet.nl Wed Jul 21 10:16:47 2010 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 21 Jul 2010 12:16:47 +0200 Subject: [Opendnssec-develop] Importing shared keys In-Reply-To: <201007211108.40720.sion@nominet.org.uk> References: <201007210959.10585.sion@nominet.org.uk> <4C46BC33.6050208@surfnet.nl> <201007211108.40720.sion@nominet.org.uk> Message-ID: <4C46C90F.5000508@surfnet.nl> Hi Sion, Sion Lloyd wrote: > Right. I would certainly only link it to that one zone initially. However if > you are sharing all other keys why not this one? Currently it would go into > the pool of unused keys for other zones on the policy, is this bad? Not necessarily, I guess it will just sit in that pool and not be used. > I'm not sure that we want/need a policy rollover where the policies are > identical apart from the shared-keys parameter. I would need to be persuaded > on this one. Ah, my bad, I'm thinking in solutions. The use case is simple: I would like to be able to move a zone from a one-key-per-zone situation to a shared-key situation. How that is solved doesn't really matter (but a policy rollover is one option, another is to change an existing policy). The rationale for this is simple: we cannot have shared keys in our set up as it is because of the limitations in OpenDNSSEC 1.1.x; in the future, however, when OpenDNSSEC does support this, we want to be able to migrate from a one-key-per-zone situation to a one-key-per-customer (shared) situation. > Yes, thank you. It also makes me think of something else. Currently you can > import any key onto a zone, _even_ if it does not comply with the current > policy... This will no doubt confuse the auditor, so should we stop it from > importing, warn or something else? Ah. My personal opinion is that this is a "deny and give an error unless user specifies --force" situation ;-) Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From sion at nominet.org.uk Wed Jul 21 10:44:54 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Wed, 21 Jul 2010 11:44:54 +0100 Subject: [Opendnssec-develop] Importing shared keys In-Reply-To: <4C46C90F.5000508@surfnet.nl> References: <201007210959.10585.sion@nominet.org.uk> <201007211108.40720.sion@nominet.org.uk> <4C46C90F.5000508@surfnet.nl> Message-ID: <201007211144.54745.sion@nominet.org.uk> > > Right. I would certainly only link it to that one zone initially. However > > if you are sharing all other keys why not this one? Currently it would > > go into the pool of unused keys for other zones on the policy, is this > > bad? > > Not necessarily, I guess it will just sit in that pool and not be used. Why shouldn't the key be used? > > I'm not sure that we want/need a policy rollover where the policies are > > identical apart from the shared-keys parameter. I would need to be > > persuaded on this one. > > Ah, my bad, I'm thinking in solutions. The use case is simple: I would > like to be able to move a zone from a one-key-per-zone situation to a > shared-key situation. How that is solved doesn't really matter (but a > policy rollover is one option, another is to change an existing policy). > The rationale for this is simple: we cannot have shared keys in our set > up as it is because of the limitations in OpenDNSSEC 1.1.x; in the > future, however, when OpenDNSSEC does support this, we want to be able > to migrate from a one-key-per-zone situation to a one-key-per-customer > (shared) situation. Okay. I think that I misunderstood "rollover" in this... Do you mean that we immediately retire the current set of keys, or just that all new keys will come from the new policy? I have a story set up for this: http://www.pivotaltracker.com/story/show/1086197 Moving from unshared to shared is okay I think, anything else is a bit more tricky; but let's not worry about that right now. > > Yes, thank you. It also makes me think of something else. Currently you > > can import any key onto a zone, _even_ if it does not comply with the > > current policy... This will no doubt confuse the auditor, so should we > > stop it from importing, warn or something else? > > Ah. My personal opinion is that this is a "deny and give an error unless > user specifies --force" situation ;-) Sounds good to me. Sion From roland.vanrijswijk at surfnet.nl Wed Jul 21 10:57:23 2010 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 21 Jul 2010 12:57:23 +0200 Subject: [Opendnssec-develop] Importing shared keys In-Reply-To: <201007211144.54745.sion@nominet.org.uk> References: <201007210959.10585.sion@nominet.org.uk> <201007211108.40720.sion@nominet.org.uk> <4C46C90F.5000508@surfnet.nl> <201007211144.54745.sion@nominet.org.uk> Message-ID: <4C46D293.1050504@surfnet.nl> Hi Sion, Sion Lloyd wrote: > Why shouldn't the key be used? Because the other zones in the policy already participate in a shared-key scheme, right? And it is not a "new" (fresh) key since it is already in use for a zone. Thinking about this: I guess a move from unshared to shared is: - Add zone to shared policy - Import zone keys into policy - Next policy-based roll or user forced roll will move zone from unshared to shared - Discard keys Would that work? > Okay. I think that I misunderstood "rollover" in this... Do you mean that we > immediately retire the current set of keys, or just that all new keys will > come from the new policy? I think both are valid options, see above. > > I have a story set up for this: > http://www.pivotaltracker.com/story/show/1086197 > > Moving from unshared to shared is okay I think, anything else is a bit more > tricky; but let's not worry about that right now. I can see why anything else might be a bit more tricky. Isn't it possible, though, to assign one key to multiple policies? In that case, a move from shared to unshared could be: - Assign shared key to new unshared policy - Next policy-based roll or user forced roll will move zone from shared to unshared - Remove shared key from policy The problem here - I think - is that you cannot discard the shared key until all zones that used to share it have moved to an unshared policy; a possible solution is to introduce reference counting (i.e. keys have an attribute that specifies the number of policies a key is used in). Keys can only be discard once the reference count reaches 0. Obviously you would need to be able to distinguish between "fresh" unused keys and "dirty" used keys. 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 Wed Jul 21 11:00:23 2010 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 21 Jul 2010 13:00:23 +0200 Subject: [Opendnssec-develop] Importing shared keys In-Reply-To: <866DB234-44BC-4868-93BE-0DC1D488E570@nominet.org.uk> References: <201007210959.10585.sion@nominet.org.uk> <201007211108.40720.sion@nominet.org.uk> <4C46C90F.5000508@surfnet.nl> <201007211144.54745.sion@nominet.org.uk> <866DB234-44BC-4868-93BE-0DC1D488E570@nominet.org.uk> Message-ID: <4C46D347.3030905@surfnet.nl> Hi Alex, Alex Dalitz wrote: >>> Ah. My personal opinion is that this is a "deny and give an error >>> unless user specifies --force" situation ;-) >> Sounds good to me. > > We have a "--force" option?! > > If we don't, and decide we need one, what should the semantics be? > i.e. Are we talking about a "disable audit for this run" flag, or for > the lifetime of the policy-incompatible key, or something else? Hmm... I was merely suggesting the general idea; it is bad practice to import keys that do not meet the policy, on the other hand there are always user who - for some reason or other - need to do this. What if, for instance, you want to move a zone to a shared-key policy and the new policies requires bigger keys? What would that use case look like (and which requirements does that translate to)? Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From AlexD at nominet.org.uk Wed Jul 21 11:15:37 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 21 Jul 2010 11:15:37 +0000 Subject: [Opendnssec-develop] Importing shared keys In-Reply-To: <4C46D347.3030905@surfnet.nl> References: <201007210959.10585.sion@nominet.org.uk> <201007211108.40720.sion@nominet.org.uk> <4C46C90F.5000508@surfnet.nl> <201007211144.54745.sion@nominet.org.uk> <866DB234-44BC-4868-93BE-0DC1D488E570@nominet.org.uk> <4C46D347.3030905@surfnet.nl> Message-ID: <779CADE0-0B3E-4AA6-B483-2340A35D58D8@nominet.org.uk> > What if, for instance, you want to move a zone to a shared-key policy > and the new policies requires bigger keys? What would that use case look > like (and which requirements does that translate to)? Handling a policy change for a zone is something I'm just about to start work on. The auditor (for version 1.2) will see that the policy has changed, and suppress errors for cases which have been caused by a change in policy. I'm not sure how we'd handle importing keys which did not obey the policy. Some kind of "imported-keys" file to record the keys which have been imported, so the auditor can ignore them, possibly? Thanks, Alex. From roland.vanrijswijk at surfnet.nl Wed Jul 21 11:20:00 2010 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 21 Jul 2010 13:20:00 +0200 Subject: [Opendnssec-develop] Importing shared keys In-Reply-To: <779CADE0-0B3E-4AA6-B483-2340A35D58D8@nominet.org.uk> References: <201007210959.10585.sion@nominet.org.uk> <201007211108.40720.sion@nominet.org.uk> <4C46C90F.5000508@surfnet.nl> <201007211144.54745.sion@nominet.org.uk> <866DB234-44BC-4868-93BE-0DC1D488E570@nominet.org.uk> <4C46D347.3030905@surfnet.nl> <779CADE0-0B3E-4AA6-B483-2340A35D58D8@nominet.org.uk> Message-ID: <4C46D7E0.8040706@surfnet.nl> Hi Alex, Alex Dalitz wrote: > Handling a policy change for a zone is something I'm just about to > start work on. The auditor (for version 1.2) will see that the policy > has changed, and suppress errors for cases which have been caused by > a change in policy. That sounds like a good way of handling this. > I'm not sure how we'd handle importing keys which did not obey the > policy. Some kind of "imported-keys" file to record the keys which > have been imported, so the auditor can ignore them, possibly? Possibly. Although I would like to guard against the user having to specify this explicitly; maybe if an "imported key" flag is there, the auditor can ignore non-compliance (perhaps generate a warning? "imported key does not adhere to policy"). Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From sion at nominet.org.uk Wed Jul 21 13:46:29 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Wed, 21 Jul 2010 14:46:29 +0100 Subject: [Opendnssec-develop] Importing shared keys In-Reply-To: <4C46D293.1050504@surfnet.nl> References: <201007210959.10585.sion@nominet.org.uk> <201007211144.54745.sion@nominet.org.uk> <4C46D293.1050504@surfnet.nl> Message-ID: <201007211446.29428.sion@nominet.org.uk> > > Why shouldn't the key be used? > > Because the other zones in the policy already participate in a > shared-key scheme, right? And it is not a "new" (fresh) key since it is > already in use for a zone. Thinking about this: I guess a move from > unshared to shared is: > > - Add zone to shared policy > - Import zone keys into policy > - Next policy-based roll or user forced roll will move zone from > unshared to shared > - Discard keys > > Would that work? Yes. However you can import keys in the GENERATE state also, say you create them with hsmutil but then want OpenDNSSEC to use them. In this case I imagine that you would want to allow multiple zones to use that key... Is this ever likely to happen? (It is allowed in the current system.) Sion From matthijs at NLnetLabs.nl Thu Jul 22 12:00:37 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 22 Jul 2010 14:00:37 +0200 Subject: [Opendnssec-develop] How to handle TTL < SOA Minimum Message-ID: <4C4832E5.4010909@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In the process of moving the c based signer engine into trunk, I bumped into several issues, one being related to TTLs. I have a RR that has the TTL field omitted. The signer fills in the the SOA Minimum or the $TTL, if set. The auditor correctly pointed out that I should take the last explicit stated value instead. Now it comes, this is a TTL that is lower than the SOA MINIMUM. How should we handle those TTLs? Must the signer use the explicit TTL or the SOA MINIMUM in this case? I think so. Such a change also has consequences for the auditor. Because the RR is changed, the current auditor will complain. Also, it would be good to check if the DNSKEY TTL and SOA TTL in the signer configuration is equal or higher than the SOA Minimum configuration value. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMSDLlAAoJEA8yVCPsQCW5lUQIAK4+j5tiSYworrLZ/YSvXAQj kt2SjZ//zZs71Jw+mnSsLmU/Z+SkETrw1196UPa2DyBgYp1GiL6+1qo4zjfO2o9N +b5v4VbDZhyg6R00mjRdEQLahW0b5peiv2cYVnEvIUfvtZReLKe7NawHH5vbgzZM f9GtdRu6rDRVtwQYWxyurMZxH4p30dVWdOMVZ8esnTlXA8jC2vwyNszwoPfq8WxQ 9WtxGFnfqz0MIOnYk1Grl9EmSsfEvQWmhPsIAsTwG7gah9tz/2rXoMEX+LMCyH12 rlCO1+KHrkmJkFdeond4HCEzCA0u6d4x2RLO3YQea8vOu2d8a/jhZ6gPeWq0lZU= =Pcbd -----END PGP SIGNATURE----- From AlexD at nominet.org.uk Fri Jul 23 08:38:11 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Fri, 23 Jul 2010 08:38:11 +0000 Subject: [Opendnssec-develop] How to handle TTL < SOA Minimum In-Reply-To: <4C4832E5.4010909@nlnetlabs.nl> References: <4C4832E5.4010909@nlnetlabs.nl> Message-ID: On 22 Jul 2010, at 13:00, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > In the process of moving the c based signer engine into trunk, I bumped > into several issues, one being related to TTLs. I have a RR that has the > TTL field omitted. The signer fills in the the SOA Minimum or the $TTL, > if set. The auditor correctly pointed out that I should take the last > explicit stated value instead. > > Now it comes, this is a TTL that is lower than the SOA MINIMUM. How > should we handle those TTLs? Must the signer use the explicit TTL or the > SOA MINIMUM in this case? I think so. I think so too. > Such a change also has > consequences for the auditor. Because the RR is changed, the current > auditor will complain. I will change the spec and implementation to deal with this (unless somebody else speaks up!). > Also, it would be good to check if the DNSKEY TTL and SOA TTL in the > signer configuration is equal or higher than the SOA Minimum > configuration value. Yes - I'll add that to the requirements and implementation. Thanks, Alex. From AlexD at nominet.org.uk Fri Jul 23 08:42:54 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Fri, 23 Jul 2010 08:42:54 +0000 Subject: [Opendnssec-develop] How to handle TTL < SOA Minimum In-Reply-To: References: <4C4832E5.4010909@nlnetlabs.nl> Message-ID: <8843DA61-CAA3-4EB1-84C7-700E52FD2990@nominet.org.uk> >> >> Now it comes, this is a TTL that is lower than the SOA MINIMUM. How >> should we handle those TTLs? Must the signer use the explicit TTL or the >> SOA MINIMUM in this case? I think so. > > I think so too. To avoid any confusion : I think the SOA Minimum should be used in this case - NOT the explicit TTL. Thanks, Alex. From owner-dnssec-trac at kirei.se Sun Jul 25 17:21:30 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 25 Jul 2010 17:21:30 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #97: How to see the GENERATED keys? In-Reply-To: <087.0a891918cc85b7a056513d2ec376e59a@kirei.se> References: <087.0a891918cc85b7a056513d2ec376e59a@kirei.se> Message-ID: <096.c63e41590ce500582407b345ecac9464@kirei.se> #97: How to see the GENERATED keys? ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: sion Type: defect | Status: accepted Priority: major | Component: Enforcer Version: 1.0.0 | Keywords: ---------------------------------------------------------------+------------ Comment(by robert@?): Thanks Sion. This is really a nice feature, I was about to report myself. Please put it high on your list. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sun Jul 25 17:25:31 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 25 Jul 2010 17:25:31 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #162: libhsm dependency reintroduced in r3586 breaks build Message-ID: <061.a7190f1b2a09e76ef9679e4523168854@kirei.se> #162: libhsm dependency reintroduced in r3586 breaks build ------------------------------------+--------------------------------------- Reporter: robert@? | Owner: matthijs Type: defect | Status: new Priority: blocker | Component: Signer Version: trunk | Keywords: libhsm reintroduced build break jakob matthijs ------------------------------------+--------------------------------------- On revisions after 3586 the signer can't be built on a "clean system" because of a libhsm dependency. I suppose hasn't been detected by tests, because maybe your system isn't as clean. It reintroduces some files which was removed in revision 3552 by Jakob. --8<-- checking what are the libhsm libs... -L/usr/local/lib -lhsm checking libhsm.h usability... no checking libhsm.h presence... no checking for libhsm.h... no configure: error: libhsm not found in source tree nor on system configure: error: ./configure failed for signer -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 05:22:20 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 05:22:20 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #161: Patch: 2-phase key backup for ksmutil In-Reply-To: <045.dbe3ce6fe250145055e6983accf2520c@kirei.se> References: <045.dbe3ce6fe250145055e6983accf2520c@kirei.se> Message-ID: <054.98b466ef56cc0e837d56f7508cc67407@kirei.se> #161: Patch: 2-phase key backup for ksmutil ------------------------+--------------------------------------------------- Reporter: vanrein | Owner: sion Type: enhancement | Status: new Priority: major | Component: Enforcer Version: | Keywords: 2-phase backup ------------------------+--------------------------------------------------- Comment(by vanrein): Hi, Jakob, you've mentioned bringing down the KASP Enforcer, so we tried it. The only thing it did was move the synchronisation problem out of OpenDNSSEC and into surrounding scripts. This results in the opposite of our intention of simplifying the rolling out of DNSSEC. Can you please explain why you think this need not go into OpenDNSSEC? We only see evidence that we were right to ask for this months ago (details follow). Please note that you're the first one I ever hear talking about the precaution of stopping a database during its backup -- I've seen enough mature database solutions run by paranoid operators that happily do without. As for versioning and "new feature" status, it's interesting for us to not have to wait this long. During a recent meeting we therefore agreed to make a simple patch to 1.1.1 and release it as a working version 1.1.2 that would include a (possibly intermediary) version of this feature. Since we've been asking for it months ago already, and since we're the ones who experienced the problems arising from the stop-KASP-Enforcer approach, we thought we'd best submit a patch, making the inclusion of such functionality a breeze. That's the patch submitted here. We believe that it will be of value to all current users of OpenDNSSEC and that it is vital to the registrar-level (of which we are earlybird examples) which we should aim for as soon as possible, now that the root is signed. If that implies using other numbering than 1.1.2 then we might have to consider that, or perhaps even bending the release rules. As for the details of what we experienced when stopping the KASP Enforcer: To the backup process, it is vitally important that the KASP Enforcer is not running. To ensure that, other processes that may stop the KASP Enforcer (such as database backup, and even plain manual intervention) should never start it back up if a key backup is in progress. What we did to achieve that, is to ensure that the KASP Enforcer cannot be taken down by more than one process at a time; we submitted a patch to /etc/init.d /ods-control to support that level of control and feedback. The problem then became that other procedures would block, while waiting for the KASP Enforcer to come back online. This is an inconvenience, and it is hard to distinguish from a crash of parts of the software. Something else we've noticed is that the KASP Enforcer is not designed to handle quick stop/start sequences, and is therefore better kept running. If not, the PID file and the actual PID start mismatching, so ods-control gets confused, and the KASP Enforcer does not terminate properly. All this strengthened our desire to see this small piece of synchronisation put in the place where its need arises, namely during the backup commands. It helps us to solve the problem we see, and may help others to avoid running into such problems by overlooking them. -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 07:45:15 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 07:45:15 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #163: Support for importing bind private keys v1.3 Message-ID: <054.ff75bb7132b29a4ac0c11554e6f9119e@kirei.se> #163: Support for importing bind private keys v1.3 -----------------------------+---------------------------------------------- Reporter: ruben@? | Owner: rb Type: enhancement | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: -----------------------------+---------------------------------------------- Attached patch allows softhsm-keyconv import bind private keys that have been created by bind 9.7 (key version format v1.3) Output is still 1.2. v1.3 adds 3 time related records that can be safely ignored -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 07:59:42 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 07:59:42 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #147: znakomstvo s transseksualom v moskve In-Reply-To: <047.538730927a67a77e1dbd5dbdba7fc45e@kirei.se> References: <047.538730927a67a77e1dbd5dbdba7fc45e@kirei.se> Message-ID: <056.afa76c399651a7226aafd2566f92ec86@kirei.se> #147: znakomstvo s transseksualom v moskve ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:00:00 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:00:00 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #148: obyavleniya intim uslug v moskve In-Reply-To: <047.3c6bffa58ec9ba5a5802a0bf21af9a7a@kirei.se> References: <047.3c6bffa58ec9ba5a5802a0bf21af9a7a@kirei.se> Message-ID: <056.8648d3d06d36d13cab31a6190abb6948@kirei.se> #148: obyavleniya intim uslug v moskve ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:00:14 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:00:14 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #149: moskva uslugi seks individualki In-Reply-To: <047.b6268e3f423c56a1119c10aded3d157d@kirei.se> References: <047.b6268e3f423c56a1119c10aded3d157d@kirei.se> Message-ID: <056.19906e3a7bca649d0d33ad025c370fe7@kirei.se> #149: moskva uslugi seks individualki ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:00:27 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:00:27 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #150: prostitutki intim dosug moskva In-Reply-To: <047.700a6c84416ec2637f9531c48de512b8@kirei.se> References: <047.700a6c84416ec2637f9531c48de512b8@kirei.se> Message-ID: <056.65c516348a04fb86a3e270c7ac6e9484@kirei.se> #150: prostitutki intim dosug moskva ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:00:38 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:00:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #152: fisting prostitutki moskvy In-Reply-To: <047.628ee287b1f5ecfc5a033074a7f966f3@kirei.se> References: <047.628ee287b1f5ecfc5a033074a7f966f3@kirei.se> Message-ID: <056.04ae9485d2ecc2202178d1d3623c7b50@kirei.se> #152: fisting prostitutki moskvy ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:00:51 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:00:51 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #153: chernye prostitutki moskvy In-Reply-To: <047.89ea7f616b4220416c61d7542cafc2ff@kirei.se> References: <047.89ea7f616b4220416c61d7542cafc2ff@kirei.se> Message-ID: <056.f106f663d6b4c8561eb6368f35dcdd95@kirei.se> #153: chernye prostitutki moskvy ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:01:02 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:01:02 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #154: prostitutki moskvy s bolshoj grudyu In-Reply-To: <047.67bda1f5e062f3e727ec9cdb645f94eb@kirei.se> References: <047.67bda1f5e062f3e727ec9cdb645f94eb@kirei.se> Message-ID: <056.8c806dfbcd7e48f19eb5759eedf7c081@kirei.se> #154: prostitutki moskvy s bolshoj grudyu ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:01:15 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:01:15 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #155: shlyuxi moskvy aziatki In-Reply-To: <047.b647141e6d08fbfb6defbc4571d8a76b@kirei.se> References: <047.b647141e6d08fbfb6defbc4571d8a76b@kirei.se> Message-ID: <056.8b8955e1946376d37e9acd5eee470219@kirei.se> #155: shlyuxi moskvy aziatki ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:01:25 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:01:25 -0000 Subject: [Opendnssec-develop] =?utf-8?b?UmU6IFtPcGVuRE5TU0VDXSAjMTU4OiA=?= =?utf-8?b?0KHQvdGP0YLRjCDQv9GA0L7RgdGC0LjRgtGD0YLQutGDINCyINCc0L7RgdC6?= =?utf-8?b?0LLQtQ==?= In-Reply-To: <047.f97f97f1d277ca24265db30c4d94920a@kirei.se> References: <047.f97f97f1d277ca24265db30c4d94920a@kirei.se> Message-ID: <056.5a5d3da4f3e457738abf020b63055217@kirei.se> #158: ????? ??????????? ? ?????? ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:01:36 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:01:36 -0000 Subject: [Opendnssec-develop] =?utf-8?b?UmU6IFtPcGVuRE5TU0VDXSAjMTU5OiA=?= =?utf-8?b?0KHQvdGP0YLRjCDQv9GA0L7RgdGC0LjRgtGD0YLQutGDINCyINCc0L7RgdC6?= =?utf-8?b?0LLQtQ==?= In-Reply-To: <047.ae256a906fce183ce9a3916adebbd970@kirei.se> References: <047.ae256a906fce183ce9a3916adebbd970@kirei.se> Message-ID: <056.1d32eb91802dd8f912875968aff4f8ce@kirei.se> #159: ????? ??????????? ? ?????? ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:02:11 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:02:11 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #144: Printing in China In-Reply-To: <055.a888d2d1d5c6e4d7fe3a51a5aafb807b@kirei.se> References: <055.a888d2d1d5c6e4d7fe3a51a5aafb807b@kirei.se> Message-ID: <064.d85d0e017840cc7925f5c53d8d80b268@kirei.se> #144: Printing in China ------------------------------+--------------------------------------------- Reporter: Printing in China | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: invalid Keywords: Printing in China | ------------------------------+--------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:02:25 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:02:25 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #145: Printing in China In-Reply-To: <055.09824a8cddde0737517aa9dbeaf1f18a@kirei.se> References: <055.09824a8cddde0737517aa9dbeaf1f18a@kirei.se> Message-ID: <064.51a8307d6a60b80e63e5b30a128434c6@kirei.se> #145: Printing in China ------------------------------+--------------------------------------------- Reporter: Printing in China | Owner: rb Type: task | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: invalid Keywords: Printing in China | ------------------------------+--------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 08:03:03 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 08:03:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #160: Adobe Creative Suite 2 Premium In-Reply-To: <047.0d0ddf9c18026453c20a67bb2cd805a0@kirei.se> References: <047.0d0ddf9c18026453c20a67bb2cd805a0@kirei.se> Message-ID: <056.9a9e07fad79c05d90318c49ad7346b45@kirei.se> #160: Adobe Creative Suite 2 Premium ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 12:07:31 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 12:07:31 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #162: libhsm dependency reintroduced in r3586 breaks build In-Reply-To: <061.a7190f1b2a09e76ef9679e4523168854@kirei.se> References: <061.a7190f1b2a09e76ef9679e4523168854@kirei.se> Message-ID: <070.8706e563db831d9c33992dbe025cbc45@kirei.se> #162: libhsm dependency reintroduced in r3586 breaks build ------------------------------------+--------------------------------------- Reporter: robert@? | Owner: rb Type: defect | Status: accepted Priority: blocker | Component: Signer Version: trunk | Keywords: libhsm reintroduced build break jakob matthijs ------------------------------------+--------------------------------------- Changes (by rb): * owner: matthijs => rb * status: new => accepted Comment: This was during the migration to the c based engine. The issue looks to be solved in current trunk. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 12:10:18 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 12:10:18 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #143: ods-signer flush moves queue further away In-Reply-To: <056.51661cc4481924e8e4b59b58961cef26@kirei.se> References: <056.51661cc4481924e8e4b59b58961cef26@kirei.se> Message-ID: <065.5725c96b588622d8d8c5174f4e8928e8@kirei.se> #143: ods-signer flush moves queue further away -------------------------------+-------------------------------------------- Reporter: dnssec@? | Owner: rb Type: defect | Status: accepted Priority: major | Component: Unknown Version: trunk | Keywords: -------------------------------+-------------------------------------------- Comment(by rb): Did I answer your question? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 12:20:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 12:20:08 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #156: ods-control ksm {start|stop} doesn't work In-Reply-To: <061.9721ad3311e47055fddc721be71f2301@kirei.se> References: <061.9721ad3311e47055fddc721be71f2301@kirei.se> Message-ID: <070.f8e60c41bf6672836cfd78714efcf5be@kirei.se> #156: ods-control ksm {start|stop} doesn't work ------------------------------------+--------------------------------------- Reporter: robert@? | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ksm stop doesn't work ------------------------------------+--------------------------------------- Comment(by rb): Yes, I can confirm this. The string after "ods-control ksm" is forward to ods-ksmutil. "start" and "stop" is not implemented in ods-ksmutil. We should implement this support. For now you can do: killall -TERM ods-enforcerd # backup the HSM ods-ksmutil backup done ods-enforcerd -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jul 26 12:26:05 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Jul 2010 12:26:05 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #163: Support for importing bind private keys v1.3 In-Reply-To: <054.ff75bb7132b29a4ac0c11554e6f9119e@kirei.se> References: <054.ff75bb7132b29a4ac0c11554e6f9119e@kirei.se> Message-ID: <063.bef737e1c9e00f7637b9e7bea0c5191c@kirei.se> #163: Support for importing bind private keys v1.3 -----------------------------+---------------------------------------------- Reporter: ruben@? | Owner: rb Type: enhancement | Status: accepted Priority: minor | Component: SoftHSM Version: trunk | Keywords: -----------------------------+---------------------------------------------- Changes (by rb): * status: new => accepted Comment: Thanks for the patch. Something similar will go into SoftHSM v2 where we will do code refactoring on this tool. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jul 27 08:43:25 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 27 Jul 2010 08:43:25 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #162: libhsm dependency reintroduced in r3586 breaks build In-Reply-To: <061.a7190f1b2a09e76ef9679e4523168854@kirei.se> References: <061.a7190f1b2a09e76ef9679e4523168854@kirei.se> Message-ID: <070.77741061804bdaec766d007d5e40fb56@kirei.se> #162: libhsm dependency reintroduced in r3586 breaks build ------------------------------------+--------------------------------------- Reporter: robert@? | Owner: rb Type: defect | Status: accepted Priority: blocker | Component: Signer Version: trunk | Keywords: libhsm reintroduced build break jakob matthijs ------------------------------------+--------------------------------------- Comment(by matthijs): Is this fixed in in r3599, after jakob integrated the signer configure into the main configure? -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at openfortress.nl Tue Jul 27 09:48:20 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 27 Jul 2010 09:48:20 +0000 Subject: [Opendnssec-develop] Reloading zonelists into the signer engine Message-ID: <20100727094820.GE721@phantom.vanrein.org> Hey Sion, You've probably noticed the patches that I uploaded through trac. I imagine the signing of "uk" is keeping you busy though! There's one more patch to come, which we'd need for our more dynamic use of OpenDNSSEC. I would intend it to go into 1.2 and/or 1.1.2, to be discussed in the face-to-face meeting. What I've proposed Matthijs (in Dutch, silly me) is to patch the signer for a command like "ods-signer reload" that would ask it to fetch the zonelist and merge it with its held status. In the same patch, I could have the KASP Enforcer send that command after it reloads the zonelist. Do you agree that this is a sensible improvement with registrar signing service in mind? Cheers, -Rick From rick at openfortress.nl Tue Jul 27 10:29:45 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 27 Jul 2010 10:29:45 +0000 Subject: [Opendnssec-develop] Reloading zonelists into the signer engine In-Reply-To: <20100727094820.GE721@phantom.vanrein.org> References: <20100727094820.GE721@phantom.vanrein.org> Message-ID: <20100727102945.GG721@phantom.vanrein.org> Hi Sion/Matthijs, > What I've proposed Matthijs is to patch the signer > for a command like "ods-signer reload" that would ask it to fetch the > zonelist and merge it with its held status. I found that it can already do "ods-signer update" with those semantics. What remains then is the question if it is considered a good idea to invoke that after "ods-ksmutil update zonelist" and "ods-ksmutil update all" or if this should be left to the surrounding utilities. Cheers, -Rick From matthijs at NLnetLabs.nl Tue Jul 27 12:24:27 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 27 Jul 2010 14:24:27 +0200 Subject: [Opendnssec-develop] Reloading zonelists into the signer engine In-Reply-To: <20100727102945.GG721@phantom.vanrein.org> References: <20100727094820.GE721@phantom.vanrein.org> <20100727102945.GG721@phantom.vanrein.org> Message-ID: <4C4ECFFB.3050504@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rick, I think it would be more logical to invoke it after ods-signer update, since the zone fetcher is controlled by the signer. Best regards, Matthijs On 07/27/2010 12:29 PM, Rick van Rein wrote: > Hi Sion/Matthijs, > >> What I've proposed Matthijs is to patch the signer >> for a command like "ods-signer reload" that would ask it to fetch the >> zonelist and merge it with its held status. > > I found that it can already do "ods-signer update" with those semantics. > > What remains then is the question if it is considered a good idea to invoke > that after "ods-ksmutil update zonelist" and "ods-ksmutil update all" or > if this should be left to the surrounding utilities. > > > Cheers, > -Rick > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMTs/7AAoJEA8yVCPsQCW5AKAH/0OtVamaJ9HgC4ONPYC/ai1l 6blgGt6Kx+ApmpBix3NehIsNcwwOu8/5R4ftAefsAKNs553TUyNC6n9MB6oCsLjq D9UBIQw5N8g/McjyLdxzNNCtuPO8PaICcLt5DhZniovm8Bbl1BOYAHO79Dan9PHl bAntA27hb1FFl25FkLAIOrYZKIR44S2Fz/ClqgINv0VL27GjAczCbGW+u0eacpqE MocFxji6TvCg/PAY/MR3odcZ/0Y2YUJSMKLNGut7Tzo6ryhb68FF2NWtdAvI8HML TahVSvS2FhJrktjnTCGpg6zQag4DYkxboiaWBhPBlMGJup8mHot5eDC7FHhXtEQ= =YfK4 -----END PGP SIGNATURE----- From roland.vanrijswijk at surfnet.nl Tue Jul 27 12:39:37 2010 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 27 Jul 2010 14:39:37 +0200 Subject: [Opendnssec-develop] Re: 2-phase key backup for ksmutil In-Reply-To: <1437B19B-F4AB-4ABF-8029-BA0D6B1DC22B@kirei.se> References: <045.dbe3ce6fe250145055e6983accf2520c@kirei.se> <054.98b466ef56cc0e837d56f7508cc67407@kirei.se> <20100727082819.GC32118@phantom.vanrein.org> <4C4EA1BC.4020602@surfnet.nl> <20100727093313.GC721@phantom.vanrein.org> <1437B19B-F4AB-4ABF-8029-BA0D6B1DC22B@kirei.se> Message-ID: <4C4ED389.4090606@surfnet.nl> Hi Jakob, Rick, Jakob Schlyter wrote: > first, we should decide if this is a problem that OpenDNSSEC should > address. I'm still not convinced this is the case, but I will look > into this later this week. I will not be at the f2f meeting in > Maastricht though. OK, shame you cannot make it to the f2f as that would've been a good place to discuss this. I'll add my ?0,02 to the discussion: The KASP already has functionality to address backing up of key material so it is aware of the fact that such things can happen. Having this feature thus means that reckoning with key backup is something that OpenDNSSEC already addresses. Unfortunately, the way in which this currently works is not sufficient when it meets "the real world". In a registrar environment there are potentially thousands if not 10s or 100s of thousands of zones for which key material is constantly being generated and updated. So creating a backup while the current KASP is running is not an option since this may incorrectly mark keys as being backed up (because - for instance - new keys were generated while the backup was running). The only way to do it currently is to stop the KASP, perform the backup and restart the KASP. Unfortunately, that has certain drawbacks: * There is no guarantee that someone or some process does not restart the KASP ad-interim before the "backup done" is sent; this makes this way of working fragile and potentially unreliable. * The current ods-control script does not support this way of working; it has issues with the PID file for the KASP that we have not been able to solve after much debugging (the PID file is sometimes overwritten or contains incorrect information). This also makes this way of working unreliable and requires to add all sorts of extra checks to work around this issue (manual checks with ps, etc.). What we are proposing is to solve this using a simple two-phase commit; it is an extension of existing functionality that is already there by introducing a new state (these keys are now being backed up). This makes it safe to back up keys with both the KASP running and the KASP not running (whichever someone prefers and compatible with existing implementations). And it has the added bonus of not having to stop an important component of a running system. Summarising: in my opinion what we are proposing is an extension to an already existing feature (namely the KASP being aware of keys being backed up before they are used). Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From sion at nominet.org.uk Tue Jul 27 14:35:48 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 27 Jul 2010 15:35:48 +0100 Subject: [Opendnssec-develop] Reloading zonelists into the signer engine In-Reply-To: <4C4ECFFB.3050504@nlnetlabs.nl> References: <20100727094820.GE721@phantom.vanrein.org> <20100727102945.GG721@phantom.vanrein.org> <4C4ECFFB.3050504@nlnetlabs.nl> Message-ID: <201007271535.48568.sion@nominet.org.uk> > I think it would be more logical to invoke it after ods-signer update, > since the zone fetcher is controlled by the signer. Is the use case adding new zones? If it is then after adding the zone with ksmutil you _need_ the enforcer to run to allocate keys to the new zone. Assuming that the enforcer has no problems doing this it will ask the signer to look at the new zone, after creating a new signconf. If the use case is removing zones then ksmutil already calls the signer to say that the zonelist has changed. Or have I misunderstood the request? Sion From jakob at kirei.se Wed Jul 28 05:59:07 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 28 Jul 2010 07:59:07 +0200 Subject: [Opendnssec-develop] How to handle TTL < SOA Minimum In-Reply-To: <8843DA61-CAA3-4EB1-84C7-700E52FD2990@nominet.org.uk> References: <4C4832E5.4010909@nlnetlabs.nl> <8843DA61-CAA3-4EB1-84C7-700E52FD2990@nominet.org.uk> Message-ID: <3A9510C9-EDF8-4049-940E-50270AA1B476@kirei.se> On 23 jul 2010, at 10.42, Alex Dalitz wrote: >>> >>> Now it comes, this is a TTL that is lower than the SOA MINIMUM. How >>> should we handle those TTLs? Must the signer use the explicit TTL or the >>> SOA MINIMUM in this case? I think so. >> >> I think so too. > > To avoid any confusion : I think the SOA Minimum should be used in this case - NOT the explicit TTL. how does BIND handle this? I'm usually a believer in "garbage in, garbage out", so my gut feeling is that the signer should use the explicit TTL. jakob From matthijs at NLnetLabs.nl Wed Jul 28 08:55:59 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 28 Jul 2010 10:55:59 +0200 Subject: [Opendnssec-develop] How to handle TTL < SOA Minimum In-Reply-To: <3A9510C9-EDF8-4049-940E-50270AA1B476@kirei.se> References: <4C4832E5.4010909@nlnetlabs.nl> <8843DA61-CAA3-4EB1-84C7-700E52FD2990@nominet.org.uk> <3A9510C9-EDF8-4049-940E-50270AA1B476@kirei.se> Message-ID: <4C4FF09F.1010803@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yesterday I read RFC 2308 again (didn't had that on top of my head), and that actually deprecates the use of SOA MINIMUM as the floor TTL. Also, the signer should use the lowest TTL of the RRset. Matthijs On 07/28/2010 07:59 AM, Jakob Schlyter wrote: > On 23 jul 2010, at 10.42, Alex Dalitz wrote: > >>>> >>>> Now it comes, this is a TTL that is lower than the SOA MINIMUM. How >>>> should we handle those TTLs? Must the signer use the explicit TTL or the >>>> SOA MINIMUM in this case? I think so. >>> >>> I think so too. >> >> To avoid any confusion : I think the SOA Minimum should be used in this case - NOT the explicit TTL. > > how does BIND handle this? > > I'm usually a believer in "garbage in, garbage out", so my gut feeling is that the signer should use the explicit TTL. > > 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMT/CeAAoJEA8yVCPsQCW5RlsH/1TCdxTHidz840Wo5LS+Xi1g LJy6q+gQ8bjVvJU/Z3EX9MpG6Dpj3o5JMPAMqc/PCy+Zr5r//2qs5AyAQpBYjzCw gDDkeO54viXd9XFs+BD+Nex02EpYptsCWW99Zr4D491u99mbYE8xv08bFjI8YRu7 VG7aA10PTCX3M2/5/3G9M2JHdqdgQ6lw8gAR1lVUE1wv35A3aF47UlewrCKZExiG 4whRaGtMhCyAxgeuVbMQEa++IJySnK0jLiExNa7dDs2o42BT5seJnhXVMmr6GQvL dXbMFFuKNxazyL80yi3ZmTNNPFIrwaHxvENdBdlqLWRWWRpTVczHj1V0UOHYOUI= =w7H4 -----END PGP SIGNATURE----- From rick at openfortress.nl Wed Jul 28 09:00:59 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 28 Jul 2010 09:00:59 +0000 Subject: [Opendnssec-develop] Reloading zonelists into the signer engine In-Reply-To: <201007271535.48568.sion@nominet.org.uk> References: <20100727094820.GE721@phantom.vanrein.org> <20100727102945.GG721@phantom.vanrein.org> <4C4ECFFB.3050504@nlnetlabs.nl> <201007271535.48568.sion@nominet.org.uk> Message-ID: <20100728090059.GB24568@phantom.vanrein.org> Hello Sion/Matthijs, > Is the use case adding new zones? Yes, or a mixture with removing zones. We generate zonelists and then update KASP accordingly. When we add zones, we find that they do not end up in OpenDNSSEC easily, not even when we suggest having backed up keys. > If it is then after adding the zone with ksmutil you _need_ the enforcer to > run to allocate keys to the new zone. Yes, we found that there is no pool of standby keys yet. We let it do that and then issue "backup done". > Assuming that the enforcer has no problems doing this it will ask the signer > to look at the new zone, after creating a new signconf. So, what you are saying is that the problem lies solely in the communication between the signer and the zone_fetcher? But that the enforcer already invokes "ods-signer update"? > If the use case is removing zones then ksmutil already calls the signer to say > that the zonelist has changed. Also through "ods-signer update" I presume? > Or have I misunderstood the request? It's quite possible that I've misunderstood the link between KASP and Signer. If my questionmarked understanding from your words is right, I need only look at the signer/zone_fetcher communication. Thanks, -Rick From matthijs at NLnetLabs.nl Wed Jul 28 09:28:35 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 28 Jul 2010 11:28:35 +0200 Subject: [Opendnssec-develop] Reloading zonelists into the signer engine In-Reply-To: <20100728090059.GB24568@phantom.vanrein.org> References: <20100727094820.GE721@phantom.vanrein.org> <20100727102945.GG721@phantom.vanrein.org> <4C4ECFFB.3050504@nlnetlabs.nl> <201007271535.48568.sion@nominet.org.uk> <20100728090059.GB24568@phantom.vanrein.org> Message-ID: <4C4FF843.9090200@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Short answer: yes. You only need to look at the signer/zone_fetcher communication. The enforcer calls ods-signer update after removing zones. The enforcer calls ods-signer update after adding zones and there are a large enough pool of keys to actual sign the added zones. Best regards, Matthijs On 07/28/2010 11:00 AM, Rick van Rein wrote: > It's quite possible that I've misunderstood the link between KASP and > Signer. If my questionmarked understanding from your words is right, > I need only look at the signer/zone_fetcher communication. > > Thanks, > -Rick > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMT/hDAAoJEA8yVCPsQCW5BYAH/jhH2Tv00mIvLHIEVx2wP54c Q3lp+DUdTcrVGLkCCWF+OXWiN541DUfzSeFR8cdn29Yh/TWT0Zpz5a+dW3B+1Amg MV1CENduHb3hFKCsuIbf7Mt7OkE4L9coRJ7uXtIEHA2TP9UCVccuK5m6apexNMHD qsqSnmkchcMRDG89n4nM605LflstRloTKXB3anEV4lc9y3z+Q8Mu0wrN6aU+SvxH yckGLBj+tJ+1JrrQw+liGdpKEfvqPholLgOhToz7yWaZH9yhVSSE5b+ibSH6iv0C w2XghoVCyayijaOJOkiOZhpF5mGYTE9jOrBHjlfAuNVjnwihje6i9B5BW4ydtLw= =FWCr -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Wed Jul 28 10:45:44 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 28 Jul 2010 10:45:44 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #162: libhsm dependency reintroduced in r3586 breaks build In-Reply-To: <061.a7190f1b2a09e76ef9679e4523168854@kirei.se> References: <061.a7190f1b2a09e76ef9679e4523168854@kirei.se> Message-ID: <070.4de1a32ccf8607f8a00360a0dd5751ca@kirei.se> #162: libhsm dependency reintroduced in r3586 breaks build -----------------------------------------------------------+---------------- Reporter: robert@? | Owner: rb Type: defect | Status: closed Priority: blocker | Component: Signer Version: trunk | Resolution: fixed Keywords: libhsm reintroduced build break jakob matthijs | -----------------------------------------------------------+---------------- Changes (by rb): * status: accepted => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jul 28 10:46:47 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 28 Jul 2010 10:46:47 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #143: ods-signer flush moves queue further away In-Reply-To: <056.51661cc4481924e8e4b59b58961cef26@kirei.se> References: <056.51661cc4481924e8e4b59b58961cef26@kirei.se> Message-ID: <065.c68cb203143076462c5080a7e32753a3@kirei.se> #143: ods-signer flush moves queue further away -------------------------------+-------------------------------------------- Reporter: dnssec@? | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: worksforme Keywords: | -------------------------------+-------------------------------------------- Changes (by rb): * status: accepted => closed * resolution: => worksforme -- Ticket URL: OpenDNSSEC OpenDNSSEC From robert at dk-hostmaster.dk Mon Jul 26 16:47:04 2010 From: robert at dk-hostmaster.dk (Robert Martin-Legene) Date: Mon, 26 Jul 2010 13:47:04 -0300 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #162: libhsm dependency reintroduced in r3586 breaks build In-Reply-To: <070.8706e563db831d9c33992dbe025cbc45@kirei.se> References: <061.a7190f1b2a09e76ef9679e4523168854@kirei.se> <070.8706e563db831d9c33992dbe025cbc45@kirei.se> Message-ID: <4C4DBC08.5030607@dk-hostmaster.dk> OpenDNSSEC wrote: > This was during the migration to the c based engine. The issue looks to be > solved in current trunk. > It was HEAD of trunk when I submitted the bug report yesterday. I don't know if you have fixed it over the last 24 hours. If you have, then maybe the problem is gone. From rick at goldmoney.com Tue Jul 27 14:20:48 2010 From: rick at goldmoney.com (Rick van Rein) Date: Tue, 27 Jul 2010 14:20:48 +0000 Subject: [Opendnssec-develop] Reloading zonelists into the signer engine In-Reply-To: <4C4ECFFB.3050504@nlnetlabs.nl> References: <20100727094820.GE721@phantom.vanrein.org> <20100727102945.GG721@phantom.vanrein.org> <4C4ECFFB.3050504@nlnetlabs.nl> Message-ID: <20100727142047.GB6298@phantom.vanrein.org> Hey Matthijs/Sion, > I think it would be more logical to invoke it after ods-signer update, > since the zone fetcher is controlled by the signer. Thanks -- and agreed. I was confusing the signer and zone_fetcher. (Just back from holiday, apparently some things have slipped.) As for getting this command from KASP Enforcer, I don't believe this is actually true. I cannot find references to the socket anywhere except in configfiles and makefiles. Experiments confirm that I currently need to "ods-control update" manually -- which is understandable with the registry target of 1.1 in mind. Thanks, -Rick