At Fri, 24 Apr 2015 23:59:22 -0400, Warren Kumari <war...@kumari.net> wrote:
> So, I have gone back through previous mail and it seems that this was > the only email that got missed. > Anyway, it seems that other folk also made similar comments, and so, > by -03, we had addressed almost all of them. > Apologies again for not seeing and responding to your mail. No worries, and thanks for addressing these so quickly. > > I agree with the sense of the statement, but specifically how can > > the operator confirm that it's misconfiguration? [...] > > My last update (a few days ago) included inserting an Appendix that > covers some of this. It is somewhat rough,and more conversational in > tone than if it were in the main part of the draft, but I think > strikes a nice balance. Do you mean Appendix B? It certainly looks good enough to me to address this point. > > - Also on that sense and this one in Section 8: > > > > Use of a > > Negative Trust Anchor MUST NOT be automatic. > > > > Again, I agree with the sense, but I wonder whether players like big > > ISPs or public DNS services are really willing to follow the > > suggestion of human intervention and/or ban of automation. [...] > > For these recommendations to be really effective rather than just > > ignored, I think we need to provide some more information, e.g., > > statistics on how often these events are happening in actual > > providers that use NTAs, show example of operational practices > > (which I guess would include some level of automation). > > We don't really have anything published, but I spoke with the person > who deals with these and it is around once per quarter (it has slowed > down). This year we have only done it once - for the .KE keyroll event > ( thread here: > https://lists.dns-oarc.net/pipermail/dns-operations/2015-March/013060.html > ) Okay, then I'd suggest adding some brief note on this point. One possibility would be to add something like this to the end of the first paragraph of Section 2: [... prior to implementing the Negative Trust Anchor.] Involving trained technical personnel is costly, but operations experiences so far suggest that this is a very rare event such as around once per quarter or even less. (and if we can include a concrete reference, do that) > > - Also on Section 8: > > > > Finally, a Negative Trust Anchor SHOULD be used only in a specific > > domain or sub-domain and MUST NOT affect validation of other names up > > the authentication chain. > > > > I think it would also help clarify that the deepest anchor should be > > used, whether positive or negative. [...] > > Actually, an NTA stops validation at that point, which includes things > under that. > Here is text (which probably changed after your comment: > "This Negative Trust Anchor can potentially be implemented at any > level within the chain > of trust and would stop validation from that point in the chain down." > > This gave us the needed behavior when .ke broke... > Yes, turning off validation for an entire ccTLD is a big hammer -- > but, it is better than turning off validation for *everyone*, or just > leaving an entire country unresolvable for many hours.... Hmm...first, if this is really the intent, I'd suggest revising Section 8, too, to state it more explicitly (also possibly with an example). Secondly, does it make most sense? If we have a manually configured positive trust anchor for "good.example.ke", isn't it better to still use it for anything on or below that, but skip DNSSEC validation for everything else on or under .ke? At least this shouldn't mean "turning off validation for *everyone*" or "just leaving an entire country unresolvable for many hours", so such arguments don't seem to be a reason for not doing this. > > - Section 10 > > > > validates can have security considerations. It is therefore > > recommended that NTA implementors should periodically attempt to > > validate the domain in question, for the period of time that the > > > > I wonder whether this 'should' may better be SHOULD. Not a strong > > opinion, but it seems to be similar to other recommendations using > > the capitalized keyword in Section 8. > > So, I went to go make that change, and discovered it is already a SHOULD. > Sometime between when you wrote this mail (11/14) and version -03 I > incorporated this change. It's still a "should" in the 04 version: validates can have security considerations. It is therefore recommended that NTA implementors should periodically attempt to validate the domain in question, for the period of time that the Negative Trust Anchor is in place, until such validation is again successful. (from https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04) > > - Appendix A: not intending to endorse a particular implementation(s), > > but I'd suggest clarifying which specific implementations support > > various recommendations of the draft. For example, BIND 9 is quite > > diligently follow it while (if my memory is correct and it's still > > the case today) unbound's support is quite primitive and you cannot > > specify timeouts. I think it's important to avoid allowing lazy > > operators to just configure some NTAs and forget them. It would > > also encourage "lazy developers" to support full recommendations > > sooner. > > I'm a little uncomfortable doing this. This is still only a draft, and > vendors will continue to add support when it gets published as an RFC. > I'd hate vendor X to add support for all the rest of the requirements, > but have customers discriminate against them because the RFC didn't > predict that... Okay, then I won't push that. But I'd like to suggest adding some more general note like this to Appendix A: Please note: These are simply examples - nameserver operators are expected to test and understand the implications of these operations. Note also that some of available implementations may not implement all recommended functionality in this document. In that case it is advisable to request the developer or vendor of the implementation to support the missing feature, rather than start using the incomplete implementation. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
