Hi,
I have the requirement to re-sign my zones exactly every 24 hours. I'm
not sure how to achieve this, because I'm not clear about the
correlation of the following parameters:
zsk-lifetime
propagation-delay
rrsig-lifetime
rrsig-refresh
rrsig-pre-refresh
Can anybody give a hint what values I need to have an exact re-signing
period of 24 hours?
Thanks a lot,
Thomas
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
Hi all,
we'd like to inform you about recently found bug in Knot DNS 2.9.x.
The bug affects automatic key roll-overs when automatic key management
is configured
https://www.knot-dns.cz/docs/2.9/singlehtml/index.html#automatic-dnssec-sig…
The ZSK, CSK or algorithm roll-over might be finished too early, so that
DNSKEY and RRSIG records in resolvers' caches get out of sync, leading
to temporary DNSSEC validation failure.
Affected versions are Knot DNS 2.9.0 -- 2.9.4.
We will release fixing version 2.9.5 soon.
In the meantime, we recommend to apply the workaround: set the
configuration option zone-max-ttl
https://www.knot-dns.cz/docs/2.9/singlehtml/index.html#zone-max-ttl
explicitly to a value greater or equal to maximal TTL among all records
in the zone. (Remove the workaround once upgraded to fixed version.)
Many thanks to Anand Buddhdev from RIPE NCC for finding this bug.
Caring regards,
Libor Peltan
CZ.NIC
We're consolidating servers, and as a result. I need to transfer
some the IPs, zones && keys to other servers.
I'm trying to find the least eventful way to accomplish this.
I attempted to transfer (signed) zones and IPs once before. But
the slaves wouldn't accept the zones and I ultimately had to
purge the journals on all the servers I had control of, and
re-key and re-sign the zones to make everything work as intended.
All the zones are written/kept on disk (except changes that haven't
already been flushed to disk from the DB).
I'm wondering if it's enough to freeze all the zones on their
current serves. Then shutdown the server(s), and transfer the
zones, keys, and merge the configs onto the new servers would
be the correct way to do this? If not. Please advise.
Thank you for all your time, and consideration.
--Chris
