Hi Libor,

Thanks for the advice, that appears to have done the trick.  Much
appreciated!

The original logic for the unsafe setting transition, as I understand,
was due to the effect of the DDoS, the signing host had started falling
behind with signing gradually to the point it missed a signing cycle and
started throwing errors/refusing to sign the zone entirely, which then
led to the

We are out of the woods for now it seems, but we'll likely need to work
on followup in the coming days/weeks and future mitigation plans,
perhaps including some of the tuning you mentioned.  Randy will likely
follow up separately, I think his mail server and DNS should be back up
and resolvable by now.

Thanks again, just wanted to drop a quick note of appreciation.

On 2024-06-12 15:52, libor.peltan via knot-dns-users wrote:
> 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
>
> --

--
Korry Luke
ルーク,　コリー
koluke@wide.ad.jp
Graduate School of Media and Governance
Keio University Shonan Fujisawa Campus
慶應義塾大学湘南藤沢キャンパス 政策・メディア研究科

--