[Opendnssec-user] *****SPAM***** Whats wrong in my ods 2.0o.1 setup.

[Fred.Zwarts]

Spam detection software, running on the system "dicht.nlnetlabs.nl",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
The administrator of that system for details.

Content preview: Last week I migrated the ods 1.4.10 system on our test system
to ods 2.0.1. As mentioned my previous mails, there were some problems to
understand what was happening, but at the end I thought that al was running
well. [...]

Content analysis details: (5.8 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.2 STOX_REPLY_TYPE No description available.
1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
1.9 STOX_REPLY_TYPE_WITHOUT_QUOTES No description available.
2.5 TO_NO_BRKTS_MSFT To: lacks brackets and supposed Microsoft tool

[Yuri Schaeffer]

Hi Fred,

It is now Mon Aug 15 09:06:33 2016 (1471244793 seconds since epoch)
Next task scheduled Sat Aug 13 14:22:00 2016 (1471090920 seconds since
epoch)
The enforcer has scheduled a task in the past. How is that possible?

I'm not 100% sure. But I do a hunch. Somehow the scheduler missed the
event work needs to be done. The worker threads wait indefinitely to get
a signal but the signal was never actually delivered by the OS.

I'll set up a test system to see if I can recreate the issue and test my
proposed fix. In the mean time what should get you out of this situation
is a user interaction which causes the enforcer to reschedule things. An
'ods-enforcer enforce' will do that, without any adverse effects. Please
let me know if you see this issue regularly.

2016-08-10T11:56:24.269750+02:00 kvivs20 ods-signerd: [namedb] zone
KVI.nl cannot keep SOA SERIAL from input zone (2014042300): previous
output SOA SERIAL is 201608100 3
These messages started early in the morning, continued for about 4 hours
(about 10 times for each domain with increasing intervals between 1
minute and one hour) and then stopped, without any change in the
configuration. Also the input zones were not changed. Is this something
to worry about?
Are we assumed to increment the serial of the unsigned zone during a
rollover?

No. the signer will do the SOA serial management for you. *unless* you
specify so in the kasp. In that case you should do it yourself.

<Serial>keep</Serial>

A better value would probably be 'datecounter'.

counter
use an increasing counter (but use the serial from the
unsigned zone if possible)
datecounter
use increasing counter in YYYYMMDDxx format (xx is
incremented within each day)
unixtime
the serial number is set to the "Unix time" (seconds
since 00:00 on 1 January 1970 (UTC)) at which the signer is run.
keep
keep the serial from the unsigned zone (do not resign unless
it has been incremented)

At the moment everything looks normal. The unsigned zone is still
unchanged and the signed zone is dated Aug 15 08:33 and shows a serial
of 2016081504.

I'm unsure as why it got better if the policy did not change. By the way
this part (signer code) is almost unchanged from 1.4.10, so I do not
expect any new bugs here.

//Yuri