17 Říj
2018
17 Říj
'18
23:25
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
18 Říj
18 Říj
9:49
New subject: DDNS with DNSSEC, is this expected behavior or a bug
Hi,
What is your version of Knot?
Could you please:
- Purge the timers `knotc -f zone-purge example.org. +timers`
- Re-sign the zone `knotc zone-sign example.org`
- Repeat your test
?
Thanks,
Daniel
On 2018-10-17 23:25, Maximilian Engelhardt wrote:
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
12:36
Hi Daniel,
The test was done using version 2.7.2. Tonight it got updated to 2.7.3, but I
don't see any difference with the new version
$ knotc -f zone-purge example.org. +timers
OK
$ knotc zone-sign example.org
OK
log output:
Okt 18 12:02:15 backroad knotd[15628]: info: [example.org.] control, received command
'zone-sign'
Okt 18 12:02:15 backroad knotd[15628]: info: [example.org.] DNSSEC, dropping previous
signatures, re-signing zone
Okt 18 12:02:15 backroad knotd[15628]: info: [example.org.] DNSSEC, key, tag 63845,
algorithm RSASHA256, KSK, public, ready, active
Okt 18 12:02:15 backroad knotd[15628]: info: [example.org.] DNSSEC, key, tag 61195,
algorithm RSASHA256, public, active
Okt 18 12:02:15 backroad knotd[15628]: info: [example.org.] DNSSEC, signing started
Okt 18 12:02:15 backroad knotd[15628]: info: [example.org.] DNSSEC, successfully signed
Okt 18 12:02:15 backroad knotd[15628]: info: [example.org.] DNSSEC, next signing at
2018-10-25T12:02:15
Okt 18 12:02:15 backroad knotd[15628]: info: [example.org.] zone file updated, serial
1539856881 -> 1539856935
$ ./test_ddns.sh
gives:
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DDNS, processing 1 updates
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DNSSEC, zone is up-to-date
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DNSSEC, next signing at
1970-01-01T01:00:00
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DDNS, finished, no changes to
the zone were made
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DDNS, processing 1 updates
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DNSSEC, successfully signed
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DNSSEC, next signing at
2018-10-25T12:03:19
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DDNS, update finished, serial
1539856935 -> 1539856999, 0.02 seconds
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] zone file updated, serial
1539856935 -> 1539856999
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DDNS, processing 1 updates
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DNSSEC, zone is up-to-date
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DNSSEC, next signing at
1970-01-01T01:00:00
Okt 18 12:03:19 backroad knotd[15628]: info: [example.org.] DDNS, finished, no changes to
the zone were made
$ knotc zone-status example.org
[example.org.] role: master | serial: 1539856999 | 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: +29D10h47m51s | parent DS query: not scheduled
Thanks,
Maxi
On Donnerstag, 18. Oktober 2018 09:49:22 CEST daniel.salzman(a)nic.cz wrote:
Hi,
What is your version of Knot?
Could you please:
- Purge the timers `knotc -f zone-purge example.org. +timers`
- Re-sign the zone `knotc zone-sign example.org`
- Repeat your test
?
Thanks,
Daniel
On 2018-10-17 23:25, Maximilian Engelhardt wrote:
> 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
9:55
New subject: DDNS with DNSSEC, is this expected behavior or a bug
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
12:36
Hi Libor,
I don't know why the message appears three times. I was also wondering about
this. I had a quick look at a tcpdump and nsupdate does indeed send three requests:
12:27:57.973741 IP6 (flowlabel 0x5e7e8, hlim 64, next-header UDP (17) payload length: 37)
::1.5835 > ::1.53: [bad udp cksum 0x0038 -> 0x19f7!] 53303 update SOA? example.org.
(29)
12:27:57.976086 IP6 (flowlabel 0x0f4a8, hlim 64, next-header UDP (17) payload length: 37)
::1.53 > ::1.5835: [bad udp cksum 0x0038 -> 0x99f6!] 53303 update- q: SOA?
example.org. 0/0/0 (29)
12:27:57.976554 IP6 (flowlabel 0x5e7e8, hlim 64, next-header UDP (17) payload length: 65)
::1.5835 > ::1.53: [bad udp cksum 0x0054 -> 0x0d44!] 32688 update [2n] SOA?
example.org. ns: example.org. ANY [0s] A 192.12.0.1, example.org. [1m] A 127.0.0.1 (57)
12:27:57.989710 IP6 (flowlabel 0x0f4a8, hlim 64, next-header UDP (17) payload length: 37)
::1.53 > ::1.5835: [bad udp cksum 0x0038 -> 0xea7d!] 32688 update- q: SOA?
example.org. 0/0/0 (29)
12:27:57.989970 IP6 (flowlabel 0x5e7e8, hlim 64, next-header UDP (17) payload length: 37)
::1.5835 > ::1.53: [bad udp cksum 0x0038 -> 0xa04c!] 18914 update SOA? example.org.
(29)
12:27:57.992947 IP6 (flowlabel 0x0f4a8, hlim 64, next-header UDP (17) payload length: 37)
::1.53 > ::1.5835: [bad udp cksum 0x0038 -> 0x204c!] 18914 update- q: SOA?
example.org. 0/0/0 (29)
Here is a trimmed down version of my configuration file which shows the same
behavior:
$ head -v -n-1 /etc/knot/knot.conf
==> /etc/knot/knot.conf <==
server:
listen: 0.0.0.0@53
listen: ::@53
user: knot:knot
log:
- target: syslog
any: info
policy:
- id: default
algorithm: RSASHA256
ksk-size: 3248
zsk-size: 2432
nsec3: on
nsec3-iterations: 330
ksk-lifetime: 365d
cds-cdnskey-publish: none
acl:
- id: example.org
action: update
template:
- id: default
file: zones/%s
semantic-checks: on
serial-policy: unixtime
- id: signed
file: zones/%s
dnssec-policy: default
dnssec-signing: on
semantic-checks: on
serial-policy: unixtime
zone:
- domain: example.org
template: signed
file: zones_ddns/%s
zonefile-load: difference
$ head -v -n-1 example.org
==> example.org <==
example.org. 3600 SOA ns1.example.org. hostmaster.example.org 1530570453 3600
1200 3628800 60
example.org. 3600 NS ns1.example.org.
The problem with knot not responding to DDNS updates happened after a server
reboot or shortly after. I could see packets arriving at the server in
tcpdump, but knot didn't react to them and didn't log anything.
The log messages after the reboot where these:
Okt 15 21:12:24 server knotd[508]: info: [<zone>] zone will be loaded
Okt 15 21:12:24 server knotd[508]: info: [<zone>] DNSSEC, key, tag 36134, algorithm
RSASHA256, KSK, public, active
Okt 15 21:12:24 server knotd[508]: info: [<zone>] DNSSEC, key, tag 62508, algorithm
RSASHA256, public, active
Okt 15 21:12:24 server knotd[508]: info: [<zone>] DNSSEC, signing started
Okt 15 21:12:25 server knotd[508]: info: [<zone>] DNSSEC, successfully signed
Okt 15 21:12:25 server knotd[508]: info: [<zone>] loaded, serial 1539630745, 7076
bytes
Okt 15 21:12:25 server knotd[508]: info: [<zone>] DNSSEC, next signing at
2018-10-19T11:32:26
Okt 15 21:12:25 server knotd[508]: info: [<zone>] zone file updated, serial
1539336748 -> 1539630745
after my manual knot restart this got logged:
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] zone will be loaded
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, key, tag 36134, algorithm
RSASHA256, KSK, public, active
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, key, tag 62508, algorithm
RSASHA256, public, active
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, signing started
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, zone is up-to-date
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] loaded, serial 1539630745, 7076
bytes
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, next signing at
2018-10-19T11:32:26
I don't know if these log are useful, but I don't have much more information.
Thanks,
Maxi
On Donnerstag, 18. Oktober 2018 09:55:05 CEST libor.peltan wrote:
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
13:16
New subject: DDNS with DNSSEC, is this expected behavior or a bug
Hi Maxi,
thank you for the information provided. There really seem to be a bug in
re-planning DNSSEC re-sign. I will take a look on it.
Btw, try using knsupdate instead of nsupdate ;)
Regarding the not-responding Knot, the only idea I have is it could have
been possibly Knot unable to bind socket due to occupied port, it would
log something like
2018-10-18T13:14:12 error: cannot bind address 0.0.0.0@53 (address
already in use)
BR,
Libor
Dne 18.10.18 v 12:36 Maximilian Engelhardt napsal(a):
Hi Libor,
I don't know why the message appears three times. I was also wondering about
this. I had a quick look at a tcpdump and nsupdate does indeed send three requests:
12:27:57.973741 IP6 (flowlabel 0x5e7e8, hlim 64, next-header UDP (17) payload length: 37)
::1.5835 > ::1.53: [bad udp cksum 0x0038 -> 0x19f7!] 53303 update SOA? example.org.
(29)
12:27:57.976086 IP6 (flowlabel 0x0f4a8, hlim 64, next-header UDP (17) payload length: 37)
::1.53 > ::1.5835: [bad udp cksum 0x0038 -> 0x99f6!] 53303 update- q: SOA?
example.org. 0/0/0 (29)
12:27:57.976554 IP6 (flowlabel 0x5e7e8, hlim 64, next-header UDP (17) payload length: 65)
::1.5835 > ::1.53: [bad udp cksum 0x0054 -> 0x0d44!] 32688 update [2n] SOA?
example.org. ns: example.org. ANY [0s] A 192.12.0.1, example.org. [1m] A 127.0.0.1 (57)
12:27:57.989710 IP6 (flowlabel 0x0f4a8, hlim 64, next-header UDP (17) payload length: 37)
::1.53 > ::1.5835: [bad udp cksum 0x0038 -> 0xea7d!] 32688 update- q: SOA?
example.org. 0/0/0 (29)
12:27:57.989970 IP6 (flowlabel 0x5e7e8, hlim 64, next-header UDP (17) payload length: 37)
::1.5835 > ::1.53: [bad udp cksum 0x0038 -> 0xa04c!] 18914 update SOA? example.org.
(29)
12:27:57.992947 IP6 (flowlabel 0x0f4a8, hlim 64, next-header UDP (17) payload length: 37)
::1.53 > ::1.5835: [bad udp cksum 0x0038 -> 0x204c!] 18914 update- q: SOA?
example.org. 0/0/0 (29)
Here is a trimmed down version of my configuration file which shows the same
behavior:
$ head -v -n-1 /etc/knot/knot.conf
==> /etc/knot/knot.conf <==
server:
listen: 0.0.0.0@53
listen: ::@53
user: knot:knot
log:
- target: syslog
any: info
policy:
- id: default
algorithm: RSASHA256
ksk-size: 3248
zsk-size: 2432
nsec3: on
nsec3-iterations: 330
ksk-lifetime: 365d
cds-cdnskey-publish: none
acl:
- id: example.org
action: update
template:
- id: default
file: zones/%s
semantic-checks: on
serial-policy: unixtime
- id: signed
file: zones/%s
dnssec-policy: default
dnssec-signing: on
semantic-checks: on
serial-policy: unixtime
zone:
- domain: example.org
template: signed
file: zones_ddns/%s
zonefile-load: difference
$ head -v -n-1 example.org
==> example.org <==
example.org. 3600 SOA ns1.example.org. hostmaster.example.org 1530570453 3600
1200 3628800 60
example.org. 3600 NS ns1.example.org.
The problem with knot not responding to DDNS updates happened after a server
reboot or shortly after. I could see packets arriving at the server in
tcpdump, but knot didn't react to them and didn't log anything.
The log messages after the reboot where these:
Okt 15 21:12:24 server knotd[508]: info: [<zone>] zone will be loaded
Okt 15 21:12:24 server knotd[508]: info: [<zone>] DNSSEC, key, tag 36134, algorithm
RSASHA256, KSK, public, active
Okt 15 21:12:24 server knotd[508]: info: [<zone>] DNSSEC, key, tag 62508, algorithm
RSASHA256, public, active
Okt 15 21:12:24 server knotd[508]: info: [<zone>] DNSSEC, signing started
Okt 15 21:12:25 server knotd[508]: info: [<zone>] DNSSEC, successfully signed
Okt 15 21:12:25 server knotd[508]: info: [<zone>] loaded, serial 1539630745, 7076
bytes
Okt 15 21:12:25 server knotd[508]: info: [<zone>] DNSSEC, next signing at
2018-10-19T11:32:26
Okt 15 21:12:25 server knotd[508]: info: [<zone>] zone file updated, serial
1539336748 -> 1539630745
after my manual knot restart this got logged:
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] zone will be loaded
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, key, tag 36134,
algorithm RSASHA256, KSK, public, active
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, key, tag 62508,
algorithm RSASHA256, public, active
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, signing started
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, zone is up-to-date
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] loaded, serial 1539630745, 7076
bytes
Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, next signing at
2018-10-19T11:32:26
I don't know if these log are useful, but I don't have much more information.
Thanks,
Maxi
On Donnerstag, 18. Oktober 2018 09:55:05 CEST libor.peltan wrote:
> 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
13:42
Hi Libor,
Thanks for you help.
In fact I tried to use knsupdate at some time in the the past and it didn't
work, which later turned out to mainly be a configuration issue on my side.
Maybe I will try switching again some time in the future.
I don't know if this was clear in my last messages, but knot did respond to
normal dns queries, just not to my ddns requests on this zone (I didn't try on
other zones). It looked like some acl or internal processing issue.
Thanks,
Maxi
On Donnerstag, 18. Oktober 2018 13:16:56 CEST libor.peltan wrote:
Hi Maxi,
thank you for the information provided. There really seem to be a bug in
re-planning DNSSEC re-sign. I will take a look on it.
Btw, try using knsupdate instead of nsupdate ;)
Regarding the not-responding Knot, the only idea I have is it could have
been possibly Knot unable to bind socket due to occupied port, it would
log something like
2018-10-18T13:14:12 error: cannot bind address 0.0.0.0@53 (address
already in use)
BR,
Libor
Dne 18.10.18 v 12:36 Maximilian Engelhardt napsal(a):
> Hi Libor,
>
> I don't know why the message appears three times. I was also wondering
> about this. I had a quick look at a tcpdump and nsupdate does indeed send
> three requests:
>
> 12:27:57.973741 IP6 (flowlabel 0x5e7e8, hlim 64, next-header UDP (17)
> payload length: 37) ::1.5835 > ::1.53: [bad udp cksum 0x0038 -> 0x19f7!]
> 53303 update SOA? example.org. (29) 12:27:57.976086 IP6 (flowlabel
> 0x0f4a8, hlim 64, next-header UDP (17) payload length: 37) ::1.53 >
> ::1.5835: [bad udp cksum 0x0038 -> 0x99f6!] 53303 update- q: SOA?
> example.org. 0/0/0 (29) 12:27:57.976554 IP6 (flowlabel 0x5e7e8, hlim 64,
> next-header UDP (17) payload length: 65) ::1.5835 > ::1.53: [bad udp
> cksum 0x0054 -> 0x0d44!] 32688 update [2n] SOA? example.org. ns:
> example.org. ANY [0s] A 192.12.0.1, example.org. [1m] A 127.0.0.1 (57)
> 12:27:57.989710 IP6 (flowlabel 0x0f4a8, hlim 64, next-header UDP (17)
> payload length: 37) ::1.53 > ::1.5835: [bad udp cksum 0x0038 -> 0xea7d!]
> 32688 update- q: SOA? example.org. 0/0/0 (29) 12:27:57.989970 IP6
> (flowlabel 0x5e7e8, hlim 64, next-header UDP (17) payload length: 37)
> ::1.5835 > ::1.53: [bad udp cksum 0x0038 -> 0xa04c!] 18914 update SOA?
> example.org. (29) 12:27:57.992947 IP6 (flowlabel 0x0f4a8, hlim 64,
> next-header UDP (17) payload length: 37) ::1.53 > ::1.5835: [bad udp
> cksum 0x0038 -> 0x204c!] 18914 update- q: SOA? example.org. 0/0/0 (29)
>
> Here is a trimmed down version of my configuration file which shows the
> same behavior:
>
> $ head -v -n-1 /etc/knot/knot.conf
> ==> /etc/knot/knot.conf <==
>
> server:
> listen: 0.0.0.0@53
> listen: ::@53
> user: knot:knot
>
> log:
> - target: syslog
>
> any: info
>
> policy:
> - id: default
>
> algorithm: RSASHA256
> ksk-size: 3248
> zsk-size: 2432
> nsec3: on
> nsec3-iterations: 330
> ksk-lifetime: 365d
> cds-cdnskey-publish: none
>
> acl:
> - id: example.org
>
> action: update
>
> template:
> - id: default
>
> file: zones/%s
> semantic-checks: on
> serial-policy: unixtime
>
> - id: signed
>
> file: zones/%s
> dnssec-policy: default
> dnssec-signing: on
> semantic-checks: on
> serial-policy: unixtime
>
> zone:
> - domain: example.org
>
> template: signed
> file: zones_ddns/%s
> zonefile-load: difference
>
> $ head -v -n-1 example.org
> ==> example.org <==
> example.org. 3600 SOA ns1.example.org. hostmaster.example.org
> 1530570453 3600 1200 3628800 60 example.org. 3600 NS
> ns1.example.org.
>
>
> The problem with knot not responding to DDNS updates happened after a
> server reboot or shortly after. I could see packets arriving at the
> server in tcpdump, but knot didn't react to them and didn't log anything.
>
> The log messages after the reboot where these:
>
> Okt 15 21:12:24 server knotd[508]: info: [<zone>] zone will be loaded
> Okt 15 21:12:24 server knotd[508]: info: [<zone>] DNSSEC, key, tag 36134,
> algorithm RSASHA256, KSK, public, active Okt 15 21:12:24 server
> knotd[508]: info: [<zone>] DNSSEC, key, tag 62508, algorithm RSASHA256,
> public, active Okt 15 21:12:24 server knotd[508]: info: [<zone>] DNSSEC,
> signing started Okt 15 21:12:25 server knotd[508]: info: [<zone>] DNSSEC,
> successfully signed Okt 15 21:12:25 server knotd[508]: info: [<zone>]
> loaded, serial 1539630745, 7076 bytes Okt 15 21:12:25 server knotd[508]:
> info: [<zone>] DNSSEC, next signing at 2018-10-19T11:32:26 Okt 15
> 21:12:25 server knotd[508]: info: [<zone>] zone file updated, serial
> 1539336748 -> 1539630745
>
> after my manual knot restart this got logged:
>
> Okt 16 15:25:32 server knotd[3033]: info: [<zone>] zone will be loaded
> Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC, key, tag 36134,
> algorithm RSASHA256, KSK, public, active Okt 16 15:25:32 server
> knotd[3033]: info: [<zone>] DNSSEC, key, tag 62508, algorithm RSASHA256,
> public, active Okt 16 15:25:32 server knotd[3033]: info: [<zone>] DNSSEC,
> signing started Okt 16 15:25:32 server knotd[3033]: info: [<zone>]
> DNSSEC, zone is up-to-date Okt 16 15:25:32 server knotd[3033]: info:
> [<zone>] loaded, serial 1539630745, 7076 bytes Okt 16 15:25:32 server
> knotd[3033]: info: [<zone>] DNSSEC, next signing at 2018-10-19T11:32:26
>
> I don't know if these log are useful, but I don't have much more
> information.
>
> Thanks,
> Maxi
>
> On Donnerstag, 18. Oktober 2018 09:55:05 CEST libor.peltan wrote:
>> 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
2152
days inactive
2153
days old
6 comments
3 participants
participants (3)
-
daniel.salzman＠nic.cz -
libor.peltan -
Maximilian Engelhardt