4.8. IPv6 Support in BIND 9

BIND 9 fully supports all currently defined forms of IPv6 name to address and address to name lookups. It will also use IPv6 addresses to make queries when running on an IPv6 capable system.

For forward lookups, BIND 9 supports both A6 and AAAA records. The use of AAAA records is deprecated, but it is still useful for hosts to have both AAAA and A6 records to maintain backward compatibility with installations where AAAA records are still used. In fact, the stub resolvers currently shipped with most operating system support only AAAA lookups, because following A6 chains is much harder than doing A or AAAA lookups.

For IPv6 reverse lookups, BIND 9 supports the new "bitstring" format used in the ip6.arpa domain, as well as the older, deprecated "nibble" format used in the ip6.int domain.

BIND 9 includes a new lightweight resolver library and resolver daemon which new applications may choose to use to avoid the complexities of A6 chain following and bitstring labels, see Chapter 5.

For an overview of the format and structure of IPv6 addresses, see Section A.3.1.

4.8.1. Address Lookups Using AAAA Records

The AAAA record is a parallel to the IPv4 A record. It specifies the entire address in a single record. For example,

$ORIGIN example.com.
host            3600    IN      AAAA    3ffe:8050:201:1860:42::1

While their use is deprecated, they are useful to support older IPv6 applications. They should not be added where they are not absolutely necessary.

4.8.2. Address Lookups Using A6 Records

The A6 record is more flexible than the AAAA record, and is therefore more complicated. The A6 record can be used to form a chain of A6 records, each specifying part of the IPv6 address. It can also be used to specify the entire record as well. For example, this record supplies the same data as the AAAA record in the previous example:

$ORIGIN example.com.
host            3600    IN      A6      0 3ffe:8050:201:1860:42::1

4.8.2.1. A6 Chains

A6 records are designed to allow network renumbering. This works when an A6 record only specifies the part of the address space the domain owner controls. For example, a host may be at a company named "company." It has two ISPs which provide IPv6 address space for it. These two ISPs fully specify the IPv6 prefix they supply.

In the company's address space:

$ORIGIN example.com.
host            3600    IN      A6      64 0:0:0:0:42::1 company.example1.net.
host            3600    IN      A6      64 0:0:0:0:42::1 company.example2.net.

ISP1 will use:

$ORIGIN example1.net.
company         3600    IN      A6      0 3ffe:8050:201:1860::

ISP2 will use:

$ORIGIN example2.net.
company         3600    IN      A6      0 1234:5678:90ab:fffa::

When host.example.com is looked up, the resolver (in the resolver daemon or caching name server) will find two partial A6 records, and will use the additional name to find the remainder of the data.

4.8.2.2. A6 Records for DNS Servers

When an A6 record specifies the address of a name server, it should use the full address rather than specifying a partial address. For example:

$ORIGIN example.com.
@               14400           IN      NS              ns0
                14400           IN      NS              ns1
ns0             14400           IN      A6              0 3ffe:8050:201:1860:42::1
ns1             14400           IN      A               192.168.42.1

It is recommended that IPv4-in-IPv6 mapped addresses not be used. If a host has an IPv4 address, use an A record, not an A6, with ::ffff:192.168.42.1 as the address.

4.8.3. Address to Name Lookups Using Nibble Format

While the use of nibble format to look up names is deprecated, it is supported for backwards compatiblity with existing IPv6 applications.

When looking up an address in nibble format, the address components are simply reversed, just as in IPv4, and ip6.int. is appended to the resulting name. For example, the following would provide reverse name lookup for a host with address 3ffe:8050:201:1860:42::1.

$ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.int.
1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0   14400 IN      PTR     host.example.com.

4.8.4. Address to Name Lookups Using Bitstring Format

Bitstring labels can start and end on any bit boundary, rather than on a multiple of 4 bits as in the nibble format. They also use ip6.arpa rather than ip6.int.

To replicate the previous example using bitstrings:

$ORIGIN \[x3ffe805002011860/64].ip6.arpa.
\[x0042000000000001/64]         14400   IN      PTR     host.example.com.

4.8.5. Using DNAME for Delegation of IPv6 Reverse Addresses

In IPV6, the same host may have many addresses from many network providers. Since the trailing portion of the address usually remains constant, DNAME can help reduce the number of zone files used for reverse mapping that need to be maintained.

For example, consider a host which has two providers (example.net and example2.net) and therefore two IPv6 addresses. Since the host chooses its own 64 bit host address portion, the provider address is the only part that changes:

$ORIGIN example.com.
host                    IN      A6      64      ::1234:5678:1212:5675 cust1.example.net.
                        IN      A6      64      ::1234:5678:1212:5675 subnet5.example2.net.
$ORIGIN example.net.
cust1                   IN      A6      48      0:0:0:dddd:: ipv6net.example.net.
ipv6net                 IN      A6      0       aa:bb:cccc::
$ORIGIN example2.net.
subnet5                 IN      A6      48      0:0:0:1:: ipv6net2.example2.net.
ipv6net2                IN      A6      0       6666:5555:4::

This sets up forward lookups. To handle the reverse lookups, the provider example.net would have:

$ORIGIN \[x00aa00bbcccc/48].ip6.arpa.
\[xdddd/16]             IN      DNAME           ipv6-rev.example.com.

and example2.net would have:

$ORIGIN \[x666655550004/48].ip6.arpa.
\[x0001/16]             IN      DNAME           ipv6-rev.example.com.

example.com needs only one zone file to handle both of these reverse mappings:

$ORIGIN ipv6-rev.example.com.
\[x1234567812125675/64] IN      PTR             host.example.com.