From he at uninett.no  Mon May 11 20:05:00 2020
From: he at uninett.no (Havard Eidnes)
Date: Mon, 11 May 2020 22:05:00 +0200 (CEST)
Subject: [Opendnssec-user] KSK stuck in "retire" state
In-Reply-To: <20200427.101942.2176256205160348720.he@uninett.no>
References: <20200427.101942.2176256205160348720.he@uninett.no>
Message-ID: <20200511.220500.2273859296249209479.he@uninett.no>

Hi,

a while earlier I reported:

> we're still running OpenDNSSEC 1.4.14 for our operational signer
> host.  This works mostly OK, but recently one of our KSKs appear
> to have become stuck in the "retire" state:
>
> ods @ signer: {1} ods-ksmutil key list | grep KSK | grep -v active
> mail.uninett.no                 KSK           retire    2020-04-22 16:16:49 
> ods @ signer: {2}

This persisted, and the KSK was being used to sign the DNSKEY
RRset as well.

I finally found a way to push OpenDNSSEC to move beyond this, and
that was to do

  ods-ksmutil key rollover -z mail.uninett.no -t KSK

and OpenDNSSEC then dignified to actually generate a new KSK and
roll out this one which had gotten "stuck".

Quite a bit earlier I reported I had the same issue on my test
installation of OpenDNSSEC 2.x, and the zone there which had
gotten stuck similarly was unwedged with

  ods-enforcer key rollover -z eduvpn.no --keytype KSK

So, not a fix for how this got into this state, but at least a
workaround to push OpenDNSSEC to move onwards.  Something to take
note of behind the ear; it appears to be a somewhat rare event...

Regards,

- H?vard

From Johan.a.Bergstrom at tietoevry.com  Tue May 26 15:21:29 2020
From: Johan.a.Bergstrom at tietoevry.com (Johan A Bergstrom)
Date: Tue, 26 May 2020 15:21:29 -0000
Subject: [Opendnssec-user] DNSSEC opendnssec vs bind inline signing
Message-ID: <HE1PR04MB3132C6D4AEFC51C060CFF6AAB0B00@HE1PR04MB3132.eurprd04.prod.outlook.com>

Hello.

So I am looking to redesign our DNS infrastructure and I am in discussions with some other architects about the DNSSEC support implementation.

We have been running OpenDNSSEC since 1.4.0 and we are quite happy with it, have been able to automate a lot of zone/DNSSEC management in this solution, but now we need to refresh the whole infrastructure and my colleagues are looking into Bind as a standalone solution now that is has support for inline signing and KASP and more.

The pro's I see is in OpenDNSSEC are that the keys are managed with better/higher security in mind, SoftHSM (or HW HSM module), in bind it's still just keeping private keypairs in the filesystem although can be in an alternate location from the zonefiles.

The con's I see in OpenDNSSEC are that the setup is much more complex, and troubleshooting it requires deeper infrastructural knowledge.

My colleagues are arguing that Bind will eventually make OpenDNSSEC obsolete, which might happen, but the timeframe I see for this is quite long, maybe in 4-5 years as they have just recently implemented KASP, still missing the HSM management for private keys, which is the most important part security wise in my perspective.

In an overview, I am looking to implement the DNSSEC management/signing/security part inhouse, and put nameserver slaves in containers/vms around available clouds.

More pro's/con's regarding either solution, what do you guys think?

H?lsningar / Best regards, 

Johan Bergstr?m, Lead Technical Architect / Linux
TietoEVRY, ZSH Hybrid Infra