BIND (Berkeley Internet Name Domain) is the most widely used implementation of DNS. It is developed by Internet Systems Consortium, Inc. (ISC), and is available as free software at ISC’s Web site, http://www.isc.org/bind/. BIND is also available at ISC’s FTP site, ftp://ftp.isc.org/isc/.
Right now, two major versions of BIND are mainly used: versions 8 and 9 (called BIND8 and BIND9, respectively).
All versions of BIND9 provide IPv6 transport support, as do 8.4 and later versions of BIND8. The implementation status of IPv6 content is a bit complicated. As seen in Section 3.3.6, some new standards of DNS contents for IPv6 were introduced and then deprecated. Some versions of BIND support the deprecated standard, and some others do not, as per the recent change in standardization. In any case, however, it is generally advisable to use the latest versions. The standardization status is now mature, and the latest implementations have already caught up to the latest standards.
Recall that three types of elements are commonly used in DNS operation: authoritative servers, caching servers, and stub resolvers. Any BIND package contains all three elements. A single network daemon called named provides the server function. The named daemon can act as an authoritative only server, a caching only server, and a server supporting both the roles simultaneously. On the other hand, a separate portable resolver library, often called libbind, provides the stub resolver function. The libbind library is actually adopted in many operating systems including BSD variants, and, in fact, the library routines seen in Section 3.4 were derived from libbind. Conversely, some IPv6 extensions to the original libbind developed by the KAME project were merged back into recent libbind implementations.
The rest of this topic will concentrate on the server side of BIND, primarily BIND9. It is the recommended version by ISC, particularly for advanced features such as IPv6 support. The support for IPv6 in BIND8 was provided for users who cannot upgrade to BIND9 for some reason, and is more limited than the IPv6 support in BIND9.10
The latest release version of BIND9, as of this writing, is 9.3, and is the main focus of this topic. The IPv6 support has been massively improved since 9.2, especially about the transport support. For example, BIND9 servers could not listen on a selected subset of IPv6 addresses for queries until 9.3. Also, BIND 9.2 was already in maintenance mode when the IETF obsoleted some IPv6 related protocol standards (Section 3.3.6), and still contains the deprecated protocol features.
Overview of BIND9
As already explained, BIND9 is the latest major release of BIND. While the configuration syntax is mostly compatible to BIND8, the implementation is totally different. In fact, BIND9 was designed and implemented from scratch. No code fragment in prior versions was used in the BIND9 implementation; the only exception is the stub resolver implementation, which is a copy of the corresponding part of BIND8. The stub resolver routines based on the BIND8 code is provided with the BIND9 package for the convenience of system developers who want to use the BIND9 program in their system while incorporating the resolver library to the same system.
In terms of technical features, BIND9 has the following characteristics:
• Full compliance to the latest DNS protocol standards
• IPv6 support, both for transport and contents
• Support for the DNS security extension (DNSSEC)
• Views, which can virtually provide multiple servers based on some properties of queries (e.g., source and/or destination address)
• Thread-based software architecture for better support for multiprocessor machines
Getting BIND9
BIND9 is, just like prior versions of BIND, open source software and is provided at ISC’s Web and FTP site free of charge. It is distributed under a BSD-style license, so users can freely modify the source code.
BIND9 is available at the following URL via FTP: ftp://ftp.isc.org/isc/bind9/VERSION/ bind-VERSION.tar.gz VERSION is 9.x.y where x and y are the major and minor versions within BIND9. For example, the source code of version 9.3.3 is available at ftp://ftp.isc.org/isc/bind9/ 9.3.3/bind-9.3.3.tar.gz
In the following discussion, if the BIND9 implementation is referred to as 9.x, the description applies to all 9.x.y versions. Minor versions are specified only when that particular version has some special behavior.
Building and Installing BIND9
BIND9 is highly portable, and it is usually easy to build and install. For many major operating systems, the installation procedure simply consists of the following steps:
The configure script should normally work fine without any command line options unless the user wants to specify nondefault install paths. In particular, IPv6 transport support is enabled by default; if there is any reason for disabling IPv6 transport, the —disable-ipv6 option should be specified for configure. The configure script also supports the —with-kame option. It was introduced when BSD did not officially support IPv6 so that BIND9 could be built on a KAME-patched BSD system for IPv6 transport, but this option is now meaningless. It should also be noted that the —disable-ipv6 option only affects the transport protocol for DNS transactions, and is irrelevant to the contents exchanged in the transactions. For example, even if the —disable-ipv6 option is specified, named will return AAAA resource records if it has the records of the query name.
On FreeBSD, which is the base operating system used in this topic, the BIND9 programs will be installed under /usr/local/bin and /usr/local/sbin by the above procedure. In particular, the named daemon should be available as /usr/local/sbin/named.
BIND9 has been incorporated in FreeBSD as a base component since 5.3-RELEASE. This can be confirmed by invoking /usr/sbin/named with the -v command line option.
Configuring BIND9 for IPv6 Operation
This section provides a brief overview of configuring a BIND9 server to support IPv6. Although Section 3.5.6 also provides a complete configuration that can be used in actual operation, neither section intends to provide a comprehensive description of BIND configuration; they concentrate on describing the IPv6-related parts. A general description of BIND configuration is beyond the scope of this topic. Those who need such information should consult other references such as [Liu06] and [Liu02].
The named.conf Configuration File
The BIND9 named daemon usually requires a configuration file. If BIND9 is built as a separate package as previously shown, the default path to the file is /usr/local/etc/named.conf. For those operating systems that incorporate BIND9 in their base systems, the default path depends on the system. On FreeBSD, it is /etc/namedb/named.conf.
The configuration file can specify a number of run-time parameters for named to operate and define zones for which the server has the authority. It consists of one or more statements, each of which often contains multiple substatements. Table 3-5 shows a summary of major statements used in the configuration file. These statements will appear in the succeeding examples.
Address Match Lists
To control DNS transport, an address match list is often required. In particular, an address match list is used to specify local IPv4 or IPv6 addresses to accept DNS queries. In general, an address match list can contain IPv4 addresses, IPv4 prefixes, IPv6 addresses, or IPv6 prefixes.
When a link-local IPv6 address or prefix is specified in an address match list, its link identifier must be given as well with the "%" notation.In this case, the BIND9 implementation assumes a one-to-one mapping between links and interfaces like the KAME implementation, and interface names can be used as a link identifier. For example, a link-local address fe80::1 on the link attached to interface fxp0 is represented as fe80::1%fxp0. Similarly, the prefix that contains all link-local addresses on this link is represented as fe80::%fxp0/10.
Some predefined keywords can also be used as an address match list element. Keyword any matches any possible address in the context, and none does not match any address. Keyword localhost matches all (IPv4 and IPv6) addresses configured on the system, and localnets matches all (IPv4 and IPv6) addresses covered by prefixes of local subnets.
TABLE 3-5
|
Statement |
Description |
|
options |
Specifies run-time operational parameters, including local IP addresses for incoming queries. |
|
controls |
Specifies control channel interfaces. |
|
zone |
Defines zones for which the server has the authority. |
|
view |
Defines a view (see Section 3.5.1). |
|
server |
Specifies nondefault parameters for a particular remote server. |
Some systems do not provide a way to determine local IPv6 subnet prefixes, and on them localnets has the same effect as localhost in terms of IPv6. Fortunately, FreeBSD provides this information and localnets works for IPv6 as expected.
Most of the above description is a new feature of BIND 9.3. Before 9.3, you could specify only any or none as local addresses to accept queries (see later). Also, localhost and localnets worked only for IPv4 addresses.
Enable Accepting IPv6 Queries
By default, named does not accept DNS queries over IPv6. The listen-on-v6 option is used to allow such queries. It should be specified in the options statement and/or in view statements.
The listen-on-v6 option takes an address match list containing IPv6 addresses or prefixes. The easiest way to accept queries over IPv6 is to add the following line in an appropriate place:
More specific configurations are also available. For example, to limit the local address that accepts queries to the loopback address only, the following configuration should be used instead:
Access Control
BIND9 named supports several options for access control purposes. These options generally take an address match list as an argument. Since an address match list equally accepts IPv4 and IPv6 addresses or prefixes, access control based on IPv6 addresses can be done just as access control based on IPv4 addresses.
For example, the following configuration limits the source address of a DNS query to the addresses that match 192.0.2.0/24 or 2001 :db8:1::/64:
A common access control policy for a caching server is to limit the source of the query to its local subnets. It can be done with the following configuration:
Recall that localnets matches both IPv4 and IPv6 addresses of local subnets.
The same configuration notation applies to the following options: allow-notify, allow-transfer, allow-recursion, and allow-update-forwarding.
Source Address Specification
BIND9 allows the user to specify a particular source address for some DNS transport operations. The configuration options for this purpose are separated for IPv4 and IPv6. In general, options for IPv6 transport have the naming convention xxx-source-v6 where xxx identifies a particular operation. The usage is the same as that of the corresponding options for IPv4.
For example, in order to specify 2 0 01 :db8::1 as the source address of DNS queries sent from the system, the following should be added:
Similarly, the following option specifies the IPv6 address 20 01 :db8::2 as the source address for zone transfers:
The same notation also applies to the options notify-source-v6 and alt-transfer-source-v6.
Server Address Specifications
In some cases, the IP address(es) of a remote DNS server must be specified in the configuration file. For example, to perform zone transfer, the IP address(es) of the master (primary) server must be specified in a zone-specific configuration. Both IPv4 and IPv6 addresses can be specified for these cases.
The following is an example of the zone transfer case. It specifies an IPv4 address 192.0.2.1 and an IPv6 address 2001 :db8::1 as master (primary) servers of a zone for which this system is acting as a slave (secondary):
In a masters statement an arbitrary number of IPv4 or IPv6 addresses can be specified. Of course, it can consist of addresses of a single address family, either IPv4 or IPv6.
This notation works for also-notify, forwarders, and dual-stack-servers. Similarly, either an IPv4 or an IPv6 address can be specified for a server statement, which defines characteristics of a particular remote server. For example, the following specifies not to use EDNS0 with the server that has an IPv6 address 2 0 01 :db8::1:
Other IPv6-Related Options
The following are other options that are related to the IPv6 operation.
preferred-glue This option specifies the preference of glue resource records when not all of them can be stored in a single UDP response due to the size limitation (see Section 3.3.4). For example, consider a zone kame.example that contains the following delegation:
That is, there are nine nameservers for a delegated zone child.kame.example, each of which has one A and one AAAA glue resource records.
The default limitation of UDP responses is usually too small to store all the glue resource records. By default, a BIND9 server returns some A records and some AAAA records when it returns a delegation to the child.kame.example zone. But if the following line is specified in the options statement:
then the response would contain all the A resource records and (possibly) some AAAA resource records.
Similarly, if the following line is specified:
then the response would probably contain as many AAAA records as possible and no A records.
This is a new feature in BIND 9.3. BIND 9.2 does not support this option.
Today it is generally advisable to specify the A record for preferred-glue. In fact, since most of the DNS (caching) server implementations that support IPv6 transport also support EDNS0 and responses to such servers will always contain a full set of glue records, this preference effectively does not have any negative impact on the caching servers; the cost at the authoritative server to handle the preference should be negligible. On the other hand, preferring A records will help older implementations that do not support IPv6 transport or EDNS0 when a response is large and some glue records must be omitted. In this case glue records of type A are clearly much more useful than AAAA glue records for these caching servers.
dual-stack-servers This option specifies the last resort forwarder for a single stack (i.e., either only IPv4 or only IPv6) caching server. Unlike the forwarders option, the caching server system normally tries to resolve names by itself in a recursive manner. However, if the system detects that a remote server cannot be reached due to address family mismatch (e.g., when the local system only has IPv4 connectivity but the remote server only has AAAA glue records), a forwarder specified in dual-stack-servers that has the missing connectivity will be used. This option does not have any effect on a dual stack node.
Note that in this context dual stack means the system can open both AF_INET and AF_INET6 sockets. This is always the case for the generic FreeBSD kernel even if the node does not have an IP address for the corresponding address family. Therefore, named must either be built with —disable-ipv6 or be invoked with the -4 option (see below for this option) in order to act as an IPv4-only node; similarly, named must be invoked with the -6 option in order to act as an IPv6-only node. Otherwise, it will be treated as a dual stack node and dual-stack-servers will not work as expected.
FIGURE 3-24
Figure 3-24 shows an example usage of a dual-stack forwarder. Recall the resolution procedure given in Figure 3-6,and assume the caching server is located in an IPv6-only network. In Figure 3-24 it is also assumed that the root server and the authoritative server of the example zone is reachable via IPv6, but the authoritative server of the kame.example zone is in an IPv4-only network.
In this case, the caching server can follow the delegation by directly sending (nonrecursive) queries to the root and the example zone servers. But since it cannot reach the kame.example zone server due to the IP version mismatch, the caching server contacts the kame.example zone server via the dual-stack forwarder with a recursive query.
Figure 3-24 shows an example usage of a dual-stack forwarder. Recall the resolution procedure given in Figure 3-6,and assume the caching server is located in an IPv6-only network. In Figure 3-24 it is also assumed that the root server and the authoritative server of the example zone is reachable via IPv6, but the authoritative server of the kame.example zone is in an IPv4-only network.
In this case, the caching server can follow the delegation by directly sending (nonrecursive) queries to the root and the example zone servers. But since it cannot reach the kame.example zone server due to the IP version mismatch, the caching server contacts the kame.example zone server via the dual-stack forwarder with a recursive query.
This is a new feature in BIND 9.3. BIND 9.2 does not support this option.
