administering 1,000 zone files

[Jim Reid]

>>>>> "Michael" == Michael van Elst <mlelstv at serpens.de> writes:

    Michael> The named.conf on the slaves is split into a general
    Michael> section and many include files.

This is not a good idea. Having "many include files" is a recipe for
needless complexity and brittle DNS administration. If this works for
you, then fine. However if I was looking after ~200K zones on some
servers, I would not do this with include files at all.

    Michael> Each include file held the zone statements for a sorted
    Michael> subset of zones with a specific prefix (i.e. all zones
    Michael> starting with 'aaa' to 'aez' or similar).

Yuk! Why make needless work for yourself determining which zone{}
statements go in which include files?

    Michael> The split is necessary because the whole config is
    Michael> several ten megabytes that you do not want to read and
    Michael> write for every change.

Yuk! This is pointless. If you force the server to reload, it has to
re-read all these include files -- what if one of them gets lost or
corrupted? -- and check the referenced zone files are current. So you
needlessly make more work for the name server and yourself ploughing
through a named.conf file split across say 20 1 Mbyte include files
than there would be parsing a single named.conf file of 20 Mbytes.
Adding or removing zone{} statements from named.conf implies that the
name server has to read all of its configuration -- ie the whole file
-- so that it knows what is the current set of zones to serve.

If you're talking about hundreds of thousands of zones and 20 Mbyte
named.conf files, you really should be using a database to keep track
of the sheer volume of data and having an SQL script generate the
config files from that database.

    Michael> Adding or deleting zones on the master triggered ssh
    Michael> sessions to each slave that ran a small program to
    Michael> add/delete zone statements to/from the appropriate
    Michael> include files and set a flag. The flag was polled
    Michael> regularly to reload the nameserver.

Yuk! What if that small program fails? Wouldn't it be better to
generate the configuration data in one place? That way, you wouldn't
have to worry about the prospect of configurations on servers drifting
from what was intended because of local, possibly transient errors.

    Michael> The polling time is offset individually for each slave to
    Michael> avoid reloading (which means an interruption of service)
    Michael> for a whole nameserver set.

Yuk! This is bad. It means there are (long?) windows where the name
server configuration on disk is not the same as that as the active
configuration in memory. Worse, the on-disk configuration is more up
to date than what the server is currently using. It can also mean lame
delegations because the master server (say) knows about a newly-added
zone while one of that zone's slaves knows nothing about it. Staggering
server reload/reconfig times is all very well. However that brings
other problems.