The DNS-shaped holes that one cuts into firewalls.

You've come to this page because you've asked a question similar to the following:

What shape of hole should I knock into my firewall in order to allow my DNS servers to work through it ?

This is the Frequently Given Answer to that question.

The shape of hole that you knock into your firewall depends from what DNS servers are inside and what DNS servers are outside your firewall, and hence what the traffic that goes through the firewall actually is.

For incoming DNS queries about domains that you own and for service of "zone transfer" database replication requests, both handled by content DNS servers, there is one shape of hole:

For DNS database replication from peer content DNS servers using the "zone transfer" database replication mechanism, there is one shape of hole:

For outgoing DNS queries, handled by proxy DNS servers, there are several hole shapes:

How to knock holes into your firewall

How you knock holes into your firewall depends from your choice of firewall software. This page is not the answer to the (different) question:

How do I knock holes into my firewall ?

That question is (or certainly should be) answered in your firewall software's documentation (which is the proper place to look - there are far too many different firewall softwares in the world to address them on a page like this). This page tells you what the shapes of the holes should be, not how you form them with your particular choice of software.

External proxy DNS servers and "zone transfer" clients talking to an internal content DNS server

The DNS traffic through the firewall is between the resolving proxy DNS servers on the rest of Internet and any "zone transfer" clients associated with your peer content DNS servers, all outside of your firewall, and a content DNS server that is inside your firewall.

For the sake of example, let us say that the IP address that your content DNS server is listening on is 199.166.24.1.

You need to knock this shape of hole into your firewall:

Local Remote
IP address port(s) IP address port(s)
199.166.24.1 53 Any 53 and 1024–65535

If you know that you are not providing DNS/TCP service, then you only need make this hole for UDP. Otherwise, you must make this hole for both UDP and TCP.

If you are providing service for the "zone transfer" database replication mechanism, you are providing DNS/TCP service. Conversely, if you are not providing "zone transfer" service and if you have determined, from analysis of what data your content DNS server is serving up, that everything that you will ever serve will fit into a DNS/UDP datagram; then you do not need to provide DNS/TCP service.

When making this hole for TCP, you must permit TCP servers to listen for connections to the local port(s), but need not permit TCP clients to make connections from the local port(s).

Note: Cisco's Firewall Intrusion Detection system, in signatures #6051 and #6052, may block remote ports 53 and 1024–65535, respectively. Cisco portrays the latter as automatically malicious and the former not. In fact, many DNS server softwares, including Microsoft's DNS server for Windows and djbdns, perform "zone transfer" with remote ports (at the client) other than 53, and neither can be considered any more malicious than the other.

An internal "zone transfer" client replicating the database content from an external content DNS server

You have a slave content DNS server inside your firewall. The DNS database replication traffic through the firewall is between the "zone transfer" client associated with that server and a (peer) master content DNS server in the rest of Internet.

For the sake of example, let us say that your "zone transfer" client is using the IP address 199.166.24.1 as the local IP address for all datagrams that it sends [footnote] to the rest of Internet and the IP address of the peer content DNS server is 199.166.28.10.

With Daniel J. Bernstein's djbdns and the Internet Utilities for OS/2, you need to knock this shape of hole into your firewall:

Local Remote
IP address port(s) IP address port(s)
199.166.24.1 1024–65535 199.166.28.10 53

With Microsoft's DNS Server for Windows and ISC's BIND versions 4, 8, and 9, you need to knock this shape of hole into your firewall:

Local Remote
IP address port(s) IP address port(s)
199.166.24.1 53 and 1024–65535 199.166.28.10 53

"Zone Transfer" database replication uses mainly DNS/TCP. The AXFR transaction uses only DNS/TCP. However, the IXFR transaction (which only some "zone transfer" softwares even support) uses DNS/UDP falling back to DNS/TCP if necessary. Therefore, you must make this hole for both UDP and TCP.

When making this hole for TCP, you must permit TCP clients to make connections from the local port(s), but need not permit TCP servers to listen for connections to the local port(s).

The additional DNS transactions performed by "zone transfer" clients.

As a precursor to replication, some "zone transfer" clients also perform an ordinary SOA lookup. "zone transfer" clients fall into three categories:

An internal forwarding proxy DNS server talking to external proxy DNS server(s)

The DNS traffic through the firewall is between a forwarding caching proxy DNS server within your firewall and a set of proxy DNS servers that are on the outside of your firewall. Inside the firewall all of the DNS client libraries are configured to talk to the forwarding caching proxy DNS server.

For the sake of example, let us say that the IP addresses of the proxy DNS servers outside of your firewall are 10.53.0.1, 10.53.0.2, and 10.53.0.3, and that the IP address used by the forwarding proxy DNS server within your firewall as the local IP address of all datagrams that it sends to the external proxy DNS servers [footnote] is 192.168.53.1.

With Daniel J. Bernstein's djbdns, the Internet Utilities for OS/2, Microsoft's DNS Server for Windows, and ISC's BIND version 9, you need to knock this shape of hole into your firewall:

Local Remote
IP address port(s) IP address port(s)
192.168.53.1 1024–65535 10.53.0.1 53
192.168.53.1 1024–65535 10.53.0.2 53
192.168.53.1 1024–65535 10.53.0.3 53

With ISC's BIND versions 4 and 8, you need to knock this shape of hole into your firewall:

Local Remote
IP address port(s) IP address port(s)
192.168.53.1 53 10.53.0.1 53
192.168.53.1 53 10.53.0.2 53
192.168.53.1 53 10.53.0.3 53

You have no assurance that the responses to your queries from the external proxy DNS server will always be small enough for DNS/UDP, and that thus your forwarding proxy DNS server will never have to resort to DNS/TCP instead. Therefore, you must make this hole for both UDP and TCP.

When making this hole for TCP, you must permit TCP clients to make connections from the local port(s), but need not permit TCP servers to listen for connections to the local port(s) .

Internal DNS clients talking directly to external proxy DNS server(s)

It is better to use an intermediate forwarding proxy DNS server, through which all client requests are funnelled to the external proxy DNS server. The hole in the firewall is a lot smaller, since it involves just one IP address (that of the forwarding proxy server's back end) rather than many (all of the DNS clients).

The DNS traffic through the firewall is between your DNS client libraries and a set of proxy DNS servers that are on the outside of your firewall.

For the sake of example, let us say that the IP addresses of the proxy DNS servers outside of your firewall are 10.53.0.1, 10.53.0.2, and 10.53.0.3, and that all of your DNS client libraries use source IP addresses on the 192.168.*.* network.

You need to knock this shape of hole into your firewall:

Local Remote
IP address port(s) IP address port(s)
192.168.*.* 53 and 1024–65535 10.53.0.1 53
192.168.*.* 53 and 1024–65535 10.53.0.2 53
192.168.*.* 53 and 1024–65535 10.53.0.3 53

Some DNS client libraries, most notably Microsoft's DNS client for Windows and the DNS client library in the Internet Utilities for OS/2, allow one to control the local port number used by the client to send queries. If you make use of this ability, you can restrict the local port number accordingly.

You have no assurance that the responses to your queries from the external proxy DNS server will always be small enough for DNS/UDP, and that thus your DNS clients will never have to resort to DNS/TCP instead. Therefore, you must make this hole for both UDP and TCP.

When making this hole for TCP, you must permit TCP clients to make connections from the local port(s), but need not permit TCP servers to listen for connections to the local port(s) .

Internal resolving proxy DNS server talking to external content DNS servers

You have a resolving proxy DNS server inside your firewall. The DNS traffic through the firewall is between that server and the content DNS servers in the rest of Internet.

For the sake of example, let us say that your resolving proxy DNS server is using the IP address 212.72.34.66 as the local IP address for all datagrams that it sends [footnote] to the rest of Internet.

With Daniel J. Bernstein's djbdns, the Internet Utilities for OS/2, Microsoft's DNS Server for Windows, and ISC's BIND version 9, you need to knock this shape of hole into your firewall:

Local Remote
IP address port(s) IP address port(s)
212.72.34.66 1024–65535 Any 53

With ISC's BIND versions 4 and 8, you need to knock this shape of hole into your firewall:

Local Remote
IP address port(s) IP address port(s)
212.72.34.66 53 Any 53

You have no assurance that the responses to your queries from the rest of Internet's content DNS servers will always be small enough for DNS/UDP, and that thus your resolving proxy DNS server will never have to resort to DNS/TCP instead. Therefore, you must make this hole for both UDP and TCP.

When making this hole for TCP, you must permit TCP clients to make connections from the local port(s), but need not permit TCP servers to listen for connections to the local port(s) .

Local IP address used by proxy DNS servers when sending datagrams

Usually the local IP address will be whatever the operating system kernel picks by default as the local IP address when communicating with the rest of Internet. With some server softwares, this can be overriden and the server can be forced to use a specific local IP address.

Local IP address used by "zone transfer" clients when sending datagrams

Usually the local IP address will be whatever the operating system kernel picks by default as the local IP address when communicating with the rest of Internet. With some server softwares, this can be overriden and the server can be forced to use a specific local IP address.


© Copyright 2001–2004,2009 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.