HP TCP/IP Services for OpenVMS

Previous Contents Index

6.3.1 Navigating Two Different BIND Environments

This section summarizes the differences between the UCX BIND implementation and BIND Version 9.

Remember that, in BIND Version 9, name servers are configured by editing a text configuration file. The use of this file is described in Section 6.5. HP recommends, but does not require, that you use the configuration file to set up BIND. You can continue using the TCPIP$CONFIG and the SET CONFIGURATION BIND commands to set up your BIND environment, as you did with previous releases of this product. The term UCX BIND in Table 6-1 describes the previous configuration method even though this method is still valid in the current release.

Table 6-1 describes changes to the database and configuration file names.

Table 6-1 UCX BIND and BIND Version 9 Differences
Database/File Names UCX BIND BIND Version 9
Local loopback files NAMED.LOCAL LOCALHOST.DB, 127_0_0.DB
Forward lookup file domain_name.DB domain_name.DB
Reverse lookup file address.DB address.DB


You must be consistent when making changes to your BIND environment. If you make changes by editing the configuration file, you should continue to make changes in that manner.

If you revert to the UCX BIND configuration method (SET CONFIGURATION BIND and CONVERT/CONFIGURATION BIND commands), any changes you made to the configuration file (TCPIP$BIND.CONF) are lost.

If you continue to use the SET CONFIGURATION BIND commands, you must always enter the CONVERT/CONFIGURATION BIND command in order for your changes to take effect.

6.4 BIND Service Startup and Shutdown

The BIND service can be shut down and started independently of TCP/IP Services. The following files are provided for this purpose:

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services.

6.5 Configuring the BIND Server

This section describes how to configure the BIND name server on your local host.

BIND Version 9 configuration is broadly similar to BIND Version 8; however, there are a few new areas of configuration, such as views. BIND Version 8 configuration files should work with few alterations in BIND Version 9, although you should review more complex configurations to see whether they can be implemented more efficiently using the new features in BIND Version 9.

BIND Version 9 stores configuration information in a text file called TCPIP$BIND.CONF. The TCP/IP Services product provides a template for this file in the SYS$SPECIFIC:[TCPIP$BIND] directory. Before starting BIND, edit this template to reflect your site-specific configuration requirements.

6.5.1 Configuration File Elements

Table 6-2 lists the elements used throughout the BIND Version 9 configuration file documentation.

Table 6-2 Name Server Configuration File Elements
Element Description
acl_name The name of an address_match_list as defined by the acl statement.
address_match_list A list of one or more of the following elements:
  • ip_addr
  • ip_prefix
  • key_id
  • acl_name

See Section 6.5.2 for more information.

domain_name A quoted string that will be used as a DNS name. For example:

dotted_decimal One to four integers valued 0 through 255 and separated by dots, such as 123, 45.67 or
ip4_addr An IPv4 address with exactly four elements in dotted decimal notation.
ip6_addr An IPv6 address, such as 2001:db8::1234 . IPv6 scoped addresses that have ambiguity on their scope zones must be disambiguated by an appropriate zone ID with the percent character (`%') as delimiter. HP strongly recommends using string zone names rather than numeric identifiers, in order to be robust against system configuration changes. However, because there is no standard mapping for such names and identifier values, currently only interface names as link identifiers are supported, assuming one-to-one mapping between interfaces and links. For example, a link-local address fe80::1 on the link attached to the interface ne0 can be specified as fe80::1%ne0. Note that on most systems link-local addresses always have the ambiguity, and need to be disambiguated.
ip_addr An ip4_addr or ip6_addr .
ip_port An IP port number from 0 to 65535. Values below 1024 are restricted to well-known processes. In some cases, an asterisk (*) character can be used as a placeholder to select a random high-numbered port.
ip_prefix An IP network specified as an ip_addr , followed by a slash (/) and then the number of bits in the netmask. Trailing zeros in an ip_addr can be omitted. For example, 127/8 is the network with netmask and is network with netmask
key_id A domain name representing the name of a shared key, to be used for transaction security.
key_list A list of one or more key_id s, separated by semicolons and ending with a semicolon.
number A nonnegative integer with an entire range limited by the range of a C language signed integer (2,147,483,647 on a machine with 32-bit integers). Its acceptable value might be limited further by the context in which it is used.
path_name A quoted string that will be used as a path name. For example:

size_spec A number, the word unlimited , or the word default . The maximum value of size_spec is that of unsigned long integers on the machine. An unlimited size_spec requests unlimited use, or the maximum available amount. A default size_spec uses the limit that was in force when the server was started. A number can optionally be followed by a scaling factor:
  • K (or k ) for kilobytes, which scales by 1024
  • M (or m ) for megabytes, which scales by 1024*1024
  • G (or g ) for gigabytes, which scales by 1024*1024*1024

Integer storage overflow is silently ignored during conversion of scaled values, resulting in values less than intended, possibly even negative. Using the unlimited keyword is the best way to safely set a really large number.

yes_or_no Either yes or no . The words true and false are also accepted, as are the numbers 1 and 0.
dialup_option One of the following:
  • yes
  • no
  • notify
  • notify-passive
  • refresh
  • passive

When used in a zone, notify-passive , refresh , and passive are restricted to slave and stub zones.

6.5.2 Address Match Lists

Address match lists are primarily used to determine access control for various server operations. They are also used in the listen-on and sortlist statements. The following example shows the syntax of the address match list:

address_match_list = address_match_list_element ; 
  [ address_match_list_element; ... ] 
address_match_list_element = [ ! ] (ip_address [/length] | 
   key key_id | acl_name | { address_match_list } ) 

The elements that constitute an address match list can be any of the following:

Elements can be negated with a leading exclamation mark (!). The match list names any , none , localhost , and localnets are predefined. More information on those names can be found in the description of the acl statement (see Section

When a given IP address or prefix is compared to an address match list, the list is traversed in order until an element matches. The interpretation of a match depends on whether the list is being used for access control, defining listen-on ports, or as a topology, and whether the element was negated. Specifically:

Because of the first-match aspect of the algorithm, an element that defines a subset of another element in the list should come before the broader element, regardless of whether either is negated. For example, in 1.2.3/24; !; , the element is ignored, because the algorithm will match any lookup for to the 1.2.3/24 element. Using !; 1.2.3/24 corrects that problem by having blocked by the negation, while all other 1.2.3.* hosts fall through.

6.5.3 Configuration File Format

A BIND configuration file consists of statements and comments. Statements end with a semicolon. Many statements contain a block of substatements that also end with a semicolon. Table 6-3 describes the configuration statements.

Table 6-3 BIND Name Server Configuration Statements
Statement Description
acl Specifies a named IP address matching list, for access control and other uses.
controls Declares control channels to be used by the rndc utility.
include Includes a file.
key Specifies key information for use in authentication and authorization using TSIG. See Section 6.2.3 for more information.
logging Specifies what the server logs, and where the log messages are sent.
masters Defines a named masters list for inclusion in stub and slave zone masters clauses.
options Controls global server configuration options and sets defaults for other statements.
server Sets configuration options, and sets defaults for other statements.
trusted-keys Specifies trusted DNSSEC keys.
view Specifies a view.
zone Specifies a zone.

The following sample is a configuration file for a master server:

options { 
        directory "SYS$SPECIFIC:[TCPIP$BIND]"; 
        type master; 
        file "FRED_PARROT_BIRD_COM.DB"; 
zone "0.0.127.IN-ADDR.ARPA" in { 
        type master; 
        file "127_0_0.DB"; 
zone "LOCALHOST" in { 
        type master; 
        file "LOCALHOST.DB"; 
zone "208.20.16.IN-ADDR.ARPA" in { 
        type master; 
        file "208_20_16_IN-ADDR_ARPA.DB"; 
zone "." in { 
        type hint; 
        file "ROOT.HINT"; 

The following comment styles are valid in a BIND configuration file. Comments can appear anywhere in the file.


Do not use a semicolon (;) as a comment character in your configuration file. The semicolon indicates the end of a configuration statement; whatever follows is interpreted as the start of the next statement. The ACL Statement

The acl statement assigns a symbolic name to an address match list. It gets its name from a primary use of address match lists: access control lists (ACLs).


The access control lists used by the BIND service and OpenVMS ACLs are different structures with different purposes.

The acl statement is formatted as follows:

acl acl-name { 

Note that the address match list must be defined with acl before it can be used elsewhere; forward references are not allowed.

The following ACLs are created automatically:
ACL Matches
any All hosts
none No hosts
localhost The IPv4 and IPv6 addresses of all interfaces on the system
localnets Any host on an IPv4 or IPv6 network for which the system has an interface. The CONTROLS Statement

The controls statement declares control channels to be used by system administrators to affect the operation of the local name server. These control channels are used by the rndc utility to send commands to, and retrieve non-DNS results from, a name server. The controls statement is formatted as follows:

controls { 
   inet ( ip_addr | * ) [ port ip_port ] allow {  address_match_list  } 
                keys {  key_list  }; 
   [ inet ...; ] 

An inet control channel is a TCP/IP socket listening at the specified ip_port on the specified ip_addr , which can be either an IPv4 or IPv6 address. The asterisk character (*) is interpreted as the IPv4 wildcard address; connections are accepted on any of the system's IPv4 addresses. To listen on the IPv6 wildcard address, use :: for the ip_addr . If you use the rndc utility only on the local host, use the local loopback address ( , or :: ) for maximum security.

If no port is specified, port 953 is used. * cannot be used for ip_port.

The ability to issue commands over the control channel is restricted by the allow and keys clauses. Connections to the control channel are permitted based on the address match list. This is for simple IP address based filtering only; any key_id elements of the address_match_list are ignored.

The primary authorization mechanism of the command channel is the key_list , which contains a list of key_id s. Each key_id in the key_list is authorized to execute commands over the control channel. See Format of the RNDC.CONF File for information about configuring keys in rndc.

If no controls statement is present, the BIND server will set up a default control channel listening on the loopback address and its IPv6 counterpart ::1 . In this case, and also when the controls statement is present but does not have a keys clause, the BIND server attempts to load the command channel key from the file RNDC.KEY in TCPIP$ETC. To create a RNDC.KEY file, use the following command:

rndc_confgen -a 

See Section 6.10 for more information about using the rndc utility.

The RNDC.KEY feature eases the transition of systems from BIND Version 8, which did not have digital signatures on its command channel messages and thus did not have a keys clause. You can use an existing BIND Version 8 configuration file in BIND Version 9 unchanged, and rndc will work the same way that ndc worked in BIND Version 8.

Because the RNDC.KEY feature is only intended to allow the backward-compatible usage of BIND Version 8 configuration files, this feature does not have a high degree of configurability. You cannot easily change the key name or the size of the secret. You should make a RNDC.CONF file with your own key if you wish to change those things.

The UNIX control channel type of BIND Version 8 is not supported in BIND Version 9 and is not expected to be added in future releases. If it is present in the controls statement from a BIND Version 8 configuration file, it is ignored and a warning is logged.

To disable the command channel, use an empty controller statement. For example:

controls { }; The INCLUDE Statement

The include statement inserts the specified file at the point that the include statement is encountered. The include statement facilitates the administration of configuration files by permitting the reading or writing of some things but not others. For example, the statement could include private keys that are readable only by a name server. The following example shows the format of the include statement:

include filename; 

Previous Next Contents Index