[Opendnssec-user] resign interval PT0S

[Emil Natan]

Ok, I found what caused the frequent/unscheduled zone resign - the
information about next zone resign in the backup file. The kasp.xml and
signconf/<zone>.xml both have resign interval of 2 days
(<Resign>PT172800S</Resign>), but the backup file still held the old value
of 12 hours -
";;Signconf: lastmod 1425817523 maxzonettl 0 resign PT43200S refresh PT0S
...".
When I force zone resign the content of the backup file is updated, but the
resign value remained to the old value. I deleted the backup file multiple
times during the last few days, but it was always recreated like this. Now
I stopped both services to be on the safe side, removed the backup file,
started the services, forced resign and it now looks ok. What I think might
have happened is that when there is no unsigned file, the signer uses the
backup file to create a signed zone and it read the resign value from there
and then scheduled the next resign for 12 hours later.
After getting this one in order I tried setting the Resign value to 3 days
and this time it was updated accordingly in the backup file.

Final words - it's clear that the OpenDNSSEC designers have set high
priority on systems ability to satisfy the resigning cycle, but using all
means, the backup files in this case creates complexity and confusion in a
system which shall be simple and reliable. And disabling the automated
resign process can be a nice feature :-).

Thank you all.

Emil

On Wed, Mar 18, 2015 at 3:37 PM, Yuri Schaeffer <yuri at nlnetlabs.nl> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > The only reasons that this occurs and that I can think of are: -
> > The unsigned zone is still in memory - The zone uses a DNS Input
> > Adapter
> >
> > From your mails it sounds unlikely that one of these is the cause
> > though...
>
> Does the signer close the backup file? Maybe it still holds the file
> descriptor.
>
> //Yuri
>
> >> The second issue is with the signer not respecting the Resign
> >> value. I have a machine where the resign interval was initially
> >> set to 12 hours, then changed to 0 seconds and then to two days,
> >> in each case updating the kasp database and even restarting both
> >> signer and enforcer services, it keeps resigning the zone twice a
> >> day. Once a day the signing process is triggered by a cronjob,
> >> exactly 12 hours later it happens by itself. And the signconf
> >> file created by the enforcer clearly states
> >> "<Resign>PT172800S</Resign>"
> >
> > This can be considered a bug:
> >
> >
> https://github.com/opendnssec/opendnssec/blob/1.4/master/signer/src/daemon/worker.c#L467
> >
> >
> >
> > duration2time is 0 and the signer will fall back to use the default
> > of 1H.
> >
> > To be honest, I am not sure if <Resign>PT0S</Resign> is a good
> > idea. Basically what it means is changing behaviour because we
> > should not put the zone back on the scheduler (if that makes
> > sense).
> >
> > Best regards, Matthijs
> >
> >
> >
> >
> >>
> >> Any idea what I'm missing?
> >>
> >> @Antti We have a resigning cycle of 24 hours, so I decided
> >> setting the resign value to 2 days is a good option because with
> >> the cronjob running every day that limit should never be reached.
> >> Unfortunately I'm still missing something.
> >>
> >> Thanks.
> >>
> >> Emil
> >>
> >>
> >>
> >>
> >> On Wed, Mar 18, 2015 at 12:34 PM, Yuri Schaeffer
> >> <yuri at nlnetlabs.nl <mailto:yuri at nlnetlabs.nl>> wrote:
> >>
> > Hi Antti,
> >
> >> I don't see this as a strange approach. In many environments the
> >> zone data is periodically transferred from a provisioning system
> >> to OpenDNSSEC signer and then the signing process is triggered
> >> by issuing "ods-signer sign <zone>" after receiving the unsigned
> >> zone.
> >
> >> We are also using this approach and we have configured the
> >> Resign interval to P10Y.
> >
> > Rainbows and unicorns.
> >
> > Until you zone content one day didn't change for "validity-jitter"
> > time and signatures start to expire because the signer is not
> > allowed to do regular maintenance.
> >
> > I'm saying, you can do it. But make sure to monitor your unicorns.
> >
> > //Yuri
> >> _______________________________________________ Opendnssec-user
> >> mailing list Opendnssec-user at lists.opendnssec.org
> >> <mailto:Opendnssec-user at lists.opendnssec.org>
> >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> >>
> >>
> >>
> >>
> >> _______________________________________________ Opendnssec-user
> >> mailing list Opendnssec-user at lists.opendnssec.org
> >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> >>
> > _______________________________________________ Opendnssec-user
> > mailing list Opendnssec-user at lists.opendnssec.org
> > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iEYEARECAAYFAlUJf6wACgkQI3PTR4mhavjrHwCbBR7Qun8+MJVeryGIMfTMGFDV
> cQgAoMOzKcpayRSLA4H7xNslhMCd2i8V
> =E3ce
> -----END PGP SIGNATURE-----
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20150318/43b72d6e/attachment.htm>