Firewall Rules and DNS

At least two kinds of firewalls are available. The simplest is packet filtering firewalls, and at the more advanced end of the spectrum is firewalls such as FireWall-1, which maintains complete connection state engines capable of filtering traffic in a much more intelligent manner. A commercial, GUI-equipped firewall should be quite easy to set to allow DNS traffic to pass correctly. However, please check the documentation because it might have specific, not-so-obvious recommendations about DNS configuration that you should adhere to.

In the old days, when BIND 4 ruled the networks, setting up firewall rules for DNS was quite simple. Everything TCP and UDP, information coming from port 53, information addressed to port 53 was DNS server-to-DNS server traffic and should be let through. As long as the clients on the inside used only the inside DNS server, the queries would get through. BIND 8 changed this: It sends queries from a random port to port 53 on the server it's querying. Then, the reply comes back from port 53 to the same random port. So, now the correct rule is that any TCP or UDP packet destined to port 53, no matter what the origin is, is a DNS packet. To spell it out, you must open for inbound UDP destined for any UDP port, as long as it originates from port 53 on some machine; the query originates on a random UDP port on the inside. This is a good reason for having a DNS proxy on the firewall because allowing UDP packets into your internal network is very dangerous business, at least if UNIX computers are on your network. Most UNIX computers run quite insecure services over UDP. If you don't control the firewall or don't want a DNS proxy on the firewall, you can instruct BIND to use port 53 to query from. This re-establishes the behavior of BIND 4 and makes things a bit easier again:

 optons {     …     query-source port 53;     … }; 

If you don't have any recursive, resolving DNS servers on the inside, you will have a flock of machines on the inside trying to talk to a resolver on the outside. The inside machines will not be querying from port 53; the queries are generated by unprivileged processes and are forbidden to use port 53. The inside machines behave exactly like BIND 8, in other words (actually it's the other way around, BIND 8 is the late entrant; stub resolvers have always used high ports). So, again you must open up several ports, and again, this is insecure. It would be much more secure to just set up BIND on one of the internal hosts and have all the inside hosts use it, and indeed this is what most people with a firewall do, as should you.

It is important to note that while DNS usually uses UDP, it sometimes needs to use TCP. This happens whenever the amount of data to be transferred exceeds 512 bytes. 512 bytes was the maximum amount of payload in UDP packets dictated by the first RFCs, and it's still the limit. Zone transfers are always larger than 512 bytes, so make sure the firewall is open for the same TCP ports as UDP. It is, however, true that the internal DNS server always initiates queries itself, and that the query is answered on the same TCP connection. Therefore, no need exists to open for incoming TCP SYN packets, unless someone on the outside needs to perform zone transfers through the firewall, of course.