On 12/16/20 11:36 AM, Reindl Harald wrote: > > > Am 16.12.20 um 18:26 schrieb Gregory Sloop: >> This isn't, IMO, very useful as a response to the OP. > > let that decide the OP > >> To sum up the response; "It's better to never fail!" >> >> Yes, that seems pretty obvious. It *would* be better to never fail. Way, way >> better. >> But the big problem in life is; We're always failing! Dammit! >> >> So, learning how to gracefully fail, and understanding what happens and why, >> when something fails, is pretty important to achieve the outcome of; "Not >> failing quite so catastrophically." > > loading a invalid zoen file is far away from "fail geraceful"! if a comozter > don't understand the input fully it's not supposed to guess > >> So, while I don't have helpful knowledge to impart to the OP, I think I can >> say that giving the advice of "don't fail" doesn't seem very helpful. > > where did i give the advice "don't fail"? > please read my repsonse again! > > * the zone fails on the master > * the zone is still available on the slaves > * so the error isn't fatal > * but you recognize your mistake > > what happens when the error is in the line of the MX record and named would > say "well, it's only one line, we still have the zone but no longer an MX"? > > it would lead to a *fatal error* for the behavior of the whole zone, even if > *all* or your nameservers go down it would be better because every delivering > MTA would just queue the messages in case of a SERVFAIL > > without the MX the would go to the A record of the zone which is in most > cases simply the wrong destination >
I agree that in a master-slave topology, your argument makes sense. I this case, the server was a singleton responsible for a small virtual private network within a much larger one. So. when the server failed to start, the client had NO DNS for that subnet. -- ---------------------------------------------------------------------------- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
