On 1/21/2010 1:29 PM, Andrew Sullivan wrote:
On Thu, Jan 21, 2010 at 04:14:03PM -0500, Edward Lewis wrote:
I'm finding this discussion enlightening and interesting.
Me too. I also think that discussion of exactly this sort belongs in
the advice we give to operators. Understanding the trade-offs and the
reason for them is exactly what makes for selecting the right policies
given the operational considerations of the environment in which one
is working. I don't think there's one answer for this question,
because what is right is surely related to other considerations.
Andrew you are right here - its not a matter of what is right - its a
matter of "how to" and that's the key I think.
For instance, despite what David says downthread about operational
realities and exercise, such exercise is a complete waste of time if
the person who does the work is different every time (as might well be
the case under a lot of outsourcing contracts).
Hmmm - let me push back. Not necessarily - the real issue is the proper
evidence of the functioning of the DNSOP is the key here. The problem is
that DNS log data sucks now. It was designed by techies for debugging
and not for evidence which is what it needs to be specifically. That
said - the real issue is how chain of custody is maintained and proven
after the fact since in the real time if the DNS doesnt work or works
wrong theorhetically the user is bright enough to catch that, but
longer term - how to you prove three years in the future that the
resolutions done today actually happened and were done correctly.
From my point of view this isnt about just working right in the present
its about working right in creating enduring evidence of that operation.
Todd Glassey
In that circumstance,
Paul is probably right: the risk of blowing the key roll outweighs the
benefits of practice.
One also worries a little that many operations people (me included) so
often think "you need to practice this" includes "in production".
(But I haven't worked many places where I've had a real, true,
complete copy of my production systems just for running fire drills.)
A
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.432 / Virus Database: 271.1.1/2636 - Release Date: 01/21/10
07:34:00
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
