18 Říj
2018
18 Říj
'18
9:55
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
Dne 17.10.18 v 23:25 Maximilian Engelhardt napsal(a):
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