On 10/04/2016 11:06 AM, Fred.Zwarts wrote:
> Hi Yuri,
>
> Is there any progress on this matter? I have a strong impression that
> the problem is not (only) caused by migration problems. It seems to
> happen always if a standby ZSK is configured.
Yuri is out of the office for today, but we have so
Hi Yuri,
Is there any progress on this matter? I have a strong impression that the
problem is not (only) caused by migration problems. It seems to happen
always if a standby ZSK is configured. When after some days of changing keys
states the system enters a more stable situation, then I see th
Hi Yuri,
I have been away a few days, so sorry for the late response.
I am not sure that your diagnosis is the whole story.
We have had two cases of this problem. In the first case your diagnosis may
apply, because it happened rather soon after the migration. However, at the
moment of the mig
Hi Fred,
Thanks for sharing the data, I now understand what has happened. The
root cause must have been an error in the migration script. I'll write
it down in detail so you can verify your part of the events.
1) Before migration there where two ZSKs in a rollover. Lets call those
ZSK1(old) and Z
> 1) A bug in the enforcer where it outputs the wrong signconf. Please
> check the entry for the 63b58e329df2a6bfa09671425146b72d key in the
> signconf. it should have a element.
Oops. That should be a element for key
63b58e329df2a6bfa09671425146b72d.
The (meaning use it for signing as ZSK) sh
Hi Fred,
We are currently in the process of finding out why the retired ZSK after
the migration gets unpublished to fast. It seems an issue in the
migration script. Working on it.
This issue seems unrelated. Judging from the output the old ZSK DNSKEY
is still being published in the DNSKEY set. At
Sorry, I forgot the database. See attachment.
kasp.db
Description: Binary data
___
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> I forced another ZSK roll-over on our test system and the same problem
> popped up.
> There are now two retiring ZSKs and one ready ZSK, but no active ZSK.
> In the zone file, many records are still signed with the retiring ZSK.
> However, this ZSK itself is no longer in the signed zone file.
To
> I am a bit confused about your reply. Does it refer to my first
> question, in an earlier mail, about the refusal of the signer to sign
> the zone because of the serial?
Oh yes sorry, I replied to the wrong thread.
>
>
> Could it be that this problem was also caused by a migration problem, or
I forced another ZSK roll-over on our test system and the same problem
popped up.
There are now two retiring ZSKs and one ready ZSK, but no active ZSK.
In the zone file, many records are still signed with the retiring ZSK.
However, this ZSK itself is no longer in the signed zone file.
Could it
Hi Yuri,
I have been a few days away, so I read your message now.
I am a bit confused about your reply. Does it refer to my first question, in
an earlier mail, about the refusal of the signer to sign the zone because of
the serial?
This was indeed solved with "ods-enforcer policy import".
How
Hi Fred,
My colleague Hoda found the error. The SOA serial strategy is numbered
differently between 1.4 and 2.0. This is actually a problem with the
migration script not taking this in to account.
What should solve your issue is running
ods-enforcer policy import
Your kasp.xml will be r
Hi Fred,
Can you send me the output of:
ods-enforcer key list -d
If possible, can you send me off list your kasp.db (assuming sqlite),
your kasp.xml. and the produced signconf for that zone? Then I can see
if it is perhaps I migration related issue.
Regards,
Yuri
On 16-09-16 22:38, Fred
13 matches
Mail list logo
