Inline below (and some proposed text for you to give feedback on). - Jason
On 2/17/13 10:19 AM, "Ted Lemon" <ted.le...@nominum.com> wrote: >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? The operator of a recursive resolver that is performing DNSSEC validation configures this on the local recursive resolver(s) they control/administer. >This seems very labor-intensive and failure-prone. It can be labor intensive, but failures in the configuration of the resolver carries the same risks as any other configuration change. We partially scripted it since we have found a need to configure NTAs more than a few times (meaning we don't manually touch each resolver but setting up and removing the NTA is not automatic based on validation failures). >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. Yes, that's pretty much the case. It is a good learning experience for authoritative administrators. Only in a subset of such failures have we used a NTA, depending on the circumstances. >> 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? I suppose so - it is a policy on a caching resolver, though that could be operated by an ISP, DNS ASP, or enterprise. So if you have your own resolver and you are validating then it should not have any effect on you. >> 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. They are definitely teachable moments. But a key concern is for the end users of a validating resolver, who may not know or care about what validation is and just know that they cannot access some domain. They blame the operator of the validating resolver (and impose costs upon them), rather that the authoritative domain. I hope that changes over time. >> 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? It was a question I received from a few folks in response to earlier versions, so I thought it worthy of flagging it for a discussion. >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. Understood. >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. Makes sense to me. So if I added very explicit text to the effect that "Negative Trust Anchors MUST NOT be used by host-based DNSSEC validating DNS resolvers; this practice only pertains to network-based DNS recursive resolvers that multiple hosts query." would that do it? - Jason >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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
