From rickard at opendnssec.org Mon Sep 5 09:12:49 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 5 Sep 2011 11:12:49 +0200 Subject: [Opendnssec-develop] Meeting 20110907 Message-ID: Hi We have a meeting on Wednesday. See the draft agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-09-07 Date: Wednesday 7 September Time: 14:00-15:00 CEST, 13:00-14:00 BST // Rickard From Roland.vanRijswijk at surfnet.nl Mon Sep 5 15:50:48 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Mon, 5 Sep 2011 17:50:48 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting 20110906 Message-ID: <35751418-F904-4923-A348-45D111D095D3@surfnet.nl> Hi all, We have an Enforcer NG meeting planned for tomorrow, September 6th 2011, at 14:00h CEST. Please use the following dial-in data: Dial-in to +31-30-2040323 Conference PIN: 030003 Draft agenda: * Action items * State of development * Testing * Integration with trunk * Alpha date Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From Roland.vanRijswijk at surfnet.nl Tue Sep 6 12:50:24 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 6 Sep 2011 14:50:24 +0200 Subject: [Opendnssec-develop] Meeting minutes for Enforcer NG meeting 20110906 Message-ID: <46715B0A-DD4F-417E-ADC8-D0A0BD2A5847@surfnet.nl> Hi guys, Here are the meeting minutes for today's Enforcer NG meeting, please correct any mistakes and add stuff you feel is missing: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-09-06 Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From rickard at opendnssec.org Wed Sep 7 08:41:19 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 7 Sep 2011 10:41:19 +0200 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: > I think we can proceed with the 1.3.1 without fixing #257 and #258. > There are some important updates that we need to get out. Bumping this thread. // Rickard From jakob at kirei.se Wed Sep 7 08:42:08 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 7 Sep 2011 10:42:08 +0200 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: On 7 sep 2011, at 10:41, Rickard Bellgrim wrote: >> I think we can proceed with the 1.3.1 without fixing #257 and #258. >> There are some important updates that we need to get out. > > Bumping this thread. Should we release today? j From rickard at opendnssec.org Wed Sep 7 08:43:34 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 7 Sep 2011 10:43:34 +0200 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: >>> I think we can proceed with the 1.3.1 without fixing #257 and #258. >>> There are some important updates that we need to get out. >> >> Bumping this thread. > > Should we release today? Yes, please. From matthijs at NLnetLabs.nl Wed Sep 7 08:55:41 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 07 Sep 2011 10:55:41 +0200 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: <4E67318D.7020007@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yesss On 09/07/2011 10:43 AM, Rickard Bellgrim wrote: >>>> I think we can proceed with the 1.3.1 without fixing #257 and #258. >>>> There are some important updates that we need to get out. >>> >>> Bumping this thread. >> >> Should we release today? > > Yes, please. > _______________________________________________ > 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOZzGNAAoJEA8yVCPsQCW58SMIAJRh/gJudLPO9/Ueuxr07VYs QnVlaHCDTnoHYUyJEfSZRBsDOrIsnb7koJTIiw8w+95M+2kEzoEBvXJV88OraA+T iXsM9kB1R6fBnzRIO+gAh3VS7UwKqd89FZJInQNSamtPdeZMzdv0Bisbf8x87w+4 hzzNyTdRpcMfxfW7e07ciMVWsPCC5Hf+FlD9QNQ7qQtOp4R801+lzND1zxZVQ1HE rv7MDf3edVXvp94KAUbvkB4sXilLIv9l2UUgtTAb+eU8nvkdcHN4i7rVz2Q73EMb iuj+UN6FQZ9dTkvEQsJlHjnZZT82EHirFuCj3MG7xjTVvZmIBeJcyIGQuibqY74= =4bMp -----END PGP SIGNATURE----- From jakob at kirei.se Wed Sep 7 09:40:14 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 7 Sep 2011 11:40:14 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: <0E368FD8-D251-4650-989C-0DA783503BF9@kirei.se> On 7 sep 2011, at 10:43, Rickard Bellgrim wrote: >> Should we release today? > > Yes, please. Because Rickard said the magic, I've just tagged 1.3.1 - http://svn.opendnssec.org/releases/OpenDNSSEC-1.3.1/. Tar-balls are being made. jakob From owner-dnssec-trac at kirei.se Wed Sep 7 12:37:16 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 07 Sep 2011 12:37:16 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> Message-ID: <072.d3343ef10fd59bd5aa2a7956e2c81976@kirei.se> #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.3.0 | Resolution: Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Comment (by matthijs): I think I understand what is going on: The backup files are corrupted because of a mismatch in backed up keys and the keys in the HSM. Therefore, the signer tries to clean up stuff. However, it tries to clean up the NSEC3PARAM RR twice. Committed a fix in the OpenDNSSEC-1.3 branch and trunk (r5588). -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 7 12:39:50 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 07 Sep 2011 12:39:50 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> Message-ID: <072.9ba59d6f695f0fad1648b11779f09551@kirei.se> #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: closed Priority: minor | Component: Signer Version: 1.3.0 | Resolution: fixed Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Wed Sep 7 12:41:48 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 7 Sep 2011 13:41:48 +0100 Subject: [Opendnssec-develop] Meeting 20110907 In-Reply-To: References: Message-ID: <4E67668C.3090502@nominet.org.uk> On 05/09/11 10:12, Rickard Bellgrim wrote: > Hi > > We have a meeting on Wednesday. See the draft agenda: > http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-09-07 > > Date: Wednesday 7 September > Time: 14:00-15:00 CEST, 13:00-14:00 BST > Minutes are up: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-09-07 please check that you have not been misquoted :) From jakob at kirei.se Wed Sep 7 13:40:53 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 7 Sep 2011 15:40:53 +0200 Subject: [Opendnssec-develop] Usage discrepancies Message-ID: <2F5CA50F-21CD-4368-AAE8-A8212F01CBD7@kirei.se> I see a small usage problem with "ods-ksmutil zone add --zone example.com" vs "ods-signer sign example.com" Would it be possible to make "--zone" optional? jakob From jakob at kirei.se Wed Sep 7 13:42:47 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 7 Sep 2011 15:42:47 +0200 Subject: [Opendnssec-develop] force key removal Message-ID: hi, Is there any way to force key removal? During the recent training we had students importing the wrong (or bad) key, which they then wanted to remove. jakob From jakob at kirei.se Wed Sep 7 13:44:50 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 7 Sep 2011 15:44:50 +0200 Subject: [Opendnssec-develop] Event-based triggers for the Enforcer Message-ID: <5AC9C429-6735-473A-8C0B-9BFB5678A431@kirei.se> The enforcer currently wakes up every now X minutes, but as it usually knows for sure when the next event will happen it is actually possible for it to schedule itself to wake up more often. Has anyone considered this? jakob From jakob at kirei.se Wed Sep 7 13:47:47 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 7 Sep 2011 15:47:47 +0200 Subject: [Opendnssec-develop] Key necromancy? Message-ID: During the training, the following events could be observed: - Add a new zone - Add keys (broken keys, so student changes his mind) - Remove zone to start over. Keys gone. - Add zone again - Import new keys (old keys gone, new set of keys looking good) ... wait a while ... - Old keys suddenly resurrected and associated with zone. oops? jakob -- Jakob Schlyter Kirei AB - http://www.kirei.se/ From sion at nominet.org.uk Wed Sep 7 13:52:19 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 7 Sep 2011 14:52:19 +0100 Subject: [Opendnssec-develop] Usage discrepancies In-Reply-To: <2F5CA50F-21CD-4368-AAE8-A8212F01CBD7@kirei.se> References: <2F5CA50F-21CD-4368-AAE8-A8212F01CBD7@kirei.se> Message-ID: <4E677713.20709@nominet.org.uk> On 07/09/11 14:40, Jakob Schlyter wrote: > I see a small usage problem with "ods-ksmutil zone add --zone example.com" vs "ods-signer sign example.com" > > Would it be possible to make "--zone" optional? > Or we could make it mandatory for the signer command? No? Okay... It is possible to have some implicit reading of command line arguments, e.g. "ods-ksmutil zone delete example.com" or "ods-ksmutil policy export default" Sion From jakob at kirei.se Wed Sep 7 13:53:38 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 7 Sep 2011 15:53:38 +0200 Subject: [Opendnssec-develop] Usage discrepancies In-Reply-To: <4E677713.20709@nominet.org.uk> References: <2F5CA50F-21CD-4368-AAE8-A8212F01CBD7@kirei.se> <4E677713.20709@nominet.org.uk> Message-ID: <26295CFA-D19F-4914-B0DC-D499D528BD17@kirei.se> On 7 sep 2011, at 15:52, Si?n Lloyd wrote: > Or we could make it mandatory for the signer command? No? Okay... Or optional for the signer command? I'm fine with that. That would give us: ods-signer sign --all ods-signer sign --zone example.com. jakob From sion at nominet.org.uk Wed Sep 7 13:54:42 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 7 Sep 2011 14:54:42 +0100 Subject: [Opendnssec-develop] force key removal In-Reply-To: References: Message-ID: <4E6777A2.2000004@nominet.org.uk> On 07/09/11 14:42, Jakob Schlyter wrote: > hi, > > Is there any way to force key removal? During the recent training we had students importing the wrong (or bad) key, which they then wanted to remove. The story exists for this: https://www.pivotaltracker.com/story/show/14648919 From nick.vandenheuvel at sidn.nl Wed Sep 7 13:56:53 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Wed, 7 Sep 2011 13:56:53 +0000 Subject: [Opendnssec-develop] Dropping connection to HSM - Heartbeat mechanism Message-ID: <60E0FAC48923D348BF7B1861488E606E08B8E870@kambx3.SIDN.local> Hi guys, As a reference to our meeting this afternoon, I did consult our operations department and they claim that we did not experience a dropping connection to the HSM after the incident last year. It would be hard (maybe even impossible) to reproduce this specific situation. For testing the heartbeat mechanism we can use other situations right? Regards, Nick Met vriendelijke groet, Nick van den Heuvel Test analist SIDN | Utrechtseweg 310 | 6802 EA | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 93 | F +31 (0)26 352 55 05 nick.vandenheuvel at sidn.nl | www.sidn.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roland.vanRijswijk at surfnet.nl Wed Sep 7 14:01:49 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 7 Sep 2011 16:01:49 +0200 Subject: [Opendnssec-develop] Event-based triggers for the Enforcer In-Reply-To: <5AC9C429-6735-473A-8C0B-9BFB5678A431@kirei.se> References: <5AC9C429-6735-473A-8C0B-9BFB5678A431@kirei.se> Message-ID: <25B1D34C-741F-47FC-9698-EE1FD5EEBD1D@surfnet.nl> Hi Jakob, On 7 sep 2011, at 15:44, Jakob Schlyter wrote: > The enforcer currently wakes up every now X minutes, but as it usually knows for sure when the next event will happen it is actually possible for it to schedule itself to wake up more often. Has anyone considered this? Yes, that is how the Enforcer NG is going to trigger itself (am not sure whether or not that will be implemented all the way yet in the alpha, I believe it partly hinges on database integration). 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 Sep 7 14:05:59 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 7 Sep 2011 15:05:59 +0100 Subject: [Opendnssec-develop] Event-based triggers for the Enforcer In-Reply-To: <5AC9C429-6735-473A-8C0B-9BFB5678A431@kirei.se> References: <5AC9C429-6735-473A-8C0B-9BFB5678A431@kirei.se> Message-ID: <4E677A47.4000601@nominet.org.uk> On 07/09/11 14:44, Jakob Schlyter wrote: > The enforcer currently wakes up every now X minutes, but as it usually knows for sure when the next event will happen it is actually possible for it to schedule itself to wake up more often. Has anyone considered this? > Alex and I discussed this at one point; but our feeling was that we use TIMESHIFT for testing and in live, so long as your settings are reasonable, it should run often enough. We could use the configured time as a maximum and be free to reduce it as we see fit. Sion From sion at nominet.org.uk Wed Sep 7 14:39:50 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 7 Sep 2011 15:39:50 +0100 Subject: [Opendnssec-develop] Key necromancy? In-Reply-To: References: Message-ID: <4E678236.5040509@nominet.org.uk> On 07/09/11 14:47, Jakob Schlyter wrote: > During the training, the following events could be observed: > > - Add a new zone > - Add keys (broken keys, so student changes his mind) > - Remove zone to start over. Keys gone. > - Add zone again > - Import new keys (old keys gone, new set of keys looking good) > > ... wait a while ... > > - Old keys suddenly resurrected and associated with zone. > > > oops? > Certainly seems like an oops. Is this all within the enforcer (we are not looking at old copies of signconf)? Currently we do not delete keys that are in the generate state, the theory being that they have never been published and so should be good for use with another zone. Is it these keys that are coming back? Sion From matthijs at NLnetLabs.nl Wed Sep 7 18:24:31 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 07 Sep 2011 20:24:31 +0200 Subject: [Opendnssec-develop] Usage discrepancies In-Reply-To: <26295CFA-D19F-4914-B0DC-D499D528BD17@kirei.se> References: <2F5CA50F-21CD-4368-AAE8-A8212F01CBD7@kirei.se> <4E677713.20709@nominet.org.uk> <26295CFA-D19F-4914-B0DC-D499D528BD17@kirei.se> Message-ID: <4E67B6DF.70400@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 so I can do both? ods-signer sign example.com. ods-signer sign --zone example.com. Best regards, Matthijs On 09/07/2011 03:53 PM, Jakob Schlyter wrote: > On 7 sep 2011, at 15:52, Si?n Lloyd wrote: > >> Or we could make it mandatory for the signer command? No? Okay... > > Or optional for the signer command? I'm fine with that. That would give us: > > ods-signer sign --all > ods-signer sign --zone example.com. > > > > 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOZ7bfAAoJEA8yVCPsQCW5QL4H/2Et6/o/vQGPH7hruX+sk+KB gcwUFzInvo6FRvu25MgeDd1G4RsGhxdNKcQyYmtvSSsKNEDFntZR0Pwtu/TwOMnt GvryonUpROh4awhqLOVbJslGHd208corYAAK41J7urNmP5HsEXPewdH8n6iCBJou CnZ2shJ17iZ17I9FFaitt6neTclH0vKvJOvwYZNM7GqcUcB9aGKTeg1CJstGrCmP 2vRuJl3KTn+hRigeBPT96I5YLEG9x9rKpGayTpaE963sTDc7tlK0ChxFIFcLdg7a mdZc5azZ0dPtLKKe6xcmx7vUrSWQ8mqx0MKgivuuLeBiSrUDfbQWr/mp6e+Es/o= =nb1c -----END PGP SIGNATURE----- From jakob at kirei.se Thu Sep 8 03:10:11 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 8 Sep 2011 05:10:11 +0200 Subject: [Opendnssec-develop] Usage discrepancies In-Reply-To: <4E67B6DF.70400@nlnetlabs.nl> References: <2F5CA50F-21CD-4368-AAE8-A8212F01CBD7@kirei.se> <4E677713.20709@nominet.org.uk> <26295CFA-D19F-4914-B0DC-D499D528BD17@kirei.se> <4E67B6DF.70400@nlnetlabs.nl> Message-ID: <1068D1DA-7904-42BA-A105-CD4E48DFFC3D@kirei.se> On 7 sep 2011, at 20:24, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > so I can do both? > > ods-signer sign example.com. > ods-signer sign --zone example.com. Sure. j From patrik.wallstrom at iis.se Thu Sep 8 06:59:23 2011 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Thu, 8 Sep 2011 08:59:23 +0200 Subject: [Opendnssec-develop] Usage discrepancies In-Reply-To: <4E677713.20709@nominet.org.uk> References: <2F5CA50F-21CD-4368-AAE8-A8212F01CBD7@kirei.se> <4E677713.20709@nominet.org.uk> Message-ID: <5045EC4C-E92A-4934-AFC0-C978C8DD76A9@iis.se> On Sep 7, 2011, at 3:52 PM, Si?n Lloyd wrote: > On 07/09/11 14:40, Jakob Schlyter wrote: >> I see a small usage problem with "ods-ksmutil zone add --zone example.com" vs "ods-signer sign example.com" >> >> Would it be possible to make "--zone" optional? >> > > Or we could make it mandatory for the signer command? No? Okay... > > It is possible to have some implicit reading of command line arguments, > e.g. > "ods-ksmutil zone delete example.com" > or > "ods-ksmutil policy export default" I think these kind of changes should be part of an overall oversight of all the commands. There are many discrepancies in there. -- 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 yuri at nlnetlabs.nl Thu Sep 8 09:50:45 2011 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Thu, 08 Sep 2011 11:50:45 +0200 Subject: [Opendnssec-develop] Event-based triggers for the Enforcer In-Reply-To: <25B1D34C-741F-47FC-9698-EE1FD5EEBD1D@surfnet.nl> References: <5AC9C429-6735-473A-8C0B-9BFB5678A431@kirei.se> <25B1D34C-741F-47FC-9698-EE1FD5EEBD1D@surfnet.nl> Message-ID: <1315475445.1706.8.camel@thorin> > Yes, that is how the Enforcer NG is going to trigger itself (am not > sure whether or not that will be implemented all the way yet in the > alpha, I believe it partly hinges on database integration). That is how the Enforcer NG currently functions. I believe the database backend has no influence on this behaviour (it might make it more efficient but I'm not sure). //yuri From matthijs at NLnetLabs.nl Thu Sep 8 10:31:30 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 08 Sep 2011 12:31:30 +0200 Subject: [Opendnssec-develop] DNS adapters configuration Message-ID: <4E689982.4090707@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, - From the notes: work has started on the DNS adapters (as opposed to file adapters). some ideas on configuration, but work needs to be done on zonefetcher to allow more flexibility. The idea is to completely deprecate the zone fetcher. In the future, people can use the DNS adapters. The zonefetch.xml currently does inbound zone transfer and can handle only one master for all zones. In order to provide more flexibility for per-zone configuration, I think the files should be split up. One file is needed when setting up the engine (which address do I listen to?), the other file lists the acl. The proposed files can be found here: branches/OpenDNSSEC-adapters/conf/addns.rnc branches/OpenDNSSEC-adapters/conf/addns.xml.in branches/OpenDNSSEC-adapters/conf/addnsconf.rnc branches/OpenDNSSEC-adapters/conf/addnsconf.xml.in In the conf.xml you have: addns.xml This tells the signer engine that there will be DNS adapters that need to be initialized. The configuration of the adapter is just a list of one of more interfaces that are listening to incoming notifies and zone transfer requests. start = element Adapter { # Type of adapter attribute type { xsd:string }, # where to listen for notifies and zone transfer requests element NotifyListen { localAddress }* } ipv4 = element IPv4 { xsd:string } ipv6 = element IPv6 { xsd:string } port = element Port { xsd:positiveInteger { maxInclusive = "65535" } } localAddress = (ipv4 | ipv6)?, port? In the zonelist.xml you can have something like: acl.xfr acl.xfr The acl.xfr file contains tsig, master and slave address and such. The syntax is as follows: start = element Adapter { # Type of adapter attribute type { xsd:string }, # inbound zone transfer settings element Inbound { # what TSIG secret to use tsig?, element RequestTransfer { remoteAddress }*, element AllowNotify { remoteAddress }*, }, # outbound zone transfer settings element Outbound { # what TSIG secret to use tsig?, element ProvideTransfer { remoteAddress }*, element Notify { remoteAddress }*, } I don't know if and how to fit in tunings for zone transfers like axfr only, udp only. Do we need to have that? If so, is that on a per zone basis or a per host basis? Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOaJmCAAoJEA8yVCPsQCW5OPAH/RV/vNnZac+ljjer0RH0UFO4 pBWWay/45pRwfCqevdfME4D5vmqdj8UzvlmNJ3Iv+nJb6JRUP7tvvljlaRHu3FQo M5/1XXYTKt5n7oOF/kaGWBGJectaAgnwdPQgdbhLVbKZ1NIg/ng/BSwgmQjnzQRm gg27VfMV+xX/lzABnPJP8pbMklFePZx4OtaSAM0giJjW33ipOHMCyG3TifVMQ2xn cuUF9ow0PjUgJhKmMhWK9a9yJ7Cu16kdT4AvRc64MYVOILRJyJ7kqIxZ8EAHkyzh jG2CxqxwdpbZQbovgd78ZfIWg+sFcjP6ahIffXkljDR+RL/Dk3vgZr280aTnKuw= =mnz4 -----END PGP SIGNATURE----- From sion at nominet.org.uk Thu Sep 8 12:32:37 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Thu, 8 Sep 2011 13:32:37 +0100 Subject: [Opendnssec-develop] Fisheye Message-ID: <4E68B5E5.6000101@nominet.org.uk> There was a question about git support yesterday... As if by magic the new version of fisheye, released yesterday, has git support. http://freshmeat.net/projects/fisheye Sion From patrik.wallstrom at iis.se Thu Sep 8 13:12:47 2011 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Thu, 8 Sep 2011 15:12:47 +0200 Subject: [Opendnssec-develop] Fisheye In-Reply-To: <4E68B5E5.6000101@nominet.org.uk> References: <4E68B5E5.6000101@nominet.org.uk> Message-ID: <9085AFD6-EE46-4D3F-9C2C-F37E06C3A1FD@iis.se> On Sep 8, 2011, at 2:32 PM, Si?n Lloyd wrote: > There was a question about git support yesterday... > > As if by magic the new version of fisheye, released yesterday, has git > support. > > http://freshmeat.net/projects/fisheye Good news. There are a number of features that I like about Git (besides being the distributed vcs it is), and that is the protected git history (by sha-1 hashes) so that you cannot manipulate commits by for example a repository breach. And you can also sign tags with PGP. http://book.git-scm.com/1_the_git_object_model.html http://learn.github.com/p/tagging.html Something that might matter also is that it is completely distributed, which means that the master repo is the place we call the master repo - not because there has to be one. All cloned git repos can be master repos. About code review, there is also a nice project called Gerrit: http://code.google.com/p/gerrit/ If we're going to put code review in place, I think we should think a little bit about the processes involved. Gerrit has a nice picture about how they see their default workflow: http://source.android.com/source/life-of-a-patch.html For SVN you also have Rietveld: http://code.google.com/p/rietveld/ Fisheye looks more to me like a source browser system than something used for code review. Please look at the Rietveld system that Chromium use (and look at something with lots of comments): http://codereview.chromium.org/ -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From sion at nominet.org.uk Thu Sep 8 13:35:17 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Thu, 8 Sep 2011 14:35:17 +0100 Subject: [Opendnssec-develop] Fisheye In-Reply-To: <9085AFD6-EE46-4D3F-9C2C-F37E06C3A1FD@iis.se> References: <4E68B5E5.6000101@nominet.org.uk> <9085AFD6-EE46-4D3F-9C2C-F37E06C3A1FD@iis.se> Message-ID: <4E68C495.3000502@nominet.org.uk> On 08/09/11 14:12, Patrik Wallstr?m wrote: > > Fisheye looks more to me like a source browser system than something used for code review. Please look at the Rietveld system that Chromium use (and look at something with lots of comments): > http://codereview.chromium.org/ > Just on this point. In the atlassian world fisheye is not intended for code review; that is the job of crucible. From jakob at kirei.se Fri Sep 9 07:01:46 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 9 Sep 2011 09:01:46 +0200 Subject: [Opendnssec-develop] Usage discrepancies In-Reply-To: <5045EC4C-E92A-4934-AFC0-C978C8DD76A9@iis.se> References: <2F5CA50F-21CD-4368-AAE8-A8212F01CBD7@kirei.se> <4E677713.20709@nominet.org.uk> <5045EC4C-E92A-4934-AFC0-C978C8DD76A9@iis.se> Message-ID: On 8 sep 2011, at 08:59, Patrik Wallstr?m wrote: > I think these kind of changes should be part of an overall oversight of all the commands. There are many discrepancies in there. Should we make this part of 1.4? I agree that it would be good to a pass at the CLI. j From owner-dnssec-trac at kirei.se Sat Sep 10 23:43:12 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sat, 10 Sep 2011 23:43:12 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #262: Looking For A Work? Job Board Software May Be The Answer Message-ID: <045.46105d3e5f6536fd0eddf6dcab878807@kirei.se> #262: Looking For A Work? Job Board Software May Be The Answer --------------------+------------------------------------------------------- Reporter: elpmaxe | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: WebScribble, Web Scribble, webscribble reviews --------------------+------------------------------------------------------- Once upon a time, searching for a work meant endless paper research, walking lower streets, tiresome and anxious interviews. This standard approach to work searching is extremely time intensive, drains types assets as well as very tedious. With the creation of technology, our way of life is different tremendously, such as work hunting. It???s known as online research. They are saying it is the best job research process. All you need to do would be to sign-up in your local or worldwide job board and get your job opening notifications. You can find employment providing in no time. This is true as well for personnel hunting. One most useful software program website is Job Board Software. There, you???ll discover all types of work available and all other data you'll need in addition to all available information about potential employees. With the development of this software, the initiatives, time and energy eaten for looking jobs and looking for possible candidates from a wide pool is becoming very simple as well as enjoyable. There is no longer a need to line up, initially to submit cv's, then, for selection interviews which could be boring and laborious for HR individuals. [http://www.webscribblereviews.com Webscribble reviews] do not lie, be informed! [http://www.webscribblereviews.com WebScribble] Job Board Software is basically an internet site that needs to put into action and perform multiple recruitment strategies. It's incorporated with assorted functions making it competent to execute the required functions in hiring. Miracle traffic bot is really a platform in which the open public can find all the required info associated with work or work posts. Job Board Software and be handled even by greenhorns. It is possible to install demands no technical training. It is allied with simple interface which may be sailed effortlessly. It's been built so it can be easily combined on the internet with the other existing web sites. There's two main kinds of queries provided within this software which are each extremely effective. These are Quick Look for job seekers out to consider a job and Sophisticated Research that is most ideal for experts seeking for particular projects. [http://www.webscribblereviews.com Web Scribble] Job Board Software strives is to maintain the user interface to the minimum level but simultaneously achieve the desired outcomes. It's regularly up-to-date make it possible for you to maintain the latest developments and improvements therefore ensuring they remain globally competitive. This similarly encourages users to get at it most often. This makes Job Board Software the most favored in the market. What this means is a better quantity of customers thus opening up largest and broadest swimming pool of human resource when it comes to recruitment and associated functions not only for could be workers and employers but the general open public too. With Job Board Software, the job from the Hr Division associated with a company has been made simple and easy , cheaper for everyone. No longer is there a need to search for custom-made software program when Job Board Software can be utilized by anybody anyplace anytime. It's no surprise employing Work Panel Software is the greatest strategy. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Sun Sep 11 18:30:45 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Sun, 11 Sep 2011 20:30:45 +0200 Subject: [Opendnssec-develop] Key necromancy? In-Reply-To: <4E678236.5040509@nominet.org.uk> References: <4E678236.5040509@nominet.org.uk> Message-ID: On 7 sep 2011, at 16:39, Si?n Lloyd wrote: > Is this all within the enforcer (we are not looking at old copies of signconf)? Correct. > Currently we do not delete keys that are in the generate state, the theory being that they have never been published and so should be good for use with another zone. Is it these keys that are coming back? Yes. j From rickard at opendnssec.org Mon Sep 12 08:52:54 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 12 Sep 2011 10:52:54 +0200 Subject: [Opendnssec-develop] The ds-* commands in Enforcer NG Message-ID: Hi I noticed that two new commands has been added to Enforcer NG, "key ds-retract" and "key ds-gone". Are those needed? For the purpose of DNSSEC, it does not matter if you have old DS RRs in the parent zone. As long as you have one valid DS. So we do not need to track the old DS RRs. It is implicit that the user remove the old DS RR, because its DNSKEY is not included in the "key export" or in the DSSubmitCommand. // Rickard From matthijs at NLnetLabs.nl Mon Sep 12 11:29:57 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 12 Sep 2011 13:29:57 +0200 Subject: [Opendnssec-develop] The ds-* commands in Enforcer NG In-Reply-To: References: Message-ID: <4E6DED35.60500@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/12/2011 10:52 AM, Rickard Bellgrim wrote: > Hi > > I noticed that two new commands has been added to Enforcer NG, "key > ds-retract" and "key ds-gone". Are those needed? For the purpose of > DNSSEC, it does not matter if you have old DS RRs in the parent zone. Unless it is an DS with a different algorithm (at least the debate is still ongoing). Best regards, Matthijs > As long as you have one valid DS. So we do not need to track the old > DS RRs. It is implicit that the user remove the old DS RR, because its > DNSKEY is not included in the "key export" or in the DSSubmitCommand. > > // Rickard > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJObe01AAoJEA8yVCPsQCW5WvAIAMOxufdLfm3onSXHALNTOknr 9j+ojPsjUdzUXPlAwggI1LVbq86oEPTRYreNyRtwnRfHgOUYMyomj4kkD/ZssEup gsfccxVQlse1FypVzn1BLQZ2jQKn1yad3+bYo2Sb04jjxBzvfLHFMYXx1xwUNBwH 8rdIZoTDqhz7hO7j2EAiHnJnLtO7gITf3evrFrdyRthaN5pTHM59Ri4zBfPtky1z +b6JUufiFYtXTSe2UqLo80453/9qOnrrJKPynurAgv/aP6Nn50wWi+jdJDyxd35Q sPdfREJeinEgAaB5C/05bBTna+JfuqJi5tSx2FaVo9a6mAF8Fl++VwvN2hqr2M4= =UwHD -----END PGP SIGNATURE----- From yuri at NLnetLabs.nl Mon Sep 12 11:39:47 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Mon, 12 Sep 2011 13:39:47 +0200 Subject: [Opendnssec-develop] The ds-* commands in Enforcer NG In-Reply-To: References: Message-ID: <4E6DEF83.90001@nlnetlabs.nl> > I noticed that two new commands has been added to Enforcer NG, "key > ds-retract" and "key ds-gone". Are those needed? For the purpose of > DNSSEC, it does not matter if you have old DS RRs in the parent zone. Having a DS RR in the parent zone for an algorithm not (any longer) available at the child is a configuration error. The enforcer must know the DS is really gone before proceeding to outroduce the DNSKEYs. > As long as you have one valid DS. So we do not need to track the old > DS RRs. It is implicit that the user remove the old DS RR, because its > DNSKEY is not included in the "key export" or in the DSSubmitCommand. I think you are proposing a UI change. key ds-submit must: - list keys that are to be submitted - list keys that are already submitted - list keys that are already seen - not list any other keys key ds-seen must: - mark the appropriate key as 'seen' - implicitly mark all keys waiting for retract as 'gone' Is this what you are implying? It seems rather unsafe to me. -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From yuri at NLnetLabs.nl Mon Sep 12 11:41:58 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Mon, 12 Sep 2011 13:41:58 +0200 Subject: [Opendnssec-develop] The ds-* commands in Enforcer NG In-Reply-To: <4E6DED35.60500@nlnetlabs.nl> References: <4E6DED35.60500@nlnetlabs.nl> Message-ID: <4E6DF006.4050802@nlnetlabs.nl> > Unless it is an DS with a different algorithm (at least the debate is > still ongoing). I believe the debate is ongoing in relation to validators. For authorities it seems very clear. -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From Roland.vanRijswijk at surfnet.nl Mon Sep 12 13:15:18 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Mon, 12 Sep 2011 15:15:18 +0200 Subject: [Opendnssec-develop] Enforcer NG minutes 20110912 Message-ID: <9AA4DE5F-66F4-40BC-B2AC-25AD0B415983@surfnet.nl> Hi all, The Enforcer NG telecon minutes for today's call are online: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-09-12 Bottom line: we are ready for an alpha release! Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From yuri at NLnetLabs.nl Mon Sep 12 14:07:37 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Mon, 12 Sep 2011 16:07:37 +0200 Subject: [Opendnssec-develop] Enforcer NG minutes 20110912 In-Reply-To: <9AA4DE5F-66F4-40BC-B2AC-25AD0B415983@surfnet.nl> References: <9AA4DE5F-66F4-40BC-B2AC-25AD0B415983@surfnet.nl> Message-ID: <4E6E1229.1080005@nlnetlabs.nl> > The Enforcer NG telecon minutes for today's call are online > We have a lot of discussion about new behaviour w.r.t. DS > submit/retract. We decide to keep the behaviour that Yuri and Ren? > implemented for the alpha even though this means an extra interaction > for the user during a KSK rollover (needs to be documented in the > README) I just had a good hart to hart talk with Matthijs about this. The bottom line is that the engine does support an atomic switch of the DS (I had trouble reasoning about and explaining it during the call). Also when doing a switch of DS RRs it does not matter at all if the ds-seen or ds-gone command is given first and the amount of time between them (For a moment I was afraid it would). But since the enforcer-ng supports an arbitrary amount of KSKs at any given time and keys are not coupled to rollovers, you would always have to specify which key is seen and which is gone. Thus leaving the following extra options: enforcer key ds-swap --zone example.com --seen 12345 --gone 98765 You specify exactly what keys, but it is not better than two commands or enforcer key ds-IDidEverythingAtTheParentYouAskedMeTo --zone example.com Applies all oustanding requests for zone. This leaves much room for error at the user. Giving the command but just do half of the tasks. How I see it, the rational behind having just one command is that the purpose is to have just one interaction with the parent, and having the user communicate twice with the enforcer defeats this purpose. But I don't think this is true. The number of user interactions is not related to the number of parent interactions but to the number of keys involved. Which I think is rather reasonable. So for now a seen and a gone command seem like the best way to go. Like said before lets keep it this way and see how the testers respond. //yuri -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From Roland.vanRijswijk at surfnet.nl Mon Sep 12 14:14:18 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Mon, 12 Sep 2011 16:14:18 +0200 Subject: [Opendnssec-develop] Enforcer NG minutes 20110912 In-Reply-To: <4E6E1229.1080005@nlnetlabs.nl> References: <9AA4DE5F-66F4-40BC-B2AC-25AD0B415983@surfnet.nl> <4E6E1229.1080005@nlnetlabs.nl> Message-ID: Hi Yuri, On 12 sep 2011, at 16:07, Yuri Schaeffer wrote: > [snip] > So for now a seen and a gone command seem like the best way to go. Like > said before lets keep it this way and see how the testers respond. Sounds well-thought-through and reasonable, so let's stick with that. Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From owner-dnssec-trac at kirei.se Tue Sep 13 07:58:46 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 13 Sep 2011 07:58:46 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.1183485a2a88b0023377eaf5dfc451dd@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Changes (by jerry): * owner: rb => jerry * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 13 07:59:02 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 13 Sep 2011 07:59:02 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #241: make dist in trunk fails In-Reply-To: <065.3ccbc0219f38890e28afbd0cb0ebf517@kirei.se> References: <065.3ccbc0219f38890e28afbd0cb0ebf517@kirei.se> Message-ID: <080.347a63b9a6bd52bf7547ab2d3b1bffe8@kirei.se> #241: make dist in trunk fails ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: trunk | Resolution: Keywords: | ------------------------------------------+--------------------------------- Changes (by jerry): * owner: rb => jerry * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Tue Sep 13 08:10:38 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 13 Sep 2011 10:10:38 +0200 Subject: [Opendnssec-develop] DNS adapters configuration In-Reply-To: <4E689982.4090707@nlnetlabs.nl> References: <4E689982.4090707@nlnetlabs.nl> Message-ID: <4E6F0FFE.6070109@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/08/2011 12:31 PM, Matthijs Mekking wrote: > Hi, > > From the notes: > > work has started on the DNS adapters (as opposed to file > adapters). some ideas on configuration, but work needs to be > done on zonefetcher to allow more flexibility. > > The idea is to completely deprecate the zone fetcher. In the future, > people can use the DNS adapters. The zonefetch.xml currently does > inbound zone transfer and can handle only one master for all zones. In > order to provide more flexibility for per-zone configuration, I think > the files should be split up. One file is needed when setting up the > engine (which address do I listen to?), the other file lists the acl. > > The proposed files can be found here: > > branches/OpenDNSSEC-adapters/conf/addns.rnc > branches/OpenDNSSEC-adapters/conf/addns.xml.in > branches/OpenDNSSEC-adapters/conf/addnsconf.rnc > branches/OpenDNSSEC-adapters/conf/addnsconf.xml.in > > In the conf.xml you have: > > > > addns.xml > > > > This tells the signer engine that there will be DNS adapters that need > to be initialized. The configuration of the adapter is just a list of > one of more interfaces that are listening to incoming notifies and zone > transfer requests. > > start = element Adapter { > # Type of adapter > attribute type { xsd:string }, > # where to listen for notifies and zone transfer requests > element NotifyListen { localAddress }* > } > > ipv4 = element IPv4 { xsd:string } > ipv6 = element IPv6 { xsd:string } > port = element Port { xsd:positiveInteger { maxInclusive = "65535" } } > > localAddress = (ipv4 | ipv6)?, port? When thinking about Dynamic Update Adapters, you would typically listen for update messages on the same interface as you would expect zone transfer requests and notifies. Perhaps we don't need Adapter configuration in conf.xml, and we can put a list of s directly in the block in conf.xml. Best regards, Matthijs > In the zonelist.xml you can have something like: > > > > acl.xfr > > > acl.xfr > > > > The acl.xfr file contains tsig, master and slave address and such. The > syntax is as follows: > > start = element Adapter { > # Type of adapter > attribute type { xsd:string }, > > # inbound zone transfer settings > element Inbound { > # what TSIG secret to use > tsig?, > element RequestTransfer { remoteAddress }*, > element AllowNotify { remoteAddress }*, > }, > > # outbound zone transfer settings > element Outbound { > # what TSIG secret to use > tsig?, > element ProvideTransfer { remoteAddress }*, > element Notify { remoteAddress }*, > } > > I don't know if and how to fit in tunings for zone transfers like axfr > only, udp only. Do we need to have that? If so, is that on a per zone > basis or a per host basis? > > Best regards, > Matthijs > > _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJObw/+AAoJEA8yVCPsQCW5r90H/jDTEMbze4psWPeAfyeaz/k8 pEf56aTH8m6Gp5YGuWXi/ffsBmSckXYnSmzUIPsIqkO/ojixO9iyZyO41vJASL3s rnpVhBAzlVXYytZBJna1tq/NPZ48nN8WdRhZSjoDLXFEfA8Le/LTUVrTW8pjnsp7 FmRpecI4r/xB68n7YQLs7nWl8k9HxmQb8l2dEkOH8VJ0LF3og57OiUHBZX7sZXVh W00xqKK9J4VXJQUocadi2XetCAYl9pG3mpQid7xgosxebnHJWiUz54MVnwp7ZrWF ETXzyG1SpKdZaGgvv1lg/pvZV5xmsAuOA77jP/uleuvdAQbUlLmU3MVH1W5EnOc= =DVrG -----END PGP SIGNATURE----- From rickard at opendnssec.org Tue Sep 13 08:34:52 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 13 Sep 2011 10:34:52 +0200 Subject: [Opendnssec-develop] DNS adapters configuration In-Reply-To: <4E689982.4090707@nlnetlabs.nl> References: <4E689982.4090707@nlnetlabs.nl> Message-ID: > I don't know if and how to fit in tunings for zone transfers like axfr > only, udp only. Do we need to have that? If so, is that on a per zone > basis or a per host basis? Perhaps an optional AxfrOnly element in both the inbound and outbound part of acl.xfr. On what level would you have UdpOnly? Do you need to know it in addns.xml? From owner-dnssec-trac at kirei.se Tue Sep 13 08:43:13 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 13 Sep 2011 08:43:13 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #261: Add a command to force a key from publish-state to ready-state In-Reply-To: <047.b037f9bb429da3778c489b0a012e1a66@kirei.se> References: <047.b037f9bb429da3778c489b0a012e1a66@kirei.se> Message-ID: <062.706401cf47de775b5734a2ddf26a270e@kirei.se> #261: Add a command to force a key from publish-state to ready-state ------------------------+--------------------------------------------------- Reporter: anonymous | Owner: sion Type: enhancement | Status: closed Priority: trivial | Component: Enforcer Version: trunk | Resolution: wontfix Keywords: | ------------------------+--------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => wontfix Comment: Will not fix. There should not be a command where you can force a change. This will break DNSSEC. If you want it to go faster, than change the timing parameters in the KASP in your lab environment. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard at opendnssec.org Tue Sep 13 08:48:52 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 13 Sep 2011 10:48:52 +0200 Subject: [Opendnssec-develop] Dropping connection to HSM - Heartbeat mechanism In-Reply-To: <60E0FAC48923D348BF7B1861488E606E08B8E870@kambx3.SIDN.local> References: <60E0FAC48923D348BF7B1861488E606E08B8E870@kambx3.SIDN.local> Message-ID: > As a reference to our meeting this afternoon, I did consult our operations > department and they claim that we did not experience a dropping connection > to the HSM after the incident last year. It would be hard (maybe even > impossible) to reproduce this specific situation. For testing the heartbeat > mechanism we can use other situations right? Ok, did they do any changes? E.g. applying the Enforcer patch or changing the network configuration? // Rickard From rickard at opendnssec.org Tue Sep 13 08:52:10 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 13 Sep 2011 10:52:10 +0200 Subject: [Opendnssec-develop] Usage discrepancies In-Reply-To: References: <2F5CA50F-21CD-4368-AAE8-A8212F01CBD7@kirei.se> <4E677713.20709@nominet.org.uk> <5045EC4C-E92A-4934-AFC0-C978C8DD76A9@iis.se> Message-ID: >> I think these kind of changes should be part of an overall oversight of all the commands. There are many discrepancies in there. > > Should we make this part of 1.4? I agree that it would be good to a pass at the CLI. I think it is something we can do once we have released the adapters and Enforcer NG. We have a story about a unified control program, where this can part of it. https://www.pivotaltracker.com/story/show/841390 // Rickard From matthijs at NLnetLabs.nl Tue Sep 13 08:58:21 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 13 Sep 2011 10:58:21 +0200 Subject: [Opendnssec-develop] DNS adapters configuration In-Reply-To: References: <4E689982.4090707@nlnetlabs.nl> Message-ID: <4E6F1B2D.7030300@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/13/2011 10:34 AM, Rickard Bellgrim wrote: >> I don't know if and how to fit in tunings for zone transfers like axfr >> only, udp only. Do we need to have that? If so, is that on a per zone >> basis or a per host basis? > > Perhaps an optional AxfrOnly element in both the inbound and outbound > part of acl.xfr. > > On what level would you have UdpOnly? Do you need to know it in addns.xml? Sorry, I should have said allow udp, to allow ixfr over udp instead of tcp. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJObxstAAoJEA8yVCPsQCW5B6gIAMvty+bMbDJkp9ylr0zRZsNw ZPmndOX338a+Ief1Dywm975jwNKY4ubBImb/lAjB5nBIZ8sT2dNYTgl3QZqNlk+Z Ekj59nxWtxcbrxsKdFtDjcAF7os1xswpGhGn/UQC+iWKVvD33rxwTWV/7kq/Kf9t idZ+h+SRV1j6ZKIWImyTLaQaulDz6JSjOiiUb8IQ2KPegOhKchyhpxYaQsGNUIGP eV8EV2qzGNIcFqRb9ICBJU314qsnxITCXw4ffzv/Sl8pziO68EkfvGOL9DxwY/OR Od4WklJO3vBhhl27gLkDOX0opiSF7/LLj9zzZJ5/1nCjeKT+RiNAZgoFUAODuYw= =IUY6 -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Tue Sep 13 12:01:00 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 13 Sep 2011 12:01:00 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #241: make dist in trunk fails In-Reply-To: <065.3ccbc0219f38890e28afbd0cb0ebf517@kirei.se> References: <065.3ccbc0219f38890e28afbd0cb0ebf517@kirei.se> Message-ID: <080.7b141b64884f7afd5c2ea3a586ecc877@kirei.se> #241: make dist in trunk fails ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: trunk | Resolution: Keywords: | ------------------------------------------+--------------------------------- Comment (by jerry): Hi, Can you verify that the trunk works now? Regards, Jerry Replying to [ticket:241 Ond?ej Sur? ]: > make[1]: Leaving directory `/root/OpenDNSSEC/auditor' > (cd plugins/eppclient && make top_distdir=../../opendnssec-1.4.0-trunk distdir=../../opendnssec-1.4.0-trunk/plugins/eppclient \ > am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir) > make[1]: Entering directory `/root/OpenDNSSEC/plugins/eppclient' > make[1]: *** No rule to make target `distdir'. Stop. > make[1]: Leaving directory `/root/OpenDNSSEC/plugins/eppclient' > make: *** [distdir] Error 1 > > > Removing plugin/eppclient from DIST_SUBDIRs list in the generated Makefile helps. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Tue Sep 13 21:27:37 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 13 Sep 2011 23:27:37 +0200 Subject: [Opendnssec-develop] make dist In-Reply-To: <4E369DB5.6030604@nlnetlabs.nl> References: <4E368D46.7080609@nlnetlabs.nl> <219FB6E4-71A8-433F-93C8-0A5C890BFD81@kirei.se> <4E369DB5.6030604@nlnetlabs.nl> Message-ID: <1B74B0B0-2A50-4C93-9F6F-E096F4F93A2B@kirei.se> On 1 aug 2011, at 14:36, Matthijs Mekking wrote: > auditor is enabled by default, but any case: adding --enable-auditor > does not help. > > For now, I will just remove the eppclient from the subdirs This should have been fixed by Jerry now. jakob From owner-dnssec-trac at kirei.se Wed Sep 14 07:18:02 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Sep 2011 07:18:02 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.30e83c0dcd3d79d0b0744db7c4265ff9@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Comment (by jerry): Hi Nick, Are you still having these problems? If so, what versions of OpenDNSSEC and SoftHSM are you running now? Regards, Jerry Replying to [ticket:245 Nick van den Heuvel]: > Last week I had the problem (with ODS 1.3.0rc2), that after the signing of a large zone (> 4M domeinnames) de signer daemon keeps running. The memory usage remains the same as during the signing. Closing the signer daemon down by using "ods-control stop" was not succesful: The message "Stopping Enforcer"stayed on the screen in the terminal. > > Yesterday I tried to reproduce it with succes. Voor the signing I did use the .nl zone from March 2011, in which 50 % DS has been added. I have signed the zone on my werkstation (Ubuntu 10.04 64 bit, 8 Gb ram, Intel core 2 duo @ 3,33 GHZ, ODS 1.3.0rc2). The memory usage was 100 % (8Gb + 6,6 Swap memory (which is slow, but soit). > > In the attacment, you see the syslog. The behaveour of ODS seem not right. I would expect that after ODS signs the zone, de signer daemon is stopped by the enforcer and the memory usage will lower to the usage before signing. > -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 14 11:34:50 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Sep 2011 11:34:50 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.2f07c6605c879153878fc95e77a5cc36@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Comment (by nick.vandenheuvel@?): Hi Jerry, The same problem still occurs though I can close the enforcer with this version. The memory is not cleaned. Tested it today with ODS 1.3.0 with SoftHSM 1.3.0 Regards, Nick -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 14 11:37:05 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Sep 2011 11:37:05 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.af95793f3707db25d8714e7540f5ee95@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Comment (by nick.vandenheuvel@?): Extra information: The signer daemon (ods-signerd) is not closed when I close the enforcer, with the command ods-control stop. Logging: root at elmo-desktop:/var/opendnssec/signed# ods-control stop Stopping enforcer... Stopping signer engine.. Engine shut down. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 14 11:54:21 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Sep 2011 11:54:21 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.01b435f5066f11a8b193e9e70f51fd1e@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Comment (by jerry): Hi Nick, How many zones do you have now? Can you cut&paste /proc//status ? Regards, Jerry -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 14 12:16:00 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Sep 2011 12:16:00 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.728c10b2d86dc0721f419b25aef8e1a3@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Comment (by nick.vandenheuvel@?): 1 large zone, I see that the signerd closes 20 minutes after the ods- control stop command has been executed. Memory is now empty again. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 14 12:18:00 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Sep 2011 12:18:00 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.03089efdfe15436186a5913a3d090131@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Comment (by jerry): Hi Nick, How many entries do you have in that zone? Where you able to cut&paste the status file? Regards, Jerry -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 14 12:24:37 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Sep 2011 12:24:37 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.3dbc0bad4ebcaa2ac26426eed04a2cfc@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Comment (by matthijs): I probably just have to do exit(0) instead of cleaning up memory when doing a ods-signer stop -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 14 12:38:13 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 14 Sep 2011 12:38:13 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.31f8b6c355938eaeaa1311e37a5eb070@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Comment (by jerry): If the memory usage is 100% (of physical memory and swap) it explains why it takes 20 minutes to exit since it would need to swap in all the memory to free it. Exit(0) might work but it would be nice to confirm if in fact its a problem with too much swap usage and then maybe look at how we can handle millions of entries without having large amount of memory. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard at opendnssec.org Wed Sep 14 16:18:08 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 14 Sep 2011 18:18:08 +0200 Subject: [Opendnssec-develop] Enforcer NG Message-ID: Hi It is now ready for an alpha release. Only have some comments that we might save for later: - I would like to have the --keytype mandatory for the "key rollover". It is a change of behavior, but it is so easy to do something wrong here. - "key list" says that the DS is rumoured, "key export" exports the key, but "ds-submit" does not say anything. // Rickard From rene at xpt.nl Thu Sep 15 07:16:44 2011 From: rene at xpt.nl (=?iso-8859-1?Q?Ren=E9_Post?=) Date: Thu, 15 Sep 2011 09:16:44 +0200 Subject: [Opendnssec-develop] Enforcer NG In-Reply-To: References: Message-ID: On Sep 14, 2011, at 6:18 PM, Rickard Bellgrim wrote: > Hi > > It is now ready for an alpha release. Only have some comments that we > might save for later: > > - I would like to have the --keytype mandatory for the "key rollover". > It is a change of behavior, but it is so easy to do something wrong > here. This means that rolling all keys is not possible anymore with a single command. Assuming that is not a problem, I'll change it. > - "key list" says that the DS is rumoured, "key export" exports the > key, but "ds-submit" does not say anything. The key is probably already in submitted state. If you configured a DelegationSignerSubmitCommand then this program was started as the key transitioned from uncommited to submit. If the program was started successfully then the key will make the transition to submitted and no longer shows up when you perform a 'key ds-submit' it will however show up when you do a 'key ds-seen' as that command shows the keys that are in 'submitted' state waiting to be marked as 'seen'. When you perform a 'key export' the state has to be either submit or submitted (or retract / retracted). I allow the re-export of a submitted key to handle the situation where a key "got lost in transit" on its way to the parent. Whenever a key is exported and is still in submit state, the key will then also transition to submitted state. Calling 'key ds-submit' will only show the keys that are in submit state and have never been submtited to the parent either via 'key export' or automatically via the DelegationSignerSubmitCommand. //Ren? From rickard at opendnssec.org Thu Sep 15 07:24:16 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 15 Sep 2011 09:24:16 +0200 Subject: [Opendnssec-develop] Enforcer NG In-Reply-To: References: Message-ID: >> - "key list" says that the DS is rumoured, "key export" exports the >> key, but "ds-submit" does not say anything. > > The key is probably already in submitted state. If you configured > a DelegationSignerSubmitCommand then this program was > started as the key transitioned from uncommited to submit. > If the program ?was started successfully then the key will make > the transition to submitted and no longer shows up when you > perform a 'key ds-submit' it will however show up when you do a > 'key ds-seen' as that command shows the keys that are in 'submitted' > state waiting to be marked as 'seen'. > > When you perform a 'key export' the state has to be either submit > or submitted (or retract / retracted). I allow the re-export of a submitted key to > handle the situation where a key "got lost in transit" on its way to the parent. > Whenever a key is exported and is still in submit state, the key will then also > transition to submitted state. Calling 'key ds-submit' will only show the keys > that are in submit state and have never been submtited to the parent either > via 'key export' or automatically via the DelegationSignerSubmitCommand. Ok, I had the DelegationSignerSubmitCommand configured. From sion at nominet.org.uk Thu Sep 15 13:22:40 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Thu, 15 Sep 2011 14:22:40 +0100 Subject: [Opendnssec-develop] Enforcer NG In-Reply-To: References: Message-ID: <4E71FC20.1080307@nominet.org.uk> On 15/09/11 08:16, Ren? Post wrote: > On Sep 14, 2011, at 6:18 PM, Rickard Bellgrim wrote: > >> Hi >> >> It is now ready for an alpha release. Only have some comments that we >> might save for later: >> >> - I would like to have the --keytype mandatory for the "key rollover". >> It is a change of behavior, but it is so easy to do something wrong >> here. > > This means that rolling all keys is not possible anymore with a single command. > Assuming that is not a problem, I'll change it. > Unless you allow "--keytype ALL" or similar? From matthijs at NLnetLabs.nl Thu Sep 15 13:57:25 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 15 Sep 2011 15:57:25 +0200 Subject: [Opendnssec-develop] DNS adapters configuration In-Reply-To: <4E689982.4090707@nlnetlabs.nl> References: <4E689982.4090707@nlnetlabs.nl> Message-ID: <4E720445.6090006@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/08/2011 12:31 PM, Matthijs Mekking wrote: ... > > The acl.xfr file contains tsig, master and slave address and such. The > syntax is as follows: > > start = element Adapter { > # Type of adapter > attribute type { xsd:string }, > > # inbound zone transfer settings > element Inbound { > # what TSIG secret to use > tsig?, > element RequestTransfer { remoteAddress }*, > element AllowNotify { remoteAddress }*, > }, > > # outbound zone transfer settings > element Outbound { > # what TSIG secret to use > tsig?, > element ProvideTransfer { remoteAddress }*, > element Notify { remoteAddress }*, > } > This is not entirely correct, tsig should be on a per server base, not per zone base: More something like: element Inbound { element RequestTransfer { remoteAddress, tsig? }*, element AllowNotify { remoteAddress, tsig? }*, }, or element Inbound { # zero or more TSIG secrets tsig*, element RequestTransfer { remoteAddress, tsig_id? }*, element AllowNotify { remoteAddress, tsig_id? }*, }, -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOcgRFAAoJEA8yVCPsQCW57J0IALPhq2PYPkANq85XYwGxgbZU 12i77JJn04Li1w1CI5XAxsi+DLxUPeiB1AKKyUrghk8Pgv3pDjjcdCluaPL/KYTS BrdfC5XHAZN4iqmJs0MYd+kkPc8xy3w815b+2OsRpKpWHBtXtrgR+rdA5ZSuRRPH 82mRcau0OVWkGnnXX/lsLJrZYz9TaBEoCOSI3UZeRxy6Ucbd/yZmwiubto5AYOEO 9pHdbheBw4qQHnaP0xrbhOpj3v9YWeJm/HrF/H/1TX2DigBKV5wBj0CpZAl3EXFB VujxnMtfLCItY+YfQglkD/khZYBtYi9rGm9TWK0D9bHmQ4kbkbYa/ng04tQKB9E= =9X62 -----END PGP SIGNATURE----- From rickard at opendnssec.org Thu Sep 15 19:45:03 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 15 Sep 2011 21:45:03 +0200 Subject: [Opendnssec-develop] DNS adapters configuration In-Reply-To: <4E720445.6090006@nlnetlabs.nl> References: <4E689982.4090707@nlnetlabs.nl> <4E720445.6090006@nlnetlabs.nl> Message-ID: > This is not entirely correct, tsig should be on a per server base, not > per zone base: You can have one tsig per zone, but perhaps it is recommended to have one tsig per server? // Rickard From matthijs at NLnetLabs.nl Fri Sep 16 07:51:29 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 16 Sep 2011 09:51:29 +0200 Subject: [Opendnssec-develop] DNS adapters configuration In-Reply-To: References: <4E689982.4090707@nlnetlabs.nl> <4E720445.6090006@nlnetlabs.nl> Message-ID: <4E730001.1040700@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/15/2011 09:45 PM, Rickard Bellgrim wrote: >> This is not entirely correct, tsig should be on a per server base, not >> per zone base: > > You can have one tsig per zone, but perhaps it is recommended to have > one tsig per server? > > // Rickard It should be possible to set it up per zone per server, I think. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOcwABAAoJEA8yVCPsQCW5B0wH+wRQ+h2P6NyBURcZFfT/Sofy FLmhAdemK1KoJn3UZ7do2yXDxbdsQrnBup9MZxPg3DigIewYu18qrwARYEai8x3s CKEpHg2A7ZkpaXj/vtQSvM9h9VDRoWh/Ampk2vHpDuJSHnMA7UEc52VW1KwVhhTh 4HOlTsx5Ud3D1Fq/UYS3HIhVkZHeFQH7bMEhzSwHKG5gtfzEeuCZ57/5Ml22S37s ASsoMH9cNO3mwsYu8rUOtj/kui4mlJceCq9wQ7jPZal3IOSxjb18N06ALLmKxY+x 31e6bAmXPnb5ViXKuXtsXKttR0hSCFgJidRkH5nOColZDhBxuuZ0n3T5041dcAw= =ur+V -----END PGP SIGNATURE----- From rickard at opendnssec.org Fri Sep 16 08:00:10 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 16 Sep 2011 10:00:10 +0200 Subject: [Opendnssec-develop] DNS adapters configuration In-Reply-To: <4E730001.1040700@nlnetlabs.nl> References: <4E689982.4090707@nlnetlabs.nl> <4E720445.6090006@nlnetlabs.nl> <4E730001.1040700@nlnetlabs.nl> Message-ID: >>> This is not entirely correct, tsig should be on a per server base, not >>> per zone base: >> >> You can have one tsig per zone, but perhaps it is recommended to have >> one tsig per server? > > It should be possible to set it up per zone per server, I think. Ohh, wait. BIND uses it per server-server-pair. You connect the IP with the corresponding TSIG key. // Rickard From sion at nominet.org.uk Fri Sep 16 08:12:10 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Fri, 16 Sep 2011 09:12:10 +0100 Subject: [Opendnssec-develop] DNS adapters configuration In-Reply-To: References: <4E689982.4090707@nlnetlabs.nl> <4E720445.6090006@nlnetlabs.nl> <4E730001.1040700@nlnetlabs.nl> Message-ID: <4E7304DA.3030206@nominet.org.uk> On 16/09/11 09:00, Rickard Bellgrim wrote: >>>> This is not entirely correct, tsig should be on a per server base, not >>>> per zone base: >>> You can have one tsig per zone, but perhaps it is recommended to have >>> one tsig per server? >> It should be possible to set it up per zone per server, I think. > Ohh, wait. BIND uses it per server-server-pair. You connect the IP > with the corresponding TSIG key. > With BIND you can do some tsig stuff per zone also, but maybe not notifies?... So long as we are flexible, then it is possible to configure it either way. Sion From rickard at opendnssec.org Fri Sep 16 12:54:58 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 16 Sep 2011 14:54:58 +0200 Subject: [Opendnssec-develop] Re: Enforcer NG In-Reply-To: References: Message-ID: > It is now ready for an alpha release. Only have some comments that we > might save for later: My comments has been handled by the team, so I think we can go ahead with the release. // Rickard From owner-dnssec-trac at kirei.se Sun Sep 18 06:51:44 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 18 Sep 2011 06:51:44 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #262: Easy methods to find work Message-ID: <055.a184fd964d0e8b43182aea1049a1fa79@kirei.se> #262: Easy methods to find work ------------------------------+--------------------------------------------- Reporter: job site software | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: job board software, job site software, job recruitment software, job portal software ------------------------------+--------------------------------------------- Are you running for an Work Company? Are you still using traditional procedure, to operate an employment company? Yes? Then you may have been tired all the methods, when it comes to money and time. The present company situation, many of us are called to fast and inexpensive techniques, not just to use assets as you want, but additionally serve an extra work to complete inside a powerful company atmosphere. Almost everyone has the custom, that these types of software program tools are difficult to apply and the organization needs [http://www.gutin.com /h1b-lawyer/webjobs job recruitment software] to do the job. Certain cases, of they need to discover newest techniques or technologies. Requirement for Pace and Web technologies, is mainly in the basis of innovation in business employment. Globalization has played a huge role in its modification and improvement, that company require [http://www.gutin.com/h1b-lawyer/webjobs job board software] candidates from around the world. Applicants will also be looking for worldwide options, and also various options or places to choose from. Employment programs have been created particularly to meet the requirements and requirements from the administration physiques of companies. It stores info for every Resume posted or job seekers on its data source and the company may filter or draw out the results every time she or he needs at the click a control button. No need to do a lot of documents and by hand select the right candidates. Some [http://www.gutin.com/h1b-lawyer/webjobs job recruitment software] also includes a computerized e-sending function using, which you can match, people looking for work who are able to meet the particular criteria with the information. The colleges likewise helps them supplying work data base to obtain the correct candidates -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 19 11:33:30 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 19 Sep 2011 11:33:30 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.4630b4f7d5289d34d3c8ea895c39434c@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Comment (by nick.vandenheuvel@?): Replying to [comment:9 jerry]: > Hi Nick, > > How many entries do you have in that zone? > > Where you able to cut&paste the status file? > > Regards, > Jerry About 10M domeinnames with 1-2 nameservers and 5 % DS. A pretty big zonefile which I created for performance tests. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 19 11:53:57 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 19 Sep 2011 11:53:57 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.758fec31e6fd36ad326693d03ce16e6e@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Comment (by nick.vandenheuvel@?): Replying to [comment:9 jerry]: > Hi Nick, > > How many entries do you have in that zone? > > Where you able to cut&paste the status file? > > Regards, > Jerry Do you mean the state file? I attached this one to this reply. Regards, Nick -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 19 14:30:55 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 19 Sep 2011 14:30:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #245: Signer daemon keeps running after signing large zone In-Reply-To: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> References: <057.244b9729c92229f8efa63e7da9e5ba6b@kirei.se> Message-ID: <072.c49e236f505701f4fe0a6ce98c2c7abc@kirei.se> #245: Signer daemon keeps running after signing large zone --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: jerry Type: defect | Status: closed Priority: major | Component: Unknown Version: 1.3.0 | Resolution: worksforme Keywords: 1.3.0rc2 | --------------------------------+------------------------------------------- Changes (by jerry): * status: assigned => closed * resolution: => worksforme Comment: Hi Nick, Replying to [comment:12 nick.vandenheuvel@?]: > About 10M domeinnames with 1-2 nameservers and 5 % DS. A pretty big zonefile which I created for performance tests. Since you are running 10M entries you will need more physical memory then 8gig to run smoothly otherwise you will start using the swap and that will make your system slow. Try 16gig or 24gig if you can. This has to do with, just as Richard wrote, that all entries are kept in memory even after its done signing and the signer daemon does not exist. I'm closing this ticket since it isn't really a problem however it might be good to discuss how we can make this work on the mailing list. Regards, Jerry -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 19 14:32:10 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 19 Sep 2011 14:32:10 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #241: make dist in trunk fails In-Reply-To: <065.3ccbc0219f38890e28afbd0cb0ebf517@kirei.se> References: <065.3ccbc0219f38890e28afbd0cb0ebf517@kirei.se> Message-ID: <080.981304e6da4396c4eeb4f6c2ae0e48af@kirei.se> #241: make dist in trunk fails ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jerry Type: defect | Status: assigned Priority: major | Component: Unknown Version: trunk | Resolution: Keywords: | ------------------------------------------+--------------------------------- Comment (by jerry): Hi Ondrej, Have you been able to verify the trunk? Regards, Jerry -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 19 14:34:57 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 19 Sep 2011 14:34:57 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #185: SoftHSM under Cygwin In-Reply-To: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> References: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> Message-ID: <070.80270e5c46825724f393d4e398e051b1@kirei.se> #185: SoftHSM under Cygwin ------------------------------+--------------------------------------------- Reporter: smokimk@? | Owner: rb Type: defect | Status: accepted Priority: major | Component: SoftHSM Version: trunk | Resolution: Keywords: | ------------------------------+--------------------------------------------- Comment (by jerry): Hi Smokimk, Replying to [comment:5 rb]: > You should get DLL files now, if you try the version in trunk. It works with MinGW. Have you been able to try the trunk version to see if you get the DLL files now? Regards, Jerry -- Ticket URL: OpenDNSSEC OpenDNSSEC From yuri at NLnetLabs.nl Tue Sep 20 08:20:08 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Tue, 20 Sep 2011 10:20:08 +0200 Subject: [Opendnssec-develop] Building Enforcer-ng on Solaris Message-ID: <4E784CB8.1030805@nlnetlabs.nl> Hi all, Unfortunately we haven't been able to build the Enforcer-ng branch on Solaris yet. As far as we can tell it is because of the mixing of C and C++, this gives us problems in case of LDNS. In file included from /d/home/yuri/ldns/include/ldns/ldns.h:95, from ./scheduler/task.h:40, from ./daemon/worker.h:37, from ./daemon/engine.h:40, from ./policy/update_kasp_cmd.h:4, from policy/update_kasp_cmd.cpp:6: /d/home/yuri/ldns/include/ldns/util.h:210: error: `_Bool' has not been declared /d/home/yuri/ldns/include/ldns/util.h:210: error: ISO C++ forbids declaration of `value' with no type (note that line numbers may be different in your copy) Use of bool in mixed code is problematic. Therefore ldns' common.h includes the following. It defines _Bool for C++. #ifdef HAVE_STDBOOL_H # include #else # ifndef HAVE__BOOL # ifdef __cplusplus typedef bool _Bool; # else # define _Bool signed char # endif # endif # define bool _Bool # define false 0 # define true 1 # define __bool_true_false_are_defined 1 #endif BUT, HAVE_STDBOOL_H and HAVE__BOOL are defined. Configure checked this, but of course only for C and not for C++. The first one is correct, C++ has (a rather empty) stdbool.h, the second isn't in our case. A solution is to insert in the above snippet between the 2nd and 3th line: # ifndef _Bool # define _Bool signed char # endif It seems rather harmless for other projects using ldns. But I don't think it is acceptable modify ldns. However it is the only thing that worked so far (then, ODS still wont compile but I haven't got to that part yet). Any ideas are welcome, or anyone willing to give it a try, I'm afraid I do not have anymore configure-fu left... //Yuri -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From jerry at opendnssec.org Tue Sep 20 09:12:46 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Tue, 20 Sep 2011 11:12:46 +0200 Subject: [Opendnssec-develop] Building Enforcer-ng on Solaris In-Reply-To: <4E784CB8.1030805@nlnetlabs.nl> Message-ID: On 2011-09-20 10.20, Yuri Schaeffer wrote: >In file included from /d/home/yuri/ldns/include/ldns/ldns.h:95, > from ./scheduler/task.h:40, > from ./daemon/worker.h:37, > from ./daemon/engine.h:40, > from ./policy/update_kasp_cmd.h:4, > from policy/update_kasp_cmd.cpp:6: >/d/home/yuri/ldns/include/ldns/util.h:210: error: `_Bool' has not been >declared >/d/home/yuri/ldns/include/ldns/util.h:210: error: ISO C++ forbids >declaration of `value' with no type Strange, can you send the config.log file? /Jerry From yuri at NLnetLabs.nl Tue Sep 20 09:39:57 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Tue, 20 Sep 2011 11:39:57 +0200 Subject: [Opendnssec-develop] Building Enforcer-ng on Solaris In-Reply-To: References: Message-ID: <4E785F6D.5010900@nlnetlabs.nl> > Strange, can you send the config.log file? Mailed off-list -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From rick at openfortress.nl Wed Sep 21 08:06:33 2011 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 21 Sep 2011 08:06:33 +0000 Subject: [Opendnssec-develop] Transient HSM problem handling Message-ID: <20110921080633.GB950@phantom.vanrein.org> Hello all, I am researching a problem with our HSMs in high-availability (replicated) mode, as we are seeing split-brain problems when it generates keys on one HSM but does not always pass them over to the other. The same may also happen with the other writing operation, namely key removal. The underlying problem may be caused by the PKCS #11 networking code or the network itself. I wonder what OpenDNSSEC does when it runs into such transient problems? It appears that the signer recovers itself (although it will complain if it fails to find keys, of course) and that the enforcer crashes (when it gets CKR_DEVICE_ERROR). Aside from the observed behaviour; what is the intended behaviour? Would it be correct to state that transient errors mean waiting a bit longer and trying again later? Has this actually been considered as a design consideration? It is definately hairy, as delayed HSMs could lead to zones running out of signatures, so I can imagine that not making explicit choices design causes various kinds of behaviour inside OpenDNSSEC. I will put this on the agenda for today's meeting, but wanted to document the problems a bit before. Cheers, -Rick From rickard at opendnssec.org Wed Sep 21 08:14:44 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 21 Sep 2011 10:14:44 +0200 Subject: [Opendnssec-develop] Meeting today Message-ID: Hi We have a telephone meeting today. You can find the agenda here: http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-09-21 // Rickard From rickard at opendnssec.org Wed Sep 21 08:29:50 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 21 Sep 2011 10:29:50 +0200 Subject: [Opendnssec-develop] Transient HSM problem handling In-Reply-To: <20110921080633.GB950@phantom.vanrein.org> References: <20110921080633.GB950@phantom.vanrein.org> Message-ID: > I am researching a problem with our HSMs in high-availability > (replicated) mode, as we are seeing split-brain problems when > it generates keys on one HSM but does not always pass them over > to the other. ?The same may also happen with the other writing > operation, namely key removal. ?The underlying problem may be > caused by the PKCS #11 networking code or the network itself. We had an issue this weekend where the HSMs were not in sync. Both HSMs were still available in the cluster. It was fixed by doing a manual synchronization, but it would be good if this was done automatically. Then again, we did not have this option set (if that would fix it???): sudo ./vtl haAdmin -autoRecovery -retry 250 I have also enable logging for the HA-mode to get more info if it happens again. > I wonder what OpenDNSSEC does when it runs into such transient > problems? ?It appears that the signer recovers itself (although > it will complain if it fails to find keys, of course) and that > the enforcer crashes (when it gets CKR_DEVICE_ERROR). The only "problem" is that you get a lot of "[hsm] unable to get key: key 2f6aced76ef88a49a902ccaccf11cbfa not found" in syslog. Yes, the Enforcer should have more checks, so that it does not crash. > Aside from the observed behaviour; what is the intended behaviour? > Would it be correct to state that transient errors mean waiting > a bit longer and trying again later? ?Has this actually been > considered as a design consideration? ?It is definately hairy, as > delayed HSMs could lead to zones running out of signatures, so > I can imagine that not making explicit choices design causes > various kinds of behaviour inside OpenDNSSEC. The intended behaviour is to back off and try again later. // Rickard From rick at openfortress.nl Wed Sep 21 10:11:31 2011 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 21 Sep 2011 10:11:31 +0000 Subject: [Opendnssec-develop] Transient HSM problem handling In-Reply-To: References: <20110921080633.GB950@phantom.vanrein.org> Message-ID: <20110921101131.GB30991@phantom.vanrein.org> Hi Rickard, > Then again, we did not have this option set (if that > would fix it???): > > sudo ./vtl haAdmin -autoRecovery -retry 250 This would fix the one-sided *creation* of keys, but if deletion would occur only on one node, this would copy the key back again. This is not a desirable solution, certainly not on LUNA 4 with its limited #licenses. The real problem appears to be somewhere in the network handling, as we mostly see it arise for the long-distance connection between a signer in one location and the HSM in the other. Cheers, -Rick From yuri at nlnetlabs.nl Wed Sep 21 10:28:39 2011 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Wed, 21 Sep 2011 12:28:39 +0200 Subject: [Opendnssec-develop] Building Enforcer-ng on Solaris In-Reply-To: References: Message-ID: <1316600919.2060.5.camel@thorin> I'm happy to announce that it compiles perfectly on sunOS now. All credits for Jerry, whom put considerable effort in it and tackled the problem effectively. So, shall we try again to have an alpha release now? Jakob? //yuri From rick at openfortress.nl Wed Sep 21 12:52:56 2011 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 21 Sep 2011 12:52:56 +0000 Subject: [Opendnssec-develop] Minutes 2011-09-21 Message-ID: <20110921125256.GB9724@phantom.vanrein.org> Hello, The meeting notes are online, http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-09-21 Let me know if anything needs changing -- or help yourself to it. Cheers, -Rick From sion at nominet.org.uk Wed Sep 21 15:15:15 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 21 Sep 2011 16:15:15 +0100 Subject: [Opendnssec-develop] Transient HSM problem handling In-Reply-To: <20110921080633.GB950@phantom.vanrein.org> References: <20110921080633.GB950@phantom.vanrein.org> Message-ID: <4E79FF83.3080802@nominet.org.uk> On 21/09/11 09:06, Rick van Rein wrote: > Aside from the observed behaviour; what is the intended behaviour? > Would it be correct to state that transient errors mean waiting > a bit longer and trying again later? Has this actually been > considered as a design consideration? It is definately hairy, as > delayed HSMs could lead to zones running out of signatures, so > I can imagine that not making explicit choices design causes > various kinds of behaviour inside OpenDNSSEC. I've ported the enforcer code into the 1.3 branch (r5651). Just to recap; this code checks the context when the enforcer wakes up. If it finds it is not valid it tries to reconnect, if this reconnect fails then the enforcer will quit. Sion From jakob at kirei.se Thu Sep 22 06:25:07 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 22 Sep 2011 08:25:07 +0200 Subject: [Opendnssec-develop] Building Enforcer-ng on Solaris In-Reply-To: <1316600919.2060.5.camel@thorin> References: <1316600919.2060.5.camel@thorin> Message-ID: <0B539405-8542-4D70-A204-BAE9C8754499@kirei.se> On 21 sep 2011, at 12:28, Yuri Schaeffer wrote: > I'm happy to announce that it compiles perfectly on sunOS now. All > credits for Jerry, whom put considerable effort in it and tackled the > problem effectively. Wheehee! > So, shall we try again to have an alpha release now? Jakob? Sure, what name should it have? opendnssec-enforcer-ng-snap-20110922 ? (as I'm not yet fully clear if it will make it into 1.4, I propose a date instead of a version) jakob From Roland.vanRijswijk at surfnet.nl Thu Sep 22 06:27:21 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 22 Sep 2011 08:27:21 +0200 Subject: [Opendnssec-develop] Building Enforcer-ng on Solaris In-Reply-To: <0B539405-8542-4D70-A204-BAE9C8754499@kirei.se> References: <1316600919.2060.5.camel@thorin> <0B539405-8542-4D70-A204-BAE9C8754499@kirei.se> Message-ID: Hi! On 22 sep 2011, at 08:25, Jakob Schlyter wrote: > On 21 sep 2011, at 12:28, Yuri Schaeffer wrote: > >> I'm happy to announce that it compiles perfectly on sunOS now. All >> credits for Jerry, whom put considerable effort in it and tackled the >> problem effectively. > > Wheehee! > >> So, shall we try again to have an alpha release now? Jakob? > > Sure, what name should it have? opendnssec-enforcer-ng-snap-20110922 ? (as I'm not yet fully clear if it will make it into 1.4, I propose a date instead of a version) That sounds prudent to me :-) +1 Cheers, ROland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From owner-dnssec-trac at kirei.se Thu Sep 22 08:44:32 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 22 Sep 2011 08:44:32 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #241: make dist in trunk fails In-Reply-To: <065.3ccbc0219f38890e28afbd0cb0ebf517@kirei.se> References: <065.3ccbc0219f38890e28afbd0cb0ebf517@kirei.se> Message-ID: <080.1f10c632882d30010bc10cac303ca97e@kirei.se> #241: make dist in trunk fails ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jerry Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by jerry): * status: assigned => closed * resolution: => fixed Comment: Closing this ticket since there is no reply and we now have a prepdist.sh that should be used to make the dist and its been tested. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Sep 22 08:48:15 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 22 Sep 2011 08:48:15 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #184: Zone fetcher should have back off and retry behaviour In-Reply-To: <044.a602faca92afd2cd4acce3713748395c@kirei.se> References: <044.a602faca92afd2cd4acce3713748395c@kirei.se> Message-ID: <059.2623e28e26051e668ea89eb60a22443d@kirei.se> #184: Zone fetcher should have back off and retry behaviour --------------------------------------+------------------------------------- Reporter: roland | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: 1.1.1 | Resolution: Keywords: Zone fetcher AXFR failure | --------------------------------------+------------------------------------- Comment (by jerry): Hi Roland, Is this still relevant to version 1.3? Regards, Jerry Replying to [ticket:184 roland]: > This ticket is linked to ticket #183 > > We have noticed that AXFRs sometimes fail half-way through. The fix in ticket #183 ensures that this is now failsafe, i.e. that this doesn't result in a half zone getting signed and served out. > > The problem of the failed AXFRs remains, however. This problem is intermittent and somewhat hard to predict when it occurs (although it occurs often enough to be reproducible, just not under exact circumstances). In my opinion, the zone fetcher should be able to handle failed AXFRs and should back off and retry later. Because it doesn't do this currently, it will only respond to the next NOTIFY which may again result in a failed AXFR. So I would strongly advocate including a back off and retry mechanism in the zone fetcher (or in the equivalent module that is going to serve this function in 1.2). > > Apart from that, the current zone fetcher also doesn't support refresh (it doesn't request an AXFR if the SOA refresh of the zone expires). This is probably also a good idea. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Sep 22 08:59:52 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 22 Sep 2011 08:59:52 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #184: Zone fetcher should have back off and retry behaviour In-Reply-To: <044.a602faca92afd2cd4acce3713748395c@kirei.se> References: <044.a602faca92afd2cd4acce3713748395c@kirei.se> Message-ID: <059.5314c0f51c924fa05c530ca9a4689b39@kirei.se> #184: Zone fetcher should have back off and retry behaviour --------------------------------------+------------------------------------- Reporter: roland | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: 1.1.1 | Resolution: Keywords: Zone fetcher AXFR failure | --------------------------------------+------------------------------------- Comment (by roland): Hi Jerry, This turned out to be a combination of a bug in the zone fetcher and a bug in LDNS. The bug in LDNS has been fixed, I'm not sure whether the fix I submitted for the zone fetcher has been included in trunk by Matthijs, I guess you should ask him ;-) Cheers, Roland -- Ticket URL: OpenDNSSEC OpenDNSSEC From jerry at opendnssec.org Thu Sep 22 09:04:32 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Thu, 22 Sep 2011 11:04:32 +0200 Subject: [Opendnssec-develop] Ticket #197: ods-ksmutil key available Message-ID: Hi all, Is this still something we want to implement: Replying to [ticket:197 Sebastian Castro ]: > While working on a PoC code to display the list of keys available (in GENERATE state) for a zone, I found a double-free issue. > > The case was produced when a query to the KASP returned no rows. In the attached code, within the ListAvailableKeys function, if no rows are returned there is no call to DbString(row, 0, &key_id), meaning no mem allocation for key_id. Later on, you try to free that memory using DbStringFree. The glibc on Debian complains about this. I'm not completely sure about the right approach for fixing this. /Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard at opendnssec.org Thu Sep 22 09:08:42 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 22 Sep 2011 11:08:42 +0200 Subject: [Opendnssec-develop] Building Enforcer-ng on Solaris In-Reply-To: <0B539405-8542-4D70-A204-BAE9C8754499@kirei.se> References: <1316600919.2060.5.camel@thorin> <0B539405-8542-4D70-A204-BAE9C8754499@kirei.se> Message-ID: > Sure, what name should it have? opendnssec-enforcer-ng-snap-20110922 ? (as I'm not yet fully clear if it will make it into 1.4, I propose a date instead of a version) +1 (Just to clarify Enforcer NG == 1.5) From rickard at opendnssec.org Thu Sep 22 09:32:31 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 22 Sep 2011 11:32:31 +0200 Subject: [Opendnssec-develop] Ticket #197: ods-ksmutil key available In-Reply-To: References: Message-ID: > Is this still something we want to implement: That will be included in the key pool functionality for Enforcer NG. // Rickard From owner-dnssec-trac at kirei.se Thu Sep 22 11:59:04 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 22 Sep 2011 11:59:04 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #184: Zone fetcher should have back off and retry behaviour In-Reply-To: <044.a602faca92afd2cd4acce3713748395c@kirei.se> References: <044.a602faca92afd2cd4acce3713748395c@kirei.se> Message-ID: <059.d47ba0c0201f9da2b513d367e3a00534@kirei.se> #184: Zone fetcher should have back off and retry behaviour --------------------------------------+------------------------------------- Reporter: roland | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: 1.1.1 | Resolution: fixed Keywords: Zone fetcher AXFR failure | --------------------------------------+------------------------------------- Changes (by jerry): * status: new => closed * resolution: => fixed Comment: Hi, The new adapters that is coming for 1.4/1.5 will support back off/retry/refresh so I am closing this ticket. Regards, Jerry -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Thu Sep 22 13:50:56 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 22 Sep 2011 15:50:56 +0200 Subject: [Opendnssec-develop] Building Enforcer-ng on Solaris In-Reply-To: References: <1316600919.2060.5.camel@thorin> <0B539405-8542-4D70-A204-BAE9C8754499@kirei.se> Message-ID: <2F3EDBF9-D7DF-4CC2-8CC1-5F0156F90339@kirei.se> http://svn.opendnssec.org/tags/OpenDNSSEC-enforcer-ng-20110922 ready and tweeted. No tarballs this time, people have to check out and test from SVN. jakob From owner-dnssec-trac at kirei.se Mon Sep 26 07:25:17 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Sep 2011 07:25:17 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #184: Zone fetcher should have back off and retry behaviour In-Reply-To: <044.a602faca92afd2cd4acce3713748395c@kirei.se> References: <044.a602faca92afd2cd4acce3713748395c@kirei.se> Message-ID: <059.38ad78f34732117364d9e39cd85754e1@kirei.se> #184: Zone fetcher should have back off and retry behaviour --------------------------------------+------------------------------------- Reporter: roland | Owner: matthijs Type: defect | Status: reopened Priority: major | Component: Signer Version: 1.1.1 | Resolution: Keywords: Zone fetcher AXFR failure | --------------------------------------+------------------------------------- Changes (by rb): * status: closed => reopened * resolution: fixed => Comment: We have not released 1.4 or 1.5, so the issue can thus not be fixed yet. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 26 07:42:28 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Sep 2011 07:42:28 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #184: Zone fetcher should have back off and retry behaviour In-Reply-To: <044.a602faca92afd2cd4acce3713748395c@kirei.se> References: <044.a602faca92afd2cd4acce3713748395c@kirei.se> Message-ID: <059.71ecb734497d1df95e63a6e5e0eb2c5a@kirei.se> #184: Zone fetcher should have back off and retry behaviour --------------------------------------+------------------------------------- Reporter: roland | Owner: matthijs Type: defect | Status: assigned Priority: major | Component: Signer Version: 1.1.1 | Resolution: Keywords: Zone fetcher AXFR failure | --------------------------------------+------------------------------------- Changes (by rb): * status: reopened => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From Roland.vanRijswijk at surfnet.nl Mon Sep 26 10:02:26 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Mon, 26 Sep 2011 12:02:26 +0200 Subject: [Opendnssec-develop] Enforcer NG telecon tomorrow at 13:00h CEST (with request to reschedule to 12:30h CEST!) Message-ID: Hi guys, We have an Enforcer NG telecon scheduled for tomorrow to discuss the state of the alpha release and hopefully also discuss some feedback (even if only from within the team). Here are the conference details: Dial-in to +31-30-2040323 Conference PIN: 030003 NOTE: I would also like to ask you guys if we can reschedule the conference to half and hour earlier, at 12:30h CEST, can you let me know if that is OK with you? If not, we'll need to keep it a little bit shorter as I have to leave at around 13:40h (and when I leave the conference room it "closes" ;-) ) Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From yuri at NLnetLabs.nl Mon Sep 26 10:13:19 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Mon, 26 Sep 2011 12:13:19 +0200 Subject: [Opendnssec-develop] Enforcer NG telecon tomorrow at 13:00h CEST (with request to reschedule to 12:30h CEST!) In-Reply-To: References: Message-ID: <4E80503F.1020506@nlnetlabs.nl> > NOTE: I would also like to ask you guys if we can reschedule the > conference to half and hour earlier, at 12:30h CEST No problem for me. //yuri From nick.vandenheuvel at sidn.nl Mon Sep 26 10:33:01 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Mon, 26 Sep 2011 10:33:01 +0000 Subject: [Opendnssec-develop] Enforcer NG telecon tomorrow at 13:00h CEST (with request to reschedule to 12:30h CEST!) In-Reply-To: References: Message-ID: <8379DE00FDBE1B4F95522D088EC260DD023C6D@kambx1.SIDN.local> No problem for me! -----Original Message----- From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Roland van Rijswijk Sent: maandag 26 september 2011 12:02 To: opendnssec-develop at lists.opendnssec.org Subject: [Opendnssec-develop] Enforcer NG telecon tomorrow at 13:00h CEST (with request to reschedule to 12:30h CEST!) Hi guys, We have an Enforcer NG telecon scheduled for tomorrow to discuss the state of the alpha release and hopefully also discuss some feedback (even if only from within the team). Here are the conference details: Dial-in to +31-30-2040323 Conference PIN: 030003 NOTE: I would also like to ask you guys if we can reschedule the conference to half and hour earlier, at 12:30h CEST, can you let me know if that is OK with you? If not, we'll need to keep it a little bit shorter as I have to leave at around 13:40h (and when I leave the conference room it "closes" ;-) ) Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From rickard at opendnssec.org Mon Sep 26 11:36:21 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 26 Sep 2011 13:36:21 +0200 Subject: [Opendnssec-develop] Enforcer NG telecon tomorrow at 13:00h CEST (with request to reschedule to 12:30h CEST!) In-Reply-To: <8379DE00FDBE1B4F95522D088EC260DD023C6D@kambx1.SIDN.local> References: <8379DE00FDBE1B4F95522D088EC260DD023C6D@kambx1.SIDN.local> Message-ID: > NOTE: I would also like to ask you guys if we can reschedule the conference to half and hour earlier, at 12:30h CEST, can you let me know if that is OK with you? If not, we'll need to keep it a little bit shorter as I have to leave at around 13:40h (and when I leave the conference room it "closes" ;-) ) I will not be able to attend tomorrow, but you can go ahead without me. // Rickard From owner-dnssec-trac at kirei.se Mon Sep 26 12:46:17 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Sep 2011 12:46:17 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? Message-ID: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> #262: Possible race condition causing CPU-bound loop in signerd? -------------------------------+-------------------------------------------- Reporter: goeran@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: 1.3.0 | Keywords: CPU-bound loop -------------------------------+-------------------------------------------- I've a problem with ODS 1.3.2 (or rather the 1.3-branch, as of rev. 5653, but I've seen it for all 1.3-versions) running on a RHE 5.7 system. The ods-signerd now and then (every second week or so) becomes stuck in a CPU loop. Most of the threads use CPU. It looks as if the problem is related to a mutex lock (futex, to be more specific).. (The pthread_cond_timedwait call in ods_thread_wait in signer/src/shared/locks.c). While stuck in the loop, it also keeps a lock on the kasp database. I've some other processes (backups of the key database for example) that wait for the same database lock. If it is a race condition when accessing the kasp database or if it is something internal to ods-signerd is unclear. It may even be a RHE Linux bug. It looks as if futex locks have had some problems in earlier Linux versions (and programming using them is tricky in any version). I attach some gdb- and other output from the process and its threads. I planned to leave ODS in the "loop" state to allow further info collection but after some strace commands, the hang was resolved. However, the next sign got stuck in a waitpid-call and the only way to resolve that was to stop (ods-control stop and kill of some processes). Maybe some internal state got confused by the long time in a CPU-bound loop. Known problem? Linux problem? Some resource problem? Other? / G?ran Bengtson Chalmers Univ. of Technology -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 26 12:58:15 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Sep 2011 12:58:15 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> Message-ID: <071.e5c01cc9210f42121a85c13cdfadfe0b@kirei.se> #262: Possible race condition causing CPU-bound loop in signerd? -------------------------------+-------------------------------------------- Reporter: goeran@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: 1.3.0 | Resolution: Keywords: CPU-bound loop | -------------------------------+-------------------------------------------- Comment (by rb): The ods-signerd never talks to the KASP database. But ods-enforcerd have a lock on it. And it could be that it is being blocked while calling e.g. "ods-signer update ". So the blocking of the KASP database is an side effect of the blocking in ods-signerd. The question is why it is deadlocking. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 26 13:29:42 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 26 Sep 2011 13:29:42 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> Message-ID: <071.53a8c26f4717d5c26014c8b5d0b2630e@kirei.se> #262: Possible race condition causing CPU-bound loop in signerd? -------------------------------+-------------------------------------------- Reporter: goeran@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: 1.3.0 | Resolution: Keywords: CPU-bound loop | -------------------------------+-------------------------------------------- Comment (by jerry): Hi G?ran, When was the gdb taken, before or after strace? Regards, Jerry -- Ticket URL: OpenDNSSEC OpenDNSSEC From Roland.vanRijswijk at surfnet.nl Mon Sep 26 14:38:16 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Mon, 26 Sep 2011 16:38:16 +0200 Subject: [Opendnssec-develop] Enforcer NG telecon tomorrow at 13:00h CEST (with request to reschedule to 12:30h CEST!) In-Reply-To: References: Message-ID: OK, given the responses I'm rescheduling for 12:30h CEST tomorrow, thanks everyone! On 26 sep 2011, at 12:02, Roland van Rijswijk wrote: > Hi guys, > > We have an Enforcer NG telecon scheduled for tomorrow to discuss the state of the alpha release and hopefully also discuss some feedback (even if only from within the team). Here are the conference details: > > Dial-in to +31-30-2040323 > > Conference PIN: 030003 > > NOTE: I would also like to ask you guys if we can reschedule the conference to half and hour earlier, at 12:30h CEST, can you let me know if that is OK with you? If not, we'll need to keep it a little bit shorter as I have to leave at around 13:40h (and when I leave the conference room it "closes" ;-) ) > > Cheers, > > Roland > > -- Roland M. van Rijswijk > -- SURFnet Middleware Services > -- t: +31-30-2305388 > -- e: roland.vanrijswijk at surfnet.nl > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From owner-dnssec-trac at kirei.se Tue Sep 27 08:01:50 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 27 Sep 2011 08:01:50 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> Message-ID: <071.95e6f7d3790ab20828dc8a58b19ab27d@kirei.se> #262: Possible race condition causing CPU-bound loop in signerd? -------------------------------+-------------------------------------------- Reporter: goeran@? | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: 1.3.0 | Resolution: Keywords: CPU-bound loop | -------------------------------+-------------------------------------------- Changes (by matthijs): * status: new => accepted Comment: Hi, To get more insight of why the signer gets stuck, I would like to know: - how many worker threads and signer threads you have configured? - how many zones you have configured? - what is the maximum size of the zones? - the kasp.xml If you prefer, you can send me this information off list. -- Ticket URL: OpenDNSSEC OpenDNSSEC From yuri at NLnetLabs.nl Tue Sep 27 08:16:46 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Tue, 27 Sep 2011 10:16:46 +0200 Subject: [Opendnssec-develop] Enforcer engine design v2 work breakdown In-Reply-To: <4DF0CC76.50005@nlnetlabs.nl> References: <4DF0CC76.50005@nlnetlabs.nl> Message-ID: <4E81866E.7050500@nlnetlabs.nl> >> - Figure out how the user indicates which rollover strategy it wants in >> the kasp.xml (input request for all of you). This issue was postponed until after the Alpha. We never made a good decision on this, so I'd like to discuss this further. I see 2 options: - [A] Specify per key - [B] Specify per policy [A] Specify per key This is like Matthijs' proposal. A drawback is that each type of key KSK|ZSK|CSK has its own set of values, with different meaning. What I do like however is that the names from the literature [1] can be used. In this option we must come up with a name for a CSK rollover that combines ZSK:PrePublication and KSK:DoubleRRset, which seems to be omitted in referred document. Thus we need 4 or 5 names which denote something else depending on the key it is mentioned in. [B] Specify per policy There are 5 possible rollovers. If we specify per policy we need to come up with 5 new names. On the bright side, their meaning is always consistent. For reference I made a table. It translates the 'minimize'-flags the enforcer internally uses to names in the key-timing-bis document. DS DNSKEY RRSIG | KSK [1] | ZSK [1] | CSK [1] | -----------------+-----------+-----------+-----------+ 0 0 0 | Dbl RRset | Dbl Sig | Dbl RRset | 0 0 1 | Dbl RRset | Pre Pub | ??? | 0 1 0 | Dbl DS | Dbl RRSig | Dbl DS | 0 1 1 | N/A | N/A | N/A | 1 0 0 | Dbl Sig | Dbl Sig | Dbl Sig | 1 0 1 | Dbl Sig | Pre Pub | Pre Pub | 1 1 0 | N/A | N/A | N/A | 1 1 1 | N/A | N/A | N/A | Three of the combinations can not be used (on a single key) as they cause a deadlock. E.g. the 7th row requires the DNSKEY to propagate before the DS is introduced AND it requires the DS to propagate before the DNSKEY is introduced. As far as I can see there can not be a conflict between 2 keys. (the dangerous case would be a split key algorithm rollover, but I think that will work in any case) //yuri [1] draft-mekking-dnsop-dnssec-key-timing-bis-00 From roland.vanrijswijk at surfnet.nl Tue Sep 27 11:06:14 2011 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 27 Sep 2011 13:06:14 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting minutes 20110927 Message-ID: Hi guys, Here are the meeting minutes for today's call: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-09-27 For those not able to attend, please note that the next meeting has been planned for October 27th at 14:00h CEST. Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jerry at opendnssec.org Thu Sep 29 07:45:25 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Thu, 29 Sep 2011 09:45:25 +0200 Subject: [Opendnssec-develop] Locking mechanism problems Message-ID: Hi, I got this assertion error from Patrik Wallstr?m yesterday and been looking into it some: ods-signerd: ../../../signer/src/daemon/cmdhandler.c:322: cmdhandler_handle_cmd_sign: assertion zone->task failed >From what I can see the problem is that zonelist_update() may leave zone objects with a zone->task set to NULL before engine_update_zones() can assign a task to them. This can happen inside cmdhandler_handle_cmd_update() because it releases the lock on the zonelist before running engine_update_zones(): 1. cmdhandler_handle_cmd_update : lock zonelist 2. cmdhandler_handle_cmd_update : zonelist_update() 3. cmdhandler_handle_cmd_update : unlock zonelist 4. cmdhandler_handle_cmd_update : engine_update_zones() 5. engine_update_zones : lock zonelist 6. engine_update_zones : update zones 7. engine_update_zones : unlock zonelist Some other thread might try and lock the zonelist at step 2 and then it would get that lock before engine_update_zones() can do its part. A quick fix to this is to make engine_update_zones() aware of the lock on zonelist so it doesn't try and lock it and release it after, suggested patch below. Altho I am seeing this almost everywhere and I would like to discuss our approach. I would really like to see read and write locks implemented to better support thread interoperability. Using pthread_mutex_trylock()/pthread_mutex_timedlock() where it suites to counter hangs. Using PTHREAD_MUTEX_RECURSIVE so different segments can lock the same locked object without letting each other know providing better OO. Of course as complexity in the locking mechanism increases so is the chance of dead locks. Why this hasn't turned up more might be that each zone is handled by one thread, only time two threads might be working on the same zone is if you do manually commands, and that the locking right now is very loose. Thoughts? /Jerry Index: signer/src/daemon/cmdhandler.c =================================================================== --- signer/src/daemon/cmdhandler.c (revision 5654) +++ signer/src/daemon/cmdhandler.c (working copy) @@ -190,11 +190,11 @@ cmdc->engine->zonelist->just_removed = 0; cmdc->engine->zonelist->just_added = 0; cmdc->engine->zonelist->just_updated = 0; - lock_basic_unlock(&cmdc->engine->zonelist->zl_lock); ods_log_debug("[%s] commit zone list changes", cmdh_str); - engine_update_zones(cmdc->engine); + engine_update_zones(cmdc->engine, 1); ods_log_debug("[%s] signer configurations updated", cmdh_str); + lock_basic_unlock(&cmdc->engine->zonelist->zl_lock); } else { lock_basic_unlock(&cmdc->engine->zonelist->zl_lock); (void)snprintf(buf, ODS_SE_MAXLINE, "Zone list has errors.\n"); Index: signer/src/daemon/engine.c =================================================================== --- signer/src/daemon/engine.c (revision 5654) +++ signer/src/daemon/engine.c (working copy) @@ -811,7 +811,7 @@ * */ void -engine_update_zones(engine_type* engine) +engine_update_zones(engine_type* engine, int zonelist_is_locked) { ldns_rbnode_t* node = LDNS_RBTREE_NULL; zone_type* zone = NULL; @@ -833,8 +833,10 @@ now = time_now(); reload_zonefetcher(engine); - lock_basic_lock(&engine->zonelist->zl_lock); - /* [LOCK] zonelist */ + if (!zonelist_is_locked) { + lock_basic_lock(&engine->zonelist->zl_lock); + /* [LOCK] zonelist */ + } node = ldns_rbtree_first(engine->zonelist->zones); while (node && node != LDNS_RBTREE_NULL) { zone = (zone_type*) node->data; @@ -929,8 +931,10 @@ } node = ldns_rbtree_next(node); } - /* [UNLOCK] zonelist */ - lock_basic_unlock(&engine->zonelist->zl_lock); + if (!zonelist_is_locked) { + /* [UNLOCK] zonelist */ + lock_basic_unlock(&engine->zonelist->zl_lock); + } if (wake_up) { engine_wakeup_workers(engine); } @@ -1097,7 +1101,7 @@ /* update zones */ if (zl_changed == ODS_STATUS_OK) { ods_log_debug("[%s] commit zone list changes", engine_str); - engine_update_zones(engine); + engine_update_zones(engine, 0); ods_log_debug("[%s] signer configurations updated", engine_str); zl_changed = ODS_STATUS_UNCHANGED; } Index: signer/src/daemon/engine.h =================================================================== --- signer/src/daemon/engine.h (revision 5654) +++ signer/src/daemon/engine.h (working copy) @@ -101,7 +101,7 @@ * \param[in] engine engine * */ -void engine_update_zones(engine_type* engine); +void engine_update_zones(engine_type* engine, int zonelist_is_locked); /** * Clean up engine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard at opendnssec.org Thu Sep 29 07:49:24 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 29 Sep 2011 09:49:24 +0200 Subject: [Opendnssec-develop] Locking mechanism problems In-Reply-To: References: Message-ID: > Thoughts? +1 // Rickard From matthijs at NLnetLabs.nl Thu Sep 29 08:00:34 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 29 Sep 2011 10:00:34 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-otr] Locking mechanism problems In-Reply-To: References: Message-ID: <4E8425A2.6090805@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/28/2011 04:59 PM, Jerry Lundstr?m wrote: > Hi, > > I got this assertion error from Patrik Wallstr?m yesterday and been > looking into it some: > > ods-signerd: ../../../signer/src/daemon/cmdhandler.c:322: > cmdhandler_handle_cmd_sign: assertion zone->task failed > > From what I can see the problem is that zonelist_update() may leave zone > objects with a zone->task set to NULL before engine_update_zones() can > assign a task to them. This can happen inside > cmdhandler_handle_cmd_update() because it releases the lock on the > zonelist before running engine_update_zones(): > > 1. cmdhandler_handle_cmd_update : lock zonelist > 2. cmdhandler_handle_cmd_update : zonelist_update() > 3. cmdhandler_handle_cmd_update : unlock zonelist > 4. cmdhandler_handle_cmd_update : engine_update_zones() > 5. engine_update_zones : lock zonelist > 6. engine_update_zones : update zones > 7. engine_update_zones : unlock zonelist > > Some other thread might try and lock the zonelist at step 2 and then it > would get that lock before engine_update_zones() can do its part. I have tried to encounter this by checking zone->just_added. cmdhandler.c:307: if (zone && zone->just_added) { cmdhandler.c:308: zone = NULL; cmdhandler.c:309: } But apparently there is another way to fail the assertion. > A quick fix to this is to make engine_update_zones() aware of the lock > on zonelist so it doesn't try and lock it and release it after, > suggested patch below. > > Altho I am seeing this almost everywhere and I would like to discuss our > approach. I would really like to see read and write locks implemented to > better support thread interoperability. Using > pthread_mutex_trylock()/pthread_mutex_timedlock() where it suites to > counter hangs. Using PTHREAD_MUTEX_RECURSIVE so different segments can > lock the same locked object without letting each other know providing > better OO. Of course as complexity in the locking mechanism increases so > is the chance of dead locks. The last sentence is exactly my reason to keep the locking mechanism simple, so only lock/unlock. > Why this hasn't turned up more might be that each zone is handled by one > thread, only time two threads might be working on the same zone is if > you do manually commands, and that the locking right now is very loose. Each zone is indeed handled by one *worker* thread, with a manually update, the cmdhandler/engine may have to update the zone. > Thoughts? I am not sure if this patch fixes the problem, When I look at the assertion error, it looks to me that there is a call that invalidly sets the zone->task to NULL. http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.3/signer/src/daemon/engine.c#L897 Here task may be set to NULL, if the task is being worked on (not scheduled). http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.3/signer/src/daemon/engine.c#L923 Here the zone->task is set to task, which might be NULL if the task was being worked on. This should not happen. The same in cmdhandler.c when a update call is received. Best regards, Matthijs > > /Jerry > > Index: signer/src/daemon/cmdhandler.c > =================================================================== > --- signer/src/daemon/cmdhandler.c(revision 5654) > +++ signer/src/daemon/cmdhandler.c(working copy) > @@ -190,11 +190,11 @@ > cmdc->engine->zonelist->just_removed = 0; > cmdc->engine->zonelist->just_added = 0; > cmdc->engine->zonelist->just_updated = 0; > - lock_basic_unlock(&cmdc->engine->zonelist->zl_lock); > > ods_log_debug("[%s] commit zone list changes", cmdh_str); > - engine_update_zones(cmdc->engine); > + engine_update_zones(cmdc->engine, 1); > ods_log_debug("[%s] signer configurations updated", cmdh_str); > + lock_basic_unlock(&cmdc->engine->zonelist->zl_lock); > } else { > lock_basic_unlock(&cmdc->engine->zonelist->zl_lock); > (void)snprintf(buf, ODS_SE_MAXLINE, "Zone list has errors.\n"); > Index: signer/src/daemon/engine.c > =================================================================== > --- signer/src/daemon/engine.c(revision 5654) > +++ signer/src/daemon/engine.c(working copy) > @@ -811,7 +811,7 @@ > * > */ > void > -engine_update_zones(engine_type* engine) > +engine_update_zones(engine_type* engine, int zonelist_is_locked) > { > ldns_rbnode_t* node = LDNS_RBTREE_NULL; > zone_type* zone = NULL; > @@ -833,8 +833,10 @@ > now = time_now(); > reload_zonefetcher(engine); > > - lock_basic_lock(&engine->zonelist->zl_lock); > - /* [LOCK] zonelist */ > + if (!zonelist_is_locked) { > + lock_basic_lock(&engine->zonelist->zl_lock); > + /* [LOCK] zonelist */ > + } > node = ldns_rbtree_first(engine->zonelist->zones); > while (node && node != LDNS_RBTREE_NULL) { > zone = (zone_type*) node->data; > @@ -929,8 +931,10 @@ > } > node = ldns_rbtree_next(node); > } > - /* [UNLOCK] zonelist */ > - lock_basic_unlock(&engine->zonelist->zl_lock); > + if (!zonelist_is_locked) { > +/* [UNLOCK] zonelist */ > +lock_basic_unlock(&engine->zonelist->zl_lock); > + } > if (wake_up) { > engine_wakeup_workers(engine); > } > @@ -1097,7 +1101,7 @@ > /* update zones */ > if (zl_changed == ODS_STATUS_OK) { > ods_log_debug("[%s] commit zone list changes", engine_str); > - engine_update_zones(engine); > + engine_update_zones(engine, 0); > ods_log_debug("[%s] signer configurations updated", > engine_str); > zl_changed = ODS_STATUS_UNCHANGED; > } > Index: signer/src/daemon/engine.h > =================================================================== > --- signer/src/daemon/engine.h(revision 5654) > +++ signer/src/daemon/engine.h(working copy) > @@ -101,7 +101,7 @@ > * \param[in] engine engine > * > */ > -void engine_update_zones(engine_type* engine); > +void engine_update_zones(engine_type* engine, int zonelist_is_locked); > > /** > * Clean up engine. > > > > _______________________________________________ > Opendnssec-otr mailing list > Opendnssec-otr at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-otr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOhCWiAAoJEA8yVCPsQCW5dJgH/0KfTB/P/xP5BNhqbs0JszrH kbmqx/Qm58ZDoNDPx1SGh7OP35Y4iV/nYwvxsahOwZAEDXYhDOJ3o8mhJ+mVsFYf Q5PlteRnv4TYjxY0GOpG3s2wZ5jmo7V5ZSe9HRfoIOQNYdS5lhkBF7NQo0oss/ss pY3bno83h5HtS69u7Fdv0ezbWVCkHzkf79RAHPSfEC0PAiqjxYqLykhnfA/K8xUN 8cw9fnKGOTF4LuG5W5DpDU3gntRmfKcbiwQHJ/61yJbPR41ksJ6fn9gYZHfaEuph UqGMh/92YXxFLXocIQ2OaJqW69b+p3P6iYwQYkFALSKIAg3ZRHce96y9XDNDZd4= =waww -----END PGP SIGNATURE----- From jerry at opendnssec.org Thu Sep 29 08:23:13 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Thu, 29 Sep 2011 10:23:13 +0200 Subject: [Opendnssec-develop] Locking mechanism problems In-Reply-To: <4E8425A2.6090805@nlnetlabs.nl> Message-ID: On 2011-09-29 10.00, Matthijs Mekking wrote: >>A quick fix to this is to make engine_update_zones() aware of the lock >> on zonelist so it doesn't try and lock it and release it after, >> suggested patch below. >> >> Altho I am seeing this almost everywhere and I would like to discuss our >> approach. I would really like to see read and write locks implemented to >> better support thread interoperability. Using >> pthread_mutex_trylock()/pthread_mutex_timedlock() where it suites to >> counter hangs. Using PTHREAD_MUTEX_RECURSIVE so different segments can >> lock the same locked object without letting each other know providing >> better OO. Of course as complexity in the locking mechanism increases so >> is the chance of dead locks. > >The last sentence is exactly my reason to keep the locking mechanism >simple, so only lock/unlock. But the cost might come as a crash or worse that the data gets corrupt. Just using PTHREAD_MUTEX_RECURSIVE would be a good start so that each separate segment in the code does not have to know about the locks. I don't know how supported PTHREAD_MUTEX_RECURSIVE is across the OS targets we have. >>Thoughts? > >I am not sure if this patch fixes the problem, When I look at the >assertion error, it looks to me that there is a call that invalidly sets >the zone->task to NULL. > >http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.3/signer/src/daem >on/engine.c#L897 > >Here task may be set to NULL, if the task is being worked on (not >scheduled). > >http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.3/signer/src/daem >on/engine.c#L923 > >Here the zone->task is set to task, which might be NULL if the task was >being worked on. This should not happen. > >The same in cmdhandler.c when a update call is received. I know that this fix does not fix everything, there are more places this can happen and there can be more data structures that might be affected by not locking correctly. Do we want to do an overhaul of the locks or is it in the plans to redo the signer? I could start looking at it in a week or so. /Jerry From matthijs at NLnetLabs.nl Thu Sep 29 08:31:06 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 29 Sep 2011 10:31:06 +0200 Subject: [Opendnssec-develop] Locking mechanism problems In-Reply-To: References: Message-ID: <4E842CCA.1030004@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/29/2011 10:23 AM, Jerry Lundstr?m wrote: > On 2011-09-29 10.00, Matthijs Mekking wrote: > >>> A quick fix to this is to make engine_update_zones() aware of the lock >>> on zonelist so it doesn't try and lock it and release it after, >>> suggested patch below. >>> >>> Altho I am seeing this almost everywhere and I would like to discuss our >>> approach. I would really like to see read and write locks implemented to >>> better support thread interoperability. Using >>> pthread_mutex_trylock()/pthread_mutex_timedlock() where it suites to >>> counter hangs. Using PTHREAD_MUTEX_RECURSIVE so different segments can >>> lock the same locked object without letting each other know providing >>> better OO. Of course as complexity in the locking mechanism increases so >>> is the chance of dead locks. >> >> The last sentence is exactly my reason to keep the locking mechanism >> simple, so only lock/unlock. > > But the cost might come as a crash or worse that the data gets corrupt. I am not sure which is better to be monitored. If the signer would deadlock, you run the risk of your signatures getting expired, though it looks like the signer is still doing its job (its up and running). If the signer would crash, of course you run this risk too, but you can immediately notice that the signer is not running. > > Just using PTHREAD_MUTEX_RECURSIVE would be a good start so that each > separate segment in the code does not have to know about the locks. I > don't know how supported PTHREAD_MUTEX_RECURSIVE is across the OS targets > we have. > >>> Thoughts? >> >> I am not sure if this patch fixes the problem, When I look at the >> assertion error, it looks to me that there is a call that invalidly sets >> the zone->task to NULL. >> >> http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.3/signer/src/daem >> on/engine.c#L897 >> >> Here task may be set to NULL, if the task is being worked on (not >> scheduled). >> >> http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.3/signer/src/daem >> on/engine.c#L923 >> >> Here the zone->task is set to task, which might be NULL if the task was >> being worked on. This should not happen. >> >> The same in cmdhandler.c when a update call is received. > > I know that this fix does not fix everything, there are more places this > can happen and there can be more data structures that might be affected by > not locking correctly. > > Do we want to do an overhaul of the locks or is it in the plans to redo > the signer? > > I could start looking at it in a week or so. I currently have no plans to redo the locking mechanisms. Too busy with the network support for adapters. > > /Jerry > > > > _______________________________________________ > 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOhCzKAAoJEA8yVCPsQCW5S8YH/iD0YOsVAli38oGZy7qne1mR +8Ntv+v4tR4vPc36jSe+ee4+oS+QqAYkblLkLiaePYs2oQ1JGdbu8UqUjBfcTUDm i8/Z6km//OaTv6EjQDfhpEZVuvdaZNPRtVy5mwKmq/2ypagH5lMy3/kOy3Xv6RTu mWMXIzhUwhdpBHQpMHGHRuUNbIouCxfuyR/qH+ue/lPXq8RDOKpYiczhyHgHHrZG xBLyg75q+K0M701LvKRhZJbHwdgh3LymBlQUgnY3dpt3mVpGeJMnTqijngy5i8Sz vIEO9lc6CXond3QdAqKI3lCBWy+nzBLzWxcLFh5cYakiVCYDOytnFA6qBWDXAk4= =jNjM -----END PGP SIGNATURE----- From nick.vandenheuvel at sidn.nl Thu Sep 29 09:13:48 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Thu, 29 Sep 2011 09:13:48 +0000 Subject: [Opendnssec-develop] Documentation website Message-ID: <8379DE00FDBE1B4F95522D088EC260DD026E65@kambx1.SIDN.local> Hi guys, I noticed that the current documentation on our opendnssec website (in the Documentation part) is based on 1.3.0. Will we change this soon? Regards, Nick Met vriendelijke groet, Nick van den Heuvel Test analist SIDN | Utrechtseweg 310 | 6802 EA | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 93 | F +31 (0)26 352 55 05 | jabber: nick.vandenheuvel at jabber.sidn.nl nick.vandenheuvel at sidn.nl | www.sidn.nl Kunt u nog zonder internet? Deze vraag stellen wij aan heel Nederland in de Nationale Internetenqu?te. Doet u mee? [enquete] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 30077 bytes Desc: image001.png URL: From rickard at opendnssec.org Thu Sep 29 10:31:24 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 29 Sep 2011 12:31:24 +0200 Subject: [Opendnssec-develop] Documentation website In-Reply-To: <8379DE00FDBE1B4F95522D088EC260DD026E65@kambx1.SIDN.local> References: <8379DE00FDBE1B4F95522D088EC260DD026E65@kambx1.SIDN.local> Message-ID: > I noticed that the current documentation on our opendnssec website (in the Documentation part) is based on 1.3.0. Will we change this soon? There have not been any changes to the documentation, so we could just bump the version to 1.3.2. We will however migrate the documentation to wiki.opendnssec.org where the documentation will only be per minor release, e.g. 1.3 or 1.4. // Rickard From jerry at opendnssec.org Thu Sep 29 13:36:53 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Thu, 29 Sep 2011 15:36:53 +0200 Subject: [Opendnssec-develop] Build farm and Jenkins Message-ID: Hey all, Good news, me and John are setting up Jenkins for automated build and test. John has contributed a server to be used as a Jenkins master, it's already up and running and he has started to split the build_and_test.sh into individual tests. (URL coming later) I am getting our servers, provided by SURFnet, ready as nodes. We have Ubuntu 10.04.3, Red Hat RHEL 6.1, FreeBSD 8.1 and a Solaris 5.11. I would also like to get a CentOS and OpenBSD, but we will see how that goes. We can soon start spamming your inboxes and even nag on Jabber :) /Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Thu Sep 29 13:37:59 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 29 Sep 2011 15:37:59 +0200 Subject: [Opendnssec-develop] Build farm and Jenkins In-Reply-To: References: Message-ID: On 29 sep 2011, at 15:36, Jerry Lundstr?m wrote: > Good news, me and John are setting up Jenkins for automated build and test. > > John has contributed a server to be used as a Jenkins master, it's already up and running and he has started to split the build_and_test.sh into individual tests. (URL coming later) > > I am getting our servers, provided by SURFnet, ready as nodes. We have Ubuntu 10.04.3, Red Hat RHEL 6.1, FreeBSD 8.1 and a Solaris 5.11. I would also like to get a CentOS and OpenBSD, but we will see how that goes. > > We can soon start spamming your inboxes and even nag on Jabber :) Wheehee - nice work! jakob From owner-dnssec-trac at kirei.se Thu Sep 29 19:21:37 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 29 Sep 2011 19:21:37 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #263: private amateure Message-ID: <047.4b30d552c26de2b080f26baa39bd952e@kirei.se> #263: private amateure ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: 1.3.0 | Keywords: private amateure ----------------------+----------------------------------------------------- [http://privat-fun.com private amateure] -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Sep 30 08:01:38 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 30 Sep 2011 08:01:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> Message-ID: <071.6ad79150b0ab41128b5e9297a25f142b@kirei.se> #262: Possible race condition causing CPU-bound loop in signerd? -------------------------------+-------------------------------------------- Reporter: goeran@? | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: 1.3.0 | Resolution: Keywords: CPU-bound loop | -------------------------------+-------------------------------------------- Comment (by anonymous): It happened again tonight. COllected some more info (strace for the CPU- bound threads). As last time, collecting info (this time with gbg) removed the condition. Collected info as an attachment. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jerry at opendnssec.org Fri Sep 30 14:33:22 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Fri, 30 Sep 2011 16:33:22 +0200 Subject: [Opendnssec-develop] Signer does not update TTL on RRs unless there is change in RDATA Message-ID: Hi, Patrik reported this problem today and its very easy to replicate in 1.3.2, just change the $TTL and issue a resign of the zone. Since there is no RDATA change the TTL does not get changed in the signed zone. This is because util_dnssec_rrs_compare() uses ldns_rr_compare_wire() and that only checks for changes in RDATA. Before I commit this fix that I've tested, I wanted to check if this can break anything else? I can't see if this is a problem in trunk since it seems that most of the rr/rrset code has been changed. /Jerry Index: branches/OpenDNSSEC-1.3/signer/src/signer/rrset.c =================================================================== --- branches/OpenDNSSEC-1.3/signer/src/signer/rrset.c (revision 5654) +++ branches/OpenDNSSEC-1.3/signer/src/signer/rrset.c (working copy) @@ -474,6 +474,9 @@ current = current->next; } else { /* equal RRs */ + /* TTL is not compared in util_dnssec_rrs_compare() so we copy it */ + ldns_rr_set_ttl(current->rr, ldns_rr_ttl(pending->rr)); + /* remove pending RR */ if (!prev) { rrset->add = pending->next; -------------- next part -------------- An HTML attachment was scrubbed... URL: From goeran at chalmers.se Mon Sep 26 13:44:30 2011 From: goeran at chalmers.se (=?ISO-8859-1?Q?G=F6ran_Bengtson?=) Date: Mon, 26 Sep 2011 15:44:30 +0200 (CEST) Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: <071.53a8c26f4717d5c26014c8b5d0b2630e@kirei.se> References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> <071.53a8c26f4717d5c26014c8b5d0b2630e@kirei.se> Message-ID: On Mon, 26 Sep 2011, OpenDNSSEC wrote: > From: OpenDNSSEC > Cc: "opendnssec-develop at lists.opendnssec.org" > > Message-ID: <071.53a8c26f4717d5c26014c8b5d0b2630e at kirei.se> > Date: Mon, 26 Sep 2011 15:29:42 +0200 > Subject: Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop > in signerd? > > #262: Possible race condition causing CPU-bound loop in signerd? > -------------------------------+-------------------------------------------- > Reporter: goeran@? | Owner: matthijs > Type: defect | Status: new > Priority: major | Component: Signer > Version: 1.3.0 | Resolution: > Keywords: CPU-bound loop | > -------------------------------+-------------------------------------------- > > Comment (by jerry): > > Hi G?ran, > > When was the gdb taken, before or after strace? Before. When the processes and threads where in the CPU loop. > > Regards, > Jerry > > -- > Ticket URL: > OpenDNSSEC > OpenDNSSEC / G?ran Bengtson Chalmers From goeran at chalmers.se Tue Sep 27 08:21:03 2011 From: goeran at chalmers.se (=?ISO-8859-1?Q?G=F6ran_Bengtson?=) Date: Tue, 27 Sep 2011 10:21:03 +0200 (CEST) Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: <071.95e6f7d3790ab20828dc8a58b19ab27d@kirei.se> References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> <071.95e6f7d3790ab20828dc8a58b19ab27d@kirei.se> Message-ID: On Tue, 27 Sep 2011, OpenDNSSEC wrote: > From: OpenDNSSEC > Cc: "opendnssec-develop at lists.opendnssec.org" > > Message-ID: <071.95e6f7d3790ab20828dc8a58b19ab27d at kirei.se> > Date: Tue, 27 Sep 2011 10:01:50 +0200 > Subject: Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop > in signerd? > > #262: Possible race condition causing CPU-bound loop in signerd? > -------------------------------+-------------------------------------------- > Reporter: goeran@? | Owner: matthijs > Type: defect | Status: accepted > Priority: major | Component: Signer > Version: 1.3.0 | Resolution: > Keywords: CPU-bound loop | > -------------------------------+-------------------------------------------- > Changes (by matthijs): > > * status: new => accepted > > > Comment: > > Hi, > > To get more insight of why the signer gets stuck, I would like to know: > - how many worker threads and signer threads you have configured? 8 worker threads, 2 signer threads. > - how many zones you have configured? 10 > - what is the maximum size of the zones? 36970 RRs. > - the kasp.xml As an attachment. Additional comments. The system is Guest configured with 2 CPUs running in a VMWare cluster. If I remeber correct from the strace (before strace removed the condition!), strace indicate that the signer loops in pthread_cond_timewait() with 'FUTEX WATI', futex returning EAGAIN (Resource temporarily unavailable). > > If you prefer, you can send me this information off list. > > -- > Ticket URL: > OpenDNSSEC > OpenDNSSEC / G?ran -------------- next part -------------- A non-text attachment was scrubbed... Name: kasp.xml Type: text/xml Size: 5115 bytes Desc: kasp.xml URL: