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