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