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 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.
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.
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).
As a precursor to replication, some "zone transfer" clients also perform an ordinary SOA lookup. "zone transfer" clients fall into three categories:
"zone transfer" clients that don't do this extra SOA lookup at all, but just get straight on with what you actually asked them to do:
These clients require nothing extra beyond the hole required for "zone transfer" itself.
"zone transfer" clients that perform the ordinary SOA lookup using their own hardwired proxy DNS service:
These are vain "trying to wear all of the hats at once" server softwares. If best practice has been followed, these softwares will be performing only content DNS service in this instance, with proxy DNS service being provided elsewhere. As such, the proxy DNS service entwined within these softwares will not be the same as the proxy DNS service used by the rest of the system.
For these, you must also have a suitable shape of hole knocked into your firewall for the "zone transfer" client's own proxy DNS service, whatever that may be, to operate.
"zone transfer" clients that perform the ordinary SOA lookup using the same system-default proxy DNS service as used by other DNS client programs. There are no "zone transfer" clients in this category, sadly enough. But if there were:
For these, you must also have a suitable shape of hole knocked into your firewall for the system-default proxy DNS service, whatever you have configured that to be, to operate.
"zone transfer" clients that perform the ordinary SOA lookup over the same DNS/TCP connection that they then perform the actual "zone transfer" over:
These clients require nothing extra beyond the hole required for "zone transfer" itself.
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) .
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) .
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) .
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.
dnscache from Daniel J. Bernstein's
djbdns can be forced to use
a specific local IP address by setting the $IPSEND
environment variable.
query-source configuration
directive.
dnsfcpd and dnsrcpd from
the Internet Utilities for OS/2
can be forced to use a specific local IP address by using the
/CLIENTIP command-line option.
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.
tcpclient from Daniel J. Bernstein's
UCSPI-TCP, which is what
axfr-get from Daniel J. Bernstein's
djbdns uses, can be forced to
use a specific local IP address by using the -i option.
dnsgetz from
the Internet Utilities for OS/2
can be forced to use a specific local IP address by using the
/CLIENTIP command-line option.