12 Čen
2024
12 Čen
'24
18:17
Please also mention to Randy that it would be much better to separate his
signing and authoritative DNS servers. Running it all on the same server is
probably not a good idea, especially with the signer being exposed to the
public Internet.
Regards,
Anand
On Wed, 12 Jun 2024 at 17:42, Korry Luke <koluke(a)wide.ad.jp> wrote:
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,
--
Korry Luke
ルーク, コリー
koluke(a)wide.ad.jp
Graduate School of Media and Governance
Keio University Shonan Fujisawa Campus
慶應義塾大学湘南藤沢キャンパス 政策・メディア研究科
--
> 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
--