Hi Maxi,

thanks much for detailed report!

First, the 1970 time information is indeed a cosmetic bug. It's just a dumb conversion of zero timestamp, in our semantics infinite future. Please interpret it as "not scheduled" until we fix it.

However, it's not clear to me how this can ever happen. Next re-sign is always planned based on ksk-lifetime, zsk-lifetime and/or rrsig-lifetime. Could you please share also (at least) the policy section of your configuration to check? I will also take a look on this anyway.

The snippet of log you sent us looks also a little weird, but maybe you know the explanation here, why did Knot receive DDNS three times in one second, with just the middle one actually changing the zone. If you think there is also a bug, please share more information to this, otherwise ok.

Please let us know if the situation with not responding to DDNS appears again.

Danke!

Libor

Hi,

I'm using a zone with DNSSEC signing enabled that is updated using DDNS.

The update procedure is very simple and looks like this:
==> test_ddns.sh <==
#! /bin/sh

ZONE="example.org."

cat << EOF | nsupdate
server localhost
zone ${ZONE}

update delete ${ZONE} A
update add ${ZONE} 60 IN A 127.0.0.1

send
quit
EOF

And the corresponding output in the knot log is this:

Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, zone is up-to-date
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 1970-01-01T01:00:00
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, finished, no changes to the zone were made
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, successfully signed
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 2018-10-24T22:58:46
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, update finished, serial 1539809849 -> 1539809926, 0.02 seconds
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, zone is up-to-date
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 1970-01-01T01:00:00
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, finished, no changes to the zone were made
Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] zone file updated, serial 1539809849 -> 1539809926

I'm wondering if the "next signing at 1970-01-01T01:00:00" output is correct 
as this seems suspicious to me.

Running "knotc zone-status example.org" gives the following output:
[example.org.] role: master | serial: 1539809926 | transaction: none | freeze: no | refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal flush: not scheduled | notify: not scheduled | DNSSEC re-sign: not scheduled | NSEC3 resalt: +29D23h53m28s | parent DS query: not scheduled

Is this expected behavior or a bug in knot?

I can give more information or create a proper bugreport if needed.

I also recently had the problem that knot didn't respond to ddns updates until 
it was restarted. I don't know if this is related or a different problem, 
however I currently don't have more information about this.

Thanks,
Maxi