On Feb 17, 2013, at 10:37 AM, "Livingood, Jason" <jason_living...@cable.comcast.com> wrote: >>> 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.
So maybe a better way to state your point at the top would be that setting up the NTA is something that validating resolver operators do, possibly in cooperation with the operators of the zones requiring the NTA, because this is what's expedient, and NTAs are all about what's expedient. :) > 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? I think that's a valid thing to say, but what I'm more concerned about is specifically saying what would be different in a response from a validating resolver that implements NTAs in the case of a zone with an NTA, versus a caching resolver that does not validate, for the same broken zone. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
