BIND 9
name servers can use both IPv4 and IPv6 as a transport; that is, they
can send and receive queries and responses over IPv4 and IPv6. BIND 8
name servers support only IPv4 as a transport. However, both name
servers support similar substatements to configure which network
interfaces and ports they listen on and send queries from.
10.15.1. Configuring the IPv4 Transport
You can specify which network
interface your BIND 8 or BIND 9 name server listens on for queries
using the
listen-on
substatement. In its simplest form,
listen-on takes an address match list as an
argument:
options {
listen-on { 192.249.249/24; };
};
The name server listens on any of the local host's network
interfaces whose addresses match the address match list. To specify
an alternate port (one other than 53) to listen on, use the
port modifier:
options {
listen-on port 5353 { 192.249.249/24; };
};
In BIND 9, you can even specify a different port for each network
interface:
options {
listen-on { 192.249.249.1 port 5353; 192.253.253.1 port 1053; };
};
Note that there's no way to configure most resolvers to query a
name server on an alternate port, so this name server might not be as
useful as you'd think. Still, it can serve zone transfers,
because you can specify an alternate port in a
masters
substatement:
zone "movie.edu" {
type slave;
masters port 5353 { 192.249.249.1; };
file "bak.movie.edu";
};
Or, if your BIND 9 name server has multiple master name servers, each
listening on a different port, you can use something like:
zone "movie.edu" {
type slave;
masters { 192.249.249.1 port 5353; 192.253.253.1 port 1053; };
file "bak.movie.edu";
};
BIND 9 even allows you to send your
NOTIFY messages to alternate ports. To
tell your master name server to notify all its slave name servers on
the same oddball port, use:
also-notify port 5353 { 192.249.249.9; 192.253.253.9; }; // zardoz's two addresses
To notify each on a different port, use:
also-notify { 192.249.249.9 port 5353; 192.249.249.1 port 1053; };
If your slave name server needs to use a particular local network
interface to send queries -- perhaps because one of its master
name servers recognizes it by only one of its many
addresses -- use the
query-source
substatement:
options {
query-source address 192.249.249.1;
};
Note that the argument isn't an address match list; it's
a single IP address. You can also specify a particular source port to
use for queries:
options {
query-source address 192.249.249.1 port 53;
};
BIND's default behavior is to use whichever network interface
the route to the destination points out and a random, unprivileged
port, i.e.:
options {
query-source address * port *;
};
Note that
query-source applies only to UDP-based
queries; TCP-based queries always choose the source address according
to the routing table and use a random source port.
There's an analogous transfer-source
substatement that controls the
source address to use for zone transfers. In BIND 9, it also applies
to a slave name server's SOA queries and to forwarded dynamic
updates:
options {
transfer-source 192.249.249.1;
};
As with
query-source, the argument is just a
single IP address, but with no
address keyword.
With BIND 8, there's no
port modifier.
With BIND 9, you can specify a source port:
options {
transfer-source 192.249.249.1 port 1053;
};
However, that source port applies only to UDP-based traffic (i.e.,
SOA queries and forwarded dynamic updates).
transfer-source can also be used as a
zone substatement, in which case it applies only
to transfers (and, for BIND 9, SOA queries and dynamic updates) of
that zone:
zone "movie.edu" {
type slave;
masters { 192.249.249.3; };
file "bak.movie.edu";
transfer-source 192.249.249.1; // always use IP address on same network
// for transfers of movie.edu
};
Finally, as of BIND 9.1.0, there's even a substatement that
lets you control which address you send
NOTIFY messages from, called
notify-source. This comes in handy with
multihomed name servers since slaves only accept NOTIFY messages for
a zone from IP addresses in that zone's
masters
substatement.
notify-source's
syntax is similar to the syntax of the other -
source
substatements; for example:
options {
notify-source 192.249.249.1;
};
As with
transfer-source,
notify-source can specify a source port and can
be used as a
zone statement to apply only to
that zone:
zone {
type slave;
masters { 192.249.249.3; };
file "bak.movie.edu";
notify-source 192.249.249.1 port 5353;
};
10.15.2. Configuring the IPv6 Transport
By default, a BIND 9 name server
won't listen for IPv6-based queries. To configure it to listen
on the local host's IPv6 network interfaces, use
the
listen-on-v6
substatement:
options {
listen-on-v6 { any; };
};
Unlike its IPv4 counterpart, the
listen-on-v6
substatement accepts only
any and
none as arguments. You can, however, configure a
BIND 9 name server to listen on an alternate port -- or even
multiple ports -- with the
port modifier:
options {
listen-on-v6 port 1053 { any; };
};
The default port is, of course, 53.
You can also determine which IPv6 address your name server uses as
the source port for outgoing queries with the
transfer-source-v6
substatement, as in:
options {
transfer-source-v6 222:10:2521:1:210:4bff:fe10:d24;
};
or:
options {
transfer-source-v6 port 53 222:10:2521:1:210:4bff:fe10:d24;
};
The default is to use the source address corresponding to whichever
network interface the route points out and a random, unprivileged
source port. As with
transfer-source, you can
use
transfer-source-v6 as a
zone
substatement. And the source port applies only to SOA queries and
forwarded dynamic updates.
Finally, BIND 9.1.0 and later let you determine which IPv6 address to
use in NOTIFY messages, à la the
notify-source substatement. The IPv6
substatement is called, not surprisingly,
notify-source-v6:
options {
notify-source-v6 222:10:2521:1:210:4bff:fe10:d24;
};
As with
transfer-source-v6, you can specify a
source port and use the substatement in a
zone
statement.