Sun Jul 24 18:07:09 EDT 1994 ---------------- This kit consists of the following files: MULTIZDB this file MZDB.patch a patch file ns_init.c complete replacement for nslookup/ns_init.c (I included a new version of ns_init.c since it was dramatically rearranged. There isn't that much new functionality there, but lots of old things were done in ways inconvenient for this extension.) ns_init.c and the patches are based on BIND 4.9.3-beta-9. Sorry in advance for the difference in code indent style, but somebody can run it through a beautifier later. The patch enables MULTIZDB by default, but it has no effect unless you put "multizone" directives in your named.boot file. ---------------- This is a description of the Multizone Database File (MULTIZDB) extension for BIND. The overall feature is controlled via an option; to enable it, define MULTIZDB in "conf/options.h". MULTIZDB allows you to put records from more than one zone in a single database file. For some scenarios, this can simplify database maintenance, and, by simplifying it, make it less error-prone. The MULTIZDB extension affects only the local storage format of the zone files. It does not affect any DNS protocol elements nor does it alter any algorithm by which BIND arrives at an answer. A simple example is that of a DNS administrator who happens to have authority for a subdomain and a Class C network address, and where the two happen to be well-aligned. The standard way to operate BIND for this case would be to have two database files. First, for the forward zone, e.g., buzz.bomb.org ==> db.buzz. Second, for the reverse mapping zone, e.g., 23.45.201.in-addr.arpa ==> db.201.445.23. Whenever an endpoint is added, deleted, or changed, both database files must be updated. With MULTIZDB, both zones could be kept in a single file, making it more likely that both halves of an update would be done in synch. A new keyword, multizone, is recognized for named.boot. It takes as its single argument the name of the file containing the resource records. Like other directives in named.boot, the filename is relative to the assumed directory. A handful of new $ directives are recognized inside a multizone database file: $primary $secondary $stub $cache These are like the similarly-named directives from the named.boot file. For $primary, if a database file is named, it is ignored. ($secondary, $stub, and $cache are provided primarily for completeness since in most scenarios there is no real win in putting that information in a multizone database file instead of in named.boot.) These directives demark zones inside the multizone database file. Logically, it's as if the reading of a new file were begun at that point. Multizone database files do not nest and may not contain $include directives. -- Bill@attmail.com billc@pegasus.ATT.COM or +1 908 576 2932, Fax x4473 William_J_Carpenter@ATT.COM AT&T Bell Labs / AT&T EasyLink Services LZ 3C-207