<div dir="ltr"><div class="gmail_quote"><br><div dir="ltr">Hi,<div><br></div><div>Sorry, I do not remember anything strange that happened or at least I did not pay attention. Anyway I can send you off-list excerpt of the log that contains everything related to that policy and the zones I configured to use that policy. I hope that can also help.</div>
<div>A detail that can be important though is that "lab" was not the first policy I started with. At first I had two other policies and the conf.xml file had <ManualKeyGeneration/> option enabled. Later I added the "lab" policy and removed the ManualKeyGeneration option, because I did not want to pre-generate too many keys. The first time I run the enforcer with the "lab" policy it did not generate keys because of ManualKeyGeneration as can be seen in the log, then I removed that option and since then I did not encounter any problems until I tried to add more zones using that policy.</div>
<div><br></div><div>ena</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 3:35 PM, Sara Dickinson <span dir="ltr"><<a href="mailto:sara@sinodun.com" target="_blank">sara@sinodun.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Emil,<br>
<br>
Sorry for the late response. This sounds similar to an issue we saw a while back where there were several keys in the database in an unexpected state, which caused a problem with the key allocation algorithm:<br>
<a href="https://issues.opendnssec.org/browse/OPENDNSSEC-546" target="_blank">https://issues.opendnssec.org/browse/OPENDNSSEC-546</a><br>
I’ll send you and email off-list to confirm this and then we can clean up the problem keys.<br>
<br>
We didn’t ever manage to work out how the keys got in this state - do you remember anything strange happening at any stage with the zones on the lab policy?<br>
<br>
We are adding tools in the next patch release that should make this problem easier to diagnose and cleanup and we are also looking at how we can make the enforcer more robust to this kind of problem in future.<br>
<br>
Best regards<br>
<span><font color="#888888"><br>
Sara.<br>
</font></span><div><div><br>
On 25 Feb 2014, at 12:59, Emil Natan <<a href="mailto:shlyoko@gmail.com" target="_blank">shlyoko@gmail.com</a>> wrote:<br>
<br>
> Ok, I think I'm getting closer. I already had a zone using the "lab" policy which was working well. Tried to add <a href="http://test.org" target="_blank">test.org</a> to "lab" as well and got into the issues I already mentioned. Then I changed the policy for <a href="http://test.org" target="_blank">test.org</a> to something else and it worked, signconf file was created, keys generated and zone signed. Then tried to add two new zones, one using "lab" and another one using "testpolicy" policy and again I had a problem for the zone using "lab" and the one using "testpolicy" worked well. A test kasp.xml file including both policies is attached. Just to make it clear I already have a zone using the "lab" policy which works well, but the second zone I add fails. Any ideas?<br>
> Thank you in advance.<br>
><br>
> ena<br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></div><br></div>