Sanity Check on Enterprise Architecture

[Kevin Darcy]

Eric Berg wrote:
> I'm seeking some advice on how to architect a consolidated DNS 
> infrastructure for my company.
>
> We are moving toward consolidating our DNS infrastructure by 
> implementing Sauron (OSS DNS mgmt system, CLI + Web) for management, and 
> by putting a single set of master bind servers in place from which all 
> other network-specific servers would perform zone transfers to get their 
> data.
>
> The other option that we're looking at, and that would also serve as an 
> interim step to the solution in the previous paragraph, is to create 
> zone configurations for each of our network-specific bind servers on an 
> individual basis and push them to the servers from a central point.
>
> Among the reasons that we're looking to implement a set of master 
> servers which would contain all of the DNS information for all hosts in 
> all of our networks are the following:
>
>     * We are trying to consolidate the management of DNS as much as
>       possible.
>     * We occasionally connect previously isolated networks and then need
>       to make hosts in each network resolvable to one another
>     * It cuts down on the amount of back-and-forth (things that can
>       break) by doing zone transfers instead of creating jobs to push
>       zone files on a daily basis.  It seems to me that once the data is
>       in bind, the zone transfer would be the cleanest way to populate
>       the other bind servers.
>
>
> It's a high-level question, but I'm hoping that anyone with experience 
> managing multiple DNS servers (on the order of 30 or more) with about as 
> many subdomains can provide some insight into how to think about this 
> problem as well as any gotchya's we might run into.
>
>   
The zone-transfer mechanism is the most straightforward way to replicate 
zone data between BIND instances, and with the advent of IXFR and/or 
TSIG-based-authentication, quite efficient and/or secure, respectively. 
But its main limitations are:
a) it only transfers zone data, not any kind of configuration metadata
b) you can't really control the replication schedule with a high degree 
of specificity, unless you're willing to waste a lot of bandwidth

Some other, "out of band" method of replication can address these 
issues, and such are often more appropriate, depending on your requirements.

For the record, we use both zone-transfer and out-of-band methods of 
replication, in different parts of our enterprise. Where zone-transfer 
is used, we have some homegrown scripts in place to maintain the slave 
named.conf files, adding or deleting zone definitions as necessary, 
using some local conventions and rules.

                                                                         
            - Kevin