inesperado RCODE RECUSED - comendo arquivos de log

Question

Eu tenho um site que eu mesmo hospedo, e eu uso o bind9 como meu servidor DNS (hospedo meus próprios servidores de nomes, etc.).

Estou tendo um problema com a largura de banda de tráfego e meu syslog está cheio do seguinte tipo de problema:

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

No syslog de hoje, há 144258 instâncias deste, todas relacionadas a target-express.com.

Minhas perguntas são:

1. há algo que eu possa fazer no firewall ou vincular a configuração para parar isso?
2. Por que minha configuração de ligação estaria tentando resolver target-express.com (não é meu domínio, não tem nada a ver comigo).

Eu verifiquei meus encaminhadores no named.conf, e nenhum deles corresponde aos IPs mostrados nos logs (eles são basicamente IPs diferentes, não apenas 193.95.142.60).

Meu iptables lê:

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 :

Eu tentei o seguinte agora em named.conf.options para bloquear a recursão.

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

Depois de fazer isso, vejo o seguinte no 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

Para eliminar o acima, adicionei:

    additional-from-cache no;

    

Answer 1

Seus encaminhadores DNS podem encaminhar solicitações de volta ao servidor original?

Nesse caso, isso pode ser algo como o problema que tive no ano passado (veja Servidores DNS do Windows solicitando repetidamente registros na zona quando recebem a resposta do SERVFAIL . Correção é não ter loops de encaminhamento. Isso só aparece como um problema significativo com as zonas que retornam SERVFAIL porque essas respostas não serão armazenadas em cache.

Quanto ao que iniciou a consulta original (e pode ter sido apenas uma) poderia ser praticamente qualquer coisa - pesquisa de DNS para controle de acesso à Web ou algo assim.

Para evitar a amplificação (talvez uma descrição melhor do que os loops), é necessário garantir que o servidor DNS em que você está vendo essas mensagens não esteja encaminhando consultas para um servidor que possa encaminhar solicitações de volta. Os servidores que você configurou no servidor DNS local estão sob seu controle ou são externos?

    

Answer 2

Certamente, seu servidor está tentando resolver 'target-express.com' e está falhando. A razão pela qual está falhando é que os servidores NS para 'target-express.com' não estão configurados corretamente. (Google 'servidores lame'). Fazer 'dig + trace' mostra dois registros NS para o domínio, mas se você consultar esses domínios, não há resposta.

Agora, a questão é quem está consultando seu servidor -

1. Usuários internos legítimos / Aplicativos - Eu não me preocuparia com isso.

2.Não usuários externos autorizados - Seus servidores dns devem permitir a resolução apenas de domínios para os quais são autoritativos. Se a sua intenção não é ter um servidor de DNS aberto, coloque uma restrição na sua configuração de DNS para que apenas os hosts permitidos possam usar o servidor para consulta recursiva.

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#