h2n(1)

NAME
h2n - Translate host table to name server file format

SYNOPSIS
h2n [option-list]

DESCRIPTION
h2n translates /etc/hosts to DNS zone files and creates BIND named.[boot|conf] configuration files. This tool can be run once or many times. After converting your host table to DNS format, you can manually maintain the DNS files, or you can maintain the host table and run h2n each time you modify /etc/hosts. h2n automatically increments the serial number in each DNS file when it makes a new one.

h2n generates files starting with the prefix "db." These are called "db files." The domain data are stored in a file called db.DOMAIN, where DOMAIN defaults to the first label in your domain name (given with the -d option). The address-to-name data are stored in files named db.NET, where NET is a network number (given with the -n option). An email address of the person responsible for the domain is included in the start-of-authority record for the domain (given with the -u option).

Each time h2n is run, it generates the DNS files from scratch. Any changes that were manually made to the DNS files are lost. If you need to add resource records to a db file generated by h2n, put the records in a file prefixed with "spcl." instead of "db." h2n will add this file's data by appending an $INCLUDE directive to the end of the db.DOMAIN or db.NET file. Top-of-zone, i.e., zone apex, records can be added to the forward-mapping db.DOMAIN file with the -T option instead of placing them in a "spcl" file. If a "spcl" file is present for -d DOMAIN, h2n will first read the DNS resource records from the file, check them for errors, and store the information internally. The "spcl" data is then referenced during subsequent processing of the host table to prevent conflicting DNS records from being generated.

By default, the MX RRset of a host consists of a single MX record with a weight of 10 that points to the host itself as the mail exchanger. The default MX RRset can be extended by specifying a global set of MX records with the -m option. All MX record generation for the domain can be suppressed by specifying the -M option. To fine-tune the MX RRset on a host-by-host basis, the following flags can be specified in the comment field of the relevant host table entry:

[no mx]
    Suppress all MX record generation for a host. This is useful for such devices as printers and networking equipment which do not need mailer information.

[smtp]
    Generate the default self-pointing MX record but suppress the global MX record(s) from the -m option(s). In environments that have a network firewall, this can be used to prevent external mail from reaching a host while still providing MX information for the routing of internal mail.

[no smtp]
    Suppress the default self-pointing MX record but include any global MX record(s) from the -m option(s). Situations in which this can be useful are:

    *   A host no longer receives mail and its host name can not become an alias of the replacement mailhost.

    *   All mail should first be routed to one or more mail hubs where virus and/or spam filtering can take place before being delivered to the host's IP address.

    Mail for hosts flagged with [no smtp] will instead be routed to the highest-priority mailhost(s) in the set of global MX records.
    NOTE:
        This flag requires that the MTA (Message Transfer Agent, e.g., sendmail, postfix, exim, etc.) running on the target mailhost(s) be configured to either accept mail on behalf of the host having the [no smtp] flag or deliver mail to the flagged host's IP address in lieu of the host's suppressed self-pointing MX record.

Another comment section flag is [TTL=num], where num is a specific time-to-live value to use for all resource records generated from a hostname entry in the host table. This is useful for setting artificially high or low TTL values for individual hosts. For example, if you are going to be moving a host to a new IP address, you can use this to set a low TTL value such as 900 (seconds). This limits how long the old IP address, aliases, and/or MX records will be cached on non-authoritative name servers. The maximum any client will have to wait for the new IP address to be seen would be 15 minutes in this case. Time intervals can also appear symbolically as seconds, minutes, hours, days, and/or weeks, e.g., [TTL=15M], [TTL=2h30m], etc.

The [no ptr] flag is available for situations where it's desired to suppress the creation of the reverse-mapping PTR record for a particular host table entry. For example, if secondary A records are needed for a particular IP address, the additional names can either be added via a "spcl" file or, perhaps more conveniently, entries with the same IP address but alternate names can be added to the host table. Specifying the [no ptr] flag for the secondary entries leaves a single PTR record that points to the primary canonical hostname.

[rafcp] is a comment field flag which causes certain records to be created or not created. Including [rafcp] in the comment section will cause WKS records indicating RAFCP support to be generated for the host and suppress generation of all MX records, even those specified with the -m option. This is to support routable AFCP on the TIO-side of HP 3000s which use Telnet Express Boxes as front ends.

Three additional comment field flags are [no -c], [mh=...] and [rp=...]. They correspond to and are documented in the sections dealing with the -c, +m, and -r options, respectively.

By default, h2n creates a BIND 4 boot file, ./named.boot (-b option), and a BIND 8/9 configuration file, ./named.conf (+c option). Files for caching-only name servers, ./[boot|conf].cacheonly, are also created unless they already exist. If either of the -z or -Z options are used, h2n creates a boot/conf file called ./[boot|conf].sec.save or ./[boot|conf].sec, respectively, for a slave name server. h2n will also look for the following files and, if found, append their contents to the appropriate boot/conf files:

     ./spcl-boot or ./spcl-conf
     ./spcl-boot.sec or ./spcl-conf.sec
     ./spcl-boot.sec.save or ./spcl-conf.sec.save

It is also possible to prepend site-specific configuration data such as ACL definitions to BIND 8/9 conf files with the +C option.

When h2n starts, it will look for a special configuration file in which host-specific network connectivity information can be entered to help h2n operate more efficiently in your environment. The filename search paths are:

     $HOME/.h2nrc
     ./h2n.conf
     /etc/h2n.conf
     /etc/opt/h2n/h2n.conf
     /usr/local/etc/h2n.conf

In addition to host-specific network information, h2n command-line options can be included as a way to customize various default values. For more detailed documentation, refer to the sample h2n.conf file which is included in the h2n distribution.

OPTIONS

-a NET[:NETMASK|/CIDR [mode=S]] ...
    Add information about hosts from network NET to the -d DOMAIN db file. This is similar to the -n option, but no PTR data is generated, i.e., no db.NET file is created. This is useful when another server is responsible for address-to-name mapping, but this server is responsible for name-to-address mapping. CIDR sizes /8 to /32 are allowed with the default being /24 unless overridden by a previous -N option. If NET is a supernet sized /8 to /24 (class A, B, or C) under which smaller networks (class B, C, or sub-C) are delegated, the mode=S argument allows those delegated subnets to be specified in subsequent -n/-a options (see the +S option for details). Including multiple NET arguments and/or -a options is allowed.

    Example:
        -a 192.249.249 15.15.16:255.255.248.0 15.0.48/21

-A  Don't create name server data for aliases in the host table.

-b BOOTFILE
    Use BOOTFILE (BIND 4) instead of the default: ./named.boot.

-B PATH
    Sets the directory where boot/conf files will be written (named.[boot|conf], [boot|conf].sec and/or [boot|conf].sec.save, and [boot|conf].cacheonly). You must specify an absolute pathname.

-c REMOTE-DOMAIN [mode=[A][I][D[Q]]] ...
    Create CNAME records in the default domain for all the hosts in REMOTE-DOMAIN. These CNAME records are generated before any other data in the default DOMAIN specified in the -d option, i.e, RR name conflicts favor the -c REMOTE-DOMAIN over the default DOMAIN. Also, CNAME records are only generated for canonical names in REMOTE-DOMAIN - aliases are ignored. This default behavior can be overridden by including one or more of the following mode= flags:

    A   Create additional CNAMEs for aliases in REMOTE-DOMAIN.

    I   Declare REMOTE-DOMAIN to be an intra-zone subdomain of the -d option DOMAIN, e.g., -c actor.movie.edu mode=I implies that there are no NS records in the movie.edu zone that delegate actor.movie.edu to a child zone. The subdomain "actor" is just another DNS label that a host within the movie.edu zone may have as part of its domain name. The resulting intra-zone CNAME would be:

         host.movie.edu. CNAME host.actor.movie.edu.

        After the CNAME is generated or registered, normal processing of the host table entry continues. i.e., A, PTR, and other RRs are generated as necessary.

    D   Defer creation of CNAMEs, i.e., RR names in the default DOMAIN takes precedence over naming conflicts in the REMOTE-DOMAIN.

    Q   Do not issue a warning message when a deferred CNAME can not be created due to a naming conflict in the default DOMAIN. Valid only when the D flag is also specified.

    Including multiple REMOTE-DOMAIN arguments and/or -c options is allowed. The -c option can be effectively canceled for any host by including the [no -c] flag in its host table comment field.
    NOTE:
        The collection of REMOTE-DOMAIN names is sorted so that subdomains within a domain tree are matched before their parent domains, i.e., the most specific domain matches before the least specific one. If a REMOTE-DOMAIN is a parent domain of the -d option DOMAIN, an exception is made and the -c option is NOT matched for host table entries matching the -d DOMAIN.

+c [CONFFILE] [mode=S|M]
    Use CONFFILE (BIND 8/9) instead of the default: ./named.conf The following optional mode= arguments are recognized:

    S   Create CONFFILE with zone statements in single-line format. This is the default.

    M   Create CONFFILE with zone statements in multi-line, indented format.

-C COMMENT-FILE
    Create resource records by using keys in the host table comment field as indices into COMMENT-FILE. COMMENT-FILE contains "key:resource record" pairs, e.g.,

     B1000:IN HINFO hp9000-B1000 hp-ux

    When h2n encounters "B1000" in the comment section of the host table, it creates a resource record by replacing the "B1000:" with the host's canonical name.

+C PRE-CONFFILE
    Prepend the contents of PRE-CONFFILE to the BIND 8/9 CONFFILE of the +c option. Useful for holding ACLs, logging specifications as an alternative to the +L option, and/or option specifications if the +O option is used without an argument.

-d DOMAIN [db=FILE1] [spcl=FILE2] [mode=D]
    Your domain name is DOMAIN. Use the db= and/or spcl= arguments to override the default filenames of db.LABEL and spcl.LABEL where LABEL is the first label of DOMAIN, e.g., label.movie.edu. Use the mode=D argument to set the default domain of unqualified canonical host names in the hostfile to DOMAIN.

-e EXCLUDED-DOMAIN ...
    Exclude data from the hostfile with names in EXCLUDED-DOMAIN. Specifying multiple EXCLUDED-DOMAIN arguments and/or -e options is allowed.
    NOTE:
        The collection of EXCLUDED-DOMAINs is sorted so that only the most top-level domain of a domain tree is kept since its subdomains are essentially redundant in this context. If any EXCLUDED-DOMAIN is the parent of the DOMAIN specified in the -d option and/or a REMOTE-DOMAIN of the -c/-p options, an exception is made and the DOMAIN or REMOTE-DOMAIN is NOT excluded.

-f FILE
    Command line options are read from a file called FILE. This option cannot be used within FILE. Comments are allowed in FILE using the same style as in the host table or DNS database files, i.e., comments start after an unquoted "#" or ";" and continue to the end of the line. The quoting characters ["'\] can be used to quote whitespace and are parsed using rules similar to the shell.

-h HOST
    Set HOST in the MNAME (master name server) field of the SOA record. The default is the host on which you run h2n.

-H HOSTFILE
    Use HOSTFILE instead of /etc/hosts.

-i NUM
    Set the SOA serial number of all created zones to NUM.

    NOTE:
        Serial number changes comply with the wrap-around arithmetic specified by RFC-1982. Setting the -i option may require a subsequent run by h2n before NUM appears as the SOA serial number.

-I [ignore|warn|audit|audit-only|warn-strict|fail|strict] [rfc2782]
    Controls the level of checking done on hostnames for conformance to naming standards established by RFC-952 and RFC-1123. The -I option accepts one of the following arguments which are ordered such that each subsequent argument includes the functionality of the preceding one:

    ignore
        Disables name checking and zone data auditing.

    warn
        Issues a warning about hostnames and domain names that do not conform to RFC-952 and RFC-1123.
        NOTE:
            Hostname aliases that generate a CNAME record type (the most common case) are generally not subject to the restrictions of these two RFCs. This flexibility of alias names allows the preservation of an otherwise illegal hostname by making it become an alias instead.

    audit
        Issues a warning about -h/-s/-S/-m options that point to CNAMEs or nonexistent domain names. If "spcl" files exist, the same checks are also done with NS, MX, SRV, PTR, AFSDB, and RT records as well as checks for dangling CNAMEs and RP records with missing TXT records. Delegated subdomains are checked for having at least two listed name servers, no missing glue records, no non-glue records at or below zone cuts, and NS RRsets with consistent TTL values. This is the default setting.

    audit-only
        Same as audit but excludes the name checking of the warn argument.

    warn-strict
        Extends conformance checking to the RFC-952 requirement that hostnames and their aliases in the host table be at least two characters in length. Includes audit.

    fail
        Performs the same level of checking as the warn argument except that non-compliant hostnames and aliases are rejected. Includes audit.

    strict
        Performs the same level of checking as the warn-strict argument except that non-compliant hostnames and aliases are rejected. Includes audit.

    rfc2782
        May be specified independently of the above arguments to check for the presence of "_service._protocol" as the leading labels in the owner names of SRV records.

    Operators of BIND 4/8 name servers that are configured with a "check-names" option setting of "fail" should run h2n with the -I fail option as well.

-L NUM
    Explicitly use a file handle limit of NUM when generating database files. Default value is 120.

+L [LOG-SPEC]
    Add a logging specification to the config files (named.conf, conf.sec, conf.sec.save). If you only specify +L, you'll get a simple logging specification that will eliminate a lot of bogus information that would otherwise fill up your syslog. You can override this by giving your own entries, e.g.,

     +L category lame-servers { null; };

    For each +L LOG-SPEC option that is specified, a line containing the LOG-SPEC is added in the config file, thus including more than one +L option is allowed. Omitting this option will also omit any logging specification from appearing in the config files. See the named man page for valid logging options.

-m WEIGHT:MX-HOST ...
    Include an MX record that points to MX-HOST at WEIGHT for each host in your domain which has neither the [no mx] nor [smtp] comment field flags. Including multiple WEIGHT:MX-HOST arguments and/or -m options is allowed.

    Example:
        -m 10:terminator.movie.edu 20:wormhole

+m [D|C|P|CP]
    Controls the method by which DNS records get generated for hosts with multiple addresses. By default, the canonical name of such multi-homed hosts is assigned an A record for each address. Aliases unique to one address are also assigned an A record. Aliases common to all addresses are assigned a CNAME record. The PTR record for each address points to the multi-address canonical name. This default behavior can be overridden by specifying one of the following flags:

    D   Same as the default behavior.

    C   The first alias unique to one address is still assigned an A record but subsequent aliases unique to the address are assigned CNAME records which point to the first alias.

    P   PTR records do not point to the multi-address canonical name but instead point to the first alias having an A record, i.e., the unique name of the specific network interface.

    Combining the C and P flags is allowed. These global specifications can be overridden for any host by including the analogous [mh=d|c|p|cp] flag in its host table comment field.

-M  Don't generate MX records.

-n NET[:NETMASK|/CIDR [mode=S] [domain=NETDOMAIN] [ptr-owner=TEMPLATE]]
    Add information about hosts from network NET to the -d DOMAIN db file. CIDR sizes /8 to /32 are allowed with the default being /24 unless overridden by a previous -N option. For CIDR sizes /8 through /24, PTR data is written to the corresponding db.NET file in the "in-addr.arpa" domain. Specifying a CIDR size of /8, e.g., -n NET/8, will cause PTR data to be written to a single class-A db.NET file. CIDR sizes 9 through 16 will cause the equivalent number of class-B db.NET files to be created. CIDR sizes 17 through 24 will cause the equivalent number of class-C db.NET files to be created. If NET is a supernet sized /8 to /24 (class A, B, or C) under which smaller networks (class B, C, or sub-C) are delegated, the mode=S argument allows those delegated subnets to be specified in subsequent -n/-a options (see the +S option for details). For sub-class-C networks, i.e., CIDR sizes /25 through /32, refer to the following sections that explain the domain= and ptr-owner= arguments for details regarding various default values. Including multiple NET arguments and/or -n options is allowed.

    domain=NETDOMAIN (for NET/25 to NET/32 only)
        Specifies that the PTR records are to reside in the DNS zone NETDOMAIN. If omitted, NETDOMAIN defaults to the naming scheme illustrated by the following examples:

         192.168.4.0/25 -> 0-127.4.168.192.in-addr.arpa
         192.168.4.0/26 -> 0-63.4.168.192.in-addr.arpa
         192.168.4.0/27 -> 0-31.4.168.192.in-addr.arpa
         192.168.4.0/28 -> 0-15.4.168.192.in-addr.arpa
         192.168.4.0/29 -> 0-7.4.168.192.in-addr.arpa
         192.168.4.0/30 -> 0-3.4.168.192.in-addr.arpa
         192.168.4.0/31 -> 0-1.4.168.192.in-addr.arpa
         192.168.4.0/32 -> 0.4.168.192.in-addr.arpa

        The default reverse-mapping db files that h2n creates are named according to the following pattern:

             192.168.4.0/25 -> db.192.168.4.0-127
             192.168.4.0/26 -> db.192.168.4.0-63
             192.168.4.0/27 -> db.192.168.4.0-31
             192.168.4.0/28 -> db.192.168.4.0-15
             192.168.4.0/29 -> db.192.168.4.0-7
             192.168.4.0/30 -> db.192.168.4.0-3
             192.168.4.0/31 -> db.192.168.4.0-1
             192.168.4.0/32 -> db.192.168.4.0

        Special characters that are are valid in a domain name but troublesome in filenames will get translated to the "%" character in the db files, e.g.,

             domain=0/28.4.168.192.in-addr.arpa -> db.192.168.4.0%28

        PTR records can even be written to the forwarding-mapping DOMAIN in the -d option, i.e., domain=DOMAIN, as long as the -d option precedes the -n option. Additional resource records can be added to a spcl.NET file where NET is suffix of the corresponding db.NET file. h2n will append such "spcl" files to their matching "db" files via an $INCLUDE directive.

    ptr-owner=TEMPLATE (for NET/25 to NET/32 only)
        Specifies that TEMPLATE be used to build the zone-relative names in the owner field of PTR records in the NETDOMAIN zone file. Substitution tokens based upon each octet of an IPv4 address are used to construct the appropriate TEMPLATE. The octet tokens (from left to right) are "$1", "$2", "$3", and "$4". To illustrate this concept, here are the fixed templates used by h2n to construct PTR owner names for class A, B, and C NETs given a host name with an IP address of "A.B.C.D":

         Class-A network:
              $ORIGIN A.in-addr.arpa.
              D.C.B PTR host.example.com.
             --------
             $4.$3.$2 <- effective template
             -n A/8 (domain=A.in-addr.arpa)
                         (ptr-owner=$4.$3.$2 )
                          ^^^^^^^^^^^^^^^^^^^^^
                           effective arguments

         Class-B network:
              $ORIGIN B.A.in-addr.arpa.
              D.C PTR host.example.com.
             -----
             $4.$3 <- effective template
             -n A.B/16 (domain=B.A.in-addr.arpa)
                        (ptr-owner=$4.$3 )
                         ^^^^^^^^^^^^^^^^^^^^^^^
                           effective arguments

         Class-C network:
              $ORIGIN C.B.A.in-addr.arpa.
              D PTR host.example.com.
             ---
             $4 <- effective template
             -n A.B.C/24 (domain=C.B.A.in-addr.arpa)
                          (ptr-owner=$4 )
                           ^^^^^^^^^^^^^^^^^^^^^^^^^
                              effective arguments

        If the ptr-owner= argument is omitted, TEMPLATE defaults to "$4". For example, given the following host table:

             192.168.4.0 drama.movie.edu
             192.168.4.1 comedy.movie.edu
             192.168.4.2 action.movie.edu
             192.168.4.3 cartoon.movie.edu

        and the following RFC-2317 delegation in NET's parent zone:

             $ORIGIN 4.168.192.in-addr.arpa.
             $GENERATE 0-3 $ CNAME $.0-3
             0-3 NS ns1.movie.edu.
                                   NS ns2.movie.edu.

        The following -n option would generate the required PTR records in file db.192.168.4.0-3:

             -n 192.168.4.0/30

             $ORIGIN 0-3.4.168.192.in-addr.arpa.
             0 PTR drama.movie.edu.
             1 PTR comedy.movie.edu.
             2 PTR action.movie.edu.
             3 PTR cartoon.movie.edu.

        To illustrate the flexibility in accommodating various RFC-2317 naming schemes, suppose that the PTR records are to be mapped back to the "movie.edu" zone like so:

             $ORIGIN 4.168.192.in-addr.arpa.
             $GENERATE 0-3 $ CNAME 192-168-4-$.movie.edu.

        The following h2n options would be needed to generate the required owner names of the PTR records in file db.movie:

             -d movie.edu
             -n 192.168.4.0/30 domain=movie.edu ptr-owner=$1-$2-$3-$4

             $ORIGIN movie.edu.
             192-168-4-0 PTR drama
             192-168-4-1 PTR comedy
             192-168-4-2 PTR action
             192-168-4-3 PTR cartoon
             drama A 192.168.4.0
             comedy A 192.168.4.1
             action A 192.168.4.2
             cartoon A 192.168.4.3

-N NETMASK|/CIDR
    Apply NETMASK or CIDR to all subsequent -n/-a NET specifications as an alternative to specifying the size of each NET. Specifying a subnet mask or CIDR size with -n/-a overrides the -N subnet mask or size for that NET only. May be specified multiple times for different blocks of -n/-a NETs. CIDR sizes /8 to /32 are allowed.

-o [REFRESH]:[RETRY]:[EXPIRE]:[MINIMUM]:[DEFAULT-TTL]
    Change the default SOA values to the values provided. For name servers running versions of BIND prior to 8.2, the default values are (10800:3600:604800:86400). For versions 8.2 and later which implement RFC-2308, the defaults are (3H:1H:1W:10M:1D) with DEFAULT-TTL appearing in a $TTL directive and MINIMUM being semantically treated as a negative caching value. h2n will always try to determine the BIND version of the master name server (-h option or localhost) and act accordingly. However, if the BIND version is unavailable, h2n version 2.40 and later will create RFC-2308 formatted zone files by default *unless* the -o option is specified with exactly four explicit and/or placeholder values.
    NOTE:
        These built-in default values do not override those in zone files that already exist. Use the -o option to specify SOA values that will override those in existing zone files as well as becoming the default values for new zone files. Also, existing $TTL directives will force RFC-2308 format unless the detected BIND version is less than 8.2, in which case the directives will be removed.

    Examples:
        -o ::::12H
            Generates a "$TTL 12H" directive in all zone files.

        -o :::12H
            Generates a non-RFC-2308 TTL of 12H in the SOA MINIMUM field of all zone files *if* the detected BIND version is less than 8.2 or is unavailable.

        -o :::
            Generates the same non-RFC-2308 format as the previous example but using the built-in default SOA values instead.

-O OPTION OPTION-ARGS
    Add a boot option specification to the boot files (named.boot, boot.sec, boot.sec.save), e.g.,

     -O options no-round-robin

    See the named man page for valid options. Including more than one -O option is allowed.

+O [OPTION-SPEC]
    Add an option section specification to the config files (named.conf, conf.sec, conf.sec.save), e.g.,

     +O round-robin no;

    For each +O OPTION-SPEC option that is specified, a line containing the OPTION-SPEC is added to the config file, thus including more than one +O OPTION-SPEC option is allowed. If you use a single +O option without an argument, the global options section will not be generated. This is useful if you want to maintain a main named.conf file for your master and slaves with a complex mix of options {}, logging {}, and/or other global sections, and "include" the h2n-generated zone sections. Combine this with a +c option.

+om OPTION OPTIONS-ARGS
    Adds a zone-specific option to the config file (named.conf), e.g.,

     +om also-notify { 15.1.2.3; 15.1.2.4; };

    This option is position dependent and applies to the last -d or -n option specified, however, if a +om option appears before any -d or -n options it is assumed that the +om option applies to all zones. Thus, it will be added to each zone section in the config file. Including multiple OPTION/OPTION-ARGS argument pairs and/or +om options is allowed.

+os OPTION OPTIONS-ARGS
    Adds a zone-specific option to the config files (conf.sec and/or conf.sec.save), e.g.,

     +os max-transfer-time-in 60;

    Like the +om option, it is position dependent and applies to the last -d or -n option specified. Also, if a +os option appears before any -d or -n options it is assumed that the +os applies to all zones. Including multiple OPTION/OPTION-ARGS argument pairs and/or +os options is allowed.

-p REMOTE-DOMAIN [mode=A|P]
    Create only PTR data for hosts in REMOTE-DOMAIN. This is useful when a different server is responsible for the forward (name-to- address) mapping data of REMOTE-DOMAIN but this server is responsible for the reverse (address-to-name) mapping data of each -n option. Including multiple REMOTE-DOMAIN arguments and/or -p options is allowed. Each REMOTE-DOMAIN may need a mode= argument with one of the following flags:

    A   Required for each REMOTE-DOMAIN which had its forward mapping data built with the h2n -A option in effect. This prevents dangling PTR records from being generated for multi-homed hosts in REMOTE-DOMAIN having the [mh=p] or [mh=cp] flag in the comment field of the host table. Can also be specified as an override flag for REMOTE-DOMAIN when the +m P option is in effect.

    P   Enables the alternate method of PTR record generation for multi-homed hosts in REMOTE-DOMAIN as previously described for the +m P option when that option is not in effect. This method is overridden for any host in REMOTE-DOMAIN having the [mh=d] or [mh=c] flag in its comment field.

    NOTE:
        The collection of REMOTE-DOMAIN names is sorted so that subdomains within a domain tree are matched before their parent domains, i.e., the most specific domain matches before the least specific one. If a REMOTE-DOMAIN is a parent domain of the -d option DOMAIN, an exception is made and the -p option is NOT matched for host table entries matching the -d DOMAIN.

-P  Preserve upper-case characters of hostnames and aliases. Requires the "Tie::CPHash" Perl module to be available.

-q  Work quietly.

-r  Enable creation of RP (Responsible Person) records. Look for strings in the comment fields of the host table that match [rp=mail-addr[ text]], where mail-addr is a usual e-mail address specification, and (optionally) text is a free-form text string (usually containing a phone number and/or pager number, or other info). This construct is converted to an RP record containing the e-mail address, and if text is present, a TXT record is also added containing text (with the RP record referencing the TXT record).

-s SERVER ...
    List SERVER for all zones. Adds NS records for the zone(s) corresponding to the -d option and all -n options. Including multiple SERVER arguments and/or -s options is allowed.

-S SERVER ...
    List SERVER for specific zone(s). Adds NS records for the zone(s) corresponding to the last preceding -d or -n option (this option is position dependent). There can be multiple zones if this applies to a -n option. Including multiple SERVER arguments and/or -S options is allowed.

+S [enable|disable]
    Control the ability of class A, B, or C NETs to act as supernets, i.e., parent networks, for subsequent -n/-a options which specify a subNET of a smaller class (B, C, or sub-C). When h2n reads its option list, each -n/-a NET is checked to see if has any overlapping IP addresses with a previously-specified NET. If an inter-class overlap exists, the default behavior is to treat the situation as an ambiguous data entry error, e.g.,

     -n 192.168/16
     -a 192.168.1/24
     Improper -a option (-a 192.168.1/24).
     It overlaps with a network of a different class from a
     previous option:
       -n 192.168/16
     They can't simultaneously specify a part of the same DNS
     address-to-name space.

    However, the overlapping -n/-a options in the preceding example are exactly what is needed in the scenario where:

     1. The file "spcl.192.168" exists and contains NS records
        which delegate the reverse-mapping name space for
        192.168.1/24 to other name servers. Remember that
        any spcl.NET file that h2n finds is appended to
        the appropriate db.NET file that gets created.
     2. The host table being used has entries for both parent
        (192.168/16) and delegated (192.168.1/24) networks.

    When inter-class network overlaps need to exist as -n/-a options to accommodate reverse-mapping delegations, the +S option must be specified so that the appropriate supernet(s) can be recognized as such. In the current example, specifically assigning supernet status to the 192.168/16 network prevents the overlapping 192.168.1/24 network from being rejected when the option list is processed. The -a option is then able to match IP addresses in the 192.168.1/24 network and prevent their corresponding PTR record(s) from being matched and created in the db.192.168 zone data file, e.g.,

     +S
     -n 192.168/16
     +S disable
     -a 192.168.1/24

    Once the +S option is specified, all subsequent class A, B, and/or C NETs declared with the -n/-a options are considered to be supernets relative to any smaller-classed subNET until cancelled by the +S disable option. Multiple +S enable/disable blocks may be used.

    As mentioned in the descriptions for the -n and -a options, the mode=S argument may also be used as an alternate way to declare an individual NET to be supernet, e.g.,

     -n 192.168/16 mode=S
     -a 192.168.1/24

    NOTE:
        -n/-a options that are declared to be supernets must appear before the corresponding -n/-a options for the overlapping subnets since h2n processes these options in a single pass. Also, care should be taken not to overuse the +S/mode=S supernetting feature. Doing so prevents the detection of unintended network overlaps.

-t  Generate TXT records from the host table comment section. Any special h2n processing flags are ignored, e.g., [no smtp].

+t DEFAULT-TTL [MINIMUM-TTL]
    Create an RFC-2308 $TTL directive at the top of all zone files. If the MINIMUM-TTL argument is specified, use that as the negative caching interval instead of the default value of 10 minutes.

-T [mode=M] [RR='DNS RR' [RR='...']] [ALIAS='NAME [TTL]'] ...
    Add additional top-of-zone-related records to DOMAIN of the -d option as an alternative to creating them in a "spcl" file. The following arguments are recognized:

    mode=M
        Add the global MX record set from the -m option(s).

    RR= Add 'DNS RR' with the owner field set to whitespace or the RFC-1035 "@" symbol. Any DNS record type that is contextually valid in the zone apex can be specified. The appropriate quotes must enclose 'DNS RR' with its embedded whitespace to capture it as a single argument.

    ALIAS=
        Add a CNAME having NAME in the owner field which has an RDATA field that points to "@", the zone apex. If an optional TTL is specified, the 'NAME TTL' argument must be enclosed in the appropriate quotes.

    Including multiple RR= and/or ALIAS= arguments and/or -T options is allowed.

-u CONTACT
    Set CONTACT as the e-mail address in the RNAME (responsible person) field of the SOA record. CONTACT should be a complete mail address, e.g.,

     hostmaster@movie.edu

    Defaults to root@DOMAIN (-d option). Periods in the username-portion of the address, e.g.,

         Sam.Spade@movie.edu

    will be escaped if necessary.
    NOTE:
        If CONTACT lacks the "@" symbol and has a trailing period, RNAME format will be assumed and CONTACT left unchanged.

-v  Display the version number of h2n.

-V DOMAIN
    Verify the integrity of a domain by performing a zone transfer and analyzing the data. All of the checks described above for the -I audit option are done plus those for "CNAME and other data" errors. In addition, listed name servers are checked for proper delegation. Including multiple DOMAIN arguments and/or -V options is allowed.

-w  Generate WKS records that list the SMTP service over the TCP protocol if an MX record is also created.

-W PATH
    Sets the directory where db files will be located on the master and slave name servers. This is useful if you build new db files on a host other than the master. You must specify an absolute pathname.

-y [mode=D|M]
    Set the SOA serial number of all created zones to use a date/version format. The default format is YYYYMMDDvv where YYYY is the year, MM is the month, DD is the day of the month, and "vv" is the version counter that starts at 00 and increments each time h2n is run on the same day. The consistent appearance of this format in the SOA record implies a limit of 100 updates per day. The -y option may be specified with one of the following mode= flags:

    D   Set the daily format of YYYYMMDDvv (default).

    M   Set the monthly format of YYYYMMvvvv. This allows up to 10,000 updates per month to be made.

    NOTE:
        Serial number changes comply with the wrap-around arithmetic specified by RFC-1982. If setting the -y option for the first time, it may take a subsequent run by h2n before the desired format is achieved.

-z ADDRESS ...
    Create a boot/conf file, ./[boot|conf].sec.save, for a slave name server that lists ADDRESS as the master to load from, and save a copy of the zone data in a backup file. (This option is similar to the -Z option). Including multiple ADDRESS arguments and/or -z options is allowed.

-Z ADDRESS ...
    Create a boot/conf file, ./[boot|conf].sec, for a slave name server that lists ADDRESS as the master to load from, and do not save a copy of the data in a backup file. (This option is similar to the -z option). Including multiple ADDRESS arguments and/or -Z options is allowed.

[-no]-recurse
    Controls whether or not delegated subdomains are themselves recursively verified after completing verification of the parent domain with the -V option. Default is -no-recurse.

[-no]-check-del
    Controls delegation checking when verifying one or more domains with the -V option. NS records that delegate child domains are also checked. Default is -check-del.

[-no]-show-nxdomain-cnames
    Controls the display of non-existent external domain names to which an internal CNAME points, i.e., "dangling" CNAMEs, if auditing is in effect. CNAMEs pointing to non-existent internal domains are always reported. Default is -show-nxdomain-cnames.

[-no]-show-chained-cnames
    Controls the display of each element of an external CNAME chain to which an internal CNAME points. The default behavior [-no] is to ignore CNAME chains that successfully resolve and display just the chain length of dangling or looping CNAMEs.

[-no]-debug[:DIRECTORY]
    Controls the removal of all temporary files that get created during the course of normal processing including a zone transfer file obtained with the -V option. If a domain is being reverified and the zone transfer file still exists from a previous run with -debug, then respecifying the -debug option will cause the existing zone transfer data to be used instead of requesting a new copy of the zone from an authoritative name server. Temporary files are created in the /tmp directory unless overridden by the optional DIRECTORY argument. Default is -no-debug.

RETURN VALUE
h2n returns the following exit codes:

    0   Successful completion. Review standard error for incidental messages.

    1   Data generation error. Review standard error for message(s) related data errors that would prevent DNS zones from being loaded and/or cause name server interoperability issues.

    2   Abnormal end of program. Review standard error for cause.

DIAGNOSTICS
Error messages that occur when h2n processes its options list are self-explanatory and usually result in abnormal program termination. Warning messages related to the processing of data in the host table and "spcl" files attempt to achieve concise clarity but do assume that the user has basic knowledge of the DNS-related RFCs.

When a DNS zone is audited, various validity checks are done depending on the type of record being inspected (NS, MX, etc.). h2n looks up intra-zone data in its internal tables and calls the DiG program to make DNS queries for resolving references to extra-zone domain names. The following status codes are used to report badly configured data and DNS query failures:

[CNAME chain ]
    The domain name is an extra-zone CNAME that points to another CNAME. The total chain length appearing within parentheses immediately follows.

[ CNAME loop ]
    The domain name is an extra-zone CNAME which ultimately points back to itself. If a CNAME chain is involved, the total length appearing within parentheses immediately follows.

[CNAME record]
    The domain name refers to a CNAME record when it should properly point to another record type, most likely an address record (A, AAAA, or A6). In addition to address records, PTR records can point to NSAP records (RFC-1706) while RT records can also reference ISDN and X25 records (RFC-1183).

[(*) CNAME RR]
    Same as above except that the domain name matches a wildcard CNAME record.

[ (*) MX RR  ]
    Same as above except that the domain name matches a wildcard MX record.

[no addr. RR ]
    The domain name exists and should have an address record (A, AAAA, or A6) but no such RR type exists. Also implies that no NSAP record exists if auditing PTR records and no ISDN nor X25 records exist if auditing RT records.

[(*) non-A RR]
    Same as above except that the domain name matches a wildcard record that is not type A, AAAA, or A6.

[ no TXT RR  ]
    The domain name exists and should have a TXT record but no such record type exists.

[(*)nonTXT RR]
    Same as above except that the domain name matches a wildcard record that is not type TXT.

[no A record ]
    The extra-zone domain name exists and should have an address record but a DNS query returned no A RRs.

[no such name]
    The intra-zone domain name does not exist.

[no RRs exist]
    The domain name exists as a node in the DNS name space but no DNS resource records are associated with the name.

[  NXDOMAIN  ]
    The requested extra-zone domain name does not exist.

[  FORMERR   ]
    The name server was unable to interpret the DNS query due to a format error.

[  SERVFAIL  ]
    The name server encountered an internal failure while processing the query, for example an operating system error, a forwarding timeout, or a failure to load a DNS zone due to bad data.

[   NOTIMP   ]
    The name server did not support the specified query.

[  REFUSED   ]
    The name server refused to perform the specified query for policy or security reasons.

[ timed out  ]
    The DNS query made by the DiG program timed out.

[con. refused]
    A query was directed to a host which was not running a name server process.

[  no route  ]
    A query was directed to an unreachable host.

[unreachable ]
    A query was directed to a host on an unreachable network.

[bad DNS msg.]
    DiG received a malformed response to its DNS query.

[buffer error]
    An overrun occurred in DiG's command buffer. This can be alleviated by running DiG 8.3 or newer.

[sync. error ]
    DiG generated unexpected output that was detected by h2n's internal parser.

EXAMPLES
Create name server data for networks 192.249.249 and 192.253.253 in movie.edu.

     h2n -d movie.edu -n 192.249.249 -n 192.253.253

Create name server data for networks 192.249.249/24 and 192.253.253/24 in "movie.edu". Eliminate lines in the host table that contain "fx.movie.edu" and include an MX record for all hosts that points to the mail hub "postmanrings2x.movie.edu". Afterwards, append the additional resource records in the file spcl.movie.edu to db.movie via an $INCLUDE directive. Put all of the options in a file that h2n can read with the -f option.

     h2n -f option_file

     option_file contains the following lines:

     -d movie.edu spcl=spcl.movie.edu
     -n 192.249.249
     -n 192.253.253
     -e fx.movie.edu
     -m 50:postmanrings2x.movie.edu

If the Web server has the following host file entry:

     192.253.253.80 web.movie.edu

The following -T option enables the URLs

     http://movie.edu
     http://www.movie.edu

to resolve to the site's Web server as well as adding the global MX record(s) from the -m option(s) to the zone apex in lieu of adding records to a "spcl" file:

     -T RR='@ A 192.253.253.80' ALIAS=www mode=M

DEPENDENCIES
h2n requires Perl 5 in order to run. The -P option for preserving upper-case characters in the host file requires the "Tie::CPHash" Perl module to be installed. This module can be obtained from the Comprehensive Perl Archive Network (CPAN) site at:

     http://search.cpan.org/search?module=Tie::CPHash

The DiG program is required for certain options (-V, -I audit) and to obtain the version of BIND that is running on the master name server (-h option) in order to optimize its functionality. The source code for DiG is available in the standard BIND distribution at:

     http://www.isc.org/products/BIND

The "check_del" utility. You have a couple of choices:

1.  Use the version written in Perl that's included with the h2n distribution. You'll need the Net::DNS module which can be obtained from one of the following sites:

     http://search.cpan.org/search?module=Net::DNS
     http://www.net-dns.org/

2.  A version written in C can be found in the BIND 8 distribution under the contrib/nutshell directory. You'll have to compile BIND first since "check_del" needs to be linked with some of BIND's static libraries.

"check_del" is only needed when h2n is used to verify a DNS zone via the -V option.

VERSION
This documentation describes h2n version 2.56.