Eu tenho um site que eu mesmo hospedo e uso o bind9 como meu servidor DNS (hospedo meus próprios servidores de nomes, etc.).
Estou tendo problemas com a largura de banda do 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, existem144258instâncias disso, todas relacionadas a target-express.com.
Minhas perguntas são:
- há algo que eu possa fazer em termos de firewall ou vincular a configuração para impedir isso?
- 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).
Verifiquei meus encaminhadores em nomeado.conf e nenhum deles corresponde aos IPs exibidos nos logs (são todos IPs basicamente diferentes, não apenas 193.95.142.60).
Meu iptables diz:
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
ATUALIZAR:
Eu tentei o seguinte agora em nomeado.conf.options para bloquear a recursão.
allow-transfer {"none";};
allow-recursion {"none";};
recursion no;
Depois de fazer isso, agora estou vendo 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 me livrar do acima, adicionei:
additional-from-cache no;
Responder1
Seus encaminhadores de DNS poderiam estar encaminhando solicitações de volta ao servidor original?
Nesse caso, isso pode ser algo parecido com o problema que tive no ano passado (vejaServidores DNS do Windows solicitam repetidamente registros na zona quando obtêm resposta SERVFAIL). A correção é não ter loops de encaminhamento. Isto só aparece como um problema significativo com 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 qualquer coisa - pesquisa de DNS para controle de acesso à web ou algo parecido.
Para evitar amplificação (talvez uma descrição melhor do que loops), você precisa ter certeza de que o servidor DNS onde você está vendo essas mensagens não está encaminhando consultas para um servidor que pode encaminhar solicitações de volta. Os servidores que você configurou em seu servidor DNS local estão sob seu controle ou são externos?
Responder2
Certamente o seu servidor está tentando resolver 'target-express.com' e está falhando. O motivo da falha é que os servidores NS de 'target-express.com' não estão configurados corretamente. (Google 'servidores coxos'). Fazer 'dig +trace' mostra dois registros NS para o domínio, mas se você consultar esses domínios, não haverá resposta.
Agora a questão é quem está consultando seu servidor -
1.Usuários/aplicativos internos legítimos - eu não me preocuparia com isso.
2. Usuários externos não autorizados - Seus servidores DNS devem permitir a resolução apenas para domínios para os quais são autorizados. Se sua intenção não é ter um servidor DNS aberto, coloque uma restrição em sua configuração de DNS para que apenas hosts permitidos possam usar o servidor para consultas recursivas.
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 ;; opções globais: +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. ;; Recebeu 228 bytes de 8.8.8.8#53(8.8.8.8) em 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. ;; Recebeu 496 bytes de 199.7.91.13#53(d.root-servers.net) em 15 ms target-express. com. 172800 IN NS sec02.ns.esat.net. target-express. com. 172800 EM NS auth02.ns.esat.net. ;; Recebeu 120 bytes de 192.48.79.30#53(j.gtld-servers.net) em 221 ms ;; Recebeu 36 bytes de 192.111.39.112#53(sec02.ns.esat.net) em 111 ms root@svm1010:/var/tmp# dig @sec02.ns.esat.net. target-express. com. tão +curto root@svm1010:/var/tmp# dig @auth02.ns.esat.net. target-express. com. tão +curto root@svm1010:/var/tmp#