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
Configuration information	UCX$CONFIGURATION.DAT	TCPIP$BIND.CONF
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
Cache file	NAMED.CA	ROOT.HINT

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

• SYS$STARTUP:TCPIP$BIND_STARTUP.COM allows you to start the BIND service.
• SYS$STARTUP:TCPIP$BIND_SHUTDOWN.COM allows you to shut down the BIND service.

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

• SYS$STARTUP:TCPIP$BIND_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the BIND service is started.
• SYS$STARTUP:TCPIP$BIND_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the BIND service is shut down.

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: "my.test.domain"
dotted_decimal	One to four integers valued 0 through 255 and separated by dots, such as 123, 45.67 or 89.123.45.67.
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 127.0.0.0 with netmask 255.0.0.0 and 1.2.3.0/28 is network 1.2.3.0 with netmask 255.255.255.240.
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: "SYS$SPECIFIC:[TCPIP$BIND]"
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:

• An IP address (IPv4 or IPv6)
• An IP prefix (in the / notation)
• A key ID, as defined by the key statement
• The name of an address match list previously defined with the acl statement
• A nested address match list enclosed in braces

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 6.5.3.1).

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:

• When used as an access control list, a non-negated match allows access and a negated match denies access. If there is no match, access is denied. The following options use address match lists for this purpose:
  • allow-notify
  • allow-query
  • allow-update-forwarding
  • allow-transfer
  • allow-update
  • blackhole
  
  The listen-on option causes the server not to accept queries on any of the machine's addresses that do not match the list.

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; ! 1.2.3.13; , the 1.2.3.13 element is ignored, because the algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24 element. Using ! 1.2.3.13; 1.2.3/24 corrects that problem by having 1.2.3.13 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]"; }; zone "FRED.PARROT.BIRD.COM" in { 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.

• C-style comments that start with /* and end with */
• C++ style comments that start with // and continue to the end of the physical line
• Shell or Perl-style comments that start with # and continue to the end of the physical line

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 acl statement is formatted as follows:

acl acl-name { address_match_list };

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.

6.5.3.2 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 ( 127.0.0.1 , 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 127.0.0.1 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 { };

6.5.3.3 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;