On Aug 30, 2012, at 10:57 AM, Joe Abley <joe.ab...@icann.org> wrote: > I suspect an increasing proportion of operators doing DNSSEC do not care how > to do rollovers, in fact. They care that the software they're using to manage > keys and sign things is doing the right thing.
Good point, yes. > The pragmatic long-term view is, I think, that this document doesn't give > advice to operators so much as advice for those implementing DNSSEC signers. Yes and no. Many of the aforementioned operators are probably going to be asked "are you sure that the software you are using follows the specifications" and those operators are going to look for the vendor's checkmark next to "the right" RFC number. If so, this argues strongly for fewer RFCs for the checkmarks to match to. > I am not suggesting that operators don't care what happens under the hood, or > that vendors don't care about operators. But I think the inference that this > is advice to heed before you dive in and perform rollovers by hand is > short-sighted. The focus ought to be advice that can be converted easily into > good code. Yes. Here, "good" should also mean "code whose logs can be followed by someone who hasn't read the RFC, if needed". > I am not a developer of DNS software, and hence don't feel well-placed to > review the draft from that perspective. However, my feeling (based on words > absorbed inadvertently from people who are developers) is that the document > would better serve that perspective if it presented robust state machines and > algorithms for arbitrary rollovers. > > As an operator I would very much like trustworthy tools that could take my > desire (say) to roll a KSK from an N-bit alg-A key to an M-bit alg-B key and > show me the timing constraints for that rollover to be completed, so I can > plan the exercise, accommodate any expected delay in DS publication in parent > zones, keep my relying parties informed, and hopefully have robots execute > the actual zone changes for me. Working all that out by hand (and making the > zone changes manually) based on the advice in dnssec-key-timing is > error-prone. Yes. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
