On Feb 17, 2013, at 9:57 AM, "Livingood, Jason" <jason_living...@cable.comcast.com> wrote: > A Negative Trust Anchor should IMO be locally configured and not rely upon > any external validation or sourcing for the Negative Trust Anchor(s).
What's local? How does the local authority know to set a negative trust anchor? This seems very labor-intensive and failure-prone. Generally speaking, from what I've heard, when bad DNSSEC configurations happen, there's a back-and-forth with the administrator of the broken zone. But this is all third-hand, at best--if your experience has been different I would like to hear about it. > It basically tells the recursive resolver to not perform (skip) DNSSEC > validation on a specific domain name for which a Negative Trust Anchor has > been locally configured. Since it would be locally configured it should > not rely on the CA infrastructure at all, and all of the inherent issues > of that - or need to rely on certificate revocations and whatnot. So this is assuming that validation is occurring on a caching resolver run by the provider, and that negative trust anchors simply won't have any effect for hosts that do their own validation? > Also, if a domain has already messed up their DNSSEC signing operations, > it is unlikely they'd figure out a way to properly sign a Negative Trust > Anchor or anything else for that matter. I think this is wrong: the incidents I've heard of were mistakes, which resulted in teaching moments for the people who made them, which resulted in them learning how to do it right. It's not like you're going to get a broken zone signature if you are completely ignorant, because if you are completely ignorant you're not going to try to sign the zone. > I hope that helps, assuming of course that I understood the question > relating RFC5280 to this I-D. :-) It does help--thanks! On to your response to Joe: > 5. The DNSOP WG should discuss how to assess when critical DNSSEC > deployment mass has been achieved so that this is no longer a common > practice. Who cares? If you publish this, you have to assume that whatever you recommend here is going to continue to be used well beyond its intended lifetime. Of course, e.g. Comcast will do the right thing, but this won't just be used by Comcast. I think that if you acknowledge that host-resident validating resolvers are not going to support negative trust anchors, this is a non-problem, since the rise of host-resident validating resolvers, which I think is inevitable in the long run, will automatically obsolete this work. However, if you do decide to rely on this, it's probably worth talking about what that obsolescence path will look like, since an NTA in the provider caching resolver may produce different results on the host-resident validating resolver, as you mention in point 6. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
