Folks, Thanks for your comments on the document. Olafur and I have prepared a -01 version, which I just submitted.
On Tue, 16 Jan 2007, Ed Lewis wrote: > What is a trust anchor? Is it a domain name or is it a specific key > at a domain name? The question comes up when you mention that it > should be a DR RR. Or should that be an RR set? It's both according to the definition in Section 2 of RFC 4033. I've made this more clear in -01. > This line is out of context: "DS RRs using SHA-1 (DS digest type 1) > are NOT RECOMMENDED." When talking about the format, don't dive into > contents as such "don't use" recommendations will change (grow) over > time. I disagree that mentioning SHA-1 is out of place here--the document's not that long. I've made the recommendation reference RFC 4509 to give some context. That document makes it clear that the we should move toward DS with SHA-256. Since this document is discussing DS records, a reminder about RFC 4509 is reasonable. > I don't know if priming, as described in section 3, is best done at > start up, but rather "on demand." As sparse as the DNSSEC portion of > DNS will be, I bet a DNSSEC-intense resolver will have a trust anchor > list a kilometer long. Good point. The document now recommends priming on demand. > The TBD at the end of section 3: I don't know that any document ought > to prescribe any actions (such as log errors) when inconsistencies > are found. That is a matter left to the implementations. The > document should explain the inconsistencies, but not dictate a > reaction. Local policy is still the trump card. The comments are there to promote a discussion. The purpose of this document is to give guidance to implementors, not dictate how an implementation must behave. Heaven knows we'd be in in better shape now if there had been a similar document giving guidance to authors of iterative resolvers 20 years ago. > The discussion on trusted update mechanism should be pulled. I think it's reasonable to give an overview of the landscape to put the discussion of trust anchor configuration in its broader context. We've re-ordered the section and removed specific product names. On Thu, 18 Jan 2007, Geoff Huston wrote: > The comment about truncation appears to be a martian, in that > truncation is neither defined nor referenced here and the reader is > left somewhat confused as to what is meant here. Point taken. I've added context. > On demand (or upon use) would be more logical in this context. Also > I note that somehow the document has changed gear and now we are > talking about DS RRs as trust anchors. What happened to DNSKEY RRs? I believe you have missed the point of the document, which is to recommend a standard format of DS RRs for specifying trust anchors in validating resolvers. I've attempted to make that meta point clear in -01. > I also would've thought that where inconsistencies are found between > the DS and DNSKEY values are found then they should not longer be > considered as viable trust anchors. Well, the document implies that by stating the positive rather than the negative: if priming succeeds according to the listed steps, the trust anchor can be used. I missed this comment of yours in the -01 revision, but can make the text more clear in -02. On Thu, 18 Jan 2007, Scott Rose wrote: > As for the text on rollover mechanisms: I don't think there will be a > choice for the majority of end systems. > Once the validator is written, it will most likely depend on the > implementors of the validator, and be very difficult for an end user to > change. Manual operation may be the only other alternative to whatever > in-band or out of band the validator implementation is built around. > And most will not care - once one way is chosen, it will probably be > used unless something forces a change. Agree; however, the document is aimed at validator implementors, not end users. Matt _______________________________________________ DNSOP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dnsop
