BIND 9.3.2 Features

• “DNSSEC Implementation Based on RFC 4033, 4034, and 4035”

• “Support for the ip6.arpa Domain”

• “New Method of Listing Master Servers”

• “New Options in the options Statement”

• “New Option to Configure the Ordering of Records”

• “New Option to Set the Advertized EDNS UDP Buffer Size”

• “New Option to Restrict the Character Set of Domain Names”

• “New Options to Enable and Disable IXFR”

• “Transition Support for IPv4 and IPv6”

• “New Commands in the rndc Utility”

• “New Option in the zone Statement”

• “New Command-Line Options”

• “Supports RFC 4193 (Unique Local IPv6 Unicast Addresses)”

DNSSEC Implementation Based on RFC 4033, 4034, and 4035

Starting with BIND 9.3.2, the Domain Name System Security Extensions (DNSSEC) feature implements the standards specified in RFC 4033 (DNS Security Introduction and Requirements), 4034 (Resource Records for the DNS Security Extensions), and 4035 (Protocol Modifications for the DNS Security Extension). The DNSSEC implementation provides the following new features:

Support for the ip6.arpa Domain

BIND 9.3.2 uses the ip6.arpa domain for IPv6 forward lookups, instead of the ip6.int domain. However, BIND 9.3.2 continues to support the ip6.int domain for backward compatibility. BIND 9.3.2 also uses the ip6.arpa domain for storing IPv6 addresses in the DNS. The existing queries that perform additional section processing to locate IPv4 addresses are redefined to perform additional section processing on both IPv4 and IPv6 addresses.

The ip6.arpa domain is a special domain defined to look up a record given an IPv6 address. This domain provides a method to map an IPv6 address to a host name.

An IPv6 address is represented as a name in the ip6.arpa domain by a sequence of nibbles separated by dots with the suffix .ip6.arpa. The sequence of nibbles is encoded in reverse order wherein the low-order nibble is encoded first, followed by the next low-order nibble and so on. Each nibble is represented by a hexadecimal digit.

For example, consider the following IPv6 address:

4321:0:1:2:3:4:567:89ab

Following is the reverse lookup domain name in the ip6.arpa domain:

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.arpa. 

New Method of Listing Master Servers

Starting with BIND 9.3.2, the masters statement provides a list of master name servers that can be included in the masters clause of the zone statement.

Following is the masters statement with the new masters_list option, which specifies the acl name of the list of master name servers:

masters name [port ip_port] {(masters_list | ip_addr [port ip_port] [key key]); [...]};

The masters_list option specifies one or more IP addresses of master servers, which the slave can contact to update its copy of the zone. The masters_list elements can also be names of other master lists. This list can be used in the masters clause in the zone statement.

Following is a sample acl statement that assigns a symbolic name to an address match list:

acl acl1 {
         15.70.190.186; 15.70.190.115;
         };

Following is a sample zone statement with the masters clause:

zone "example.com" { 
type slave; 
masters {acl1;};
file "db.example";
};

Where:

acl1 specifies the name of the list of master name servers.

New Options in the options Statement

Table 1-3 lists the new options added in the options statement.

New Option to Configure the Ordering of Records

The new rrset-order option in the options statement enables you to configure the ordering of the records in a multiple-record response. When the name server returns multiple records in a response, it is useful to configure the order of the records placed into the response.

Following is the syntax of the rrset-order option:

Where, an order_spec can be defined as follows:

The default value for class and type is ANY, and for name is *.

The valid values for ordering are:

Following is an example of the rrset-order option:

rrset-order {
        class IN type A name "host.example.com" order random;
         order cyclic;
};

This rrset-order option causes responses for type A records in class IN that have host.example.com as a suffix, to be returned in random order. Other types of records are returned in cyclic order.

If the options statement contains multiple rrset-order options, they are not combined but only the last rrset-order option is used.

New Option to Set the Advertized EDNS UDP Buffer Size

The edns-udp-size option in the options statement sets the advertised Extended DNS (EDNS) User Datagram Protocol (UDP) buffer size to enable UDP answers to pass through broken firewalls that block fragmented packets greater than 512 bytes. The valid range of values is 512 to 4096 bytes (values not in this range are adjusted appropriately). The default value of this option is 4096 bytes.

New Option to Restrict the Character Set of Domain Names

This check-names option in the options statement restricts the character set and syntax of certain domain names in the master files and DNS responses. The rules for valid host names or mail domains are derived from RFC 952 (DoD Internet Host Table Specification) and RFC 821 (Simple Mail Transfer Protocol) as modified by RFC 1123 (Requirements for Internet Hosts - Application and Support). The check-names option checks the names of the owner names of A, AAAA, and MX records and also checks domain names in the RDATA of NS, SOA, and MX records. It also applies to the RDATA of PTR records where the owner name indicates that it is a reverse lookup of a hostname (the owner name ends with in-addr.arpa, ip6.arpa, or ip6.int).

The default value of the check-names option depends on the usage area. For master zones, the default value is fail. For slave zones, the default value is warn. For an answer (response) received from the network, the default value is ignore.

New Options to Enable and Disable IXFR

In BIND 9.3.2, the incremental zone transfer (IXFR) feature is enabled by default. describes the new options available in the options statement that can be used to enable and disable IXFR.

Transition Support for IPv4 and IPv6

BIND 9.3.2 provides transition support for IPv4 and IPv6 to solve the problem caused by lack of support for either IPv4 or IPv6 address on a host system. It also provides the dual-stack-servers option to enable the transition support for IPv4 and IPv6 addresses. This option specifies host names or addresses of systems that access both IPv4 and IPv6 transports. If the host name is specified, a name server must be able to resolve a host name by using only the transport supported by the name server. If the dual-stack-servers option is used in dual-stacked system, this option does not have any influence if access to the IPv4 or IPv6 transport is disabled on the command line using the named -4 command or named -6 command, respectively.

The syntax for the dual-stack-servers option in the options statement in the /etc/named.conf file is as follows:

New Commands in the rndc Utility

The following are new commands in the remote name daemon control (rndc) utility:

For more information on these commands, see rndc(1). A sample rndc.conf file is distributed with this release of BIND in the /usr/examples/bind directory. This file can be generated automatically using the rndc-confgen utility, which is also distributed with BIND 9.3.2.

New Option in the zone Statement

The delegation-only option is added to the zone statement. You can use this option to enforce the delegation-only status of infrastructure zones (for example, COM, NET, and ORG). Any answer that a name server receives without an explicit or implicit delegation in the authority section is treated as NXDOMAIN, which indicates that a host name is not found. The NXDOMAIN response is the type of response sent by the name server.

New Command-Line Options

Table 1-5 lists the new command-line options for the various binaries and tools in BIND 9.3.2.

Supports RFC 4193 (Unique Local IPv6 Unicast Addresses)

BIND 9.3.2 (C.9.3.2.5.0) for the HP-UX 11i v3 operating system conforms to RFC 4193 (Unique Local IPv6 Unicast Addresses). RFC 4193 defines a format for the unique local IPv6 unicast address that is globally unique and not intended for external networks. When named receives an unique local IPv6 unicast address for resolution, it does not send this address to the global DNS server for resolution. Instead, it returns the NXDOMAIN response message by default. As a result, the unique local IPv6 unicast addresses are never exposed to the outside network and are not accessible by external systems.