23 Lis
2017
23 Lis
'17
13:23
Hello Knot DNS users,
CZ.NIC has released Knot DNS 2.6.2!
This version primarily extends dnskey rollover support. From now it's
easy with enabled automatic DNSSEC signing to switch between (KSK, ZSK)
key pair and one CSK. An algorithm rotation is also possible.
One old bug was fixed relating to unexpected reply for a DS query
with an owner below a delegation point.
Some issues with old compilers or 32-bit platforms were resolved.
Changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.6.2/NEWS
Documentation:
https://www.knot-dns.cz/docs/2.6/html/
Source code:
https://secure.nic.cz/files/knot-dns/knot-2.6.2.tar.xz
https://secure.nic.cz/files/knot-dns/knot-2.6.2.tar.xz.asc
Regards,
Daniel
23 Lis
23 Lis
14:45
Hello,
I upgraded from knot 2.6.1 and experienced some unexpected results.
knot.conf
semantic-checks: on
single-type-signing: on
algorithm: ecdsap256sha256
zonefile-sync: -1 # (sigs stored in journal)
After upgrade and restart with knot 2.6.2 I saw the following log messages:
....
knotd: info: [seckle.cz.] DNSSEC, signing scheme rollover started
knotd: info: [seckle.cz.] DNSSEC, key, tag 16025, algorithm
ECDSAP256SHA256, CSK, public
knotd: info: [seckle.cz.] DNSSEC, key, tag 16019, algorithm
ECDSAP256SHA256, KSK, public, active
knotd: error: [seckle.cz.] DNSSEC, keys validation failed (missing
active KSK or ZSK)
knotd: error: [seckle.cz.] DNSSEC, failed to load keys (missing active
KSK or ZSK)
knotd: error: [seckle.cz.] zone event 'load' failed (missing active KSK
or ZSK)
....
knot would then answer SERVFAIL when asked for any query e.g.
kdig @::1 seckle.cz soa
I was surprised that the upgrade resulted in the creation of a new KSK
(CSK) keyid: 16025.
I guess the zone did not load because of the semantic-checks. This seems
to be a "mandatory check" because "extra checks" are logged only
(knot.conf (5)). However, it is not clear to me what mandatory check
prevented the zone load?
I removed the new key again with keymgr:
keymgr seckle.cz list
05b7706700f77a2c8ec864816e2824fd8bca21a5 ksk=yes tag=16025 algorithm=13
public-only=no created=1511442713 pre-active=0 publish=1511442713
ready=0 active=0 retire-active=0 retire=0 post-active=0 remove=0
30d3916050ba253ee8aedebe9402f64f07b721dc ksk=yes tag=16019 algorithm=13
public-only=no created=1507904215 pre-active=0 publish=1507904215
ready=1507907815 active=1507983419 retire-active=0 retire=0
post-active=0 remove=0
keymgr seckle.cz delete 05b7706700f77a2c8ec864816e2824fd8bca21a5
OK
I also downgraded to 2.6.1 and everything works again.
No I'm wondering why did this go wrong?
Maybe I should have tried to purge the journal first? or use "knotc
zone-sign seckle.cz" to fully resign the zone?
Daniel
16:03
Hi Daniel,
It's interesting. We didn't come across this problem during testing.
Please stay tuned!
Daniel
On 2017-11-23 14:45, Daniel Stirnimann wrote:
Hello,
I upgraded from knot 2.6.1 and experienced some unexpected results.
knot.conf
semantic-checks: on
single-type-signing: on
algorithm: ecdsap256sha256
zonefile-sync: -1 # (sigs stored in journal)
After upgrade and restart with knot 2.6.2 I saw the following log
messages:
....
knotd: info: [seckle.cz.] DNSSEC, signing scheme rollover started
knotd: info: [seckle.cz.] DNSSEC, key, tag 16025, algorithm
ECDSAP256SHA256, CSK, public
knotd: info: [seckle.cz.] DNSSEC, key, tag 16019, algorithm
ECDSAP256SHA256, KSK, public, active
knotd: error: [seckle.cz.] DNSSEC, keys validation failed (missing
active KSK or ZSK)
knotd: error: [seckle.cz.] DNSSEC, failed to load keys (missing active
KSK or ZSK)
knotd: error: [seckle.cz.] zone event 'load' failed (missing active KSK
or ZSK)
....
knot would then answer SERVFAIL when asked for any query e.g.
kdig @::1 seckle.cz soa
I was surprised that the upgrade resulted in the creation of a new KSK
(CSK) keyid: 16025.
I guess the zone did not load because of the semantic-checks. This
seems
to be a "mandatory check" because "extra checks" are logged only
(knot.conf (5)). However, it is not clear to me what mandatory check
prevented the zone load?
I removed the new key again with keymgr:
keymgr seckle.cz list
05b7706700f77a2c8ec864816e2824fd8bca21a5 ksk=yes tag=16025 algorithm=13
public-only=no created=1511442713 pre-active=0 publish=1511442713
ready=0 active=0 retire-active=0 retire=0 post-active=0 remove=0
30d3916050ba253ee8aedebe9402f64f07b721dc ksk=yes tag=16019 algorithm=13
public-only=no created=1507904215 pre-active=0 publish=1507904215
ready=1507907815 active=1507983419 retire-active=0 retire=0
post-active=0 remove=0
keymgr seckle.cz delete 05b7706700f77a2c8ec864816e2824fd8bca21a5
OK
I also downgraded to 2.6.1 and everything works again.
No I'm wondering why did this go wrong?
Maybe I should have tried to purge the journal first? or use "knotc
zone-sign seckle.cz" to fully resign the zone?
Daniel
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
19:04
Hi all,
we have analyzed the problem and are considering the best way to fix it.
Please keep using version 2.6.1 for now.
Apologizes for the issue!
Libor
Dne 23.11.2017 v 16:03 daniel.salzman(a)nic.cz napsal(a):
Hi Daniel,
It's interesting. We didn't come across this problem during testing.
Please stay tuned!
Daniel
On 2017-11-23 14:45, Daniel Stirnimann wrote:
Hello,
I upgraded from knot 2.6.1 and experienced some unexpected results.
knot.conf
semantic-checks: on
single-type-signing: on
algorithm: ecdsap256sha256
zonefile-sync: -1 # (sigs stored in journal)
After upgrade and restart with knot 2.6.2 I saw the following log
messages:
....
knotd: info: [seckle.cz.] DNSSEC, signing scheme rollover started
knotd: info: [seckle.cz.] DNSSEC, key, tag 16025, algorithm
ECDSAP256SHA256, CSK, public
knotd: info: [seckle.cz.] DNSSEC, key, tag 16019, algorithm
ECDSAP256SHA256, KSK, public, active
knotd: error: [seckle.cz.] DNSSEC, keys validation failed (missing
active KSK or ZSK)
knotd: error: [seckle.cz.] DNSSEC, failed to load keys (missing active
KSK or ZSK)
knotd: error: [seckle.cz.] zone event 'load' failed (missing active KSK
or ZSK)
....
knot would then answer SERVFAIL when asked for any query e.g.
kdig @::1 seckle.cz soa
I was surprised that the upgrade resulted in the creation of a new KSK
(CSK) keyid: 16025.
I guess the zone did not load because of the semantic-checks. This seems
to be a "mandatory check" because "extra checks" are logged only
(knot.conf (5)). However, it is not clear to me what mandatory check
prevented the zone load?
I removed the new key again with keymgr:
keymgr seckle.cz list
05b7706700f77a2c8ec864816e2824fd8bca21a5 ksk=yes tag=16025 algorithm=13
public-only=no created=1511442713 pre-active=0 publish=1511442713
ready=0 active=0 retire-active=0 retire=0 post-active=0 remove=0
30d3916050ba253ee8aedebe9402f64f07b721dc ksk=yes tag=16019 algorithm=13
public-only=no created=1507904215 pre-active=0 publish=1507904215
ready=1507907815 active=1507983419 retire-active=0 retire=0
post-active=0 remove=0
keymgr seckle.cz delete 05b7706700f77a2c8ec864816e2824fd8bca21a5
OK
I also downgraded to 2.6.1 and everything works again.
No I'm wondering why did this go wrong?
Maybe I should have tried to purge the journal first? or use "knotc
zone-sign seckle.cz" to fully resign the zone?
Daniel
_______________________________________________
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
2557
days inactive
2557
days old
3 comments
4 participants
participants (4)
-
Daniel Salzman -
Daniel Stirnimann -
daniel.salzman＠nic.cz
-
libor.peltan＠nic.cz