15 Čec
2020
15 Čec
'20
16:53
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
15 Čec
15 Čec
18:10
Hi JP,
first of all, it's usually more suitable to configure
cds-cdnskey-publish to "rollover". The KSK for any newly created zone is
created in 'submission' phase, so the CDS+CDNSKEY will be present at the
beginning, together with immediate DS push. Does this really not work
for you?
With cds-cdnskey-publish: always, it was also an intention that DS push
is done only in case the CDS is really changed. There might be a tiny
bug that does this on every zone change. Let me put it on a todo list...
BR,
L.
Dne 15.07.20 v 16:53 Jan-Piet Mens napsal(a):
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
16 Čec
16 Čec
13:51
Libor,
Does this really not work for you?
It does.
With cds-cdnskey-publish: always, it was also an
intention that DS push
is done only in case the CDS is really changed. There might be a tiny
bug that does this on every zone change. Let me put it on a todo
list...
I think that "tiny bug" is there, yes. :)
-JP
11:43
On Wed, 15 Jul 2020 16:53:14 +0200
Jan-Piet Mens <list(a)mens.de> wrote:
I have the following signing policy configured in a
test environment:
ksk-lifetime: 30m
zsk-lifetime: 2h
These settings are insane. You shouldn't have that short lifetime for
ksk. Make sure your ksk lifetime is at least multiple times longer than
zsk lifetime.
--
Tuomo Soini <tis(a)foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>
12:31
Well, when the intention is just experimenting and testing Knot behavior
during roll-overs, then such settings is pretty much OK :)
For real DNSSEC deployment, there is no reason to have key lifetime
shorter than several months.
Libor
Dne 16.07.20 v 11:43 Tuomo Soini napsal(a):
On Wed, 15 Jul 2020 16:53:14 +0200
Jan-Piet Mens <list(a)mens.de> wrote:
I have the following signing policy configured in
a test environment:
ksk-lifetime: 30m
zsk-lifetime: 2h
These settings are insane. You shouldn't have that
short lifetime for
ksk. Make sure your ksk lifetime is at least multiple times longer than
zsk lifetime.
1388
days inactive
1389
days old
5 comments
3 participants
participants (3)
-
Jan-Piet Mens -
libor.peltan -
Tuomo Soini