12 Pro
2017
12 Pro
'17
15:20
Hi everybody,
I would have a question related to zone signing. Whenever I reload knot config
using knotc reload it starts to resign all DNSSEC enabled zones. It makes the
daemon sometimes unresponsive to knotc utility.
root@idunn:# knotc reload
error: failed to control (connection timeout)
Is it a design intent to sign zones while reloading config? Is it really
needed? It invokes zone transfers, consumes resources, etc.
Thanks for answer
With regards
Ales
12 Pro
12 Pro
15:27
Hi,
If the zone is up-to-date, then there is no re-sign during server reload.
Are the changes stored in the journal/zonefile? Could you send me
some relating parts of the log?
Daniel
On 12/12/2017 03:20 PM, Aleš Rygl wrote:
Hi everybody,
I would have a question related to zone signing. Whenever I reload knot config
using knotc reload it starts to resign all DNSSEC enabled zones. It makes the
daemon sometimes unresponsive to knotc utility.
root@idunn:# knotc reload
error: failed to control (connection timeout)
Is it a design intent to sign zones while reloading config? Is it really
needed? It invokes zone transfers, consumes resources, etc.
Thanks for answer
With regards
Ales
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
17:19
Hi,
See the relevant parts of the config and also the log below. There were no updates to the
zone, I have flushed journal to file, performed zone-status command followed by knotc
reload. Then I can see that zone is re-signed an zone transfer follows (KNOT is a hidden
master),
Configuration (just rozjezdy.cz choosen as an example):
policy:
- id: tmcz-default
algorithm: ecdsap256sha256
zsk-lifetime: 30d
ksk-lifetime: 90d
nsec3: on
nsec3-salt-length: 16
cds-cdnskey-publish: always
propagation-delay: 1d
ksk-submission: nic.cz
template:
- id: signed
storage: "/var/lib/knot/signed"
file: "db.%s"
serial-policy: unixtime
disable-any: on
semantic-checks: on
module: mod-rrl/rrl-10
module: mod-stats/custom
notify: idunn-freya
acl: [allowed_transfer]
dnssec-policy: tmcz-default
dnssec-signing: on
zone:
- domain: rozjezdy.cz
template: signed
root@idunn:/etc/knot# knotc zone-status rozjezdy.cz
[rozjezdy.cz.] role: master | serial: 1513089643 | transaction: none | freeze: no |
refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal
flush: not scheduled | notify: not scheduled | DNSSEC re-sign: +6D17h31m18s | NSEC3
resalt: +22D22h35m50s | parent DS query: not scheduled
root@idunn:/etc/knot#
root@idunn:~# journalctl -u knot -f | grep rozjezdy
Dec 12 17:03:34 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 12 17:06:42 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-flush'
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-19T10:34:52
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513089643 -> 1513094831
Dec 12 17:07:12 idunn knotd[4604]: info: [rozjezdy.cz.] notify, outgoing,
93.153.117.50@53: serial 1513094831
Dec 12 17:07:13 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.50@40241: started, serial 1513089643 -> 1513094831
Dec 12 17:07:13 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.50@40241: finished, 0.00 seconds, 1 messages, 705 bytes
Dec 12 17:07:14 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.20@40111: started, serial 1513089643 -> 1513094831
Dec 12 17:07:14 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.20@40111: finished, 0.00 seconds, 1 messages, 705 bytes
root@idunn:/etc/knot# knotc zone-status rozjezdy.cz
[rozjezdy.cz.] role: master | serial: 1513094831 | transaction: none | freeze: no |
refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal
flush: not scheduled | notify: not scheduled | DNSSEC re-sign: +6D17h27m3s | NSEC3 resalt:
+22D22h31m35s | parent DS query: not scheduled
root@idunn:/etc/knot#
I have not checked it in a detail nevertheless is seems that all zones are re-signed:
Dec 12 17:03:34 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 12 17:06:42 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-flush'
Dec 12 17:07:01 idunn knotd[4604]: info: control, received command 'reload'
Dec 12 17:07:01 idunn knotd[4604]: info: reloading configuration file
'/etc/knot/knot.conf'
Dec 12 17:07:08 idunn knotd[4604]: info: configuration reloaded
Dec 12 17:07:08 idunn knotd[4604]: info: [test.net.] DNSSEC, signing zone
Dec 12 17:07:08 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, signing zone
Dec 12 17:07:09 idunn knotd[4604]: info: [test.net.] DNSSEC, key, tag 31290, algorithm
ECDSAP256SHA256, KSK, public, ready, active
Dec 12 17:07:09 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, key, tag 50849, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 12 17:07:09 idunn knotd[4604]: info: [test.net.] DNSSEC, key, tag 51884, algorithm
ECDSAP256SHA256, public, active
Dec 12 17:07:09 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, key, tag 40637, algorithm
ECDSAP256SHA256, public, active
Dec 12 17:07:10 idunn knotd[4604]: info: [test.net.] DNSSEC, signing started
Dec 12 17:07:10 idunn knotd[4604]: info: [test.net.] DNSSEC, zone is up-to-date
Dec 12 17:07:10 idunn knotd[4604]: info: [test.net.] DNSSEC, next signing at
2017-12-14T13:22:15
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, signing zone
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, key, tag 53237, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, key, tag 36052, algorithm
ECDSAP256SHA256, public, active
Dec 12 17:07:10 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, signing started
Dec 12 17:07:10 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, zone is up-to-date
Dec 12 17:07:10 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, next signing at
2017-12-15T14:01:52
Dec 12 17:07:10 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, signing zone
Dec 12 17:07:10 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, key, tag 11563, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 12 17:07:10 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, key, tag 39847, algorithm
ECDSAP256SHA256, public, active
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, signing started
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, zone is up-to-date
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, next signing at
2017-12-15T08:26:15
Dec 12 17:07:10 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, signing zone
Dec 12 17:07:10 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, key, tag 30976, algorithm
ECDSAP256SHA256, KSK, public, ready, active
Dec 12 17:07:10 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, key, tag 26699, algorithm
ECDSAP256SHA256, public, active
Dec 12 17:07:11 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, signing started
Dec 12 17:07:11 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, signing started
Dec 12 17:07:11 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, successfully signed
Dec 12 17:07:11 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, zone is up-to-date
Dec 12 17:07:11 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, next signing at
2017-12-19T16:39:13
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, signing zone
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, key, tag 26662, algorithm
ECDSAP256SHA256, KSK, public, ready, active
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, key, tag 38793, algorithm
ECDSAP256SHA256, public, active
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, signing started
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, zone is up-to-date
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, next signing at
2017-12-19T16:39:13
Dec 12 17:07:11 idunn knotd[4604]: info: [tcrowd.cz.] DNSSEC, signing zone
Dec 12 17:07:11 idunn knotd[4604]: info: [tcrowd.cz.] DNSSEC, key, tag 1752, algorithm
ECDSAP256SHA256, KSK, public, ready, active
Dec 12 17:07:11 idunn knotd[4604]: info: [tcrowd.cz.] DNSSEC, key, tag 30878, algorithm
ECDSAP256SHA256, public, active
Dec 12 17:07:11 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, next signing at
2017-12-13T09:52:40
Dec 12 17:07:11 idunn knotd[4604]: info: [tmusic.cz.] DNSSEC, signing zone
Regards
Ales
On úterý 12. prosince 2017 15:27:22 CET Daniel Salzman wrote:
Hi,
If the zone is up-to-date, then there is no re-sign during server reload.
Are the changes stored in the journal/zonefile? Could you send me
some relating parts of the log?
Daniel
On 12/12/2017 03:20 PM, Aleš Rygl wrote:
Hi everybody,
I would have a question related to zone signing. Whenever I reload knot
config using knotc reload it starts to resign all DNSSEC enabled zones.
It makes the daemon sometimes unresponsive to knotc utility.
root@idunn:# knotc reload
error: failed to control (connection timeout)
Is it a design intent to sign zones while reloading config? Is it really
needed? It invokes zone transfers, consumes resources, etc.
Thanks for answer
With regards
Ales
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
20:47
Hi,
On 2017-12-12 17:19, Aleš Rygl wrote:
Hi,
See the relevant parts of the config and also the log below. There
were no updates to the zone, I have flushed journal to file, performed
zone-status command followed by knotc reload. Then I can see that zone
is re-signed an zone transfer follows (KNOT is a hidden master),
Configuration (just rozjezdy.cz choosen as an example):
policy:
- id: tmcz-default
algorithm: ecdsap256sha256
zsk-lifetime: 30d
ksk-lifetime: 90d
nsec3: on
nsec3-salt-length: 16
cds-cdnskey-publish: always
propagation-delay: 1d
ksk-submission: nic.cz
template:
- id: signed
storage: "/var/lib/knot/signed"
file: "db.%s"
serial-policy: unixtime
disable-any: on
semantic-checks: on
module: mod-rrl/rrl-10
module: mod-stats/custom
notify: idunn-freya
acl: [allowed_transfer]
dnssec-policy: tmcz-default
dnssec-signing: on
zone:
- domain: rozjezdy.cz
template: signed
root@idunn:/etc/knot# knotc zone-status rozjezdy.cz
[rozjezdy.cz.] role: master | serial: 1513089643 | transaction: none |
freeze: no | refresh: not scheduled | update: not scheduled |
expiration: not scheduled | journal flush: not scheduled | notify: not
scheduled | DNSSEC re-sign: +6D17h31m18s | NSEC3 resalt: +22D22h35m50s
| parent DS query: not scheduled
root@idunn:/etc/knot#
root@idunn:~# journalctl -u knot -f | grep rozjezdy
Dec 12 17:03:34 idunn knotd[4604]: info: [rozjezdy.cz.] control,
received command 'zone-status'
Dec 12 17:06:42 idunn knotd[4604]: info: [rozjezdy.cz.] control,
received command 'zone-flush'
I don't understand the following re-sign. Was it triggered by a zone
change?
Dec 12 17:07:11 idunn knotd[4604]: info:
[rozjezdy.cz.] DNSSEC, signing
zone
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key,
tag 52375, algorithm ECDSAP256SHA256, KSK, public, active
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key,
tag 53957, algorithm ECDSAP256SHA256, public, active
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing
started
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC,
successfully signed
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next
signing at 2017-12-19T10:34:52
Dec 12 17:07:11 idunn knotd[4604]: info: [rozjezdy.cz.] zone file
updated, serial 1513089643 -> 1513094831
Dec 12 17:07:12 idunn knotd[4604]: info: [rozjezdy.cz.] notify,
outgoing, 93.153.117.50@53: serial 1513094831
Dec 12 17:07:13 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR,
outgoing, 93.153.117.50@40241: started, serial 1513089643 ->
1513094831
Dec 12 17:07:13 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR,
outgoing, 93.153.117.50@40241: finished, 0.00 seconds, 1 messages, 705
bytes
Dec 12 17:07:14 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR,
outgoing, 93.153.117.20@40111: started, serial 1513089643 ->
1513094831
Dec 12 17:07:14 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR,
outgoing, 93.153.117.20@40111: finished, 0.00 seconds, 1 messages, 705
bytes
root@idunn:/etc/knot# knotc zone-status rozjezdy.cz
[rozjezdy.cz.] role: master | serial: 1513094831 | transaction: none |
freeze: no | refresh: not scheduled | update: not scheduled |
expiration: not scheduled | journal flush: not scheduled | notify: not
scheduled | DNSSEC re-sign: +6D17h27m3s | NSEC3 resalt: +22D22h31m35s
| parent DS query: not scheduled
root@idunn:/etc/knot#
I have not checked it in a detail nevertheless is seems that all zones
are re-signed:
Dec 12 17:03:34 idunn knotd[4604]: info: [rozjezdy.cz.] control,
received command 'zone-status'
Dec 12 17:06:42 idunn knotd[4604]: info: [rozjezdy.cz.] control,
received command 'zone-flush'
Dec 12 17:07:01 idunn knotd[4604]: info: control, received command
'reload'
Dec 12 17:07:01 idunn knotd[4604]: info: reloading configuration file
'/etc/knot/knot.conf'
Dec 12 17:07:08 idunn knotd[4604]: info: configuration reloaded
Dec 12 17:07:08 idunn knotd[4604]: info: [test.net.] DNSSEC, signing
zone
Dec 12 17:07:08 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, signing
zone
Dec 12 17:07:09 idunn knotd[4604]: info: [test.net.] DNSSEC, key, tag
31290, algorithm ECDSAP256SHA256, KSK, public, ready, active
Dec 12 17:07:09 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, key, tag
50849, algorithm ECDSAP256SHA256, KSK, public, active
Dec 12 17:07:09 idunn knotd[4604]: info: [test.net.] DNSSEC, key, tag
51884, algorithm ECDSAP256SHA256, public, active
Dec 12 17:07:09 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, key, tag
40637, algorithm ECDSAP256SHA256, public, active
Dec 12 17:07:10 idunn knotd[4604]: info: [test.net.] DNSSEC, signing
started
Dec 12 17:07:10 idunn knotd[4604]: info: [test.net.] DNSSEC, zone is
up-to-date
Dec 12 17:07:10 idunn knotd[4604]: info: [test.net.] DNSSEC, next
signing at 2017-12-14T13:22:15
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, signing
zone
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, key, tag
53237, algorithm ECDSAP256SHA256, KSK, public, active
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, key, tag
36052, algorithm ECDSAP256SHA256, public, active
Dec 12 17:07:10 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, signing
started
Dec 12 17:07:10 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, zone is
up-to-date
Dec 12 17:07:10 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, next
signing at 2017-12-15T14:01:52
Dec 12 17:07:10 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, signing
zone
Dec 12 17:07:10 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, key, tag
11563, algorithm ECDSAP256SHA256, KSK, public, active
Dec 12 17:07:10 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, key, tag
39847, algorithm ECDSAP256SHA256, public, active
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, signing
started
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, zone is
up-to-date
Dec 12 17:07:10 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, next
signing at 2017-12-15T08:26:15
Dec 12 17:07:10 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, signing
zone
Dec 12 17:07:10 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, key, tag
30976, algorithm ECDSAP256SHA256, KSK, public, ready, active
Dec 12 17:07:10 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, key, tag
26699, algorithm ECDSAP256SHA256, public, active
Dec 12 17:07:11 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, signing
started
Dec 12 17:07:11 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, signing
started
Dec 12 17:07:11 idunn knotd[4604]: info: [t-run.cz.] DNSSEC,
successfully signed
Dec 12 17:07:11 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, zone is
up-to-date
Dec 12 17:07:11 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, next
signing at 2017-12-19T16:39:13
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, signing
zone
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, key, tag
26662, algorithm ECDSAP256SHA256, KSK, public, ready, active
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, key, tag
38793, algorithm ECDSAP256SHA256, public, active
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, signing
started
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, zone is
up-to-date
Dec 12 17:07:11 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, next
signing at 2017-12-19T16:39:13
Dec 12 17:07:11 idunn knotd[4604]: info: [tcrowd.cz.] DNSSEC, signing
zone
Dec 12 17:07:11 idunn knotd[4604]: info: [tcrowd.cz.] DNSSEC, key, tag
1752, algorithm ECDSAP256SHA256, KSK, public, ready, active
Dec 12 17:07:11 idunn knotd[4604]: info: [tcrowd.cz.] DNSSEC, key, tag
30878, algorithm ECDSAP256SHA256, public, active
Dec 12 17:07:11 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, next
signing at 2017-12-13T09:52:40
Dec 12 17:07:11 idunn knotd[4604]: info: [tmusic.cz.] DNSSEC, signing
zone
Ok, during the server reload all zones are checked for re-sign
necessity:
Dec 12 17:07:10 idunn knotd[4604]: info: [test.net.] DNSSEC, signing
started
If the zone wasn't re-signed, this message is logged:
Dec 12 17:07:10 idunn knotd[4604]: info: [test.net.] DNSSEC, zone is
up-to-date
Of course, in the case of many zones the full reload takes some time.
How
many zones do you have configured?
You should increase the control timeout on the server side:
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#timeout
and also on the client side:
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#document-man_knotc
Regards
Ales
On úterý 12. prosince 2017 15:27:22 CET Daniel Salzman wrote:
Hi,
If the zone is up-to-date, then there is no re-sign during server
reload.
Are the changes stored in the journal/zonefile? Could you send me
some relating parts of the log?
Daniel
On 12/12/2017 03:20 PM, Aleš Rygl wrote:
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users Hi everybody,
I would have a question related to zone signing. Whenever I reload knot
config using knotc reload it starts to resign all DNSSEC enabled zones.
It makes the daemon sometimes unresponsive to knotc utility.
root@idunn:# knotc reload
error: failed to control (connection timeout)
Is it a design intent to sign zones while reloading config? Is it really
needed? It invokes zone transfers, consumes resources, etc.
Thanks for answer
With regards
Ales
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
13 Pro
13 Pro
8:46
Hi Daniel,
I don't understand the following re-sign. Was it
triggered by a zone
change?
Neither me. There was no change to the zone and I have flushed it before reload (is it
ok?):
Dec 12 17:03:34 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 12 17:06:42 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-flush'
I have taken this zone as an example. I can see re-sign for many other zones.
In order to simulate it again I did it again. The last change to the zone (caused by
signing) is from yesterday:
-rw-rw---- 1 knot knot 3.6K Dec 12 17:07 db.rozjezdy.cz
Zone status now:
root@idunn:/var/lib/knot/signed# knotc zone-status rozjezdy.cz
[rozjezdy.cz.] role: master | serial: 1513094831 | transaction: none | freeze: no |
refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal
flush: not scheduled | notify: not scheduled | DNSSEC re-sign: +6D2h26m36s | NSEC3 resalt:
+22D7h31m8s | parent DS query: not scheduled
After knotc reload:
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep rozjezdy.cz.
Dec 13 08:07:43 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:08:16 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-19T10:34:52
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513094831 -> 1513148928
I would expect that zone is up-to-date and no re-sign is necessary. From all the
configured zones following were considered as up-to-date:
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [test.net.] DNSSEC, zone is up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [tcrowd.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [charger.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [tsearch.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [bigtelka.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-sound.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [mmsnasim.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-motion.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-search.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [twistneomezene.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [magentovakariera.cz.] DNSSEC, zone is
up-to-date
... and following were re-signed. There were no changes to the zone files at all!
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep signed
Dec 13 08:08:46 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, successfully signed
Dec 13 08:08:47 idunn knotd[4604]: info: [tmusic.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-crowd.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-music.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-press.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [abctarify.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [internet-4g.cz.] DNSSEC, successfully signed
And what is interesting - after a subsequent reload rozjezdy.cz is resigned again :-)
root@idunn:~# journalctl -u knot -S "2017-12-13 8:15" | grep
"rozjezdy.cz.\|reload"
Dec 13 08:38:04 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:38:11 idunn knotd[4604]: info: control, received command 'reload'
Dec 13 08:38:11 idunn knotd[4604]: info: reloading configuration file
'/etc/knot/knot.conf'
Dec 13 08:38:26 idunn knotd[4604]: info: configuration reloaded
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-19T10:34:52
Dec 13 08:38:32 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513148928 -> 1513150711
Of course, in the case of many zones the full reload
takes some time.
How
many zones do you have configured?
I have 23 forward and DNSSEC enabled zones. All of them are really small, up to 4kB
(signed). The server running knotd is rather weak, it has just 2 cores.
You should increase the control timeout on the server
side:
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#timeout
and also on the client side:
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#document-man_knotc
Thanks
Let me know if you need more details, logs or debugging output. I am ready to help you to
clarify this behavior.
Regards
Ales
14:46
Hi,
Thanks for the logs. I have already reproduced a similar situation. Please wait.
Daniel
On 12/13/2017 08:46 AM, Aleš Rygl wrote:
Hi Daniel,
I don't understand the following re-sign. Was
it triggered by a zone
change?
Neither me. There was no change to the zone and I have flushed it before
reload (is it ok?):
Dec 12 17:03:34 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 12 17:06:42 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-flush'
I have taken this zone as an example. I can see re-sign for many other zones.
In order to simulate it again I did it again. The last change to the zone (caused by
signing) is from yesterday:
-rw-rw---- 1 knot knot 3.6K Dec 12 17:07 db.rozjezdy.cz
Zone status now:
root@idunn:/var/lib/knot/signed# knotc zone-status rozjezdy.cz
[rozjezdy.cz.] role: master | serial: 1513094831 | transaction: none | freeze: no |
refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal
flush: not scheduled | notify: not scheduled | DNSSEC re-sign: +6D2h26m36s | NSEC3 resalt:
+22D7h31m8s | parent DS query: not scheduled
After knotc reload:
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep rozjezdy.cz.
Dec 13 08:07:43 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:08:16 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-19T10:34:52
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513094831 -> 1513148928
I would expect that zone is up-to-date and no re-sign is necessary. From all the
configured zones following were considered as up-to-date:
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [test.net.] DNSSEC, zone is up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [tcrowd.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [charger.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [tsearch.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [bigtelka.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-sound.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [mmsnasim.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-motion.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-search.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [twistneomezene.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [magentovakariera.cz.] DNSSEC, zone is
up-to-date
... and following were re-signed. There were no changes to the zone files at all!
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep signed
Dec 13 08:08:46 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, successfully signed
Dec 13 08:08:47 idunn knotd[4604]: info: [tmusic.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-crowd.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-music.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-press.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [abctarify.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [internet-4g.cz.] DNSSEC, successfully signed
And what is interesting - after a subsequent reload rozjezdy.cz is resigned again :-)
root@idunn:~# journalctl -u knot -S "2017-12-13 8:15" | grep
"rozjezdy.cz.\|reload"
Dec 13 08:38:04 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:38:11 idunn knotd[4604]: info: control, received command 'reload'
Dec 13 08:38:11 idunn knotd[4604]: info: reloading configuration file
'/etc/knot/knot.conf'
Dec 13 08:38:26 idunn knotd[4604]: info: configuration reloaded
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-19T10:34:52
Dec 13 08:38:32 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513148928 -> 1513150711
Of course, in the case of many zones the full
reload takes some time.
How
many zones do you have configured?
I have 23 forward and DNSSEC enabled zones. All
of them are really small, up to 4kB (signed). The server running knotd is rather weak, it
has just 2 cores.
You should increase the control timeout on the
server side:
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#timeout
and also on the client side:
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#document-man_knotc
Thanks
Let me know if you need more details, logs or debugging output. I am ready to help you to
clarify this behavior.
Regards
Ales 
15 Pro
15 Pro
10:26
Hi all,
first, we must distinguish two things:
1) on every reload, every zone is attempted to be re-signed. This takes
some CPU time, as the NSEC(3) chain is re-constructed and RRSIGs
validated. Anyway, if we perform reload "often", it "usually" ends up
with the messages "DNSSEC, zone is up-to-date". This is a design feature
of Knot. Is it a problem for you?
2) when anything in the zone changes, or the zone would re-sign itself
anyway in the meantime, the re-signing ends up with "DNSSEC,
successfully signed". This happens e.g. if zone contents changed, NSEC3
salt updated, some RRSIG nearing its end of validity... If this happens
on "clear" zone, it's a bug. We have de-bugged this behavior in the past
and we also have got a test case covering this. But still it may happen
that there is a bug. The best point to start at is journal contents. In
the changesets it should be visible what changed. You can explore the
journal with "kjournalprint" utility.
Looking forward to some more info.
Libor
Dne 13.12.2017 v 14:46 Daniel Salzman napsal(a):
Hi,
Thanks for the logs. I have already reproduced a similar situation. Please wait.
Daniel
On 12/13/2017 08:46 AM, Aleš Rygl wrote:
Hi Daniel,
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users I don't understand the following re-sign. Was
it triggered by a zone
change?
Neither me. There was no change to the zone and I have flushed it before
reload (is it ok?):
Dec 12 17:03:34 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 12 17:06:42 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-flush'
I have taken this zone as an example. I can see re-sign for many other zones.
In order to simulate it again I did it again. The last change to the zone (caused by
signing) is from yesterday:
-rw-rw---- 1 knot knot 3.6K Dec 12 17:07 db.rozjezdy.cz
Zone status now:
root@idunn:/var/lib/knot/signed# knotc zone-status rozjezdy.cz
[rozjezdy.cz.] role: master | serial: 1513094831 | transaction: none | freeze: no |
refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal
flush: not scheduled | notify: not scheduled | DNSSEC re-sign: +6D2h26m36s | NSEC3 resalt:
+22D7h31m8s | parent DS query: not scheduled
After knotc reload:
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep rozjezdy.cz.
Dec 13 08:07:43 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:08:16 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-19T10:34:52
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513094831 -> 1513148928
I would expect that zone is up-to-date and no re-sign is necessary. From all the
configured zones following were considered as up-to-date:
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [test.net.] DNSSEC, zone is up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [tcrowd.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [charger.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [tsearch.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [bigtelka.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-sound.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [mmsnasim.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-motion.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-search.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [twistneomezene.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [magentovakariera.cz.] DNSSEC, zone is
up-to-date
... and following were re-signed. There were no changes to the zone files at all!
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep signed
Dec 13 08:08:46 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, successfully signed
Dec 13 08:08:47 idunn knotd[4604]: info: [tmusic.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-crowd.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-music.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-press.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [abctarify.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [internet-4g.cz.] DNSSEC, successfully signed
And what is interesting - after a subsequent reload rozjezdy.cz is resigned again :-)
root@idunn:~# journalctl -u knot -S "2017-12-13 8:15" | grep
"rozjezdy.cz.\|reload"
Dec 13 08:38:04 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:38:11 idunn knotd[4604]: info: control, received command 'reload'
Dec 13 08:38:11 idunn knotd[4604]: info: reloading configuration file
'/etc/knot/knot.conf'
Dec 13 08:38:26 idunn knotd[4604]: info: configuration reloaded
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-19T10:34:52
Dec 13 08:38:32 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513148928 -> 1513150711
Of course, in the case of many zones the full
reload takes some time.
How
many zones do you have configured?
I have 23 forward and DNSSEC enabled zones. All
of them are really small, up to 4kB (signed). The server running knotd is rather weak, it
has just 2 cores.
You should increase the control timeout on the
server side:
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#timeout
and also on the client side:
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#document-man_knotc
Thanks
Let me know if you need more details, logs or debugging output. I am ready to help you to
clarify this behavior.
Regards
Ales
19 Pro
19 Pro
20:38
Hi Libor,
On Friday 15 of December 2017 10:26:09 libor.peltan(a)nic.cz wrote:
Hi all,
first, we must distinguish two things:
1) on every reload, every zone is attempted to be re-signed. This takes
some CPU time, as the NSEC(3) chain is re-constructed and RRSIGs
validated. Anyway, if we perform reload "often", it "usually" ends
up
with the messages "DNSSEC, zone is up-to-date". This is a design feature
of Knot. Is it a problem for you?
This is perfectly clear to me and it is not an issue for me. I like that up-to-date status
is logged during the startup.
2) when anything in the zone changes, or the zone would re-sign itself
anyway in the meantime, the re-signing ends up with "DNSSEC,
successfully signed". This happens e.g. if zone contents changed, NSEC3
salt updated, some RRSIG nearing its end of validity... If this happens
on "clear" zone, it's a bug. We have de-bugged this behavior in the past
and we also have got a test case covering this. But still it may happen
that there is a bug. The best point to start at is journal contents. In
the changesets it should be visible what changed. You can explore the
journal with "kjournalprint" utility.
This is also clear to me. I am just trying to find the reason for re-sign when the zone
content was not (externally) updated. I am rather wonder why this is happening than
complaining.
Thanks for reminding me of kjournalprint. When checking the journal I can see (last three
changes):
;; Changes between zone versions: 1513694442 -> 1513707970
;;Removed
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513694442 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102144042 20171219131042 53957
rozjezdy.cz.
Vnzp8R5bJk3sOybu9WoJzf/1ABNuIz3d0WHhbyQ3VDiIzmZwJ13OOUjsqYuD18OqsFO9eFMNJrPccKjMHsDBLw==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102144042 20171219131042
53957 rozjezdy.cz.
9lv+D3biq8FHB2PyTXa98J/31Lf7rdv6KNJNILlm7jsimi0ylSslK6uisLdt5h13jXFRLePs3yWqWMfdBLG8FA==
;;Added
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513707970 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182610 20171219165610 53957
rozjezdy.cz.
zG1o9Rc5zeiO2+JDntbkjrs3Cv+LbKgxvyCYB4tnkT8U/5874YPZlX8OGfDhXAo+QjYk8+RMEf3DReIN/gcbOA==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182610 20171219165610
53957 rozjezdy.cz.
xLDqFtMLVWF8Rwjaq84qj5GATN8ozFKEn1sGUNm4rPvPomChkhpz3z6jAC+jTTawTsCbzfMYkAINIeQpMkLJeA==
;; Changes between zone versions: 1513707970 -> 1513708136
;;Removed
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513707970 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182610 20171219165610 53957
rozjezdy.cz.
zG1o9Rc5zeiO2+JDntbkjrs3Cv+LbKgxvyCYB4tnkT8U/5874YPZlX8OGfDhXAo+QjYk8+RMEf3DReIN/gcbOA==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182610 20171219165610
53957 rozjezdy.cz.
xLDqFtMLVWF8Rwjaq84qj5GATN8ozFKEn1sGUNm4rPvPomChkhpz3z6jAC+jTTawTsCbzfMYkAINIeQpMkLJeA==
;;Added
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513708136 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182856 20171219165856 53957
rozjezdy.cz.
GId9nFX7W6zDuhDkXSEoYHL7P2A3tQpr0mlAlJCpGrW2VnxBXlnmMqfVm376PbfN9jijSt3wKHagzz3eS+22DA==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182856 20171219165856
53957 rozjezdy.cz.
nYEne/00rSqUQtS5p3Lvi7KbeKQvrlPrdiz31WlQoBwMj+Pg5wZdTu1rbacF4vQCjGfdCYgvuU4M1noAlCfZdg==
;; Changes between zone versions: 1513708136 -> 1513708291
;;Removed
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513708136 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182856 20171219165856 53957
rozjezdy.cz.
GId9nFX7W6zDuhDkXSEoYHL7P2A3tQpr0mlAlJCpGrW2VnxBXlnmMqfVm376PbfN9jijSt3wKHagzz3eS+22DA==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182856 20171219165856
53957 rozjezdy.cz.
nYEne/00rSqUQtS5p3Lvi7KbeKQvrlPrdiz31WlQoBwMj+Pg5wZdTu1rbacF4vQCjGfdCYgvuU4M1noAlCfZdg==
;;Added
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513708291 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102183131 20171219170131 53957
rozjezdy.cz.
KklZfsp8Ztzih04/Weedt1aP5Qa9oxsnj72KuGeeqI1szSvL/l6uGC6Rf6ZZJjrN/A/TQMcJzbkgwIMe6YetYA==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102183131 20171219170131
53957 rozjezdy.cz.
FfE9FhQgr8NWCfKf9d1aA0I8h4cd7CCSRbp0Nkq+BXmLOpRMs862lRSWCNHPxRPqufQvjo34AlroRrTYpevwEg==
I do not understand it: are the changes listed above the cause or the consequenceof
re-sign?
Regards
Ales
22 Pro
22 Pro
13:44
Hi Aleš,
thanks for the kjournalprint output! It led strightforwardly to finding
the bug in Knot. The bug is always re-creating and re-signing NSEC3PARAM
record. We have fixed it.
Would you be able and willing to check the bugfix for us before we
release a package? You could either build Knot from current sources
(branch 2.6), or we could send you a newly-built binaries for your
architecture (actually, the fix is probably in libknot shared library).
BR,
Libor
Dne 19.12.2017 v 20:38 Aleš Rygl napsal(a):
Hi Libor,
On Friday 15 of December 2017 10:26:09 libor.peltan(a)nic.cz wrote:
Hi all,
first, we must distinguish two things:
1) on every reload, every zone is attempted to be re-signed. This takes
some CPU time, as the NSEC(3) chain is re-constructed and RRSIGs
validated. Anyway, if we perform reload "often", it "usually" ends
up
with the messages "DNSSEC, zone is up-to-date". This is a design feature
of Knot. Is it a problem for you?
This is perfectly clear to me and it is not an
issue for me. I like that up-to-date status is logged during the startup.
2) when anything in the zone changes, or the zone
would re-sign itself
anyway in the meantime, the re-signing ends up with "DNSSEC,
successfully signed". This happens e.g. if zone contents changed, NSEC3
salt updated, some RRSIG nearing its end of validity... If this happens
on "clear" zone, it's a bug. We have de-bugged this behavior in the past
and we also have got a test case covering this. But still it may happen
that there is a bug. The best point to start at is journal contents. In
the changesets it should be visible what changed. You can explore the
journal with "kjournalprint" utility.
This is also clear to me. I am
just trying to find the reason for re-sign when the zone content was not (externally)
updated. I am rather wonder why this is happening than complaining.
Thanks for reminding me of kjournalprint. When checking the journal I can see (last three
changes):
;; Changes between zone versions: 1513694442 -> 1513707970
;;Removed
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513694442 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102144042 20171219131042 53957
rozjezdy.cz.
Vnzp8R5bJk3sOybu9WoJzf/1ABNuIz3d0WHhbyQ3VDiIzmZwJ13OOUjsqYuD18OqsFO9eFMNJrPccKjMHsDBLw==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102144042 20171219131042
53957 rozjezdy.cz.
9lv+D3biq8FHB2PyTXa98J/31Lf7rdv6KNJNILlm7jsimi0ylSslK6uisLdt5h13jXFRLePs3yWqWMfdBLG8FA==
;;Added
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513707970 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182610 20171219165610 53957
rozjezdy.cz.
zG1o9Rc5zeiO2+JDntbkjrs3Cv+LbKgxvyCYB4tnkT8U/5874YPZlX8OGfDhXAo+QjYk8+RMEf3DReIN/gcbOA==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182610 20171219165610
53957 rozjezdy.cz.
xLDqFtMLVWF8Rwjaq84qj5GATN8ozFKEn1sGUNm4rPvPomChkhpz3z6jAC+jTTawTsCbzfMYkAINIeQpMkLJeA==
;; Changes between zone versions: 1513707970 -> 1513708136
;;Removed
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513707970 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182610 20171219165610 53957
rozjezdy.cz.
zG1o9Rc5zeiO2+JDntbkjrs3Cv+LbKgxvyCYB4tnkT8U/5874YPZlX8OGfDhXAo+QjYk8+RMEf3DReIN/gcbOA==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182610 20171219165610
53957 rozjezdy.cz.
xLDqFtMLVWF8Rwjaq84qj5GATN8ozFKEn1sGUNm4rPvPomChkhpz3z6jAC+jTTawTsCbzfMYkAINIeQpMkLJeA==
;;Added
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513708136 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182856 20171219165856 53957
rozjezdy.cz.
GId9nFX7W6zDuhDkXSEoYHL7P2A3tQpr0mlAlJCpGrW2VnxBXlnmMqfVm376PbfN9jijSt3wKHagzz3eS+22DA==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182856 20171219165856
53957 rozjezdy.cz.
nYEne/00rSqUQtS5p3Lvi7KbeKQvrlPrdiz31WlQoBwMj+Pg5wZdTu1rbacF4vQCjGfdCYgvuU4M1noAlCfZdg==
;; Changes between zone versions: 1513708136 -> 1513708291
;;Removed
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513708136 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182856 20171219165856 53957
rozjezdy.cz.
GId9nFX7W6zDuhDkXSEoYHL7P2A3tQpr0mlAlJCpGrW2VnxBXlnmMqfVm376PbfN9jijSt3wKHagzz3eS+22DA==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182856 20171219165856
53957 rozjezdy.cz.
nYEne/00rSqUQtS5p3Lvi7KbeKQvrlPrdiz31WlQoBwMj+Pg5wZdTu1rbacF4vQCjGfdCYgvuU4M1noAlCfZdg==
;;Added
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513708291 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102183131 20171219170131 53957
rozjezdy.cz.
KklZfsp8Ztzih04/Weedt1aP5Qa9oxsnj72KuGeeqI1szSvL/l6uGC6Rf6ZZJjrN/A/TQMcJzbkgwIMe6YetYA==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102183131 20171219170131
53957 rozjezdy.cz.
FfE9FhQgr8NWCfKf9d1aA0I8h4cd7CCSRbp0Nkq+BXmLOpRMs862lRSWCNHPxRPqufQvjo34AlroRrTYpevwEg==
I do not understand it: are the changes listed above the cause or the consequenceof
re-sign?
Regards
Ales
26 Pro
26 Pro
9:54
Hi Libor,
Good news! If you would not mind providing me with a Debian Stretch 64bit package, it
would be great. I am ready to test it.
Regards
Ales
22. prosince 2017 13:44:04 SEČ, "libor.peltan(a)nic.cz"
<libor.peltan(a)nic.cz> napsal:
Hi Aleš,
thanks for the kjournalprint output! It led strightforwardly to finding
the bug in Knot. The bug is always re-creating and re-signing
NSEC3PARAM
record. We have fixed it.
Would you be able and willing to check the bugfix for us before we
release a package? You could either build Knot from current sources
(branch 2.6), or we could send you a newly-built binaries for your
architecture (actually, the fix is probably in libknot shared library).
BR,
Libor
Dne 19.12.2017 v 20:38 Aleš Rygl napsal(a):
that up-to-date status is logged during the startup.
re-sign when the zone content was not (externally) updated. I
am rather
wonder why this is happening than complaining.
Hi Libor,
On Friday 15 of December 2017 10:26:09 libor.peltan(a)nic.cz wrote:
> Hi all,
>
> first, we must distinguish two things:
>
> 1) on every reload, every zone is attempted to be re-signed. This
takes
> some CPU time, as the NSEC(3) chain is
re-constructed and RRSIGs
> validated. Anyway, if we perform reload "often", it "usually"
ends
up
> with the messages "DNSSEC, zone is
up-to-date". This is a design
feature
of Knot.
Is it a problem for you?
This is perfectly clear to me and it is not an issue for
me. I like
> 2) when anything in the zone changes, or the zone would re-sign
itself
> anyway in the meantime, the re-signing ends
up with "DNSSEC,
> successfully signed". This happens e.g. if zone contents changed,
NSEC3
> salt updated, some RRSIG nearing its end of
validity... If this
happens
> on "clear" zone, it's a bug. We
have de-bugged this behavior in the
past
> and we also have got a test case covering
this. But still it may
happen
> that there is a bug. The best point to start
at is journal contents.
In
> the changesets it should be visible what
changed. You can explore
the
journal
with "kjournalprint" utility.
This is also clear to me. I am just trying
to find the reason for Thanks for reminding me of kjournalprint. When
checking the journal I
can see (last three changes):
;; Changes between zone versions: 1513694442 -> 1513707970
;;Removed
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz.
dss-system.t-mobile.cz.
1513694442 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2
3600 20180102144042
20171219131042 53957 rozjezdy.cz.
Vnzp8R5bJk3sOybu9WoJzf/1ABNuIz3d0WHhbyQ3VDiIzmZwJ13OOUjsqYuD18OqsFO9eFMNJrPccKjMHsDBLw==
rozjezdy.cz. 0 RRSIG
NSEC3PARAM 13 2 0
20180102144042 20171219131042 53957 rozjezdy.cz.
9lv+D3biq8FHB2PyTXa98J/31Lf7rdv6KNJNILlm7jsimi0ylSslK6uisLdt5h13jXFRLePs3yWqWMfdBLG8FA==
;;Added
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz.
dss-system.t-mobile.cz.
1513707970 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2
3600 20180102182610
20171219165610 53957 rozjezdy.cz.
zG1o9Rc5zeiO2+JDntbkjrs3Cv+LbKgxvyCYB4tnkT8U/5874YPZlX8OGfDhXAo+QjYk8+RMEf3DReIN/gcbOA==
rozjezdy.cz. 0 RRSIG
NSEC3PARAM 13 2 0
20180102182610 20171219165610 53957 rozjezdy.cz.
xLDqFtMLVWF8Rwjaq84qj5GATN8ozFKEn1sGUNm4rPvPomChkhpz3z6jAC+jTTawTsCbzfMYkAINIeQpMkLJeA==
;; Changes between zone versions: 1513707970
-> 1513708136
;;Removed
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz.
dss-system.t-mobile.cz.
1513707970 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2
3600 20180102182610
20171219165610 53957 rozjezdy.cz.
zG1o9Rc5zeiO2+JDntbkjrs3Cv+LbKgxvyCYB4tnkT8U/5874YPZlX8OGfDhXAo+QjYk8+RMEf3DReIN/gcbOA==
rozjezdy.cz. 0 RRSIG
NSEC3PARAM 13 2 0
20180102182610 20171219165610 53957 rozjezdy.cz.
xLDqFtMLVWF8Rwjaq84qj5GATN8ozFKEn1sGUNm4rPvPomChkhpz3z6jAC+jTTawTsCbzfMYkAINIeQpMkLJeA==
;;Added
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz.
dss-system.t-mobile.cz.
1513708136 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2
3600 20180102182856
20171219165856 53957 rozjezdy.cz.
GId9nFX7W6zDuhDkXSEoYHL7P2A3tQpr0mlAlJCpGrW2VnxBXlnmMqfVm376PbfN9jijSt3wKHagzz3eS+22DA==
rozjezdy.cz. 0 RRSIG
NSEC3PARAM 13 2 0
20180102182856 20171219165856 53957 rozjezdy.cz.
nYEne/00rSqUQtS5p3Lvi7KbeKQvrlPrdiz31WlQoBwMj+Pg5wZdTu1rbacF4vQCjGfdCYgvuU4M1noAlCfZdg==
;; Changes between zone versions: 1513708136
-> 1513708291
;;Removed
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz.
dss-system.t-mobile.cz.
1513708136 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2
3600 20180102182856
20171219165856 53957 rozjezdy.cz.
GId9nFX7W6zDuhDkXSEoYHL7P2A3tQpr0mlAlJCpGrW2VnxBXlnmMqfVm376PbfN9jijSt3wKHagzz3eS+22DA==
rozjezdy.cz. 0 RRSIG
NSEC3PARAM 13 2 0
20180102182856 20171219165856 53957 rozjezdy.cz.
nYEne/00rSqUQtS5p3Lvi7KbeKQvrlPrdiz31WlQoBwMj+Pg5wZdTu1rbacF4vQCjGfdCYgvuU4M1noAlCfZdg==
;;Added
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz.
dss-system.t-mobile.cz.
1513708291 7200 600 1209600 3600
rozjezdy.cz. 3600 RRSIG SOA 13 2
3600 20180102183131
20171219170131 53957 rozjezdy.cz.
KklZfsp8Ztzih04/Weedt1aP5Qa9oxsnj72KuGeeqI1szSvL/l6uGC6Rf6ZZJjrN/A/TQMcJzbkgwIMe6YetYA==
rozjezdy.cz. 0 RRSIG
NSEC3PARAM 13 2 0
20180102183131 20171219170131 53957 rozjezdy.cz.
FfE9FhQgr8NWCfKf9d1aA0I8h4cd7CCSRbp0Nkq+BXmLOpRMs862lRSWCNHPxRPqufQvjo34AlroRrTYpevwEg==
I do not understand it: are the changes listed above the cause or the
consequenceof
re-sign?
>
> Regards
> Ales
5 Led
5 Led
13:54
Hi Aleš,
Dan told me a Debian package is ready in our repo, see
https://www.knot-dns.cz/download/
Please check the fix.
Thanks,
Libor
Dne 26.12.2017 v 09:54 Aleš Rygl napsal(a):
Hi Libor,
Good news! If you would not mind providing me with a Debian Stretch
64bit package, it would be great. I am ready to test it.
Regards
Ales
22. prosince 2017 13:44:04 SEČ, "libor.peltan(a)nic.cz"
<libor.peltan(a)nic.cz> napsal:
Hi Aleš,
thanks for the kjournalprint output! It led strightforwardly to finding
the bug in Knot. The bug is always re-creating and re-signing NSEC3PARAM
record. We have fixed it.
Would you be able and willing to check the bugfix for us before we
release a package? You could either build Knot from current sources
(branch 2.6), or we could send you a newly-built binaries for your
architecture (actually, the fix is probably in libknot shared library).
BR,
Libor
Dne 19.12.2017 v 20:38 Aleš Rygl napsal(a):
Hi Libor, On Friday 15 of December 2017 10:26:09
libor.peltan(a)nic.cz wrote:
Hi all, first, we must distinguish two things: 1) on every
reload, every zone is attempted to be re-signed. This
takes some CPU time, as the NSEC(3) chain is
re-constructed and RRSIGs validated. Anyway, if we perform
reload "often", it "usually" ends up with the messages
"DNSSEC, zone is up-to-date". This is a design feature of
Knot. Is it a problem for you?
This is perfectly clear to me and it is not an issue for me. I
like that up-to-date status is logged during the startup.
2) when anything in the zone changes, or the zone would
re-sign itself anyway in the meantime, the re-signing ends
up with "DNSSEC, successfully signed". This happens e.g.
if zone contents changed, NSEC3 salt updated, some RRSIG
nearing its end of validity... If this happens on "clear"
zone, it's a bug. We have de-bugged this behavior in the
past and we also have got a test case covering this. But
still it may happen that there is a bug. The best point to
start at is journal contents. In the changesets it should
be visible what changed. You can explore the journal with
"kjournalprint" utility.
This is also clear to me. I am just trying to find the reason
for re-sign when the zone content was not (externally)
updated. I am rather wonder why this is happening than
complaining. Thanks for reminding me of kjournalprint. When
checking the journal I can see (last three changes): ;;
Changes between zone versions: 1513694442 -> 1513707970
;;Removed rozjezdy.cz <http://rozjezdy.cz>. 3600 SOA
idunn.t-mobile.cz <http://idunn.t-mobile.cz>.
dss-system.t-mobile.cz <http://dss-system.t-mobile.cz>.
1513694442 7200 600 1209600 3600 rozjezdy.cz
<http://rozjezdy.cz>. 3600 RRSIG SOA 13 2 3600 20180102144042
20171219131042 53957 rozjezdy.cz <http://rozjezdy.cz>.
Vnzp8R5bJk3sOybu9WoJzf/1ABNuIz3d0WHhbyQ3VDiIzmZwJ13OOUjsqYuD18OqsFO9eFMNJrPccKjMHsDBLw==
rozjezdy.cz <http://rozjezdy.cz>. 0 RRSIG NSEC3PARAM 13 2 0
20180102144042 20171219131042 53957 rozjezdy.cz
<http://rozjezdy.cz>.
9lv+D3biq8FHB2PyTXa98J/31Lf7rdv6KNJNILlm7jsimi0ylSslK6uisLdt5h13jXFRLePs3yWqWMfdBLG8FA==
;;Added rozjezdy.cz <http://rozjezdy.cz>. 3600 SOA
idunn.t-mobile.cz <http://idunn.t-mobile.cz>.
dss-system.t-mobile.cz <http://dss-system.t-mobile.cz>.
1513707970 7200 600 1209600 3600 rozjezdy.cz
<http://rozjezdy.cz>. 3600 RRSIG SOA 13 2 3600 20180102182610
20171219165610 53957 rozjezdy.cz <http://rozjezdy.cz>.
zG1o9Rc5zeiO2+JDntbkjrs3Cv+LbKgxvyCYB4tnkT8U/5874YPZlX8OGfDhXAo+QjYk8+RMEf3DReIN/gcbOA==
rozjezdy.cz <http://rozjezdy.cz>. 0 RRSIG NSEC3PARAM 13 2 0
20180102182610 20171219165610 53957 rozjezdy.cz
<http://rozjezdy.cz>.
xLDqFtMLVWF8Rwjaq84qj5GATN8ozFKEn1sGUNm4rPvPomChkhpz3z6jAC+jTTawTsCbzfMYkAINIeQpMkLJeA==
;; Changes between zone versions: 1513707970 -> 1513708136
;;Removed rozjezdy.cz <http://rozjezdy.cz>. 3600 SOA
idunn.t-mobile.cz <http://idunn.t-mobile.cz>.
dss-system.t-mobile.cz <http://dss-system.t-mobile.cz>.
1513707970 7200 600 1209600 3600 rozjezdy.cz
<http://rozjezdy.cz>. 3600 RRSIG SOA 13 2 3600 20180102182610
20171219165610 53957 rozjezdy.cz <http://rozjezdy.cz>.
zG1o9Rc5zeiO2+JDntbkjrs3Cv+LbKgxvyCYB4tnkT8U/5874YPZlX8OGfDhXAo+QjYk8+RMEf3DReIN/gcbOA==
rozjezdy.cz <http://rozjezdy.cz>. 0 RRSIG NSEC3PARAM 13 2 0
20180102182610 20171219165610 53957 rozjezdy.cz
<http://rozjezdy.cz>.
xLDqFtMLVWF8Rwjaq84qj5GATN8ozFKEn1sGUNm4rPvPomChkhpz3z6jAC+jTTawTsCbzfMYkAINIeQpMkLJeA==
;;Added rozjezdy.cz <http://rozjezdy.cz>. 3600 SOA
idunn.t-mobile.cz <http://idunn.t-mobile.cz>.
dss-system.t-mobile.cz <http://dss-system.t-mobile.cz>.
1513708136 7200 600 1209600 3600 rozjezdy.cz
<http://rozjezdy.cz>. 3600 RRSIG SOA 13 2 3600 20180102182856
20171219165856 53957 rozjezdy.cz <http://rozjezdy.cz>.
GId9nFX7W6zDuhDkXSEoYHL7P2A3tQpr0mlAlJCpGrW2VnxBXlnmMqfVm376PbfN9jijSt3wKHagzz3eS+22DA==
rozjezdy.cz <http://rozjezdy.cz>. 0 RRSIG NSEC3PARAM 13 2 0
20180102182856 20171219165856 53957 rozjezdy.cz
<http://rozjezdy.cz>.
nYEne/00rSqUQtS5p3Lvi7KbeKQvrlPrdiz31WlQoBwMj+Pg5wZdTu1rbacF4vQCjGfdCYgvuU4M1noAlCfZdg==
;; Changes between zone versions: 1513708136 -> 1513708291
;;Removed rozjezdy.cz <http://rozjezdy.cz>. 3600 SOA
idunn.t-mobile.cz <http://idunn.t-mobile.cz>.
dss-system.t-mobile.cz <http://dss-system.t-mobile.cz>.
1513708136 7200 600 1209600 3600 rozjezdy.cz
<http://rozjezdy.cz>. 3600 RRSIG SOA 13 2 3600 20180102182856
20171219165856 53957 rozjezdy.cz <http://rozjezdy.cz>.
GId9nFX7W6zDuhDkXSEoYHL7P2A3tQpr0mlAlJCpGrW2VnxBXlnmMqfVm376PbfN9jijSt3wKHagzz3eS+22DA==
rozjezdy.cz <http://rozjezdy.cz>. 0 RRSIG NSEC3PARAM 13 2 0
20180102182856 20171219165856 53957 rozjezdy.cz
<http://rozjezdy.cz>.
nYEne/00rSqUQtS5p3Lvi7KbeKQvrlPrdiz31WlQoBwMj+Pg5wZdTu1rbacF4vQCjGfdCYgvuU4M1noAlCfZdg==
;;Added rozjezdy.cz <http://rozjezdy.cz>. 3600 SOA
idunn.t-mobile.cz <http://idunn.t-mobile.cz>.
dss-system.t-mobile.cz <http://dss-system.t-mobile.cz>.
1513708291 7200 600 1209600 3600 rozjezdy.cz
<http://rozjezdy.cz>. 3600 RRSIG SOA 13 2 3600 20180102183131
20171219170131 53957 rozjezdy.cz <http://rozjezdy.cz>.
KklZfsp8Ztzih04/Weedt1aP5Qa9oxsnj72KuGeeqI1szSvL/l6uGC6Rf6ZZJjrN/A/TQMcJzbkgwIMe6YetYA==
rozjezdy.cz <http://rozjezdy.cz>. 0 RRSIG NSEC3PARAM 13 2 0
20180102183131 20171219170131 53957 rozjezdy.cz
<http://rozjezdy.cz>.
FfE9FhQgr8NWCfKf9d1aA0I8h4cd7CCSRbp0Nkq+BXmLOpRMs862lRSWCNHPxRPqufQvjo34AlroRrTYpevwEg==
I do not understand it: are the changes listed above the cause
or the consequenceof re-sign? Regards Ales
18 Pro
18 Pro
10:18
Hi Aleš,
Could you please set "zone.zonefile-load: difference"
(https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#zonefile-load)?
As the server configuration was extended, some new operation situations have emerged and
we have to consider how to
handle them...
Thanks,
Daniel
On 12/13/2017 08:46 AM, Aleš Rygl wrote:
Hi Daniel,
I don't understand the following re-sign. Was
it triggered by a zone
change?
Neither me. There was no change to the zone and I have flushed it before
reload (is it ok?):
Dec 12 17:03:34 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 12 17:06:42 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-flush'
I have taken this zone as an example. I can see re-sign for many other zones.
In order to simulate it again I did it again. The last change to the zone (caused by
signing) is from yesterday:
-rw-rw---- 1 knot knot 3.6K Dec 12 17:07 db.rozjezdy.cz
Zone status now:
root@idunn:/var/lib/knot/signed# knotc zone-status rozjezdy.cz
[rozjezdy.cz.] role: master | serial: 1513094831 | transaction: none | freeze: no |
refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal
flush: not scheduled | notify: not scheduled | DNSSEC re-sign: +6D2h26m36s | NSEC3 resalt:
+22D7h31m8s | parent DS query: not scheduled
After knotc reload:
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep rozjezdy.cz.
Dec 13 08:07:43 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:08:16 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-19T10:34:52
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513094831 -> 1513148928
I would expect that zone is up-to-date and no re-sign is necessary. From all the
configured zones following were considered as up-to-date:
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [test.net.] DNSSEC, zone is up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [5gnet.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:46 idunn knotd[4604]: info: [mych5.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [tnews.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [t-news.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:47 idunn knotd[4604]: info: [tcrowd.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [charger.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [tsearch.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [bigtelka.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-sound.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [mmsnasim.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-motion.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [t-search.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [twistneomezene.cz.] DNSSEC, zone is up-to-date
Dec 13 08:08:48 idunn knotd[4604]: info: [magentovakariera.cz.] DNSSEC, zone is
up-to-date
... and following were re-signed. There were no changes to the zone files at all!
root@idunn:~# journalctl -u knot -S "2017-12-13" | grep signed
Dec 13 08:08:46 idunn knotd[4604]: info: [t-run.cz.] DNSSEC, successfully signed
Dec 13 08:08:47 idunn knotd[4604]: info: [tmusic.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-crowd.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-music.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [t-press.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [abctarify.cz.] DNSSEC, successfully signed
Dec 13 08:08:48 idunn knotd[4604]: info: [internet-4g.cz.] DNSSEC, successfully signed
And what is interesting - after a subsequent reload rozjezdy.cz is resigned again :-)
root@idunn:~# journalctl -u knot -S "2017-12-13 8:15" | grep
"rozjezdy.cz.\|reload"
Dec 13 08:38:04 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 13 08:38:11 idunn knotd[4604]: info: control, received command 'reload'
Dec 13 08:38:11 idunn knotd[4604]: info: reloading configuration file
'/etc/knot/knot.conf'
Dec 13 08:38:26 idunn knotd[4604]: info: configuration reloaded
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 13 08:38:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-19T10:34:52
Dec 13 08:38:32 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513148928 -> 1513150711
Of course, in the case of many zones the full
reload takes some time.
How
many zones do you have configured?
I have 23 forward and DNSSEC enabled zones. All
of them are really small, up to 4kB (signed). The server running knotd is rather weak, it
has just 2 cores.
You should increase the control timeout on the
server side:
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#timeout
and also on the client side:
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#document-man_knotc
Thanks
Let me know if you need more details, logs or debugging output. I am ready to help you to
clarify this behavior.
Regards
Ales
19 Pro
19 Pro
20:13
Hi Daniel,
I have tried:
- domain: rozjezdy.cz
template: signed
zonefile-load: difference
Zone status before config reloads:
root@idunn:/etc/knot# knotc zone-status rozjezdy.cz
[rozjezdy.cz.] role: master | serial: 1513694442 | transaction: none | freeze: no |
refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal
flush: not scheduled | notify: not scheduled | DNSSEC re-sign: +6D15h11m9s | NSEC3 resalt:
+15D20h15m41s | parent DS query: not scheduled
Nevertheless it does not seem to have any effect. The 1st reload below is without
"zonefile-load: difference".
root@idunn:~# journalctl -u knot -S "2017-12-19 19:20" -f | grep
"rozjezdy\|reload"
Dec 19 19:20:00 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-read'
Dec 19 19:23:43 idunn knotd[4604]: info: [rozjezdy.cz.] control, received command
'zone-status'
Dec 19 19:25:57 idunn knotd[4604]: info: control, received command 'reload'
Dec 19 19:25:57 idunn knotd[4604]: info: reloading configuration file
'/etc/knot/knot.conf'
Dec 19 19:26:07 idunn knotd[4604]: info: configuration reloaded
Dec 19 19:26:10 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 19 19:26:10 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 19 19:26:10 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 19 19:26:10 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 19 19:26:10 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 19 19:26:10 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-26T10:34:52
Dec 19 19:26:10 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513694442 -> 1513707970
Dec 19 19:26:10 idunn knotd[4604]: info: [rozjezdy.cz.] notify, outgoing,
93.153.117.50@53: serial 1513707970
Dec 19 19:26:11 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.50@42577: started, serial 1513694442 -> 1513707970
Dec 19 19:26:11 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.50@42577: finished, 0.00 seconds, 1 messages, 705 bytes
Dec 19 19:26:12 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.20@56615: started, serial 1513694442 -> 1513707970
Dec 19 19:26:12 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.20@56615: finished, 0.00 seconds, 1 messages, 705 bytes
===== 2nd reload =====
Dec 19 19:28:40 idunn knotd[4604]: info: control, received command 'reload'
Dec 19 19:28:41 idunn knotd[4604]: info: reloading configuration file
'/etc/knot/knot.conf'
Dec 19 19:28:53 idunn knotd[4604]: info: configuration reloaded
Dec 19 19:28:56 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 19 19:28:56 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 19 19:28:56 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 19 19:28:56 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 19 19:28:56 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 19 19:28:56 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-26T10:34:52
Dec 19 19:28:57 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513707970 -> 1513708136
Dec 19 19:28:58 idunn knotd[4604]: info: [rozjezdy.cz.] notify, outgoing,
93.153.117.50@53: serial 1513708136
Dec 19 19:28:58 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.50@37453: started, serial 1513707970 -> 1513708136
Dec 19 19:28:58 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.50@37453: finished, 0.00 seconds, 1 messages, 705 bytes
Dec 19 19:29:00 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.20@47995: started, serial 1513707970 -> 1513708136
Dec 19 19:29:00 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.20@47995: finished, 0.00 seconds, 1 messages, 705 bytes
===== 3rd reload: =====
Dec 19 19:31:22 idunn knotd[4604]: info: control, received command 'reload'
Dec 19 19:31:23 idunn knotd[4604]: info: reloading configuration file
'/etc/knot/knot.conf'
Dec 19 19:31:28 idunn knotd[4604]: info: configuration reloaded
Dec 19 19:31:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing zone
Dec 19 19:31:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 52375, algorithm
ECDSAP256SHA256, KSK, public, active
Dec 19 19:31:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, key, tag 53957, algorithm
ECDSAP256SHA256, public, active
Dec 19 19:31:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, signing started
Dec 19 19:31:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, successfully signed
Dec 19 19:31:31 idunn knotd[4604]: info: [rozjezdy.cz.] DNSSEC, next signing at
2017-12-26T10:34:52
Dec 19 19:31:32 idunn knotd[4604]: info: [rozjezdy.cz.] zone file updated, serial
1513708136 -> 1513708291
Dec 19 19:31:32 idunn knotd[4604]: info: [rozjezdy.cz.] notify, outgoing,
93.153.117.50@53: serial 1513708291
Dec 19 19:31:34 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.50@58367: started, serial 1513708136 -> 1513708291
Dec 19 19:31:34 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.50@58367: finished, 0.00 seconds, 1 messages, 705 bytes
Dec 19 19:31:35 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.20@32929: started, serial 1513708136 -> 1513708291
Dec 19 19:31:35 idunn knotd[4604]: info: [rozjezdy.cz.] IXFR, outgoing,
93.153.117.20@32929: finished, 0.00 seconds, 1 messages, 705 bytes
IMHO there is no reason to reason for zone re-sign.
Content of rozjezdy.cz:
;; Zone dump (Knot DNS 2.6.3)
rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz.
1513708291 7200 600 1209600 3600
rozjezdy.cz. 3600 NS ns2.gts.cz.
rozjezdy.cz. 3600 NS freya.t-mobile.cz.
rozjezdy.cz. 3600 NS idunn.t-mobile.cz.
rozjezdy.cz. 3600 MX 10 ms.glow.cz.
rozjezdy.cz. 3600 TXT "v=spf1 +all"
rozjezdy.cz. 3600 A 77.78.107.190
rozjezdy.cz. 3600 DNSKEY 256 3 13
vYmiA2bjCC2MFdb3rX/bq27KkptR9kAUoQzlpbgbhIOHfvK1RQPBqHN2caloQ/hVSdl1dDraGHMvUvHWd+ZK2w==
rozjezdy.cz. 3600 DNSKEY 257 3 13
XMHN1TNq54o2afNNcgmJ7D7gioZ1QFSsCdFXFRJfQojlafd44fHHWihfM1OQ+jswgfo9OYgALfqPFR/XH0givw==
rozjezdy.cz. 0 CDNSKEY 257 3 13
XMHN1TNq54o2afNNcgmJ7D7gioZ1QFSsCdFXFRJfQojlafd44fHHWihfM1OQ+jswgfo9OYgALfqPFR/XH0givw==
rozjezdy.cz. 0 CDS 52375 13 2
484003681345128F0B8D208C6CB34FAB7A0BF6926F49B73251EAE53DE55CAB75
rozjezdy.cz. 0 NSEC3PARAM 1 0 10 -
www.rozjezdy.cz. 3600 CNAME rozjezdy.cz.
;; DNSSEC signatures
rozjezdy.cz. 3600 RRSIG A 13 2 3600 20180102093452 20171219080452 53957
rozjezdy.cz.
Tp7dJqJb/TwT0ymaYpvUcR8xlDFqOOxmlVXbzBq/N2iIuzxdCJDFUnquasS3HchO7v1ebYLWNY28BtWIdCOCnA==
rozjezdy.cz. 3600 RRSIG NS 13 2 3600 20180102093452 20171219080452 53957
rozjezdy.cz.
NOZU3T1+GsKbPFnE9ApeZJ900P5SLLfCS6zkwZmQl625PWM4nmXLYP1mebbf7ywdf5+Llztv74mJU4MHbAWqtA==
rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102183131 20171219170131 53957
rozjezdy.cz.
KklZfsp8Ztzih04/Weedt1aP5Qa9oxsnj72KuGeeqI1szSvL/l6uGC6Rf6ZZJjrN/A/TQMcJzbkgwIMe6YetYA==
rozjezdy.cz. 3600 RRSIG MX 13 2 3600 20180102093452 20171219080452 53957
rozjezdy.cz.
rl4/0l7GM7aSGVGbEpjzCd8vu43+LaNTYiKlP7rBix6OdwZettSCLAKW0yF7y+rduvar0GBm22ZHVO5kMnSQsA==
rozjezdy.cz. 3600 RRSIG TXT 13 2 3600 20180102093452 20171219080452 53957
rozjezdy.cz.
kvISPLCm8YUqbBxIar0Ay3gS9DvZ5/LNgj+kB2kcsUVy8dj3MF+FrOjn5gQrj+8h8Vw1eT6hwqXPNAsVYH4ZVQ==
rozjezdy.cz. 3600 RRSIG DNSKEY 13 2 3600 20180102132118 20171219115118
52375 rozjezdy.cz.
Qqj3siwXg/sFdK8LCe5iUcy4COP9XbMvjGnUWxj7CdcqNhNnjM3KFIJb628bRsrgSv/P1XmxspCxaA9mi/UKNg==
rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102183131 20171219170131
53957 rozjezdy.cz.
FfE9FhQgr8NWCfKf9d1aA0I8h4cd7CCSRbp0Nkq+BXmLOpRMs862lRSWCNHPxRPqufQvjo34AlroRrTYpevwEg==
rozjezdy.cz. 0 RRSIG CDS 13 2 0 20180102093452 20171219080452 53957
rozjezdy.cz.
dvgtm8dVDrVNI47PVy1uFV8sRf11prgMjHVc6MQ7rYRQa0pr1bUHSQksW1n3JVBiTmfWTKjT/++8yEv8ZiCPzQ==
rozjezdy.cz. 0 RRSIG CDNSKEY 13 2 0 20180102093452 20171219080452 53957
rozjezdy.cz.
k9PfpKDCpOgOzt0+xe0SDke81et9ST3V86Nf9w0x7GWtVFRiZmJlOEevJtxGGNqFmrOXAYnIQuKL/+bMAnUxAw==
www.rozjezdy.cz. 3600 RRSIG CNAME 13 3 3600 20180102093452 20171219080452
53957 rozjezdy.cz.
8pCV7fzDTrocVR3eVszHeaRpZDVaCIJKHlrrZSv/zvXG23mUfxNkr2fb1doVC7h3IYgxfQPzA/S+XnFLxUkpEw==
;; DNSSEC NSEC3 chain
dqrampcd1k487r07t2gi35ah2r44ltgu.rozjezdy.cz. 3600 NSEC3 1 0 10 -
FLVVS4U1UT4AG241269G9SRVDP08PUS3 CNAME RRSIG
flvvs4u1ut4ag241269g9srvdp08pus3.rozjezdy.cz. 3600 NSEC3 1 0 10 -
DQRAMPCD1K487R07T2GI35AH2R44LTGU A NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM CDS CDNSKEY
;; DNSSEC NSEC3 signatures
dqrampcd1k487r07t2gi35ah2r44ltgu.rozjezdy.cz. 3600 RRSIG NSEC3 13 3 3600
20180102144042 20171219131042 53957 rozjezdy.cz.
wCX+HQ2NWTlnzAFhriJgk3WLBDOtVzLCTyaZbO+3NFEgh94vLQ8xpMO8wMxOSWdf1oqOtAPozmxNimVjXmGXKQ==
flvvs4u1ut4ag241269g9srvdp08pus3.rozjezdy.cz. 3600 RRSIG NSEC3 13 3 3600
20180102144042 20171219131042 53957 rozjezdy.cz.
rzrUuG2ABhWaUoEL6pjeBDhm8+1JcXTDno3ys6XqP72+R+jA50cfx2UJK0tRlcxwJpuOHhchnC/VxDz3Qh1KPg==
;; Written 27 records
;; Time 2017-12-19 19:31:32 CET
Let me know if I can do something more here.
Regards
Ales
On Monday 18 of December 2017 10:18:29 Daniel Salzman wrote:
Hi Aleš,
Could you please set "zone.zonefile-load: difference"
(https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#zonefile-load)? As
the server configuration was extended, some new operation situations have
emerged and we have to consider how to handle them...
Thanks,
Daniel
2309
days inactive
2333
days old
12 comments
4 participants
participants (4)
-
Aleš Rygl -
Daniel Salzman -
daniel.salzman＠nic.cz
-
libor.peltan＠nic.cz