[Opendnssec-user] Serial problem after rollover in 2.0.1

[Fred.Zwarts]

Recently we upgraded to ods 2.01. from 1.4.10. During key roll-overs we
never needed to update our input zones as long as we used version 1.
This night ods was still in the process of retiring the backup keys, used in
version 1.4.10, when it started a ZSK key roll-over. After that the signer
refused to sign zones.
The log file shows messages from the signer each hour, see the attachment.
The fix was easy, we incremented the serial of the input zone.

The log message "If this is the result of a key rollover ..." suggests (at
least to me) that it is normal that a manual intervention is needed during a
roll-over, but we are not used to it.
Is this a bug, or is it the intended behavior?
Are there new options to be included in the configuration?

[Yuri Schaeffer]

Hi Fred,

Post by Fred.Zwarts
The log message "If this is the result of a key rollover ..." suggests
(at least to me) that it is normal that a manual intervention is needed
during a roll-over, but we are not used to it.
Is this a bug, or is it the intended behavior?
Are there new options to be included in the configuration?

I'm guessing you use 'keep' strategy[0] for the SOA. Then you are
responsible to increment the serial yourself and the signer is unable to
push out updates when that hasn't happened.

The reason for the message is that the enforcer can have the signer
notified that a resign needs to happen. (because a key rollover for
example). But with this serial strategy the signer can't without a SOA
bump.

So make sure your serial in the input zone is greater than 2016091511.
But better would be to use 'datecounter' to let the signer manage the
serial.

Regards,
Yuri

[0]
https://wiki.opendnssec.org/display/DOCS20/kasp.xml#kasp.xml-ZoneInformation

[Fred.Zwarts]

Post by Yuri Schaeffer
Hi Fred,

Post by Fred.Zwarts
The log message "If this is the result of a key rollover ..." suggests
(at least to me) that it is normal that a manual intervention is needed
during a roll-over, but we are not used to it.
Is this a bug, or is it the intended behavior?
Are there new options to be included in the configuration?

I'm guessing you use 'keep' strategy[0] for the SOA. Then you are
responsible to increment the serial yourself and the signer is unable to
push out updates when that hasn't happened.
The reason for the message is that the enforcer can have the signer
notified that a resign needs to happen. (because a key rollover for
example). But with this serial strategy the signer can't without a SOA
bump.
So make sure your serial in the input zone is greater than 2016091511.
But better would be to use 'datecounter' to let the signer manage the
serial.
Regards,
Yuri

We never had this problem with 1.4. From our /etc/opendnssec/kasp.xml:

<Zone>
<PropagationDelay>PT15H</PropagationDelay>
<SOA>
<TTL>PT86400S</TTL>
<Minimum>PT10800S</Minimum>
<Serial>datecounter</Serial>
</SOA>
</Zone>

The kasp.xml has not been touched since December 2015.
So, there must be something else. Could it be that the migration of the
database changed it from datacounter to keep?
Should I update the configuration after the migration?

[Yuri Schaeffer]

Post by Fred.Zwarts
<Zone>
<PropagationDelay>PT15H</PropagationDelay>
<SOA>
<TTL>PT86400S</TTL>
<Minimum>PT10800S</Minimum>
<Serial>datecounter</Serial>
</SOA>
</Zone>
The kasp.xml has not been touched since December 2015.
So, there must be something else. Could it be that the migration of the
database changed it from datacounter to keep?
Should I update the configuration after the migration?

The log message really seem to suggest 'keep' is used. Can you check the
SOA section of /var/opendnssec/signconf/kvi.nl (or similar path)?

If it says 'keep' in the signconf you should make sure the enforcerd
reads the kasp.xml from the correct location. If it does -something odd
has happend during conversion- you can issue a 'ods-enforcer policy
import' to have the enforcer reread the kasp.xml.

Regards,
Yuri

[Fred.Zwarts]

Post by Yuri Schaeffer

Post by Fred.Zwarts
<Zone>
<PropagationDelay>PT15H</PropagationDelay>
<SOA>
<TTL>PT86400S</TTL>
<Minimum>PT10800S</Minimum>
<Serial>datecounter</Serial>
</SOA>
</Zone>
The kasp.xml has not been touched since December 2015.
So, there must be something else. Could it be that the migration of the
database changed it from datacounter to keep?
Should I update the configuration after the migration?

The log message really seem to suggest 'keep' is used. Can you check the
SOA section of /var/opendnssec/signconf/kvi.nl (or similar path)?
If it says 'keep' in the signconf you should make sure the enforcerd
reads the kasp.xml from the correct location. If it does -something odd
has happend during conversion- you can issue a 'ods-enforcer policy
import' to have the enforcer reread the kasp.xml.
Regards,
Yuri

Thanks! The signconf indeed had a 'keep'. Using an enforcer policy import
changed it into 'datecounter'.

However, the system log shows some strange messages during the import
operation:

2016-09-16T12:48:12.257225+02:00 kvir07 ods-enforcerd: INFO: The XML in
/etc/opendnssec/kasp.xml is valid
2016-09-16T12:48:12.257576+02:00 kvir07 ods-enforcerd: WARNING: No policy
named 'default' in /etc/opendnssec/kasp.xml. This means you will need to
refer explicitly to the policy for each zone
2016-09-16T12:48:12.257742+02:00 kvir07 ods-enforcerd: WARNING: In policy
SIDN, Y used in duration field for Keys/KSK Lifetime (P1Y) in
/etc/opendnssec/kasp.xml - this will be interpreted as 365 days
2016-09-16T12:48:12.257897+02:00 kvir07 ods-enforcerd: WARNING: In policy
SIDN, M used in duration field for Keys/ZSK Lifetime (P3M) in
/etc/opendnssec/kasp.xml - this will be interpreted as 31 days
2016-09-16T12:48:12.258054+02:00 kvir07 ods-enforcerd: WARNING: In policy
RuG, Y used in duration field for Keys/KSK Lifetime (P1Y) in
/etc/opendnssec/kasp.xml - this will be interpreted as 365 days
2016-09-16T12:48:12.258315+02:00 kvir07 ods-enforcerd: WARNING: In policy
RuG, M used in duration field for Keys/ZSK Lifetime (P3M) in
/etc/opendnssec/kasp.xml - this will be interpreted as 31 days
2016-09-16T12:48:12.258789+02:00 kvir07 ods-enforcerd: [policy_import]
policy SIDN updated
2016-09-16T12:48:12.259838+02:00 kvir07 ods-enforcerd: [policy_import]
policy RuG updated
2016-09-16T12:48:12.260044+02:00 kvir07 ods-enforcerd: [signconf_cmd]
performing signconf for all zones
2016-09-16T12:48:12.261957+02:00 kvir07 ods-enforcerd: [signconf_cmd]
signconf done, notifying signer
2016-09-16T12:48:12.265637+02:00 kvir07 ods-enforcerd: [enforce_task] No
changes to any signconf file required
2016-09-16T12:48:12.267431+02:00 kvir07 ods-signerd: [nsec3] invalid salt 0
2016-09-16T12:48:12.267635+02:00 kvir07 ods-signerd: [nsec3] unable to
create: create salt failed
2016-09-16T12:48:12.267804+02:00 kvir07 ods-signerd: [signconf] unable to
read signconf /var/opendnssec/signconf/KVI.nl.xml: nsec3params_create()
failed
2016-09-16T12:48:12.267963+02:00 kvir07 ods-signerd: [signconf] unable to
update signconf: failed to read file /var/opendnssec/signconf/KVI.nl.xml
(Memory allocation error)
2016-09-16T12:48:12.268116+02:00 kvir07 ods-signerd: [zone] unable to load
signconf for zone KVI.nl: signconf /var/opendnssec/signconf/KVI.nl.xml
Memory allocation error
2016-09-16T12:48:12.268271+02:00 kvir07 ods-signerd: [tools] unable to load
signconf for zone KVI.nl: Memory allocation error
2016-09-16T12:48:12.268427+02:00 kvir07 ods-signerd: [worker[1]] continue
task [sign] for zone KVI.nl
2016-09-16T12:48:12.466672+02:00 kvir07 ods-enforcerd: [signconf_cmd]
performing signconf for all zones
2016-09-16T12:48:12.468766+02:00 kvir07 ods-enforcerd: [signconf_cmd]
signconf done, notifying signer
2016-09-16T12:48:12.472990+02:00 kvir07 ods-enforcerd: [signconf_cmd]
performing signconf for all zones
2016-09-16T12:48:12.474993+02:00 kvir07 ods-enforcerd: [signconf_cmd]
signconf done, notifying signer
2016-09-16T12:48:12.485463+02:00 kvir07 ods-signerd: [signconf] zone KVI.nl
signconf: RESIGN[PT2H] REFRESH[P3D] VALIDITY[P14D] DENIAL[P14D] KEYSET[PT0S]
JITTER[P1D] OFFSET[PT1H] NSEC[50] DNSKEYTTL[PT1H] SOATTL[P1D] MINIMUM[PT3H]
SERIAL[datecounter]
2016-09-16T12:48:12.839254+02:00 kvir07 ods-signerd: [STATS] KVI.nl
2016091604 RR[count=1 time=0(sec)] NSEC3[count=676 time=0(sec)]
RRSIG[new=682 reused=2963 time=0(sec) avg=0(sig/sec)] TOTAL[time=0(sec)]
2016-09-16T12:48:12.880746+02:00 kvir07 ods-signerd: [worker[1]] continue
task [sign] for zone KVI.nl


I use explicit policies, so the default policy is not needed. I am worried a
bit about the signer messages about salt and about Memory allocation error.
It seems that it recovered from that, but I am not sure. I will monitor it
the next few hours to see if it keeps running. At least the "ods-signer
sign --all" can now be used several times without the need to update the
input zone.

[Fred.Zwarts]

Post by Yuri Schaeffer
Hi Fred,

Post by Fred.Zwarts
The log message "If this is the result of a key rollover ..." suggests
(at least to me) that it is normal that a manual intervention is needed
during a roll-over, but we are not used to it.
Is this a bug, or is it the intended behavior?
Are there new options to be included in the configuration?

I'm guessing you use 'keep' strategy[0] for the SOA. Then you are
responsible to increment the serial yourself and the signer is unable to
push out updates when that hasn't happened.
The reason for the message is that the enforcer can have the signer
notified that a resign needs to happen. (because a key rollover for
example). But with this serial strategy the signer can't without a SOA
bump.
So make sure your serial in the input zone is greater than 2016091511.
But better would be to use 'datecounter' to let the signer manage the
serial.
Regards,
Yuri
[0]
https://wiki.opendnssec.org/display/DOCS20/kasp.xml#kasp.xml-ZoneInformation

When I change the serial in the input zone, I can do a "ods-signer
sign -all" once without problem and it will resign the zone.
When I try it a second time, it fails again with the same messages. Then I
have to update the serial again in the input zone.