Devo executar meu próprio recursor DNS ou daemon de cache local?

Question

Estou no AWC EC2, pois o meu servidor vai fazer muita consulta para domínios de terceiros, estou pensando nas seguintes opções

• instala o nscd em todos os servidores
• use o recursor de nome padrão ec2
• instale o meu próprio nome recursor
• é só usar 8.8.8.8

Estou hesitante em instalar o recursor centralizado, por isso é um ponto único de falha e está sujeito a ataques como: link

1. Hoje em dia, é comum usar uma consulta DNS recursiva de suporte ao servidor de nomes, como sugere o artigo acima?

2. Em termos de segurança e desempenho, estou pensando em instalar nscd , existe alguma desvantagem?

Answer 1

O nscd faz mais do que apenas armazenar em cache solicitações de DNS; ele também armazena em cache pesquisas para nomes de usuários e grupos, juntamente com alguns outros usos menos comuns. É padrão em sistemas Linux (é empacotado como parte do glibc) e provavelmente já está instalado, e usa muito pouca memória, então não há razão para não executá-lo. Ele fornecerá um bom comportamento de armazenamento em cache sem precisar de nenhuma configuração adicional.

Como o EC2 cobra pelo tráfego externo e o tráfego para o 8.8.8.8 (o resolvedor do Google) será muito mais lento do que o tráfego interno ao datacenter, você deve preferir o DNS do EC2, a menos que você tenha um motivo muito específico para isso. Você pode configurar o DNS do Google (8.8.8.8 e 8.8.4.4) como backups para o DNS da Amazon, se desejar, mas é muito improvável que eles fiquem inativos quando o restante da zona estiver funcionando.

Minhas recomendações para suas máquinas virtuais EC2:

• Use o nscd, que deve ser configurado por padrão (/ usr / sbin / nscd; você deve verificar a configuração de execução de sua distribuição para garantir que o serviço seja iniciado na inicialização).
• Use os servidores DNS da Amazon como seus padrões.
• Adicione os servidores do Google como backups, se desejar. Como você faz isso vai variar de acordo com sua distribuição. Se não tiver certeza, verifique o /etc/resolv.conf, que é o arquivo que a glibc (nscd) examina, e geralmente haverá um comentário informando como ele foi configurado. Os servidores são verificados na ordem em que estão listados no resolv.conf, portanto, adicionar os IPs da Amazon primeiro e depois os IPs do Google permitirão que o nscd volte ao Google se, por algum motivo, a Amazon não estiver funcionando.

Fontes: man pages para nscd (8) e resolv.conf (5)

    

Answer 2

Instale o dnsmasq ou dnscache em três ou mais máquinas na sua rede. Eu recomendaria usar o AWS VPC para toda a infraestrutura, mas isso é um problema um pouco separado.

Apontar todos os seus hosts para esses três servidores de nomes.

Configure seu resolv.conf com o seguinte:

nameserver IP_ADDRESS_1
nameserver IP_ADDRESS_2
nameserver IP_ADDRESS_3
options rotate 
options timeout:1

A configuração acima tem muitas vantagens. Primeiro, você tem a resiliência no nível do servidor de nomes recursivo ao ter no mínimo três hosts. Segundo, você obtém os benefícios do armazenamento em cache de forma que, quando o servidor faz uma pesquisa em relação a IP_ADDRESS_1 pela primeira vez, esse servidor de nome em IP_ADDRESS_1 armazenará em cache o resultado. Quando outro servidor faz uma pesquisa, o resultado será retornado muito mais rápido em um hit do cache. Em terceiro lugar, definindo a opção de rotação, você equilibra a carga na sua infra-estrutura DNS recursiva. Finalmente, definindo o tempo limite: 1 você minimiza o impacto de ter um dos servidores DNS inativo para manutenção.

    

Answer 3

O Ubuntu instala dnsmasq por padrão e deve fornecer uma maneira razoavelmente segura e rápida de configurar um cache DNS, sem quaisquer inconvenientes.

Mais detalhes no link

    

Answer 4

O artigo do GoDaddy ao qual você está vinculado está delineando os problemas de se executar um servidor de nomes recursivo aberto . Na verdade, isso seria uma lata de vermes, e você não gostaria de fazê-lo. Contanto que seu recursor esteja escutando apenas em loopback ou dentro de sua interface interna e / ou com firewall, para que ninguém mais possa acessá-lo, o artigo não se aplica.

Sua linha de pensamento é excelente e todas as opções que você está considerando são ótimas. Se você confia no EC2 ou no recursor do Google, não vá em frente.

Na verdade, é bastante comum que muitas organizações de médio a grande porte executem seus próprios recursores.

Para desempenho, eu instalaria um par de recursores em cada zona de disponibilidade e os configuraria para serem os dois primeiros servidores de nomes em /etc/resolv.conf e, em seguida, acrescentar o recursor EC2. Desta forma, você pode ter certeza que

Instalar seu próprio recursor garante latência mínima (em vez de ir para 8.8.8.8), e seu cache não é compartilhado com outras pessoas (o que tem vantagens e desvantagens).

Para um recursor moderno, bem conservado, leve e de alto desempenho, recomendo não consolidado (consulte a recomendação independente aqui: link )

    

Answer 5

IMHO é tudo sobre suas tarefas. Se você fizer muitas consultas a uma pequena quantidade de endereços (por exemplo, de 1000 a 10 domínios), o daemon de cache local será bom o suficiente para você. Se você solicitar a propagação para uma grande quantidade de endereços (uma consulta para 1000 domínios por segundo), recomendo usar o recursor DNS local para acelerar o processo de consulta e reduzir o tráfego DNS. Não esqueça de configurar o cache, se você planeja use o localor.

    

Answer 6

Nunca instale um resolvedor de cache DNS local, isso causará mais problemas do que os benefícios que ele traz.

O Ubuntu não veio com o resolvedor de cache DNS local por padrão provou o meu ponto.