Lista de DNS cinza e intervalos de repetição longos - práticas padrão?

Question

O ISP da minha empresa implementou o que denominarei "listagem cinza" do DNS (ou eles têm um problema de configuração) - eles estão bloqueando as consultas DNS de entrada entre pares [resolver IP, IP do servidor] que não tentaram uma consulta os últimos 60 segundos. Portanto, se a primeira consulta falhar, outras consultas serão bem-sucedidas, desde que menos de 60 segundos tenham se passado desde a tentativa anterior. Suponho que isso é para ocultar hosts de varreduras, sob a suposição de que um resolvedor legítimo tentará novamente a consulta. Eles podem até estar bloqueando todos os pacotes UDP para combater as verificações de portas, mas ainda não encontrei uma maneira de testar isso.

Acontece que os dispositivos Cisco IronPort geralmente têm um intervalo de repetição maior que 60 segundos. (15 segundos para testar cada servidor DNS secundário e 60 segundos antes de tentar novamente o primário) Minha empresa não pode receber e-mails da maioria das organizações com dispositivos IronPort.

Meu sentimento é que pelo menos um desses comportamentos é errado. Então minhas perguntas são:

1) Quais são os intervalos de repetição recomendados para resolvedores de DNS? Você pode referenciar uma RFC ou outra fonte, ou é de fato um padrão da indústria?

2) DNS ou UDP "listagem cinza" é uma prática padrão? Referências?

EDIT - Alguns detalhes de fundo adicionais:

Ambos os servidores DNS da minha empresa são afetados, assim como o servidor de nomes primário do nosso ISP. Seus servidores de nomes secundários, que na verdade residem fora de sua rede, e os servidores de nomes upstream de quaisquer hosts afetados não são afetados. Também temos um segundo ISP e as consultas DNS que entram por essa rota não são bloqueadas. Rastreamentos de pacotes em nosso firewall externo mostram que atendemos a todas as consultas DNS recebidas - as consultas descartadas não são entregues em nossas redes. Meu principal objetivo ao fazer essa pergunta é ter um documento de padrões para mostrar ao nosso ISP (ou, menos provavelmente, à Cisco) que seu comportamento está quebrado e precisa ser corrigido.

    

Answer 1

Os servidores DNS se enquadram em alguns grupos diferentes:

• Servidor autoritativo
• Recursor público
• Recursor não público

Em nenhum desses casos, fará algum sentido tentar esconder sua existência. Os servidores DNS autoritativos devem estar disponíveis publicamente para executar a tarefa para a qual foram configurados. Um recursor público é inútil se você tentar esconder sua existência. E se você executar um recursor que não deveria ser público, em vez de tentar ocultá-lo, basta bloquear as solicitações para ele de um IP do cliente não autorizado.

Da sua pergunta, parece que o servidor DNS que você está perguntando é autoritativo para sua zona. Então eu suponho que é um servidor DNS autoritativo.

Ambos os servidores DNS autoritativos e recursores públicos recebem consultas de endereços IP de clientes arbitrários, e isso significa que eles poderiam ser usados em ataques de amplificação.

Infelizmente, o protocolo DNS não oferece boa proteção contra esses ataques. O comportamento que você descreve pode ser uma tentativa muito ruim de proteger contra esses ataques.

Existem maneiras pelas quais um servidor DNS pode proteger contra ataques de amplificação sem causar tanto impacto quanto o que você descreve.

• Não aplique contramedidas quando nenhum ataque estiver acontecendo. Em vez disso, procure as respostas de erro ICMP que um ataque causaria e aplique contramedidas quando um possível ataque for detectado.
• Não elimine solicitações, em vez disso, envie uma resposta sem nenhuma seção de resposta e defina o bit truncado. Isso fará com que qualquer cliente DNS adequado tente novamente usando o TCP.
• Como o TCP é mais resistente a spoofing, as respostas podem ser enviadas sem se preocupar com ataques de amplificação.
• Lembrar endereços IP que foram consultados com êxito sobre TCP. Aqueles podem ter permissão para consultar sobre o UDP no futuro.

O que eu descrevo aqui não são algumas práticas recomendadas oficiais, é do melhor do meu conhecimento o melhor que você pode fazer para proteger contra ataques de amplificação com o protocolo DNS como parece hoje. Não tenho conhecimento de nenhuma implementação real dessa abordagem.