10.15 Addresses and Ports

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.