3

We're running Bind as a Caching-Nameserver and these are the 3 rules on our setup to handle the DNS functionality:

iptables -A INPUT -s $OUR_NETWORK -p udp --destination-port 53 -j ACCEPT
iptables -A INPUT -s $OUR_NETWORK -p tcp --destination-port 53 -j ACCEPT
iptables -A INPUT -p udp --source-port 53 -m state --state ESTABLISHED,RELATED -j ACCEPT

The first two rules are for our clients. Notice that I included TCP even though we don't allow zone-transfers since we're not hosting any zones (but I noticed some legitimate clients doing queries via TCP) and that's the reason I included it.

My question is regarding the third line. This line is for the response from upstream DNS servers (responses to our recursive queries). I thought this line was sufficient but then I noticed on the log (packets I drop that don't match any ALLOW line) that there were dozens of UDP packets coming from source-port UDP/53.

My initial thoughts were:

1) these are legitimate responses from other DNS servers that the connection-tracking of my system didn't recognized as "related"

2) these are legitimate responses but they're "late responses" and thus my system didn't recognize them.

What rule do you use for the responses on you caching nameservers? Should I allow ANY by matching just the incoming source-port udp/53 regardless of state? Do you use the connection-tracking mechanism (ESTABLISHED, RELATED) for udp?

All the best, JFA

3 Answers3

3

IMHO, you should specifically permit egress DNS queries on your OUTPUT chain (on both UDP and TCP, of course), and then drop the port- and protocol- specific flags from the RELATED ingress rule, e.g.:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Or, in other words, use egress policy to control outbound traffic on a per-protocol basis, and stateful matching to control the inbound responses.

The default RHEL/CentOS iptables rules work like this, albeit they default to permit any OUTPUT packet.

And yes, you will quite often see rejected packets because they were too late to match the stateful matching.

Alnitak
  • 20,901
  • 3
  • 48
  • 81
1

Connection tracking and UDP doesn't make any sense. There is no connection to track as UDP is a connectionless protocol.

To be fully RFC compliant, you must listen on port 53 for both tcp and udp traffic.

https://www.rfc-editor.org/rfc/rfc5966

Community
  • 1
dmourati
  • 24,720
  • 2
  • 40
  • 69
0

TCP is used when the query is over 512 bytes in size, which as you say is usually for zone transfers and the like, but you'll sometimes see legitimate clients doing this too.

The reason you're seeing a lot of connections from udp/53 is because a lot of nameservers are configured to respond on that port, as opposed to a random high port. If I was you, I'd allow udp/53 from the upstream DNS servers and leave it at that.

Andy Smith
  • 1,798
  • 13
  • 15
  • Replying to my own answer, but you might find the conntrack tools (http://www.netfilter.org/projects/conntrack-tools/index.html) useful for viewing and managing the conntrack tables. – Andy Smith Feb 08 '10 at 15:45
  • Actually, TCP is used when the packet is _truncated_. With the use of EDNS0 (RFC 2671) that is not always at 512 bytes. – Alnitak Feb 09 '10 at 12:55
  • Ah, fair enough... my mistake :-) – Andy Smith Feb 15 '10 at 18:30