Moin! On 27.03.2012, at 17:19, Livingood, Jason wrote:
> I posted a –01 a short time ago > (http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01) and > listed this in open items for the next version. I may have some questions on > the best way to include that. Ok here are some comments on that: 1. While I agree that the use of negative trust anchors will be become less necessary as we get more mature deploying the technology I don't think it will become obsolete and should not be used in the future. As long as people are handling technology there will be error, so the ability to deploy negative trust anchors has to exist indefinitely. 2. We either should enumerate all the possible failures (which is hard I guess) or just reference the examples of zone administrator errors we already had (still hard, but probably doable). While nasa.gov was the most prominent there are others that happened before. And of course there are errors that only affect certain implementations, which may relate to yet not exactly defined handling of certain aspects of the protocol, or because of the way the application handles validation. We should also name these as possible reasons for Domain validation failures. 7. The example in the text should match the graph and we should maybe add some other TLDs to show effect on TLD negative trust anchors (we already needed those ;-), and that it doesn't affect any domain beside or above it. 8. Aren't negative trust anchors a configuration option of an validator implementation (they are named the same in my companies product and are called domain-insecure in another implementation). I think this paragraph should leave the management of these to the implementation, but should urge validator implementers to include such a feature, as AFAIK only two implementations have it now. Appendix B.: Yes we all have those purposely broke domains and we definitely don't want negative trust anchors on these. As a negative trust anchor is something an operator (human) has to deploy he certainly will look hard before he does this. So why not put an TXT record at the zone apex saying "This domain is purposely DNSSEC broken". Another thing that we maybe could include in this documents are steps that people should do to find out if a domain is broken because of an attack or an administrator error, although these may change as the bad guys read the document. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400 Redwood City, California 94063 [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
