7.3 Configuring a Name Server to Work with a Firewall (or Vice Versa)

7.3.1 Problem

You want to configure a name server to work through a firewall, or configure a firewall to work with a name server.

7.3.2 Solution

Configure your firewall to pass the UDP and TCP traffic that a BIND name server requires. This matrix shows you the traffic necessary for each purpose.

Purpose	Protocol	Source address	Source port	Destination address	Destination port
Queries from your name server	UDP or TCP	Your name server	> 1023	Any	53
Responses to your name server	UDP or TCP	Any	53	Your name server	> 1023
Queries from remote name servers	UDP or TCP	Any	> 1023	Your name server	53
Responses to remote name servers	UDP or TCP	Your name server	53	Any	> 1023

Refresh queries -- the queries a slave name server sends to its master name server to see if a zone's serial number has increased -- and NOTIFY messages are also sent from a high-numbered port (above 1023) to port 53.

7.3.3 Discussion

Normally, BIND name servers choose a source port to use for outbound queries when they start, which means you must allow DNS messages from any unprivileged port. However, you can configure a name server to use a particular source port for outbound queries with the query-source options substatement. (On BIND 8 name servers, query-source also controls the source port for NOTIFY messages and refresh queries.) For example, to instruct a name server to use port 1053 as the source port for all outbound queries, use:

options {
    directory "/var/named";
    query-source address * port 1053;
};

This may let you simplify the firewall rules somewhat, because you can limit outbound, UDP-based query traffic to a single source port. If the name server has multiple network interfaces, you can also use the query-source substatement to choose which source address it uses in queries. For example, to tell a name server to use 192.168.0.1 as the source address in queries, use:

options {
    directory "/var/named";
    query-source address 192.168.0.1;
};

You can specify both the source address and source port, too:

options {
    directory "/var/named";
    query-source address 192.168.0.1 port 1053;
};

If you run a BIND 9 name server, use the transfer-source substatement in a zone, view or options statement to specify the source port used in refresh queries and forwarded dynamic updates. For example:

zone "foo.example" {
    type slave;
    masters { 192.168.0.1; };
    file "bak.foo.example";
    transfer-source * port 1053;
};

This tells the name server to use port 1053 as the source for all refresh queries and dynamic updates it forwards. The port specification doesn't apply to zone transfers, however, that use TCP; for TCP-based traffic, the source port is always chosen randomly. The address specification (here, "*") does apply to the source address of TCP zone transfer requests, though.

On BIND 8 name servers, transfer-source is only a zone substatement until BIND 8.2.2, when it's also supported as an options substatement. It only sets the source address used in zone transfers (that is, you can't specify a port argument):

options {
    directory "/var/named";
    transfer-source 192.168.0.2;
};

For NOTIFY messages, BIND 9.1.0 and later and BIND 8.3.2 and later name servers understand the notify-source substatement, which has the same argument syntax as transfer-source and can also be used as a zone, view, or options substatement.

Remember that queries can be TCP-based as well as UDP-based, so you must allow traffic from queriers to TCP port 53 as well as UDP port 53, and from your name server to TCP port 53.

7.3.4 See Also

"Configuring the IPv4 Transport" in Chapter 10 of DNS and BIND.