Sent from my Nokia phone
-----Original Message-----
From: [email protected]
Sent: 02/12/2011 19:00:11
To: [email protected]
Subject: Opendnssec-user Digest, Vol 30, Issue 2
Send Opendnssec-user mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opendnssec-user digest..."
Today's Topics:
1. Howto publish an additional DNSKEY-record (Michael Braunoeder)
2. Re: Howto publish an additional DNSKEY-record (Hugo Salgado)
3. Re: Howto publish an additional DNSKEY-record (Rickard Bellgrim)
4. Re: Howto publish an additional DNSKEY-record (Michael Braunoeder)
5. Re: Howto publish an additional DNSKEY-record (Michael Braunoeder)
6. Re: Howto publish an additional DNSKEY-record (Antti Ristim?ki)
7. Policy rollover fails (Casper Gielen)
----------------------------------------------------------------------
Message: 1
Date: Thu, 1 Dec 2011 15:04:33 +0100
From: Michael Braunoeder <[email protected]>
Subject: [Opendnssec-user] Howto publish an additional DNSKEY-record
To: "[email protected]"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Hi,
I'm currently implementing a DNSSEC-Setup and I need some ideas how to
fix a specific problem.
Our setup looks like this:
We use Hardware-HSMs to store the keys (KSKs and ZSKs) and to do the
daily work. The DS-Record(s) for the KSK(s) are added to the parent
zone. To be prepared in cause of failures of these HSMs, we would like
to generate a key stored in a SoftHSM. The DNSKEY-Record of this key
should also be added to the signed zone (only the DNSKEY-Record, no
signatures with this key should be generated) and the corresponding
DS-Record to the parent zone. For security reasons this SoftHSM should
not be available on the server. In case of emergency, the SoftHSM is
copied to the server and a key rollover to this key should be done.
How can I realize this setup with OpenDNSSEC? Is it possible to keep
this key in the "Publish" state until 1.1.2100 (or something like that)?
Thanks in advance and best,
Michael
------------------------------
Message: 2
Date: Thu, 01 Dec 2011 11:30:12 -0300
From: Hugo Salgado <[email protected]>
Subject: Re: [Opendnssec-user] Howto publish an additional
DNSKEY-record
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15
On 12/01/2011 11:04 AM, Michael Braunoeder wrote:
> Hi,
>
> I'm currently implementing a DNSSEC-Setup and I need some ideas how to
> fix a specific problem.
>
> Our setup looks like this:
> We use Hardware-HSMs to store the keys (KSKs and ZSKs) and to do the
> daily work. The DS-Record(s) for the KSK(s) are added to the parent
> zone. To be prepared in cause of failures of these HSMs, we would like
> to generate a key stored in a SoftHSM. The DNSKEY-Record of this key
> should also be added to the signed zone (only the DNSKEY-Record, no
> signatures with this key should be generated) and the corresponding
> DS-Record to the parent zone. For security reasons this SoftHSM should
> not be available on the server. In case of emergency, the SoftHSM is
> copied to the server and a key rollover to this key should be done.
>
> How can I realize this setup with OpenDNSSEC? Is it possible to keep
> this key in the "Publish" state until 1.1.2100 (or something like that)?
What I would do is to add the emergency DNSKEY as a normal RR in the
plain zone, because OpenDNSSEC doesn't need to maintain its state as a
key.
Then, in case of a rollover, it should be a matter of adding a new
keystore with SoftHSM.
Just thinking, never tested.
Hugo
------------------------------
Message: 3
Date: Thu, 1 Dec 2011 15:48:53 +0100
From: Rickard Bellgrim <[email protected]>
Subject: Re: [Opendnssec-user] Howto publish an additional
DNSKEY-record
To: Hugo Salgado <[email protected]>
Cc: [email protected]
Message-ID:
<CAKFiofmZqgMAs3mz-FKH2==qpsyquznw6vjhh_knn1x3_b4...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
> What I would do is to add the emergency DNSKEY as a normal RR in the
> plain zone, because OpenDNSSEC doesn't need to maintain its state as a
> key.
>
> Then, in case of a rollover, it should be a matter of adding a new
> keystore with SoftHSM.
You just add the DNSKEY of the emergency ZSK in the unsigned zone. And
add a DS of the emergency KSK to the parent zone. But the DS could be
added later if you feel that you have time for that. You also need to
use the same algorithm. If not, then it would be an algorithm rollover
which is not handled in this way.
// Rickard
------------------------------
Message: 4
Date: Thu, 1 Dec 2011 15:49:26 +0100
From: Michael Braunoeder <[email protected]>
Subject: Re: [Opendnssec-user] Howto publish an additional
DNSKEY-record
To: Hugo Salgado <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Am 01.12.2011 15:30, schrieb Hugo Salgado:
> On 12/01/2011 11:04 AM, Michael Braunoeder wrote:
>> Hi,
>>
>> I'm currently implementing a DNSSEC-Setup and I need some ideas how to
>> fix a specific problem.
>>
>> Our setup looks like this:
>> We use Hardware-HSMs to store the keys (KSKs and ZSKs) and to do the
>> daily work. The DS-Record(s) for the KSK(s) are added to the parent
>> zone. To be prepared in cause of failures of these HSMs, we would like
>> to generate a key stored in a SoftHSM. The DNSKEY-Record of this key
>> should also be added to the signed zone (only the DNSKEY-Record, no
>> signatures with this key should be generated) and the corresponding
>> DS-Record to the parent zone. For security reasons this SoftHSM should
>> not be available on the server. In case of emergency, the SoftHSM is
>> copied to the server and a key rollover to this key should be done.
>>
>> How can I realize this setup with OpenDNSSEC? Is it possible to keep
>> this key in the "Publish" state until 1.1.2100 (or something like that)?
>
> What I would do is to add the emergency DNSKEY as a normal RR in the
> plain zone, because OpenDNSSEC doesn't need to maintain its state as a
> key.
>
> Then, in case of a rollover, it should be a matter of adding a new
> keystore with SoftHSM.
If it would be that easy, this would be great :-)
> Just thinking, never tested.
IIRC I tested it some time ago (with one of the first OpenDNSSEC beta
versions) and I got an error. But I'll test it again.
Best,
Michael
------------------------------
Message: 5
Date: Thu, 1 Dec 2011 15:54:25 +0100
From: Michael Braunoeder <[email protected]>
Subject: Re: [Opendnssec-user] Howto publish an additional
DNSKEY-record
To: Rickard Bellgrim <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Hi Rickard,
Am 01.12.2011 15:48, schrieb Rickard Bellgrim:
>> What I would do is to add the emergency DNSKEY as a normal RR in the
>> plain zone, because OpenDNSSEC doesn't need to maintain its state as a
>> key.
>>
>> Then, in case of a rollover, it should be a matter of adding a new
>> keystore with SoftHSM.
>
> You just add the DNSKEY of the emergency ZSK in the unsigned zone.
Perfect.
> And add a DS of the emergency KSK to the parent zone. But the DS could be
> added later if you feel that you have time for that. You also need to use
> the same algorithm. If not, then it would be an algorithm rollover
> which is not handled in this way.
Yes, all our keys will use the same algorithm.
Thanks,
Michael
------------------------------
Message: 6
Date: Fri, 2 Dec 2011 07:58:34 +0200
From: Antti Ristim?ki <[email protected]>
Subject: Re: [Opendnssec-user] Howto publish an additional
DNSKEY-record
To: <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Hi,
On 2011-12-01 16:54, Michael Braunoeder wrote:
> Hi Rickard,
>
> Am 01.12.2011 15:48, schrieb Rickard Bellgrim:
>>> What I would do is to add the emergency DNSKEY as a normal RR in the
>>> plain zone, because OpenDNSSEC doesn't need to maintain its state as a
>>> key.
>>>
>>> Then, in case of a rollover, it should be a matter of adding a new
>>> keystore with SoftHSM.
>>
>> You just add the DNSKEY of the emergency ZSK in the unsigned zone.
>
> Perfect.
When switching over to the emergency HSM, I think you should also add
the DNSKEY record of the old HSM's ZSK to the unsigned zone file that is
then signed using the emergency HSM. That is because a resolver can
still have a signature made with the old ZSK in the cache but needs to
fetch the DNSKEY RRset from the authoritative servers.
Antti
------------------------------
Message: 7
Date: Fri, 02 Dec 2011 10:28:21 +0100
From: Casper Gielen <[email protected]>
Subject: [Opendnssec-user] Policy rollover fails
To: Open DNSSEC List <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
I've been doing key rollovers. It works fine for individual zones, but not when
rolling entire policies. I am recovering from a major failure so it might be a
matter of a confuse database.
Background: I tried to switch a large number of zones to a new policy.
However I purged the old policy and keys before doing the actual rollover. For
learning & entertainment purposes I've decided not to restore from backup but
to try to get through this (it's not a production environment).
$ ods-ksmutil key rollover --policy uvtonly --keytype ksk
The enforcer is reloaded but other than that nothing is logged.
$ ods-ksmutil key rollover --zone example.nl --keytype ksk
Works fine
root@metagross:~# ods-ksmutil key list -v --zone example.com
Zone: Keytype: State: Date of next
transition: CKA_ID: Repository:
Keytag:
example.com KSK dsready When required
04840543f5e3ffc7810245c1630f06c4 LocalHSM NOT IN repository
example.com KSK dsready When required
aa1442918ebcc61ac17b7e67aefa8a37 LocalHSM NOT IN repository
example.com KSK active 2012-04-26
16:40:01 7a4dd93a1fbc287dab40ab4b50e75ccd LocalHSM NOT IN repository
example.com ZSK active 2011-12-22
16:42:17 bb6af6c8fa3d84ac0a02d3f397c7c0b1 LocalHSM NOT IN repository
example.com ZSK ready next rollover
3ddd5e497198da5eddae217c2dd861fd LocalHSM NOT IN repository
example.com ZSK ready next rollover
9ab2bec08974d8e8f4fbf270278f9ebc LocalHSM NOT IN repository
example.com ZSK ready next rollover
27771ce6d3372a9a08201ded94b3708d LocalHSM NOT IN repository
root@metagross:~# ods-ksmutil key rollover --policy uvtonly --keytype ksk
*WARNING* This will roll all keys on the policy; are you sure? [y/N] y
root@metagross:~# ods-ksmutil key rollover --policy uvtonly
*WARNING* This will roll all keys on the policy; are you sure? [y/N] y
root@metagross:~# ods-ksmutil key list -v --zone example.com
example.com KSK dsready When required
04840543f5e3ffc7810245c1630f06c4 LocalHSM NOT IN repository
example.com KSK dsready When required
aa1442918ebcc61ac17b7e67aefa8a37 LocalHSM NOT IN repository
example.com KSK active 2012-04-26
16:40:01 7a4dd93a1fbc287dab40ab4b50e75ccd LocalHSM NOT IN repository
example.com ZSK active 2011-12-22
16:42:17 bb6af6c8fa3d84ac0a02d3f397c7c0b1 LocalHSM NOT IN repository
example.com ZSK ready next rollover
3ddd5e497198da5eddae217c2dd861fd LocalHSM NOT IN repository
example.com ZSK ready next rollover
9ab2bec08974d8e8f4fbf270278f9ebc LocalHSM NOT IN repository
example.com ZSK ready next rollover
27771ce6d3372a9a08201ded94b3708d LocalHSM NOT IN repository
root@metagross:~# ods-ksmutil key rollover --zone example.com --keytype ksk
root@metagross:~# ods-ksmutil key list -v --zone example.com
example.com KSK keypublish 2011-12-02
11:21:13 04840543f5e3ffc7810245c1630f06c4 LocalHSM NOT IN repository
example.com KSK keypublish 2011-12-02
11:21:13 aa1442918ebcc61ac17b7e67aefa8a37 LocalHSM NOT IN repository
example.com KSK active 2011-12-02
10:20:55 7a4dd93a1fbc287dab40ab4b50e75ccd LocalHSM NOT IN repository
example.com ZSK active 2011-12-22
16:42:17 bb6af6c8fa3d84ac0a02d3f397c7c0b1 LocalHSM NOT IN repository
example.com ZSK ready next rollover
3ddd5e497198da5eddae217c2dd861fd LocalHSM NOT IN repository
example.com ZSK ready next rollover
9ab2bec08974d8e8f4fbf270278f9ebc LocalHSM NOT IN repository
example.com ZSK ready next rollover
27771ce6d3372a9a08201ded94b3708d LocalHSM NOT IN repository
With a bit of patience I can get all keys rolled over and back to valid keys.
I wouldn't advise anyone to do this in a production environment, but it is
possible
to get out of this situation by using normal ODS commands.
All this just for your information.
--
Casper Gielen <[email protected]> | LIS UNIX
PGP fingerprint = 16BD 2C9F 8156 C242 F981 63B8 2214 083C F80E 4AF7
Universiteit van Tilburg | Postbus 90153, 5000 LE
Warandelaan 2 | Telefoon 013 466 4100 | G 236 | http://www.uvt.nl
------------------------------
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
End of Opendnssec-user Digest, Vol 30, Issue 2
**********************************************
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
