Hi Korry, Randy,
Manual: On
Delete-Delay: 30d
Unsafe-Operation: No-Check-Keyset
...
What is the original point in using unsafe operation within your zones?
In general, your key set is probably broken. As a result of the
unsafe-operation settings, Knot ignores the issue and tries to sign the
zone somehow, which however does not lead to good result in this situation.
(Anyway, the delete-delay has no effect in manual policy.)
# keymgr psg.com list
649b0d43d1493dd4ad30f8043ca4561c33c38b5a 53567 KSK
RSASHA256/2048 publish=1078099200 active=1078099200
173597db4b4f2f072b568cb637710e891ac52246 25843 ZSK
RSASHA256/2048 publish=1709251200 active=1709251200 retire=1717977600
remove=1717977600
3194d896f2a64f10b103991e5018b72cd3f1cd28 59161 ZSK
RSASHA256/2048 publish=1709251200 active=1709251200 retire=1717977600
remove=1717977600
7b1bf414b34f605c68f9ddb7b52c32c6b53da8d3 5489 KSK
RSASHA256/2048 publish=1718161132
902b8e02a5e75754bd69791735e76cb11c3e37af 22090 ZSK
RSASHA256/2048 publish=1718161132
There are two ZSKs already retired by far, no problem with them. Than
there is a KSK in active state. Do you actually expect this a to be a
CSK, signing both the DNSKEY and the rest of the zone? Besides this,
there is one KSK and one ZSK in "published" state, which means that they
are not used for signing.
I'd recommend you to clean up you keyset. The most straightforward way
would be to make the existing published ZSK active (keymgr psg.com. set
902b8e02a5e75754bd69791735e76cb11c3e37af active=+0). Than decide what to
do with the second published KSK (delete or what?). And finally, maybe
deleting the old keys might be good idea, depending on their purpose.
Please let us know how you proceed with this issue.
Anyway, we are somewhat interested in your experience from under-DDoS
operation. How severe they are and how they are affecting your
authoritative DNS service? Maybe there would be good point in trying out
XDP if the circumstances allow it?
Thanks,
Libor
--
