From rickard.bellgrim at iis.se Wed Sep 1 06:49:12 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 1 Sep 2010 08:49:12 +0200 Subject: [Opendnssec-develop] trunk/utils directory In-Reply-To: <201008311444.28857.sion@nominet.org.uk> References: <201008311444.28857.sion@nominet.org.uk> Message-ID: <95B415CF-422B-4DD1-B8E3-C9318AD220E5@iis.se> On 31 aug 2010, at 15.44, Sion Lloyd wrote: > Is this right? Look like it is right. The SIGNER part of the name might although have to do with the signer engine. // Rickard From rickard.bellgrim at iis.se Wed Sep 1 06:54:05 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 1 Sep 2010 08:54:05 +0200 Subject: [Opendnssec-develop] Meeting today Message-ID: Hello We have a meeting today at 14:00 CEST, 13:00 BST. Agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-09-01 Please add any topics you want to discuss during the meeting. // Rickard From matthijs at NLnetLabs.nl Wed Sep 1 07:00:16 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 01 Sep 2010 09:00:16 +0200 Subject: [Opendnssec-develop] trunk/utils directory In-Reply-To: <201008311444.28857.sion@nominet.org.uk> References: <201008311444.28857.sion@nominet.org.uk> Message-ID: <4C7DFA00.4060202@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks right, though I introduced ODS_SE_* defines to be part of the OpenDNSSEC signer engine. For example: ODS_SE_WORKDIR refers to the signer engine working directory, which might differ from the enforcer working directory. Might I suggest ODS_EF_KASPCHECK or something similar? Matthijs On 08/31/2010 03:44 PM, Sion Lloyd wrote: > Hi there. > > I'm not sure if I am doing the right thing, I just want to check. > > I want to add a #define ODS_SE_KASPCHECK to config.h to check for the > existance of, and run, ods-kaspcheck as per pivotal story 3998557. > > So what I did was edit trunk/utils/m4/opendnssec_common.m4 and then run make > install which copies that file into the OpenDNSSEC directory... See svn status > and diff below. > > Is this right? I assume that acx_cunit.m4 apparently changing has nothing to > do with me and I won't commit it. > > Cheers, > Sion > > > sion at sion:~/temp/opendnssec/trunk$ svn status -q > M hsmbully/m4/acx_cunit.m4 > M utils/m4/opendnssec_common.m4 > M OpenDNSSEC/m4/opendnssec_common.m4 > M OpenDNSSEC/plugins/eppclient/m4/opendnssec_common.m4 > M OpenDNSSEC/auditor/m4/opendnssec_common.m4 > sion at sion:~/temp/opendnssec/trunk$ svn diff utils/m4/opendnssec_common.m4 > Index: utils/m4/opendnssec_common.m4 > =================================================================== > --- utils/m4/opendnssec_common.m4 (revision 3830) > +++ utils/m4/opendnssec_common.m4 (working copy) > @@ -60,6 +60,7 @@ > OPENDNSSEC_SIGNER_SOCKET=$OPENDNSSEC_PID_DIR/engine.sock > OPENDNSSEC_SIGNER_ENGINE=$OPENDNSSEC_SBIN_DIR/ods-signerd > OPENDNSSEC_SIGNER_AUDITOR=$OPENDNSSEC_BIN_DIR/ods-auditor > +OPENDNSSEC_SIGNER_KASPCHECK=$OPENDNSSEC_BIN_DIR/ods-kaspcheck > OPENDNSSEC_SIGNER_CLI=$OPENDNSSEC_SBIN_DIR/ods-signer > > AC_SUBST([OPENDNSSEC_SIGNER_SOCKET]) > @@ -79,5 +80,6 @@ > AC_DEFINE_UNQUOTED(ODS_SE_ENGINE, ["$OPENDNSSEC_SIGNER_ENGINE -vvv"], [Path > to the OpenDNSSEC signer engine binary]) > AC_DEFINE_UNQUOTED(ODS_SE_CLI, ["$OPENDNSSEC_SIGNER_CLI"], [Path to the > OpenDNSSEC signer client binary]) > AC_DEFINE_UNQUOTED(ODS_SE_AUDITOR, ["$OPENDNSSEC_SIGNER_AUDITOR"], [Path > to the OpenDNSSEC auditor binary]) > +AC_DEFINE_UNQUOTED(ODS_SE_KASPCHECK, ["$OPENDNSSEC_SIGNER_KASPCHECK"], > [Path to the OpenDNSSEC kaspcheck binary]) > > ]) > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMffn/AAoJEA8yVCPsQCW5QEIH/i9yOhGYyZyRmHUO5+Buya4K yKPJ46D0W6DOOvhmUbv7UMxAwbpIUPyTxy9PLFVPtLTCOWeq/00Htm1jhKwiwMrV mgrwrJOjKxiEGEFEYFDbrzWiLm7BGjDfaEiqG71pWjJikrLnXON7hNT5BKhj1E3n jrkJ+UNx2MegRsokq9Wpw4iK2YKq0aOKUAwduREULSPqgc+mPI4Qa/hmvQierzXR C37W7l2o9LX1Ql3GoUFcRtK6ZjUBSlOBoF77LnOPX35BBM7bSWvfoLLvGX5uQfPP /CpgeLgTIDRdQ+IxyMKrUK0giOIwYMuHlnKIsRrI6+LGpBdgxK7FO1THPIlbCMo= =yhIb -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Wed Sep 1 07:29:20 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 01 Sep 2010 07:29:20 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #179: Auditor problem with srv records and hypens In-Reply-To: <077.927b5a6fb972cd2aea5c0b1df8e88eb4@kirei.se> References: <077.927b5a6fb972cd2aea5c0b1df8e88eb4@kirei.se> Message-ID: <086.0878c4c0b49964eaf6428c8355f566ea@kirei.se> #179: Auditor problem with srv records and hypens ------------------------------------------------------+--------------------- Reporter: P?sztor J?nos | Owner: alex Type: defect | Status: closed Priority: critical | Component: Auditor Version: 1.1.1 | Resolution: invalid Keywords: | ------------------------------------------------------+--------------------- Changes (by alex): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From AlexD at nominet.org.uk Wed Sep 1 07:37:00 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 1 Sep 2010 07:37:00 +0000 Subject: [Opendnssec-develop] Default InceptionOffset In-Reply-To: References: Message-ID: <9CAFF28F-4F26-4B32-A4F4-FA82D90E61B7@nominet.org.uk> > We have one hour as the default inception offset in kasp.xml, but the ods-kaspcheck gives as warning if it is greater than 10 minutes. Should we change the default value or the requirements of the ods-kaspcheck? Changed requirements to one hour. Alex. From AlexD at nominet.org.uk Wed Sep 1 14:28:18 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 1 Sep 2010 14:28:18 +0000 Subject: [Opendnssec-develop] Signconf.xml and partial auditing Message-ID: Hi - If you define the tag in the element of signconf.xml (in defiance of the signconf.rnc), then the signer fails. The enforcer does this if it sees in the kasp.xml policy. Has the enforcer always done this? Has the tag ever existed? Does the signer use this tag, or does it look as kasp.xml? Thanks, Alex. From jakob at kirei.se Thu Sep 2 05:56:14 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 2 Sep 2010 07:56:14 +0200 Subject: [Opendnssec-develop] Signconf.xml and partial auditing In-Reply-To: References: Message-ID: <2D47514D-BAD6-46BC-8611-6DF927CCA534@kirei.se> On 1 sep 2010, at 16.28, Alex Dalitz wrote: > If you define the tag in the element of signconf.xml (in defiance of the signconf.rnc), then the signer fails. The enforcer does this if it sees in the kasp.xml policy. > > Has the enforcer always done this? Has the tag ever existed? The current signconf schema does allow any tags inside . On the other hand, the comments in the schema indicates that the contents of are to be taken from the KASP. jakob From patrik.wallstrom at iis.se Sat Sep 4 08:44:03 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Sat, 4 Sep 2010 10:44:03 +0200 Subject: [Opendnssec-develop] bug with adding zones on opendnssec trunk Message-ID: <8CB841A9-579E-4AA0-8015-8DC871D3FE25@iis.se> Add some zones using ods-ksmutil zone add. Then do ods-ksmutil update zonelist, and all the (added) zones are removed from the configuration. This was a really unexpected behaviour. But what should happen? Using zone add the zones were never added to the zonelist.xml though, so I guess it is correct, but the problem might be zone add. -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From owner-dnssec-trac at kirei.se Sat Sep 4 09:45:54 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sat, 04 Sep 2010 09:45:54 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #180: New map Message-ID: <047.aca7f40b0d2e116de23efbf795be8b42@kirei.se> #180: New map ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ----------------------+----------------------------------------------------- {{{ #!html Main
Viagra indications
Viagra celias
Viagra capsules
Viagra joks
M585 viagra
Viagra shop
Viagra dissent
Viagra germany
Viagra patent
Viagra clipart
Viagra rezeptfrei
    Dog viagra
    Viagra chemistry
    Frau viagra
    Viagra secret
    Herbal viagra
    Altertive viagra
    Porn viagra
    Viagra interactions
    Viagra ad
    Aftermarket viagra
    Viagra now
    Testing viagra
    Viagra deals
    Substitute viagra
    Viagra equivalent
    Overseas viagra
    Viagra testimony
    Viagra facial
    Viagra how
    Steroid viagra
    Snort viagra
    Viagra strenghts
    Contact viagra
    Viagra daily
    Demora viagra
    Hrx viagra
    Veeline viagra
    Viagra color
    Viagra addiction
    Online viagra
    Viagra norco
    Viagra misleading
    Viagra wholesale
    Viagra france
    Viagra sports
    Viagra keyword
    Best viagra
    Viagra newsletter
    Viagra coma
    Blindness viagra
    Viagra hypertension
    Viagra usage
    Viagra language
    Viagra substatute
    Kasumifanbbs viagra
    Need viagra
    Tulip viagra
    Viagra urethral
    Viagra extacy
    Viagra watermelon
    Viagra cactus
    Viagra commericials
    Viagra alcahol
    Viagra large
    Viva viagra
    Internet viagra
    Viagra freebies
    Viagra without
    Viagra jelly
    Viagra dreampharm
    Viagra gift
    Viagra delivery
    Viagra subsatute
    Viagra tune
    Viagra timing
    Viagra interaction
    Viagra test
    Viagra magazine
    Viagra dildo
    Viagra websites
    Viagra scottland
    Viagra resource
    Arrythmia viagra
    Latvia viagra
    Viagra joke
    Sophia viagra
    Offical viagra
    Thug viagra
    Viagra sperm
    Viagra pharmacokinetics
    Viagra selges
    Viagra crohn's
    Pleasure viagra
    Viagra crap
    Viagra siesta
    Supplier viagra
    Lipitor viagra
    Hiv viagra
    Viagra affects
    Viagra pills
    Lsbian viagra
    Viagra parties
    Viagra drugs
    Viagra merchant
    Mexican viagra
    Viagra pushups
    Metformin viagra
    Viagra refills
    Viagra rosa
    Phizer viagra
    Indian viagra
    Viagra herb
    Viagra maker
    Viagra result
    Chopping viagra
    About viagra
    Nature's viagra
    Headaches viagra
    Viagra enema
    Synthetic viagra
    Ddmac viagra
    Viagra moa
    Kaufen viagra
    Genetic viagra
    Viagra testimonies
    Viagra supplement
    Viagra hat
    Viagra oxytocin
    Viagra scams
    Viagra bangkok
    Viagra water
    Viagra men
    Viagra peeing
    Viagra forums
    Viagra virus
    Viagra faqs
    Viagra synthesis
    Half viagra
    Kamagra viagra
    Prescription-free viagra
    Discounted viagra
    Wiki viagra
    Bangkok viagra
    Dicloxacil viagra
    Viagra profesional
    Viagra vancouver
    Vidrgne viagra
    Viagra generica
    African viagra
    Viagra sa
    Viagra levitra
    Viagra physer
    Drunk viagra
    Viagra fact
    Viagra theme
    Naturopathic viagra
    Viagra impact
    Video viagra
    Nonprescription viagra
    Viagra animate
    Viagra pregnancy
    Viagra manufacturing
    Viagra dog
    Viagra samples
    Viagra mug
    Trouver viagra
    Viagra nottingham
    Viagra options
    Viagra pastilles
    Calias viagra
    Flomax viagra
    Movie viagra
    Viagra canadian
    Idose viagra
    Viagra prescriptions
    Sell viagra
    Viagra 50mg
    Cialas viagra
    Xray viagra
    Viagra utah
    Viagra ecstasy
    Viagra iowa
    Viagra dicks
    Viagra capsule
    Viagra types
    Teenagers viagra
    Cvs viagra
    Viagra question
    Walgreen viagra
    Re viagra
    Viagra marching
    Viagra vitamans
    Green viagra
    Viagra tylenol
    Viagra 2
    Viagra cursor
    Viagra graphic
    Viagra emoticon
    Viagra idiots
    Viagra tutorial
    Viagra vietnam
    Milf viagra
    On-line viagra
    Viagra on- line
    Cfids viagra
    Official viagra
    Funkadelic viagra
    Viagra online
    Viagra chrismas
    Gerneric viagra
    Viagra efectos
    Viagra aphrodisiac
    Plateau viagra
    Aspirin viagra
    Viagra stories
    Viagra prozac
    Viagra inc
    Viagra wiki
    Safe viagra
    Canada viagra
    Viagra naturale
    Thailand viagra
    Viagra patent
    Genirc viagra
    Cigar viagra
    Viagra cialas
    Viagra super
    Viagra lolo
    Watermallon viagra
    Viagra incidents
    Viagra doctor
    Viagra teenager
    Viagra field
    Viagra phuket
    Viagra xenical
    Viagra info
    Viagra definition
    Viagra contest
    }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Mon Sep 6 07:29:15 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Mon, 6 Sep 2010 08:29:15 +0100 Subject: [Opendnssec-develop] bug with adding zones on opendnssec trunk In-Reply-To: <8CB841A9-579E-4AA0-8015-8DC871D3FE25@iis.se> References: <8CB841A9-579E-4AA0-8015-8DC871D3FE25@iis.se> Message-ID: <201009060829.15774.sion@nominet.org.uk> On Saturday 04 Sep 2010 9:44:03 am Patrik Wallstr?m wrote: > Add some zones using ods-ksmutil zone add. Then do ods-ksmutil update > zonelist, and all the (added) zones are removed from the configuration. > This was a really unexpected behaviour. But what should happen? Using zone > add the zones were never added to the zonelist.xml though, so I guess it > is correct, but the problem might be zone add. Are you using the --no-xml flag? There is an issue where adding zones to the database only followed by an update removes zones which don't exist in the database. (Normally we regard the zonelist as the authority.) So if you add zones without altering the xml you need to use the "ods-ksmutil zonelist export" command to create a new zonelist that reflects the database. Is it the case that the --no-xml flag is defaulting to on? What message do you get when you do a zone add? Sion From owner-dnssec-trac at kirei.se Mon Sep 6 07:30:40 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 06 Sep 2010 07:30:40 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #181: Multi-master mode MySQL breaks KASP Enforcer Message-ID: <045.9047d2edad78872271e5fbd8c639c7da@kirei.se> #181: Multi-master mode MySQL breaks KASP Enforcer --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: --------------------+------------------------------------------------------- We have setup a replicated signer on top of a multi-master-mode MySQL database. This gave unexpected results; concretely, our datecounter setting in kasp.xml was turned into (null) in the .signconf files. We found the cause to be the multi-master mode of MySQL. If you use that, you set auto_increment such that no two nodes can generate the same IDs automatically; in our case, one signer generated even numbers and the other produced odd numbers. This led to IDs that were not 1, 2, 3, ... but 1, 3, 5, ... and it appears that the KASP Enforcer has a hard-coded assumption of the former scheme. A work-around that worked for us: Since no two nodes will be actively inserting records at the same time, we skipped the cautious distributed auto-numbering scheme of MySQL. This means that KASP may now assume a 1, 2, 3, ... auto-numbering scheme as with a single node. This brought back the usual level of reliable service. Solutions in the KASP code could be any of: 1. Use the function that provides the last auto-generated ID; 2. Do not resort to autonumbering but write explicit IDs for such things as configuration parameters; 3. Use strings like 'datecounter' everywhere in the database scheme, and less numeric IDs. We hope this is a useful report in preparation of 1.2. It is a bug in 1.1.2 that warrants a resolution or a warning to users. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon Sep 6 07:34:34 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 6 Sep 2010 09:34:34 +0200 Subject: [Opendnssec-develop] Key sharing and new zones Message-ID: Hi What logic should we have when adding new zones to a policy that is sharing keys between already existing zones? The current trunk takes take the first available keys. But that means that the zone will most likely get dead or retired keys (according to the other zones). The keys will be assigned since they haven't been purged yet. Shouldn't we use the newest set of keys in order to be aligned with the zone that has progressed the furthest in key rollovers? The reason not to use a dead or retired key is because we somehow have determined them to be unsafe to use, when we do a rollover. // Rickard From sion at nominet.org.uk Mon Sep 6 07:39:57 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Mon, 6 Sep 2010 08:39:57 +0100 Subject: [Opendnssec-develop] Key sharing and new zones In-Reply-To: References: Message-ID: <201009060839.57128.sion@nominet.org.uk> > What logic should we have when adding new zones to a policy that is sharing > keys between already existing zones? > > The current trunk takes take the first available keys. But that means that > the zone will most likely get dead or retired keys (according to the other > zones). The keys will be assigned since they haven't been purged yet. > Shouldn't we use the newest set of keys in order to be aligned with the > zone that has progressed the furthest in key rollovers? > > The reason not to use a dead or retired key is because we somehow have > determined them to be unsafe to use, when we do a rollover. It should only pick up dead keys which "died of natural causes", i.e. ones that were retired according to their lifetime, not ones which were rolled manually... Of course if we want to keep zones roughly in sync then I should probably take the currently active keys instead. This might not be so simple in a system where a key exists in lots of different states... So the logic could be "the oldest key which is not in the retired state on any zone"? Or "the most recently published key"? Sion From owner-dnssec-trac at kirei.se Mon Sep 6 07:42:45 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 06 Sep 2010 07:42:45 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #161: Patch: 2-phase key backup for ksmutil In-Reply-To: <045.dbe3ce6fe250145055e6983accf2520c@kirei.se> References: <045.dbe3ce6fe250145055e6983accf2520c@kirei.se> Message-ID: <054.68228c527182abf74c874a1eb2fac0f3@kirei.se> #161: Patch: 2-phase key backup for ksmutil ------------------------+--------------------------------------------------- Reporter: vanrein | Owner: sion Type: enhancement | Status: new Priority: major | Component: Enforcer Version: | Keywords: 2-phase backup ------------------------+--------------------------------------------------- Comment(by vanrein): A comment about this/our patch to 2-phase key backup: We did not spot all the places where information about the key types is located in code; concretely, this can lead to reports about unrecognised key state 11. This state 11 is the intermediate state that we introduced as the temporary state between prepare and commit. This message occured when we folded two OpenDNSSEC cycles in one another; that is, before having backed up keys for a new zone, we already submitted new ones and notified the enforcer of the change. The message appears to be harmless. The problem is hereby documented alongside our patch in trac; please note that the branch has 2-phase key backup that is likely to be better integrated with the rest of the KASP Enforcer. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 6 07:55:06 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 06 Sep 2010 07:55:06 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #181: Multi-master mode MySQL breaks KASP Enforcer In-Reply-To: <045.9047d2edad78872271e5fbd8c639c7da@kirei.se> References: <045.9047d2edad78872271e5fbd8c639c7da@kirei.se> Message-ID: <054.2d53f803b3d7fce3b8beca9ebb6f1bb1@kirei.se> #181: Multi-master mode MySQL breaks KASP Enforcer --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: --------------------+------------------------------------------------------- Comment(by sion): I've added a story to pivotal. I think that the fix I'll work on is not using autoincrement for Id fields. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at openfortress.nl Mon Sep 6 08:19:16 2010 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 6 Sep 2010 08:19:16 +0000 Subject: [Opendnssec-develop] Key sharing and new zones In-Reply-To: References: Message-ID: <20100906081916.GA26979@phantom.vanrein.org> Hello, > The current trunk takes take the first available keys. But that means that the zone will most likely get dead or retired keys (according to the other zones). The keys will be assigned since they haven't been purged yet. Shouldn't we use the newest set of keys in order to be aligned with the zone that has progressed the furthest in key rollovers? I would formulate an answer in terms of "the key shouldn't be scheduled for rolling very soon, nor should it be used longer than we deem safe". What that means in most practical scenarios is to use the newest. > The reason not to use a dead or retired key is because we somehow have determined them to be unsafe to use, when we do a rollover. Of course. -Rick From patrik.wallstrom at iis.se Mon Sep 6 08:32:44 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Mon, 6 Sep 2010 10:32:44 +0200 Subject: [Opendnssec-develop] bug with adding zones on opendnssec trunk In-Reply-To: <201009060829.15774.sion@nominet.org.uk> References: <8CB841A9-579E-4AA0-8015-8DC871D3FE25@iis.se> <201009060829.15774.sion@nominet.org.uk> Message-ID: <54689AA5-5780-44F3-98D5-3B7051B13AC8@iis.se> On Sep 6, 2010, at 9:29 AM, Sion Lloyd wrote: > > On Saturday 04 Sep 2010 9:44:03 am Patrik Wallstr?m wrote: >> Add some zones using ods-ksmutil zone add. Then do ods-ksmutil update >> zonelist, and all the (added) zones are removed from the configuration. >> This was a really unexpected behaviour. But what should happen? Using zone >> add the zones were never added to the zonelist.xml though, so I guess it >> is correct, but the problem might be zone add. > > Are you using the --no-xml flag? There is an issue where adding zones to the > database only followed by an update removes zones which don't exist in the > database. (Normally we regard the zonelist as the authority.) I did not use the --no-xml flag. > So if you add zones without altering the xml you need to use the "ods-ksmutil > zonelist export" command to create a new zonelist that reflects the database. > > Is it the case that the --no-xml flag is defaulting to on? What message do you > get when you do a zone add? I spent some time testing this now. The problem (still) seems to be that if I start up the system from scratch, with no zones added, and the zonelist is empty - is that I get this error message (without --no-xml) when adding zones: Not enough keys to satisfy zsk policy for zone: 6suffix.orgods-enforcerd will create some more keys on its next runError allocating zsks to zone 6suffix.orgFailed to Link Keys to zone And also, nothing is added to zonelist.xml. If I do exactly the same thing, but before starting the system add an example.com zone and setup the system with that, all new zones are added just fine with this message: "Imported zone: 6suffix.org" What is --no-xml used for? Can I run the system without any dependency on zonelist.xml? -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From sion at nominet.org.uk Mon Sep 6 09:16:59 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Mon, 6 Sep 2010 10:16:59 +0100 Subject: [Opendnssec-develop] bug with adding zones on opendnssec trunk In-Reply-To: <54689AA5-5780-44F3-98D5-3B7051B13AC8@iis.se> References: <8CB841A9-579E-4AA0-8015-8DC871D3FE25@iis.se> <201009060829.15774.sion@nominet.org.uk> <54689AA5-5780-44F3-98D5-3B7051B13AC8@iis.se> Message-ID: <201009061016.59776.sion@nominet.org.uk> On Monday 06 Sep 2010 9:32:44 am Patrik Wallstr?m wrote: > On Sep 6, 2010, at 9:29 AM, Sion Lloyd wrote: > > On Saturday 04 Sep 2010 9:44:03 am Patrik Wallstr?m wrote: > >> Add some zones using ods-ksmutil zone add. Then do ods-ksmutil update > >> zonelist, and all the (added) zones are removed from the configuration. > >> This was a really unexpected behaviour. But what should happen? Using > >> zone add the zones were never added to the zonelist.xml though, so I > >> guess it is correct, but the problem might be zone add. > > > > Are you using the --no-xml flag? There is an issue where adding zones to > > the database only followed by an update removes zones which don't exist > > in the database. (Normally we regard the zonelist as the authority.) > > I did not use the --no-xml flag. > > > So if you add zones without altering the xml you need to use the > > "ods-ksmutil zonelist export" command to create a new zonelist that > > reflects the database. > > > > Is it the case that the --no-xml flag is defaulting to on? What message > > do you get when you do a zone add? > > I spent some time testing this now. > > The problem (still) seems to be that if I start up the system from scratch, > with no zones added, and the zonelist is empty - is that I get this error > message (without --no-xml) when adding zones: > > Not enough keys to satisfy zsk policy for zone: 6suffix.orgods-enforcerd > will create some more keys on its next runError allocating zsks to zone > 6suffix.orgFailed to Link Keys to zone > > And also, nothing is added to zonelist.xml. > > If I do exactly the same thing, but before starting the system add an > example.com zone and setup the system with that, all new zones are added > just fine with this message: > > "Imported zone: 6suffix.org" > > What is --no-xml used for? Can I run the system without any dependency on > zonelist.xml? I think that Rickard and I have got somewhere with this. You will still see the error message but the zones should appear in the zonelist now. If the behaviour is right then I will suppress that message (if I can) when there are no zones. Sion From rick at openfortress.nl Mon Sep 6 09:18:28 2010 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 6 Sep 2010 09:18:28 +0000 Subject: [Opendnssec-develop] Meeting notes 2010-09-01 Message-ID: <20100906091828.GF26979@phantom.vanrein.org> Hello, Better late than never: I wrote the notes of last meeting. Alex, you hadn't included your minutes in the list of agendas/minutes, I also did that for you. Cheers, -Rick From sion at nominet.org.uk Mon Sep 6 10:29:54 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Mon, 6 Sep 2010 11:29:54 +0100 Subject: [Opendnssec-develop] Key sharing and new zones In-Reply-To: <20100906081916.GA26979@phantom.vanrein.org> References: <20100906081916.GA26979@phantom.vanrein.org> Message-ID: <201009061129.54923.sion@nominet.org.uk> > > The current trunk takes take the first available keys. But that means > > that the zone will most likely get dead or retired keys (according to > > the other zones). The keys will be assigned since they haven't been > > purged yet. Shouldn't we use the newest set of keys in order to be > > aligned with the zone that has progressed the furthest in key rollovers? > > I would formulate an answer in terms of "the key shouldn't be scheduled for > rolling very soon, nor should it be used longer than we deem safe". What > that means in most practical scenarios is to use the newest. The problem with this is that in order to properly describe "very soon" we need a new configuration parameter. So, would everyone be happy if I go with "the most recently published key"? This would be the active key unless it's sucessor has already been published. Of course if you happen to run just before the next key is published then you will use a key that is about to retire. If we want to avoid that and use some logic like "only use the active key if it has been active for less than 25% of its lifetime" then: 1) it is more work 2) adding zones will be slower and 3) we either need a new configuration option, or we hard-code something. none of which mean that we shouldn't do it of course. Sion From rick at openfortress.nl Mon Sep 6 11:23:23 2010 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 6 Sep 2010 11:23:23 +0000 Subject: [Opendnssec-develop] Key sharing and new zones In-Reply-To: <201009061129.54923.sion@nominet.org.uk> References: <20100906081916.GA26979@phantom.vanrein.org> <201009061129.54923.sion@nominet.org.uk> Message-ID: <20100906112323.GA31318@phantom.vanrein.org> Hey, > The problem with this is that in order to properly describe "very soon" > we need a new configuration parameter. > > So, would everyone be happy if I go with "the most > recently published key"? Agreed (on both points). > This would be the active key unless it's sucessor has already been > published. Of course if you happen to run just before the next key is > published then you will use a key that is about to retire. Yes, and "very soon" then basically becomes "we haven't yet started the process of introducing new key material". Makes bundles of sense to me. > If we want to avoid that and use some logic like "only use the active > key > if it has been active for less than 25% of its lifetime" then: > 1) it is more work > 2) adding zones will be slower > and > 3) we either need a new configuration option, or we hard-code something. > none of which mean that we shouldn't do it of course. This all sounds like a bad idea to me... -Rick From owner-dnssec-trac at kirei.se Mon Sep 6 19:35:14 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 06 Sep 2010 19:35:14 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #182: prostitute Message-ID: <047.59f61ade9cbbdf9d6e49a22305c2dd20@kirei.se> #182: prostitute ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: prostitute ----------------------+----------------------------------------------------- prostitute,sex in site [http://xgirls.com.ua/] -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 6 19:41:29 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 06 Sep 2010 19:41:29 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #182: prostitute In-Reply-To: <047.59f61ade9cbbdf9d6e49a22305c2dd20@kirei.se> References: <047.59f61ade9cbbdf9d6e49a22305c2dd20@kirei.se> Message-ID: <056.2f51a98962ee22ac23a4d0234863dc56@kirei.se> #182: prostitute -----------------------+---------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: closed Priority: trivial | Component: Unknown Version: trunk | Resolution: invalid Keywords: prostitute | -----------------------+---------------------------------------------------- Changes (by jakob): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Sep 8 09:24:32 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 08 Sep 2010 09:24:32 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #177: ods-control stucks if enforcer is dead In-Reply-To: <059.51e1c6c7f1497a515487a34ffeb43187@kirei.se> References: <059.51e1c6c7f1497a515487a34ffeb43187@kirei.se> Message-ID: <068.19e1a7a43d84fef04a39aee1a3c232dd@kirei.se> #177: ods-control stucks if enforcer is dead ----------------------------------+----------------------------------------- Reporter: sebastian@? | Owner: sion Type: defect | Status: closed Priority: minor | Component: Enforcer Version: trunk | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Changes (by vanrein): * status: new => closed * resolution: => fixed Comment: We discussed this in our last meeting. The problem can also occur when replacing RPMs, which is a more serious case. It is not serious or difficult enough to warrant a new release, but it has been fixed in trunk and is therefore (a) available and (b) heading for future releases. I hope this solves it for you too. Thanks for reporting. -- Ticket URL: OpenDNSSEC OpenDNSSEC From AlexD at nominet.org.uk Thu Sep 9 09:58:17 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Thu, 9 Sep 2010 09:58:17 +0000 Subject: [Opendnssec-develop] Default algorithm Message-ID: <8543D5D8-0619-48ED-AF9B-3171B8FF6BE2@nominet.org.uk> Hi - Wouter has suggested making the default algorithm in kasp.xml be 8, not 7. I think I agree. WDYT? Thanks, Alex. From marco.davids at sidn.nl Thu Sep 9 09:59:30 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Thu, 9 Sep 2010 11:59:30 +0200 Subject: [Opendnssec-develop] Default algorithm In-Reply-To: <8543D5D8-0619-48ED-AF9B-3171B8FF6BE2@nominet.org.uk> References: <8543D5D8-0619-48ED-AF9B-3171B8FF6BE2@nominet.org.uk> Message-ID: <4C88B002.6020302@sidn.nl> On 09/09/10 11:58, Alex Dalitz wrote: > Wouter has suggested making the default algorithm in kasp.xml be 8, not 7. I think I agree. +1 -- Marco From rick at openfortress.nl Thu Sep 9 11:09:45 2010 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 9 Sep 2010 11:09:45 +0000 Subject: [Opendnssec-develop] Default algorithm In-Reply-To: <4C88B002.6020302@sidn.nl> References: <8543D5D8-0619-48ED-AF9B-3171B8FF6BE2@nominet.org.uk> <4C88B002.6020302@sidn.nl> Message-ID: <20100909110945.GB17939@phantom.vanrein.org> Hi, > Wouter has suggested making the default algorithm in kasp.xml be 8, not 7. I think I agree. +1 Nobody's wants to do key rolling in these early stages of DNSSEC! -Rick From rickard.bellgrim at iis.se Thu Sep 9 11:14:41 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 9 Sep 2010 13:14:41 +0200 Subject: [Opendnssec-develop] Default algorithm In-Reply-To: <8543D5D8-0619-48ED-AF9B-3171B8FF6BE2@nominet.org.uk> References: <8543D5D8-0619-48ED-AF9B-3171B8FF6BE2@nominet.org.uk> Message-ID: <02ED16F5-EBC4-46A7-BDB1-6635E58E214C@iis.se> On 9 sep 2010, at 11.58, Alex Dalitz wrote: > Wouter has suggested making the default algorithm in kasp.xml be 8, not 7. I think I agree. +1 Changes committed to trunk // Rickard From Roland.vanRijswijk at surfnet.nl Thu Sep 9 12:15:14 2010 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 9 Sep 2010 14:15:14 +0200 Subject: [Opendnssec-develop] Default algorithm In-Reply-To: <8543D5D8-0619-48ED-AF9B-3171B8FF6BE2@nominet.org.uk> References: <8543D5D8-0619-48ED-AF9B-3171B8FF6BE2@nominet.org.uk> Message-ID: <704920EE-565F-4AC2-B539-442FCC13168A@surfnet.nl> > Wouter has suggested making the default algorithm in kasp.xml be 8, not 7. I think I agree. > > WDYT? +1, we've just changed all our policies to reflect this ;-) -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From owner-dnssec-trac at kirei.se Fri Sep 10 12:10:14 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 10 Sep 2010 12:10:14 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #183: Serious issue in zone_fetcher (includes patch) Message-ID: <044.29428d0eeaa8ce9153cb1b7cf9a3ffa1@kirei.se> #183: Serious issue in zone_fetcher (includes patch) ---------------------+------------------------------------------------------ Reporter: roland | Owner: rb Type: defect | Status: new Priority: critical | Component: Signer Version: 1.1.1 | Keywords: zone_fetcher AXFR bug ---------------------+------------------------------------------------------ Guys, I have found a serious bug in the zone_fetcher. The result of this bug is that if an AXFR fails half-way through, the zone_fetcher assumes that the transfer was successful. The result of this is that the signer receives a partial zone as input which it will sign diligently and will be served out. The end result is that mangled zones end up on the Internet which is very bad indeed. The patch included with this ticket fixes two issues: * It checks after the AXFR ends whether the AXFR was complete (i.e. whether the SOA record was seen twice as per the RFC, it uses the LDNS function ldns_axfr_complete for this) * The code is changed so the ldns_resolver structure used by the zone_fetcher is not re-used. I've talked to Wouter from NLnet Labs and he is of the opinion that it was never designed to be used for multiple AXFRs. The fact that the zone_fetcher starts acting erroneously seems to suggest that this is indeed the case. I now create and clean up an ldns_resolver structure for each separate AXFR, this vastly improves the stability of the zone fetcher I highly recommend that we plan a new release ASAP that includes this fix as we got into serious trouble because of this bug. It is most likely to occur for larger zones such as our main domain surfnet.nl. Let's just say that it's not good if all records that start with the letters s-z are not served out... -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Sep 10 12:41:26 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 10 Sep 2010 12:41:26 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #183: Serious issue in zone_fetcher (includes patch) In-Reply-To: <044.29428d0eeaa8ce9153cb1b7cf9a3ffa1@kirei.se> References: <044.29428d0eeaa8ce9153cb1b7cf9a3ffa1@kirei.se> Message-ID: <053.5f77d87528845c87409e00f6df9ae18b@kirei.se> #183: Serious issue in zone_fetcher (includes patch) ----------------------------------+----------------------------------------- Reporter: roland | Owner: rb Type: defect | Status: closed Priority: critical | Component: Signer Version: 1.1.1 | Resolution: fixed Keywords: zone_fetcher AXFR bug | ----------------------------------+----------------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks, applied in r3912 -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Fri Sep 10 12:41:52 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 10 Sep 2010 14:41:52 +0200 Subject: [Opendnssec-develop] Releasing v1.1.3 Message-ID: <3EF9907F-B7E9-40D6-85F6-4D60905F323D@iis.se> Hi Roland found a big issue in the zone fetcher. The zone gets signed, even though the transfer was only partial. He provided a patch and it has been applied to the v1.1 branch. Are we ready to do a quick release of a v1.1.3? http://trac.opendnssec.org/ticket/183 // Rickard From owner-dnssec-trac at kirei.se Fri Sep 10 12:44:53 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 10 Sep 2010 12:44:53 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #184: Zone fetcher should have back off and retry behaviour Message-ID: <044.a602faca92afd2cd4acce3713748395c@kirei.se> #184: Zone fetcher should have back off and retry behaviour -------------------+-------------------------------------------------------- Reporter: roland | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: 1.1.1 | Keywords: Zone fetcher AXFR failure -------------------+-------------------------------------------------------- This ticket is linked to ticket #183 We have noticed that AXFRs sometimes fail half-way through. The fix in ticket #183 ensures that this is now failsafe, i.e. that this doesn't result in a half zone getting signed and served out. The problem of the failed AXFRs remains, however. This problem is intermittent and somewhat hard to predict when it occurs (although it occurs often enough to be reproducible, just not under exact circumstances). In my opinion, the zone fetcher should be able to handle failed AXFRs and should back off and retry later. Because it doesn't do this currently, it will only respond to the next NOTIFY which may again result in a failed AXFR. So I would strongly advocate including a back off and retry mechanism in the zone fetcher (or in the equivalent module that is going to serve this function in 1.2). Apart from that, the current zone fetcher also doesn't support refresh (it doesn't request an AXFR if the SOA refresh of the zone expires). This is probably also a good idea. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Fri Sep 10 12:51:12 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 10 Sep 2010 14:51:12 +0200 Subject: [Opendnssec-develop] Releasing v1.1.3 In-Reply-To: <3EF9907F-B7E9-40D6-85F6-4D60905F323D@iis.se> References: <3EF9907F-B7E9-40D6-85F6-4D60905F323D@iis.se> Message-ID: On 10 sep 2010, at 14.41, Rickard Bellgrim wrote: > Roland found a big issue in the zone fetcher. The zone gets signed, even though the transfer was only partial. He provided a patch and it has been applied to the v1.1 branch. Are we ready to do a quick release of a v1.1.3? > http://trac.opendnssec.org/ticket/183 yes. j From rickard.bellgrim at iis.se Mon Sep 13 13:10:33 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 13 Sep 2010 15:10:33 +0200 Subject: [Opendnssec-develop] Key sharing and new zones In-Reply-To: References: Message-ID: <437C14A1-C33A-41B9-95B9-E07941F051ED@iis.se> Hi On 6 sep 2010, at 09.34, Rickard Bellgrim wrote: > What logic should we have when adding new zones to a policy that is sharing keys between already existing zones? > > The current trunk takes take the first available keys. But that means that the zone will most likely get dead or retired keys (according to the other zones). The keys will be assigned since they haven't been purged yet. Shouldn't we use the newest set of keys in order to be aligned with the zone that has progressed the furthest in key rollovers? > > The reason not to use a dead or retired key is because we somehow have determined them to be unsafe to use, when we do a rollover. What is the status one this one? // Rickard From rickard.bellgrim at iis.se Tue Sep 14 14:30:00 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 14 Sep 2010 16:30:00 +0200 Subject: [Opendnssec-develop] Meeting 2010-09-15 Message-ID: Hi We have a meeting tomorrow. Please add any topics to the draft agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-09-15 // Rickard From marco.davids at sidn.nl Mon Sep 20 08:48:02 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Mon, 20 Sep 2010 10:48:02 +0200 Subject: [Opendnssec-develop] RRSIG's and 2038 Message-ID: <4C971FC2.4010405@sidn.nl> List, Inspired by... https://lists.isc.org/pipermail/bind-users/2010-September/081076.html I tried some dates in the future with DNSSEC and I was able to sign a zone (forfunsec.org) with an expiration time of 20771231000000. Dates after that are not possible, which seems consistent with RFC1982. For what is is worth; DNScheck seems unable to handle this date. It generates an error: 'DNSSEC signature expired'. I haven't tried to lower the date up to a value that DNScheck accepts, but I suspect that it will be somewhere around the year 2038? Reagards, -- Marco Davids Technical Advisor SIDN | Utrechtseweg 310 | 6812 AR | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 83 | M +31 (0)6 52 37 34 35 | F +31 (0)26 352 55 05 marco.davids at sidn.nl | www.sidn.nl | enum:+31652373435 | sip:583 at sidn.nl From patrik.wallstrom at iis.se Mon Sep 20 09:07:40 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Mon, 20 Sep 2010 11:07:40 +0200 Subject: [Opendnssec-develop] RRSIG's and 2038 In-Reply-To: <4C971FC2.4010405@sidn.nl> References: <4C971FC2.4010405@sidn.nl> Message-ID: On Sep 20, 2010, at 10:48 AM, Marco Davids (SIDN) wrote: > > List, > > Inspired by... > > https://lists.isc.org/pipermail/bind-users/2010-September/081076.html > > I tried some dates in the future with DNSSEC and I was able to sign a > zone (forfunsec.org) with an expiration time of 20771231000000. Dates > after that are not possible, which seems consistent with RFC1982. > > For what is is worth; DNScheck seems unable to handle this date. It > generates an error: 'DNSSEC signature expired'. > > I haven't tried to lower the date up to a value that DNScheck accepts, > but I suspect that it will be somewhere around the year 2038? I have notified the DNSCheck people. ;) -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From marco.davids at sidn.nl Mon Sep 20 09:56:00 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Mon, 20 Sep 2010 11:56:00 +0200 Subject: [Opendnssec-develop] RRSIG's and 2038 In-Reply-To: References: <4C971FC2.4010405@sidn.nl> Message-ID: <4C972FB0.5090108@sidn.nl> On 09/20/10 11:07, Patrik Wallstr?m wrote: > On Sep 20, 2010, at 10:48 AM, Marco Davids (SIDN) wrote: >> For what is is worth; DNScheck seems unable to handle this date. It >> generates an error: 'DNSSEC signature expired'. > I have notified the DNSCheck people. ;) Ah, wrong list... :-( Sorry for that. -- Marco From sion at nominet.org.uk Tue Sep 21 08:50:39 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 21 Sep 2010 09:50:39 +0100 Subject: [Opendnssec-develop] Running with no policies Message-ID: <201009210950.39456.sion@nominet.org.uk> http://www.pivotaltracker.com/story/show/4180085 In the kasp.rnc file we specifically say that we require one or more policies... Can anyone think why we have that, or think of a reason why I shouldn't change it to zero or more? Sion From rick at openfortress.nl Tue Sep 21 10:58:10 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 21 Sep 2010 10:58:10 +0000 Subject: [Opendnssec-develop] Running with no policies In-Reply-To: <201009210950.39456.sion@nominet.org.uk> References: <201009210950.39456.sion@nominet.org.uk> Message-ID: <20100921105810.GB28770@phantom.vanrein.org> Hey Sion, > http://www.pivotaltracker.com/story/show/4180085 > > In the kasp.rnc file we specifically say that we require one or more > policies... Can anyone think why we have that, or think of a reason why I > shouldn't change it to zero or more? Zero _zones_ for a policy is a logical consequence of supporting subscriptions by members. But zero policies? No, I think you want to be able to pickup parameters like key sizes, and could not possible run OpenDNSSEC without it? Cheers, -Rick From sion at nominet.org.uk Tue Sep 21 12:24:11 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 21 Sep 2010 13:24:11 +0100 Subject: [Opendnssec-develop] Running with no policies In-Reply-To: <20100921105810.GB28770@phantom.vanrein.org> References: <201009210950.39456.sion@nominet.org.uk> <20100921105810.GB28770@phantom.vanrein.org> Message-ID: <201009211324.11113.sion@nominet.org.uk> On Tuesday 21 Sep 2010 11:58:10 am Rick van Rein wrote: > Hey Sion, > > > http://www.pivotaltracker.com/story/show/4180085 > > > > In the kasp.rnc file we specifically say that we require one or more > > policies... Can anyone think why we have that, or think of a reason why I > > shouldn't change it to zero or more? > > Zero _zones_ for a policy is a logical consequence of supporting > subscriptions by members. But zero policies? No, I think you want to be > able to pickup parameters like key sizes, and could not possible run > OpenDNSSEC without it? That is not what the story asks for though... And when "policy prune" is implemented we may well go to zero policies. If the system gets into this state then a policy will need to be added before any zones can be processed. Have I misread the story? If so, could you explain what it means? Cheers, Sion From rick at openfortress.nl Tue Sep 21 14:10:00 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 21 Sep 2010 14:10:00 +0000 Subject: [Opendnssec-develop] Running with no policies In-Reply-To: <201009211324.11113.sion@nominet.org.uk> References: <201009210950.39456.sion@nominet.org.uk> <20100921105810.GB28770@phantom.vanrein.org> <201009211324.11113.sion@nominet.org.uk> Message-ID: <20100921141000.GA32189@phantom.vanrein.org> Hello, > That is not what the story asks for though... And when "policy prune" is > implemented we may well go to zero policies. Good catch. Indeed that could happen. > If the system gets into this state then a policy will need to be added before > any zones can be processed. Might be a good way out. > Have I misread the story? If so, could you explain what it means? I must've had the general idea "it's always good to consider zero cases" in mind while I was writing this up about zero zones per policy, but thinking about it again it seems unlogical to allow for zero policies. Hope that helps, Cheers, -Rick From sion at nominet.org.uk Tue Sep 21 15:40:45 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 21 Sep 2010 16:40:45 +0100 Subject: [Opendnssec-develop] Running with no policies In-Reply-To: <20100921141000.GA32189@phantom.vanrein.org> References: <201009210950.39456.sion@nominet.org.uk> <201009211324.11113.sion@nominet.org.uk> <20100921141000.GA32189@phantom.vanrein.org> Message-ID: <201009211640.45482.sion@nominet.org.uk> > I must've had the general idea "it's always good to consider zero cases" > in mind while I was writing this up about zero zones per policy, but > thinking about it again it seems unlogical to allow for zero policies. I'd rather not have to treat the last policy as "special" and stop it from being purged / pruned... So I would rather change the .rng and deal with a system that has no policies (easy, do nothing if there is nothing to do). You can not add zones to such a system as there is no policy to add it to; so I can't see any bad things happening... It is also a simpler change (one character as opposed to I don't know how many lines). Sion From rick at openfortress.nl Wed Sep 22 08:08:11 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 22 Sep 2010 08:08:11 +0000 Subject: [Opendnssec-develop] Running with no policies In-Reply-To: <201009211640.45482.sion@nominet.org.uk> References: <201009210950.39456.sion@nominet.org.uk> <201009211324.11113.sion@nominet.org.uk> <20100921141000.GA32189@phantom.vanrein.org> <201009211640.45482.sion@nominet.org.uk> Message-ID: <20100922080811.GB17859@phantom.vanrein.org> Hello, > I'd rather not have to treat the last policy as "special" and stop it from > being purged / pruned... Agreed, that's the sort of exception that usually leads to weirdly structured programs. Agreed, that a system without policies has no need for data. Agreed, treating zero-cases gently as a normal part of operations instead of as an exception is a good idea. But I cannot judge if this is practical, which makes me humble instead of pushy towards this somewhat theoretical form of beauty. In short: whatever you think makes sense! > So I would rather change the .rng and deal with a system that has no policies > (easy, do nothing if there is nothing to do). You can not add zones to such a > system as there is no policy to add it to; Indeed, and syntax already takes care of that: a zone can only be defined with a reference to a policy that is known to the system. > so I can't see any bad things > happening... It is also a simpler change (one character as opposed to I don't > know how many lines). Simpler is better, certainly if it makes the concepts more elegant, that is less exception-ridden :-D Good thinking, Sion! -Rick From owner-dnssec-trac at kirei.se Sun Sep 26 13:20:12 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 26 Sep 2010 13:20:12 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #185: SoftHSM under Cygwin Message-ID: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> #185: SoftHSM under Cygwin ------------------------------+--------------------------------------------- Reporter: smokimk@? | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------+--------------------------------------------- I want to try softhsm under windows. I compiled it under cygwin and it is working. Now I want to use it through PKCS#11 interface, but I need a dll, but cygwin has created only exe files (softhsm and softhsm-keyconv). How can I connect to softhsm through PKCS#11 under windows? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 27 08:20:39 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 27 Sep 2010 08:20:39 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #185: SoftHSM under Cygwin In-Reply-To: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> References: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> Message-ID: <064.34f8de2a5e7bfe3ad4fad10cae4a9548@kirei.se> #185: SoftHSM under Cygwin ------------------------------+--------------------------------------------- Reporter: smokimk@? | Owner: rb Type: defect | Status: accepted Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------+--------------------------------------------- Changes (by rb): * status: new => accepted Comment: I haven't tried to build with cygwin, so I do not know what the problem could be. It would be helpful if you have more information about what the compiler says. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 27 09:07:38 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 27 Sep 2010 09:07:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #185: SoftHSM under Cygwin In-Reply-To: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> References: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> Message-ID: <064.004e6f0b5ca1207de1117d85130b1522@kirei.se> #185: SoftHSM under Cygwin ------------------------------+--------------------------------------------- Reporter: smokimk@? | Owner: rb Type: defect | Status: accepted Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------+--------------------------------------------- Comment(by anonymous): There is no problem with the build process, it builds and runs perfectly. But I want to connect through PKCS#11 interface, and under windows it is done through dll (there should be softhsm.dll or something). The compiler (and cygwin) compiled binary exe files, but no dll. Has someone managed to connect to softhsm pkcs#11 interface through windows OS? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Sep 27 09:45:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 27 Sep 2010 09:45:08 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #185: SoftHSM under Cygwin In-Reply-To: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> References: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> Message-ID: <064.fb2a1927155319893dc1c0dd4f9de060@kirei.se> #185: SoftHSM under Cygwin ------------------------------+--------------------------------------------- Reporter: smokimk@? | Owner: rb Type: defect | Status: accepted Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------+--------------------------------------------- Comment(by rb): You get the library in this location when you are building in Unix: (builddir)/src/lib/.libs/libsofthsm.so But you should get a dll file in Windows. This is the file that provides the PKCS#11 interface. If there is no DLL-file then there is something that went wrong. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Sep 28 06:32:35 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 28 Sep 2010 08:32:35 +0200 Subject: [Opendnssec-develop] Meeting 20100929 Message-ID: Hi We have a telephone meeting tomorrow. Date: Wednesday 29 September Time: 14:00-15:00 CEST, 13:00-14:00 BST Here is the agenda. Please add any topics that you would like to discuss: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-09-29 // Rickard From Roland.vanRijswijk at surfnet.nl Tue Sep 28 07:20:22 2010 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 28 Sep 2010 09:20:22 +0200 Subject: [Opendnssec-develop] Meeting 20100929 In-Reply-To: References: Message-ID: <5FCE2240-6880-4705-87AE-8645B0D33176@surfnet.nl> Hi Rickard, all, On 28 sep 2010, at 08:32, Rickard Bellgrim wrote: > We have a telephone meeting tomorrow. > > Date: Wednesday 29 September > Time: 14:00-15:00 CEST, 13:00-14:00 BST > > Here is the agenda. Please add any topics that you would like to discuss: > http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-09-29 I won't be able to attend due to other obligations but have added "Switching to LDNS 1.6.7" to the agenda; we encountered a bug in the zone transfer code included in LDNS that NLnet Labs are currently fixing (this was also the underlying cause that triggered the bug in zone_fetcher that we fixed earlier). I would like to propose either a 1.1.4 release that mandates using LDNS 1.6.7 (although that may be overkill) or a statement to users to please upgrade to LDNS 1.6.7 if they intend to use OpenDNSSEC in "bump-in-the-wire" mode with the zone_fetcher. I've also added USENIX LISA '10 as upcoming event as I will be giving an invited talk there that will feature OpenDNSSEC. Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From owner-dnssec-trac at kirei.se Tue Sep 28 09:57:56 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 28 Sep 2010 09:57:56 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #185: SoftHSM under Cygwin In-Reply-To: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> References: <055.aa769925ca759b25ca67c9324d728d03@kirei.se> Message-ID: <064.3de7921675fc11f996103cf85eb982ee@kirei.se> #185: SoftHSM under Cygwin ------------------------------+--------------------------------------------- Reporter: smokimk@? | Owner: rb Type: defect | Status: accepted Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------+--------------------------------------------- Comment(by anonymous): Nope, there is no dll created, just libsoft.{a, la, lai} The configure and build outputs are given below. The ./configure process is: -------------------------------------------------------------------- $ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes configure: sysconfdir set to /etc configure: localstate set to /var checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking what are the Botan includes... -I/usr/local/include checking what are the Botan libs... -L/usr/local/lib -lbotan checking for Botan >= v1.8.0 ... yes checking for Botan reseed API fix ... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking what are the SQLite3 includes... -I/usr/local/include checking what are the SQLite3 libs... -L/usr/local/lib -lsqlite3 checking sqlite3.h usability... yes checking sqlite3.h presence... yes checking for sqlite3.h... yes checking for sqlite3_prepare_v2 in -lsqlite3... yes checking for sched_yield in -lrt... yes checking for getpassphrase... no checking for sys/time.h... yes checking for dlfcn.h... yes checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for a sed that does not truncate output... /usr/bin/sed checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import| ^x86 DLL checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for dlfcn.h... (cached) yes checking whether we are using the GNU C++ compiler... (cached) yes checking whether g++ accepts -g... (cached) yes checking dependency style of g++... (cached) gcc3 checking how to run the C++ preprocessor... g++ -E checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for ld used by g++... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating src/lib/Makefile config.status: creating src/bin/Makefile config.status: creating checks/Makefile config.status: creating softhsm.conf config.status: creating softhsm.conf.5 config.status: creating src/bin/softhsm.1 config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands ----------------------------------------------------------- The make process is: ------------------------------------------------------------ $ make make all-recursive make[1]: Entering directory `/home/mine/softhsm-1.1.4' Making all in src make[2]: Entering directory `/home/mine/softhsm-1.1.4/src' Making all in lib make[3]: Entering directory `/home/mine/softhsm-1.1.4/src/lib' /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT main.lo -MD -MP -MF .deps/main.Tpo -c -o main.lo main.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT main.lo -MD -MP -MF . deps/main.Tpo -c main.cpp -DDLL_EXPORT -DPIC -o .libs/main.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT main.lo -MD -MP -MF . deps/main.Tpo -c main.cpp -o main.o >/dev/null 2>&1 mv -f .deps/main.Tpo .deps/main.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT mutex.lo -MD -MP -MF .deps/mutex.Tpo -c -o mutex.lo mutex.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT mutex.lo -MD -MP -MF .deps/mutex.Tpo -c mutex.cpp -DDLL_EXPORT -DPIC -o .libs/mutex.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT mutex.lo -MD -MP -MF .deps/mutex.Tpo -c mutex.cpp -o mutex.o >/dev/null 2>&1 mv -f .deps/mutex.Tpo .deps/mutex.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT file.lo -MD -MP -MF .deps/file.Tpo -c -o file.lo file.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT file.lo -MD -MP -MF . deps/file.Tpo -c file.cpp -DDLL_EXPORT -DPIC -o .libs/file.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT file.lo -MD -MP -MF . deps/file.Tpo -c file.cpp -o file.o >/dev/null 2>&1 mv -f .deps/file.Tpo .deps/file.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT log.lo -MD -MP -MF .deps/log.Tpo -c -o log.lo log.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT log.lo -MD -MP -MF .d eps/log.Tpo -c log.cpp -DDLL_EXPORT -DPIC -o .libs/log.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT log.lo -MD -MP -MF .d eps/log.Tpo -c log.cpp -o log.o >/dev/null 2>&1 mv -f .deps/log.Tpo .deps/log.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT attribute.lo -MD -MP -MF .deps/attribute.Tpo -c -o attribute.lo attri bute.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT attribute.lo -MD -MP -MF .deps/attribute.Tpo -c attribute.cpp -DDLL_EXPORT -DPIC -o .libs/attribute. o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT attribute.lo -MD -MP -MF .deps/attribute.Tpo -c attribute.cpp -o attribute.o >/dev/null 2>&1 mv -f .deps/attribute.Tpo .deps/attribute.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT userhandling.lo -MD -MP -MF .deps/userhandling.Tpo -c -o userhandling .lo userhandling.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT userhandling.lo -MD - MP -MF .deps/userhandling.Tpo -c userhandling.cpp -DDLL_EXPORT -DPIC -o .libs/u serhandling.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT userhandling.lo -MD - MP -MF .deps/userhandling.Tpo -c userhandling.cpp -o userhandling.o >/dev/null 2 >&1 mv -f .deps/userhandling.Tpo .deps/userhandling.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT tokenhandling.lo -MD -MP -MF .deps/tokenhandling.Tpo -c -o tokenhandl ing.lo tokenhandling.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT tokenhandling.lo -MD -MP -MF .deps/tokenhandling.Tpo -c tokenhandling.cpp -DDLL_EXPORT -DPIC -o .lib s/tokenhandling.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT tokenhandling.lo -MD -MP -MF .deps/tokenhandling.Tpo -c tokenhandling.cpp -o tokenhandling.o >/dev/nu ll 2>&1 mv -f .deps/tokenhandling.Tpo .deps/tokenhandling.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT mechanisms.lo -MD -MP -MF .deps/mechanisms.Tpo -c -o mechanisms.lo me chanisms.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT mechanisms.lo -MD -MP -MF .deps/mechanisms.Tpo -c mechanisms.cpp -DDLL_EXPORT -DPIC -o .libs/mechani sms.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT mechanisms.lo -MD -MP -MF .deps/mechanisms.Tpo -c mechanisms.cpp -o mechanisms.o >/dev/null 2>&1 mv -f .deps/mechanisms.Tpo .deps/mechanisms.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT SoftHSMInternal.lo -MD -MP -MF .deps/SoftHSMInternal.Tpo -c -o SoftHS MInternal.lo SoftHSMInternal.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftHSMInternal.lo -M D -MP -MF .deps/SoftHSMInternal.Tpo -c SoftHSMInternal.cpp -DDLL_EXPORT -DPIC - o .libs/SoftHSMInternal.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftHSMInternal.lo -M D -MP -MF .deps/SoftHSMInternal.Tpo -c SoftHSMInternal.cpp -o SoftHSMInternal.o >/dev/null 2>&1 mv -f .deps/SoftHSMInternal.Tpo .deps/SoftHSMInternal.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT SoftSlot.lo -MD -MP -MF .deps/SoftSlot.Tpo -c -o SoftSlot.lo SoftSlot .cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftSlot.lo -MD -MP - MF .deps/SoftSlot.Tpo -c SoftSlot.cpp -DDLL_EXPORT -DPIC -o .libs/SoftSlot.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftSlot.lo -MD -MP - MF .deps/SoftSlot.Tpo -c SoftSlot.cpp -o SoftSlot.o >/dev/null 2>&1 mv -f .deps/SoftSlot.Tpo .deps/SoftSlot.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT SoftSession.lo -MD -MP -MF .deps/SoftSession.Tpo -c -o SoftSession.lo SoftSession.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftSession.lo -MD -M P -MF .deps/SoftSession.Tpo -c SoftSession.cpp -DDLL_EXPORT -DPIC -o .libs/Soft Session.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftSession.lo -MD -M P -MF .deps/SoftSession.Tpo -c SoftSession.cpp -o SoftSession.o >/dev/null 2>&1 mv -f .deps/SoftSession.Tpo .deps/SoftSession.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT SoftFind.lo -MD -MP -MF .deps/SoftFind.Tpo -c -o SoftFind.lo SoftFind .cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftFind.lo -MD -MP - MF .deps/SoftFind.Tpo -c SoftFind.cpp -DDLL_EXPORT -DPIC -o .libs/SoftFind.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftFind.lo -MD -MP - MF .deps/SoftFind.Tpo -c SoftFind.cpp -o SoftFind.o >/dev/null 2>&1 mv -f .deps/SoftFind.Tpo .deps/SoftFind.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT SoftDatabase.lo -MD -MP -MF .deps/SoftDatabase.Tpo -c -o SoftDatabase .lo SoftDatabase.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftDatabase.lo -MD - MP -MF .deps/SoftDatabase.Tpo -c SoftDatabase.cpp -DDLL_EXPORT -DPIC -o .libs/S oftDatabase.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftDatabase.lo -MD - MP -MF .deps/SoftDatabase.Tpo -c SoftDatabase.cpp -o SoftDatabase.o >/dev/null 2 >&1 mv -f .deps/SoftDatabase.Tpo .deps/SoftDatabase.Plo /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long- long -g -O2 -MT SoftKeyStore.lo -MD -MP -MF .deps/SoftKeyStore.Tpo -c -o SoftKeyStore .lo SoftKeyStore.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftKeyStore.lo -MD - MP -MF .deps/SoftKeyStore.Tpo -c SoftKeyStore.cpp -DDLL_EXPORT -DPIC -o .libs/S oftKeyStore.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./cryptoki_compat -I/usr/lo cal/include -I/usr/local/include -Wno-long-long -g -O2 -MT SoftKeyStore.lo -MD - MP -MF .deps/SoftKeyStore.Tpo -c SoftKeyStore.cpp -o SoftKeyStore.o >/dev/null 2 >&1 mv -f .deps/SoftKeyStore.Tpo .deps/SoftKeyStore.Plo /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -O2 -version-info 1:4:0 -a void-version -module -o .la -rpath /usr/local/lib main.lo mutex.lo fi le.lo log.lo attribute.lo userhandling.lo tokenhandling.lo mechanisms.lo SoftHSM Internal.lo SoftSlot.lo SoftSession.lo SoftFind.lo SoftDatabase.lo SoftKeyStore. lo -L/usr/local/lib -lbotan -L/usr/local/lib -lsqlite3 -lrt libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared l ibraries libtool: link: ar cru .libs/libsofthsm.a main.o mutex.o file.o log.o attribute. o userhandling.o tokenhandling.o mechanisms.o SoftHSMInternal.o SoftSlot.o SoftS ession.o SoftFind.o SoftDatabase.o SoftKeyStore.o libtool: link: ranlib .libs/libsofthsm.a libtool: link: ( cd ".libs" && rm -f "libsofthsm.la" && ln -s "../libsofthsm.la" "libsofthsm.la" ) make[3]: Leaving directory `/home/mine/softhsm-1.1.4/src/lib' Making all in bin make[3]: Entering directory `/home/mine/softhsm-1.1.4/src/bin' g++ -DHAVE_CONFIG_H -I. -I../.. -I./../lib/cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long-long -g -O2 -MT softhsm.o -MD -MP -MF .deps/sof thsm.Tpo -c -o softhsm.o softhsm.cpp mv -f .deps/softhsm.Tpo .deps/softhsm.Po /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -O2 -static -o softhsm.ex e softhsm.o ../lib/libsofthsm.la -lstdc++ libtool: link: g++ -g -O2 -o softhsm.exe softhsm.o ../lib/.libs/libsofthsm.a -L /usr/local/lib -lbotan /usr/local/lib/libsqlite3.dll.a -lrt /usr/lib/gcc/i686-pc -cygwin/4.3.4/libstdc++.dll.a -L/usr/local/lib -L/usr/lib/gcc/i686-pc- cygwin/4.3 .4 -L/usr/local/lib -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 g++ -DHAVE_CONFIG_H -I. -I../.. -I./../lib/cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long-long -g -O2 -MT softhsm-keyconv.o -MD -MP -MF . deps/softhsm-keyconv.Tpo -c -o softhsm-keyconv.o softhsm-keyconv.cpp mv -f .deps/softhsm-keyconv.Tpo .deps/softhsm-keyconv.Po gcc -DHAVE_CONFIG_H -I. -I../.. -I./../lib/cryptoki_compat -I/usr/local/include -I/usr/local/include -Wno-long-long -g -O2 -pedantic -Wall -Wextra -MT base64. o -MD -MP -MF .deps/base64.Tpo -c -o base64.o base64.c mv -f .deps/base64.Tpo .deps/base64.Po /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -O2 -o softhsm- keyconv.e xe softhsm-keyconv.o base64.o -L/usr/local/lib -lbotan -lstdc++ libtool: link: g++ -g -O2 -o .libs/softhsm-keyconv.exe softhsm-keyconv.o base64. o -L/usr/local/lib -lbotan -lstdc++ ./.libs/lt-softhsm-keyconv.c:229: warning: string length '2668' is greater than the length '509' ISO C90 compilers are required to support ./.libs/lt-softhsm-keyconv.c:276: warning: string length '1250' is greater than the length '509' ISO C90 compilers are required to support make[3]: Leaving directory `/home/mine/softhsm-1.1.4/src/bin' make[3]: Entering directory `/home/mine/softhsm-1.1.4/src' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/mine/softhsm-1.1.4/src' make[2]: Leaving directory `/home/mine/softhsm-1.1.4/src' Making all in checks make[2]: Entering directory `/home/mine/softhsm-1.1.4/checks' gcc -DHAVE_CONFIG_H -I. -I.. -I./../src/lib/cryptoki_compat -DCHECKS_SOFTHSM_CO NF='"./softhsm.conf"' -Wno-long-long -g -O2 -pedantic -Wall -Wextra -MT checks. o -MD -MP -MF .deps/checks.Tpo -c -o checks.o checks.c mv -f .deps/checks.Tpo .deps/checks.Po /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -pedantic -Wall -Wextra -n o-install -o checks.exe checks.o ../src/lib/libsofthsm.la -lstdc++ libtool: link: warning: `-no-install' is ignored for i686-pc-cygwin libtool: link: warning: assuming `-no-fast-install' instead libtool: link: gcc -g -O2 -pedantic -Wall -Wextra -o .libs/checks.exe checks.o ../src/lib/.libs/libsofthsm.a -L/usr/local/lib -lbotan /usr/local/lib/libsqlite3 .dll.a -lrt /usr/lib/gcc/i686-pc-cygwin/4.3.4/libstdc++.dll.a -L/usr/local/lib - L/usr/lib/gcc/i686-pc-cygwin/4.3.4 -L/usr/local/lib -L/usr/lib/gcc/i686 -pc-cygwi n/4.3.4 ./.libs/lt-checks.c:229: warning: string length '4369' is greater than the lengt h '509' ISO C90 compilers are required to support ./.libs/lt-checks.c:285: warning: string length '1569' is greater than the lengt h '509' ISO C90 compilers are required to support make[2]: Leaving directory `/home/mine/softhsm-1.1.4/checks' make[2]: Entering directory `/home/mine/softhsm-1.1.4' make[2]: Leaving directory `/home/mine/softhsm-1.1.4' make[1]: Leaving directory `/home/mine/softhsm-1.1.4'- ------------------------------------------------------------------------------ -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 28 11:32:39 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 28 Sep 2010 11:32:39 -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.8a2617473585722987d58617387a0d8e@kirei.se> #102: 4Suite-XML is obsolete and does not support Python 2.6 --------------------------------+------------------------------------------- Reporter: GooseYArd@? | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: trunk | Resolution: fixed Keywords: 4suite-xml, python | --------------------------------+------------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed Comment: The trunk has a signer engine written in c, so the python dependencies are gone. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Sep 28 11:34:11 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 28 Sep 2010 11:34:11 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #180: New map In-Reply-To: <047.aca7f40b0d2e116de23efbf795be8b42@kirei.se> References: <047.aca7f40b0d2e116de23efbf795be8b42@kirei.se> Message-ID: <056.907d8c9e4dceae175217c5f6cffde7a1@kirei.se> #180: New map ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Wed Sep 29 11:03:01 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Wed, 29 Sep 2010 12:03:01 +0100 Subject: [Opendnssec-develop] ods-control hangs Message-ID: <201009291203.01863.sion@nominet.org.uk> Hi there. I've had this report from Matthijs: http://www.pivotaltracker.com/story/show/5184282 Where I think that because ods-control is looking at the return value of the parent process (not the forked one) it sees "success" even when, for instance, the HSM PIN is wrong in conf.xml... My shell scripting is a bit rusty, and I don't have much experience in it to start with. So can someone sanity-check this before I check it in? I just want the start command to timeout. (Sorry about the indenting.) Cheers, Sion sion at sion:~/work/opendnssec/trunk/OpenDNSSEC$ svn diff tools/ods-control.in Index: tools/ods-control.in =================================================================== --- tools/ods-control.in (revision 4024) +++ tools/ods-control.in (working copy) @@ -62,8 +62,14 @@ "$sbindir/ods-enforcerd" RETVAL=$? if [ $RETVAL = 0 ]; then + i=0 while [ ! -r "$enforcer_pid_file" ]; do sleep 1 + i=$(( $i + 1 )) + if [ $i -ge 10 ]; then + RETVAL=1 + break + fi done fi fi From jakob at kirei.se Wed Sep 29 12:48:37 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 29 Sep 2010 14:48:37 +0200 Subject: [Opendnssec-develop] review: Signature recycle etc. Message-ID: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> please review http://trac.opendnssec.org/wiki/Signer/Signatures. j From matthijs at NLnetLabs.nl Wed Sep 29 13:44:26 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 29 Sep 2010 15:44:26 +0200 Subject: [Opendnssec-develop] review: Signature recycle etc. In-Reply-To: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> References: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> Message-ID: <4CA342BA.2070102@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In Recycling RRSIGs: A signature may NOT be recycled if: * the signature is made by a key marked as Deactivate. I don't think we need a Deactivate flag for this. We proposed Deactivate for Double signature rollover, to enforce creating a new signature with the newly included key. Instead, I want to propose an additional rule under Generated RRSIGs. In Generated RRSIGs: New rule: If there are not enough valid signatures, additional signatures must be created. The DNSKEY RRset MUST have equally number of signatures as there are active KSKs. Every other RRset MUST have equally number of signatures as there are active ZSKs. This allows for a smooth transition between the various steps in pre-published key rollover. There can be signatures of key N in the zone, while key N is retired and key N+1 is active. This allows for a fast transition when double signature key rollover is used. When key N+1 is introduced (being published and active, just like key N), RRsets signed by these keys require two signatures. Signature from key N may be reused, while signature of key N+1 needs to be added. Best regards, Matthijs On 09/29/2010 02:48 PM, Jakob Schlyter wrote: > please review http://trac.opendnssec.org/wiki/Signer/Signatures. > > j > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMo0K6AAoJEA8yVCPsQCW5rY4IANBwVLsYalZEQ0nOXg6ucyGQ GjdAB6P79HAQYWceejx5/oy9Ls8BVUfif9qU02FdvUt1wMv+FseC/xifbmc0z1Ad I/pDmMhT5QAscBw8D5+eEmzGzp5qyErcSh7aaULl7MFAn3k6XzRsyOtCDLMaTTWN zdEQLGVVHYcF3XoSu6gJ9WHQcj/YAqIMnSg7107hHa0rQwVcQOiCHT4fD96hlYbc AVJv3M3K6B8gIOF2LZ5LyOokXd4xdyiNdbxLJH8pJCzwbQJ8sWENOFVeYPrF8dNV 6OqjYKvkxd3Kx3Yv4F462Qkn/Np7f9yHLdWMdpy1DC2bxxTPBt4BtRTrvZklyFQ= =ROsw -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Wed Sep 29 14:44:04 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 29 Sep 2010 16:44:04 +0200 Subject: [Opendnssec-develop] what to do with garbage in Message-ID: <4CA350B4.2010608@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, What should we do with garbage in? For every class of garbage in, we have I believe three choices: 1. Reject the update, continue with current zone 2. Garbage in, garbage out 3. Garbage in, clean up the mess (make it rfc compliant) Classes of garbage in: a) multiple records of a singleton type (CNAME, DNAME) at the same owner name b) data next to CNAME c) occluded data (below or at a delegation, not glue, or below a DNAME) It might be that we have to behave differently depending on if we are primary (file, dynamic update) or secondary (axfr, ixfr). Classes a) and b): I think these should be rejected if we are primary. This is according to rfc 1035 and rfc2672 (-bis). In the unlikely situation that we get an {A,I}XFR that tries to insert this garbage, probably also reject it and continue with the old zone. Rejecting it means we don't need to worry on garbage out. Classes c): we should accept on zone transfer and dynamic update (rfc 5936), but reject on zone file (rfc 2672). Thus also follow these rules on the outbound side. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMo1C0AAoJEA8yVCPsQCW5emQH/AmGNopex1GNruUbO4FIVoq3 vmcSD2IiZPqsQ2OiaMq3mRWn/cVOkESba8q4WIVaoseGRQGKtAzffJ6cEP7f/2Tw bL53tq4B76xV3Xfmlt6+4bGT6b0JXEYcxsp51NdlyatqBx60Ry3hKYSnjX9kdNyo c+Ln7xq3+cDMPXdb6NjmDqAKa/7TcDa5iMQNKGMcZTesEvH0/F5TW5QkVcmGA67g mYYZlbECF50wLF3pv4jX9Sy2O0tt3l3ZxmuVdPXZd5lDIGg5UwTyGD9pK2h7kdi4 /of4caPTngP3iZD9aDEj+uvK1/JDNa6NM5TatZbfEmvlL0lZSAQAWY0zUVLAurI= =HHNq -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Thu Sep 30 07:47:28 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 30 Sep 2010 09:47:28 +0200 Subject: [Opendnssec-develop] review: Signature recycle etc. In-Reply-To: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> References: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> Message-ID: On 29 sep 2010, at 14.48, Jakob Schlyter wrote: > please review http://trac.opendnssec.org/wiki/Signer/Signatures. How will this affect the Enforcer? Does it e.g. take recycling into account when rolling ZSK? // Rickard From jakob at kirei.se Thu Sep 30 07:55:11 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 30 Sep 2010 09:55:11 +0200 Subject: [Opendnssec-develop] review: Signature recycle etc. In-Reply-To: <4CA342BA.2070102@nlnetlabs.nl> References: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> <4CA342BA.2070102@nlnetlabs.nl> Message-ID: <3CA22ABB-840D-4800-AD4C-A70A34FAB839@kirei.se> On 29 sep 2010, at 15.44, Matthijs Mekking wrote: > New rule: > If there are not enough valid signatures, additional signatures > must be created. The DNSKEY RRset MUST have equally number of > signatures as there are active KSKs. Every other RRset MUST have > equally number of signatures as there are active ZSKs. this sounds more like a rule for an enforcer, than a rule for a signer, no? j From rickard.bellgrim at iis.se Thu Sep 30 08:14:05 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 30 Sep 2010 10:14:05 +0200 Subject: [Opendnssec-develop] what to do with garbage in In-Reply-To: <4CA350B4.2010608@nlnetlabs.nl> References: <4CA350B4.2010608@nlnetlabs.nl> Message-ID: <39C32B9D-349E-4183-95B9-20F00B24C354@iis.se> On 29 sep 2010, at 16.44, Matthijs Mekking wrote: > Classes a) and b): > I think these should be rejected if we are primary. This is according to > rfc 1035 and rfc2672 (-bis). Yes, since it must be enforced that there is only one CNAME or DNAME. "If a DNAME RR is present at a node N, there may be other data at N (except a CNAME or another DNAME), but there MUST be no data at any descendant of N. This restriction applies only to records of the same class as the DNAME record." ... "It MUST be enforced when authoritative zone data is loaded." > In the unlikely situation that we get an {A,I}XFR that tries to insert > this garbage, probably also reject it and continue with the old zone. Yes, since the one sending the {A,I}XFR also have to obey the rule above. It thus unlikely that we will get such a zone transfer. If we do, then we can safely reject it since there is probably something wrong with the master. > Classes c): > we should accept on zone transfer and dynamic update (rfc 5936), but > reject on zone file (rfc 2672). Thus also follow these rules on the > outbound side. Zone file: Yes, the rule above also states that " there MUST be no data at any descendant of N". Dynamic update: Yes, RFC2136 7.14 "No semantic checking is required in the primary master server when adding new RRs." Zone transfers: Doesn't these sort under the same rules as zone files? // Rickard From sion at nominet.org.uk Thu Sep 30 09:00:41 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Thu, 30 Sep 2010 09:00:41 +0000 Subject: [Opendnssec-develop] review: Signature recycle etc. In-Reply-To: <3CA22ABB-840D-4800-AD4C-A70A34FAB839@kirei.se> References: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> <4CA342BA.2070102@nlnetlabs.nl> <3CA22ABB-840D-4800-AD4C-A70A34FAB839@kirei.se> Message-ID: > > New rule: > > If there are not enough valid signatures, additional signatures > > must be created. The DNSKEY RRset MUST have equally number of > > signatures as there are active KSKs. Every other RRset MUST have > > equally number of signatures as there are active ZSKs. > > this sounds more like a rule for an enforcer, than a rule for a signer, > no? The enforcer decides which keys should be used/published. It never sees the signed zones and knows nothing about signatures. From jakob at kirei.se Thu Sep 30 09:02:40 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 30 Sep 2010 11:02:40 +0200 Subject: [Opendnssec-develop] review: Signature recycle etc. In-Reply-To: References: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> <4CA342BA.2070102@nlnetlabs.nl> <3CA22ABB-840D-4800-AD4C-A70A34FAB839@kirei.se> Message-ID: <4AA5C50B-D61E-4ED9-8491-FB4BF949B280@kirei.se> On 30 sep 2010, at 11.00, Sion Lloyd wrote: >>> New rule: >>> If there are not enough valid signatures, additional signatures >>> must be created. The DNSKEY RRset MUST have equally number of >>> signatures as there are active KSKs. Every other RRset MUST have >>> equally number of signatures as there are active ZSKs. >> >> this sounds more like a rule for an enforcer, than a rule for a signer, >> no? > > The enforcer decides which keys should be used/published. It never sees the signed zones and knows nothing about signatures. sure, but it does choose what keys should sign the zone. I'd like that decision to made by the enforcer, not giving the signer much options. j From sion at nominet.org.uk Thu Sep 30 09:03:39 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Thu, 30 Sep 2010 09:03:39 +0000 Subject: [Opendnssec-develop] review: Signature recycle etc. In-Reply-To: References: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> Message-ID: > > > please review http://trac.opendnssec.org/wiki/Signer/Signatures. > > How will this affect the Enforcer? Does it e.g. take recycling into > account when rolling ZSK? For ZSKs we move from retire to dead after: zsksiglife + propdelay + retire safety and for KSKs it looks like: kskttl + kskpropdelay + retire safety If we keep keys in the retire state for an additional "expiration minus Refresh" then we are covered. (Maybe just expiration to be on the safe side?) Does this change need to be made to trunk? From matthijs at NLnetLabs.nl Thu Sep 30 13:09:58 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 30 Sep 2010 15:09:58 +0200 Subject: [Opendnssec-develop] review: Signature recycle etc. In-Reply-To: <4AA5C50B-D61E-4ED9-8491-FB4BF949B280@kirei.se> References: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> <4CA342BA.2070102@nlnetlabs.nl> <3CA22ABB-840D-4800-AD4C-A70A34FAB839@kirei.se> <4AA5C50B-D61E-4ED9-8491-FB4BF949B280@kirei.se> Message-ID: <4CA48C26.7040605@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What I am trying to enforce with this rule is: If the enforcer decides we should use n KSKs, the signer should make sure that n signatures exist in the zone that cover the DNSKEY RRset. If the enforcer decides we should use n ZSKs, the signer should make sure that for every non-DNSKEY RRset n signatures exist in the zone. Best regards, Matthijs On 09/30/2010 11:02 AM, Jakob Schlyter wrote: > On 30 sep 2010, at 11.00, Sion Lloyd wrote: > >>>> New rule: >>>> If there are not enough valid signatures, additional signatures >>>> must be created. The DNSKEY RRset MUST have equally number of >>>> signatures as there are active KSKs. Every other RRset MUST have >>>> equally number of signatures as there are active ZSKs. >>> >>> this sounds more like a rule for an enforcer, than a rule for a signer, >>> no? >> >> The enforcer decides which keys should be used/published. It never sees the signed zones and knows nothing about signatures. > > sure, but it does choose what keys should sign the zone. I'd like that decision to made by the enforcer, not giving the signer much options. > > j > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMpIwlAAoJEA8yVCPsQCW58oEH/1X7K279vcNMf0A5Sc4gYfcX hatlmiLePmgZLju6GcP5dEy///54Dcm0kbvaWEHu6Up+HpYU9JwDYibrSulfP/mh 17cWRJo3CqkqlLwU35EGAj3umyqihoFMI1aV+X5nTeIBO0Nw78//NGKw+U8KeLcG St6xYcfa/tlLAe+ZqE6sB0sarummu+YsW6Bt6BWKVmCAaJe9vEW1I85Y5ZM3wmfn L8j8y7moquzNL7iQkOcAnWNGFb5xQpYsHTSig4F7S1JF1UJjRYtvsPL4h3/0Fwav 0NZpnqnVgrzVxoceQdXqL6U3BzcmBDbev2S0cGsjAENhYn3QnXmmMfkDlHmOEQI= =TXWS -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Thu Sep 30 13:19:11 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 30 Sep 2010 15:19:11 +0200 Subject: [Opendnssec-develop] review: Signature recycle etc. In-Reply-To: References: <2AB41453-EFDC-429B-9EFE-7AF0AD8888A6@kirei.se> Message-ID: <4CA48E4F.5030404@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/30/2010 11:03 AM, Sion Lloyd wrote: >> >>> please review http://trac.opendnssec.org/wiki/Signer/Signatures. >> >> How will this affect the Enforcer? Does it e.g. take recycling into >> account when rolling ZSK? > > For ZSKs we move from retire to dead after: > zsksiglife + propdelay + retire safety retire safety should cover the time to resign the zone. From the key-timing draft, Iret = Dsgn + Dprp + TTLSIG. The time to resign covers refresh: Dsgn = max(expiration) - refresh But then the enforcer needs to check zone content for the expiration timings. That doesn't feel right. Perhaps you can derive it from the policy: Dsgn = (validity + offset + jitter) - refresh ? Best regards, Matthijs > > and for KSKs it looks like: > kskttl + kskpropdelay + retire safety > > > If we keep keys in the retire state for an additional "expiration minus > Refresh" then we are covered. (Maybe just expiration to be on the safe side?) > > Does this change need to be made to trunk? > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMpI5OAAoJEA8yVCPsQCW5Lg8IAKuZJMaUXOoefSjVie+gTWci /3swxRRLgCrLmgD9q2o3I6VAAEgREqPA3Ox5vAhVxnPEX2wU0GSrjXMS+0rG8hCa JR5c3yY0Lcr3Q74ZJIJZpbemEQW7KsMaNWVvSLS4tDcLnNZK7zeU0xfUgyJTYzGX m4u82mhzw82SmHRv0hlET2C5yNGF0M7Pp+jVmrqA0+YOqfKYHpA+37BTpusC+3gK +msPym6ElpaO5GPoWDCJQZLoz03UX0JemD2cpYpOgtbOaqoZ7X/XdWBb8J9Ot6gy /SmqCVFeqFbYcY6M4UVhJQCEK00tSys/BI/VNnwi/i17ZHqBf9btvmhTbjb4/kA= =9gvs -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Thu Sep 30 13:23:10 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 30 Sep 2010 15:23:10 +0200 Subject: [Opendnssec-develop] what to do with garbage in In-Reply-To: <39C32B9D-349E-4183-95B9-20F00B24C354@iis.se> References: <4CA350B4.2010608@nlnetlabs.nl> <39C32B9D-349E-4183-95B9-20F00B24C354@iis.se> Message-ID: <4CA48F3E.4070802@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 09/30/2010 10:14 AM, Rickard Bellgrim wrote: >> Classes c): Occluded data >> we should accept on zone transfer and dynamic update (rfc 5936), but >> reject on zone file (rfc 2672). Thus also follow these rules on the >> outbound side. > Zone transfers: Doesn't these sort under the same rules as zone files? No, see the occluded data section in rfc 5936. These rules differ from rfc 2672. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMpI8+AAoJEA8yVCPsQCW5FSIIAIEPiI6xsLut3MIBluB9MhpT OrLSDL+GSBNeiOE1865yf7ZJPquV87ItPC4wtnZtXUyQpLOVuswc1wsgwdyGW9Cc tBa5iwcAeUcUPrPcJnw5eVofzpZJrakuqSlm++/++i4lwy8ut6alECXUxk5ln/bn ds4aldIsPFbXxmE68U54T8Sn9s3F8UvfHBtvvuHe1GywbSu858hR4+QKceSnKkMj KFBrwGQH8Cg7B3KWbbd6u8P45FYkebCaVjqQYRsQEGh0I5/6nfEhJ4NIdKDKEe4U 87nUv/RfNsEBFdpOTgCW9UQEQ4lr2b6Fr0BSKGhBX53X/6wI6Dy+X/vjSu7Fhqg= =pfMw -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Thu Sep 30 13:31:04 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 30 Sep 2010 15:31:04 +0200 Subject: [Opendnssec-develop] what to do with garbage in In-Reply-To: <4CA48F3E.4070802@nlnetlabs.nl> References: <4CA350B4.2010608@nlnetlabs.nl> <39C32B9D-349E-4183-95B9-20F00B24C354@iis.se> <4CA48F3E.4070802@nlnetlabs.nl> Message-ID: On 30 sep 2010, at 15.23, Matthijs Mekking wrote: >> Zone transfers: Doesn't these sort under the same rules as zone files? > > No, see the occluded data section in rfc 5936. These rules differ from > rfc 2672. ACK From patrik.wallstrom at iis.se Thu Sep 30 17:08:31 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Thu, 30 Sep 2010 19:08:31 +0200 Subject: [Opendnssec-develop] too many open files Message-ID: <88B6E545-4A8F-4584-A797-65DA944C77CE@iis.se> I am testing performance on a better machine now, with fast disks and a quad core xeon processor. Performance is much better. I seem to get 5000 signed domains without too much hassle. First, create 5000 domains, adding them using no-xml (with mysql), and exporting the xml zonelist. First problem here, the first three lines is not xml, it's the mysql config. Remove this by hand. HUP the enforcer, and the enforcer creates signer configs reasonable fast. The signer acts a little strange, so after restarting the signer, it signs all domains without too much problem. Add another 5000 domains, that one is a little bit slower with the enforcer. Export and HUP, and it creates signer configs. Here somewhere (had some dinner), the signer loops with this: Sep 30 18:53:21 dnslab ods-signerd: command handler accept error: Too many open files So this problem do still exist. It might be that the enforcer grabs all file descriptors, I don't know. But maybe the signer should be more resilient about it. So, we still have to find the file descriptor leak. But it looks better and better, performance wise. -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From patrik.wallstrom at iis.se Thu Sep 30 19:02:37 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Thu, 30 Sep 2010 21:02:37 +0200 Subject: [Opendnssec-develop] too many open files In-Reply-To: <88B6E545-4A8F-4584-A797-65DA944C77CE@iis.se> References: <88B6E545-4A8F-4584-A797-65DA944C77CE@iis.se> Message-ID: On Sep 30, 2010, at 7:08 PM, Patrik Wallstr?m wrote: > > I am testing performance on a better machine now, with fast disks and a quad core xeon processor. Performance is much better. I seem to get 5000 signed domains without too much hassle. > > First, create 5000 domains, adding them using no-xml (with mysql), and exporting the xml zonelist. First problem here, the first three lines is not xml, it's the mysql config. Remove this by hand. HUP the enforcer, and the enforcer creates signer configs reasonable fast. The signer acts a little strange, so after restarting the signer, it signs all domains without too much problem. > > Add another 5000 domains, that one is a little bit slower with the enforcer. Export and HUP, and it creates signer configs. Here somewhere (had some dinner), the signer loops with this: > > Sep 30 18:53:21 dnslab ods-signerd: command handler accept error: Too many open files > > So this problem do still exist. It might be that the enforcer grabs all file descriptors, I don't know. But maybe the signer should be more resilient about it. So, we still have to find the file descriptor leak. > > But it looks better and better, performance wise. And after putting the kids to sleep, I just tried to start ods again. Lots of these, of course, but look at the end. Sep 30 21:00:50 dnslab ods-signerd: unable to open file 1908more.org.state for reading: No such file or directory Sep 30 21:00:50 dnslab ods-signerd: On Thu Sep 30 19:04:42 2010 I will sign zone 1909many.org Sep 30 21:00:50 dnslab ods-signerd: unable to open file 1909more.org.state for reading: No such file or directory Sep 30 21:00:50 dnslab ods-signerd: On Thu Sep 30 19:04:42 2010 I will sign zone 190many.org Sep 30 21:00:50 dnslab ods-signerd: unable to open file 190more.org.state for reading: No such file or directory Sep 30 21:00:50 dnslab ods-signerd: On Thu Sep 30 19:04:42 2010 I will sign zone 1910many.org Sep 30 21:00:50 dnslab ods-signerd: unable to open file 1910more.org.state for reading: No such file or directory Sep 30 21:00:50 dnslab ods-signerd: On Thu Sep 30 19:04:42 2010 I will sign zone 1911many.org Sep 30 21:00:50 dnslab ods-signerd: unable to open file 1911more.org.state for reading: No such file or directory Sep 30 21:00:50 dnslab ods-signerd: On Thu Sep 30 19:04:42 2010 I will sign zone 1912many.org Sep 30 21:00:50 dnslab ods-signerd: unable to open file 1912more.org.state for reading: No such file or directory Sep 30 21:00:50 dnslab ods-signerd: On Thu Sep 30 19:04:42 2010 I will sign zone 1913many.org Sep 30 21:00:50 dnslab ods-signerd: unable to open file 1913more.org.state for reading: No such file or directory Sep 30 21:00:50 dnslab ods-signerd: unable to open file 1914many.org.unsorted for reading: Too many open files Sep 30 21:00:50 dnslab ods-signerd: error reading zone 1914many.org from file 1914many.org.unsorted Sep 30 21:00:50 dnslab ods-signerd: unable to recover unsorted zone from file 1914many.org.unsorted: parse error Sep 30 21:00:50 dnslab ods-signerd: unable to open file 1914many.org.task for reading: Too many open files Sep 30 21:00:50 dnslab kernel: [23674.642930] ods-signerd[16728]: segfault at 0 ip 0000000000416f80 sp 00007fffbb5a05f0 error 6 in ods-signerd[400000+33000] -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/