Discussion:
[Opendnssec-user] OpenDNSSEC 2.0.1 - The SOA Serial Number
Mark Elkins
2016-10-06 15:58:28 UTC
Permalink
I'm having fun with Serial numbers in my test suite.

I'm running a Bump-in-the-wire.

The source of the zone is rewritten every 15 minute - which allows for
96 changes a day (4 x 24) - which fits in with a YYYYMMDDxx format for
the SOA Serial.

This also means I tickle the Signer every 15 minutes - and also every 15
minutes - even if there are no other changes.

At the moment - I'm trying "keep – keep the serial from the unsigned
zone (do not resign unless it has been incremented)"

This gives (syslog) error messages like:

Oct 6 17:45:01 signer1 ods-signerd: [namedb] zone za cannot keep SOA
SERIAL from input zone (2016100627): previous output SOA SERIAL is
2016100627
Oct 6 17:45:01 signer1 ods-signerd: [zone] unable to update zone za soa
serial: Conflict detected
Oct 6 17:45:01 signer1 ods-signerd: [zone] If this is the result of a
key rollover, please increment the serial in the unsigned zone za
Oct 6 17:45:01 signer1 ods-signerd: [worker[1]] unable to sign zone za:
failed to increment serial
Oct 6 17:45:01 signer1 ods-signerd: [worker[1]] CRITICAL: failed to
sign zone za: Conflict detected
Oct 6 17:45:01 signer1 ods-signerd: [worker[1]] backoff task [sign] for
zone za with 60 seconds

The Zone is signed though and appears to be OK.
I am though unhappy with the error messages. They suggest I've broken
something.

For now, in kasp.xml - I'm using "lab" with:
<Signatures>
<Resign>PT15M</Resign>
<Refresh>PT45M</Refresh>
(otherwise no changes)
[Note: this will change to "default" - ie Signed every two hours]

I also get the same sort of errors in two other (child) zones.

The ideal outcome would be a new distributed zone every 15 minutes -
where the serial number indicates which 15 minute clock tick it was
created (or rather signed) on. In the long run - the signer needs to
maintain RRSIGs (etc) every two hours but still potentially IXFR in
changes to the zone every 15 minutes.

Initially - I used "unixtime" which (because of the published format)
changed to counter - which then overflowed the "xx" of the desired format.

Suggestions?
--
Mark James ELKINS - Posix Systems - (South) Africa
***@posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
Yuri Schaeffer
2016-10-07 08:01:44 UTC
Permalink
Hi Mark,
Post by Mark Elkins
Oct 6 17:45:01 signer1 ods-signerd: [namedb] zone za cannot keep SOA
SERIAL from input zone (2016100627): previous output SOA SERIAL is
2016100627
Oct 6 17:45:01 signer1 ods-signerd: [zone] unable to update zone za soa
serial: Conflict detected
I think it is because your resign interval is 15 minutes and you are
getting XFR's every 15 minutes. There is a chance the signer will have 2
consecutive runs but did not see an XFR in between. The signer will
retry a bit later and no harm was done.

To get rid of this message I would advice to raise the resign interval a
bit. Maybe even to 2*[XFR interval]. Better yet would be to have the
signer keep its own SOA serial. That way it can still refresh signatures
even if you don't get XFRs for some period.

Regards,
Yuri
Mark Elkins
2016-10-10 16:54:46 UTC
Permalink
I'm afraid after changing the resign interval - everything broke.
I've restarted everything with "datecounter" and [AI]XFR an unsigned
zone that is only regenerated every 30 minutes. Also use a 30 minutes
resign in KASP. Everything currently working.

I want "datecounter" because "unixtime" ends (hopefully) within my
lifetime - January 19, 2038 03:14:08 GMT - and its getting uncomfortably
close.
Post by Yuri Schaeffer
Hi Mark,
Post by Mark Elkins
Oct 6 17:45:01 signer1 ods-signerd: [namedb] zone za cannot keep SOA
SERIAL from input zone (2016100627): previous output SOA SERIAL is
2016100627
Oct 6 17:45:01 signer1 ods-signerd: [zone] unable to update zone za soa
serial: Conflict detected
I think it is because your resign interval is 15 minutes and you are
getting XFR's every 15 minutes. There is a chance the signer will have 2
consecutive runs but did not see an XFR in between. The signer will
retry a bit later and no harm was done.
To get rid of this message I would advice to raise the resign interval a
bit. Maybe even to 2*[XFR interval]. Better yet would be to have the
signer keep its own SOA serial. That way it can still refresh signatures
even if you don't get XFRs for some period.
Regards,
Yuri
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
--
Mark James ELKINS - Posix Systems - (South) Africa
***@posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
Havard Eidnes
2016-10-10 17:26:45 UTC
Permalink
Post by Mark Elkins
I want "datecounter" because "unixtime" ends (hopefully) within my
lifetime - January 19, 2038 03:14:08 GMT - and its getting uncomfortably
close.
Oh, "the wrap of 32-bit unixtime" should not be a worry: the SOA
version number uses serial number arithmetic for comparison -- the
number space is circular and not linear, ref. RFC 1982.

Datecounter wins on readability, though, hands down, as long as
you can use it.

Regards,

- Håvard
Mark Elkins
2016-10-10 19:16:13 UTC
Permalink
I honestly don't know what will happen. When I run the "EndOfTime" perl
script:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
print ctime($clock);
}

...it works just fine on my 64-bit laptop running Gentoo

I'm told the above script rolls to 1900 on 32 bit machines.

Which begs the question, how much (if anything) will OpenDNSSEC break on
around Tue Jan 19 03:14:07 2038 GMT ?
Post by Mark Elkins
I'm afraid after changing the resign interval - everything broke.
I've restarted everything with "datecounter" and [AI]XFR an unsigned
zone that is only regenerated every 30 minutes. Also use a 30 minutes
resign in KASP. Everything currently working.
I want "datecounter" because "unixtime" ends (hopefully) within my
lifetime - January 19, 2038 03:14:08 GMT - and its getting uncomfortably
close.
Post by Yuri Schaeffer
Hi Mark,
Post by Mark Elkins
Oct 6 17:45:01 signer1 ods-signerd: [namedb] zone za cannot keep SOA
SERIAL from input zone (2016100627): previous output SOA SERIAL is
2016100627
Oct 6 17:45:01 signer1 ods-signerd: [zone] unable to update zone za soa
serial: Conflict detected
I think it is because your resign interval is 15 minutes and you are
getting XFR's every 15 minutes. There is a chance the signer will have 2
consecutive runs but did not see an XFR in between. The signer will
retry a bit later and no harm was done.
To get rid of this message I would advice to raise the resign interval a
bit. Maybe even to 2*[XFR interval]. Better yet would be to have the
signer keep its own SOA serial. That way it can still refresh signatures
even if you don't get XFRs for some period.
Regards,
Yuri
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
--
Mark James ELKINS - Posix Systems - (South) Africa
***@posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
Loading...