Thanks for the reply. So instead of creating the zone from scratch and
HUP'ing named, apply the static entries (from the database) using nsupdate
(or similar)? I wouldn't mind having a look at your script if you don't

Assuming a database of 30,000 hosts with various DNS records (PTR, CNAME's
etc) for each, how long would it take to nsupdate that?


On Sun, 28 Sep 2008, Chris Thompson wrote:

> On Sep 28 2008, David Forrest wrote:
>> On Sun, 28 Sep 2008, Mike Diggins wrote:
>>> My DNS environment (BIND) consists of a Master Name Server which is
>>> updated via a Database. A web page allows for changes, which updates the
>>> database, and periodically the database is dumped out to zone files for
>>> named, which are read and propagated to my slaves via regular zone
>>> transfers.
>>> My question is about transitioning to Dynamic updates, which I am not yet
>>> allowing. We have a number of zones, all updated through the Web interface
>>> I describe above. What happens if I want a client to be able to update one
>>> of those zones dynamically, while still updating all the static entries in
>>> the same zone, via the Web/Database and zone transfers? Is that even
>>> possible to update a zone this way, and allow dynamic updates? I can't
>>> seem to wrap my head around that. Can someone straighten me out?
>>> -Mike

>> Investigate the rndc freeze and thaw commands. I dynamically update my
>> internal zones this way as it rolls the dynamic .jnl files into the zones
>> and deletes the .jnls. Although I seen on this list that the serial
>> numbers are updated, I haven't seen that. But it looks like your database
>> dumping script would update them anyway so that would seem correct.
>> I see this as a possibility:
>> rndc freeze
>> update database
>> rndc thaw

> I would rather advise you to make your own updates via DNS update
> operations. I can offer you a Perl script that compares two
> normalised-by-"named-checkzone -D" zone files and generates input
> to nsupdate(1) that will turn one into the other. This is primarily
> intended for use when the whole zone contents are derived from the
> database, but you may be able to tweak it for use when some of the
> zone is under foreign control.
> --
> Chris Thompson
> Email:


Mike Diggins Voice: 905.525.9140 Ext. 27471
Network Analyst, Enterprise Networks FAX: 905.528.3773
University Technology Services E-Mail:
McMaster University, Hamilton, Ontario