From owner-dnssec-trac at kirei.se Mon Feb 1 08:57:10 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Feb 2010 08:57:10 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #82: Extra dependency on rubygems In-Reply-To: <065.bb808204d9c370131ee93606878b01ce@kirei.se> References: <065.bb808204d9c370131ee93606878b01ce@kirei.se> Message-ID: <074.fb0326d30378fb82d9eda9c8306aa0ef@kirei.se> #82: Extra dependency on rubygems ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: enhancement | Status: closed Priority: minor | Component: Auditor Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks Fixed in r2732 and r2733 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Feb 1 09:23:41 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Feb 2010 09:23:41 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #83: --version prints OPENDNSSEC_VERSION In-Reply-To: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> References: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> Message-ID: <074.bb66ce3476113cad889ab6c5a60c86ec@kirei.se> #83: --version prints OPENDNSSEC_VERSION ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): It looks to me that this does work. I can print the version for all of the configure scripts. It also works if I do make dist for the individual components. Where does it go wrong for you? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Feb 1 10:57:12 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Feb 2010 10:57:12 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #83: --version prints OPENDNSSEC_VERSION In-Reply-To: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> References: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> Message-ID: <074.d249d4326e0a68518e6a2878169caa10@kirei.se> #83: --version prints OPENDNSSEC_VERSION ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Hi, problem is when you package each component separately then ../version.m4 doesn't exists. I have solved this with following patch in every split- out package, but it would be better if make dist could do: `for dir in auditor conf enforcer libhsm signer; cp version.m4 ${dir}; done' {{{ ondrej at howl:~/Projects/pkg-opendnssec/opendnssec-conf/debian/patches$ cat 001_version_m4.patch --- a/configure.ac +++ b/configure.ac @@ -1,6 +1,6 @@ # $Id: configure.ac 1971 2009-10-01 06:37:51Z jakob $ -m4_sinclude([../version.m4]) +m4_sinclude([version.m4]) AC_PREREQ(2.61) AC_INIT([opendnssec-conf], OPENDNSSEC_VERSION) --- /dev/null +++ b/version.m4 @@ -0,0 +1,5 @@ +# $Id: version.m4 2710 2010-01-25 20:10:09Z jakob $ +# +# this file contains the current OpenDNSSEC version + +define([OPENDNSSEC_VERSION], [1.0.0rc3]) }}} But consider this as a wishlist, I could easily cope with this when creating split-out tarballs. Ondrej -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick.zijlker at sidn.nl Mon Feb 1 11:10:01 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Mon, 1 Feb 2010 12:10:01 +0100 Subject: [Opendnssec-develop] Test the new sorter References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> Hey, I tested the new sorter with the unsorted nl zone. Here is a comparison: [root at signer1 rick]# time /usr/local/libexec/opendnssec/sorter -f ./nl -w ./nl.sorted2 -m 3600 -t 3600 -o nl. Number of records sorted: 8446249 real 5m24.859s user 5m5.311s sys 0m18.056s [root at signer1 rick]# time ./quicksorter -f ./nl -w ./nl.sorted -m 3600 -t 3600 -o nl. Killed real 5m14.711s user 0m10.172s sys 2m23.606s The quicksorter keeps getting killed which results in an incomplete sorted zone: -rw-rw-r-- 1 rick rick 226143877 Nov 17 16:46 nl -rw-r--r-- 1 root root 0 Feb 1 11:28 nl.sorted -rw-r--r-- 1 root root 396950529 Feb 1 11:00 nl.sorted2 Also I don?t see improvement in performance. Even though the sorter is not even the bottleneck. The processing is what takes 45-50 minutes. Cheers, Rick From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Rickard Bellgrim Sent: woensdag 27 januari 2010 16:47 To: Opendnssec-develop at lists.opendnssec.org Subject: [Opendnssec-develop] Test the new sorter -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi There is a new sorter available in our SVN. Could you test it if you had any performance issues, e.g. SIDN? Solves some part of the problem. wget http://trac.opendnssec.org/export/2729/home/bjst/quicksorter.c gcc -Wall quicksorter.c -o quicksorter time ./quicksorter -f -w -m -t -o Compare the result with time /usr/local/libexec/opendnssec/sorter -f -w -m -t -o It is 10 times faster for me. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2Bf9uCjgaNTdVjaAQiOEQf/QtwEZINZKNPmApEKsXCDFTP+8Jz6UOAq 5AmkcNDjaz47hrdv+/voBPNu+CFws1Hw200gKysXk/rnkU848v+29o0iLv2p0TW5 9GAGVYJM5CQHcXRCQDB6B0/bb8IARbeokWHv2IGoGbk+ALcr+Dh4010mfuFGh7C8 nV57pYGNvf/rnpnmryEFP0xPqSBac5PsblVjABg/Hr6o0cKpPC1tR5tVqwjxoEDj pVzvQxz2v7oq8bl0OkpAlqZ0xT/cp6KZG+hBdrh4wxzbY1LdyoicLIGYg7G11NpW 3IYdr46p/ZYVY+E+TC6C1AIjZU8sZBBL15qJ0YBgglK0dObR55PyEA== =d0Ce -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Mon Feb 1 12:03:58 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 01 Feb 2010 13:03:58 +0100 Subject: [Opendnssec-develop] Test the new sorter In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> Message-ID: <4B66C32E.9030100@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rick, The sorter is being improved for another zone, which has performance issues in this specific tool. I just started working on improving the zone_reader. To be continued... Best regards, Matthijs Rick Zijlker wrote: > Hey, > > > > I tested the new sorter with the unsorted nl zone. Here is a comparison: > > > > [root at signer1 rick]# time /usr/local/libexec/opendnssec/sorter -f ./nl > -w ./nl.sorted2 -m 3600 -t 3600 -o nl. > > Number of records sorted: 8446249 > > > > real 5m24.859s > > user 5m5.311s > > sys 0m18.056s > > > > [root at signer1 rick]# time ./quicksorter -f ./nl -w ./nl.sorted -m 3600 > -t 3600 -o nl. > > Killed > > > > real 5m14.711s > > user 0m10.172s > > sys 2m23.606s > > > > > > The quicksorter keeps getting killed which results in an incomplete > sorted zone: > > > > -rw-rw-r-- 1 rick rick 226143877 Nov 17 16:46 nl > > -rw-r--r-- 1 root root 0 Feb 1 11:28 nl.sorted > > -rw-r--r-- 1 root root 396950529 Feb 1 11:00 nl.sorted2 > > > > Also I don?t see improvement in performance. Even though the sorter is > not even the bottleneck. The processing is what takes 45-50 minutes. > > > > Cheers, > > Rick > > > > > > *From:* opendnssec-develop-bounces at lists.opendnssec.org > [mailto:opendnssec-develop-bounces at lists.opendnssec.org] *On Behalf Of > *Rickard Bellgrim > *Sent:* woensdag 27 januari 2010 16:47 > *To:* Opendnssec-develop at lists.opendnssec.org > *Subject:* [Opendnssec-develop] Test the new sorter > > > > Hash: SHA256 > > > > Hi > > > > There is a new sorter available in our SVN. Could you test it if you had > any performance issues, e.g. SIDN? Solves some part of the problem. > > > > wget http://trac.opendnssec.org/export/2729/home/bjst/quicksorter.c > > gcc -Wall quicksorter.c -o quicksorter > > > > time ./quicksorter -f -w -m minimum> -t -o > > > > Compare the result with > > > > time /usr/local/libexec/opendnssec/sorter -f -w > -m -t -o > > > > It is 10 times faster for me. > > > > // Rickard > > > - ------------------------------------------------------------------------ _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLZsMrAAoJEA8yVCPsQCW5NjYH+wQn1pWiRPMEHUzYQYjXqStg yxgeiaS499x3QUmpECfE6kftTxwjsDe80bXb+W5dmckW1qDGDVG8adyMiUFKHSUQ oxSWuvtq2DJAPBj+UoDrofpyvSkUMhne8ZuM8XFEEhSydZ56hLFr5HHEoloNMFzw KwBF0ldKNopigoX5LnPB18Xf1y+C80CqgWEacYbacwL5jvfMSxOSOR54gKzs5Dze hpjps0z/X17EWtf1jJ+kv8Y4TyZy25WAhiMPdTAMh+dzF1j541mk06G1A0It202f VAj/XCeDO/0l0oCDyUn63VgphKfSIkcUhD8T6nbdnfyU+Sk6recYajQ0xK73fMs= =Jwu/ -----END PGP SIGNATURE----- From bjorn at haxx.se Mon Feb 1 12:42:58 2010 From: bjorn at haxx.se (=?iso-8859-1?Q?Bj=F6rn?= Stenberg) Date: Mon, 1 Feb 2010 13:42:58 +0100 Subject: [Opendnssec-develop] Test the new sorter In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> Message-ID: <20100201124258.GA14993@giant> Rick Zijlker wrote: > The quicksorter keeps getting killed Interesting. The time signature suggests it spent considerable time swapping memory to disk. That certainly sounds like a bug in quicksorter. Try changing line 50 to "#if 1" to enable some debug output. Is there any way I can get a copy of a file that triggers this behaviour? -- Bj?rn From owner-dnssec-trac at kirei.se Mon Feb 1 14:06:06 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Feb 2010 14:06:06 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #83: --version prints OPENDNSSEC_VERSION In-Reply-To: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> References: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> Message-ID: <074.6b197dc4933b34b76c6d6f90de8f2f50@kirei.se> #83: --version prints OPENDNSSEC_VERSION ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: assigned Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Changes (by jakob): * owner: alex => jakob * status: new => assigned Comment: How would you recommend we do this automatically? -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick.zijlker at sidn.nl Mon Feb 1 14:17:13 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Mon, 1 Feb 2010 15:17:13 +0100 Subject: [Opendnssec-develop] Test the new sorter References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> <20100201124258.GA14993@giant> Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local> Hey Bj?rn, Unfortunately I cannot supply a copy of the file I tested with. It's the .nl zone. I did enable the debug output. Apparently it runs out of memory. The test server has 16 GB's of RAM. I believe the logging below shows the entire 'kill'. If not, please let me know. Cheers, Rick Feb 1 14:40:34 signer1 kernel: automount invoked oom-killer: gfp_mask=0x200d2, order=0, oomkilladj=0 Feb 1 14:40:34 signer1 kernel: Feb 1 14:40:34 signer1 kernel: Call Trace: Feb 1 14:40:34 signer1 kernel: [] out_of_memory+0x8e/0x2f3 Feb 1 14:40:34 signer1 kernel: [] __wake_up+0x38/0x4f Feb 1 14:40:34 signer1 kernel: [] __alloc_pages+0x245/0x2ce Feb 1 14:40:34 signer1 kernel: [] read_swap_cache_async+0x45/0xd8 Feb 1 14:40:34 signer1 kernel: [] wake_bit_function+0x0/0x23 Feb 1 14:40:34 signer1 kernel: [] swapin_readahead+0x60/0xd3 Feb 1 14:40:34 signer1 kernel: [] __handle_mm_fault+0xacc/0xf99 Feb 1 14:40:34 signer1 kernel: [] do_page_fault+0x4cb/0x830 Feb 1 14:40:34 signer1 kernel: [] error_exit+0x0/0x84 Feb 1 14:40:34 signer1 kernel: Feb 1 14:40:34 signer1 kernel: Mem-info: Feb 1 14:40:34 signer1 kernel: Node 0 DMA per-cpu: Feb 1 14:40:34 signer1 kernel: cpu 0 hot: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 0 cold: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 1 hot: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 1 cold: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 2 hot: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 2 cold: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 3 hot: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 3 cold: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 4 hot: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 4 cold: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 5 hot: high 0, batch 1 used:0 Feb 1 14:40:34 signer1 kernel: cpu 5 cold: high 0, batch 1 used:0 Feb 1 14:40:35 signer1 kernel: cpu 6 hot: high 0, batch 1 used:0 Feb 1 14:40:35 signer1 kernel: cpu 6 cold: high 0, batch 1 used:0 Feb 1 14:40:35 signer1 kernel: cpu 7 hot: high 0, batch 1 used:0 Feb 1 14:40:35 signer1 kernel: cpu 7 cold: high 0, batch 1 used:0 Feb 1 14:40:35 signer1 kernel: Node 0 DMA32 per-cpu: Feb 1 14:40:35 signer1 kernel: cpu 0 hot: high 186, batch 31 used:25 Feb 1 14:40:35 signer1 kernel: cpu 0 cold: high 62, batch 15 used:43 Feb 1 14:40:35 signer1 kernel: cpu 1 hot: high 186, batch 31 used:0 Feb 1 14:40:35 signer1 kernel: cpu 1 cold: high 62, batch 15 used:0 Feb 1 14:40:35 signer1 kernel: cpu 2 hot: high 186, batch 31 used:30 Feb 1 14:40:35 signer1 kernel: cpu 2 cold: high 62, batch 15 used:47 Feb 1 14:40:35 signer1 kernel: cpu 3 hot: high 186, batch 31 used:0 Feb 1 14:40:35 signer1 kernel: cpu 3 cold: high 62, batch 15 used:0 Feb 1 14:40:35 signer1 kernel: cpu 4 hot: high 186, batch 31 used:35 Feb 1 14:40:35 signer1 kernel: cpu 4 cold: high 62, batch 15 used:58 Feb 1 14:40:35 signer1 kernel: cpu 5 hot: high 186, batch 31 used:0 Feb 1 14:40:35 signer1 kernel: cpu 5 cold: high 62, batch 15 used:0 Feb 1 14:40:35 signer1 kernel: cpu 6 hot: high 186, batch 31 used:17 Feb 1 14:40:35 signer1 kernel: cpu 6 cold: high 62, batch 15 used:51 Feb 1 14:40:35 signer1 kernel: cpu 7 hot: high 186, batch 31 used:0 Feb 1 14:40:35 signer1 kernel: cpu 7 cold: high 62, batch 15 used:0 Feb 1 14:40:35 signer1 kernel: Node 0 Normal per-cpu: Feb 1 14:40:35 signer1 kernel: cpu 0 hot: high 186, batch 31 used:3 Feb 1 14:40:35 signer1 kernel: cpu 0 cold: high 62, batch 15 used:42 Feb 1 14:40:35 signer1 kernel: cpu 1 hot: high 186, batch 31 used:0 Feb 1 14:40:35 signer1 kernel: cpu 1 cold: high 62, batch 15 used:0 Feb 1 14:40:35 signer1 kernel: cpu 2 hot: high 186, batch 31 used:13 Feb 1 14:40:36 signer1 kernel: cpu 2 cold: high 62, batch 15 used:14 Feb 1 14:40:36 signer1 kernel: cpu 3 hot: high 186, batch 31 used:0 Feb 1 14:40:36 signer1 kernel: cpu 3 cold: high 62, batch 15 used:0 Feb 1 14:40:36 signer1 kernel: cpu 4 hot: high 186, batch 31 used:123 Feb 1 14:40:36 signer1 kernel: cpu 4 cold: high 62, batch 15 used:46 Feb 1 14:40:36 signer1 kernel: cpu 5 hot: high 186, batch 31 used:0 Feb 1 14:40:36 signer1 kernel: cpu 5 cold: high 62, batch 15 used:0 Feb 1 14:40:36 signer1 kernel: cpu 6 hot: high 186, batch 31 used:18 Feb 1 14:40:36 signer1 kernel: cpu 6 cold: high 62, batch 15 used:14 Feb 1 14:40:36 signer1 kernel: cpu 7 hot: high 186, batch 31 used:0 Feb 1 14:40:36 signer1 kernel: cpu 7 cold: high 62, batch 15 used:0 Feb 1 14:40:36 signer1 kernel: Node 0 HighMem per-cpu: empty Feb 1 14:40:36 signer1 kernel: Node 1 DMA per-cpu: empty Feb 1 14:40:36 signer1 kernel: Node 1 DMA32 per-cpu: empty Feb 1 14:40:36 signer1 kernel: Node 1 Normal per-cpu: Feb 1 14:40:36 signer1 kernel: cpu 0 hot: high 186, batch 31 used:0 Feb 1 14:40:36 signer1 kernel: cpu 0 cold: high 62, batch 15 used:0 Feb 1 14:40:36 signer1 kernel: cpu 1 hot: high 186, batch 31 used:145 Feb 1 14:40:36 signer1 kernel: cpu 1 cold: high 62, batch 15 used:57 Feb 1 14:40:36 signer1 kernel: cpu 2 hot: high 186, batch 31 used:0 Feb 1 14:40:36 signer1 kernel: cpu 2 cold: high 62, batch 15 used:0 Feb 1 14:40:36 signer1 kernel: cpu 3 hot: high 186, batch 31 used:17 Feb 1 14:40:36 signer1 kernel: cpu 3 cold: high 62, batch 15 used:60 Feb 1 14:40:36 signer1 kernel: cpu 4 hot: high 186, batch 31 used:30 Feb 1 14:40:36 signer1 kernel: cpu 4 cold: high 62, batch 15 used:0 Feb 1 14:40:36 signer1 kernel: cpu 5 hot: high 186, batch 31 used:5 Feb 1 14:40:36 signer1 kernel: cpu 5 cold: high 62, batch 15 used:12 Feb 1 14:40:36 signer1 kernel: cpu 6 hot: high 186, batch 31 used:0 Feb 1 14:40:36 signer1 kernel: cpu 6 cold: high 62, batch 15 used:0 Feb 1 14:40:36 signer1 kernel: cpu 7 hot: high 186, batch 31 used:2 Feb 1 14:40:36 signer1 kernel: cpu 7 cold: high 62, batch 15 used:38 Feb 1 14:40:36 signer1 kernel: Node 1 HighMem per-cpu: empty Feb 1 14:40:36 signer1 kernel: Free pages: 45216kB (0kB HighMem) Feb 1 14:40:36 signer1 kernel: Active:2425862 inactive:1416219 dirty:0 writeback:0 unstable:0 free:11304 slab:5420 mapped-file:1543 mapped-anon:3840679 pagetables:240708 Feb 1 14:40:36 signer1 kernel: Node 0 DMA free:10880kB min:8kB low:8kB high:12kB active:0kB inactive:0kB present:10500kB pages_scanned:0 all_unreclaimable? yes Feb 1 14:40:36 signer1 kernel: lowmem_reserve[]: 0 3502 8047 8047 Feb 1 14:40:36 signer1 kernel: Node 0 DMA32 free:21644kB min:3528kB low:4408kB high:5292kB active:1746380kB inactive:1572836kB present:3586464kB pages_scanned:7384686 all_unreclaimable? yes Feb 1 14:40:36 signer1 kernel: lowmem_reserve[]: 0 0 4545 4545 Feb 1 14:40:36 signer1 kernel: Node 0 Normal free:4552kB min:4576kB low:5720kB high:6864kB active:2193936kB inactive:2097072kB present:4654080kB pages_scanned:8441309 all_unreclaimable? yes Feb 1 14:40:36 signer1 kernel: lowmem_reserve[]: 0 0 0 0 Feb 1 14:40:36 signer1 kernel: Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no Feb 1 14:40:36 signer1 kernel: lowmem_reserve[]: 0 0 0 0 Feb 1 14:40:36 signer1 kernel: Node 1 DMA free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no Feb 1 14:40:36 signer1 kernel: lowmem_reserve[]: 0 0 8080 8080 Feb 1 14:40:36 signer1 kernel: Node 1 DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no Feb 1 14:40:36 signer1 kernel: lowmem_reserve[]: 0 0 8080 8080 Feb 1 14:40:36 signer1 kernel: Node 1 Normal free:8140kB min:8140kB low:10172kB high:12208kB active:5776148kB inactive:1981472kB present:8273920kB pages_scanned:13423603 all_unreclaimable? yes Feb 1 14:40:36 signer1 kernel: lowmem_reserve[]: 0 0 0 0 Feb 1 14:40:36 signer1 kernel: Node 1 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no Feb 1 14:40:36 signer1 kernel: lowmem_reserve[]: 0 0 0 0 Feb 1 14:40:36 signer1 kernel: Node 0 DMA: 4*4kB 2*8kB 2*16kB 4*32kB 3*64kB 2*128kB 0*256kB 0*512kB 2*1024kB 0*2048kB 2*4096kB = 10880kB Feb 1 14:40:36 signer1 kernel: Node 0 DMA32: 3*4kB 0*8kB 0*16kB 2*32kB 1*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 5*4096kB = 21644kB Feb 1 14:40:36 signer1 kernel: Node 0 Normal: 2*4kB 10*8kB 1*16kB 1*32kB 1*64kB 2*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 4552kB Feb 1 14:40:36 signer1 kernel: Node 0 HighMem: empty Feb 1 14:40:36 signer1 kernel: Node 1 DMA: empty Feb 1 14:40:36 signer1 kernel: Node 1 DMA32: empty Feb 1 14:40:36 signer1 kernel: Node 1 Normal: 3*4kB 4*8kB 4*16kB 1*32kB 1*64kB 2*128kB 0*256kB 1*512kB 1*1024kB 1*2048kB 1*4096kB = 8140kB Feb 1 14:40:36 signer1 kernel: Node 1 HighMem: empty Feb 1 14:40:36 signer1 kernel: 2181 pagecache pages Feb 1 14:40:36 signer1 kernel: Swap cache: add 12583314, delete 12583048, find 2552/3863, race 1+2 Feb 1 14:40:36 signer1 kernel: Free swap = 0kB Feb 1 14:40:37 signer1 kernel: Total swap = 16779884kB Feb 1 14:40:37 signer1 kernel: Free swap: 0kB Feb 1 14:40:37 signer1 kernel: 4325375 pages of RAM Feb 1 14:40:37 signer1 kernel: 216985 reserved pages Feb 1 14:40:37 signer1 kernel: 3859 pages shared Feb 1 14:40:37 signer1 kernel: 491 pages swap cached Feb 1 14:40:37 signer1 kernel: Out of memory: Killed process 20064 (quicksorter). -----Original Message----- From: Bj?rn Stenberg [mailto:bjorn at haxx.se] Sent: maandag 1 februari 2010 13:43 To: Rick Zijlker Cc: Rickard Bellgrim; Opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] Test the new sorter Rick Zijlker wrote: > The quicksorter keeps getting killed Interesting. The time signature suggests it spent considerable time swapping memory to disk. That certainly sounds like a bug in quicksorter. Try changing line 50 to "#if 1" to enable some debug output. Is there any way I can get a copy of a file that triggers this behaviour? -- Bj?rn From rickard.bellgrim at iis.se Mon Feb 1 14:44:47 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 1 Feb 2010 15:44:47 +0100 Subject: [Opendnssec-develop] Roadmap Message-ID: <983F17705339E24699AA251B458249B527EF102355@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi This is a summary of what we decided during the previous meeting. The roadmap is also available on http://www.opendnssec.org/about/release-plan/ OpenDNSSEC 1.1 (March) * Performance improvements for large zones * Performance improvements for large numbers of zones * Clarification to the KSK rollover process * Different auditing levels * Configurable auditing program * Improved registrar support (EPP client plugin) OpenDNSSEC 1.2 (May) * Improved handling of shared keys * Only the private key object on the HSM is needed, will save space * Replace the Python engine with a C engine. OpenDNSSEC 1.3 (July) * Working with internal structures instead of temporary files. OpenDNSSEC 2.0 * Zone transfers using IXFR and dynamic updates * Continuous signing * Better flow of information within the signer * Powerfail/crash recovery * Web interface? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2bo3+CjgaNTdVjaAQiswgf+Md8KEqHY1jNDClcIUnQNysR+0e7m4fFR Nf0v27Ep6Ha3CiZT1hMP+RfIe6u3uTNfv9Ks8PUzE3d9DVFMljujf8YLPya2wK04 5aCnKSnETI+mepq3IzsEA9FcvDg9cLkN0viDc8tBZJF9+Aklh497qflBOjeiPw78 /BX5YFA0/Lqfc87mVm+4apA7uZ1uyaxKmtzXff+mInKoVmzYma+PKOf+Co7V7+XC b5xULA0Z24pPR6H7Dl0J5xbSUHejlxgfR2ngmWh7HzCGtuZQM2WsPE43UstT/vTt DlvnklOURXva90oOR9NRo36LECTg9uNPQCkuPPmRsgVqM8mPMNzFEg== =2Mig -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Mon Feb 1 15:01:07 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Feb 2010 15:01:07 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #83: --version prints OPENDNSSEC_VERSION In-Reply-To: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> References: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> Message-ID: <074.1449c075c28aa79992e835d11bfb2ed5@kirei.se> #83: --version prints OPENDNSSEC_VERSION ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: assigned Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): What about simple: {{{ $ svn diff autogen.sh Index: autogen.sh =================================================================== --- autogen.sh (revision 2761) +++ autogen.sh (working copy) @@ -2,4 +2,9 @@ # # $Id$ +SUBDIRS="auditor libhsm enforcer signer conf" +for SUBDIR in ${SUBDIRS}; do + ln version.m4 ${SUBDIR}/version.m4 +done + autoreconf --install --force }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Feb 1 19:12:35 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Feb 2010 19:12:35 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #83: --version prints OPENDNSSEC_VERSION In-Reply-To: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> References: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> Message-ID: <074.7c803fbf4b6c0180a0da0c82bc645cff@kirei.se> #83: --version prints OPENDNSSEC_VERSION ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: closed Priority: minor | Component: Auditor Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by jakob): * status: assigned => closed * resolution: => fixed Comment: Thanks, I hope this is sorted out now. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Feb 2 08:21:36 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Feb 2010 08:21:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #84: --version prints OPENDNSSEC_VERSION if you run autoreconf In-Reply-To: <065.05df7ea1f63639b118e7043287fdc43e@kirei.se> References: <065.05df7ea1f63639b118e7043287fdc43e@kirei.se> Message-ID: <074.abda3a19443cb197cef0837c17d72817@kirei.se> #84: --version prints OPENDNSSEC_VERSION if you run autoreconf ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): Is this still present with the fix from http://trac.opendnssec.org/ticket/83 ? -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Feb 2 08:31:03 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 2 Feb 2010 09:31:03 +0100 Subject: [Opendnssec-develop] Test the new sorter In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local> References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> <20100201124258.GA14993@giant> <850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local> Message-ID: <983F17705339E24699AA251B458249B527EF102410@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I can't remember if you have told us this before. Could you perhaps tell us some more about your system? What hardware are you running? What OS do you run on? Do run a 64-bit OS with 64-bit software? Is it possible to have some form of non-disclosure agreement so that we in the project can test with your zone? It would help us to improve the performance for you. // Rickard > Unfortunately I cannot supply a copy of the file I tested with. It's > the .nl zone. > > I did enable the debug output. Apparently it runs out of memory. The > test server has 16 GB's of RAM. I believe the logging below shows the > entire 'kill'. If not, please let me know. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2fix+CjgaNTdVjaAQiIlAf/crrg9P1yf0Depfph1XTI1w0UZUjROEN5 qKtgFqzCA9WhyQ0M0CejiO+lmGFfC8+NtXdWFa8hS23VW25gFM0me/+/7CFVNy22 xrlK3cZyDSxK/dFmxr7kT5zc26kl3tRaCAkFj0aDRp8h+6evTSO7cQ8Y6atTgdrs QnGhDvtH/mcag5ah7M5tEKY3sw8xoj8Ot/c+vHL7z7jHF0zBkD9kjazEy61vFmcd 6YOdxD3So/C9xkYipEYcaS18S9dlRIE7jmJ9epx/cpppiBy9b+0LsqNHjl2DawM7 w42zbCUNHTSiNLb+i8A6e2Zgi3Uf4dpcdkP8StQqp4Q6UgmmXZimkQ== =Rtk/ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at haxx.se Tue Feb 2 08:34:17 2010 From: bjorn at haxx.se (=?iso-8859-1?Q?Bj=F6rn?= Stenberg) Date: Tue, 2 Feb 2010 09:34:17 +0100 Subject: [Opendnssec-develop] Test the new sorter In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local> References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> <20100201124258.GA14993@giant> <850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local> Message-ID: <20100202083417.GC14993@giant> Rick Zijlker wrote: > I did enable the debug output. Apparently it runs out of memory. Indeed it did. Lines that need expansion grabbed a full 64 KB each... I have now committed an update: http://trac.opendnssec.org/export/2772/home/bjst/quicksorter.c Thank you for testing. -- Bj?rn From rick.zijlker at sidn.nl Tue Feb 2 10:26:29 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Tue, 2 Feb 2010 11:26:29 +0100 Subject: [Opendnssec-develop] Test the new sorter References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> <20100201124258.GA14993@giant> <850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local> <983F17705339E24699AA251B458249B527EF102410@EXCHANGE2K7.office.nic.se> Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86A8@KAEVS1.SIDN.local> Hey Rickard, We have 2 identical test servers: - HP ProLiant DL360 G6 - 8 core 2Ghz - 16GB RAM - Red Hat 5.4 - 64bit NLNetLabs has access to one of our slaves. So Matthijs has a copy of our zone and will use it while optimizing the zone_reader. Which means the zone is accessible by the project. I?m not sure if it?s possible to supply our zone to you as well. I will have to check this with the designated persons. Cheers, Rick From: Rickard Bellgrim [mailto:rickard.bellgrim at iis.se] Sent: dinsdag 2 februari 2010 9:31 To: Rick Zijlker; Bj?rn Stenberg Cc: Opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] Test the new sorter -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I can't remember if you have told us this before. Could you perhaps tell us some more about your system? What hardware are you running? What OS do you run on? Do run a 64-bit OS with 64-bit software? Is it possible to have some form of non-disclosure agreement so that we in the project can test with your zone? It would help us to improve the performance for you. // Rickard > Unfortunately I cannot supply a copy of the file I tested with. It's > the .nl zone. > > I did enable the debug output. Apparently it runs out of memory. The > test server has 16 GB's of RAM. I believe the logging below shows the > entire 'kill'. If not, please let me know. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2fix+CjgaNTdVjaAQiIlAf/crrg9P1yf0Depfph1XTI1w0UZUjROEN5 qKtgFqzCA9WhyQ0M0CejiO+lmGFfC8+NtXdWFa8hS23VW25gFM0me/+/7CFVNy22 xrlK3cZyDSxK/dFmxr7kT5zc26kl3tRaCAkFj0aDRp8h+6evTSO7cQ8Y6atTgdrs QnGhDvtH/mcag5ah7M5tEKY3sw8xoj8Ot/c+vHL7z7jHF0zBkD9kjazEy61vFmcd 6YOdxD3So/C9xkYipEYcaS18S9dlRIE7jmJ9epx/cpppiBy9b+0LsqNHjl2DawM7 w42zbCUNHTSiNLb+i8A6e2Zgi3Uf4dpcdkP8StQqp4Q6UgmmXZimkQ== =Rtk/ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Feb 2 10:42:18 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 2 Feb 2010 11:42:18 +0100 Subject: [Opendnssec-develop] Test the new sorter In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86A8@KAEVS1.SIDN.local> References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> <20100201124258.GA14993@giant> <850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local> <983F17705339E24699AA251B458249B527EF102410@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A8@KAEVS1.SIDN.local> Message-ID: <983F17705339E24699AA251B458249B527EF1024AE@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > NLNetLabs has access to one of our slaves. So Matthijs has a copy of > our > zone and will use it while optimizing the zone_reader. Which means the > zone is accessible by the project. I?m not sure if it?s possible to > supply our zone to you as well. I will have to check this with the > designated persons. Ok, good. Then it is easier for Matthijs to help you. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2gBiuCjgaNTdVjaAQh6rQf/V7qz9W2Sj3hI9wRmut167G7vChNx5p8m cInsqEifLXZbew95W/Ull1TQBzXPyZChMWJiyBk6gZ4nQVSK/fwyO2MwMhhp7AJ6 rjx99AGBp1KczBUtKRaU4z8CVQVtRVjJrhVHvPwxKk/gBkLG5EjJMAijdZHg1NIC qmYoKfFFu5uckVnzc5fpKAP8U6pbA/E6y8T4ofPjlXBI4qNJRO4qRVYC83ekI6hX 3TKUnUmu4OJ3L0KfLhBVyAfrM+QXQtZOnvW8vVr2pj/OzI9NTe7+JY1y7HNLqsAQ qjU74JpQeR5LTF0JgShhxOWmTbjz3GzcfiFK3ZyUgHHnC1x7sIDU0g== =/j9m -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Tue Feb 2 11:22:37 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 2 Feb 2010 11:22:37 +0000 Subject: [Opendnssec-develop] OpenDNSSEC 1.1 aims at registries In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86A8@KAEVS1.SIDN.local> References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> <20100201124258.GA14993@giant> <850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local> <983F17705339E24699AA251B458249B527EF102410@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A8@KAEVS1.SIDN.local> Message-ID: <20100202112237.GD23150@phantom.vanrein.org> Hi Rick, I'm not sure if people have told you -- during last week's meeting we discussed the future path for OpenDNSSEC and concluded that 1.1 was going to be fit for registries -- so it'll includes lots of efficiency improvements for larger zones. Also, specifically to accommodate SIDN, the 1.1 release is scheduled to occur in _early_ March. Cheers, -Rick From owner-dnssec-trac at kirei.se Tue Feb 2 12:01:57 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Feb 2010 12:01:57 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #85: Please provide manpages In-Reply-To: <065.f44b4f339eff1d911e7e95ac5e5d6265@kirei.se> References: <065.f44b4f339eff1d911e7e95ac5e5d6265@kirei.se> Message-ID: <074.1d75309a5a39a36c2b2b3be0905dd1a4@kirei.se> #85: Please provide manpages ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: closed Priority: minor | Component: Auditor Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thank you. All of the commands now have man-pages, but some of them does not include any information. Just saying "No information yet. Will be updated in a future release." They will be updated real soon. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Feb 2 12:03:14 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 2 Feb 2010 13:03:14 +0100 Subject: [Opendnssec-develop] RC4 Message-ID: <983F17705339E24699AA251B458249B527EF1024DD@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Are we ready for a RC4 tonight? We are waiting for dnsruby 1.43. Should we require 1.43 in the configure script? The man-pages has been added, but some of them do not have any content (ods-control, ods-hsmutil, ods-hsmspeed). Is there something more? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2gUguCjgaNTdVjaAQiRhgf/aRWT8hS71rwTTvM0caBodTOrxtbJvJRA 5zoYdTqRSN9jfnpDTSnhndgRsR5CGpFD9SBVloxnrzl6kOXNzPIgzgaCjR8X2zkv 6aOzT+6jp17mdXnq8/9VFc696c02bvX1RWNnvqv3n8xuJ06OL+EE0467jj/Eu8/a H68aYlAcJqx/a7721MDOwG/x5pJSle670SPMlQCjKpg2UpLGiBKDwiUkFkwj/CrZ 2XhF5CzRHvXmMiwpIBEqEeOK5eJHrE6EN1Cv5mxwcsSV2Ttv8rYTBX1H42NcGMZz JZ1UjobDpax6OadA7uod7M7eQBzRQlt+VrDtNKbd89i1uX6EG+gaaA== =j6Wj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Tue Feb 2 12:05:01 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Tue, 2 Feb 2010 12:05:01 +0000 Subject: [Opendnssec-develop] RC4 In-Reply-To: <983F17705339E24699AA251B458249B527EF1024DD@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EF1024DD@EXCHANGE2K7.office.nic.se> Message-ID: > We are waiting for dnsruby 1.43. Should we require 1.43 in the > configure script? Yes. It's been released already, but may take a little time to show up. It fixes outstanding issues with crazy NAPTR records. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Tue Feb 2 12:47:40 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 02 Feb 2010 13:47:40 +0100 Subject: [Opendnssec-develop] RC4 In-Reply-To: <983F17705339E24699AA251B458249B527EF1024DD@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EF1024DD@EXCHANGE2K7.office.nic.se> Message-ID: <4B681EEC.9090200@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think the contents of the man-pages can be filled in between RC4 and v1.0 Matthijs Rickard Bellgrim wrote: > Hi > > Are we ready for a RC4 tonight? > > We are waiting for dnsruby 1.43. Should we require 1.43 in the configure > script? > The man-pages has been added, but some of them do not have any content > (ods-control, ods-hsmutil, ods-hsmspeed). > > Is there something more? > > // Rickard > - ------------------------------------------------------------------------ _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLaB7qAAoJEA8yVCPsQCW5DLgIALCM8w6vtx7oajlRccYj78GR CODUlnLJndFS00FC3K6sj22lj3zSC20DiFymJQKgmx1sUfGf5K+N/tLaXCMtbOIY BATAFcl2rvLSfj4enue5NWBvj1o9Dt+AKrkmAqxXDxg2JCc048GifTf0JHxEMY8+ miLR+k3a4lRlDkep+d8NcazrZVbH1dvuZmmSdVtHMD4f5p5LFJP/7P0zgOmrpIxL MqdEjlAJcvfyJLpDhcgm2jH+s7atjuHBppsN8Vh4Ea7GdJ5VSMwCn3gG/puYplQp 40XpaVnQ1AmDqi3Vj3mQSZ8nCLsPKHYj6zIp5VVy+AfiZcyuUFc/k4wm4V8XouI= =g0wr -----END PGP SIGNATURE----- From rick.zijlker at sidn.nl Tue Feb 2 12:49:19 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Tue, 2 Feb 2010 13:49:19 +0100 Subject: [Opendnssec-develop] Test the new sorter References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> <20100201124258.GA14993@giant> <850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local> <20100202083417.GC14993@giant> Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86AB@KAEVS1.SIDN.local> Hey Bj?rn, I ran the newly committed quicksorter and it didn't crash. Also nice performance! [root at signer1 rick]# time ./quicksorter -f ./nl -w ./nl.sorted -m 3600 -t 3600 -o nl. real 0m50.035s user 0m47.859s sys 0m1.192s I'm gonna check the output files now. Cheers, Rick -----Original Message----- From: Bj?rn Stenberg [mailto:bjorn at haxx.se] Sent: dinsdag 2 februari 2010 9:34 To: Rick Zijlker Cc: Opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] Test the new sorter Rick Zijlker wrote: > I did enable the debug output. Apparently it runs out of memory. Indeed it did. Lines that need expansion grabbed a full 64 KB each... I have now committed an update: http://trac.opendnssec.org/export/2772/home/bjst/quicksorter.c Thank you for testing. -- Bj?rn From owner-dnssec-trac at kirei.se Tue Feb 2 13:24:49 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Feb 2010 13:24:49 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #84: --version prints OPENDNSSEC_VERSION if you run autoreconf In-Reply-To: <065.05df7ea1f63639b118e7043287fdc43e@kirei.se> References: <065.05df7ea1f63639b118e7043287fdc43e@kirei.se> Message-ID: <074.2768bdb1fa554ede3fa4cd410eb8462d@kirei.se> #84: --version prints OPENDNSSEC_VERSION if you run autoreconf ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Please close, this is duplicate due some network lag (clicked on Submit changes twice). -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Feb 2 13:28:03 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Feb 2010 13:28:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #84: --version prints OPENDNSSEC_VERSION if you run autoreconf In-Reply-To: <065.05df7ea1f63639b118e7043287fdc43e@kirei.se> References: <065.05df7ea1f63639b118e7043287fdc43e@kirei.se> Message-ID: <074.01f040a4dafa12b0e2cc2558e7d5fb4d@kirei.se> #84: --version prints OPENDNSSEC_VERSION if you run autoreconf ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: closed Priority: minor | Component: Auditor Version: trunk | Resolution: duplicate Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => duplicate -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Feb 2 13:56:02 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Feb 2010 13:56:02 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #90: Extra symbols in libhsm Message-ID: <065.d9f2da5f94fdaf6c8aa6909b7138e9ae@kirei.se> #90: Extra symbols in libhsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: new Priority: minor | Component: libhsm Version: trunk | Keywords: ------------------------------------------+--------------------------------- You probably don't want to export those symbols into a public interface. {{{ strlcat at Base 1.0.0~rc3 strlcpy at Base 1.0.0~rc3 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Feb 2 14:02:33 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Feb 2010 14:02:33 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #90: Extra symbols in libhsm In-Reply-To: <065.d9f2da5f94fdaf6c8aa6909b7138e9ae@kirei.se> References: <065.d9f2da5f94fdaf6c8aa6909b7138e9ae@kirei.se> Message-ID: <074.1728c2b53c9cb0bec59b468b8ad979eb@kirei.se> #90: Extra symbols in libhsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: assigned Priority: minor | Component: libhsm Version: trunk | Keywords: ------------------------------------------+--------------------------------- Changes (by jakob): * status: new => assigned Comment: correct, this is bad. can you suggest how to fix this issue? we still want the compat code linked into the library of course. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick.zijlker at sidn.nl Tue Feb 2 14:06:15 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Tue, 2 Feb 2010 15:06:15 +0100 Subject: [Opendnssec-develop] Test the new sorter References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se><850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local><20100201124258.GA14993@giant><850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local><20100202083417.GC14993@giant> <850A39016FA57A4887C0AA3C8085F949014D86AB@KAEVS1.SIDN.local> Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86AC@KAEVS1.SIDN.local> Even though the filesizes differ slightly: -rw-r--r-- 1 root root 396950665 Feb 2 13:27 nl.sorted -rw-r--r-- 1 root root 396950529 Feb 1 11:00 nl.sorted2 The contents are identical apart from some tabs. For instance the SOA RR: Quicksorter: [root at signer1 rick]# more nl.sorted|grep SOA nl. 7200 IN SOA ns1.nic.nl. hostmaster.domain-registry.nl. 2009111707 7200 900 2419200 900 Sorter: [root at signer1 rick]# more nl.sorted2|grep SOA nl. 7200 IN SOA ns1.nic.nl. hostmaster.domain-registry.nl. 2009111707 7200 900 2419200 900 Great performance boost. Hopefully a similar boost can be achieved with the processing part. Cheers, Rick -----Original Message----- From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Rick Zijlker Sent: dinsdag 2 februari 2010 13:49 To: Bj?rn Stenberg Cc: Opendnssec-develop at lists.opendnssec.org Subject: RE: [Opendnssec-develop] Test the new sorter Hey Bj?rn, I ran the newly committed quicksorter and it didn't crash. Also nice performance! [root at signer1 rick]# time ./quicksorter -f ./nl -w ./nl.sorted -m 3600 -t 3600 -o nl. real 0m50.035s user 0m47.859s sys 0m1.192s I'm gonna check the output files now. Cheers, Rick -----Original Message----- From: Bj?rn Stenberg [mailto:bjorn at haxx.se] Sent: dinsdag 2 februari 2010 9:34 To: Rick Zijlker Cc: Opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] Test the new sorter Rick Zijlker wrote: > I did enable the debug output. Apparently it runs out of memory. Indeed it did. Lines that need expansion grabbed a full 64 KB each... I have now committed an update: http://trac.opendnssec.org/export/2772/home/bjst/quicksorter.c Thank you for testing. -- Bj?rn _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From bjorn at haxx.se Tue Feb 2 14:38:11 2010 From: bjorn at haxx.se (=?iso-8859-1?Q?Bj=F6rn?= Stenberg) Date: Tue, 2 Feb 2010 15:38:11 +0100 Subject: [Opendnssec-develop] Test the new sorter In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86AC@KAEVS1.SIDN.local> References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <850A39016FA57A4887C0AA3C8085F949014D86A5@KAEVS1.SIDN.local> <20100201124258.GA14993@giant> <850A39016FA57A4887C0AA3C8085F949014D86A7@KAEVS1.SIDN.local> <20100202083417.GC14993@giant> <850A39016FA57A4887C0AA3C8085F949014D86AB@KAEVS1.SIDN.local> <850A39016FA57A4887C0AA3C8085F949014D86AC@KAEVS1.SIDN.local> Message-ID: <20100202143811.GE21218@giant> Rick Zijlker wrote: > The contents are identical apart from some tabs. For instance the SOA RR: Yes, for performance reasons the lines are simply concatenated, which causes the resulting single line to be rather long. > Great performance boost. Hopefully a similar boost can be achieved with the > processing part. Thank you. Unfortunately Ray Bellis found that RDATA comparison is done incorrectly, so you should not rely on quicksorter until I have fixed that. -- Bj?rn From rickard.bellgrim at iis.se Tue Feb 2 15:26:40 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 2 Feb 2010 16:26:40 +0100 Subject: [Opendnssec-develop] Re: RC4 In-Reply-To: <983F17705339E24699AA251B458249B527EF1024DD@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EF1024DD@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B527EF1025B2@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > The man-pages has been added, but some of them do not have any content > (ods-control, ods-hsmutil, ods-hsmspeed). All of the man-pages now have text in them. There remains two thing: 1. How to handle the licenses for the man-pages Currently is says: ************************* .\" Copyright (c) 2010, OpenDNSSEC. All rights reserved. .\" See LICENSE for the license. ************************* There is no OpenDNSSEC entity. And no LICENSE file. Do you need a license in a man-page? 2. Substitute e.g. /etc/opendnssec/conf.xml with @opendnssecsysconfdir@/conf.xml (+ AC_SUBST) Can this wait for 1.0.0? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2hEMOCjgaNTdVjaAQgXDgf/XuhnsGF+ziuS5E1k6WL19QMXwbIFrQaS GcVjavi8g/HkYt22Jx5XCYl31lbtQ5oDvZrBzjKWpyD7ryZknwfl5Fjstv5MWQg2 +mVjoli++CutgTkpE5RY2CtRroMPZGBsIVLYP/FMwyJhVxy4KxSvdZI9vRlWhBsr svADIOnFAd4BjlYTF99ndlQWjCeX7J0u9+Q/yzKgzX3KvPYUGTur6mzNiV8520xD YAgjPt2ssNkWVAhjqazD7CmNTaqSw8bxPjDF0g7IYmni/JPi2UCt4JrIRalTaXAP ptRI9YaPC+LH/wx2Le9862eMbZguGruEv9h21qBetTQcqp5aqN1tmg== =R0DN -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Tue Feb 2 15:30:14 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Feb 2010 15:30:14 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #91: Extra symbols in libsofthsm Message-ID: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> #91: Extra symbols in libsofthsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- There is a lot of extra symbols in libsofthsm.so.1.*: Lot of symbols starting with _ZN like: {{{ _Z10logWarningPKcS0_ at Base 1.1.3 _Z14readConfigFilev at Base 1.1.3 ... }}} {{{ function_list at Base 1.1.3 softHSM at Base 1.1.3 softHSMCreateMutex at Base 1.1.3 softHSMDestroyMutex at Base 1.1.3 softHSMLockMutex at Base 1.1.3 softHSMUnlockMutex at Base 1.1.3 }}} I guess you want to export just PKCS#11 functions? Somehow same approach as in #90 doesn't work for softhsm. Maybe there's something wrong with g++ linker: {{{ libtool: link: g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux- gnu/4.4.3/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux- gnu/4.4.3/crtbeginS.o .libs/main.o .libs/mutex.o .libs/file.o .libs/log.o .libs/attribute.o .libs/userhandling.o .libs/tokenhandling.o .libs/mechanisms.o .libs/SoftHSMInternal.o .libs/SoftSlot.o .libs/SoftSession.o .libs/SoftFind.o .libs/SoftDatabase.o .libs/SoftKeyStore.o -L/usr/local/lib -lbotan /usr/lib/libsqlite3.so -lpthread -ldl -lrt -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crtn.o -m64 -m64 -Wl,-soname -Wl,libsofthsm.so.1 -Wl,-retain-symbols-file -Wl,pkcs11.sym -o .libs/libsofthsm.so.1.0.4 }}} This command still produces _ZN* junk. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Feb 2 15:31:58 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Feb 2010 15:31:58 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #90: Extra symbols in libhsm In-Reply-To: <065.d9f2da5f94fdaf6c8aa6909b7138e9ae@kirei.se> References: <065.d9f2da5f94fdaf6c8aa6909b7138e9ae@kirei.se> Message-ID: <074.e168b09f97dd26856aab8b2a0622290b@kirei.se> #90: Extra symbols in libhsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: assigned Priority: minor | Component: libhsm Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Attached patch works fine for me. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at openfortress.nl Tue Feb 2 16:05:31 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 2 Feb 2010 16:05:31 +0000 Subject: [Opendnssec-develop] Re: RC4 In-Reply-To: <983F17705339E24699AA251B458249B527EF1025B2@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EF1024DD@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B527EF1025B2@EXCHANGE2K7.office.nic.se> Message-ID: <20100202160531.GB30509@phantom.vanrein.org> Hi, > Currently is says: > ************************* > .\" Copyright (c) 2010, OpenDNSSEC. All rights reserved. > .\" See LICENSE for the license. > ************************* > > There is no OpenDNSSEC entity. And no LICENSE file. Heheh, the LICENSE file is a good idea. As for the entity, I've also seen places where "The XYZ project" is referenced, possibly together with its online address. BTW, I don't think there's going to be a doubt about the meaning of this non-existent entity in the mind of a judge. Even a jury is likely to understand what we mean. > Do you need a license in a man-page? No idea. I never bother. You are welcome to remove them from the manpages I wrote; they're just there as a result of LDNS' template. > 2. Substitute e.g. /etc/opendnssec/conf.xml with @opendnssecsysconfdir@/conf.xml (+ AC_SUBST) Good thinking, albeit a somewhat long name ;-) > Can this wait for 1.0.0? I'd say make a pragmatic choice now, then tag RC4 and if we decide to panic over these matters we can still fix them before 1.0. I doubt they're worth the attention, really. Hope this helps, -Rick From owner-dnssec-trac at kirei.se Tue Feb 2 16:16:07 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Feb 2010 16:16:07 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #91: Extra symbols in libsofthsm In-Reply-To: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> References: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> Message-ID: <074.3dbae32c26627fe7549039d20c68c7af@kirei.se> #91: Extra symbols in libsofthsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): I have confirmed that it looks like a bug in libtool, if I change --tag to CC, then it correctly strips symbols according to pkcs11.sym. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Feb 2 16:21:28 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Feb 2010 16:21:28 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #91: Extra symbols in libsofthsm In-Reply-To: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> References: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> Message-ID: <074.b752cc9c4a12d4c3ad6265a745b49b4f@kirei.se> #91: Extra symbols in libsofthsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): See also: http://bugs.debian.org/430971 -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Feb 2 16:50:09 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 2 Feb 2010 17:50:09 +0100 Subject: [Opendnssec-develop] Re: RC4 In-Reply-To: <20100202160531.GB30509@phantom.vanrein.org> References: <983F17705339E24699AA251B458249B527EF1024DD@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B527EF1025B2@EXCHANGE2K7.office.nic.se> <20100202160531.GB30509@phantom.vanrein.org> Message-ID: <983F17705339E24699AA251B458249B527EF1025E1@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > No idea. I never bother. You are welcome to remove them from the > manpages I wrote; they're just there as a result of LDNS' template. Removed > I'd say make a pragmatic choice now, then tag RC4 and if we decide to > panic over these matters we can still fix them before 1.0. I doubt > they're worth the attention, really. There is a new story for this in Pivotal. I think OpenDNSSEC is ready for RC4. No test is failing. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2hXweCjgaNTdVjaAQj++Af/XcMtECjZMj5rIE54kv4O+CRArWjrlmV7 +Xoe1TYry2M6HsP/Q0BiIl4yGQGOtd7bsMMFgiEcuY6VJrbLW04Xt1ljX1UhZZuO UVHuRU6ExuYSp9R5mAwbfMKGN0hRl7GdvbSHNZCxLRmx8jnumyKhNdkA7FQAW5jH /24AHthK3BFzOARhU0PpEiXK/yRrlLphkAZNzBPHfBCdDudLV4ggBuV5nm9OXSPa 4TZHfJk26NLmzC5ca3u+dHlbCbqIFiAM0X5djTzKUZ/aO3/KAu/rLePkyZ2eBEEV wj5viECcy0JsMpsZWsUrtBadHcLwhC+XbUpUAI+0ASheJSOK+Ue+tA== =DX7c -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Wed Feb 3 09:30:19 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 3 Feb 2010 09:30:19 +0000 Subject: [Opendnssec-develop] Fw: [dnsext] Question on NAPTR text format Message-ID: I asked namedroppers for opinion on the /D notation in resource records (as discussed last week on this list). The response (below) seems to be that this is an error. Should we update ldns and dnsruby with this behaviour, so that they at least behave consistently when confronted with this invalid notation? Thanks, Alex. ----- Forwarded by Alex Dalitz/Nominet on 03/02/2010 09:28 ----- Donald Eastlake wrote on 02/02/2010 23:10:40: > Donald Eastlake > 02/02/2010 23:10 > > To > > Alexd at nominet.org.uk > > cc > > namedroppers at ops.ietf.org > > Subject > > Re: [dnsext] Question on NAPTR text format > > Right, see RFC 4343: > "A back-slash followed by only one or two decimal digits is undefined" > > Donald > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com > > On Tue, Feb 2, 2010 at 4:33 PM, Mark Andrews wrote: > > In message 004271B4 at nominet.or > g.uk>, Alexd at nominet.org.uk writes: > > Hi - > > > > I'm hoping somebody can please help me understand how to treat the > > following text in a NAPTR/TXT record : > > > > "blah\2blah" > > > > We have from RFC 1035 : > > > > \X where X is any character other than a digit (0-9), is > > used to quote that character so that its special meaning > > does not apply. For example, "\." can be used to place > > a dot character in a label. > > > > and > > > > \DDD where each D is a digit is the octet corresponding to > > the decimal number described by DDD. The resulting > > octet is assumed to be text and is not checked for > > special meaning. > > > > So what happens if there is only one digit, instead of three? (i.e. \D) > > > > Should this be taken as : > > > > 1) a one digit decimal number specifying an octet between 0 and 9 (e.g. > > \002) > > 2) the number character itself (e.g. '2') > > 3) an error? > It's a error because it is undefined. > > > I've noticed that different libraries take different views on this, and > > thought it would be nice to have more common behaviour. > > > > Thanks in advance for your help! > > > > Alex. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Wed Feb 3 09:57:24 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 3 Feb 2010 10:57:24 +0100 Subject: [Opendnssec-develop] Code sprint in April (Doodle) Message-ID: <983F17705339E24699AA251B458249B527EF1026D0@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi We would like to have a 4-day code sprint in April, Stockholm. Please vote on your preferred dates here: http://www.doodle.com/xtz423qyscw35ahz // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2lIhOCjgaNTdVjaAQh7/Qf/X4DH68wPpPaF13tk5cXriRWmuzWvkWl5 ifueUvPqMfUpU1Vvc/vuuX59Q70oYwpOzlygt5YCJyFDBEZoT87cAsdu4MxM9MCM +PjLZz5XstvxTb69iCPAi6VyRpzSGCpfWzKF1aomiok2vSZVO/3clO59BdR9s3m2 4lSZykW5lEn832oRivB0zSkDJQELQ6t20np8e6aW5qcaqwJmfMh95C+uofY4aqyM hVUIOKHI/c3VEfVq+Zm2vXlR2e85Bn0rataLsAcziAt1HPXyzrid+ZEVKifMrkb0 nFFjy4ieTPLAjaU0uceynYfff50srULXEsZ+2H+YCSsnUlWp8s7jOg== =ibye -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Wed Feb 3 10:07:12 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 3 Feb 2010 10:07:12 +0000 Subject: [Opendnssec-develop] 1.0.1 release Message-ID: Morning, taking pivotal as our reference Alex and I have been looking at the work scheduled for the 1.0.1 release. Given that 1.1.0 will follow 1.0.0 by about 4 weeks (hopefully), and most of the scheduled work has been known about for that long, can we really say that they can't wait for 1.1.0? Also; given the amount of work to be done for 1.1.0 and the timeframe involved, would it be a good time to branch and so open trunk for work again? Sion p.s. Sorry if this was all discussed in the meeting last week, I'm not aiming to restart any arguments. From jakob at kirei.se Wed Feb 3 10:07:14 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 3 Feb 2010 11:07:14 +0100 Subject: [Opendnssec-develop] Fw: [dnsext] Question on NAPTR text format In-Reply-To: References: Message-ID: <21BA0FE9-64B1-4825-A488-87FD3D4C4EBD@kirei.se> On 3 feb 2010, at 10.30, Alexd at nominet.org.uk wrote: > I asked namedroppers for opinion on the /D notation in resource records (as discussed last week on this list). > > The response (below) seems to be that this is an error. > > Should we update ldns and dnsruby with this behaviour, so that they at least behave consistently when confronted with this invalid notation? yes, I think so. it is not critical for 1.0, but it should be fixed. jakob From rick at openfortress.nl Wed Feb 3 10:12:26 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 3 Feb 2010 10:12:26 +0000 Subject: [Opendnssec-develop] 1.0.1 release In-Reply-To: References: Message-ID: <20100203101226.GC18800@phantom.vanrein.org> Sion, > Given that 1.1.0 will follow 1.0.0 by about 4 weeks (hopefully), and most > of the scheduled work has been known about for that long, can we really say > that they can't wait for 1.1.0? Instead of this subjective line of reasoning, it is probably best to look at the purpose of 1.1, which is to support registries, notably SIDN. There is a more detailed list in the minutes. > Also; given the amount of work to be done for 1.1.0 and the timeframe > involved, would it be a good time to branch and so open trunk for work > again? IMHO that is a very good idea. (But I am a Darcs user -- I tend to think of versions as a pile of patches that are good enough to release, so I have a tendency to make branches for every individual task of some size.) Alternatively, you could have multiple checkouts to work on. > p.s. Sorry if this was all discussed in the meeting last week, I'm not > aiming to restart any arguments. What I said above is what we discussed. Note the IMHO though! -Rick From owner-dnssec-trac at kirei.se Wed Feb 3 10:13:34 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 03 Feb 2010 10:13:34 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #91: Extra symbols in libsofthsm In-Reply-To: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> References: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> Message-ID: <074.7a0cdf49389efd7f4b73a5e26178e7c3@kirei.se> #91: Extra symbols in libsofthsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Those two patches are working solution, but there is some bug (probably in botan1.8), which causes checks to fail if _ZTIN5Botan14PK_Signing_KeyE symbol is not exported. See: http://bugs.randombit.net/show_bug.cgi?id=65 -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Wed Feb 3 10:20:56 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 3 Feb 2010 11:20:56 +0100 Subject: [Opendnssec-develop] 1.0.1 release In-Reply-To: References: Message-ID: <983F17705339E24699AA251B458249B527EF1026EE@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > taking pivotal as our reference Alex and I have been looking at the > work > scheduled for the 1.0.1 release. > > Given that 1.1.0 will follow 1.0.0 by about 4 weeks (hopefully), and > most > of the scheduled work has been known about for that long, can we really > say > that they can't wait for 1.1.0? Yeah, since 1.1.0 is not so far away, there might be no time for a 1.0.1. > Also; given the amount of work to be done for 1.1.0 and the timeframe > involved, would it be a good time to branch and so open trunk for work > again? 1.0.0 will be branched off and trunk will be opened for 1.1.0. Will be fixed by Jakob. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2lOCOCjgaNTdVjaAQgehAf/dBUQYWrUKGQGRpLRw0dgRzR1oEtW3u2h 9qrciHkU1YazweTGMKWuOoHAXZhGsIw6eZeWk4Dd45fuSfoju6kKSOTcjBZEUiZU kXXGGwL6OWBGv+2byPWq8pCZzfYa9XL0Ca8Wj1djlSQwhWPtgB83Dnm28goHpqxw Fkp0NBkSe9Rqhq5ooKDas2eV1YsmafRtMBpoIYPapDD6Aef5E1JH9HjFsnQdYHCF oQxdkiYnrXfyslikz07vssB+N8Fovfqg57CDDF6bhrE13/4ZfysMaj/BQvAzTRrl 62EXbYCu8yVaADhbuVL0kLP8VJkhRuYSn9VCTAZPrYa53WEucif3cQ== =2Z9V -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Wed Feb 3 10:22:20 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 3 Feb 2010 11:22:20 +0100 Subject: [Opendnssec-develop] 1.0.1 release In-Reply-To: <983F17705339E24699AA251B458249B527EF1026EE@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EF1026EE@EXCHANGE2K7.office.nic.se> Message-ID: <1893DB20-28A7-4DF2-B38F-090A1D350DB0@kirei.se> On 3 feb 2010, at 11.20, Rickard Bellgrim wrote: > 1.0.0 will be branched off and trunk will be opened for 1.1.0. Will be fixed by Jakob. 1.0 is branched, trunk is now open for business. Let the mayhem begin! jakob From matthijs at NLnetLabs.nl Wed Feb 3 10:51:50 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 03 Feb 2010 11:51:50 +0100 Subject: [Opendnssec-develop] Fw: [dnsext] Question on NAPTR text format In-Reply-To: References: Message-ID: <4B695546.7010806@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We could update the libraries, but I think it is not a huge issue. As it is undefined, it is garbage in / garbage out. I'll update ldns, but I think there is no time constraint for making a new release for this. Matthijs Alexd at nominet.org.uk wrote: > I asked namedroppers for opinion on the /D notation in resource records > (as discussed last week on this list). > > The response (below) seems to be that this is an error. > > Should we update ldns and dnsruby with this behaviour, so that they at > least behave consistently when confronted with this invalid notation? > > Thanks, > > > Alex. > > > ----- Forwarded by Alex Dalitz/Nominet on 03/02/2010 09:28 ----- > > Donald Eastlake wrote on 02/02/2010 23:10:40: > >> Donald Eastlake >> 02/02/2010 23:10 >> >> To >> >> Alexd at nominet.org.uk >> >> cc >> >> namedroppers at ops.ietf.org >> >> Subject >> >> Re: [dnsext] Question on NAPTR text format >> >> Right, see RFC 4343: >> "A back-slash followed by only one or two decimal digits is undefined" >> >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-634-2066 (home) >> 155 Beaver Street >> Milford, MA 01757 USA >> d3e3e3 at gmail.com >> > >> On Tue, Feb 2, 2010 at 4:33 PM, Mark Andrews wrote: >> >> In message > 004271B4 at nominet.or >> g.uk>, Alexd at nominet.org.uk writes: >> > Hi - >> > >> > I'm hoping somebody can please help me understand how to treat the >> > following text in a NAPTR/TXT record : >> > >> > "blah\2blah" >> > >> > We have from RFC 1035 : >> > >> > \X where X is any character other than a digit (0-9), is >> > used to quote that character so that its special meaning >> > does not apply. For example, "\." can be used to place >> > a dot character in a label. >> > >> > and >> > >> > \DDD where each D is a digit is the octet corresponding to >> > the decimal number described by DDD. The resulting >> > octet is assumed to be text and is not checked for >> > special meaning. >> > >> > So what happens if there is only one digit, instead of three? (i.e. \D) >> > >> > Should this be taken as : >> > >> > 1) a one digit decimal number specifying an octet between 0 and 9 (e.g. >> > \002) >> > 2) the number character itself (e.g. '2') >> > 3) an error? > >> It's a error because it is undefined. >> >> > I've noticed that different libraries take different views on this, and >> > thought it would be nice to have more common behaviour. >> > >> > Thanks in advance for your help! >> > >> > Alex. >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 iQEcBAEBAgAGBQJLaVU/AAoJEA8yVCPsQCW5JUEIAJcZZDTEr8rZB0dGJQCbdRQT 0AXUYtq4wxTOSxu3yBpci9kFVnbWbXjr2CfBJNveh3UE6TNZ1atSnc4ym/RjWTcB jiOYHqvBkdZBajjJikhs+brVUXmiXz6xT/GYeX+SrL0d9KunItkLw4fQ19iGp/t1 UoCSSA9lGZ9sxeXn/KgSRP+pfQ13cZVdNPPjoacbrXTgD/K2R6eRSqO0hs+AKaCi ao8xnDVB0XUU9+AtWj5I1oKOdvJVx6QXPIxZgyaS6TYsMe/4IVUENXRCx5i6J6Kt FrAFX9KoJSdNLn84U1ux5lyubw6G1DM0jOxeNe+3Zm36Kt2qHQtu1bTImLeN9ZE= =Iq+1 -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Feb 4 07:48:04 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Feb 2010 07:48:04 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #92: This ticket is a test only to see if the spamfilter catches it. Message-ID: <054.530de5fdbd01bdeccc29a46e9bfd3c47@kirei.se> #92: This ticket is a test only to see if the spamfilter catches it. -----------------------------+---------------------------------------------- Reporter: jakob@? | Owner: rb Type: defect | Status: new Priority: blocker | Component: SoftHSM Version: trunk | Keywords: -----------------------------+---------------------------------------------- Perhaps this is spam? Or just a test. Nobody knows but mr Akismet himself I guess. Bug in foo.c line 123 seems to be criticial, let's give this to Rickard then. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Feb 4 10:31:47 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Feb 2010 10:31:47 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #92: This ticket is a test only to see if the spamfilter catches it. In-Reply-To: <054.530de5fdbd01bdeccc29a46e9bfd3c47@kirei.se> References: <054.530de5fdbd01bdeccc29a46e9bfd3c47@kirei.se> Message-ID: <063.f9e8c0dbade56def11aa8d3cb65006a3@kirei.se> #92: This ticket is a test only to see if the spamfilter catches it. -----------------------------+---------------------------------------------- Reporter: jakob@? | Owner: rb Type: defect | Status: closed Priority: blocker | Component: SoftHSM Version: trunk | Resolution: worksforme Keywords: | -----------------------------+---------------------------------------------- Changes (by rb): * status: new => closed * resolution: => worksforme -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Feb 4 10:43:01 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Feb 2010 10:43:01 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #91: Extra symbols in libsofthsm In-Reply-To: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> References: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> Message-ID: <074.dccef8e3bde8e2f246491fb683082111@kirei.se> #91: Extra symbols in libsofthsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): Does this work for you? {{{ Index: src/lib/Makefile.am =================================================================== --- src/lib/Makefile.am (revision 2792) +++ src/lib/Makefile.am (working copy) @@ -22,7 +22,7 @@ SoftDatabase.cpp \ SoftKeyStore.cpp libsofthsm_la_LIBADD = @BOTAN_LIBS@ @SQLITE3_LIBS@ @YIELD_LIB@ -libsofthsm_la_LDFLAGS = -version-info @VERSION_INFO@ +libsofthsm_la_LDFLAGS = -version-info @VERSION_INFO@ -export-symbols-regex '^C_.*' EXTRA_DIST = $(srcdir)/*.h \ $(srcdir)/cryptoki_compat/*.h }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Feb 4 13:09:10 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Feb 2010 13:09:10 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #91: Extra symbols in libsofthsm In-Reply-To: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> References: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> Message-ID: <074.d7202ea3b423d8a35f18d7c21188ae89@kirei.se> #91: Extra symbols in libsofthsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Yes, that would work too, but you still need 002 patch. And it looks like this needs: -export-symbols-regex '^(C_|_Z).*' to keep GCC happy about RTTI. So we cannot get rid of _Z symbols. Hah, I knew there must be some reason why I don't like C++ :) Just a note. Another way how to hide symbols in GCC is to explicitly define visibility: http://gcc.gnu.org/wiki/Visibility or more general paper from Ulrich Drepper about DSO: http://people.redhat.com/drepper/dsohowto.pdf Ondrej -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Thu Feb 4 14:11:02 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 4 Feb 2010 14:11:02 +0000 Subject: [Opendnssec-develop] key generation Message-ID: I'm looking at the "ods-ksmutil key generate" command, particularly how I interpret the interval option. Currently what I do is say "how many keys do I need for that length of time" - "how many suitable keys do I already have"... My question is, is that what you would expect? I am tempted to just generate X years worth of keys regardless of how many we currently have... Do you think that this is more likely to fit with expectations? Sion From owner-dnssec-trac at kirei.se Thu Feb 4 14:59:48 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Feb 2010 14:59:48 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #91: Extra symbols in libsofthsm In-Reply-To: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> References: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> Message-ID: <074.f0001dfe623ac0a06890cc543e955326@kirei.se> #91: Extra symbols in libsofthsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Hi, feel free to close this bug as WONTFIX. C++ shared libraries dynamic linker is very fragile and it looks like it cannot be fixed at all. I spent some time looking at various approaches, but nothing but keeping all symbols visible really works. Ondrej -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Thu Feb 4 15:00:50 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 4 Feb 2010 16:00:50 +0100 Subject: [Opendnssec-develop] key generation In-Reply-To: References: Message-ID: <025C76A7-AD10-4119-BB75-F1910FB6783A@kirei.se> On 4 feb 2010, at 15.11, sion at nominet.org.uk wrote: > I'm looking at the "ods-ksmutil key generate" command, particularly how I > interpret the interval option. > > Currently what I do is say "how many keys do I need for that length of > time" - "how many suitable keys do I already have"... that seems fair. > My question is, is that what you would expect? I am tempted to just > generate X years worth of keys regardless of how many we currently have... I'm thinking "make sure I have at least X years of keys" more than "generate X years of keys". jakob From owner-dnssec-trac at kirei.se Thu Feb 4 15:30:43 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Feb 2010 15:30:43 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #91: Extra symbols in libsofthsm In-Reply-To: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> References: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> Message-ID: <074.ef43bc0d41d1d5734021d2b63da38ce5@kirei.se> #91: Extra symbols in libsofthsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): Everything worked fine on Ubuntu 8.04, when just doing the simple -export- symbols-regex '^C_.*' The checks also passed. So it might have something to do with a newer OS. But as you say, I maybe should close this down. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 5 12:58:35 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Feb 2010 12:58:35 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #93: IWBN to have a --version for SoftHSM Message-ID: <066.0f4b9dd81a16a732a404b3654e35eae5@kirei.se> #93: IWBN to have a --version for SoftHSM -----------------------------------------+---------------------------------- Reporter: bortzmeyer+opendnssec@? | Owner: rb Type: enhancement | Status: new Priority: trivial | Component: SoftHSM Version: trunk | Keywords: -----------------------------------------+---------------------------------- Just to know easily what is the installed version. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 5 13:04:38 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Feb 2010 13:04:38 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #94: IWBN to be notified when a key rolls over Message-ID: <087.a1ed4cda6b56b83f7f4d3bd7223d4f06@kirei.se> #94: IWBN to be notified when a key rolls over ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: sion Type: enhancement | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ---------------------------------------------------------------+------------ In conf.xml, there is for the signer, but I find no equivalent for key (KSK and ZSK) rollovers. The only workaround seems to be a parsing of the syslog files, or of the output of ksmutil key list, which are asynchronous methods. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Fri Feb 5 13:11:18 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 5 Feb 2010 14:11:18 +0100 Subject: [Opendnssec-develop] Telephone meeting 20100209 Message-ID: <983F17705339E24699AA251B458249B527EF102D4C@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi We would like to have a short telephone meeting on Tuesday. 1.0.0? Date: Tuesday 09 February Time: 14:00-14:15 CET, 13:00-13:15 GMT http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-02-09 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2wY9eCjgaNTdVjaAQifrQgAkNrpaZ/MRnz+IcpRoGrogAdrShtkxSOj asW7aX6iUMItyntOwB2aODPTtKGL1ra5yKoOn9f3j0oF2rAPObFiCfxSwgruPW99 HGE6FGJ9R1Q11aHGiAoEUiw7DIKeTcgSHL2cFrF0FR1FQe9PC+jcbQjMEayQCEgo hzsv7ro+s46u7KE3pktyh9mKxbcjPnYBb8ePuQxBl+LP+i37Cwl9NkddNbd5YOD2 A+C0dnlMvi9Pxt02WX4ILiJnWeqp4QVPbqkDqAlacIvkNeyHQTjAH2fxMMYMlDT4 ja0Xv+8B8NQ6dCU9f46+ty1SyHXY+XmcVpCRyYiqbNG8gLZnwhgm0Q== =cyMQ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Fri Feb 5 13:13:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Feb 2010 13:13:08 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #95: SHA-2 supported or not? Message-ID: <087.9a0d821b0446b14ff0b9daa7a44aaa5c@kirei.se> #95: SHA-2 supported or not? ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ---------------------------------------------------------------+------------ kasp.xml apparently lets me specify algorithm 8: 8 The keys are created and the signer seems happy: bortzmeyer.fr. 600 IN DNSKEY 256 3 8 AwEAAcaRUNNJN//PQz... bortzmeyer.fr. 86400 IN RRSIG TXT 8 2 86400 20100205230826 20100205110816 36024 bortzmeyer.fr. qOERRH/Tn... But kaspcheck disagrees: ods-kaspcheck ERROR: In policy test, incompatible algorithm (8) used for ZSK NSEC3 in /etc/opendnssec/kasp.xml - should be 6 or 7 ERROR: In policy test, incompatible algorithm (8) used for KSK NSEC3 in /etc/opendnssec/kasp.xml - should be 6 or 7 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 5 13:20:34 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Feb 2010 13:20:34 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #95: SHA-2 supported or not? In-Reply-To: <087.9a0d821b0446b14ff0b9daa7a44aaa5c@kirei.se> References: <087.9a0d821b0446b14ff0b9daa7a44aaa5c@kirei.se> Message-ID: <096.1830f310c3414dc7d0929af0dbcca1f6@kirei.se> #95: SHA-2 supported or not? ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ---------------------------------------------------------------+------------ Comment(by alex): Hi Stephane - It looks like you might be using an old version of ods-kaspcheck. Can you please report the version? ods-kaspcheck -v Thanks! Alex. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 5 13:24:38 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Feb 2010 13:24:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #95: SHA-2 supported or not? In-Reply-To: <087.9a0d821b0446b14ff0b9daa7a44aaa5c@kirei.se> References: <087.9a0d821b0446b14ff0b9daa7a44aaa5c@kirei.se> Message-ID: <096.b5e81eaad8748a1fc8bdb805f108d3d4@kirei.se> #95: SHA-2 supported or not? ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ---------------------------------------------------------------+------------ Comment(by St?phane Bortzmeyer ): % ods-kaspcheck -v 1.0.0b5-trunk Strange, I installed OpenDNSSEC 1.0.0rc3 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 5 13:26:30 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Feb 2010 13:26:30 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #96: State of the key: GENERATE or GENERATED? Message-ID: <087.7dcf112a2234fd2c1a1f3eb816d0de65@kirei.se> #96: State of the key: GENERATE or GENERATED? ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ---------------------------------------------------------------+------------ In ksmutil.c, the state of the key is sometimes listed as GENERATE, sometimes as GENERATED. Probably not a big problem in practice since all comparisons are done on the first eight characters. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 5 14:28:37 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Feb 2010 14:28:37 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #91: Extra symbols in libsofthsm In-Reply-To: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> References: <065.e2ee8a660f018be829a9d84a96406968@kirei.se> Message-ID: <074.39f31ad726f2741fd03f542c497cb93a@kirei.se> #91: Extra symbols in libsofthsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: closed Priority: minor | Component: SoftHSM Version: trunk | Resolution: wontfix Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => wontfix -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 5 14:41:48 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Feb 2010 14:41:48 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #95: SHA-2 supported or not? In-Reply-To: <087.9a0d821b0446b14ff0b9daa7a44aaa5c@kirei.se> References: <087.9a0d821b0446b14ff0b9daa7a44aaa5c@kirei.se> Message-ID: <096.58ad1b0eec95d7250a17752818d8ed44@kirei.se> #95: SHA-2 supported or not? ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: invalid Keywords: | ---------------------------------------------------------------+------------ Changes (by alex): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Feb 9 10:39:03 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 09 Feb 2010 10:39:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #93: IWBN to have a --version for SoftHSM In-Reply-To: <066.0f4b9dd81a16a732a404b3654e35eae5@kirei.se> References: <066.0f4b9dd81a16a732a404b3654e35eae5@kirei.se> Message-ID: <075.3c75932dede32d05be61ee1f73c396e8@kirei.se> #93: IWBN to have a --version for SoftHSM -----------------------------------------+---------------------------------- Reporter: bortzmeyer+opendnssec@? | Owner: rb Type: enhancement | Status: closed Priority: trivial | Component: SoftHSM Version: trunk | Resolution: fixed Keywords: | -----------------------------------------+---------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Fixed in r2805 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Feb 9 10:49:34 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 09 Feb 2010 10:49:34 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #94: IWBN to be notified when a key rolls over In-Reply-To: <087.a1ed4cda6b56b83f7f4d3bd7223d4f06@kirei.se> References: <087.a1ed4cda6b56b83f7f4d3bd7223d4f06@kirei.se> Message-ID: <096.eb7a9e829aebaf036f55e1198e9d9150@kirei.se> #94: IWBN to be notified when a key rolls over ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: sion Type: enhancement | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ---------------------------------------------------------------+------------ Comment(by rb): There will be an interface in order to feed the EPP client with keys. See http://trac.opendnssec.org/wiki/Plugins/EPP -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Feb 10 09:30:51 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 10 Feb 2010 09:30:51 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #97: How to see the GENERATED keys? Message-ID: <087.0a891918cc85b7a056513d2ec376e59a@kirei.se> #97: How to see the GENERATED keys? ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: 1.0.0 | Keywords: ---------------------------------------------------------------+------------ I can generate keys in advance: {{{ % sudo ods-ksmutil key generate --policy test --interval 3D --verbose SQLite database set to: /var/opendnssec/kasp.db Key sharing is Off HSM opened successfully. Created key in repository softHSM Created ZSK size: 1024, alg: 8 with id: a839acc3dd48945e47b8ab9dbb930843 in repository: softHSM and database. all done! hsm_close result: 0 }}} Running it twice generates no keys the next time, which makes sense. But this key a839acc3dd48945e47b8ab9dbb930843 does not appear in the list: {{{ % sudo ods-ksmutil key list --verbose --all SQLite database set to: /var/opendnssec/kasp.db Keys: Zone: Keytype: State: Date of next transition: CKA_ID: Repository: Keytag: bortzmeyer.fr KSK active 2010-02-05 15:40:41 e6f23e17fda9693e2ba3dc5a79cad1d8 softHSM 53691 bortzmeyer.fr KSK ready next rollover 1c4d8e9a6e616f09ef66cd3b140e0179 softHSM 48468 bortzmeyer.fr KSK ready next rollover c62686f986b46df14d6bbd58a0d383a1 softHSM 65117 bortzmeyer.fr ZSK active 2010-02-10 16:09:10 1d117886e98f80b3dd8516d9a975c877 softHSM 24243 bortzmeyer.fr ZSK ready next rollover 980d24646af64877ac20aa051b4d29cb softHSM 48961 fr KSK active 2010-08-07 15:40:41 804f8d743a0e4bcd98d7ce0d4eba4519 softHSM 53478 fr KSK ready next rollover bd5602eb87c58af57cd54faf5222c75e softHSM 52185 fr ZSK active 2010-03-04 15:40:41 5f64166ae2394afa1b17d21839c503e8 softHSM 50714 fr ZSK ready next rollover a4aa0e76caceaab4744638f1a15486b5 softHSM 59717 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Feb 10 10:04:45 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 10 Feb 2010 10:04:45 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #97: How to see the GENERATED keys? In-Reply-To: <087.0a891918cc85b7a056513d2ec376e59a@kirei.se> References: <087.0a891918cc85b7a056513d2ec376e59a@kirei.se> Message-ID: <096.0204b9acef476a269c687fe88e6927aa@kirei.se> #97: How to see the GENERATED keys? ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: sion Type: defect | Status: accepted Priority: major | Component: Enforcer Version: 1.0.0 | Keywords: ---------------------------------------------------------------+------------ Changes (by sion): * status: new => accepted Comment: Currently there is no way to do this with ods-ksmutil because, until they are published, keys are not associated with a particular zone. I have a task to extend the functionality of "key list", and this is something that will be added. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Feb 10 10:25:04 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 10 Feb 2010 10:25:04 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #96: State of the key: GENERATE or GENERATED? In-Reply-To: <087.7dcf112a2234fd2c1a1f3eb816d0de65@kirei.se> References: <087.7dcf112a2234fd2c1a1f3eb816d0de65@kirei.se> Message-ID: <096.a013b5d729ce34391c8bd70740a8cade@kirei.se> #96: State of the key: GENERATE or GENERATED? ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: sion Type: defect | Status: closed Priority: minor | Component: Enforcer Version: trunk | Resolution: wontfix Keywords: | ---------------------------------------------------------------+------------ Changes (by sion): * status: new => closed * resolution: => wontfix Comment: As you say, commands should accept either tense (the same is true of PUBLISH/PUBLISHED etc.) Unless there is a potential ambiguity then I think that it is okay like this. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Feb 10 20:23:33 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 10 Feb 2010 20:23:33 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #98: Few questions and documentation in FR Message-ID: <061.7bcb16c95b5cebb5d79044c07d5601ec@kirei.se> #98: Few questions and documentation in FR ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: | Keywords: ------------------------------------+--------------------------------------- Hello, and thanks for your answers, 1/ What is the action for activate this, or for corrected this : "RequireBackup NOT set; please make sure that you know the potential problems of using keys which are not recoverable" 2/ After many time now or Opendnssec running on my computer, i am realy surprise to find 2 KSK and 2 ZSK. Is it the real procedur for DNSSEC. I am chocking for this (repository to 1). 3/ and after many readind documentation by your site, and same another documentation...i am happy to purpose at you a documentation for use openDNSSEC with Bind principaly. And your the first to see my work before an publication. Sorry it's not swedish ... i have 3 formats for this documention : XHTML, PDF and Docbook. I think it's a good idea for your product with a documentation for the french people, good documentation i will see after. 5/ OpenDNSSEC is ready for Gentoo 2009. 6/ I has a big problem very probably with the last Ubuntu (9.10) and Gnome + OpenDNSSEC. I think there is an incompatibility whith an libray in Python(?)...at 3 time my PC freeze for this, and after all it's not good. Best regards and thanks a lot. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Feb 11 08:45:00 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Feb 2010 08:45:00 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #98: Few questions and documentation in FR In-Reply-To: <061.7bcb16c95b5cebb5d79044c07d5601ec@kirei.se> References: <061.7bcb16c95b5cebb5d79044c07d5601ec@kirei.se> Message-ID: <070.384d5af2beb34a0b03e761d143ab52c7@kirei.se> #98: Few questions and documentation in FR ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: | Keywords: ------------------------------------+--------------------------------------- Comment(by rb): 1. This is a notice for you that the system will use keys that has not been flagged as backed up. Add the -tag to your repository in the conf.xml. http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/conf/conf.xml.in#L21 If this tag is present, then you have to give "ods-ksmutil backup done" before the key can be used. But before you do that, do not forget to do a backup. 2. You probably have a standby key. This will make it faster for you to do an emergency key rollover, since the key is already pre published. 3. We could always provide a link to your documentation. Where can we find it? 5. Tom Hendrikx is going to package OpenDNSSEC for Gentoo. http://www.opendnssec.org/download/packages/ 6. It works well for me. Could you describe it more? -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Fri Feb 12 15:10:55 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 12 Feb 2010 16:10:55 +0100 Subject: [Opendnssec-develop] Signing the root Message-ID: <983F17705339E24699AA251B458249B527EF196932@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I am setting up an education environment based on OpenDNSSEC. In this environment I want to have my own root. The resolvers will be configured with this root. My root will be signed with OpenDNSSEC. But I cannot sign it. My first attempt was to use this configuration: default /var/opendnssec/signconf/root.xml /var/cache/bind/unsigned/root /var/cache/bind/signed/root The Signer was able to sign the zone and the result looked ok. I get files like: ..finalized ..sorted But the Auditor fails with: Feb 12 15:51:02 TeacherODS-LAB ods-auditor[2687]: SOA name () is different to the configured zone name (.) - aborting So I tried with a second configuration: default /var/opendnssec/signconf/root.xml /var/cache/bind/unsigned/root /var/cache/bind/signed/root And now the Signer fails: Feb 12 15:57:57 TeacherODS-LAB ods-signerd: Run command: '/usr/local/libexec/opendnssec/sorter -o -f /var/cache/bind/unsigned/root -w /var/opendnssec/tmp/.sorted -m 3600 -t 3600' Feb 12 15:57:57 TeacherODS-LAB ods-signerd: stderr from sorter: Error, no zone name specified (-o) How should you configure OpenDNSSEC to sign the root? How do we want OpenDNSSEC to behave? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS3Vvf+CjgaNTdVjaAQiDCQf+Ol8Q+1ixqfjPHoiT4t0R0PjR3eZuYg6A XqE7KFaXykzaoaJV2IKMr5PcNuP/Hol2CwLzwSxnJtGZrHNM1gu3Y8tCxS4r7fYG C05HOSdBNMgMkyzfIo2t+77emRcHnimsF3f9v2qWpA+2AaxhezqiqvQCGQIFAPgN FI0aQh/zCUv6tZe/9b48md56m5eVaE3+3RL5rL9OkLm105X9m0wi9zUi61FvkRFL Qaj5UJ9AbKeacPujba3O075MQQaNpxBBk2viXTis5uHZdJgGw+iDMSzGrFILzLtH 1AaCgolVAfeTj2gicasY6UcYxMaZMwdrAttBh4NCFWqoNMxlvdFAsA== =zmSU -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Fri Feb 12 15:45:38 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 12 Feb 2010 16:45:38 +0100 Subject: [Opendnssec-develop] Re: Signing the root In-Reply-To: <983F17705339E24699AA251B458249B527EF196932@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EF196932@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B527EF196956@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > How should you configure OpenDNSSEC to sign the root? How do we want > OpenDNSSEC to behave? Would it be possible to change OpenDNSSEC so that we use zone names with the trailing dot? Including in the zonelist? But we should also be backward compatible with those who do not use the trailing dot. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS3V3ouCjgaNTdVjaAQi+0Af+Myyxg7hkNsntjl+u3y38eS+TqWbpIX0P QtxP7X22u5x4fl1ZeM3sbPRmauPa8QeRETa7MCCuz/UGhBMjGpvfE+JBIPr7eIfy T2xi2gwkW4GS68yNAExmnRGq0mlYqSwdkyO+HBHtWwsg1/8yDbcTsAQ9kkLZ6yga tkFjWBknhfN8RTyyfEaz/Wp3zUWodHhWTybQ69xK6OgRpRWOqWIMwXSuEoGZOqUC SrZmNbojWnW+1k6xY9tC/OwS2rFZsZBskLGaJVV5+PCgGycz0LFHoIG8WJf0676F x4aueo71Ot2AWCqY6obvvbe9+9NC+tQ4m+JHKxLJ5Ft10fr76olDcQ== =kM6k -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Fri Feb 12 20:39:14 2010 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 12 Feb 2010 20:39:14 +0000 Subject: [Opendnssec-develop] Supporting DNS64 with a wild trick Message-ID: <20100212203914.GA27889@phantom.vanrein.org> Hello all, I've been reading into the proposals that the IETG behave WG is drafting about IPv4 <--> IPv6 translation. One of their components is DNS64, which translates A records into AAAA. A counterpart component, DNS46, is also in the making. DNS64 cooperates with NAT64, a translator to which mapped traffic is routed so internal IPv6 traffice gets translated into external IPv4 traffic. DNS64 assembles the AAAA records from the A records in a deterministic manner; as a result we know exactly what those AAAA records will look like, based on the zone. The only variable is a prefix that could be network-local (in which case the network admin will have to worry about DNSSEC) and there is a standardised prefix, 0064:FF9B::/96 which is used to route traffic to the NAT64 translator. Needless to say that this causes severe headaches for secure resolvers if they fall behind this DNS64 translator. It wouldn't be good if DNSSEC and IPv6 would hold each other hostage. Speaking for myself, I don't like to expand my trust in a network at the same time its reach is expanded... What I am wondering now is if the following would be acceptable for DNSSEC signer tools like OpenDNSSEC: 1. To derive such AAAA records from any A that has no AAAA records explicitly defined by the DNS operator; 2. To create signatures, NSEC/NSEC3, anything that DNSSEC needs; 3. To publish the DNSSEC aspects in DNS, but not the AAAA records themselves (oops!) Not publishing the AAAA records themselves is vital, as it is a site-local decision to employ DNS64 -- not everybody will have a NAT64 translator in reach. But correct RRSIG AAAA records can only be constructed at the time of signing. How ugly is this? Would there be operational issues? Without this, I fear end-to-end DNSSEC would require a trust path from resolver/cache to each individual network device... or IPv6 would suffer from yet another reason for delay. We can ask ourselves if that warrants an ugly hack like this one. Links: http://tools.ietf.org/html/draft-ietf-behave-dns64-05 http://tools.ietf.org/html/draft-ietf-behave-address-format-04 http://tools.ietf.org/wg/behave/ Cheers, -Rick From rick at openfortress.nl Fri Feb 12 21:12:32 2010 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 12 Feb 2010 21:12:32 +0000 Subject: [Opendnssec-develop] Supporting DNS64 with a wild trick In-Reply-To: <20100212203914.GA27889@phantom.vanrein.org> References: <20100212203914.GA27889@phantom.vanrein.org> Message-ID: <20100212211232.GA29384@phantom.vanrein.org> Hi, Silly me... > 3. To publish the DNSSEC aspects in DNS, but not the AAAA records > themselves (oops!) That is bound to cause invalidity outcries normal resolvers... which isn't quite what we're after. Sigh, then this puzzle remains unsolved for now... -Rick From jakob at kirei.se Fri Feb 12 22:05:05 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 12 Feb 2010 14:05:05 -0800 Subject: [Opendnssec-develop] Re: Signing the root In-Reply-To: <983F17705339E24699AA251B458249B527EF196956@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EF196932@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B527EF196956@EXCHANGE2K7.office.nic.se> Message-ID: <8DA29CC2-32AE-4198-8DBA-0CC64C7C1D61@kirei.se> On 12 feb 2010, at 07.45, Rickard Bellgrim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > How should you configure OpenDNSSEC to sign the root? How do we want > > OpenDNSSEC to behave? > > Would it be possible to change OpenDNSSEC so that we use zone names with the trailing dot? Including in the zonelist? we should have a common way of canonicalizing the zone name, so we always add a trailing dot if it is missing. this would make "" become "." and "xyzzy.se" become "xyzzy.se.". now that 1.0.0 has been shipped, we also need to upgrade any existing data upon upgrade if we make this change. OR we just use zone names without trailing dot but encode root as "." anyway. jakob From matthijs at NLnetLabs.nl Mon Feb 15 09:56:49 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 15 Feb 2010 10:56:49 +0100 Subject: [Opendnssec-develop] Supporting DNS64 with a wild trick In-Reply-To: <20100212203914.GA27889@phantom.vanrein.org> References: <20100212203914.GA27889@phantom.vanrein.org> Message-ID: <4B791A61.3040906@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, If I'm right, the DNS64 covers three cases. One is implementing the DNS64 functionality at the stub, another is implementing it at the resolver and the third puts the functionality in the authoritative name server. The third case might be of interest for OpenDNSSEC. AAAA synthesis may be done when receiving a query, or when creating/adapting the zone. The latter is preferred, which require no DNS64 functionality. Unless Dynamic Update is used. I agree that we could design for DNS64 synthesis in the DynUpdate module. Matthijs Rick van Rein wrote: > Hello all, > > I've been reading into the proposals that the IETG behave WG is > drafting about IPv4 <--> IPv6 translation. One of their components > is DNS64, which translates A records into AAAA. A counterpart > component, DNS46, is also in the making. > > DNS64 cooperates with NAT64, a translator to which mapped traffic > is routed so internal IPv6 traffice gets translated into external > IPv4 traffic. > > DNS64 assembles the AAAA records from the A records in a deterministic > manner; as a result we know exactly what those AAAA records will look > like, based on the zone. The only variable is a prefix that could be > network-local (in which case the network admin will have to worry > about DNSSEC) and there is a standardised prefix, 0064:FF9B::/96 which > is used to route traffic to the NAT64 translator. > > Needless to say that this causes severe headaches for secure resolvers > if they fall behind this DNS64 translator. It wouldn't be good if > DNSSEC and IPv6 would hold each other hostage. Speaking for myself, I > don't like to expand my trust in a network at the same time its reach > is expanded... > > What I am wondering now is if the following would be acceptable for > DNSSEC signer tools like OpenDNSSEC: > > 1. To derive such AAAA records from any A that has no AAAA records > explicitly defined by the DNS operator; > > 2. To create signatures, NSEC/NSEC3, anything that DNSSEC needs; > > 3. To publish the DNSSEC aspects in DNS, but not the AAAA records > themselves (oops!) > > Not publishing the AAAA records themselves is vital, as it is a > site-local decision to employ DNS64 -- not everybody will have a > NAT64 translator in reach. But correct RRSIG AAAA records can > only be constructed at the time of signing. > > > How ugly is this? Would there be operational issues? Without this, I > fear end-to-end DNSSEC would require a trust path from resolver/cache > to each individual network device... or IPv6 would suffer from yet > another reason for delay. We can ask ourselves if that warrants an > ugly hack like this one. > > > Links: > > http://tools.ietf.org/html/draft-ietf-behave-dns64-05 > http://tools.ietf.org/html/draft-ietf-behave-address-format-04 > http://tools.ietf.org/wg/behave/ > > > Cheers, > -Rick > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLeRpgAAoJEA8yVCPsQCW5nFgH/247xxU73YRcb6NuMt8mpbtI kiUT0kVqo9pvnlRbypkNN/BsA/Ail8Nz7EzVnScd19c5pxrSgV+cqqqqhHWjL2Wa ZeKypwrLZHzvG70UsJ+qZ8vp/mijEf9f1p9+tCpKFC0oorls7Y7/4AcoR9jCNtDe +/TPhWbXIUpu44+36u56ACF8SwvFi2EH+r9lwxFEWPm9nbM3mAKrhNAOWqrE+NbQ mnnnZLem7JOCd5UY9oWrc65rTibUAf+HtE6y8ROsxb3S+wOnRfecs/ERuz6twLRW iYzpNYigAex1IyAu+Ha6LZgKiDS1gtGOfBuXx80GvfXh5y7LMgVYk+Bu6ewR31E= =2U1I -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Mon Feb 15 13:00:19 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Feb 2010 14:00:19 +0100 Subject: [Opendnssec-develop] Re: Code sprint in April, 20-23 In-Reply-To: <983F17705339E24699AA251B458249B527EF1026D0@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EF1026D0@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B52E6DB91A27@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Last meeting we decided to have the code sprint the 20-23 April, in Stockholm. We can recommend the Clarion Hotel. It is located next to our office. http://www.clarionstockholm.com/startpage.aspx // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS3lFY+CjgaNTdVjaAQhYiwgAmYEyPjIddO0Dz9p2kyQMZXudvv/NVUSK 9QyfL+/3E9ZWWN44yMgN0jNs+tcZ0PD6vnA5UDArTFjWOQkojq1T/JFZK5F6RSaV A0YrjdXrDQ3DvrQHbNh4vlJCNDInZkXY6CK/NBP66t35KPBL90I1aKSTbzhktnmN NZj5h/w9B5JjlujJ+rrmhVN4MlVvWCU736whuk2qffsBTBxvMf0lToHlMxzA/TBZ w6Jaxc/xkpomLWq1Re4/tNCNzXLC7/+2w1lvjsdUDZfFwPR05xr8rcW/t6B6mi1z ryV4BRfy+GPo1Tla5wL/iLpIXZ5TAqTOZbBrhff4OrM2GTBlAzxZ3Q== =vhrv -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Mon Feb 15 13:38:03 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Feb 2010 14:38:03 +0100 Subject: [Opendnssec-develop] Telephone meeting - 24 February Message-ID: <983F17705339E24699AA251B458249B52E6DB91A4E@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Next telephone meeting is on Wednesday 24 February. 14-15 CET, 13-14 GMT. An agenda will be added to the wiki. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS3lOO+CjgaNTdVjaAQi6tggAlpxrPpHvAe5z+/WqNNITXO/c3p6JZ96J bh2AMD3J106Oy5glCqYJo3zfcEzRVrNLMGwJdCythoDfelNypmrXuWaJhQkE1dsL DI3k+B2OOQUjTDKeVHk7QAHi7AcLCza4AXByuLhMmTKVmQKZJumGEYzDbfMgXBG+ EmNacmFZoMkFO62b652PcmXgcpLs/U3wnrb9KHXBUSaaIkSry4gOjPiakAJXupKL SOuYbgDaL0yZu767HjFC3QWz3S9GPBe9mdyzW5UhBKsRkou1/bekFXXU4vMPLbls xInaOeWdJHPGAvx4nFhGPij2a2LTHMbnVpdzXLERDqeEDl+yZvRRKw== =ARBq -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Mon Feb 15 15:15:47 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 15 Feb 2010 15:15:47 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #99: IWBN to have a structured output format Message-ID: <087.00ca85b1cce0f69168a5e07b2450a157@kirei.se> #99: IWBN to have a structured output format ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: sion Type: enhancement | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: ---------------------------------------------------------------+------------ I would like to see tools like ods-ksmlist produce reports in a structured format (for instance XML). Today, if I want to be notified when a new key appears (see ticket #94), I need to parse the output of ksmlist (which is brittle). Same thing if I want to have a Web page showing the current keys and their states (for the ops people). -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Tue Feb 16 11:00:53 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 16 Feb 2010 12:00:53 +0100 Subject: [Opendnssec-develop] New zone reader Message-ID: <4B7A7AE5.8040303@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have just committed the new zone reader to trunk. This new tool uses a lot of the structures that are going to be used in the new signer engine. Basically, it takes the sorted zone file and adds empty non-terminals to it, defines glue and unsigned delegations. It could also work on the .unsorted file. It adds NSEC and NSEC3 records where necessary. The nseccer and nsec3er tool become obsolete. No .processed files are created anymore. In case of NSEC: All glue records go into the .optout file. In case of NSEC3: All glue records and unsigned delegations (in case of optout) go into the .optout file. The signer is presented with the other records, just like in versions 1.0.0 and before. The finalizer glues back the .optout file to the .finalized file. I would be grateful if you could test it. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLenriAAoJEA8yVCPsQCW5LF4IAJNnikUfF7wZpMi7aHrgIiay VW0Fb0gDYdG2JttXdz8wt/5b2USjGsMB2pl+whwvKK61RIMxRdcTzHzE1cjGjC9+ 1KnSSy+msH4qo+AYCno0FarHDKg+QrQtt2PZJKm69BqG2/TWylbiL8zQViCllsCv l0TdkG/MAmGtG0QeXZd2TnznHmCMDx7cOkii6Eb6V8C8/kZz/h7niVT/ty2nUIT/ XsKxxXfk5MZmLsSQ6mxg76ElbrBiREukbhAJLiMTv0PmKDDHJN/vqSsoaJViOmtC z02NduYUmgdXXepJ2792csn5M5moeqPzl9k56ChKuydE2mcliEYTYiQ5BDRwDtM= =Fi6f -----END PGP SIGNATURE----- From sion at nominet.org.uk Tue Feb 16 16:26:40 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 16 Feb 2010 16:26:40 +0000 Subject: [Opendnssec-develop] OpenDNSSEC and RFC5155 Message-ID: Evening all, RFC5155 says, on page 32, "zone signing tools SHOULD NOT default to using opt-out". But in trunk/OpenDNSSEC/conf/kasp.xml.in we turn opt-out on... Should we comment this tag out? Cheers, Sion From rick.zijlker at sidn.nl Wed Feb 17 10:32:04 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Wed, 17 Feb 2010 11:32:04 +0100 Subject: [Opendnssec-develop] New zone reader References: <4B7A7AE5.8040303@nlnetlabs.nl> Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86C9@KAEVS1.SIDN.local> Hey Matthijs, Signing the .nl zone opt-out without DS records now took 10 minutes of which sorting took 5 minutes. When the quicksorter is ready and added it should be signed in 6 minutes. Great work! We will now check the effects of respectively adding 10, 20 and 30 percent of DS records. Just FYI, Tom Walker from Nominet is visiting us right now and we're having a "test-sprint". Cheers, Rick -----Original Message----- From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Matthijs Mekking Sent: dinsdag 16 februari 2010 12:01 To: Opendnssec-develop at lists.opendnssec.org Subject: [Opendnssec-develop] New zone reader -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have just committed the new zone reader to trunk. This new tool uses a lot of the structures that are going to be used in the new signer engine. Basically, it takes the sorted zone file and adds empty non-terminals to it, defines glue and unsigned delegations. It could also work on the .unsorted file. It adds NSEC and NSEC3 records where necessary. The nseccer and nsec3er tool become obsolete. No .processed files are created anymore. In case of NSEC: All glue records go into the .optout file. In case of NSEC3: All glue records and unsigned delegations (in case of optout) go into the .optout file. The signer is presented with the other records, just like in versions 1.0.0 and before. The finalizer glues back the .optout file to the .finalized file. I would be grateful if you could test it. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLenriAAoJEA8yVCPsQCW5LF4IAJNnikUfF7wZpMi7aHrgIiay VW0Fb0gDYdG2JttXdz8wt/5b2USjGsMB2pl+whwvKK61RIMxRdcTzHzE1cjGjC9+ 1KnSSy+msH4qo+AYCno0FarHDKg+QrQtt2PZJKm69BqG2/TWylbiL8zQViCllsCv l0TdkG/MAmGtG0QeXZd2TnznHmCMDx7cOkii6Eb6V8C8/kZz/h7niVT/ty2nUIT/ XsKxxXfk5MZmLsSQ6mxg76ElbrBiREukbhAJLiMTv0PmKDDHJN/vqSsoaJViOmtC z02NduYUmgdXXepJ2792csn5M5moeqPzl9k56ChKuydE2mcliEYTYiQ5BDRwDtM= =Fi6f -----END PGP SIGNATURE----- _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From olaf at NLnetLabs.nl Wed Feb 17 10:49:53 2010 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Wed, 17 Feb 2010 11:49:53 +0100 Subject: [Opendnssec-develop] OpenDNSSEC and RFC5155 In-Reply-To: References: Message-ID: <88C882CE-A909-4AA6-948F-A478AA68D868@NLnetLabs.nl> On Feb 16, 2010, at 5:26 PM, sion at nominet.org.uk wrote: > Evening all, > > RFC5155 says, on page 32, "zone signing tools SHOULD NOT default to using > opt-out". But in trunk/OpenDNSSEC/conf/kasp.xml.in we turn opt-out on... > Should we comment this tag out? Yes... OPT-OUT was designed for delegation centric zones, and while the OpenDNSSEC development group is top heavy with those the common user-base is not. --Olaf ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam From bjorn at haxx.se Wed Feb 17 14:02:04 2010 From: bjorn at haxx.se (=?iso-8859-1?Q?Bj=F6rn?= Stenberg) Date: Wed, 17 Feb 2010 15:02:04 +0100 Subject: [Opendnssec-develop] Test the new quicksorter Message-ID: <20100217140204.GD25596@giant> Hi. As I wrote here a while back, a flaw was found in quicksorter that required extensive modification (in short, I sorted on the RDATA presentation format instead of the wire format). The code has now been rewritten and could use some more testing and/or review. If you have a few minutes to spare, please take a look here: http://trac.opendnssec.org/browser/home/bjst/quicksorter Report all bugs to me. Thanks. -- Bj?rn From jakob at kirei.se Wed Feb 17 14:26:48 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 17 Feb 2010 06:26:48 -0800 Subject: [Opendnssec-develop] OpenDNSSEC and RFC5155 In-Reply-To: <88C882CE-A909-4AA6-948F-A478AA68D868@NLnetLabs.nl> References: <88C882CE-A909-4AA6-948F-A478AA68D868@NLnetLabs.nl> Message-ID: On 17 feb 2010, at 02.49, Olaf Kolkman wrote: > On Feb 16, 2010, at 5:26 PM, sion at nominet.org.uk wrote: > >> Evening all, >> >> RFC5155 says, on page 32, "zone signing tools SHOULD NOT default to using >> opt-out". But in trunk/OpenDNSSEC/conf/kasp.xml.in we turn opt-out on... >> Should we comment this tag out? > > > > Yes... +1 jakob From marco.davids at sidn.nl Wed Feb 17 14:46:36 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Wed, 17 Feb 2010 15:46:36 +0100 Subject: [Opendnssec-develop] OpenDNSSEC and RFC5155 In-Reply-To: References: <88C882CE-A909-4AA6-948F-A478AA68D868@NLnetLabs.nl> Message-ID: <4B7C014C.3030300@sidn.nl> >>> RFC5155 says, on page 32, "zone signing tools SHOULD NOT default to using >>> opt-out". But in trunk/OpenDNSSEC/conf/kasp.xml.in we turn opt-out on... >>> Should we comment this tag out? >> >> >> Yes... > > +1 And... +1 here too. Please also add a remark in kasp.xml, referring to RFC5155. Well spotted btw! -- Marco From Alexd at nominet.org.uk Wed Feb 17 15:07:50 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 17 Feb 2010 15:07:50 +0000 Subject: [Opendnssec-develop] Partial Auditor Message-ID: Hi - I'm in the process of adding the new PartialAuditor class to the auditor. This performs most of the same tests as the full auditor, but leaves out the few which require a full canonical sort of the zone. This reduces the time taken to audit a zone with many millions of signed records to a few minutes (from a few hours). I still have to finish things off, but would like to add the configuration options for selecting the new auditor now. It seemed to us that the easiest thing to do would be to add a "Partial" tag to the Audit element in kasp.xml. Only the auditor would read this, and would adjust its behaviour accordingly (i.e. run the full or partial auditor on the zone of interest). Any other configuration for the partial auditor (e.g. what checks to run) can be in a separate (non-XML) file. Is everyone happy with this? If so, shall I add the Partial tag? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy at nominet.org.uk Wed Feb 17 15:11:36 2010 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 17 Feb 2010 10:11:36 -0500 Subject: [Opendnssec-develop] OpenDNSSEC and RFC5155 In-Reply-To: References: Message-ID: Sion wrote on 02/16/2010 11:26:40 AM: > Evening all, > > RFC5155 says, on page 32, "zone signing tools SHOULD NOT default to using > opt-out". But in trunk/OpenDNSSEC/conf/kasp.xml.in we turn opt-out on... > Should we comment this tag out? I think we should comment this tag out, so we do not present the operator with Opt-Out as default. Thanks Sion! Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Wed Feb 17 15:41:56 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 17 Feb 2010 07:41:56 -0800 Subject: [Opendnssec-develop] Partial Auditor In-Reply-To: References: Message-ID: On 17 feb 2010, at 07.07, alexd at nominet.org.uk wrote: > If so, shall I add the Partial tag? please provide a schema diff first, I'd like to make sure it fits the overall schema "architecture". jakob From Ray.Bellis at nominet.org.uk Wed Feb 17 16:14:12 2010 From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk) Date: Wed, 17 Feb 2010 16:14:12 +0000 Subject: [Opendnssec-develop] ZDNet Blog article Message-ID: On ZDNet's "Linux and Open Source" blog: http://blogs.zdnet.com/open-source/?p=5859 [FWIW, I'm pretty sure the author doesn't actually understand it...] Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Feb 17 20:34:37 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 17 Feb 2010 20:34:37 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #100: Certificate support + C_Encrypt and C_Decrypt support Message-ID: <063.7e7e24c70d6d211c49a31709f23add49@kirei.se> #100: Certificate support + C_Encrypt and C_Decrypt support --------------------------------------+------------------------------------- Reporter: calderon.thomas@? | Owner: rb Type: enhancement | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: Certificate, C_Encrypt, C_Decrypt --------------------------------------+------------------------------------- Hi there, I would like to propose the following two patches which I wrote. The first one adds certificate support to SoftHSM. The second one, is an implementation of the C_Encrypt and C_Decrypt operations. I used the C_Sign as a code base and adapted it. I discussed the possibility to add these functionnalities in v1 of softhsm with Rickard and I hope the code quality will be decent enough. Adding those two functionnalities would be great as there are essential to use the softtoken in other apps. Best regards, Thomas Calderon -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Thu Feb 18 06:56:04 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 18 Feb 2010 06:56:04 +0000 Subject: [Opendnssec-develop] Partial Auditor In-Reply-To: References: Message-ID: > > If so, shall I add the Partial tag? > > please provide a schema diff first, I'd like to make sure it fits > the overall schema "architecture". Index: kasp.rnc =================================================================== --- kasp.rnc (revision 2848) +++ kasp.rnc (working copy) @@ -125,7 +125,10 @@ element SOA { anysoa } }, - audit? + element Audit { + # Do a partial audit? + partial? + }* }+ } @@ -194,4 +197,4 @@ propagationdelay = element PropagationDelay { xsd:duration } -audit = element Audit { empty } +partial = element Partial { empty } Alex. P.S. Sorry - sent the wrong diff, off-list, yesterday... -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Thu Feb 18 07:09:40 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 18 Feb 2010 07:09:40 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #100: Certificate support + C_Encrypt and C_Decrypt support In-Reply-To: <063.7e7e24c70d6d211c49a31709f23add49@kirei.se> References: <063.7e7e24c70d6d211c49a31709f23add49@kirei.se> Message-ID: <072.9e95849ea7498905813d9a36843c212f@kirei.se> #100: Certificate support + C_Encrypt and C_Decrypt support --------------------------------------+------------------------------------- Reporter: calderon.thomas@? | Owner: rb Type: enhancement | Status: accepted Priority: major | Component: SoftHSM Version: trunk | Keywords: Certificate, C_Encrypt, C_Decrypt --------------------------------------+------------------------------------- Changes (by rb): * status: new => accepted Comment: Thanks The patches looks good. The only thing I have to do is to implement the "TODO", where I check whether the key can be used to sign, verify, encrypt, or decrypt. Then I will have a look on the PKCS#11 specification of these functions and see if everything is handled correctly. I am not so familiar with certificates in combination with decrypt and encrypt. Will the implemented mechanism be sufficient for most people? Or should I try to add more? Do you know any good implementation that I can test with? -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at openfortress.nl Thu Feb 18 11:43:31 2010 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 18 Feb 2010 11:43:31 +0000 Subject: [Opendnssec-develop] Supporting DNS64 with a wild trick In-Reply-To: <4B791A61.3040906@nlnetlabs.nl> References: <20100212203914.GA27889@phantom.vanrein.org> <4B791A61.3040906@nlnetlabs.nl> Message-ID: <20100218114331.GA18814@phantom.vanrein.org> Hi all, > If I'm right, the DNS64 covers three cases. One is implementing the > DNS64 functionality at the stub, another is implementing it at the > resolver and the third puts the functionality in the authoritative name > server. > > The third case might be of interest for OpenDNSSEC. I had to think over your angle. I think you are proposing that the user defines a prefix (96 bits to be placed in front of the IPv4 address), and that your are proposing to not use the well-known prefix 64:FF9B::/96 as a _default_ value. Not yet, at least. If you'd do that then the DNS administrator could setup NAT64/NAT46 translation for incoming traffic to their servers, and translate the IPv6 traffic to the IPv4 addresses. Sounds good to me, although I wonder if it'd add anything w.r.t. setting up dual stack servers. You could at some point move towards using a NAT64 translation service that might be offered by an external party, perhaps sixxs.net or comparable IPv6-drivers. If that happens, a globally routable (or user based alternative) prefix such as the well-known prefix could be used. Once that setup would work reliably, it could become a default to be set in OpenDNSSEC. It'd help in moving traffic over to IPv6, which is a Good Thing(tm). > AAAA synthesis may > be done when receiving a query, or when creating/adapting the zone. The > latter is preferred, which require no DNS64 functionality. Whether it can be done dynamically would depend on whether the IPv6 prefix used is dynamic. In practice, it is quite doable to get stable addresses for a server; only 2002::/16 addresses are dynamic if the IPv4 tunnel endpoint is dynamic. But I doubt if anyone would setup a server (by which I mean, DNS-published entities) using a 2002::/16 address. A simple tunnel like AYIYA can provide a static IPv6 address, even over a dynamic IPv4 address. > Unless Dynamic Update is used. I agree that we could design for DNS64 > synthesis in the DynUpdate module. Sounds lovely to me. What is left are the other places of supporting NAT64/DNS64. I don't care very much about the stub, as it seems simpler to use a dual stack instead; but a DNS64 resolver serving a LAN and passing traffic through NAT64 could be a more difficult case. This was what I had in mind with my original, immediately withdrawn, idea. I'm afraid it's going to be useful to support the resolver-case for DNS64. Matthijs told me a patch for Unbound is already available. This makes Unbound sit in a split: you can use it for strict DNSSEC on your LAN, or for DN64-enabled strict IPv6 on your LAN, but not both. A horrible way out (it'd work, but I'd love to see a better solution) could be to publish the AAAA record signatures for such applications on a subdomain, as in www IN A 123.45.67.89 ; IN AAAA to be generated by DNS64 dns64sig.www IN RRSIG AAAA ... This dns64sig.www would sign the "www IN AAAA" record with the well-known prefix, thus enabling network administrators to setup such an extension internally. There would be a recommendation along the lines of "a network that uses DNS64 alongside DNSSEC resolvers in clients MUST use the well-known prefix for DNS64 and it MUST use the dns64sig sub-zones to get hold of the AAAA signatures". Let the record show that I find the above very ugly. But it would be a way of supporting DNSSEC in combination with DNS64. Better ideas and opinions are quite welcome! (One that I can see is the introduction of a special RR "DNS64RRSIGforAAAA" but I haven't thought that through.) Cheers, -Rick From matthijs at NLnetLabs.nl Thu Feb 18 12:47:03 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 18 Feb 2010 13:47:03 +0100 Subject: [Opendnssec-develop] Supporting DNS64 with a wild trick In-Reply-To: <20100218114331.GA18814@phantom.vanrein.org> References: <20100212203914.GA27889@phantom.vanrein.org> <4B791A61.3040906@nlnetlabs.nl> <20100218114331.GA18814@phantom.vanrein.org> Message-ID: <4B7D36C7.9030708@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rick van Rein wrote: > Hi all, > >> If I'm right, the DNS64 covers three cases. One is implementing the >> DNS64 functionality at the stub, another is implementing it at the >> resolver and the third puts the functionality in the authoritative name >> server. >> >> The third case might be of interest for OpenDNSSEC. > > I had to think over your angle. I think you are proposing that the > user defines a prefix (96 bits to be placed in front of the IPv4 > address), and that your are proposing to not use the well-known > prefix 64:FF9B::/96 as a _default_ value. Not yet, at least. Whatever the prefix is, you can put it in configuration. > If you'd do that then the DNS administrator could setup NAT64/NAT46 > translation for incoming traffic to their servers, and translate the > IPv6 traffic to the IPv4 addresses. Sounds good to me, although I > wonder if it'd add anything w.r.t. setting up dual stack servers. DNS64 only deals with IPv4-only to/from IPv6-only communications. > You could at some point move towards using a NAT64 translation > service that might be offered by an external party, perhaps > sixxs.net or comparable IPv6-drivers. If that happens, a globally > routable (or user based alternative) prefix such as the well-known > prefix could be used. Once that setup would work reliably, it could > become a default to be set in OpenDNSSEC. It'd help in moving traffic > over to IPv6, which is a Good Thing(tm). > >> AAAA synthesis may >> be done when receiving a query, or when creating/adapting the zone. The >> latter is preferred, which require no DNS64 functionality. > > Whether it can be done dynamically would depend on whether the IPv6 > prefix used is dynamic. In practice, it is quite doable to get stable > addresses for a server; only 2002::/16 addresses are dynamic if the > IPv4 tunnel endpoint is dynamic. Of course, without knowing the prefix, you cannot synthesize. The prefix can be learned through configuration, although there are other approaches submitted within the behave wg. > But I doubt if anyone would setup a server (by which I mean, DNS-published > entities) using a 2002::/16 address. A simple tunnel like AYIYA can provide > a static IPv6 address, even over a dynamic IPv4 address. > >> Unless Dynamic Update is used. I agree that we could design for DNS64 >> synthesis in the DynUpdate module. > > Sounds lovely to me. > > What is left are the other places of supporting NAT64/DNS64. I don't > care very much about the stub, as it seems simpler to use a dual stack > instead; but a DNS64 resolver serving a LAN and passing traffic through > NAT64 could be a more difficult case. This was what I had in mind with > my original, immediately withdrawn, idea. > > I'm afraid it's going to be useful to support the resolver-case for DNS64. > Matthijs told me a patch for Unbound is already available. This makes > Unbound sit in a split: you can use it for strict DNSSEC on your LAN, > or for DN64-enabled strict IPv6 on your LAN, but not both. But that is at the resolver side. OpenDNSSEC will be at the authoritative side, and thus in that case, there are no changes required for us (and with us, I mean the OpenDNSSEC project group). DNS64 is a contributed module in Unbound that you can turn on. In that case, Unbound will do synthesis after validation. I don't see the 'split' issue. > A horrible way out (it'd work, but I'd love to see a better solution) > could be to publish the AAAA record signatures for such applications on > a subdomain, as in > > www IN A 123.45.67.89 > ; IN AAAA to be generated by DNS64 > dns64sig.www IN RRSIG AAAA ... > > This dns64sig.www would sign the "www IN AAAA" record with the well-known > prefix, thus enabling network administrators to setup such an extension > internally. There would be a recommendation along the lines of "a network > that uses DNS64 alongside DNSSEC resolvers in clients MUST use the > well-known prefix for DNS64 and it MUST use the dns64sig sub-zones to > get hold of the AAAA signatures". > > Let the record show that I find the above very ugly. But it would be a > way of supporting DNSSEC in combination with DNS64. Better ideas and > opinions are quite welcome! (One that I can see is the introduction > of a special RR "DNS64RRSIGforAAAA" but I haven't thought that through.) As you mentioned, a horrible idea ;). And not compliant with the current DNS64 specification. DNS64 is mainly a resolver thingie. On the authoritative side, implementors have little worries supporting DNS64, unless you are going to do Dynamic Updates. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLfTbFAAoJEA8yVCPsQCW58cAH/ifR3skqJ3klTCf8r2Uv15Ja AeVW/MktINjXcjASV/1EotjgojAZbrNIkuHJdEpynUK8DoMEOSezcrW895iTMu4d 5a50NC9i0GfanU5abiq5ocTKVUnmEqXT4c2R6muzzfGsvEwZyN1H8UAaeVMzeiB8 Mx3Xak8acywDWYtjkf3/K2j1XRtSXzXpX7hgnjIFTrMNdHT1cMSfIUp4cfRuiGq1 bNoe4d6UULToHmbaz6gfBZbnedclXwjjRmrm49LH2oCfllppwf1YsUivxAYmU8tt yQoovkQ7zbsbTYaBFt011XRB+gh7XiwDRB/C4iUSwD1QqHt4VV5NbuGCggjrIVg= =MmQv -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Feb 18 17:55:10 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 18 Feb 2010 17:55:10 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #101: ods-signerd should create a pidfile Message-ID: <055.d49a44ecf4dd00b8dd8822e5afab209d@kirei.se> #101: ods-signerd should create a pidfile ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: ------------------------------+--------------------------------------------- To check if a daemon is running, the easiest way is by checking if the pid of the daemon still exists. The signer daemon should create its own pidfile. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 19 00:27:40 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 19 Feb 2010 00:27:40 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #102: 4Suite-XML is obsolete and does not support Python 2.6 Message-ID: <057.4221d683d79f9c884cec467c9f5f1f83@kirei.se> #102: 4Suite-XML is obsolete and does not support Python 2.6 --------------------------------+------------------------------------------- Reporter: GooseYArd@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: 4suite-xml, python --------------------------------+------------------------------------------- See this message from the developer: https://bugs.launchpad.net/ubuntu/jaunty/+source/python- 4suite/+bug/338079/comments/1 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 19 06:51:12 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 19 Feb 2010 06:51:12 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #100: Certificate support + C_Encrypt and C_Decrypt support In-Reply-To: <063.7e7e24c70d6d211c49a31709f23add49@kirei.se> References: <063.7e7e24c70d6d211c49a31709f23add49@kirei.se> Message-ID: <072.3fcb655e37ecda0df66ceda084c9869d@kirei.se> #100: Certificate support + C_Encrypt and C_Decrypt support --------------------------------------+------------------------------------- Reporter: calderon.thomas@? | Owner: rb Type: enhancement | Status: accepted Priority: major | Component: SoftHSM Version: trunk | Keywords: Certificate, C_Encrypt, C_Decrypt --------------------------------------+------------------------------------- Comment(by calderon.thomas@?): Hi, I guess the current mechanism and padding is the one used in most tokens (I have compared to Gemalto cards). So I would say it is going to be enough for most people. For testing, I used Kerberos, but as unit testing, you could try using openssl and the token to perform rsa encryption/decryption. However you would have to ensure the right padding for openssl as the command line utility seems buggy for that (different resutls, but identical when comparing the results with a hardware token). Another solution is to use "libp11" which have one example script performing decryption. Regards, Thomas Calderon. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 19 08:06:12 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 19 Feb 2010 08:06:12 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #101: ods-signerd should create a pidfile In-Reply-To: <055.d49a44ecf4dd00b8dd8822e5afab209d@kirei.se> References: <055.d49a44ecf4dd00b8dd8822e5afab209d@kirei.se> Message-ID: <064.ab7daf764e9bd253ba8345e7c4ad62a3@kirei.se> #101: ods-signerd should create a pidfile ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: trunk | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed Comment: I have committed revision 2853 (trunk) that should do this. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Feb 19 08:10:16 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 19 Feb 2010 08:10:16 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #102: 4Suite-XML is obsolete and does not support Python 2.6 In-Reply-To: <057.4221d683d79f9c884cec467c9f5f1f83@kirei.se> References: <057.4221d683d79f9c884cec467c9f5f1f83@kirei.se> Message-ID: <066.ed2f24be3da8078309c24939ba61b1d1@kirei.se> #102: 4Suite-XML is obsolete and does not support Python 2.6 --------------------------------+------------------------------------------- Reporter: GooseYArd@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: 4suite-xml, python --------------------------------+------------------------------------------- Comment(by matthijs): Replacing the python code with c is on our short term planning. So, this bug should resolve itself by then. Until then, I leave this report open. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Mon Feb 22 08:06:48 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 22 Feb 2010 09:06:48 +0100 Subject: [Opendnssec-develop] Partial Auditor In-Reply-To: References: Message-ID: <6C18D577-068C-4EF4-AC4C-7ED06985E42C@kirei.se> On 18 feb 2010, at 07.56, Alexd at nominet.org.uk wrote: > > > If so, shall I add the Partial tag? > > > > please provide a schema diff first, I'd like to make sure it fits > > the overall schema "architecture". > > Index: kasp.rnc > =================================================================== > --- kasp.rnc (revision 2848) > +++ kasp.rnc (working copy) > @@ -125,7 +125,10 @@ > element SOA { anysoa } > }, > > - audit? > + element Audit { > + # Do a partial audit? > + partial? > + }* > }+ > } > > @@ -194,4 +197,4 @@ > > propagationdelay = element PropagationDelay { xsd:duration } > > -audit = element Audit { empty } > +partial = element Partial { empty } ok, please commit this. jakob From sion at nominet.org.uk Mon Feb 22 11:19:33 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 22 Feb 2010 11:19:33 +0000 Subject: [Opendnssec-develop] Defining KSK rollover schemes Message-ID: For v1.1 I am working on implementing the different KSK rollover schemes defined in: http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-01 This means adding an option to kasp.xml; and I think that it will involve a database schema change too. So, does the following look reasonable? Sion Index: kasp.rnc =================================================================== --- kasp.rnc (revision 2857) +++ kasp.rnc (working copy) @@ -89,7 +89,10 @@ # use RFC 5011 for key rollover? # Not implemented yet - element RFC5011 { empty }? + element RFC5011 { empty }?, + + # Define the rollover scheme to be used + rollover? }*, # Zone Signing Keys (ZSK) parameters @@ -195,3 +198,29 @@ propagationdelay = element PropagationDelay { xsd:duration } audit = element Audit { empty } + +rollover = element RolloverScheme { + # Define the rollover scheme to be used. + + # The new KSK is added to the DNSKEY RRset which is then signed with + # both the old and new key. After waiting for the old DNSKEY RRset to + # expire from caches, the DS record in the parent zone is changed. + # After waiting a further interval for this change to be reflected in + # validating resolver caches, the old key is removed from the DNSKEY + # RRset. + "DoubleDNSKey" | + + # The new DS record is published. After waiting for this + # change to propagate into the caches of all validating resolvers, the + # KSK is changed. After a further interval during which the old DNSKEY + # RRset expires from caches, the old DS record is removed. + "DoubleDS" | + + # The new KSK is added to the DNSKEY RRset which is then signed with + # both the old and new key, and the new DS record added to the parent + # zone. After waiting a suitable interval for the old DS and DNSKEY + # RRsets to expire from validating resolver caches, the old DNSKEY and + # DS record are removed. + "DoubleRRSet" + +} From rickard.bellgrim at iis.se Mon Feb 22 11:29:44 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 22 Feb 2010 12:29:44 +0100 Subject: [Opendnssec-develop] Defining KSK rollover schemes In-Reply-To: References: Message-ID: <9F556D6E-1C8E-4B4C-95BD-1E3051AED528@iis.se> > This means adding an option to kasp.xml; and I think that it will involve a > database schema change too. Would any changes be incompatible with version 1.0? How to handle updates between 1.0 and 1.1, so that we do not get many migration scripts. > So, does the following look reasonable? It looks reasonable. And if nothing is specified, then we default to? Should the default KASP be update with this element? > + "DoubleDNSKey" | DoubleDNSKEY > + "DoubleRRSet" DoubleRRset // Rickard From jakob at kirei.se Mon Feb 22 11:32:41 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 22 Feb 2010 12:32:41 +0100 Subject: [Opendnssec-develop] Defining KSK rollover schemes In-Reply-To: References: Message-ID: <9AEF964D-7CBF-450A-A7A8-4A88B2530979@kirei.se> isn't DoubleRRSet == DoubleDNSKey + DoubleDS ? jakob From sion at nominet.org.uk Mon Feb 22 11:52:59 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 22 Feb 2010 11:52:59 +0000 Subject: [Opendnssec-develop] Defining KSK rollover schemes In-Reply-To: <9F556D6E-1C8E-4B4C-95BD-1E3051AED528@iis.se> References: <9F556D6E-1C8E-4B4C-95BD-1E3051AED528@iis.se> Message-ID: > > This means adding an option to kasp.xml; and I think that it will involve a > > database schema change too. > > Would any changes be incompatible with version 1.0? How to handle > updates between 1.0 and 1.1, so that we do not get many migration scripts. I have not got the details quite finished yet. The issue is that for some schemes we need to know when the DS record was seen. We might not need to store the timestamp itself, I will avoid this if I can. If we can not avoid it then I will create update scripts, increment the database schema etc. I will try to make it backwards compatible if I can, and thinking off the top of my head it should be possible. > > So, does the following look reasonable? > > It looks reasonable. And if nothing is specified, then we default > to? Should the default KASP be update with this element? > > > + "DoubleDNSKey" | > > DoubleDNSKEY > > > + "DoubleRRSet" > > DoubleRRset Thank you, I meant to ask if people had a preference for what to default to (I was thinking DoubleDS); whatever it is should go in the default kasp though. Sion From Stephen.Morris at nominet.org.uk Mon Feb 22 12:01:44 2010 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Mon, 22 Feb 2010 12:01:44 +0000 Subject: [Opendnssec-develop] Defining KSK rollover schemes In-Reply-To: <9AEF964D-7CBF-450A-A7A8-4A88B2530979@kirei.se> References: <9AEF964D-7CBF-450A-A7A8-4A88B2530979@kirei.se> Message-ID: Jakob Schlyter wrote on 22/02/2010 11:32:41: > isn't DoubleRRSet == DoubleDNSKey + DoubleDS ? > > jakob Effectively, yes. You are rolling both the DS and the DNSKEY at the same time, so intervals depend on the parameters of both the parent and child zones. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Mon Feb 22 12:07:54 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 22 Feb 2010 12:07:54 +0000 Subject: [Opendnssec-develop] Defining KSK rollover schemes In-Reply-To: References: <9AEF964D-7CBF-450A-A7A8-4A88B2530979@kirei.se> Message-ID: > > isn't DoubleRRSet == DoubleDNSKey + DoubleDS ? > > > > jakob > > Effectively, yes. > > You are rolling both the DS and the DNSKEY at the same time, so > intervals depend on the parameters of both the parent and child zones. I was going to leave this option until last, and will happily postpone it to after v1.1 if there are other things to do or if I run out of time. From sion at nominet.org.uk Mon Feb 22 16:09:38 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 22 Feb 2010 16:09:38 +0000 Subject: [Opendnssec-develop] Partial Auditor In-Reply-To: References: Message-ID: > If so, shall I add the Partial tag? So, if I understand, the proposal is to have a switch in kasp.xml that can turn partial auditing on or off. Then, possibly, further configuration will be in a separate (non-xml) file? A couple of observations... Is it really desirable to have more config files? And if so, do we want to mix xml and non-xml? I'm just trying to think if users will find this more confusing than the system is already. Although the alternative of putting all the information into kasp.xml is no simpler, it is at least one fewer file and a consistent format. Sion From Stephen.Morris at nominet.org.uk Mon Feb 22 16:23:34 2010 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Mon, 22 Feb 2010 16:23:34 +0000 Subject: [Opendnssec-develop] Partial Auditor In-Reply-To: References: Message-ID: sion at nominet.org.uk wrote on 22/02/2010 16:09:38: > > If so, shall I add the Partial tag? > > So, if I understand, the proposal is to have a switch in kasp.xml that can > turn partial auditing on or off. Then, possibly, further configuration will > be in a separate (non-xml) file? > > A couple of observations... Is it really desirable to have more config > files? And if so, do we want to mix xml and non-xml? > > I'm just trying to think if users will find this more confusing than the > system is already. Although the alternative of putting all the information > into kasp.xml is no simpler, it is at least one fewer file and a consistent > format. The idea was partially mine because of the idea raised our face to face meeting last month that we should allow people to configure their own auditor into the system. To allow for maximum flexibility, we should not require that auditor options be contained within our configuration file. Perhaps better would be for the auditor to look for its own configuration file and decide whether it should do a full or partial audit based on the contents. (For upwards compatibility, the default should a full audit if the file is not present.). The switch in kasp.xml keeps its current function of turning auditing on or off. But I take your point that this is yet another configuration file... Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Tue Feb 23 10:44:44 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 23 Feb 2010 11:44:44 +0100 Subject: [Opendnssec-develop] Partial Auditor In-Reply-To: References: Message-ID: <1F156440-F93F-41BE-A453-E0F719B7F7CA@kirei.se> On 22 feb 2010, at 17.09, sion at nominet.org.uk wrote: >> If so, shall I add the Partial tag? > > So, if I understand, the proposal is to have a switch in kasp.xml that can > turn partial auditing on or off. Then, possibly, further configuration will > be in a separate (non-xml) file? I've always envisioned that all Auditor configuration would be kept inside in the kasp, i.e. everything inside the container is passed transparently to the signer configuration so the enforcer just needs to read the whole container and dump it when writing the signconf. makes sense? jakob From Alexd at nominet.org.uk Tue Feb 23 10:50:54 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Tue, 23 Feb 2010 10:50:54 +0000 Subject: [Opendnssec-develop] Partial Auditor In-Reply-To: <1F156440-F93F-41BE-A453-E0F719B7F7CA@kirei.se> References: <1F156440-F93F-41BE-A453-E0F719B7F7CA@kirei.se> Message-ID: > > So, if I understand, the proposal is to have a switch in kasp.xml that can > > turn partial auditing on or off. Then, possibly, further configuration will > > be in a separate (non-xml) file? > > I've always envisioned that all Auditor configuration would be kept > inside in the kasp, i.e. everything inside the > container is passed transparently to the signer configuration so the > enforcer just needs to read the whole container and dump it when > writing the signconf. makes sense? But the Auditor doesn't read the signconf (other than for the NSEC3 salt), so there is not much point in putting the config there (except for human debugging, I suppose). Unless you propose that the signer should read the auditor config and start the auditor with that config. It seemed a bit unnecessary for the signer to have to do that, though. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Tue Feb 23 11:02:55 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 23 Feb 2010 11:02:55 +0000 Subject: [Opendnssec-develop] Partial Auditor In-Reply-To: References: <1F156440-F93F-41BE-A453-E0F719B7F7CA@kirei.se> Message-ID: > > > So, if I understand, the proposal is to have a switch in kasp.xml that can > > > turn partial auditing on or off. Then, possibly, further > configuration will > > > be in a separate (non-xml) file? > > > > I've always envisioned that all Auditor configuration would be kept > > inside in the kasp, i.e. everything inside the > > container is passed transparently to the signer configuration so the > > enforcer just needs to read the whole container and dump it when > > writing the signconf. makes sense? > > But the Auditor doesn't read the signconf (other than for the NSEC3 > salt), so there is not much point in putting the config there > (except for human debugging, I suppose). > > Unless you propose that the signer should read the auditor config > and start the auditor with that config. It seemed a bit unnecessary > for the signer to have to do that, though. I think that we need to worry more about the extra work that users need to do to configure the system. That is the only reason I was uneasy about having an extra file. Sion From jakob at kirei.se Tue Feb 23 11:53:32 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 23 Feb 2010 12:53:32 +0100 Subject: [Opendnssec-develop] Partial Auditor In-Reply-To: References: <1F156440-F93F-41BE-A453-E0F719B7F7CA@kirei.se> Message-ID: <2DE0EDF8-5ED1-42E2-B13F-9DF3871D48B7@kirei.se> On 23 feb 2010, at 11.50, Alexd at nominet.org.uk wrote: > But the Auditor doesn't read the signconf (other than for the NSEC3 salt), right, but the auditor does read the kasp, no? if not, perhaps it could at least read the signconf? jakob From Alexd at nominet.org.uk Tue Feb 23 12:07:02 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Tue, 23 Feb 2010 12:07:02 +0000 Subject: [Opendnssec-develop] Partial Auditor In-Reply-To: <2DE0EDF8-5ED1-42E2-B13F-9DF3871D48B7@kirei.se> References: <1F156440-F93F-41BE-A453-E0F719B7F7CA@kirei.se> <2DE0EDF8-5ED1-42E2-B13F-9DF3871D48B7@kirei.se> Message-ID: > right, but the auditor does read the kasp, no? Yes. If the general consensus is that the auditor configuration should be hard-coded to a particular auditor implementation in the main kasp.xml file, then I'm quite happy to do that. Our feeling was that a little decoupling could be a good thing, if the future plan was to allow plug-in auditors. The majority of opendnssec users are not going to need to configure a partial auditor, and the main configuration file could be said to be confusing enough as it is - so why add more clutter that isn't really required? Not that it really matters... Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Feb 24 13:39:45 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Feb 2010 13:39:45 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #103: Enforcer not taking into account the standby parameter for zsk Message-ID: <069.d6a949cae776483355eeb0b8604742d7@kirei.se> #103: Enforcer not taking into account the standby parameter for zsk --------------------------------------------+------------------------------- Reporter: Mathieu Arnold | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: 1.0.0 | Keywords: --------------------------------------------+------------------------------- After trying to have two standby zsk for a week, I decided that it was not me that was doing something wrong, so I started searching, and there's a tiny typo in enforcer/ksm/include/ksm/ksm.h : {{{ --- enforcer/ksm/include/ksm/ksm.h~ 2010-02-24 14:33:05.000000000 +0100 +++ enforcer/ksm/include/ksm/ksm.h 2010-02-24 14:33:16.000000000 +0100 @@ -402,7 +402,7 @@ #define KSM_PAR_STANDBYKSKS_CAT "ksk" #define KSM_PAR_STANDBYZSKS 1 #define KSM_PAR_STANDBYZSKS_STRING "standby" -#define KSM_PAR_STANDBYZSKS_CAT "ksk" +#define KSM_PAR_STANDBYZSKS_CAT "zsk" #define KSM_PAR_SIGNINT 7200 /* 2 hours */ #define KSM_PAR_SIGNINT_STRING "resign" #define KSM_PAR_SIGNINT_CAT "signature" }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Feb 24 13:53:35 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Feb 2010 13:53:35 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #104: Linking conf.xml to softhsm pkcs#11 lib on mac Message-ID: <043.c7d913a6b74d94cd59e500d185fc64e2@kirei.se> #104: Linking conf.xml to softhsm pkcs#11 lib on mac ------------------------+--------------------------------------------------- Reporter: pawal | Owner: rb Type: enhancement | Status: new Priority: minor | Component: Unknown Version: trunk | Keywords: ------------------------+--------------------------------------------------- When compiling and installing on MacOS, you want to use libsofthsm.dylib instead of the default currently in conf.xml. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Feb 24 13:55:38 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Feb 2010 13:55:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #104: Linking conf.xml to softhsm pkcs#11 lib on mac In-Reply-To: <043.c7d913a6b74d94cd59e500d185fc64e2@kirei.se> References: <043.c7d913a6b74d94cd59e500d185fc64e2@kirei.se> Message-ID: <052.85bf732e48868a6ebe07bdd1b85065ac@kirei.se> #104: Linking conf.xml to softhsm pkcs#11 lib on mac ------------------------+--------------------------------------------------- Reporter: pawal | Owner: jakob Type: enhancement | Status: assigned Priority: minor | Component: Unknown Version: trunk | Keywords: ------------------------+--------------------------------------------------- Changes (by pawal): * owner: rb => jakob * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Feb 24 14:06:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Feb 2010 14:06:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #103: Enforcer not taking into account the standby parameter for zsk In-Reply-To: <069.d6a949cae776483355eeb0b8604742d7@kirei.se> References: <069.d6a949cae776483355eeb0b8604742d7@kirei.se> Message-ID: <078.2ea6772d9907aca702201e48b6baefab@kirei.se> #103: Enforcer not taking into account the standby parameter for zsk --------------------------------------------+------------------------------- Reporter: Mathieu Arnold | Owner: sion Type: defect | Status: closed Priority: major | Component: Enforcer Version: 1.0.0 | Resolution: fixed Keywords: | --------------------------------------------+------------------------------- Changes (by sion): * status: new => closed * resolution: => fixed Comment: This is fixed in trunk. We need to decide if we should patch v1.0.0 also. Sion -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Feb 24 21:34:07 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 24 Feb 2010 21:34:07 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #105: ./configure support for --disable-sqlite3 Message-ID: <055.7b6bd6d817d00369a920b5831a38086f@kirei.se> #105: ./configure support for --disable-sqlite3 ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: rb Type: enhancement | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- Gentoo does not like it when external libraries are implicitly linked to when they are optional, as is currently done with sqlite. To solve this issue, I wrote a small addition to enforcer/configure.ac that adds a --disable-sqlite3 option. Default is still to use sqlite. When both mysql and sqlite are enabled (or disabled) a configure error is thrown. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Thu Feb 25 08:31:19 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 25 Feb 2010 09:31:19 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.0.1 Message-ID: <7809D36C-4825-4B35-94A5-7E7A75209057@iis.se> Hi We said during the meeting yesterday that we are not releasing a 1.0.1, but it might be usefull if we any patches that we want to apply to the 1.0.0. Do we have any? * The standby keys * Use of prefix * etc... // Rickard From owner-dnssec-trac at kirei.se Thu Feb 25 09:27:28 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 25 Feb 2010 09:27:28 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #106: IWBN to export keys to the new BIND 9.7 format (with timing information) Message-ID: <087.a9c318cd62a5bf49afda547b0f215abd@kirei.se> #106: IWBN to export keys to the new BIND 9.7 format (with timing information) ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: rb Type: enhancement | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ---------------------------------------------------------------+------------ BIND 9.7 has a new format for key files, with timing information that BIND can use to find out which key to use for signing (that's useful for dynamic update). But softhsm-keyconv can apparently only export to the old 1.2 format. {{{ Private-key-format: v1.3 ... Created: 20100225092158 Publish: 20100225092158 Activate: 20100225092158 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Thu Feb 25 10:37:43 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 25 Feb 2010 10:37:43 +0000 Subject: [Opendnssec-develop] KSK rollover Message-ID: I'm trying to implement the DoubleDNSKEY scheme without changing the database. Here is a summary of how the scheme works IpubC == publication interval in child IpubP == publication interval in parent DoubleDNSKEY 1. pre-publish key (IpubC + IpubP) before retirement (double safety margin?) new key in zone, used to sign 2. after IpubC prompt for DS to be submitted 3. wait for ds-seen to be issued 4. IpubP after (3) the rollover can occur (either manual or automatic) old key in zone, not used 5. retired key can move to dead old key removed I think that 4 and 5 occur at the same time... anyway; the issue is that we have to wait after publication before we can submit the DS record, but we also have to wait after the DS is seen before we can safely roll the key. Currently, the key would go from published to ready at step 2, which means we have no state to describe "waiting for DS seen". Ideally I would add new columns "DS-PUBLISHED" and "DS-READY" or similar... Of course this breaks backwards compatibility. One alternative is to move the key into a new state of DS_PUBLISHED when the DS is seen and reuse the PUBLISHED timestamp, then DS_READY using the READY timestamp... The problem with this is that we lose information. The question is, do people prefer the slightly kludgy option or the schema changing option? (Note that we already need to update the database with the RolloverScheme policy parameter, the difference there is that if that update is not run we can still operate, just with the default scheme.) Sion From sion at nominet.org.uk Thu Feb 25 11:03:14 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 25 Feb 2010 11:03:14 +0000 Subject: [Opendnssec-develop] KSK rollover In-Reply-To: References: Message-ID: > I'm trying to implement the DoubleDNSKEY scheme without changing the > database. Here is a summary of how the scheme works > > > IpubC == publication interval in child > IpubP == publication interval in parent > > DoubleDNSKEY > > 1. pre-publish key (IpubC + IpubP) before retirement (double safety > margin?) > new key in zone, used to sign > 2. after IpubC prompt for DS to be submitted > 3. wait for ds-seen to be issued > 4. IpubP after (3) the rollover can occur (either manual or automatic) > old key in zone, not used > 5. retired key can move to dead > old key removed > > I think that 4 and 5 occur at the same time... anyway; the issue is that we > have to wait after publication before we can submit the DS record, but we > also have to wait after the DS is seen before we can safely roll the key. > > Currently, the key would go from published to ready at step 2, which means > we have no state to describe "waiting for DS seen". Ideally I would add new > columns "DS-PUBLISHED" and "DS-READY" or similar... Of course this breaks > backwards compatibility. > > One alternative is to move the key into a new state of DS_PUBLISHED when > the DS is seen and reuse the PUBLISHED timestamp, then DS_READY using the > READY timestamp... The problem with this is that we lose information. > > The question is, do people prefer the slightly kludgy option or the schema > changing option? (Note that we already need to update the database with the > RolloverScheme policy parameter, the difference there is that if that > update is not run we can still operate, just with the default scheme.) > One further complication... Should we allow different DS_PUBLISHED and DS_READY times for different zones sharing keys? Currently all times are stored against the key, rather than the zones instance of a key. (I.e. in the keypairs table, not the dnsseckeys table for those familiar with the kasp schema.) This would have implications for all subsequent events like rollovers... Sounds like a new story to me. From owner-dnssec-trac at kirei.se Thu Feb 25 12:18:25 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 25 Feb 2010 12:18:25 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #106: IWBN to export keys to the new BIND 9.7 format (with timing information) In-Reply-To: <087.a9c318cd62a5bf49afda547b0f215abd@kirei.se> References: <087.a9c318cd62a5bf49afda547b0f215abd@kirei.se> Message-ID: <096.7a6c72ec9ebd35c332300d692002103e@kirei.se> #106: IWBN to export keys to the new BIND 9.7 format (with timing information) ---------------------------------------------------------------+------------ Reporter: St?phane Bortzmeyer | Owner: rb Type: enhancement | Status: closed Priority: major | Component: SoftHSM Version: trunk | Resolution: wontfix Keywords: | ---------------------------------------------------------------+------------ Changes (by jakob): * status: new => closed * resolution: => wontfix Comment: softHSM has no knowledge of the timing parameters (and thus cannot export them), nor has any other PKCS#11 provider I know of. in the OpenDNSSEC architecture this is all in the hands of the KASP Enforcer, which on the other hand cannot export keys since they are all in the PKCS#11 provider. -- Ticket URL: OpenDNSSEC OpenDNSSEC From Stephen.Morris at nominet.org.uk Thu Feb 25 18:01:02 2010 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Thu, 25 Feb 2010 18:01:02 +0000 Subject: [Opendnssec-develop] Minutes of teleconference: 2010-02-24 Message-ID: Now available on the wiki: http://trac.opendnssec.org/wiki/Meetings/Minutes/2010-02-24 Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Fri Feb 26 08:18:42 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 26 Feb 2010 09:18:42 +0100 Subject: [Opendnssec-develop] Meeting during IETF in Anaheim Message-ID: <4E9171EA-CE1E-40A6-8FC7-F183EC233E6A@iis.se> Hi We should try to schedule a meeting during the IETF in Anaheim. Please fill in the doodle: http://www.doodle.com/yvnnqwzek2wegsxa Thanks // Rickard From jakob at kirei.se Sun Feb 28 18:13:38 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Sun, 28 Feb 2010 19:13:38 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.0.1 In-Reply-To: <7809D36C-4825-4B35-94A5-7E7A75209057@iis.se> References: <7809D36C-4825-4B35-94A5-7E7A75209057@iis.se> Message-ID: <0A2AE627-4878-4406-A096-208D6F691403@kirei.se> while moving all common variables to OPENDNSSEC_COMMON, I've discovered the following errors. I suggest we commit this to the 1.0 branch: Index: signer/configure.ac =================================================================== --- signer/configure.ac (revision 2904) +++ signer/configure.ac (working copy) @@ -31,7 +31,7 @@ ], [CFLAGS="-D__EXTENSIONS__ $CFLAGS"]) fetch_pid_file=$localstatedir/run/opendnssec/zone_fetcher.pid -signer_cli="$prefix/bin/ods-signer sign" +signer_cli="$prefix/sbin/ods-signer sign" AC_DEFINE_UNQUOTED(FETCH_PIDFILE, ["`eval echo $fetch_pid_file | sed s,NONE,$ac_default_prefix,g`"], [Path to the OpenDNSSEC zone fetcher pid file]) AC_DEFINE_UNQUOTED(SIGNER_CLI_COMMAND, ["`eval echo $signer_cli | sed s,NONE,$ac_default_prefix,g`"], [Path to the OpenDNSSEC signer engine cli]) Index: signer/README =================================================================== --- signer/README (revision 2904) +++ signer/README (working copy) @@ -202,7 +202,7 @@ running the engine ------------------ -You can run the engine bij calling /bin/ods-signer start +You can run the engine by calling /sbin/ods-signer start If everything is ok, you should see the following output: $ ./ods-signer start Index: tools/solaris/ods-signerd.init.in =================================================================== --- tools/solaris/ods-signerd.init.in (revision 2904) +++ tools/solaris/ods-signerd.init.in (working copy) @@ -30,7 +30,7 @@ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:@full_prefix@/lib signer_bin_file="@full_prefix@/sbin/ods-signerd" -signer_cli_file="@full_prefix@/bin/ods-signer" +signer_cli_file="@full_prefix@/sbin/ods-signer" signer_pid_file="@localstatedir@/run/opendnssec/signerd.pid" case "$1" in