On 3/11/15, 14:19, "Doug Barton" <do...@dougbarton.us> wrote:
>I think it would be Ok to put up a large, difficult to ignore warning >that the user is about to do something painfully stupid, sure. How much >farther than that to go is an exercise for the implementors. To go a little deeper into what I witnessed up close. Had we had the option of having the server log a problem or even launch an email, we could have handled the configuration. After the post-mortem I was talking to a colleague who said he too had requested a safety breaking system from some tool makers and was "laughed off." Take what I am saying here as umpteenth-hand retelling of a fib because we never bothered to make the same request, we just rolled our own script (because we had the staff available to do this, although they weren't ordinarily dedicated to this function). >And the issue of non-BIND authoritative servers not doing their own >iterative queries is a red herring. I would be astonished if those >systems were not on a host that had access to a resolver. It's not a question if this can be done. It's a question of how can this be packaged for operations. To sum up something - one thing I learned during my stints in operations - many of the assumptions held by protocol engineers and architects about how a protocol is put to work are far from reality. (Not that the engineers and architects are wrong in their approach but the assumptions are wrong.) I don't mean that operators are using bailing wire and duct tape to reap huge profits, but the approach to sound operational practices sometimes runs counter to what I learned to be sound in the lab.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
