annoyances

Jim Reid jim at rfc1035.com
Tue Aug 6 01:17:07 UTC 2002


>>>>> ">" == those who know me have no need of my name <not-a-real-address at usa.net> writes:

    >> which i think is foolish; bind should start if at all possible.
    >> the configuration file was syntactically correct.  at most the
    >> duplicated zones shouldn't be served.

That's your opinion. However in this case the config file was broken,
even though it was syntactically correct. The safest and smartest
thing to do when a config file is known to be wrong is report the
errors then fail safe and refuse to run. This is simply the right
thing to do. This approach is far, far better than trying to
second-guess what the DNS administrator meant to configure. And
probably getting that wrong. Or, worse, have the name server execute
in an undefined state. Does any other software continue running when
it finds its configuration file(s) are broken? Expecting named to do
that is a bit like expecting a compiler to generate the code you meant
to write but didn't.

Taking the above example, just rejecting the duplicate zone{}
statements would be bad. It would lead to lame delegations unless the
broken config file was fixed. That would be unlikely to happen because
the name server would still be running. So the hostmaster might think
everything is OK (because named is running) and not bother to check
the logs for errors. Treating a broken named.conf as a hard error
makes sure the problem is noticed immediately. And presumably gets
fixed before even worse bad things start to happen.

Oh and BIND9 comes with named-checkconf, so there's no excuse for
presenting a broken config file to the name server.


More information about the bind-users mailing list