question to the bind9 developers

[Jim Reid]

>>>>> "Robi" == Robi  <eris at nexus.hu> writes:

    Robi> Hi, I noticed, that on loading the config file, if a
    Robi> duplicate zone is found, bind reports a fatal error, and
    Robi> exits. I was testing 9.1.1., so sorry, if the newer version
    Robi> don't do this.

All versions of BIND9 refuse to run if they find an error in
named.conf.

    Robi> As I remember, bind8 did not take this as a fatal error,
    Robi> only reported it as a warning. Is there any reason to treat
    Robi> this as fatal?

Yes. It's simple common sense. If the config file is broken, it means
the administrator hasn't defined the name server's configuration
correctly. Therefore it's safer to refuse to run -- and so force the
administrator to fix the error(s) -- than have the name server operate
in an undefined, possibly dangerous, way that is known to be wrong. In
this case, no service is better than serving bad or wrong data. Do you
know of any other programs that operate correctly when given corrupt
or broken configuration files? Why should you expect BIND to be any
different?

BIND8's behaviour with broken named.conf files was and is wrong IMO. It
tries to work around any syntax errors, which generally creates worse
problems and inconsistencies for the name server. For instance, it
could mean the server incorrectly applies an ACL which was not defined
properly. That might allow access for unwanted guests or denies access
for permitted users while the DNS administrator is unaware of
this. For them, the server is running fine and applying the ACLs as
they thought they'd set them up. Even though it's not.

    Robi> I work for an ISP, so we have more people working on the
    Robi> config files.  Ocassionaly happens, that zones are written
    Robi> twice to the config.

So fix your procedures to prevent this from happening. This is a local
problem with your administrative processes and change control and
auditing procedures. Fix them. At the very least you should be running
named-checkconf on a new version of named.conf before presenting it to
the name server. This would identify the errors and give you a chance
to fix them before the name server is made to read the broken file.

    This>  This shouldn't be a problem in a case
    Robi> of a running named, but if we stop the server, or it crashes
    Robi> (happened in the past), we are unable to start it
    Robi> automaticly just because of the duplicated zones.

And quite right too. Does your C compiler generate correct working
code when the source code -- in effect a configuration file --
contains syntax errors?

    Robi> So my question is: Was it not a good behaviour to take the
    Robi> first occurrence of a zone as correct, and only warn about
    Robi> the rest?  If you don't mean to change this, could you give
    Robi> me a clue, where should I change this in the source?
    Robi> (server.c:1869?)

Please think about this. Kludging the name server to patch over
failings in your administrative processes is not a very sensible thing
to do. First of all, you create for yourself a long-running problem of
software maintenance and documentation. Every new version of BIND9 or
patch you get will need to be changed to have your local kludge
applied, assuming it existed. This will be error prone and time
consuming. And you need to document it: what if a new colleague
downloads and installs the newest version of BIND? Who's going to know
about and support that kludge? Secondly maintaining and applying your
kludge will be more expensive in time and resources in the long run
than fixing the actual problem. Thirdly, it does not address the
underlying problem: your broken administrative processes are still
broken.