[dns-operations] What would it take...
Edward Lewis
edward.lewis at icann.org
Wed Mar 11 18:45:12 UTC 2015
On 3/11/15, 14:19, "Doug Barton" <dougb at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150311/b2d0fc75/attachment.bin>
More information about the dns-operations
mailing list