Evitando tempos limite de DNS quando um servidor DNS falha

Temos um pequeno datacenter com cerca de cem hosts apontando para 3 servidores DNS internos (bind 9). Nosso problema ocorre quando um dos servidores DNS internos fica indisponível. Nesse ponto, todos os clientes que apontam para esse servidor começam a executar muito lentamente.

O problema parece ser que o resolvedor de estoque linux realmente não tem o conceito de "failover" para um servidor DNS diferente. Você pode ajustar o tempo limite e o número de tentativas que ele usa (e definir rodar para que funcione na lista), mas não importa quais configurações sejam usadas pelos nossos serviços, elas executam muito mais lentamente se um servidor DNS primário ficar indisponível. No momento, essa é uma das maiores fontes de interrupção de serviço para nós.

Minha resposta ideal seria algo como "RTFM: tweak /etc/resolv.conf assim ...", mas se essa é uma opção, não a vi.

Eu queria saber como outras pessoas lidaram com esse problema?

Eu posso ver três tipos possíveis de soluções:

• Use linux-ha / pacemaker e ips de failover (para que os VIPs IP do DNS estejam "sempre" disponíveis). Infelizmente, não temos uma boa infraestrutura de esgrima, e sem o marcapasso de esgrima não funciona muito bem (na minha experiência, o Pacemaker reduz a disponibilidade sem esgrima).

• Execute um servidor DNS local em cada nó e faça com que o resolv.conf aponte para localhost. Isso funcionaria, mas nos daria muito mais serviços para monitorar e gerenciar.

• Execute um cache local em cada nó. As pessoas parecem considerar o nscd "quebrado", mas o dnrd parece ter o conjunto correto de recursos: marca os servidores DNS como ativo ou inativo e não usa servidores DNS "inativos".

Qualquer conversão parece funcionar apenas no nível de roteamento IP e depende das atualizações de rota para falha do servidor. A transmissão múltipla parecia ser uma resposta perfeita, mas o bind não suporta transmissão ou transmissão múltipla, e os documentos que pude encontrar parecem sugerir que o DNS multicast é mais voltado para a descoberta e configuração automática de serviços do que para a resolução regular de DNS .

Estou perdendo uma solução óbvia?

Algumas opções. Ambos irão distribuir a carga do DNS entre seus servidores DNS.

• Tente usar options rotateno resolv.conf. Isso minimizará o impacto do servidor primário estar inativo. Se um dos outros servidores estiver inativo, as ações serão mais lentas.
• Use uma ordem de servidor de nomes diferente em clientes diferentes. Isso permitirá que alguns clientes sejam executados normalmente se o servidor DNS primário estiver inativo. Isso espalha o impacto de um servidor DNS fora de serviço.

Essas opções podem ser combinadas com options timeout:1 attempts:5. Aumente as tentativas se você diminuir o tempo limite para poder lidar com servidores externos lentos.

Dependendo da configuração do seu roteador, você poderá configurar os servidores DNS para assumir o endereço IP do servidor DNS primário quando estiver inativo. Isso pode ser combinado com as técnicas acima.

NOTA: Executo anos sem interrupções não programadas do DNS. Como outros observaram, eu trabalhava na solução dos problemas que causavam falhas nos servidores DNS. As etapas acima também ajudam com servidores DNS configurados incorretamente na especificação de servidores de nomes inacessíveis.

Confira "man resolv.conf". Você pode adicionar uma opção de tempo limite ao resolv.conf. O padrão é 5, mas adicionar o seguinte ao resolv.conf deve reduzir para 1 segundo:

tempo limite das opções: 1

Software de cluster, como batimentos cardíacos ou marcapasso / corosync, é seu amigo aqui. Como exemplo, configuramos o marcapasso / corosync da seguinte maneira:

• Emparelhe cada servidor com outro
• Por par tem 2 dns vips, geralmente um em cada
• Se a ligação ou o servidor falhar, o vip será movido para o outro servidor em milissegundos

As horas de produção são 24x7, mas acreditamos firmemente que deve ser possível que todos os servidores falhem sem afetar os clientes. opção rodar é apenas uma solução alternativa, eu não faria isso.

Execute um servidor DNS local em cada nó e faça com que o resolv.conf aponte para localhost. Isso funcionaria, mas nos daria muito mais serviços para monitorar e gerenciar.

FWIW, esta é a única solução viável que encontrei para esse problema. Você precisa restringir o servidor para escutar apenas no host local, mas ele eliminou completamente os usuários que notaram falhas no DNS em nosso ambiente.

Um efeito colateral interessante é que, se o servidor localhost for desativado por algum motivo, as bibliotecas de resolvedores padrão parecerão manipular o failover para o próximo servidor muito mais rapidamente do que no caso padrão.

Fazemos isso há cerca de 3 anos e não vi um único problema que possa estar relacionado à falha / indisponibilidade de um servidor DNS em execução no localhost.

Se um servidor de nomes estiver inativo para manutenção, é um procedimento normal reduzir antecipadamente os tempos limites no SOA para esse domínio, para que, quando a manutenção ocorra, as alterações sejam alteradas (como remover registros NS antes da manutenção e colocá-los novamente após a manutenção ) propagar rapidamente. Observe que essa é uma abordagem do lado do servidor - alterar os resolvedores é uma abordagem do cliente e ... a menos que você possa conversar com todos e cada um de seus clientes e levá-los a fazer esse ajuste na máquina ... pode não ser a abordagem correta. Bem, acho que você disse apenas uma centena de clientes em um data center usando servidores DNS internos, mas você realmente deseja alterar a configuração de uma centena de clientes quando pode apenas mudar a zona?

Eu dizia a você quais valores na SOA ajustar, mas estava navegando na Web para descobrir essas informações exatas quando deparei com essa pergunta.

Talvez você possa colocar seus servidores DNS atrás de um balanceador de carga? Aparentemente, o LVS pode equilibrar o UDP. Obviamente, torne seu LB altamente disponível para que não seja um único ponto de falha.

Sei que isso pode parecer trivial, mas que tal criar uma infraestrutura de DNS mais estável e resiliente como uma solução permanente para o problema.

Uma solução mais centrada na rede seria usar dois servidores DNS com o mesmo roteamento IP (dedicado) e Anycast . (Eu não notei essa resposta neste tópico até agora, mas é isso que é usado aqui.)

Desde que ambos estejam ativos, o servidor mais próximo é usado. Se um cair, o tráfego para esse IP será roteado para o outro nó até que ele apareça novamente. Isso faz especialmente sentido se você tiver dois ou mais locais ou data centers.