I have the following signing policy configured in a test environment:
- id: rsadefault
algorithm: RSASHA256
ksk-size: 2048
ksk-lifetime: 30m
zsk-size: 1024
zsk-lifetime: 2h
propagation-delay: 2s
dnskey-ttl: 10s
zone-max-ttl: 15s
nsec3: on
nsec3-iterations: 5
nsec3-salt-length: 8
nsec3-salt-lifetime: 100d
cds-cdnskey-publish: always
ksk-submission: ds_checker
ds-push: hidden-primary
I notice that every five minutes Knot is updating the DS in the parent
zone hosted on a BIND server. It appears that every time Knot refreshes
the secondary it also updates the DS in the parent. (Logs below.)
Isn't that a bit much? I realize I've configured `cds-cdnskey-publish:
always', but I was expecting "always if something changes" :-)
I would prefer on CDS publishing on "rollover", but then the DS record
isn't added to the parent when a zone is first signed.
Is this expected behaviour, respectively, is there a different
configuration I should set?
Thank you,
-JP
zone aa.tm. has an SOA refresh of 300s (5 minutes)
Knot console:
Jul 15 14:38:14 ods knotd[14346]: info: [aa.tm.] refresh, remote 192.168.1.140@53, remote serial 20, zone is up-to-date
Jul 15 14:38:14 ods knotd[14346]: info: [aa.tm.] DS push, outgoing, remote 192.168.1.140@53, success
BIND console:
15-Jul-2020 16:38:23.946 client @0x7fd5bc7f8568 192.168.1.150#58386 (aa.tm): query: aa.tm IN SOA -E(0)T (192.168.1.140)
15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer (tm): query: tm IN SOA -SE(0)T (192.168.1.140)
15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer: signer "k-signer" approved
15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer: updating zone 'tm/IN': deleting rrset at 'aa.tm' DS
15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer: updating zone 'tm/IN': adding an RR at 'aa.tm' DS 54410 8 2 5EAF060C7F00846B82D66CAAB29542450383DDF99390151694CC2A95 8C78E648
... after five minutes ...
Knot console:
Jul 15 14:43:14 ods knotd[14346]: info: [aa.tm.] refresh, remote 192.168.1.140@53, remote serial 20, zone is up-to-date
Jul 15 14:43:14 ods knotd[14346]: info: [aa.tm.] DS push, outgoing, remote 192.168.1.140@53, success
BIND console:
15-Jul-2020 16:43:24.016 client @0x7fd56c220d68 192.168.1.150#58390 (aa.tm): query: aa.tm IN SOA -E(0)T (192.168.1.140)
15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer (tm): query: tm IN SOA -SE(0)T (192.168.1.140)
15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer: signer "k-signer" approved
15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer: updating zone 'tm/IN': deleting rrset at 'aa.tm' DS
15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer: updating zone 'tm/IN': adding an RR at 'aa.tm' DS 54410 8 2 5EAF060C7F00846B82D66CAAB29542450383DDF99390151694CC2A95 8C78E648
Hello!
first of all, thank you for a wonderful authoritative DNS server; as
mentioned a while back, I'm loving the automatic key management and DS
push; both work a treat.
I have a requirement for manual key management and that is to be able to
roll KSK keys a la RFC 5011 for both BIND and Unbound instances to
automatically change their trust anchors.
In Knot I can retire a key and subsequently have it removed, but the key
isn't revoked (a.k.a. key flags 257+128 == 385).
keymgr . set 41155 active=+1mi retire=+5mi remove=+60mi
As such, BIND will, when this particular KSK is removed from the DNSKEY
RRset, (rightly) complain:
managed-keys-zone: Active key 41155 for zone . unexpectedly
missing
managed-keys-zone: Key 30377 for zone . is now trusted
(acceptance timer complete)
I've not found the word 'revoke' in the documentation, and no flags I
can set with keymgr(8) seem to indicate that I can revoke a key. Can you
help me, please?
As an aside, I've noticed that when keymgr's `remove' time is reached,
the key is removed from the zone (which is expected), however the key
itself remains in the key store. From there, I can delete it, but I can
also set flags on it in such a way as that it's brought *back* into the
zone. Is that expected behaviour? It's not a problem per se, I'd just
like to know whether I've understood the system.
Thank you and kind regards,
-JP
Dear all,
I am deploying a DNS system using the Knot DNS software.
I have read in the document and I did not see any DNS query log.
So let me ask DNS Knot software can collect DNS query log? If possible,
what is the configuration?
Best regards,
Chinhlk.
Hi,
I performed a manual key roll over with this command:
$ knotc zone-key-rollover dnssec-test.xxx zsk
The result is 2 different ZSK's with the same key id:
dnssec-test.xxx. 3600 IN DNSKEY 256 3 8 (
AwEAAc5W.....
) ; ZSK; alg = RSASHA256; key id = 7030
dnssec-test.xxx. 3600 IN DNSKEY 256 3 8 (
AwEAAc7Q5U......
) ; ZSK; alg = RSASHA256; key id = 7030
>From the log:
2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, key, tag 56464,
algorithm RSASHA256, KSK, public, ready, active+
2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, key, tag 7030,
algorithm RSASHA256, public
2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, key, tag 7030,
algorithm RSASHA256, public, active
2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, signing started
2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, zone is up-to-date
Is it the indented behavior to have two ZSK's with the same key id?
Thanks a lot,
Thomas
