[dnssec-deployment] some observations about .SE's DNSSEC

Blacka, David davidb at verisign.com
Tue Sep 25 19:03:20 EDT 2007


Patrik Fältström wrote:
> Another thing btw, that I saw the other week when I was forced to do an
> emergency key rollover... Yes, I knew this, but experiencing it is
> something different.

Ah, when theoretical pain becomes actual pain...

> I had to change the KSK asap. The problem of course was that the TTL of
> the existing KSK and DS in parent zone was longer that what I wanted (in
> this case the DS).

This is certainly an argument for giving DS RRsets small TTLs.  Or
letting the customer dictate the DS TTL (up to a point).

> This in turn lead to the conclusion that (unfortunately) the design of
> DNSSEC via the DS give no redundancy part from pre-publishing the "next
> KSK". Redundancy we for example have with multiple NS records.

You can have multiple DS records, so I don't see how this is a problem
with the design of DNSSEC or DS.

> I.e. DNSSEC and the DS give in many cases one and only one link to the
> child, and if that breaks, well, it is broken.

It is an operational choice to only have one DS, one based, no doubt, on
the assumption that having to do an emergency rollover is a rare event
when compared to server failure.

-- 
David Blacka                          <davidb at verisign.com>
Sr. Engineer    VeriSign Infrastructure Product Engineering

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5033 bytes
Desc: S/MIME Cryptographic Signature
Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20070925/c1dda5be/attachment.bin 


More information about the Dnssec-deployment mailing list