DNS Administration Automation

[Kevin Darcy]

Well, first of all, there is a separation in BIND between named.conf maintenance and zone-data maintenance.

For zone-data maintenance, I would recommend looking at Dynamic Update to maintain your DNS data. It avoids a lot of the pitfalls associated with zonefile-based DNS maintenance tools (e.g. locking against concurrent
write access to the zonefile, minor bugs causing syntax errors and zone rejection, neglecting to increment serial number, etc.), and if you ever decide to integrate your DNS with DHCP or (shudder!) Windows 2000
Active Directory, you'll have to turn on Dynamic Update anyway, upon which you will discover that the *only* reasonable way to maintain a Dynamic Update-enabled zone is through Dynamic Update. Many folks find that
their zonefile-based maintenance tools become obsolete in such a scenario.

Dynamic Update-based maintenance also has the advantage that your maintenance processes can run on a totally separate box than your DNS server(s). (For security, you'd probably want to TSIG-sign your updates if you
make such a separation). My homegrown maintenance system, for instance, is web-based, and I'd rather not have to run a web server on the same box(es) as the DNS server(s), nor would I relish having to set up some
sort of trust relationship(s) between the web server and the DNS server(s) so that they could run remote commands or shuttle files between each other.

(Unfortunately, all of my stuff is technically DaimlerChrysler intellectual property and it would be next to impossible to get the bureaucracy around here to authorize a "release". But I could give general advice to
anyone wanting to re-invent the same wheel.)

A third alternative, in addition to zonefile-based maintenance and Dynamic-Update-based maintenance, is the use of a backend database to store your DNS data. This is the approach used by many commercial
DNS products, for instance (if they are an integrated DNS/DHCP product, they often store the DHCP data there also). I've never cared much for this approach. Do I really want to maintain an instance of Oracle or
Sybase just for my DNS data? Seems like overkill. And what if the database gets out of synch with what's in DNS (shouldn't be an issue if you use BIND 9's capability of loading zone data directly from a backend
database, but it's a big issue if you use BIND 8 or anything other than the standard mechanism for getting BIND to load from a database)? I see no reason why a separate database should be necessary -- with all of
the resources it takes, including the human resources necessary to maintain it -- when DNS is perfectly capable of maintaining its *own* database through Dynamic Update. Eliminate the middleman, I say. Not to
mention, what are you going to do if you ever want to integrate with DHCP and/or Win2K (as mentioned above)? Propagate the Dynamic Updates *through* the backend database? That's just ugly.

When constructing a zone-data maintenance system, one thing to strive for is to put as many "sanity checks" as possible into the update process. A user shouldn't be able to delete a name that doesn't exist, or add a
name that already exists, for instance (although you may wish to allow the creation of "round robin" names, i.e. names which resolve to 2 or more address records -- this, however, should be a conscious choice by the
user since round-robin names tend to be much rarer than mistyped addresses or other input mistakes). The failure of a sanity check should result in *immediate* feedback to the user, so that they can double-check the
input and correct it. The more sanity checks you put in, the more likely you'll avoid the syndrome of simple human errors, when accumulated over time, turning your DNS database into a dungheap. This imperative
applies no matter *what* the "backend" maintenance system happens to be, i.e. zonefile-based, Dynamic Update-based, SQL-database-based or whatever. In my maintenance system, for example, there is a middle component
sandwiched between the web-based frontend and the Dynamic Update-based backend, which a) checks the user's authorization to make that particular change, b)  sanity-checks the update in various ways, and
c) automatically generates reverse-record updates (where necessary) in parallel with the forward-record changes -- these "subsidiary" updates are also sanity-checked and auth-checked. By the time the data gets to
the Dynamic Update stage, it's already been thoroughly verified and confirmed. Just for good measure, I then use Dynamic Update prerequisites for an extra level of safety (since data could theoretically have changed
in between the time the sanity checks were done and the Dynamic Update issued).

As for named.conf maintenance, I'm afraid I can't help you much there. Traditionally, we add zones fairly infrequently (we are, after all, not an ISP or hosting company!), so I haven't put a lot of effort into
automating the process. For our internal DNS, I'm still in the habit of manually adding the zone definitions to named.conf on the master server (but I do have a script running on all of my internal slaves which will
automatically detect the addition and configure it into the local named.conf). For our external DNS, this has traditionally been an all-manual affair, on both the master and the slaves, but I'm working on a
mechanism to automate it.

                                                                                                                                            - Kevin

Frank Tanner III wrote:

> Does anyone have any idea where I can get information about, or the actual scripts themselves for DNS administration automation written in Perl?
>
> I am needing one script or several scriptlets to create zone file (based on a template if necessary), add to zone files, delete from zone files, add zones to named.conf, remove zones from named.conf and the like.
>
> Any information you can give me would be greatly appreciated.