unexpected RCODE REFUSED - eating up log files

Question

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;

Answer 1

Most certainly your server is trying to resolve 'target-express.com' and it is failing. The reason it is failing is the NS servers for 'target-express.com' are not properly setup. (Google 'lame servers'). Doing 'dig +trace' shows two NS records for the domain, but if you query those domains, there is no response.

Now the question is who is querying your server -

1.Legitimate internal users/Apps - I would not worry about this.

2.Not authorized external users - Your dns servers should allow resolving only for domains that they are authoritative for. If your intention is not to have an open dns server, then put a restriction in your dns configuration so that only allowed hosts can use the server for recursive query.

root@svm1010:/var/tmp# dig @8.8.8.8 target-express.com NS +short
root@svm1010:/var/tmp# dig +trace target-express.com NS

; > DiG 9.7.0-P1 > +trace target-express.com NS
;; global options: +cmd
.           16978   IN  NS  d.root-servers.net.
.           16978   IN  NS  i.root-servers.net.
.           16978   IN  NS  f.root-servers.net.
.           16978   IN  NS  b.root-servers.net.
.           16978   IN  NS  a.root-servers.net.
.           16978   IN  NS  k.root-servers.net.
.           16978   IN  NS  l.root-servers.net.
.           16978   IN  NS  h.root-servers.net.
.           16978   IN  NS  e.root-servers.net.
.           16978   IN  NS  j.root-servers.net.
.           16978   IN  NS  m.root-servers.net.
.           16978   IN  NS  g.root-servers.net.
.           16978   IN  NS  c.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 9 ms

com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
;; Received 496 bytes from 199.7.91.13#53(d.root-servers.net) in 15 ms

target-express.com. 172800  IN  NS  sec02.ns.esat.net.
target-express.com. 172800  IN  NS  auth02.ns.esat.net.
;; Received 120 bytes from 192.48.79.30#53(j.gtld-servers.net) in 221 ms

;; Received 36 bytes from 192.111.39.112#53(sec02.ns.esat.net) in 111 ms

root@svm1010:/var/tmp# dig @sec02.ns.esat.net. target-express.com. soa +short
root@svm1010:/var/tmp# dig @auth02.ns.esat.net. target-express.com. soa +short
root@svm1010:/var/tmp# 

Answer 2

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?