This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[dns-wg] KSK lifetimes
- Previous message (by thread): [dns-wg] Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories
- Next message (by thread): [dns-wg] KSK lifetimes
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jim Reid
jim at rfc1035.com
Fri Feb 5 15:58:12 CET 2010
On 5 Feb 2010, at 14:18, Ralf Weber wrote: > With the root planning for much longer time frames on KSK rollovers > maybe RIPE NCC should think about increasing it's KSK life times. Ralf, I don't follow you. Could you please explain why the NCC should increase the lifetime of its KSKs? Just because "the root's going to have long KSK lifetimes" isn't an answer. :-) As I'm sure you know, there are all sorts of trade-offs that have to be made when choosing key sizes and rollover intervals. And every zone has its own set of requirements and operational criteria. So what's good for one zone may not be so suitable for another. I'd like to hear the reasoning why key management by the NCC should be the same as that for the root, particularly if it goes beyond the usual "if it's good enough for the root, it's good enough for me". FWIW, I regularly make that case when people ask me what DNS software they should run. What I do think would be helpful is a document explaining how the eventual parameters were chosen and the trade-offs/thinking that went into those choices. This is needed for DNSSEC generally as well as for the root zone and the NCC's bits of the .arpa tree.
- Previous message (by thread): [dns-wg] Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories
- Next message (by thread): [dns-wg] KSK lifetimes
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]