It's an acceptable idea - certainly not a bad one. Adding security to an existing system will, inherently, make it more brittle. What ever can be done to soften the brittleness while retaining the basic need for security should be done for the sake of resilience and availability of the system being secured. (Security should never be the objective, it's a supporting actor in achieving a higher objective.)
The posed question is whether expanding the lifetime of a signature by "10%" is a good idea. All that can be objectively stated is that no cache poisoning enabled by this ploy has ever been detected. That's why I said it is acceptable and not bad, I didn't say it was a good idea in the sense we will never know. Data sets that validly fall into this 10% region may fall in to this state for reasons other than operator sloppiness, so the assertion that this encourages more sloppiness is not necessarily true. What it might do (in the sense I have no data to tell) is reduce support call volume, which is a significant benefit. From reading lists, talking to folks and watching operations, I have learned of more failed validations caused by hardware failures, disaster recovery mishaps and operational mistakes than other reasons, including "operator sloppiness" and malicious activity. So trimming failed validations by removing brittleness is a good place to start. I'll define "sloppiness" as failure to refresh signatures in time (or not automate that). There are a lot of other things that can go wrong despite attentive care, including clocks drifting, external events overrunning planned capacity, and so on. On Jan 18, 2013, at 10:06, Chris Thompson wrote: > > Is fudging the expiry times like that really a good idea? If all > all validators allowed a 10% overrun, DNS operators would just > get 10% sloppier and we would back where we started. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses.
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
