Early on in the life of Ganymede, a schema kit was written for managing DNS here at Applied Research Laboratories. It was designed to support transitioning from GASH, the management software used prior to Ganymede. As a result, it works well for the specific arrangement at the lab, and is currently in use here, but would be practically unusable for any network setup not previously administered using GASH.
The GASH schema kit contains a custom builder task which takes the DNS-related objects in the Ganymede database and generates a source file that can then be processed by an external script into the appropriate DNS db files. Currently, the source file that the GASH schema kit produces is identical in format to the original "hosts_info" file generated by GASH. Creating the same output file as GASH allows the use of existing scripts and configuration files, but there are several drawbacks to remaining tied to the hosts_info structure.
The hosts_info file has a very rigid structure which is not very user friendly. Information for a single host is spread throughout the file, with data separated by an unintuitive mixture of spaces, commas, and colons. This means that writing a script to extract pertinent data is much more difficult than necessary, and any addition or modification of data fields can require substantial changes to the code that processes the file. It also limits the applicability of the information to a single, very specific, perl script. It would be more useful if the data existed in a standard format which was both easily understood by humans and easily accessed by other applications.
The actual content of the hosts_info file is also somewhat restrictive. There is no representation of forward or reverse zone information such as the REFRESH/RETRY/EXPIRE values of the DNS db file header, nor any support for multiple zones at all. Limitations like these require the current perl script to access external data files or use values hard-coded into the script, resulting in the unnecessary burden of maintaining multiple files of data which should really be held in Ganymede. In addition, hosts_info contains extra information like room number and user that, since not used in the generation of the DNS files, is extraneous. Given GASH's rigidity and singleness of purpose, the hosts_info file fulfills its role adequately, but it is just not flexible enough to extend to non-GASH DNS configurations.
The overall strategy, then, is to develop a schema kit that can support DNS in a manner that is not tied to any particular network configuration, but that is as flexible as DNS itself. This involves defining in the schema the DNS-related object types previously discussed, writing the custom code for managing those object types, and writing the builder tasks for generating the DNS db files used by BIND. To achieve any degree of flexibility in DNS configuration, the builder task must output data in a format other than the hosts_info file.