Iptables – unexpected RCODE REFUSED – eating up log files

binddns-hostingiptables

I have a website which I host myself, and I use bind9 as my DNS server (host my own nameservers etc.).

I am having a problem with traffic bandwidth, and my syslog is full of the following type of issue:

error (unexpected RCODE REFUSED) resolving 'target-express.com/AAAA/IN': 193.95.142.60#53
error (unexpected RCODE REFUSED) resolving 'target-express.com/A/IN': 2001:7c8:3:2::5#53

In today's syslog, there are 144258 instances of this, all related to target-express.com.

My questions are:

  1. is there anything I can do firewall-wise or bind config to stop this?
  2. Why would my bind setup be trying to resolve target-express.com (it's not my domain, nothing to do with me).

I have checked my forwarders in named.conf, and none of them match the IPs showing in the logs (they are all basically different IPs, not just 193.95.142.60).

My iptables reads:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             loopback/8           reject-with icmp-port-unreachable
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
LOG        all  --  anywhere             anywhere             limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere

UPDATE:

I've tried the following now in named.conf.options to block recursion.

allow-transfer {"none";};
allow-recursion {"none";};
recursion no;

Once I did this, I am now seeing the following in syslog:

Mar  4 00:02:21 mail named[29037]: client 127.0.0.1#42139: query (cache) '24.124.41.103.in-addr.arpa/PTR/IN' denied
Mar  4 00:02:22 mail named[29037]: client 127.0.0.1#58405: query (cache) '45.124.41.103.in-addr.arpa/PTR/IN' denied
Mar  4 00:02:24 mail named[29037]: client 127.0.0.1#48692: query (cache) '106.49.174.61.in-addr.arpa/PTR/IN' denied

To get rid of the above, I added:

    additional-from-cache no;

Best Answer

Could your DNS forwarders be forwarding requests back to the original server?

If so this might be something like the problem I had last year (see Windows DNS servers repeatedly requesting records in zone when they get SERVFAIL response). Fix is to not have forwarding loops. This only shows up as a significant problem with zones that return SERVFAIL because those responses won't be cached.

As to what initiated the original query (and it may only have been one) could be just about anything - DNS lookup for web access control or something like that.

To avoid amplification (perhaps a better description than loops) you need to make sure that the DNS server where you're seeing these messages isn't forwarding queries to a server which might forward requests back. Are the servers you have configured on your local DNS server under your control or are they external?

Related Topic