Zone file version control vs. DDNS

[Tilman Schmidt]

I am running split horizon DNS for the zone sema.de, the externally
visible zone being a proper subset of the internal one. In particular,
the internal zone includes addresses assigned by DHCP from the RFC1918
address space 192.168.70.0/23. This is currently achieved by a Perl
script which reads the DHCP lease file and writes foward and reverse
mapping files. These are then $INCLUDEd by the internal sema.de and
70.168.192.in-addr.arpa zone files. This mechanism works but has
several shortcomings, so I would like to replace it with the dynamic
update feature of ISC DHCP 3.

So far, all the zone files are under RCS version control. Changes
are made by hand editing the files, committing the change to RCS,
and then reloading the server. It seems that with DDNS this will not
be feasible anymore. Specifically, I read in this list that if DDNS
is used then all zone changes should be made through DDNS. But I
will be having three sources of changes to my internal zones:
(a) manual changes to the external zone mirrored to the internal one,
(b) manual changes to the internal zone not visible externally, and
(c) dynamic updates from DDNS.

How are others handling this? Surely I am not the first one to hit
that problem.
-- 
Tilman Schmidt          E-Mail: Tilman.Schmidt at sema.de (office)
Sema Group Koeln, Germany       tilman at schmidt.bn.uunet.de (private)