21 Srp
2020
21 Srp
'20
22:00
I'm currently on 2.6.5, and am moving everything
to a new server I've created that's using the newest
version. However, I've got a couple of zones I am trying
to clean up before the move.
In my effort to resign these zones, I'm retiring/removing
keys associated with these zones prior to resigning them.
But keymgr(8) isn't working as expected.
eg;
12:25pm
Fri, 21
# keymgr some.zone. set 09696 retire=20200821122736 remove=20200821122755
12:28pm
Fri, 21
# keymgr some.zone. list iso
...
83ded1e7f4375657fe12ca666d4bbc6c33b7edea ksk=no zsk=yes tag=09696 algorithm=5
public-only=no created=2020-05-06T04:42:32 pre-active=2020-05-06T04:42:32
publish=2020-05-06T05:42:32 ready=1970-01-01T00:00:00 active=2020-05-06T18:42:32
retire-active=1970-01-01T00:00:00 retire=2020-08-21T12:27:36
post-active=1970-01-01T00:00:00 remove=2020-08-21T12:27:55
...
As you can see, it's 12:28 but the key was not removed.
What am I (missing/misunderstanding?
Thanks.
--Chris
22 Srp
22 Srp
0:19
On Fri, 21 Aug 2020 13:00:26 -0700 knot(a)tacomawireless.net said
I'm currently on 2.6.5, and am moving everything
to a new server I've created that's using the newest
version. However, I've got a couple of zones I am trying
to clean up before the move.
In my effort to resign these zones, I'm retiring/removing
keys associated with these zones prior to resigning them.
But keymgr(8) isn't working as expected.
eg;
12:25pm
Fri, 21
# keymgr some.zone. set 09696 retire=20200821122736 remove=20200821122755
12:28pm
Fri, 21
# keymgr some.zone. list iso
...
83ded1e7f4375657fe12ca666d4bbc6c33b7edea ksk=no zsk=yes tag=09696
algorithm=5 public-only=no created=2020-05-06T04:42:32
pre-active=2020-05-06T04:42:32 publish=2020-05-06T05:42:32
ready=1970-01-01T00:00:00 active=2020-05-06T18:42:32
retire-active=1970-01-01T00:00:00 retire=2020-08-21T12:27:36
post-active=1970-01-01T00:00:00 remove=2020-08-21T12:27:55
...
As you can see, it's 12:28 but the key was not removed.
What am I (missing/misunderstanding?
OK none of this is working as expected;
knotc -f zone-purge some.zone.
keymgr some.zone. list iso
still shows keys
knotc -f zone-purge some.zone. +journal +kaspdb +timers +expire
keymgr some.zone. list iso
nope. all the keys are still there.
so I knotc zone-freeze some.zone.
knotc zone-flush some.zone.
no changes on disk. So I simply edit whats already there on
disk -- delete all key info, and leave only whats required for an
unsigned zone.
keymgr some.zone. generate algorithm=RSASHA1 zsk=true size=1024 active=20200821143536
warning: creating key with different algorithm than configured in the policy
keyhash...
what? the conf file lists:
algorithm: RSASHA1
ksk-size: 2048
zsk-size: 1024
Oh well. Nothing else is working. Let's continue...
keymgr some.zone. generate algorithm=RSASHA1 ksk=true size=2048 active=20200821143536
warning: creating key with different algorithm than configured in the policy
keyhash...
Hmm... same problem. Big surprise. :-(
knotc zone-thaw some.zone.
knotc zone-sign some.zone.
service knot restart
OK the zone on disk was (re?)signed.
let's have a look at the records in the DB:
keymgr some.zone. list iso
Bummer. Now there are 7 records (keys) where there were only 4.
I give up on this version. If I delete the DB's, and simply transfer
the zones on disk to the new server (eliminating the key info). Then
sign them on the new server under the current version of knot. Will
everything work as advertized? Or am I simply misunderstanding the
whole thing?
Thank you for all your time, and consideration.
--Chris
Thanks.
--Chris
--
https://lists.nic.cz/mailman/listinfo/knot-dns-users
24 Srp
24 Srp
9:52
New subject: keymgr doesn't delete (remove) keys
Hi Chris,
Dne 22.08.20 v 00:19 Chris napsal(a):
On Fri, 21 Aug 2020 13:00:26 -0700
knot(a)tacomawireless.net said
> I'm currently on 2.6.5, and am moving everything
> to a new server I've created that's using the newest
> version. However, I've got a couple of zones I am trying
> to clean up before the move.
> In my effort to resign these zones, I'm retiring/removing
> keys associated with these zones prior to resigning them.
> But keymgr(8) isn't working as expected.
> eg;
> 12:25pm
> Fri, 21
> # keymgr some.zone. set 09696 retire=20200821122736
> remove=20200821122755
>
> 12:28pm
> Fri, 21
> # keymgr some.zone. list iso
> ...
> 83ded1e7f4375657fe12ca666d4bbc6c33b7edea ksk=no zsk=yes tag=09696
> algorithm=5 public-only=no created=2020-05-06T04:42:32
> pre-active=2020-05-06T04:42:32 publish=2020-05-06T05:42:32
> ready=1970-01-01T00:00:00 active=2020-05-06T18:42:32
> retire-active=1970-01-01T00:00:00 retire=2020-08-21T12:27:36
> post-active=1970-01-01T00:00:00 remove=2020-08-21T12:27:55
> ...
>
> As you can see, it's 12:28 but the key was not removed.
> What am I (missing/misunderstanding?
The key is still there, and its 'removed' timer is set to what you
specified: 2020-08-21T12:27:55. It won't appear in the zone after this
timestamp. If you want to remove the key from the KASP database
whatsoever, simply call `keymgr some.zone. delete 9696`.
OK none of this is working as expected;
knotc -f zone-purge some.zone.
Please note, that `knotc` is a tool that in most
cases only tells the
running `knotd` what it shall do. What was the output of the `knotc`
command you called, and what did the running Knot DNS server print into
its log when you called?
keymgr some.zone. list iso
still shows keys
knotc -f zone-purge some.zone. +journal +kaspdb +timers +expire
keymgr some.zone. list iso
nope. all the keys are still there.
so I knotc zone-freeze some.zone.
knotc zone-flush some.zone.
no changes on disk. So I simply edit whats already there on
disk -- delete all key info, and leave only whats required for an
unsigned zone.
Zone-flush shall only update the zone file on disk. Did it? Or was
it
already up-to-date?
keymgr some.zone. generate algorithm=RSASHA1 zsk=true size=1024
active=20200821143536
warning: creating key with different algorithm than configured in the
policy
keyhash...
what? the conf file lists:
algorithm: RSASHA1
ksk-size: 2048
zsk-size: 1024
Can you please check if keymgr worked with the same (default,
depends on
your distribution and Knot build/package) configuration file as Knot
daemon? Is the RSASHA1 algorithm in the configuration file really
assigned to that zone?
Oh well. Nothing else is working. Let's
continue...
keymgr some.zone. generate algorithm=RSASHA1 ksk=true size=2048
active=20200821143536
warning: creating key with different algorithm than configured in the
policy
keyhash...
Hmm... same problem. Big surprise. :-(
knotc zone-thaw some.zone.
knotc zone-sign some.zone.
service knot restart
OK the zone on disk was (re?)signed.
let's have a look at the records in the DB:
keymgr some.zone. list iso
Bummer. Now there are 7 records (keys) where there were only 4.
How do they look
like? What appears in the log of Knot daemon?
I give up on this version. If I delete the DB's, and simply transfer
the zones on disk to the new server (eliminating the key info). Then
sign them on the new server under the current version of knot. Will
everything work as advertized? Or am I simply misunderstanding the
whole thing?
You are probably misunderstanding some pieces of the whole thing.
Consider re-reading our documentation carefully. It's far from ideal,
but some users were already able to deal with it :)
Thank you for all your time, and consideration.
--Chris
>
> Thanks.
>
> --Chris
> --
> https://lists.nic.cz/mailman/listinfo/knot-dns-users
BR,
Libor
1550
days inactive
1553
days old
2 comments
2 participants
participants (2)
-
Chris -
libor.peltan