Servidores DNS do Windows que solicitam repetidamente registros na zona quando recebem a resposta do SERVFAIL

Question

Estamos vendo níveis altos (mais de 2000 solicitações / segundo) de consultas DNS de nossos servidores DNS em cache para servidores externos. Isso pode ter acontecido por um longo tempo - isso veio à luz recentemente devido a problemas de desempenho com o nosso firewall. Conversando com colegas de outras instituições, fica claro que estamos fazendo mais consultas do que elas.

Meu pensamento inicial foi que o problema era a falta de armazenamento em cache das respostas do SERVFAIL. Tendo feito mais investigações, fica claro que o problema é um alto nível de solicitações para o registro com falha dos servidores DNS do Windows. Parece que, em nosso ambiente, uma única consulta a um dos servidores DNS do Windows para um registro de uma zona que retorna SERVFAIL resulta em um fluxo de solicitações para esse registro de todos dos servidores DNS do Windows. O fluxo de pedidos não pára até que eu adicione uma zona vazia falsa em um dos servidores Bind.

Meu plano de amanhã é verificar a configuração dos servidores DNS do Windows - eles devem apenas estar encaminhando para os servidores Bind de cache. Eu acho que devemos ter algo errado lá, pois não posso acreditar que ninguém mais tenha acertado isso se não for um erro de configuração. Eu atualizarei esta questão depois disso (possivelmente fechando esta e abrindo uma nova, mais clara).

Nossa configuração é um par de servidores de cache que executam o Bind 9.3.6, que são usados diretamente pelos clientes ou por meio de nossos controladores de domínio do Windows. Os servidores de armazenamento em cache passam consultas para nossos servidores DNS principais que estão executando 9.8.4-P2 - esses servidores são autoritativos para nossos domínios e passam consultas para outros domínios para servidores externos.

Comportamento que estamos vendo é que consultas como essa abaixo não estão sendo armazenadas em cache. Eu verifiquei isso observando o tráfego de rede dos servidores DNS usando o tcpdump.

 [root@dns1 named]# dig ptr 119.49.194.173.in-addr.arpa.

 ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> ptr 119.49.194.173.in-addr.arpa.
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8680
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

 ;; QUESTION SECTION:
 ;119.49.194.173.in-addr.arpa.   IN      PTR

 ;; Query time: 950 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Sun Mar  9 13:34:20 2014
 ;; MSG SIZE  rcvd: 45

A consulta do servidor do Google mostra diretamente que estamos recebendo uma resposta RECUSADA.

[root@dns1 named]# dig ptr 119.49.194.173.in-addr.arpa. @ns4.google.com.

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> ptr 119.49.194.173.in-addr.arpa. @ns4.google.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 38825
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;119.49.194.173.in-addr.arpa.   IN      PTR

;; Query time: 91 msec
;; SERVER: 216.239.38.10#53(216.239.38.10)
;; WHEN: Sun Mar  9 13:36:38 2014
;; MSG SIZE  rcvd: 45

Isso não está acontecendo apenas com endereços do Google ou pesquisas reversas, mas uma alta proporção das consultas é para esses intervalos (suspeito que seja por causa de um recurso de relatório do Sophos).

Nossos servidores DNS devem armazenar em cache essas respostas negativas? Eu li o link , mas não vi nada sobre REFUSED. Nós não especificamos lame-ttl no arquivo de configuração, então eu esperaria que o padrão fosse 10 minutos.

Eu acredito que isso (a falta de cache) é um comportamento esperado. Não entendo porque os outros sites com os quais falei não estão vendo a mesma coisa. Eu tentei um servidor de teste executando a última versão estável do Bind e que mostra o mesmo comportamento. Eu também tentei o Unbound e isso também não armazenou em cache o SERVFAIL. Há alguma discussão sobre isso em djbdns aqui , mas a conclusão é que a funcionalidade foi removida.

Existem configurações na configuração do Bind que podemos alterar para influenciar esse comportamento? lame-ttl não ajudou (e nós estávamos rodando com o padrão de qualquer maneira).

Como parte da investigação, adicionei algumas zonas vazias falsas em nossos servidores DNS em cache para cobrir os intervalos que levam à maioria das solicitações. Isso diminuiu o número de solicitações para servidores externos, mas não é sustentável (e também parece errado). Paralelamente, pedi a um colega para obter logs dos servidores DNS do Windows, para que possamos identificar os clientes que fazem as solicitações originais.

    

Answer 1

A causa ficou óbvia quando analisei a configuração dos servidores DNS do Windows (algo se perdeu no relatório verbal).

Cada controlador de domínio foi configurado para encaminhar solicitações não apenas para os dois servidores de Ligação em cache, mas também para todos os outros servidores DNS do Windows. Para solicitações que foram bem-sucedidas (incluindo NXDOMAIN) que funcionariam bem, pois os servidores Bind responderiam e nunca cairíamos no outro DNS do Windows. No entanto, para coisas que retornaram SERVFAIL, um servidor perguntaria a todos os outros que, por sua vez, perguntariam aos servidores Bind. Estou realmente surpreso que isso não tenha causado mais dor.

Vamos aproveitar o encaminhamento extra e espero que o volume de solicitações caia drasticamente.

    

Answer 2

A parte relevante da RFC2308 é §7.1 Falha do servidor (OPCIONAL) .

In either case a resolver MAY cache a server failure response. If it does so it MUST NOT cache it for longer than five (5) minutes, and it MUST be cached against the specific query tuple .

Não tenho conhecimento de uma diretiva de configuração simples que possa substituir isso, embora, se você estivesse inclinado, pudesse encaminhar essa zona para outro local ou veiculá-la diretamente.

Se estiver causando problemas de firewall diretamente, você deve verificar os tempos limite de pseudo-conexão UDP, o cache do DNS UDP pode preencher uma tabela de estado se ela estiver alta. Consultas DNS tendem a bloquear, então espero que você não esteja fazendo (m) nenhuma dessas no firewall.

Algumas das zonas inversas para 173.194 / 16 parecem quebradas. Eles devem , na pior das hipóteses, retornar NXDOMAINs armazenáveis em cache em vez de SERVFAIL ou RECUSADOS.

$ dig 194.173.in-addr.arpa. ns +short
NS4.GOOGLE.COM.
NS3.GOOGLE.COM.
NS2.GOOGLE.COM.
NS1.GOOGLE.COM.

$ dig @ns4.google.com 119.49.194.173.in-addr.arpa. ns
; <<>> DiG 9.8.4-P4 <<>> @ns4.google.com 119.49.194.173.in-addr.arpa. ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 63925
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

194.173.in-addr.arpa é delegado por ARIN para o Google:

$ dig @z.arin.net 194.173.in-addr.arpa. ns +auth

;; AUTHORITY SECTION:
194.173.in-addr.arpa.   86400   IN      NS      NS4.GOOGLE.COM.
194.173.in-addr.arpa.   86400   IN      NS      NS1.GOOGLE.COM.
194.173.in-addr.arpa.   86400   IN      NS      NS2.GOOGLE.COM.
194.173.in-addr.arpa.   86400   IN      NS      NS3.GOOGLE.COM.

Mas esses servidores de nomes não jogam bola, todos os quatro retornam SERVFAIL para

$ dig @ns4.google.com 194.173.in-addr.arpa. soa

Além de ser "rude", isso costumava violar a política ARIN, mas não faz mais . Mas outras zonas funcionam, tente 46.194.173.in-addr.arpa. ou 65.194.173.in-addr.arpa. então parece deliberado e seletivo.