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: - 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. - 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:-) 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). - 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. 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. - 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". - 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. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
