+The domain list contains configuration commands describing all domains handled
+by your server and their parameters. In fact, it's a M4 script, but viewing it as
+a config file is a good approximation (however, see Section 8 for some caveats).
+Lines starting with a semicolon are treated as comments and ignored. Text outside
+declarations is silently ignored.
+
+You can specify:
+
+PRIMARY(zone, [extra-files...])
+ Define a zone (domain) we run a primary name server for.
+ The contents of the zone are described in cf/<zone>
+ and possibly in other specified cf files (all files are
+ concatenated to produce a single configuration). See the next
+ section for a look inside these files.
+
+SECONDARY(zone, primary)
+ Define a zone we run a secondary name server for.
+ "primary" is an IP address of the primary name server.
+
+REVERSE(network, primary-files...)
+ Define a reverse zone for the given network. The network name
+ consists of several numbers separated by dots, just like an IP
+ address does, but the network usually has only 3 components.
+ Each reverse zone has its own config file cf/<network> which
+ can of course specify the contents of the zone.
+
+ However, there is a more convenient method to generate the PTR
+ records directly from the A records: just specify the REVERSE
+ directive in cf/<network> and then include all the config files
+ for the primary zones containing hosts from this network. The
+ automatic concatenation of multiple primary-files comes very
+ handy for that.
+
+ In fact, REVERSE(network, p-f...) is almost an equivalent of
+ PRIMARY(REV(network), p-f...) where REV(network) is a macro
+ translating network numbers to names of the corresponding
+ reverse zones [e.g., REV(1.2.3) equals 3.2.1.in-addr.arpa].
+ The only difference is that although the domain name is translated
+ by REV, the config file is still named according to the network.
+ You can also use the REV macro explicitly, which can be handy
+ for example in SECONDARY declarations.
+
+ZONE_OPTIONS(`options;
+ more options;
+')
+ Define options to be inserted to all subsequent zone declarations
+ until the next ZONE_OPTIONS command. Please keep in mind that the
+ semicolon character act as M4 comment, so you need to put the
+ closing quote at a separate line. See our example cf/domains.
+
+CONFIG(...)
+ Insert user data to named.conf, again beware of semicolons.
+
+MAKEFILE(...)
+ Insert user data to Makefile.
+
+
+3. The Domain Files
+~~~~~~~~~~~~~~~~~~~
+The domain files contain descriptions of all DNS records for the given
+domain, starting with the SOA record. Again, these are M4 scripts and the
+declarations are macro calls. Lines starting with a semicolon are treated
+as comments and just copied to the generated zone file. Text outside
+declarations is copied to the zone file as well, so you can spice up the NSC
+output with your own records.
+
+All host or domain names are either names relative to the current domain
+with no dots inside or absolute names (in this case, NSC automatically
+ensures that the trailing dot is present in the resource records). Relative
+names with dots are not supported, but they are rare and you can always write
+them as absolute anyway.
+
+Your menu:
+
+SOA(domain-name)
+ Generate a SOA record for the domain. This must be the first
+ declaration in the config file. The parameters of the SOA
+ are taken from configuration variables (see below). The
+ serial number is calculated from the version number remembered
+ in the version file, following the usual practice of encoding
+ current date and a sequence number within the current day
+ in the serial number, which is guaranteed to be strictly
+ increasing unless you perform more than 99 updates in a single
+ day (in which case NSC stops and tells you to tweak the serial
+ number manually).
+
+ The SOA record otherwise acts like a sub-domain (D) declaration,
+ therefore it can be followed by other records like NS (mandatory)
+ or MX.
+
+H(host)
+ Start declaration of a host. Doesn't generate anything, only
+ remembers the host's name.
+
+ADDR(addr...)
+ Specify addresses for the current host. In the normal mode, it
+ creates A records, in the reverse mode, PTR records.
+
+H(host, addr...)
+ A shortcut for H(host) ADDR(addr...) -- in many cases everything
+ you need for a single host.
+
+DADDR(addr...)
+ Like ADDR, but suppresses PTR records. (This one is useful if you
+ have a single IP address used for zillions of names and you want
+ to avoid having zillions of PTR records for the same address.)
+
+DH(host, addr...)
+ A shortcut for H(host) DADDR(addr...)
+
+D(domain)
+ Start declaration of a sub-domain. Technically the same as H(domain),
+ but this one should be more intuitive.
+
+GLUE(ns, addr...)
+ Specify a glue record for a name server contained within a sub-domain
+ it's a primary for. Currently it's an equivalent of DH(ns, addr...).
+
+NS(ns...)
+ Specify a list of name server names for the current domain
+ (started by either a SOA or D declaration). Generates NS records.
+
+MX(mx...)
+ Specify a list of mail exchangers for the current host or domain.
+ Each mail exchanger should be preceded by a priority. Generates
+ MX records.
+
+HI(hw,os)
+ Specify a HINFO record for the current host. Very rare in the
+ today's Internet.
+
+ALIAS(alias...)
+ Specify a list of aliases for the current host or domain.
+ Generates a series of CNAME records pointing from the aliases
+ to the current host/domain.
+
+TXT(text)
+ Specify a TXT record for the current host or domain.
+
+RP(mail, txt)
+ Specify a RP (responsible person) record for the current host or domain.
+ The first argument is a mail address in DNS notation (with `@' replaced
+ by `.' as in the SOA record), the second one is a name of a TXT record
+ with contact information.
+
+SRV(service, protocol, priority, weight, port, target)
+ Specify a SRV (service) record for the current host or domain.
+
+CNAME(src, dest)
+ Generate a CNAME record -- "src" points to "dest".
+
+PTR(src, dest)
+ Generate a PTR record -- "src" points to "dest". It's a common
+ record in reverse zones (and although it's legal in forward
+ zones as well, such use is very rare), however it's more convenient
+ to have your PTR's generated by the REVERSE directive. But if you
+ need anything special, here is the tool.
+
+REVBLOCK(subdomain, min, max)
+ Generate a series of CNAME records numbered from `min' to `max'
+ and pointing to the same name in the given sub-domain, finally
+ declaring the sub-domain as well, so you can continue with its
+ NS records.
+
+ Example: REVBLOCK(a, 16, 18) NS(ns.xyzzy.org) yields