Algorithm rollover - OOOOPS!!!

[John]

On 1/12/2015 3:28 PM, John wrote:
> On 1/12/2015 10:48 AM, Viktor Dukhovni wrote:
>> On Mon, Jan 12, 2015 at 09:29:59AM -0500, John wrote:
>>
>>> This may be the wrong mailing list but I cannot find another concerning
>>> DNSSEC  general.
>> Note, this list does not have very many subscribers as yet (just
>> 20 at present), and it seems you're posting from a different addres
>> than the one you subscribed with (you've left off the address
>> extension) so the list moderators have to manually release your
>> posts.
>
> That's what comes of trying to be cute. I was trying to make life 
> easier for myself and avoid having create a filter.
>
>>> When I originally setup DNSSEC I used the RSASHA1 algorithm as this 
>>> seemed
>>> to be the only one that could be used with NSEC3.
>>>
>>> However, further reading (and/or changes in DNSSEC) would indicate the
>>> RSASHA256... can also be used with NSEC3.
>> Yes, algorithm 7 vs algorithm 8.
>>
>>> As a result I would like change algorithm.
>> Note that, for example, the .org zone is also using algorithm 7.
>> You're in good company.
>>
>>> 1) delete the keys that have been published including the .ca (? 
>>> forgotten
>>> tech term), publish new keys for the site and wait for the dust to 
>>> settle.
>> The correct way to do algorithm rollover in DNSSEC is:
>>
>>      * First include additional keys in your zone (publish DNSKEY
>>        records at the zone apex for both algorithm 7 and 8).
>>
>>      * Wait a few TTLs after all the secondary nameservers also have the
>>        new keys.
>>
>>      * Publish additional DS records matching the algorithm 8 KSK via
>>        your registrar.
>>
>>      * Wait a couple of parent zone TTLs.
>>
>>      * Delete the algorithm 7 DS RRs.
>>
>>      * Wait a few more parent zone TTLs.
>>
>>      * Delete the algorithm 7 DNSKEY records from the zone apex.
>>
>> The important invariant here is that all times each DS record from
>> the parent zone unexpired in any resolvers cache or served by the
>> parent zone must match some DNSKEY at the zone apex unexpired in
>> that resolvers cache or served by the zone's nameservers.
>>
> Which is what I thought.
>
Well I tied it .........!/!!/***
I don't know what I did wrong but at some point the algorithm 8 KSK 
became a ZSK  and things went downhill from there real fast.
In the end I decided that I had lost control and that as nobody could be 
relying on my DNSSEC info that a tear-down and rebuild was required.

I obviously screwed up, as I said I am not sure the what, when or how!
My only advice to anybody thinking of doing this is be very cautious. I 
would suggest setting up a test server (if you have the resources) and 
working upon that. Then once everything looks OK switch it to live.

-- 
John Allen
KLaM
------------------------------------------
As every cat owner knows, nobody owns a cat.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4268 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.sys4.de/cgi-bin/mailman/private/dane-users/attachments/20150117/652219aa/attachment.bin>