On 2013-02-17, at 09:57, "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). I hear you, but I'm not sure why you think so. If I was running a farm of validators inside an ISP network and I didn't already have my configuration control centralised and automated, being able to publish a single zone for internal use which encapsulated the policy does not seem like a bad option for keeping them all consistent. > 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. The use case here is not people who have messed up signing their zones publishing an NTA; it's validator operators who need a convenient way to share their validation policy. So, to spell it out: - hopcount.ca's signer explodes (or something else happens such that hopcount.ca is badly signed) - since hopcount.ca is such a popular domain for Comcast customers, Comcast DNS engineers take the time to discover that the validation failure for that zone is in fact due to an operational problem and not an attack - Comcast adds a hopcount.ca.nta.comcast.com zone, which is signed - Comcast's validators pick up the NTA from that zone and configure themselves accordingly Precisely what mechanism is used for that last part needs discussion, if people think that this kind of NTA distribution mechanism is worth exploring. It could be a crude mechanism like "tail the validation failure log, look up hopcount.ca.nta.comcast.com, if there's something there reconfigure unbound accordingly" or it could be something more integrated with the validator, so that unbound does the same work internally. Thinking ahead (and making assumptions about how much disgust people are feeling right now at this idea) I'd be in favour of an NTA being encoded with some timers to help ensure that NTAs are temporary. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
