On Wed, Nov 5, 2014 at 2:31 PM, 神明達哉 <jin...@wide.ad.jp> wrote: > I've read the draft. Overall it's pretty well written. I also > personally support the idea of NTAs; although I see its side effect > and the possibility of abuse, the draft seems to do its best to > explain the implications and avoid abusing. > > Here are some specific comments on the 01 version:
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. > > - Section 8: > > Technical personnel trained in the operation of DNS servers MUST > confirm that a failure is due to misconfiguration, as a similar > breakage could have occurred if an attacker gained access to a > domain's authoritative servers and modified those records or had the > domain pointed to their own rogue authoritative servers. > > I agree with the sense of the statement, but specifically how can > the operator confirm that it's misconfiguration? Cases like sending > a bogus answer from an off-site attacker may be easier to > distinguish (e.g. repeat the same query to the authoritative server > by hand, maybe over TCP), but I guess such cases as compromised > authoritative servers can be quite difficult to distinguish (or > maybe impossible in some cases) from mere misconfiguration. It > would help if it (maybe in the appendix) can provide example > diagnosing techniques for such cases. 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. > > - 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. In fact, > with my biased impression it's quite surprising to me if Google > really allows involving humans, not machines, in such cases:-) Yup. NTAs really are an unusual event (think hbonow.com dnssec debacle, not kumari.net forgot to roll keys) - it requires humans to do stuff. > 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 ) I think Comcast might have more public statistics that they can share. > > - 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. So, in the example diagram, if > there's a (positive) trust anchor for sub.zone1.example.com, the NTA > for zone1.example.com won't apply for sub.zone1.example.com, > www.sub.zone1.example.com, etc (is my understanding correct?). It > may look quite obvious, but I think it's worth noting. 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.... > > On a related note, there are some corner cases which may also be > worth noting: queries for DS or DLV (or anything similar to that). > So, for example, zone1.example.com/DS should still be validated even > if there's an NTA for zone1.example.com. Again, this might sound > obvious, but I think it's worthwhile. > > - 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. > > - Section 12: a minor point, but it may be better to use "server > failure" instead of SERVFAIL: > > this or other similarly intentionally broken domains should fail to > resolve and should result in a SERVFAIL error. > > Even though this is a "de facto standard" technical term, I know > some people hate it to be used in public documents as it's an > "implementation-specific jargon". > Thank you, fixed. > - 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... I *think* that having some usage examples (from the vendors who supplied them) is useful, but I'm often uncomfortable with implementation level reports (unless that is the sole purpose of a document and it makes it clear that this is ass of time YYY). If folk provide text (or feel very strongly) I'm happy to revisit... Thank you, I have just posted a new version. Apologies again for not having responded to your comments earlier. W > -- > JINMEI, Tatuya > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
