Jump to content

How to configure a name server to work with a firewall (or vice versa)

+ 2
  cricketliu's Photo
Posted Sep 15 2009 10:20 AM

If you want to configure a name server to work through a firewall, or configure a firewall to work with a name server, 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.

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. 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;

};

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.

For NOTIFY messages, BIND 9.1.0 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.

DNS & Bind Cookbook

Learn more about this topic from DNS & Bind Cookbook.

The DNS & BIND Cookbook presents solutions to the many problems faced by network administrators responsible for a name server. This title is an indispensable companion to DNS & BIND, 4th Edition, the definitive guide to the critical task of name server administration. The cookbook contains dozens of code recipes showing solutions to everyday problems, ranging from simple questions, like, "How do I get BIND?" to more advanced topics like providing name service for IPv6 addresses.

See what you'll learn


Tags:
1 Subscribe


3 Replies

 : Mar 05 2010 01:54 PM
What's the rationale behind blocking queries from (and responses to) remote ports below 1024?

While I supposedly have full control over the client ports used by my own name server as well as other machines on my network, I generally find attempts to discriminate between remote clients based on the port numbers they assign for themselves pointless at best, and self-deceptive at worst. It provides no protection against intruders or DDoS attacks, but it may block otherwise legit traffic from oddly configured client hosts. Or does a client using a "privileged" port in its own end constitute a protocol violation? Which RFC or STD document should I read? I think I stopped browsing the RFC index for news more than ten years ago...

And by the way, shouldn't "Queries from/Responses to remote name servers" in the above table rather read "Queries from/Responses to remote clients"? While you may of course in reality have two BIND server hosts talking to each other, one of them is then acting as a client, and your firewall has no way of finding out what kind of client the remote host really is.
 : Mar 03 2011 05:15 PM
What's the matter? Doesn't a poster deserve a reply or doesn't O'Reilly give a hoot?
+ 1
  cricketliu's Photo
Posted Mar 07 2011 10:27 AM

I can't speak for O'Reilly, but I give a hoot. I just wasn't aware of the question.

There's no rationale for blocking queries from and responses to remote ports below 1024. In fact, my home firewall's configuration allows queries from any port (though in fact BIND won't source queries from just any port) and responses to any port. I suppose it was just BIND-induced myopia on my part when I wrote the original answer. As you correctly point out, non-BIND implementations of DNS servers could use other source ports.

And yes, "remote DNS clients" would have been correct.