What are the implications of using a default DROP rule on a public DNS server

Question

RHEL 6.6 authoritative DNS server. Right now in IPtables I have the INPUT chain defaulting to ACCEPT.

:INPUT ACCEPT [0:0]

I have been having some issues with it being attacked lately and I am just wondering what would be affected from a DNS service standpoint if I were to change the default policy to DROP?

:INPUT DROP [0:0]

I am also looking at doing this with the output chain as well but again my concern is since this is a public DNS server if I change this would there be negative implications in how the server communicates with other DNS servers doing things such as zone transfers, caching and things like that?

Just to give an idea of what I have now here is the contents of /etc/sysconfig/iptables.

*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1015316:198598633]
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s X.X.X.X/24 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -s X.X.X.X/18 -p icmp -m icmp --icmp-type 8 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -s X.X.X.X/32 -j DROP
-A INPUT -s X.X.X.X/32 -j DROP
-A INPUT -j DROP
-A OUTPUT -d X.X.X.X/20 -j DROP
COMMIT

Answer 1

Since you aren't being forthcoming about the nature of the attack you experienced, my advice will be likewise more generic.

• You're using --state, which loads the conntrack module. It's not common knowledge but this should always be considered an option of last resort with services that can expect to see a large volume of queries as part of normal operation. Once the session table fills your server will start dropping packets, and warnings of such will begin appearing in dmesg. Even if we were to assume that this should not happen on an authoritative DNS server unless you're being leveraged in an attack (and therefore you will not leverage sysctl to raise the limit), this is a poor strategy because you're dropping good packets along with the bad. It would be much more preferable to investigate using BIND's newer client rate limiting features, since you're dropping the right traffic at that point.
• RE: a default DROP policy in the OUTPUT table, expect to see log messages about being unable to resolve names. NS records that you serve trigger internal lookups of those records (known as additional section processing), and unless you are 100% sure that you have no delegations, you will see these log messages. Even if you don't have delegations, it's reasonable to expect that they will be present in the future. Adding port 53 to the OUTPUT table is therefore recommended despite your server not being recursive.

Lastly, and perhaps far most importantly, it's extremely unlikely that you're actually going to get any benefit out of putting a packet based firewall here.

• Most DNS based attacks leverage the normal operation of a DNS server. The firewall won't stop this. Minimization of your DNS attack surface is all about your nameserver and network configuration.
• The firewall doesn't make the packets go away. It just drops them before the receiving program sees them. If your circuit gets flooded with inbound traffic, the flood is still happening and you're still down. If your circuit is getting flooded with outbound traffic from your server as part of an attack, you need to address the problem directly, and your Q&A does not actually explain the nature of the attack.

Given the above factors, enabling iptables in this scenario is likely to accomplish little in the way of benefit that could not be better solved through other strategies. As such, taking this approach over those is mostly increasing the odds that you will be dropping legitimate traffic during attack events when it could have been avoided.