From matthijs at NLnetLabs.nl Tue Sep 1 08:53:37 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 01 Sep 2009 10:53:37 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-user] Signer Engine? In-Reply-To: <5c494b510908311434x4d65614h6bcec11aeedbe096@mail.gmail.com> References: <5c494b510908190242i7f91be70u1d9dc9514371286e@mail.gmail.com> <69830D4127201D4EBD146B9041199718F76720@EXCHANGE.office.nic.se> <4A9553B4.6040902@nlnetlabs.nl> <5c494b510908270857j717716e8l546636a4cbb0cf5d@mail.gmail.com> <4A9BBEA3.6000807@nlnetlabs.nl> <5c494b510908311434x4d65614h6bcec11aeedbe096@mail.gmail.com> Message-ID: <4A9CE111.2090601@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brett, In python 2.4 and older, The exception inherits from StandardError instead of BaseException, so it might be accidentally caught by code that catches Exception. See http://docs.python.org/library/exceptions.html#exceptions.SystemExit I have applied a patch, that should fix this problem (or get the latest trunk). Best regards, Matthijs B C wrote: > On Mon, Aug 31, 2009 at 1:14 PM, Matthijs Mekking wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Brett, >> >> With the current information, I have not been able to solve the issue. I >> have two suggestions left: >> >> * Which version of Python do you use? The SystemExit exception has >> changed to inherit from BaseException instead of StandardError since >> version 2.5. > > rpm reports: > > python-2.4.3-24.el5_3.6 > > Python reports > > Python 2.4.3 (#1, Jul 27 2009, 17:56:30) > [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2 > > Should I be running 2.5 ? I don't see this as a req in the docs? > >> * Could it be that there is an old engine running that outputs the log >> messages? >> # ps waux | grep Engine >> > > There was only one copy running. To be sure I killed that one, and > started a new one: > > [root at dnssigner2 ~]# /opt/opendnssec2/sbin/signer_engine > Python engine proof of concept, v 0.0002 alpha > Zone list updated: 0 removed, 1 added, 0 updated > running as pid 24065 > Unable to continue, stopping: > Unexpected error: exceptions.SystemExit > > However again the process is still running: > > root 24065 0.3 0.7 308020 7264 ? Sl 22:27 0:00 > python /opt/opendnssec2/lib/opendnssec/signer/Engine.py > > Brett -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKnOEPAAoJEA8yVCPsQCW5zMIIAMt1Y1SV9x3/UgoVjZM13cSq aQItwUQgr53B+sTvVlOHMvb/ogP4gguB5Mh3NVXp95CHwU6ud2TSGKv16d2vlE7k fn3Cn+/39sjr91X8zlqvrA2k/N7g8EpgCb0/gNUPVOKlb3vZTbedwT4YJthVfGsC ahFM+2Imu9j7VjHTCdDO9vQlraLE+ZXSi9NnAybsUsJwCKP/RaMy9MUp1j3Fx/e1 sCv/fNBX7Qd61oK81q4GcbhdPs0F4kzOUL4NSVXpuVgiUSVemg0nHyw0+vZJWOnP efNLKUQUWHL0BLXXHrQNDqqa18SadKdXORt1UA8XiULn9LPOd1dDYDqc2IUkSqI= =Rt6v -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: systemexit.patch Type: text/x-patch Size: 642 bytes Desc: not available URL: From owner-dnssec-trac at kirei.se Tue Sep 1 09:17:46 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 01 Sep 2009 09:17:46 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #20: Added generation statistics for nseccer, nsec3er and signer In-Reply-To: <059.6dc553c3ddb0e93ee9e0308360446ab8@kirei.se> References: <059.6dc553c3ddb0e93ee9e0308360446ab8@kirei.se> Message-ID: <068.473664ec700e19f222e8dd42817c2089@kirei.se> #20: Added generation statistics for nseccer, nsec3er and signer ----------------------------------------+----------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: enhancement | Status: assigned Priority: minor | Component: Signer Version: 1.0a1 | Resolution: Keywords: enhancement generation rate | ----------------------------------------+----------------------------------- Changes (by matthijs): * owner: jelte => matthijs * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Tue Sep 1 10:40:54 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 1 Sep 2009 11:40:54 +0100 Subject: [Opendnssec-develop] manual Rollover Message-ID: Hi there, I've made another change to the enforcer database (svn r1757), a migration script is provided so please run: sqlite3 < enforcer/utils/migrate_090901_1.sqlite3 or "ksmutil setup" if you don't want to keep existing data. This adds the ManualRollover setting for KSKs and ZSKs, preventing the rollover from happening without "ksmutil rollover " being called. Everything else carries on as normal, and communicated logs a message when the rollover is due (and continues to log until the rollover is done). Sion From Stephen.Morris at nominet.org.uk Tue Sep 1 11:45:13 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 1 Sep 2009 12:45:13 +0100 Subject: [Opendnssec-develop] Embedded scripts can replace syslog() In-Reply-To: <0D6A38B7-ED04-4087-A65A-8BB222AC3B61@kirei.se> References: <20090828104508.GA11966@phantom.vanrein.org> <20090828144321.GA16292@phantom.vanrein.org> <0D6A38B7-ED04-4087-A65A-8BB222AC3B61@kirei.se> Message-ID: Jakob Schlyter wrote on 31/08/2009 09:57:34: > > Relativating my own democode, I see the inclusion of a complete Python > > interpreter as a potential problem: > > * as a static library, it makes programs larger > > * as a dynamic library, it adds a dependency (on python-devel) > > > > Another approach, with a similar drop-in-place approach, could be to > > use an exec() call to invoke the "logger" utility or another (shell) > > script with the same options as used to logger(1), > > for each and every log line? that's something I would encourage my > competitors do do. Agreed. We have multiple daemon processes all logging to syslog. If we want to give users the ability to process log messages, I suggest that we ensure that all OpenDNSSEC code logs via a thin wrapper around syslog which calls a user-exit function and, depending on the returned status, syslog, e.g. void MsgLog() { if (UeLog() == 0) { syslog() } } As part of the OpenDNSSEC distribution, we include a DLL that contains nothing but dummy user-exit functions. The one for UeLog would look like: int UeLog() { return 0; } If the user wants to intercept log messages, all they need to do is to replace this one DLL without touching the rest of the OpenDNSSEC code. They can do what they want with each message (such as starting a Python script or suppressing syslog output), but there is minimal overhead if they choose not to use the capability. > > > Having said that, I'm interested in hearing your thoughts on the > > trade-offs. > > for version 1, which is our focus currently - I say we do syslog only. Agreed again. For version 1, let's do the minimum required to get it working. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Tue Sep 1 11:49:17 2009 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 1 Sep 2009 11:49:17 +0000 Subject: [Opendnssec-develop] Embedded scripts can replace syslog() In-Reply-To: References: <20090828104508.GA11966@phantom.vanrein.org> <20090828144321.GA16292@phantom.vanrein.org> <0D6A38B7-ED04-4087-A65A-8BB222AC3B61@kirei.se> Message-ID: <20090901114917.GB10373@phantom.vanrein.org> Hi, > > for each and every log line? that's something I would encourage my > > competitors do do. > > Agreed. You are right, embedding logging code is better. > We have multiple daemon processes all logging to syslog. If we want to > give users the ability to process log messages, I suggest that we ensure > that all OpenDNSSEC code logs via a thin wrapper around syslog which calls > a user-exit function and, depending on the returned status, syslog, e.g. Yes, that's what I did with the embedded script. It is much, much more efficient -- except that it includes a scripting language into OpenDNSSEC. That means a lot of flexibility as well as the larger binary size to hold the interpreter. It's just a proposal -- I'll leave it to others to decide if we want to be _that_ general, but building our own logging system doesn't seem like a dream job to me. -Rick From matthijs at NLnetLabs.nl Tue Sep 1 12:08:47 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 01 Sep 2009 14:08:47 +0200 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #13: "engine: no new signatures, keeping zone" when changing zone parameters In-Reply-To: <4A9BCD5F.8090609@nlnetlabs.nl> References: <058.aa1d6fb1117521292b7da9d6cb0ad93f@kirei.se> <067.f65a0dd3d639fb49c0ea52dde52e44a1@kirei.se> <4A9BCD5F.8090609@nlnetlabs.nl> Message-ID: <4A9D0ECF.1040907@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FIY Matthijs Mekking wrote: > Hi, > > Picking op this ticket. Not sure what to do. > > The report is two-fold. > > 1. > What to do if the signer engine is presented a new SignerConfiguration > but no new signatures need to be created. Should we keep the old zone or > should we force a new output zone? > > In my point of view, we should only output a new zone if new signatures > where created. So, for example an increased signature refresh value does > not necessarily result in a new output zone. Currently, it forces new signatures when a new SignerConfiguration is detected. > 2. > What to do when signer_engine_cli sign is called. Should we force > a new output zone or only if new signatures are created? > > In my point of view, again, we should only output a new zone if new > signatures are created. If the SOA serial changed, we should only output > a new zone if the SOA/Serial is equal to "keep". Currently, the old zone is kept if only the SOA serial changes (regardless of the SOA/Serial value). > > Is this ok? > > Matthijs > > OpenDNSSEC wrote: >> #13: "engine: no new signatures, keeping zone" when changing zone parameters >> ---------------------------------+------------------------------------------ >> Reporter: mattias at nonetwork.se | Owner: matthijs >> Type: defect | Status: assigned >> Priority: minor | Component: Unknown >> Version: | Resolution: >> Keywords: | >> ---------------------------------+------------------------------------------ >> Changes (by jakob): > >> * owner: jelte => matthijs > > > > >> ------------------------------------------------------------------------ > >> _______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKnQ7MAAoJEA8yVCPsQCW5unIIANcCHm+SuGjZUgWQZWhnhr1p aMhZXY1Y65bEn3VnYxJrvHaqBnFUs0S+uOaUAPaSd+X8yAR9xWUk5hskXqj/gHK3 siUPOAfH/EXCUcxdGdmTc4Zi76VLAnhJ6cFJDMi//ZNYieVy9ATtMn1sA4w5basD cM6yDkxdDdUluM2IuA0pbI3H9+By/w5N4ghmtpJtaLt9pkvkzZHHinqRwL8p6Gsl M5p9ZmcWn1h9Hcl0jn9WIRBiheFPOXdacl0HARfxI9aDvF84eaq8ZhaOdwkN32EK DJU70yiYO62MlYS4yo53SCyP/NnTR6SZzXQrUIyL1wFZSa1wkEDSgmk5/Bg+rE8= =rI0N -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Tue Sep 1 14:37:52 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 1 Sep 2009 15:37:52 +0100 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #13: "engine: no new signatures, keeping zone" when changing zone parameters In-Reply-To: <4A9D0ECF.1040907@nlnetlabs.nl> References: <058.aa1d6fb1117521292b7da9d6cb0ad93f@kirei.se> <067.f65a0dd3d639fb49c0ea52dde52e44a1@kirei.se> <4A9BCD5F.8090609@nlnetlabs.nl> <4A9D0ECF.1040907@nlnetlabs.nl> Message-ID: Matthijs Mekking wrote on 01/09/2009 13:08:47: > > Hi, > > > > Picking op this ticket. Not sure what to do. > > > > The report is two-fold. > > > > 1. > > What to do if the signer engine is presented a new SignerConfiguration > > but no new signatures need to be created. Should we keep the old zone or > > should we force a new output zone? > > > > In my point of view, we should only output a new zone if new signatures > > where created. So, for example an increased signature refresh value does > > not necessarily result in a new output zone. > > Currently, it forces new signatures when a new SignerConfiguration is > detected. I would have thought that would be OK. How often is the signer configuration likely to change once the system is in operation? > > 2. > > What to do when signer_engine_cli sign is called. Should we force > > a new output zone or only if new signatures are created? > > > > In my point of view, again, we should only output a new zone if new > > signatures are created. If the SOA serial changed, we should only output > > a new zone if the SOA/Serial is equal to "keep". > > Currently, the old zone is kept if only the SOA serial changes > (regardless of the SOA/Serial value). I think we should force a new output zone: the user has requested that a signing operation be performed and so we should do it. We could always add a flag to the command (or add a new command) that will only output the zone if new signatures are created. However, bear in mind one special case: the OpenDNSSEC data flow is: Unsigned zone -> Signer -> Signed zone -> Auditor -> Nameserver What happens if an insecure delegation is added to the unsigned zone and the zone is signed using NSEC3? No new signatures (other than that for the updated SOA) have to be created, but signer needs to propagate the new information through to the nameserver. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Sep 2 06:33:11 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 02 Sep 2009 06:33:11 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #13: "engine: no new signatures, keeping zone" when changing zone parameters In-Reply-To: <058.aa1d6fb1117521292b7da9d6cb0ad93f@kirei.se> References: <058.aa1d6fb1117521292b7da9d6cb0ad93f@kirei.se> Message-ID: <067.4bad1a22b40b4e324372bd7e9b7084d0@kirei.se> #13: "engine: no new signatures, keeping zone" when changing zone parameters ---------------------------------+------------------------------------------ Reporter: mattias at nonetwork.se | Owner: matthijs Type: defect | Status: closed Priority: minor | Component: Unknown Version: | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Changes (by rb): * status: assigned => closed * resolution: => fixed Comment: Closing this one, since it looks like this has been resolved. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Thu Sep 3 08:30:52 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 3 Sep 2009 09:30:52 +0100 Subject: [Opendnssec-develop] Overlapping KSKs Message-ID: Morning, >From item 8 of http://trac.opendnssec.org/wiki/Meetings/Minutes/2009-08-27 I see that overlapping KSKs is still up for discussion. I was going to move on to this as my next piece of work so I'll kick off the discussion... The KSK is used as soon as it is published in the zone (event 2 in figure 5 of the timing draft), the ready time signifies when we believe that the DNSKEY and or DS records have propagated. The key becomes "active" when its predecessor is retired, so really "active" means "the next key to retire" for KSKs. This means that we already have overlapping keys, but they are not both marked as "active", one is marked as "ready". A lifetime of 1 year means that a key will be in the "ready" state for about a year (while its predecessor is active), and active for 1 year; unless an emergency rollover is performed. Does this work for .se? Or, do we need some new logic to mark 2 keys as "active"? Then we have a question about rollovers. If the rollover is an emergency one do we have to assume that all keys on that HSM are compromised? Do we need to think about standby keys (ones on the same hsm, waiting for scheduled rollovers) and emergency keys (stored on a separate hsm) as separate entities? Sion From jakob at kirei.se Thu Sep 3 09:39:27 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 3 Sep 2009 05:39:27 -0400 Subject: [Opendnssec-develop] Overlapping KSKs In-Reply-To: References: Message-ID: <81768D7E-3CBA-49D4-AA01-8BD3021E0813@kirei.se> On 3 sep 2009, at 04.30, sion at nominet.org.uk wrote: > Does this work for .se? Or, do we need some new logic to mark 2 keys > as > "active"? we need to mark 2 keys active concurrently. > Then we have a question about rollovers. If the rollover is an > emergency > one do we have to assume that all keys on that HSM are compromised? > Do we > need to think about standby keys (ones on the same hsm, waiting for > scheduled rollovers) and emergency keys (stored on a separate hsm) as > separate entities? in amsterdam we decided that what we currently call "emergency keys" should be renamed to "standby keys". the reason was that the standby keys are more used for standby than for actual emergency, IIRC: jakob From Alexd at nominet.org.uk Thu Sep 3 14:59:12 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 3 Sep 2009 15:59:12 +0100 Subject: [Opendnssec-develop] Matching DNSKEYs up to Keys->KSK elements Message-ID: Hi - I'm meant to be tracking DNSKEYs (their in-use lifetime, and the number of pre-published keys). I'm meant to check these against the kasp.xml Keys->KSK or Keys->ZSK elements. The thing is that there can be several of these elements per algorithm. So, I don't know how I can take a DNSKEY record from the zone and relate it to an individual Keys->KSK or Keys->ZSK element. So, I don't know what the associated Lifetime or Emergency elements are either, and can't audit the key. Does anybody know how I can match up a DNSKEY RR in the zone to an individual Keys->KSK element, without looking up the database? Thanks!! Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Sun Sep 6 14:37:56 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 06 Sep 2009 14:37:56 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #21: nsec3er can't handle an "Empty non-terminal" at the start of the file Message-ID: <065.b815188286fe6a297c65edb867871f51@kirei.se> #21: nsec3er can't handle an "Empty non-terminal" at the start of the file ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: jelte Type: defect | Status: new Priority: major | Component: Signer Version: 1.0a1 | Keywords: ----------------------------------------+----------------------------------- If there's an "Empty non-terminal" at the start of the sorted file, the nsec3er program tries to dereference a NULL pointer: {{{ #0 ldns_rr_rd_count (rr=0x0) at rr.c:761 #1 0x08049416 in link_nsec3_rrs (nsec3_a=0x0, nsec3_b=0x8b38028) at nsec3er.c:164 #2 0x080496da in handle_name (out_file=0x8b371c8, rr=0x0, origin=0x8b37018, ttl=3600, prev_name=0x0, rr_list=0x8b382e0, prev_nsec=0xbfe4e004, first_nsec=0xbfe4e000, n3p=0x8b37008, ent_name=0x8b382f0, ent_ns=0) at nsec3er.c:289 #3 0x08049a7d in handle_line (out_file=0x8b371c8, line=0x8b37330 "; Empty non-terminal: .ip6.arpa.", line_len=93, origin=0x8b37018, soa_min_ttl=3600, prev_name=0xbfe4dffc, n3p=0x8b37008, rr_list=0x8b382e0, prev_nsec=0xbfe4e004, first_nsec=0xbfe4e000) at nsec3er.c:365 #4 0x08049c54 in create_nsec3_records (input_file=0x8b37060, out_file=0x8b371c8, origin=0x8b37018, n3p=0x8b37008, soa_min_ttl=3600) at nsec3er.c:432 #5 0x0804a4da in main (argc=13, argv=0xbfe4e114) at nsec3er.c:615 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sun Sep 6 14:43:49 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 06 Sep 2009 14:43:49 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #22: keygend frequently doesn't realise new keys need to be generated Message-ID: <065.77063d64e3ca06af09d071317f6125a2@kirei.se> #22: keygend frequently doesn't realise new keys need to be generated ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: | Keywords: ----------------------------------------+----------------------------------- The mechanism used to determine if new keys need to be generated is too simplistic. Counting zones and keys doesn't appear to work correctly. I have to modify the code to make it think some more keys need to be generated. This shows up most often when adding a single zone, and it may be also be caused by removing and then adding a zone. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sun Sep 6 14:54:23 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 06 Sep 2009 14:54:23 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #21: nsec3er can't handle an "Empty non-terminal" at the start of the file In-Reply-To: <065.b815188286fe6a297c65edb867871f51@kirei.se> References: <065.b815188286fe6a297c65edb867871f51@kirei.se> Message-ID: <074.b19282596a9c1143c2e8d398c5e86cdf@kirei.se> #21: nsec3er can't handle an "Empty non-terminal" at the start of the file ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: jelte Type: defect | Status: new Priority: major | Component: Signer Version: 1.0a1 | Resolution: Keywords: | ----------------------------------------+----------------------------------- Comment(by opendnssec.simon at arlott.org): It also shouldn't have continued and created an empty zone file when nsec3er crashed. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 7 13:21:52 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 07 Sep 2009 13:21:52 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #20: Added generation statistics for nseccer, nsec3er and signer In-Reply-To: <059.6dc553c3ddb0e93ee9e0308360446ab8@kirei.se> References: <059.6dc553c3ddb0e93ee9e0308360446ab8@kirei.se> Message-ID: <068.635ab5f823e5b8fd236b88e2763d9a9f@kirei.se> #20: Added generation statistics for nseccer, nsec3er and signer ----------------------------------------+----------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: enhancement | Status: closed Priority: minor | Component: Signer Version: 1.0a1 | Resolution: fixed Keywords: enhancement generation rate | ----------------------------------------+----------------------------------- Changes (by matthijs): * status: assigned => closed * resolution: => fixed Comment: Hi! I have adapted your patch (so it can handle time elapsed = 0) and submitted in trunk -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 7 13:24:07 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 07 Sep 2009 13:24:07 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #21: nsec3er can't handle an "Empty non-terminal" at the start of the file In-Reply-To: <065.b815188286fe6a297c65edb867871f51@kirei.se> References: <065.b815188286fe6a297c65edb867871f51@kirei.se> Message-ID: <074.a7897c8c9ad37c12d73d03c1fbc39502@kirei.se> #21: nsec3er can't handle an "Empty non-terminal" at the start of the file ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: 1.0a1 | Resolution: Keywords: | ----------------------------------------+----------------------------------- Changes (by matthijs): * owner: jelte => matthijs * status: new => accepted -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Tue Sep 8 07:41:18 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 8 Sep 2009 09:41:18 +0200 Subject: [Opendnssec-develop] 1.0a4 later this week Message-ID: <25545A3D-7D09-4619-9E10-A352FB225DA3@kirei.se> hi, I'm planning on tagging 1.0a4 thursday after lunch - please make sure finished stories in the tracker has been accepted. jakob From owner-dnssec-trac at kirei.se Tue Sep 8 11:44:32 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 08 Sep 2009 11:44:32 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #21: nsec3er can't handle an "Empty non-terminal" at the start of the file In-Reply-To: <065.b815188286fe6a297c65edb867871f51@kirei.se> References: <065.b815188286fe6a297c65edb867871f51@kirei.se> Message-ID: <074.05dd7e069d78a3fe7b99ef90399462a2@kirei.se> #21: nsec3er can't handle an "Empty non-terminal" at the start of the file ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: 1.0a1 | Resolution: Keywords: | ----------------------------------------+----------------------------------- Comment(by opendnssec.simon at arlott.org): The original zone that caused the problem is an ip6.arpa zone, which unlike most in-addr.arpa zone files contains multiple levels of hostname parts, e.g. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. IN PTR localhost. Example zone file "test": {{{ $ cat > test.input @ SOA . . ( 1 1 1 1 1 ) 1.2.3.4 PTR . $ src/OpenDNSSEC-1.0a3/signer/tools/zone_reader -o test -w test.sorted -n -s 00 -t 5 -a 1 < test.input $ cat test.sorted ; Empty non-terminal: 4.test. 1.2.3.4.test. 3600 IN PTR . test. 3600 IN SOA . . 1 1 1 1 1 test. 3600 IN NSEC3PARAM 1 0 5 00 ; Empty non-terminal: 2.3.4.test. ; Empty non-terminal: 3.4.test. $ src/OpenDNSSEC-1.0a3/signer/tools/nsec3er -o test -s 00 -t 5 -a 1 -i test.sorted -w test.nsec Segmentation fault $ }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Tue Sep 8 11:46:54 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Tue, 8 Sep 2009 12:46:54 +0100 Subject: [Opendnssec-develop] Agenda for conference call tomorrow Message-ID: Hi - Does anybody know if there is an agenda posted for tomorrow's call? Thanks! Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy at nominet.org.uk Tue Sep 8 13:18:02 2009 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 8 Sep 2009 14:18:02 +0100 Subject: [Opendnssec-develop] Call logistics and Call for Agenda items for conference call tomorrow In-Reply-To: References: Message-ID: Alex Dalitz wrote on 09/08/2009 12:46:54 PM: > Does anybody know if there is an agenda posted for tomorrow's call? Rickard is honeymooning this month, and he asked me to take care of the administrivia. So here goes: Could I have agenda items please? The few subjects I have are: 1) scribe volunteer & agenda bash 2) Introduction of Rick Zijlker 3) action items of last meeting (see below) 4) possibly unifying the enforcer 5) release of .a4 6) testing 7) codesprint administrativia 8) aob Logistics: 2009-09-09 from 13:00h-15:00h CET (12:00h-14:00h BST) 2009-09-23 from 13:00h-15:00h CET (12:00h-14:00h BST) UK 08702407821 UK toll free 08081005145 SE 0858536827 SE toll free 0200110476 NL 0202013852 NL toll free 08000223422 Contact me if you want numbers in other countries. The passcode for the participants is: 4227104 Jabber: xmpp:opendnssec at conference.kirei.se Action items of last meeting (as result of grep): Action Item: Write a user guide on time durations and fixed points in time for rolling keys Action Item: Make note: known issue: signer engine: a month is always 31 days Action Item: Write some stuff to explain to users how to do outbound AXFR Action Item: Inbound hack will be provided by Matthijs Action Item: Implement optional flag to turn off automatic key rollover Action Item: Create a simple HOWTO-description about rolling keys on a specific date Action Item: Rickard: add configure option to SoftHSM to link Botan statically, same for LDNS Action Item: Rickard: add configure option to top level configure to disable the auditor (and thus not include Ruby) Action Item: Roland contact undisclosed HSM vendor to talk about HSMs for testing purposes Action Item: Rickard: will compile a reading guide for the Wiki for the testers Action Item: Markus: send an e-mail when the testers should be put on the development mailing list Action Item: Matthijs: check whether there is any test documentation for LDNS Action Item: Rick + Stephen: work on requirements and use cases Action Item: All developers: check your code against the requirements and make the documents consistent if necessary Action Item: Markus: check if a rough test can be performed on the beta in October Action Item: Stephen: write the story for the unified control program in Pivotal Kind regards, Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Tue Sep 8 13:40:04 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 08 Sep 2009 13:40:04 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #21: nsec3er can't handle an "Empty non-terminal" at the start of the file In-Reply-To: <065.b815188286fe6a297c65edb867871f51@kirei.se> References: <065.b815188286fe6a297c65edb867871f51@kirei.se> Message-ID: <074.0f33c211f13d383febb06b52250739db@kirei.se> #21: nsec3er can't handle an "Empty non-terminal" at the start of the file ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: 1.0a1 | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by matthijs): * status: accepted => closed * resolution: => fixed Comment: Fixed. Could you let me know if the trunk works for you? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 9 00:42:23 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 09 Sep 2009 00:42:23 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #23: Building requires java but configure doesn't check for it Message-ID: <059.e1074333efbf8b8b5453d5e9879430d9@kirei.se> #23: Building requires java but configure doesn't check for it ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: jakob Type: defect | Status: new Priority: trivial | Component: Unknown Version: | Keywords: ----------------------------------+----------------------------------------- The documentation indicates Java (actually a JRE) is required to build openDNSSEC. The 'configure' process doesn't detect the presence or absence of a JRE on the host machine, causing a failure on the xml/Makefile if not present. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 9 05:44:57 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 09 Sep 2009 05:44:57 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #24: In-house changes to patch for ticket #20 break the signer engine Message-ID: <059.24fcabc8aa9f6ccb8df5df380acbc4eb@kirei.se> #24: In-house changes to patch for ticket #20 break the signer engine ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: jelte Type: defect | Status: new Priority: major | Component: Signer Version: | Keywords: ----------------------------------+----------------------------------------- In ticket #20 I provided a patch to return statistics about the record generation process (NSEC(3) and RRSIG). When they were included on the trunk code, the in-house changes break the interaction between signer and the signer_engine. My patch was based on the behaviour of signer_engine to print to the logs the STDERR of the signer binary. I was careful not to change the output line "Number of signatures created: " because the signer_engine relays on it to detect the success of the signer call, so I added a second output line indicating the record generation rate. A local change merged both output lines in one and added a "signer: " prefix, breaking the parsing done on the signer_engine (Zone.py, line 807). With this, signer_engine is unable to detect the success of the signing process, iterating over and over to resign the zone. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 9 06:03:22 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 09 Sep 2009 06:03:22 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #24: In-house changes to patch for ticket #20 break the signer engine In-Reply-To: <059.24fcabc8aa9f6ccb8df5df380acbc4eb@kirei.se> References: <059.24fcabc8aa9f6ccb8df5df380acbc4eb@kirei.se> Message-ID: <068.a8b83ad0cca7193d074e09fb5083f3d6@kirei.se> #24: In-house changes to patch for ticket #20 break the signer engine ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: defect | Status: assigned Priority: major | Component: Signer Version: | Resolution: Keywords: | ----------------------------------+----------------------------------------- Changes (by jakob): * owner: jelte => matthijs * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 9 06:11:56 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 09 Sep 2009 06:11:56 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #23: Building requires java but configure doesn't check for it In-Reply-To: <059.e1074333efbf8b8b5453d5e9879430d9@kirei.se> References: <059.e1074333efbf8b8b5453d5e9879430d9@kirei.se> Message-ID: <068.701f6a4ad74ad8cc246330f6e5f1383a@kirei.se> #23: Building requires java but configure doesn't check for it ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: jakob Type: defect | Status: accepted Priority: trivial | Component: Unknown Version: | Resolution: Keywords: | ----------------------------------+----------------------------------------- Changes (by jakob): * status: new => accepted -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 9 06:17:49 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 09 Sep 2009 06:17:49 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #23: Building requires java but configure doesn't check for it In-Reply-To: <059.e1074333efbf8b8b5453d5e9879430d9@kirei.se> References: <059.e1074333efbf8b8b5453d5e9879430d9@kirei.se> Message-ID: <068.20dd7097b6e5a3c2be1ad1b498e4224e@kirei.se> #23: Building requires java but configure doesn't check for it ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: jakob Type: defect | Status: closed Priority: trivial | Component: Unknown Version: 1.0a3 | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Changes (by jakob): * status: accepted => closed * version: => 1.0a3 * resolution: => fixed Comment: Fixed in r1790. The fix is written so make will output an error message if java js not found during the build only. This is because java is not required except when building form the repository - as soon as a "make dist" has been issued, the tar-ball includes a converted schema. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 9 07:45:37 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 09 Sep 2009 07:45:37 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #24: In-house changes to patch for ticket #20 break the signer engine In-Reply-To: <059.24fcabc8aa9f6ccb8df5df380acbc4eb@kirei.se> References: <059.24fcabc8aa9f6ccb8df5df380acbc4eb@kirei.se> Message-ID: <068.90dbda1079633023cfd085382be42dbb@kirei.se> #24: In-house changes to patch for ticket #20 break the signer engine ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Changes (by matthijs): * status: assigned => closed * resolution: => fixed Comment: restored the line -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Wed Sep 9 09:01:30 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 9 Sep 2009 11:01:30 +0200 Subject: [Opendnssec-develop] getting rid of HSM calls from the communicator Message-ID: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> hi, I suggest we get rid of the only HSM call that we have in the communicator/libksm, the salt generation, and use some other random function instead. generating the salt is not critical and libhsm to this doesn't really help that much. ok? jakob From jakob at kirei.se Wed Sep 9 10:39:38 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 9 Sep 2009 12:39:38 +0200 Subject: [Opendnssec-develop] getting rid of HSM calls from the communicator In-Reply-To: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> Message-ID: <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> On 9 sep 2009, at 11.01, Jakob Schlyter wrote: > I suggest we get rid of the only HSM call that we have in the > communicator/libksm, the salt generation, and use some other random > function instead. generating the salt is not critical and libhsm to > this doesn't really help that much. so I'm saying this code (now used when no HSM is found) is good enough for generating the salt: srand( time(0) ); for (i = 0; i < 2*(policy->denial->saltlength); i++) { salt[i] = hex_chars[rand()%strlen(hex_chars)]; } remember that the salt is published in the zone and does not have to be very random. jakob From rick at openfortress.nl Wed Sep 9 10:48:15 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 9 Sep 2009 10:48:15 +0000 Subject: [Opendnssec-develop] getting rid of HSM calls from the communicator In-Reply-To: <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> Message-ID: <20090909104815.GB436@phantom.vanrein.org> Hi, > remember that the salt is published in the zone and does not have to > be very random. More accurately: it does not have to be a secret. But it is important that it cannot be influenced by an adversary. That's the main reason to use random numbers as salts. -Rick From jakob at kirei.se Wed Sep 9 10:49:56 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 9 Sep 2009 12:49:56 +0200 Subject: [Opendnssec-develop] getting rid of HSM calls from the communicator In-Reply-To: <20090909104815.GB436@phantom.vanrein.org> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <20090909104815.GB436@phantom.vanrein.org> Message-ID: On 9 sep 2009, at 12.48, Rick van Rein wrote: > More accurately: it does not have to be a secret. But it is important > that it cannot be influenced by an adversary. That's the main reason > to use random numbers as salts. right. do you agree that rand() - or maybe arc4random() - is good enough? jakob From rick at openfortress.nl Wed Sep 9 10:57:33 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 9 Sep 2009 10:57:33 +0000 Subject: [Opendnssec-develop] getting rid of HSM calls from the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <20090909104815.GB436@phantom.vanrein.org> Message-ID: <20090909105733.GD436@phantom.vanrein.org> Hi, > >More accurately: it does not have to be a secret. But it is important > >that it cannot be influenced by an adversary. That's the main reason > >to use random numbers as salts. > > right. do you agree that rand() - or maybe arc4random() - is good > enough? I don't object. Using OS calls means that the admin has control over their level of randomness by choosing proper hardware. And it's not as if it is possible to wave a magic wand to get to random material -- not in the digital world, that is. Noise has a preoccupation with analog only. -Rick From roy at nominet.org.uk Wed Sep 9 14:00:07 2009 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 9 Sep 2009 15:00:07 +0100 Subject: [Opendnssec-develop] getting rid of HSM calls from the communicator In-Reply-To: <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> Message-ID: Jakob Schlyter wrote on 09/09/2009 11:39:38 AM: > On 9 sep 2009, at 11.01, Jakob Schlyter wrote: > > > I suggest we get rid of the only HSM call that we have in the > > communicator/libksm, the salt generation, and use some other random > > function instead. generating the salt is not critical and libhsm to > > this doesn't really help that much. > > so I'm saying this code (now used when no HSM is found) is good enough > for generating the salt: > > srand( time(0) ); > for (i = 0; i < 2*(policy->denial->saltlength); i++) { > salt[i] = hex_chars[rand()%strlen(hex_chars)]; > } > > remember that the salt is published in the zone and does not have to > be very random. Speaking as (one of the) authors of RFC5155, the salt has one, but only one function: to complicate enumeration efforts that make use of dictionary containing hash to name mappings (like rainbow tables and the like). If a zone with salt X is largely enumerated and the hash to name mappings are stored in a dictionary, an attacker can skip those hashes already matched when enumerating a new version of the zone, i.e. the enumeration effort becomes incremental. A new salt makes the previous hash to name mapping obsolete. So far the theory, now the practise: The drawback of changing a salt is that the entire zone needs to be re-hashed and re-signed. So in highly dynamic environments or when zones are very large, the cost of changing salt is high as well. The costs really are the resigning effort and distributing the entire zone again. With ixfr, it is even worse, as the old nsec3 chain needs to be removed, and the new nsec3 chain needs to be added. Which basically doubles the load. In general, we'll probably see that salts are not changed regularly, if at all. I'm also seeing that registries which intend to deploy with NSEC3 do that because of the opt-out functionality, not just anti-enumeration. As for opendnssec, we'd need to make sure that automated re-salting is off by default. Preferably ship it with a default salt. It has no implication that the salt is the same for each opendnssec-deployment, since there is no overlap of names that are hashed anyway. That said, I'm completely confident that using the systems default random() function is good enough. Using a HSM for that is just too much. Get rid of it. Kind regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Wed Sep 9 14:12:10 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 9 Sep 2009 15:12:10 +0100 Subject: [Opendnssec-develop] getting rid of HSM calls from the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> Message-ID: > As for opendnssec, we'd need to make sure that automated re-salting > is off by default. Preferably ship it with a default salt. Really?! Would it not be safer to make the salt randomly generated on a per-installation basis? Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Morris at nominet.org.uk Wed Sep 9 16:42:43 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Wed, 9 Sep 2009 17:42:43 +0100 Subject: [Opendnssec-develop] Minutes from Teleconference of 9 September Message-ID: Minutes from today's teleconference are now on the wiki: http://trac.opendnssec.org/wiki/Meetings/Minutes/2009-09-09 Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Thu Sep 10 07:47:12 2009 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 10 Sep 2009 07:47:12 +0000 Subject: [Opendnssec-develop] Comparing times Message-ID: <20090910074712.GB18309@phantom.vanrein.org> Hello all, As mentioned yesterday, I have an idea about how to compare timing, and deal with comparisons of times. It is a bit more complicated than the plain approach, but it _does_ service the idea of a pushbutton, IMHO. Specifications like 1y are vague -- is it 365 days or 366? The core of this question is that we sometimes need the higher value, and sometimes the lower one. We want to make sure not to make a choice that ends up screwing with people's assumptions, or worse, that ends up screwing up a domain's signed state. The idea is simple -- we only use timing for comparisons. Things like "if I add a month, will I fall within the range of the year until rollover"? In comparisons, it is possible to take the cautious approach: if t1 < t2: act_boldly () would become if t1.maximum < t2.minimum: act_boldly () That is, t1 has both its maximum and minimum time added. So if t1 is specified as "1y + 1mo" its minimum would be 365+28 and its maximum would be 366+31. The funny thing is that this means that 1y <= 1y does not hold, nor does 1y < 1y. This is the result of being cautious. Now, how would this look in implementation? Instead of keeping timing in an integer (counting days), it would be kept in a structure with a maximum/minimum field with those integers. When parsing timing, the fields would be filled as said above. def addtm (t1, t2): return { max: t1.max + t2.max, min: t1.min + t2.min } def subtm (t1, t2): return { max: t1.max - t2.min, min: t1.min - t2.max } def less_equal (t1, t2): cmp = subtm (t1, t2) return (cmp.max <= 0) def less (t1, t2): cmp = subtm (t1, t2) return (cmp.max < 0) def equal (t1, t2): # Do we ever need this BTW? cmp = subtm (t1, t2) return (cmp.max == 0 and cmp.min == 0) The advantage of this is that it makes it absolutely impossible for users to assume things we cannot guarantee. For example: - a year comprises of 14 months: 1y = 365..366 and 1mo = 28..31 - a year comprises of 12 periods of 31 days: 1y = 365..366 and 31d = 31..31 This does not happen to answer to user's wishes for refreshes at set dates, I know. It does make it impossible to make false calculations based on assumed period durations though. The disadvantage is that this complicates calculations in a place where they already require a lot of caution. I can imagine that to be a driving force in deciding to abandon this defensive coding approach. Hope this helps, Cheers, -Rick From Antoin.Verschuren at sidn.nl Thu Sep 10 08:51:42 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 10 Sep 2009 10:51:42 +0200 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> Message-ID: <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 It would seem the better option to me too to generate the salt at system installation/first startup. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ > -----Original Message----- > From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec- > develop-bounces at lists.opendnssec.org] On Behalf Of Alexd at nominet.org.uk > Sent: Wednesday, September 09, 2009 4:12 PM > To: Roy Arends > Cc: Opendnssec-develop at lists.opendnssec.org; opendnssec-develop- > bounces at lists.opendnssec.org > Subject: Re: [Opendnssec-develop] getting rid of HSM callsfrom the > communicator > > > As for opendnssec, we'd need to make sure that automated re-salting > > is off by default. Preferably ship it with a default salt. > > Really?! > > Would it not be safer to make the salt randomly generated on a per- > installation basis? > > > Alex. -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSqi+HjqHrM883AgnAQjLnwf/TYpaR1u7vo6SojfatWqpRS8CLwF2ZMKx QfHQr8zuLRCVSCFPmmD0SU/tjc0PnUVc2NlcmIs9KAQJ/jx6Hx/hNJKUdHXg18Rv JEwu67JCMjy7GwAxytnn0hTJZLM58uYQ1rMZjib1S1y2eumXzHX6jKw+87K0iqfI 4C7M5PTqDtW4cSiwNmyWftdDDAyLnruhz7r91hzkA9Nj9cQwgPoDGcA5iyGzMdsz 5/daHxicnKynTRRpJVL27TAABJ6H5hXepTUMOFBlLXpoqFg5CgEYG2pMJGOdX1lB O+ZjxspXD1rsAOGfTS9q1sOtRovqbwMLyAK36z8gmllbeZD/8BOo/Q== =kft3 -----END PGP SIGNATURE----- From roland.vanrijswijk at surfnet.nl Thu Sep 10 08:55:21 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 10 Sep 2009 10:55:21 +0200 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> Message-ID: <4AA8BEF9.3040909@surfnet.nl> +1, a default salt is a bad idea IMHO. Antoin Verschuren wrote: > It would seem the better option to me too to generate the salt at system installation/first startup. > > Antoin Verschuren > > Technical Policy Advisor SIDN > Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands > > P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 > mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ > > >> -----Original Message----- >> From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec- >> develop-bounces at lists.opendnssec.org] On Behalf Of Alexd at nominet.org.uk >> Sent: Wednesday, September 09, 2009 4:12 PM >> To: Roy Arends >> Cc: Opendnssec-develop at lists.opendnssec.org; opendnssec-develop- >> bounces at lists.opendnssec.org >> Subject: Re: [Opendnssec-develop] getting rid of HSM callsfrom the >> communicator > >>> As for opendnssec, we'd need to make sure that automated re-salting >>> is off by default. Preferably ship it with a default salt. >> Really?! > >> Would it not be safer to make the salt randomly generated on a per- >> installation basis? > > >> Alex. ------------------------------------------------------------------------ _______________________________________________ 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 roy at nominet.org.uk Thu Sep 10 09:01:01 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 10 Sep 2009 10:01:01 +0100 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> Message-ID: Antoin Verschuren wrote on 09/10/2009 09:51:42 AM: > It would seem the better option to me too to generate the salt at > system installation/first startup. Why? Kind regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy at nominet.org.uk Thu Sep 10 09:06:17 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 10 Sep 2009 10:06:17 +0100 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: <4AA8BEF9.3040909@surfnet.nl> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <4AA8BEF9.3040909@surfnet.nl> Message-ID: Roland van Rijswijk wrote on 09/10/2009 09:55:21 AM: > +1, a default salt is a bad idea IMHO. Why? Nice that we're voting and all, but some text to back up a decision would be nice Kind regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Thu Sep 10 09:08:33 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 10 Sep 2009 10:08:33 +0100 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> Message-ID: > > It would seem the better option to me too to generate the salt at > > system installation/first startup. > > Why? Would it be easier for an attacker to guess the hashes if he knew the salt? If not, then I suppose it doesn't matter. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Thu Sep 10 09:09:13 2009 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 10 Sep 2009 09:09:13 +0000 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> Message-ID: <20090910090913.GB20185@phantom.vanrein.org> Hi, > > It would seem the better option to me too to generate the salt at > > system installation/first startup. > > Why? Salt is used to make dictionary attacks harder, and the more generic a dictionary can be used, the more likely such an attack becomes. So, in order to be less predictable, salts must be changed as often as is practical, ideally every time before using it. Installing a system with the same salt everywhere is exactly as good as not salting at all. -Rick From roy at nominet.org.uk Thu Sep 10 09:09:24 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 10 Sep 2009 10:09:24 +0100 Subject: [Opendnssec-develop] getting rid of HSM calls from the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> Message-ID: Alex Dalitz/Nominet wrote on 09/09/2009 03:12:10 PM: > > As for opendnssec, we'd need to make sure that automated re-salting > > is off by default. Preferably ship it with a default salt. > > Really?! > > Would it not be safer to make the salt randomly generated on a per- > installation basis? It is possible, yes. But how does a unique salt per installation prevent enumeration compared to the same salt per installation? Kind regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.vanrijswijk at surfnet.nl Thu Sep 10 09:10:37 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 10 Sep 2009 11:10:37 +0200 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <4AA8BEF9.3040909@surfnet.nl> Message-ID: <4AA8C28D.8080203@surfnet.nl> Having a default salt in all OpenDNSSEC installations is bad practice I think, because it would make a dictionary attack on all 'default' OpenDNSSEC installations more feasible. It's trivial to include the generation of a salt in the installation process, so why not do it? Or even better, and still quite simple: why not generate a per zone salt the first time you start signing a zone? I see your argument about having re-sign and re-hash an entire zone by generating new salts for all changes, but let's at least have some differentiation between OpenDNSSEC installations by applying either of the suggestion above. Cheers, Roland Roy Arends wrote: > Roland van Rijswijk wrote on 09/10/2009 09:55:21 AM: > >> +1, a default salt is a bad idea IMHO. > > Why? > > Nice that we're voting and all, but some text to back up a decision > would be nice > > Kind regards, > > Roy Arends > Sr. Researcher > Nominet UK -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From roy at nominet.org.uk Thu Sep 10 09:19:51 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 10 Sep 2009 10:19:51 +0100 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: <20090910090913.GB20185@phantom.vanrein.org> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <20090910090913.GB20185@phantom.vanrein.org> Message-ID: Rick van Rein wrote on 09/10/2009 10:09:13 AM: > Salt is used to make dictionary attacks harder, and the more generic > a dictionary can be used, the more likely such an attack becomes. The input to the hash function is unique per deployment, regardless if everyone uses the same salt. > So, in order to be less predictable, salts must be changed as often > as is practical, In order to change it, you'd need to have a salt first. And that salt can be the same for everyone. The changing over time needs to be a change from the _previous_ salt. > ideally every time before using it. Again, why _before_ using it? > Installing a system with the same salt everywhere is exactly as good > as not salting at all. Right. The same is true for the same salt every. Only when you change the salt, salting becomes valuable. Kind regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Thu Sep 10 09:24:11 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 10 Sep 2009 10:24:11 +0100 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> Message-ID: > Would it be easier for an attacker to guess the hashes if he knew > the salt? Whoops! It's in the NSEC3PARAM record anyway... *blush* I guess it doesn't matter. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy at nominet.org.uk Thu Sep 10 09:41:09 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 10 Sep 2009 10:41:09 +0100 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: <4AA8C28D.8080203@surfnet.nl> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <4AA8BEF9.3040909@surfnet.nl> <4AA8C28D.8080203@surfnet.nl> Message-ID: Roland van Rijswijk wrote on 09/10/2009 10:10:37 AM: > Having a default salt in all OpenDNSSEC installations is bad practice I > think, because it would make a dictionary attack on all 'default' > OpenDNSSEC installations more feasible. This is false. 1) The salt is publicized in the NSEC3 record. 2) If you want to deploy a dictionary attack on surfnet.nl's zone you'd have to build the dictionary first, regardless of salting. 3) The dictionary build for surfnet.nl is completely useless for openfortress.nl, eventhough both use the _exact_ same salt. 4) if surfnet.nl _changes_ the default salt, the dictionary built for surfnet.nl becomes obsolete, and a new dictionary needs to be build Step 4 is the reason we introduced salts. fwiw, you still haven't explained why it is 'more feasible' > It's trivial to include the > generation of a salt in the installation process, so why not do it? Or > even better, and still quite simple: why not generate a per zone salt > the first time you start signing a zone? To be clear, the default (well, the example xml) already specifies a random salt, of length 8, and resalts every 100 days. > I see your argument about having re-sign and re-hash an entire zone by > generating new salts for all changes, but let's at least have some > differentiation between OpenDNSSEC installations by applying either of > the suggestion above The only security gain we get from random-salt-per-install is that deployments can't be remotely identified as OpenDNSSEC. (which can also be seen as a marketing loss) However, this has nothing to do with the cryptography of DNSSEC. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.vanrijswijk at surfnet.nl Thu Sep 10 09:45:16 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 10 Sep 2009 11:45:16 +0200 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <4AA8BEF9.3040909@surfnet.nl> <4AA8C28D.8080203@surfnet.nl> Message-ID: <4AA8CAAC.2090708@surfnet.nl> Hi Roy, Roy Arends wrote: > Roland van Rijswijk wrote on 09/10/2009 > 10:10:37 AM: > >> Having a default salt in all OpenDNSSEC installations is bad practice I >> think, because it would make a dictionary attack on all 'default' >> OpenDNSSEC installations more feasible. > > This is false. Not necessarily true, since all zones will have similar records in them like 'www', 'smtp', 'ns', 'mail', etc., right? > 3) The dictionary build for surfnet.nl is completely useless for > openfortress.nl, eventhough both use the _exact_ same salt. What if the above holds and we have remarkably similar structures? I have a whole host of domains that are set up using a template containing well known regards. This - of course - doesn't hold if the FQDN is the input for the hash, but I haven't checked that, is that the case? > To be clear, the default (well, the example xml) already specifies a > random salt, of length 8, and resalts every 100 days. > >> I see your argument about having re-sign and re-hash an entire zone by >> generating new salts for all changes, but let's at least have some >> differentiation between OpenDNSSEC installations by applying either of >> the suggestion above > > The only security gain we get from random-salt-per-install is that > deployments can't be remotely identified as OpenDNSSEC. (which can also > be seen as a marketing loss) However, this has nothing to do with the > cryptography of DNSSEC. LOL, marketing losses are of course bad. Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From roy at nominet.org.uk Thu Sep 10 10:01:05 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 10 Sep 2009 11:01:05 +0100 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: <4AA8CAAC.2090708@surfnet.nl> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <4AA8BEF9.3040909@surfnet.nl> <4AA8C28D.8080203@surfnet.nl> <4AA8CAAC.2090708@surfnet.nl> Message-ID: Roland van Rijswijk wrote on 09/10/2009 10:45:16 AM: > >> Having a default salt in all OpenDNSSEC installations is bad practice I > >> think, because it would make a dictionary attack on all 'default' > >> OpenDNSSEC installations more feasible. > > > > This is false. > > Not necessarily true, since all zones will have similar records in them > like 'www', 'smtp', 'ns', 'mail', etc., right? > > > 3) The dictionary build for surfnet.nl is completely useless for > > openfortress.nl, eventhough both use the _exact_ same salt. > > What if the above holds and we have remarkably similar structures? I > have a whole host of domains that are set up using a template containing > well known regards. If it results in remarkably similar structures, the hash function is broken, as each pre-image will be unique per fully qualified domain name. Also the zone structure will not be influenced by the salt. > This - of course - doesn't hold if the FQDN is the input for the hash, > but I haven't checked that, is that the case? That is the case > > To be clear, the default (well, the example xml) already specifies a > > random salt, of length 8, and resalts every 100 days. > > > >> I see your argument about having re-sign and re-hash an entire zone by > >> generating new salts for all changes, but let's at least have some > >> differentiation between OpenDNSSEC installations by applying either of > >> the suggestion above > > > > The only security gain we get from random-salt-per-install is that > > deployments can't be remotely identified as OpenDNSSEC. (which can also > > be seen as a marketing loss) However, this has nothing to do with the > > cryptography of DNSSEC. > > LOL, marketing losses are of course bad. :-) Kind regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.vanrijswijk at surfnet.nl Thu Sep 10 10:09:44 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 10 Sep 2009 12:09:44 +0200 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <4AA8BEF9.3040909@surfnet.nl> <4AA8C28D.8080203@surfnet.nl> <4AA8CAAC.2090708@surfnet.nl> Message-ID: <4AA8D068.6050406@surfnet.nl> Hi Roy, Roy Arends wrote: > If it results in remarkably similar structures, the hash function is > broken, as each pre-image will be unique per fully qualified domain > name. Also the zone structure will not be influenced by the salt. > >> This - of course - doesn't hold if the FQDN is the input for the hash, >> but I haven't checked that, is that the case? > > That is the case In that case I don't object anymore. It should - however - be made clear to users what choices they have and what the tradeoffs are, so perhaps some lines about this in the documentation are in order ;-) Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From Antoin.Verschuren at sidn.nl Thu Sep 10 11:02:19 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 10 Sep 2009 13:02:19 +0200 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <4AA8BEF9.3040909@surfnet.nl> <4AA8C28D.8080203@surfnet.nl> <4AA8CAAC.2090708@surfnet.nl> <4AA8D068.6050406@surfnet.nl> Message-ID: <850A39016FA57A4887C0AA3C8085F949011B740B@KAEVS1.SIDN.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 With Roy's explanation, I also don't see any objections anymore, apart from the fact that advising to periodically changing your salt as BCP is less convincing if we ship all software with the same salt. That's not a security issue however, but more an operational issue. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ > -----Original Message----- > From: Roland van Rijswijk [mailto:roland.vanrijswijk at surfnet.nl] > Sent: Thursday, September 10, 2009 12:10 PM > To: Roy Arends > Cc: Antoin Verschuren; Opendnssec-develop at lists.opendnssec.org > Subject: Re: [Opendnssec-develop] getting rid of HSM callsfrom the > communicator > > Hi Roy, > > Roy Arends wrote: > > If it results in remarkably similar structures, the hash function is > > broken, as each pre-image will be unique per fully qualified domain > > name. Also the zone structure will not be influenced by the salt. > > > >> This - of course - doesn't hold if the FQDN is the input for the hash, > >> but I haven't checked that, is that the case? > > > > That is the case > > In that case I don't object anymore. > > It should - however - be made clear to users what choices they have and > what the tradeoffs are, so perhaps some lines about this in the > documentation are in order ;-) > > Cheers, > > Roland > > -- > -- Roland M. van Rijswijk > -- SURFnet Middleware Services > -- t: +31-30-2305388 > -- e: roland.vanrijswijk at surfnet.nl -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSqjcuzqHrM883AgnAQjuKgf+L2VJQFI/sWzmUArShlsk2HBKdp+y/FEV 4DiJja8R1loZ588msZTFRSGd8Rx0naUEofF5Aof3X4WI3JSEwll8rVPuG6dY686B M3Bgzygad4a5HGgFcQgXBVWwNNk5oPWt/Y3qqn6tos6ipxnjahfWjwdiEh381VMF qU5qYA04d4TVZavwfM+VNgi8g7omc7tOuOnE1A+YGDaqh7C6iDbUn6Sm7P+Fjzl/ vS6KrOy8ZGaUqBJ05SJsiXY5tHbnH4FBO9n4MLUyPaT6oc9reG0TrP6qbsYsyylv UZJRONDvJcohiYY7yYUbO9nPO4L0NF3sH9IJ8RhslmIDioFZlA4CqA== =khTI -----END PGP SIGNATURE----- From jakob at kirei.se Thu Sep 10 12:35:17 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 10 Sep 2009 14:35:17 +0200 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <4AA8BEF9.3040909@surfnet.nl> <4AA8C28D.8080203@surfnet.nl> Message-ID: <7C265F98-9FE7-41F2-BACF-F2BFDB31564C@kirei.se> hej, On 10 sep 2009, at 11.41, Roy Arends wrote: > To be clear, the default (well, the example xml) already specifies a > random salt, of length 8, and resalts every 100 days. I agree with Roy here, but I see no point in changing this at this time - it would just confuse people. jakob From roy at nominet.org.uk Thu Sep 10 13:09:33 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 10 Sep 2009 14:09:33 +0100 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: <7C265F98-9FE7-41F2-BACF-F2BFDB31564C@kirei.se> References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <4AA8BEF9.3040909@surfnet.nl> <4AA8C28D.8080203@surfnet.nl> <7C265F98-9FE7-41F2-BACF-F2BFDB31564C@kirei.se> Message-ID: Jakob Schlyter wrote on 09/10/2009 01:35:17 PM: > On 10 sep 2009, at 11.41, Roy Arends wrote: > > > To be clear, the default (well, the example xml) already specifies a > > random salt, of length 8, and resalts every 100 days. > > I agree with Roy here, but I see no point in changing this at this > time - it would just confuse people. Thanks Jakob, lets stick with these defaults then. As for the original topic (my apologies for digressing), I have no issue with using a system's own default random() function to replace the remaining call. Kind regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From Patrik.Wallstrom at iis.se Fri Sep 11 12:09:16 2009 From: Patrik.Wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Fri, 11 Sep 2009 14:09:16 +0200 Subject: [Opendnssec-develop] error compiling trunk... Message-ID: Has any of you seen this? make[2]: Entering directory `/home/pawal/src/opendnssec/trunk/ OpenDNSSEC/enforcer/keygend' gcc -DHAVE_CONFIG_H -I. -I../common -I./../common -I./../common - I./../ksm/include -I./../ksm/include -I/home/pawal/src/opendnssec/ trunk/OpenDNSSEC/enforcer/../libhsm/src -I/usr/include/libxml2 -I/usr/ local/include -g -O2 -pedantic -Wall -Wextra -MT keygend.o -MD -MP - MF .deps/keygend.Tpo -c -o keygend.o keygend.c mv -f .deps/keygend.Tpo .deps/keygend.Po /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -pedantic - Wall -Wextra -o keygend keygend.o ../common/libenforcer.a ../ksm/ libksm.a -lxml2 -L/usr/local/lib -lsqlite3 -L../../libhsm/src/.libs - lhsm libtool: link: gcc -g -O2 -pedantic -Wall -Wextra -o keygend keygend.o ../common/libenforcer.a ../ksm/libksm.a /usr/lib/libxml2.so -L/usr/local/lib /usr/lib/libsqlite3.so -L/home/pawal/src/opendnssec/ trunk/OpenDNSSEC/libhsm/src/.libs /usr/local/lib/libhsm.so keygend.o: In function `server_main': /home/pawal/src/opendnssec/trunk/OpenDNSSEC/enforcer/keygend/keygend.c: 300: undefined reference to `hsm_get_error' /home/pawal/src/opendnssec/trunk/OpenDNSSEC/enforcer/keygend/keygend.c: 312: undefined reference to `hsm_get_error' /home/pawal/src/opendnssec/trunk/OpenDNSSEC/enforcer/keygend/keygend.c: 136: undefined reference to `hsm_get_error' collect2: ld returned 1 exit status make[2]: *** [keygend] Error 1 make[2]: Leaving directory `/home/pawal/src/opendnssec/trunk/ OpenDNSSEC/enforcer/keygend' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/pawal/src/opendnssec/trunk/ OpenDNSSEC/enforcer' make: *** [all-recursive] Error 1 -- 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 Patrik.Wallstrom at iis.se Fri Sep 11 12:17:58 2009 From: Patrik.Wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Fri, 11 Sep 2009 14:17:58 +0200 Subject: [Opendnssec-develop] error compiling trunk... In-Reply-To: References: Message-ID: <7C4FF23E-23F3-430B-9260-35D2A0739046@iis.se> On Sep 11, 2009, at 2:09 PM, Patrik Wallstr?m wrote: > Has any of you seen this? Solved it by installing libhsm separately, and then compiling again... -- 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 Patrik.Wallstrom at iis.se Fri Sep 11 19:31:11 2009 From: Patrik.Wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Fri, 11 Sep 2009 21:31:11 +0200 Subject: [Opendnssec-develop] performance Message-ID: I am testing to sign a 1000 domains. Having found the major performance issue in SoftHSM I found out that the signing of 1000 domains takes forever. I guess that there is a lot of sleeping going on. Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 6 acquiring lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 6 acquired lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 6 released lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: Got task for worker 6 Sep 11 21:28:19 mask OpenDNSSEC signer engine: Worker 6 run task Sep 11 21:28:19 mask OpenDNSSEC signer engine: Zone action to perform: 6 Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 7 acquiring lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 7 acquired lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 7, sleep for 22.8428030014 Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 7 released lock by going to wait (for ttime) Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 8 acquiring lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 8 acquired lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 8, sleep for 22.8425970078 Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 8 released lock by going to wait (for ttime) Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 5 acquiring lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 5 acquired lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 5, sleep for 22.8424079418 Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 5 released lock by going to wait (for ttime) Sep 11 21:28:19 mask OpenDNSSEC signer engine: Run command: '/usr/ local/libexec/opendnssec/signer -c /etc/opendnssec/conf.xml -p /var/ opendnssec/tmp/459manyzones.signed -w /var/opendnssec/tmp/ 459manyzones.signed2 -r' Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 1 acquiring lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 1 acquired lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 1, sleep for 22.8420629501 Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 1 released lock by going to wait (for ttime) Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 3 acquiring lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 3 acquired lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 3, sleep for 22.8418889046 Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 3 released lock by going to wait (for ttime) Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 4 acquiring lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 4 acquired lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 4, sleep for 22.841711998 Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 4 released lock by going to wait (for ttime) Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 2 acquiring lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 2 acquired lock Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 2, sleep for 22.8298828602 Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 2 released lock by going to wait (for ttime) Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :origin 459manyzones Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :soa_ttl 3600 Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :soa_minimum 3600 Sep 11 21:28:19 mask OpenDNSSEC signer engine: set serial to 1252697299 Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :expiration 20090918192819 Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :expiration_denial 20090918192819 Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :jitter 43200 Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :inception 20090911192319 Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :refresh 20090915192819 Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :refresh_denial 20090915192819 Sep 11 21:28:19 mask OpenDNSSEC signer engine: use signature key: a1724d88fbb45b1142ff5bdde3e3f385 Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :add_ksk a1724d88fbb45b1142ff5bdde3e3f385 7 257 Sep 11 21:28:19 mask OpenDNSSEC signer engine: use signature key: 53305ef26679e5467409d8fbe68e8b17 Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :add_zsk 53305ef26679e5467409d8fbe68e8b17 7 256 Sep 11 21:28:20 mask communicated: INFO: Promoting ZSK from publish to active as this is the first pass for the zone Sep 11 21:28:21 mask communicated: WARNING: Making non-backed up ZSK active, PLEASE make sure that you know the potential problems of using keys which are not recoverable Sep 11 21:28:22 mask keygend: /var/opendnssec/kasp.db.our_lock already locked, sleep Sep 11 21:28:25 mask OpenDNSSEC signer engine: signer stderr: signer: number of signatures created: 1 (0 rr/sec) Sep 11 21:28:25 mask OpenDNSSEC signer engine: No new signatures, keeping zone Sep 11 21:28:25 mask OpenDNSSEC signer engine: worker 6 acquiring lock Sep 11 21:28:25 mask OpenDNSSEC signer engine: worker 6 acquired lock Sep 11 21:28:25 mask OpenDNSSEC signer engine: no task for worker 6, sleep for 16.4016799927 Sep 11 21:28:25 mask OpenDNSSEC signer engine: worker 6 released lock by going to wait (for ttime) Sep 11 21:28:28 mask OpenDNSSEC signer engine: Received command: 'update 670manyzones' Sep 11 21:28:28 mask OpenDNSSEC signer engine: Zone 670manyzones locked Sep 11 21:28:28 mask OpenDNSSEC signer engine: Scheduling task to sign zone 670manyzones at 1252678193.9 with resign time 7200 Sep 11 21:28:28 mask OpenDNSSEC signer engine: acquire cond Sep 11 21:28:28 mask OpenDNSSEC signer engine: notify Sep 11 21:28:28 mask OpenDNSSEC signer engine: release cond Sep 11 21:28:28 mask OpenDNSSEC signer engine: Releasing lock on zone 670manyzones Sep 11 21:28:28 mask OpenDNSSEC signer engine: Scheduling task to sign zone 670manyzones at 1252678193.9 with resign time 7200 Sep 11 21:28:28 mask OpenDNSSEC signer engine: acquire cond Sep 11 21:28:28 mask OpenDNSSEC signer engine: notify Sep 11 21:28:28 mask OpenDNSSEC signer engine: release cond Sep 11 21:28:28 mask OpenDNSSEC signer engine: acquire cond Sep 11 21:28:28 mask OpenDNSSEC signer engine: notify Sep 11 21:28:28 mask OpenDNSSEC signer engine: release cond Sep 11 21:28:28 mask OpenDNSSEC signer engine: Releasing lock on engine Sep 11 21:28:28 mask OpenDNSSEC signer engine: Sending response: Zone now has config#012 Sep 11 21:28:28 mask OpenDNSSEC signer engine: Done handling command Sep 11 21:28:28 mask OpenDNSSEC signer engine: Connection closed by peer Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 5 acquiring lock Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 5 acquired lock Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 5 released lock Sep 11 21:28:28 mask OpenDNSSEC signer engine: Got task for worker 5 Sep 11 21:28:28 mask OpenDNSSEC signer engine: Worker 5 run task Sep 11 21:28:28 mask OpenDNSSEC signer engine: Zone action to perform: 3 Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 8 acquiring lock Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 3 acquiring lock Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 3 acquired lock Sep 11 21:28:28 mask OpenDNSSEC signer engine: no task for worker 3, sleep for 13.7042028904 Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 3 released lock by going to wait (for ttime) Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 1 acquiring lock Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 1 acquired lock Sep 11 21:28:28 mask OpenDNSSEC signer engine: no task for worker 1, sleep for 13.7039978504 Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 1 released lock by going to wait (for ttime) Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 7 acquiring lock Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 7 acquired lock So this is what I get timing wise: -rw-r--r-- 1 root root 10591 2009-09-11 21:14 647manyzones -rw-r--r-- 1 root root 10591 2009-09-11 21:14 648manyzones -rw-r--r-- 1 root root 10588 2009-09-11 21:15 649manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:15 650manyzones -rw-r--r-- 1 root root 10591 2009-09-11 21:16 651manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:17 652manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:17 653manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:18 654manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:19 655manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:19 656manyzones -rw-r--r-- 1 root root 10617 2009-09-11 21:20 657manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:21 658manyzones -rw-r--r-- 1 root root 10591 2009-09-11 21:21 659manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:22 660manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:23 661manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:23 662manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:24 663manyzones -rw-r--r-- 1 root root 10617 2009-09-11 21:24 664manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:25 665manyzones -rw-r--r-- 1 root root 10591 2009-09-11 21:26 666manyzones -rw-r--r-- 1 root root 10617 2009-09-11 21:26 667manyzones -rw-r--r-- 1 root root 10617 2009-09-11 21:27 668manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:28 669manyzones -rw-r--r-- 1 root root 10618 2009-09-11 21:28 670manyzones -rw-r--r-- 1 root root 10591 2009-09-11 21:29 671manyzones 1.5 domains per minute is not very good. -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From jakob at kirei.se Fri Sep 11 21:00:09 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 11 Sep 2009 23:00:09 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-user] Problems compiling trunk In-Reply-To: References: Message-ID: <15DB6ADC-6D08-422D-9B17-673956D07B13@kirei.se> On 11 sep 2009, at 18.35, Antti Ristim?ki wrote: > I'm trying to install the latest trunk, but facing some problems > when compiling. At least the following error messages seem to be > related to this problem: > > /root/trunk/OpenDNSSEC/enforcer/keygend/keygend.c:136: undefined > reference to `hsm_get_error' > /root/trunk/OpenDNSSEC/enforcer/keygend/keygend.c:250: undefined > reference to `hsm_get_error' > > I reverted the keygend.c back to revision 1767, after which I was > able to compile the program. it seems that even though the enforcer is set to link with the libhsm in the build tree, it ends up trying to link with the installed libhsm. don't we just love dynamic linking? jakob From owner-dnssec-trac at kirei.se Mon Sep 14 05:37:36 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 14 Sep 2009 05:37:36 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #25: Could ksmutil print the key_id Message-ID: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> #25: Could ksmutil print the key_id ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: sion Type: enhancement | Status: new Priority: minor | Component: Enforcer Version: | Keywords: ----------------------------------+----------------------------------------- The output of the signed zone before 'finalizer' adds the key_id to each DNSKEY added to the zone. When you call 'ksmutil list' shows the list of keys being used and their type, but the key_id is not shown. This would be useful for testing and debugging purposes. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 14 06:10:14 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 14 Sep 2009 06:10:14 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #25: Could ksmutil print the key_id In-Reply-To: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> References: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> Message-ID: <068.f5c5a380a612edf037feded63b8c1811@kirei.se> #25: Could ksmutil print the key_id ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: jakob Type: enhancement | Status: accepted Priority: minor | Component: Enforcer Version: | Resolution: Keywords: | ----------------------------------+----------------------------------------- Changes (by jakob): * owner: sion => jakob * status: new => accepted Comment: have you tried {{{ksmutil -l list keys}}} ? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 14 08:42:29 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 14 Sep 2009 08:42:29 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #26: Signer (or communicated) gets very slow with many zones Message-ID: <043.3e06d24187eff497c818ae327e7a67e4@kirei.se> #26: Signer (or communicated) gets very slow with many zones -------------------+-------------------------------------------------------- Reporter: pawal | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: | Keywords: -------------------+-------------------------------------------------------- As I said during the weekend, the signer seems slow with many zones. This is approximately what happens. I don't have SharedKeys enabled (this will be my next test). I have 1000 zones which I add using the ksmutil addzone command. I do this very rapidly. 1) keygend creates a lot of keys (8000). This is faster now after I added the index to the SoftHSM database. 2) after 1) the signer begins to sign zones. At first this is pretty fast, On this machines, fast means six zones per minute. However, this performance does gradually become much worse, the last zones takes about one minute each to sign. 3) after 2) trying to look at keys and zones using this: mask:/var/opendnssec/signed# ksmutil export ds 992manyzones SQLite database set to: /var/opendnssec/kasp.db ^C mask:/var/opendnssec/signed# ksmutil list keys 992manyzones SQLite database set to: /var/opendnssec/kasp.db /var/opendnssec/kasp.db.our_lock already locked, sleep ...is pretty much impossible. The kasp.db is always locked by the communicated process. So my guess is that communicated is the process that is having the performance problems. By looking into it using strace, I believe communicated gets very slow when writing to the kasp.dp, but I don't really know what it is writing. -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Mon Sep 14 08:46:24 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 14 Sep 2009 10:46:24 +0200 Subject: [Opendnssec-develop] performance In-Reply-To: References: Message-ID: <4AAE02E0.7070100@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another guess is that the signer engine is file based. More files in a directory slows down the engine, see the story in the icebox (story id 846640) Matthijs Patrik Wallstr?m wrote: > I am testing to sign a 1000 domains. Having found the major > performance issue in SoftHSM I found out that the signing of 1000 > domains takes forever. I guess that there is a lot of sleeping going on. > > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 6 acquiring lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 6 acquired lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 6 released lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: Got task for worker 6 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: Worker 6 run task > Sep 11 21:28:19 mask OpenDNSSEC signer engine: Zone action to perform: 6 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 7 acquiring lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 7 acquired lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 7, > sleep for 22.8428030014 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 7 released lock > by going to wait (for ttime) > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 8 acquiring lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 8 acquired lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 8, > sleep for 22.8425970078 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 8 released lock > by going to wait (for ttime) > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 5 acquiring lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 5 acquired lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 5, > sleep for 22.8424079418 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 5 released lock > by going to wait (for ttime) > Sep 11 21:28:19 mask OpenDNSSEC signer engine: Run command: '/usr/ > local/libexec/opendnssec/signer -c /etc/opendnssec/conf.xml -p /var/ > opendnssec/tmp/459manyzones.signed -w /var/opendnssec/tmp/ > 459manyzones.signed2 -r' > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 1 acquiring lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 1 acquired lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 1, > sleep for 22.8420629501 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 1 released lock > by going to wait (for ttime) > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 3 acquiring lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 3 acquired lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 3, > sleep for 22.8418889046 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 3 released lock > by going to wait (for ttime) > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 4 acquiring lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 4 acquired lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 4, > sleep for 22.841711998 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 4 released lock > by going to wait (for ttime) > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 2 acquiring lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 2 acquired lock > Sep 11 21:28:19 mask OpenDNSSEC signer engine: no task for worker 2, > sleep for 22.8298828602 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: worker 2 released lock > by going to wait (for ttime) > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :origin > 459manyzones > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :soa_ttl > 3600 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to > subp: :soa_minimum 3600 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: set serial to 1252697299 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to > subp: :expiration 20090918192819 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to > subp: :expiration_denial 20090918192819 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :jitter > 43200 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to > subp: :inception 20090911192319 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :refresh > 20090915192819 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to > subp: :refresh_denial 20090915192819 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: use signature key: > a1724d88fbb45b1142ff5bdde3e3f385 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :add_ksk > a1724d88fbb45b1142ff5bdde3e3f385 7 257 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: use signature key: > 53305ef26679e5467409d8fbe68e8b17 > Sep 11 21:28:19 mask OpenDNSSEC signer engine: write to subp: :add_zsk > 53305ef26679e5467409d8fbe68e8b17 7 256 > Sep 11 21:28:20 mask communicated: INFO: Promoting ZSK from publish to > active as this is the first pass for the zone > Sep 11 21:28:21 mask communicated: WARNING: Making non-backed up ZSK > active, PLEASE make sure that you know the potential problems of using > keys which are not recoverable > Sep 11 21:28:22 mask keygend: /var/opendnssec/kasp.db.our_lock already > locked, sleep > Sep 11 21:28:25 mask OpenDNSSEC signer engine: signer stderr: signer: > number of signatures created: 1 (0 rr/sec) > Sep 11 21:28:25 mask OpenDNSSEC signer engine: No new signatures, > keeping zone > Sep 11 21:28:25 mask OpenDNSSEC signer engine: worker 6 acquiring lock > Sep 11 21:28:25 mask OpenDNSSEC signer engine: worker 6 acquired lock > Sep 11 21:28:25 mask OpenDNSSEC signer engine: no task for worker 6, > sleep for 16.4016799927 > Sep 11 21:28:25 mask OpenDNSSEC signer engine: worker 6 released lock > by going to wait (for ttime) > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Received command: > 'update 670manyzones' > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Zone 670manyzones locked > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Scheduling task to sign > zone 670manyzones at 1252678193.9 with resign time 7200 > Sep 11 21:28:28 mask OpenDNSSEC signer engine: acquire cond > Sep 11 21:28:28 mask OpenDNSSEC signer engine: notify > Sep 11 21:28:28 mask OpenDNSSEC signer engine: release cond > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Releasing lock on zone > 670manyzones > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Scheduling task to sign > zone 670manyzones at 1252678193.9 with resign time 7200 > Sep 11 21:28:28 mask OpenDNSSEC signer engine: acquire cond > Sep 11 21:28:28 mask OpenDNSSEC signer engine: notify > Sep 11 21:28:28 mask OpenDNSSEC signer engine: release cond > Sep 11 21:28:28 mask OpenDNSSEC signer engine: acquire cond > Sep 11 21:28:28 mask OpenDNSSEC signer engine: notify > Sep 11 21:28:28 mask OpenDNSSEC signer engine: release cond > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Releasing lock on engine > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Sending response: Zone > now has config#012 > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Done handling command > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Connection closed by peer > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 5 acquiring lock > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 5 acquired lock > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 5 released lock > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Got task for worker 5 > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Worker 5 run task > Sep 11 21:28:28 mask OpenDNSSEC signer engine: Zone action to perform: 3 > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 8 acquiring lock > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 3 acquiring lock > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 3 acquired lock > Sep 11 21:28:28 mask OpenDNSSEC signer engine: no task for worker 3, > sleep for 13.7042028904 > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 3 released lock > by going to wait (for ttime) > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 1 acquiring lock > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 1 acquired lock > Sep 11 21:28:28 mask OpenDNSSEC signer engine: no task for worker 1, > sleep for 13.7039978504 > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 1 released lock > by going to wait (for ttime) > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 7 acquiring lock > Sep 11 21:28:28 mask OpenDNSSEC signer engine: worker 7 acquired lock > > So this is what I get timing wise: > > -rw-r--r-- 1 root root 10591 2009-09-11 21:14 647manyzones > -rw-r--r-- 1 root root 10591 2009-09-11 21:14 648manyzones > -rw-r--r-- 1 root root 10588 2009-09-11 21:15 649manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:15 650manyzones > -rw-r--r-- 1 root root 10591 2009-09-11 21:16 651manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:17 652manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:17 653manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:18 654manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:19 655manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:19 656manyzones > -rw-r--r-- 1 root root 10617 2009-09-11 21:20 657manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:21 658manyzones > -rw-r--r-- 1 root root 10591 2009-09-11 21:21 659manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:22 660manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:23 661manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:23 662manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:24 663manyzones > -rw-r--r-- 1 root root 10617 2009-09-11 21:24 664manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:25 665manyzones > -rw-r--r-- 1 root root 10591 2009-09-11 21:26 666manyzones > -rw-r--r-- 1 root root 10617 2009-09-11 21:26 667manyzones > -rw-r--r-- 1 root root 10617 2009-09-11 21:27 668manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:28 669manyzones > -rw-r--r-- 1 root root 10618 2009-09-11 21:28 670manyzones > -rw-r--r-- 1 root root 10591 2009-09-11 21:29 671manyzones > > 1.5 domains per minute is not very good. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKrgLdAAoJEA8yVCPsQCW51KkIAMJ9i8U0h30dKxjR1iZqlXZU Q99yrr83dIsdfHOnDh5jyz4MDr0dk/o8eZDTv/NuF0CZ2TwlqqtGq3/sHPioFHVG C3iRGJAgKtttS9n5qAmVr/qGO3AEZCi2kwMBw+U12PoZQX4cnoJNpusHoPRCCHJ2 a4O8HUklDstsQ05fcEiEOVlFw8tIfKcXAVEAZlYeAhJAY8mqTPZ4DLMdSeEXodfE ToME2BW2Cilb7I+exRQLqGsD8w7dmz/3p6cq5BZdOZ5QhGAdHhWR02y0FQXAGBWS qdAugwgTjO8g6PS8QPhTzFWRpqqqW1Z7PXrc1oN95Rp/7o/yZlsjHuSt/6iETk8= =d05V -----END PGP SIGNATURE----- From patrik.wallstrom at iis.se Mon Sep 14 08:57:05 2009 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Mon, 14 Sep 2009 10:57:05 +0200 Subject: [Opendnssec-develop] performance In-Reply-To: <4AAE02E0.7070100@nlnetlabs.nl> References: <4AAE02E0.7070100@nlnetlabs.nl> Message-ID: <33710725-A681-4CE9-AF51-B197FB94FD9C@iis.se> On Sep 14, 2009, at 10:46 AM, Matthijs Mekking wrote: > Another guess is that the signer engine is file based. More files in a > directory slows down the engine, see the story in the icebox (story id > 846640) Maybe - but even if you stat() each file, it wouldn't really take more than a minute to do it for 1000 files, would it? I think it is more related to the kasp.db somehow. Since the first domains (in the fully populated directory) is more quicker to sign than the last domains. -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From owner-dnssec-trac at kirei.se Mon Sep 14 21:41:38 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 14 Sep 2009 21:41:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #25: Could ksmutil print the key_id In-Reply-To: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> References: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> Message-ID: <068.43a36ab3df82e5438bd07abc23d57041@kirei.se> #25: Could ksmutil print the key_id ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: jakob Type: enhancement | Status: accepted Priority: minor | Component: Enforcer Version: | Resolution: Keywords: | ----------------------------------+----------------------------------------- Comment(by sebastian at nzrs.net.nz): Thanks, that's useful. But I was thinking about the key_id that is included in the signed zone as a comment (usually a integer on the range 0 .. 65535 if I'm not wrong). On the zone, a comment like this is included ;{id = 23784 (zsk), size = 1024b} But from your command is not straightforward to find which key represents: co.nz ZSK active 2009-09-16 11:22:18 cf48cd9b54c966ae1601f4e46ce498e9 softHSM co.nz ZSK ready next rollover 4c54815bcb4fe35fb06b5c6e27cf48fb softHSM -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 15 06:00:43 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 15 Sep 2009 06:00:43 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #27: New placeholder for NotifyCommand Message-ID: <059.8f2dc0b9bcc95354b2168296b3756b48@kirei.se> #27: New placeholder for NotifyCommand ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: enhancement | Status: new Priority: minor | Component: Signer Version: | Keywords: ----------------------------------+----------------------------------------- While checking the signer_engine to find how the NotifyCommand value from the conf.xml file is used, I noticed there is a placeholder called "%zone" that can be used to provide the notify command with the name of the zone. That feature is not described on the current annotated configuration file. To make it more useful, I added a second placeholder called %zonefile, that contains the name of the output zone file after signing. With this, a notify command can check if the zone generated is good and reload it (thinking in BIND would be named-checkzone and rndc reload). Please find the patch attached. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 15 07:13:28 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 15 Sep 2009 07:13:28 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #25: Could ksmutil print the key_id In-Reply-To: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> References: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> Message-ID: <068.69825c2cc9e82e4fddadd5a728cb7ad8@kirei.se> #25: Could ksmutil print the key_id ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: sion Type: enhancement | Status: assigned Priority: minor | Component: Enforcer Version: | Resolution: Keywords: | ----------------------------------+----------------------------------------- Changes (by jakob): * owner: jakob => sion * status: accepted => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 15 07:18:17 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 15 Sep 2009 07:18:17 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #26: Signer (or communicated) gets very slow with many zones In-Reply-To: <043.3e06d24187eff497c818ae327e7a67e4@kirei.se> References: <043.3e06d24187eff497c818ae327e7a67e4@kirei.se> Message-ID: <052.20ccf2676f677c279919f41df85c683a@kirei.se> #26: Signer (or communicated) gets very slow with many zones -------------------+-------------------------------------------------------- Reporter: pawal | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: | Resolution: Keywords: | -------------------+-------------------------------------------------------- Comment(by pawal): Replying to [ticket:26 pawal]: > As I said during the weekend, the signer seems slow with many zones. After some more testing... it is not slow when using SharedKeys. So the issue is many zones with many keys only. However, the signer with many zones is not really optimized anyway. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 15 07:49:46 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 15 Sep 2009 07:49:46 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #27: New placeholder for NotifyCommand In-Reply-To: <059.8f2dc0b9bcc95354b2168296b3756b48@kirei.se> References: <059.8f2dc0b9bcc95354b2168296b3756b48@kirei.se> Message-ID: <068.bccf2ed8597cfca3d8e79ded29920dce@kirei.se> #27: New placeholder for NotifyCommand ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: matthijs Type: enhancement | Status: closed Priority: minor | Component: Signer Version: | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Changes (by jakob): * status: new => closed * resolution: => fixed Comment: Thank you. Committed as r1808. -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Tue Sep 15 12:09:05 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 15 Sep 2009 14:09:05 +0200 Subject: [Opendnssec-develop] Inbound AXFR design Message-ID: <4AAF83E1.2080402@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are my thoughts about the Inbound AXFR design. Changes to the signer engine: If is present in the conf.xml file: - - See if there is a newly transferred file in the axfr directory. - - If so, move it to be the input file. - - Continue with normal operation (read input file adapter, nsec, sign, audit, write output). Consequences for the auditor: Currently none, since a zone cannot have multiple tasks in parallel. The auditor will still be able to do the audit on the unsigned input file and signed output file. New signer tool, axfr_listener runs as daemon: - - Listen to NOTIFY messages. - - If no input file exists or if a NOTIFY is received from a master: - do axfr request (nsd-xfer) - write result back to axfr directory - execute signer_engine_cli update Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKr4PeAAoJEA8yVCPsQCW5E4gH/1epXysEKiOj6eKN2DUZTDNe 7IFvpwEVRG/6SGABAEjmoh2dFc96svDF2wIFmba91yLD6qCR0ASkFFeNR0EOX3ST +A0sdB3MFgxyh0wqn5pKdQGuwBc5ch4+dGZj295rMPKvbxAFLFAhQDN6tTH+N4CW TxONvItK1OY70QsdT4uEVs0XWnb6az5IjqJHuFUtO3aWwnFqiKaQU9IcWGK40Ml8 5vQbUEKUu+SSXviin4f/6yOcoZs/CEYwzUVtt45DRQf+qRGZI2r2KCGsKnJoOsHK nd5IlBKHMXpWXS6Jjz7JOuW/mOGp+MUr3fFtdENHOW/FJnp1GcJ3pbOgWJ+L6TM= =+a9j -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Tue Sep 15 12:15:24 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 15 Sep 2009 14:15:24 +0200 Subject: [Opendnssec-develop] Action point: check your code against the requirements Message-ID: <4AAF855C.8050801@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If nobody objects, I would like to add the following requirements to the wiki: The system SHOULD be able to send a notify command to the local nameserver. The system MUST be able to drop privileges upon start up It MUST be possible to update the polices and zone data, without taking the system down. The system SHOULD be able to deal with (variable) durations. The policy for the zone MUST allow values for the following signing parameters to be set: * Signature re-sign interval * Signature refresh interval The policy MUST allow values for the following NSEC3 parameters to be set: * Opt-Out * Algorithm * Iterations * Salt * TTL? The policy SHOULD allow values for the following SOA parameters to be set: * Minimum * TTL * Serial - - Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKr4VZAAoJEA8yVCPsQCW52HQIAM70l29CvFf1Rp2gJLT59q/h oWv+ZvaSAPPu3P7LD+uMppvntrpNgCzCqm8xLvlU4VZ2MWCUdnj4guc8yKJhYGvl qOKropPdi5JxXLm5Wv0dA4tYsr4XltLTKM7OWkb68lgMgiduOfo3zIpkX8I3MJRB gC0hKM9XmjyzN1+vDVuK3Lz3t2iInAJPWMrQyndDlm0TACqsoQNPFa/7rg2KsIFq +pIYo7s3rBRxKnVWYCZVXpHhplzIEqEmULGxbs+jukoeyEbukXrti6jQVQ7eLZ6+ KA7SRSnmpgQd07lkLWsl/cjqJFztJ5r3dTZ7gn2Rzb7dg5N/CLplytwPlPEI4B8= =sQp0 -----END PGP SIGNATURE----- From Ray.Bellis at nominet.org.uk Tue Sep 15 12:40:25 2009 From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk) Date: Tue, 15 Sep 2009 13:40:25 +0100 Subject: [Opendnssec-develop] Inbound AXFR design In-Reply-To: <4AAF83E1.2080402@nlnetlabs.nl> References: <4AAF83E1.2080402@nlnetlabs.nl> Message-ID: > New signer tool, axfr_listener runs as daemon: > - - Listen to NOTIFY messages. > - - If no input file exists or if a NOTIFY is received from a master: > - do axfr request (nsd-xfer) > - write result back to axfr directory > - execute signer_engine_cli update Are there any thoughts as to whether this daemon needs to honour the "refresh" and "expiry" times from the SOA, such that it periodically polls the master for the SOA even if it hasn't received a NOTIFY? If it hasn't already been decided, consideration may need to be given as to whether the NOTIFY channel (and hence the axfr_listener) requires TSIG support. Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Tue Sep 15 12:51:01 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 15 Sep 2009 14:51:01 +0200 Subject: [Opendnssec-develop] Inbound AXFR design In-Reply-To: <4AAF83E1.2080402@nlnetlabs.nl> References: <4AAF83E1.2080402@nlnetlabs.nl> Message-ID: we just had a discussion about this via Jabber and I think we came to the following conclusion: - Matthijs implements a stand-alone zonefetcher (trunk/OpenDNSSEC/ zonefetcher) written in C - the zonefetcher will likely have its own configuration file, bascially saying: fetch zone Z from master M using tsig secret T (name,algo,secret) and write the result into file F. F can be specified in the config or maybe fetch from the File adapter in the ZoneList. - after an update zone has been fetched, it will poke the signer engine. jakob From matthijs at NLnetLabs.nl Tue Sep 15 13:08:04 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 15 Sep 2009 15:08:04 +0200 Subject: [Opendnssec-develop] Inbound AXFR design In-Reply-To: References: <4AAF83E1.2080402@nlnetlabs.nl> Message-ID: <4AAF91B4.3050605@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ray.Bellis at nominet.org.uk wrote: > >> New signer tool, axfr_listener runs as daemon: >> - - Listen to NOTIFY messages. >> - - If no input file exists or if a NOTIFY is received from a master: >> - do axfr request (nsd-xfer) >> - write result back to axfr directory >> - execute signer_engine_cli update > > Are there any thoughts as to whether this daemon needs to honour the > "refresh" and "expiry" times from the SOA, such that it periodically > polls the master for the SOA even if it hasn't received a NOTIFY? That depends if OpenDNSSEC is being a bump in the wire or acts as a real secondary. If secondary, it should honour the refresh and expiry timers. If bump, imo, it only has to listen to NOTIFY. > If it hasn't already been decided, consideration may need to be given as > to whether the NOTIFY channel (and hence the axfr_listener) requires > TSIG support. That has been taken into account. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKr5GyAAoJEA8yVCPsQCW5lUQH/in+ZQ2VwNNSYh3WFQe+gV/h IvS5gM9BFSFRm26FvnVlzDXzCJNFgWzLmg1S15PrbHvPUeS9PKHhbznvyOr0jTJ0 8M2yKFbgYjMddVJZO+NOPyaIT3XLLKIumifsl8e1nTn0ccY1/kslFZAp1imJautq G3f5hDXmvaEbYKVWtDHriwDFrDYTFH9wma0iE1OxzThQApHLh2DeBikPURJq1VFS 8OeGizB4pjzm5P5Qua7V5A/uROYDk9TlQPq+0rlqcqtWOy0XXE8w65KGxO3gSifw 3S0OB/9/ZrCRXvlhQyWb/EyasKKRKjqaa9DIZXoC9cTQHQr6k5OdPrPj1lsRdd8= =oKaE -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Wed Sep 16 12:22:33 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 16 Sep 2009 12:22:33 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #25: Could ksmutil print the key_id In-Reply-To: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> References: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> Message-ID: <068.10e475a79fe392f2f0987d6848a5e6fb@kirei.se> #25: Could ksmutil print the key_id ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: sion Type: enhancement | Status: assigned Priority: minor | Component: Enforcer Version: | Resolution: Keywords: | ----------------------------------+----------------------------------------- Comment(by matthijs): FIY: I have adapted the signer tools in such a way, that the key id also stays in the signed output file, not only the temporary .signed file. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Mon Sep 21 09:16:06 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 21 Sep 2009 10:16:06 +0100 Subject: [Opendnssec-develop] getting rid of HSM callsfrom the communicator In-Reply-To: References: <46FEEBD3-89DB-45FB-BF50-A0B7F5BAB64C@kirei.se> <12D7BB56-EE33-4D21-B9DE-5224B3E53678@kirei.se> <850A39016FA57A4887C0AA3C8085F949011B73E9@KAEVS1.SIDN.local> <4AA8BEF9.3040909@surfnet.nl> <4AA8C28D.8080203@surfnet.nl> <7C265F98-9FE7-41F2-BACF-F2BFDB31564C@kirei.se> Message-ID: > > > To be clear, the default (well, the example xml) already specifies a > > > random salt, of length 8, and resalts every 100 days. > > > > I agree with Roy here, but I see no point in changing this at this > > time - it would just confuse people. Sorry I'm coming a bit late to this party. I just want to clear up how the salt works currently, to make sure that we are all happy with it. There is no default salt... only a default length for the salt (in kasp.xml). The salt is per _policy_; i.e. all zones on the same policy will have the same salt. That salt is generated the first time the communicator sees that policy, and every after that. (We do not tell the signer that the salt has changed though, is that okay?) Sion From matthijs at NLnetLabs.nl Mon Sep 21 13:08:25 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 21 Sep 2009 15:08:25 +0200 Subject: [Opendnssec-develop] Inbound AXFR design In-Reply-To: References: <4AAF83E1.2080402@nlnetlabs.nl> Message-ID: <4AB77AC9.3010803@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakob Schlyter wrote: > we just had a discussion about this via Jabber and I think we came to > the following conclusion: > > - Matthijs implements a stand-alone zonefetcher > (trunk/OpenDNSSEC/zonefetcher) written in C > - the zonefetcher will likely have its own configuration file, bascially > saying: > > fetch zone Z from master M using tsig secret T (name,algo,secret) and > write the result into file F. > F can be specified in the config or maybe fetch from the File adapter > in the ZoneList. I'd rather not store the fetched zone into //Adapter/Input/File directly, because in that way, the unsigned input file could be overwrited with a new version of the zone, before the auditor have checked the previous version. So, you need a different way to specify F, could be in the special configuration file, but than the signer engine would not know where to get the transferred zone. So I propose F is specified in the zonelist.xml, because the zone_fetcher needs to read that anyway and the signer_engine already does. Matthijs > > - after an update zone has been fetched, it will poke the signer engine. > > > jakob > > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKt3rGAAoJEA8yVCPsQCW5814IALmTnPjWhhugACxB4SNf4MVe eEseTV85n6pqEueKliIWK15JXxJLE7jMOXrSv/kBdVDelj317hXkQnFoaWRRGtZA +fZXQlAaQKmUTO88oZYZv5slOESsgk+EaXbFRLXO3uN5wXjge3Rih4iKqc3T5QMj BRaMyUTddlpcAMfdh9fpS9fLnYrhvmEeo2luM2lmin0n7v3eHHlfGCBL+lXYU4ma UH6nuAqn3WbgLfKXw+90Q7EKM5b9hBrfBCNLcGkuQRTCeNPyanB4owsfwG4Av7Qh g9kL9NNJKrvVSdNuDCwdPJ2vF+EqocYldjCzQ2OpSPyaH0HSixqaJD80wMB138k= =rAoJ -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Mon Sep 21 13:20:02 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 21 Sep 2009 13:20:02 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #28: java missing from signer prereqs Message-ID: <061.69f066453c2a5312ff828d0b2b3f6b58@kirei.se> #28: java missing from signer prereqs ------------------------------------+--------------------------------------- Reporter: robert at dk-hostmaster.dk | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: 1.0a3 | Keywords: ------------------------------------+--------------------------------------- http://trac.opendnssec.org/wiki/Signer/Install mentions a lot of pre- requisite packages needed to compile the signer. 1.0a3 will configure but not make, unless you have java. openjdk-6-jdk worked for me on Debian. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 21 17:12:52 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 21 Sep 2009 17:12:52 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #29: $prefix unexpanded in softhsm.conf Message-ID: <061.e596d6f44aca1b96f86baf44e1b0c9ef@kirei.se> #29: $prefix unexpanded in softhsm.conf ------------------------------------+--------------------------------------- Reporter: robert at dk-hostmaster.dk | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: 1.0a3 | Keywords: ------------------------------------+--------------------------------------- prefix goes unexpanded into softhsm.conf: {{{ $ cat /usr/local/etc/softhsm.conf # softHSM configuration file # 0:${prefix}/var/softhsm/slot0.db }}} strace says softhsm subsequently tries to open:[[BR]] /usr/local/etc/${prefix}/var/softhsm/slot0.db -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 21 18:03:55 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 21 Sep 2009 18:03:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #28: java missing from signer prereqs In-Reply-To: <061.69f066453c2a5312ff828d0b2b3f6b58@kirei.se> References: <061.69f066453c2a5312ff828d0b2b3f6b58@kirei.se> Message-ID: <070.41b1dda9a40c3b5aff94706af1d614bf@kirei.se> #28: java missing from signer prereqs ------------------------------------+--------------------------------------- Reporter: robert at dk-hostmaster.dk | Owner: rb Type: defect | Status: closed Priority: trivial | Component: Unknown Version: 1.0a3 | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by jakob): * status: new => closed * resolution: => fixed Comment: correct, we wrote the installer documentation for the tarballs (which does not yet exist...) and for them you do not need java. I'll update the documentation to make a not of this. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 21 18:14:03 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 21 Sep 2009 18:14:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #29: $prefix unexpanded in softhsm.conf In-Reply-To: <061.e596d6f44aca1b96f86baf44e1b0c9ef@kirei.se> References: <061.e596d6f44aca1b96f86baf44e1b0c9ef@kirei.se> Message-ID: <070.6a033ad97ca4fc5f699bf6530ad3bc4a@kirei.se> #29: $prefix unexpanded in softhsm.conf ------------------------------------+--------------------------------------- Reporter: robert at dk-hostmaster.dk | Owner: rb Type: defect | Status: closed Priority: minor | Component: SoftHSM Version: 1.0a3 | Resolution: worksforme Keywords: | ------------------------------------+--------------------------------------- Changes (by jakob): * status: new => closed * resolution: => worksforme Comment: This should be fixed in later versions, please try 1.0a5 or trunk. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Tue Sep 22 10:50:22 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 22 Sep 2009 12:50:22 +0200 Subject: [Opendnssec-develop] Inbound AXFR design In-Reply-To: <4AB77AC9.3010803@nlnetlabs.nl> References: <4AAF83E1.2080402@nlnetlabs.nl> <4AB77AC9.3010803@nlnetlabs.nl> Message-ID: <924F1B55-05E3-48DA-8F73-34305C339143@kirei.se> Matthijs had a quick jabber chat this morning regarding this and came to the conclusion that the zonefetcher will read both the zonelist and (the new) zonefetch config file. initially fetch all zones in the zonelist from the source specified in zonefetch.xml and write the resulting files to the input file specified in the zonelist with ".axfr" appended to the filename. the signer engine will, once it finds an .axfr-file, move it to the real input file and continue its business. we think this should be good enough for 1.0. jakob From sion at nominet.org.uk Tue Sep 22 10:52:30 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 22 Sep 2009 11:52:30 +0100 Subject: [Opendnssec-develop] keys formerly known as "Emergency" Message-ID: I've renamed "Emergency" keys as "Standby" keys to better reflect their role. This has meant some database changes in svn r1841 As usual a migration script is provided so please run: sqlite3 < enforcer/utils/migrate_090922_1.sqlite3 or "ksmutil setup" if you don't want to keep existing data. Also, you will need to rebuild in the xml directory if you do not regularly do this as it changes the .rng files. Sorry if I have missed anything, Sion From owner-dnssec-trac at kirei.se Tue Sep 22 11:47:15 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 22 Sep 2009 11:47:15 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #30: Compile links to wrong libhsm Message-ID: <065.585083d175d6ccb72217a26c902ec560@kirei.se> #30: Compile links to wrong libhsm ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ----------------------------------------+----------------------------------- If libhsm is already installed in the system library path, this is used instead of the library in the build tree. {{{ /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -pedantic -Wall -Wextra -o keygend keygend.o ../common/libenforcer.a ../ksm/libksm.a -lxml2 -lz -lm -L/usr/local/lib -lsqlite3 -L../../libhsm/src/.libs -lhsm libtool: link: gcc -g -O2 -pedantic -Wall -Wextra -o keygend keygend.o ../common/libenforcer.a ../ksm/libksm.a -L/usr/local/lib /usr/lib/libsqlite3.so -lpthread -L/.../libhsm/src/.libs /usr/local/lib/libhsm.so -L/usr/lib /usr/lib/libldns.so -lnsl -lcrypto /usr/lib/libxml2.so -lz -lm -ldl keygend.o: In function `server_main': enforcer/keygend/keygend.c:316: undefined reference to `hsm_get_error' enforcer/keygend/keygend.c:240: undefined reference to `hsm_get_error' enforcer/keygend/keygend.c:304: undefined reference to `hsm_get_error' enforcer/keygend/keygend.c:136: undefined reference to `hsm_get_error' collect2: ld returned 1 exit status make: *** [keygend] Error 1 }}} It may be possible to fix this by incrementing the libhsm version number so that libtool prefers the local version over the older installed library. Alternatively the library paths could be specified in the correct order. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 22 12:00:48 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 22 Sep 2009 12:00:48 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #31: keepcounter serial option Message-ID: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> #31: keepcounter serial option ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: enhancement | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: ----------------------------------------+----------------------------------- A "keepcounter" option for the serial would try to use the '''input serial''' (if it is after the '''current output serial'''), before resorting to using '''current output serial''' + 1. This is an alternative to "keep" which allows the output serial to be the same as the input serial when the zone is changed, but unlike "keep" does not require manual intervention when a subsequent signature change requires a new serial. The expected use for this would be a time-based input serial which is likely to increment faster than the signed zone. e.g. Input 2009092200 and Output 2009092200, 2009092201, 2009092202 (signature changes) followed by Input 2009093000 which results in Output 2009093000. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 22 12:03:39 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 22 Sep 2009 12:03:39 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #32: Serial calculations do not handle wrapping Message-ID: <065.68dd9d87807e48d8444761fed737a064@kirei.se> #32: Serial calculations do not handle wrapping ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: ----------------------------------------+----------------------------------- DNS serials wrap around 2^32, with the previous 2^31 values being "before" and the next 2^31 being "after". The serial calculation code needs to handle this properly when comparing two serials to determine which one is >= the other, and also when incrementing it. The "unixtime" serial just needs to be calculated MOD 2^32, and "datecounter" requires no change. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 22 12:31:25 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 22 Sep 2009 12:31:25 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #30: Compile links to wrong libhsm In-Reply-To: <065.585083d175d6ccb72217a26c902ec560@kirei.se> References: <065.585083d175d6ccb72217a26c902ec560@kirei.se> Message-ID: <074.9a7383bf15489cd9571666571ab0d2a1@kirei.se> #30: Compile links to wrong libhsm ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: jakob Type: defect | Status: accepted Priority: major | Component: Unknown Version: trunk | Resolution: Keywords: | ----------------------------------------+----------------------------------- Changes (by jakob): * owner: rb => jakob * status: new => accepted -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 22 12:32:04 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 22 Sep 2009 12:32:04 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #30: Compile links to wrong libhsm In-Reply-To: <065.585083d175d6ccb72217a26c902ec560@kirei.se> References: <065.585083d175d6ccb72217a26c902ec560@kirei.se> Message-ID: <074.1cee4431927b3c639d88366becff199f@kirei.se> #30: Compile links to wrong libhsm ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: jakob Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by jakob): * status: accepted => closed * resolution: => fixed Comment: yes, we should use better versions number - will fix at release. patch committed, thanks! -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 22 12:37:50 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 22 Sep 2009 12:37:50 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #31: keepcounter serial option In-Reply-To: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> References: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> Message-ID: <074.e8ea3f733afe05ae62ae60c82a0dc4a0@kirei.se> #31: keepcounter serial option ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: jakob Type: enhancement | Status: accepted Priority: minor | Component: Signer Version: trunk | Resolution: Keywords: | ----------------------------------------+----------------------------------- Changes (by jakob): * owner: matthijs => jakob * status: new => accepted Comment: What happens when "keepcounter" has increased the serial a number of steps, and the inputfiles serial goes slightly backwards? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 22 12:46:49 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 22 Sep 2009 12:46:49 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #31: keepcounter serial option In-Reply-To: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> References: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> Message-ID: <074.214a8dfd119702243374cac5ff823698@kirei.se> #31: keepcounter serial option ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: enhancement | Status: assigned Priority: minor | Component: Signer Version: trunk | Resolution: Keywords: | ----------------------------------------+----------------------------------- Changes (by jakob): * owner: jakob => matthijs * status: accepted => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 22 14:21:03 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 22 Sep 2009 14:21:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #31: keepcounter serial option In-Reply-To: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> References: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> Message-ID: <074.1814bd7f3838f7f087ff45d4a75e1bf3@kirei.se> #31: keepcounter serial option ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: enhancement | Status: closed Priority: minor | Component: Signer Version: trunk | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by matthijs): * status: assigned => closed * resolution: => fixed Comment: Accepted and fixed in trunk (also in xml and enforcer) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 23 11:42:50 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 23 Sep 2009 11:42:50 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #32: Serial calculations do not handle wrapping In-Reply-To: <065.68dd9d87807e48d8444761fed737a064@kirei.se> References: <065.68dd9d87807e48d8444761fed737a064@kirei.se> Message-ID: <074.4739e4e60f1582c67841331cd58323e3@kirei.se> #32: Serial calculations do not handle wrapping ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: defect | Status: closed Priority: minor | Component: Signer Version: trunk | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed Comment: Added function compare_serial according to RFC 1982 Do serial addition according to RFC 1982 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 29 08:53:35 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 29 Sep 2009 08:53:35 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #31: keepcounter serial option In-Reply-To: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> References: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> Message-ID: <074.1c40f66575fcb040e0d057592a2c2535@kirei.se> #31: keepcounter serial option ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: enhancement | Status: closed Priority: minor | Component: Signer Version: trunk | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Comment(by matthijs): We decided that this is useful for counter as well. So the keepcounter is removed again (it wasn't released anyway, it only lived in trunk for a while). counter gets the functionality of keepcounter. It makes the options much more cleaner. I hope this is sufficient. -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Tue Sep 29 09:00:32 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Tue, 29 Sep 2009 10:00:32 +0100 Subject: [Opendnssec-develop] Code Reviews Message-ID: Hi - I remember (from some time ago) that we decided to defer code reviews until the beta release. Now that we're thinking of tagging the release (hopefully this week), it seems like a good idea to try to schedule some reviews. How should this work? When should we try to do the reviews? Should we be trying to use any tools to help this (e.g. Crucible)? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Tue Sep 29 15:35:04 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 29 Sep 2009 15:35:04 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #22: keygend frequently doesn't realise new keys need to be generated In-Reply-To: <065.77063d64e3ca06af09d071317f6125a2@kirei.se> References: <065.77063d64e3ca06af09d071317f6125a2@kirei.se> Message-ID: <074.9ffa616ce170f5c2b6fbbda2e3fd2b6e@kirei.se> #22: keygend frequently doesn't realise new keys need to be generated ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: sion Type: defect | Status: closed Priority: major | Component: Enforcer Version: | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by sion): * status: new => closed * resolution: => fixed Comment: This is fixed in trunk. Keys are now marked as "dead" when they are not used so that they can not confuse the keygend on further runs. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 29 15:39:46 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 29 Sep 2009 15:39:46 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #25: Could ksmutil print the key_id In-Reply-To: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> References: <059.1d1ceb1ea0a775de0469ce3c92d51228@kirei.se> Message-ID: <068.080acf5766735a87a6cf754007e48172@kirei.se> #25: Could ksmutil print the key_id ----------------------------------+----------------------------------------- Reporter: sebastian at nzrs.net.nz | Owner: sion Type: enhancement | Status: closed Priority: minor | Component: Enforcer Version: | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Changes (by sion): * status: assigned => closed * resolution: => fixed Comment: The keytag is now printed (when the -l flag is used) -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Wed Sep 30 07:56:52 2009 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 30 Sep 2009 08:56:52 +0100 Subject: [Opendnssec-develop] Policy configuration checker requirements Message-ID: Hi - Just a quick reminder to please add any new checks you can think of for the policy configuration checker to : http://trac.opendnssec.org/wiki/Signer/Configuration/ConfigurationChecker Thanks! Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrik.wallstrom at iis.se Wed Sep 30 08:58:46 2009 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Wed, 30 Sep 2009 10:58:46 +0200 Subject: [Opendnssec-develop] Policy configuration checker requirements In-Reply-To: References: Message-ID: <1013D9FB-6605-4BBD-AABE-C62C0A845256@iis.se> On Sep 30, 2009, at 9:56 AM, wrote: > Hi - > > Just a quick reminder to please add any new checks you can think of > for the policy configuration checker to : > > http://trac.opendnssec.org/wiki/Signer/Configuration/ConfigurationChecker > > Thanks! I hope you get all system paths - the most common problem that I've had on an Ubuntu system is that /var/run/opendnssec is removed after reboot. -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From owner-dnssec-trac at kirei.se Wed Sep 30 11:45:11 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 30 Sep 2009 11:45:11 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #33: signer doesn't handle changes in SOA record Message-ID: <065.882be2547268c674f8684c7b5e7c6b45@kirei.se> #33: signer doesn't handle changes in SOA record ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: ----------------------------------------+----------------------------------- If only the SOA record is changed, the new zone is not used: {{{ 30 12:34:56 signer engine: signer stderr: signer: number of signatures created: 1 (0 rr/sec) 30 12:34:56 signer engine: No new signatures, keeping zone }}} The content of the SOA record (excluding the serial) from the previous output file should be compared with the new output file. If a "keep" type of serial is being used and the input serial is newer than the previous output file, then this would also indicate that the newly signed zone should be used (even if nothing else has changed) as the SOA serial has been incremented. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 30 12:03:58 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 30 Sep 2009 12:03:58 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #31: keepcounter serial option In-Reply-To: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> References: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> Message-ID: <074.c2d7c0f907b333326f1ca2114bc04d22@kirei.se> #31: keepcounter serial option ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: enhancement | Status: closed Priority: minor | Component: Signer Version: trunk | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Comment(by opendnssec.simon at arlott.org): I'm only using the keepcounter version, so it won't affect me, but counter is distinct from keepcounter. If it's not used carefully (e.g. input serial stays at "1" forever), then eventually it will change meaning from being behind the output serial to being ahead of the output serial. When this happens, the output serial will jump forward the maximum possible amount and any slave nameservers that miss that update will become out of sync. If the input serial is always 1, then the output serial will be: 2147483648 (after 1), 2147483649 (equal to 1), 2147483650 (before 1), 1, 2, 3. If a slave nameserver misses the updates when this happens, it'll look like the master has an old serial. The behaviour of "keepcounter" requires that the input and output serials will not get too far out of sync. If the zone is going to change frequently (perhaps because it has many thousands of RRs that will need to be resigned) and the input serial is rarely changed, or is changed at a different rate from the output serial (input+1 for every new/changed RR will not be the same as the output+1 for every re-signed RR), then this could happen... but it does require over 2 billion re-signings of the zone. The correct serial in this case would of course be "unixtime", but that may not be obvious, and a pure "count + 1 on each change" might be desired, which is no longer possible. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 30 12:19:38 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 30 Sep 2009 12:19:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #31: keepcounter serial option In-Reply-To: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> References: <065.a4adaf3764c9d14a225bf1f5e27f49a4@kirei.se> Message-ID: <074.942de740b7958ba2099b598ca05f6fab@kirei.se> #31: keepcounter serial option ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: enhancement | Status: closed Priority: minor | Component: Signer Version: trunk | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Comment(by matthijs): Replying to [comment:5 opendnssec.simon at arlott.org]: > I'm only using the keepcounter version, so it won't affect me, but counter is distinct from keepcounter. notice that the keyword keepcounter will dissappear. The counter will get the behavior of keepcounter. > If it's not used carefully (e.g. input serial stays at "1" forever), then eventually it will change meaning from being behind the output serial to being ahead of the output serial. When this happens, the output serial will jump forward the maximum possible amount and any slave nameservers that miss that update will become out of sync. I have added rfc 1982 support to cover that. > > If the input serial is always 1, then the output serial will be: 2147483648 (after 1), 2147483649 (equal to 1), 2147483650 (before 1), 1, 2, 3. If the input serial is always one, it is ignored because the output serial will always be larger. > If a slave nameserver misses the updates when this happens, it'll look like the master has an old serial. If all the NOTIFY stuff works, the slave nameserver would not miss it. If it does miss it (what are the odds?), it will eventually expire and stop serving it's old dns data. According to the specification, the secondary has to discard the obsoleted zone and do a fresh transfer. > > The behaviour of "keepcounter" requires that the input and output serials will not get too far out of sync. If the zone is going to change frequently (perhaps because it has many thousands of RRs that will need to be resigned) and the input serial is rarely changed, or is changed at a different rate from the output serial (input+1 for every new/changed RR will not be the same as the output+1 for every re-signed RR), then this could happen... but it does require over 2 billion re-signings of the zone. As I said, what are the odds. And the impact is imo not that big and will restore automatically. > > The correct serial in this case would of course be "unixtime", but that may not be obvious, and a pure "count + 1 on each change" might be desired, which is no longer possible. If someone wants a pure count + 1, they can do that and leave the input serial unchanged. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 30 12:20:29 2009 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 30 Sep 2009 12:20:29 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #33: signer doesn't handle changes in SOA record In-Reply-To: <065.882be2547268c674f8684c7b5e7c6b45@kirei.se> References: <065.882be2547268c674f8684c7b5e7c6b45@kirei.se> Message-ID: <074.eb3fa65d785d47b1929d2e44e7fc8d10@kirei.se> #33: signer doesn't handle changes in SOA record ----------------------------------------+----------------------------------- Reporter: opendnssec.simon at arlott.org | Owner: matthijs Type: defect | Status: accepted Priority: minor | Component: Signer Version: trunk | Resolution: Keywords: | ----------------------------------------+----------------------------------- Changes (by matthijs): * status: new => accepted -- Ticket URL: OpenDNSSEC OpenDNSSEC