Evitando tempos limite de DNS quando um servidor dns falha

Question

Temos um pequeno datacenter com cerca de cem hosts apontando para 3 servidores de DNS internos (bind 9). Nosso problema surge quando um dos servidores de 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 Linux 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 usa (e defina a rotação para que funcione na lista), mas não importa quais configurações um usa nossos serviços executam muito mais lentamente se um servidor de DNS primário ficar indisponível. No momento, esta é uma das maiores fontes de problemas de serviço para nós.

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

Eu queria saber como outras pessoas lidaram com esse problema?

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

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

• Execute um servidor de DNS local em cada nó e tenha o resolv.conf apontado para o host local. Isso funcionaria, mas nos daria muito mais serviços para monitorar e gerenciar.

• Execute um cache local em cada nó. As pessoas parecem considerar nscd "quebrado", mas dnrd parece ter o conjunto de recursos certo: ele marca os servidores dns como para cima ou para baixo e não usará servidores DNS "para baixo".

Any-casting parece funcionar apenas no nível de roteamento ip e depende das atualizações de rota para falha do servidor. Multi-casting parecia que seria uma resposta perfeita, mas bind não não suportam transmissão ou multi-casting, e os documentos que eu encontrei parecem sugerir que O multicast dns é mais voltado para a descoberta de serviços e a autoconfiguração do que para a resolução regular de DNS.

Estou perdendo uma solução óbvia?

    

Answer 1

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

• Tente usar options rotate no resolv.conf. Isso minimizará o impacto do servidor principal estar inativo. Se um dos outros servidores estiver inativo, diminuirá as ações.
• 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 roteador, você poderá configurar seus servidores DNS para assumir o endereço IP do servidor DNS primário quando ele estiver inativo. Isso pode ser combinado com as técnicas acima.

NOTA: Eu corro anos sem interrupções de DNS não programadas. Como outros notaram, eu trabalharia na solução dos problemas que causam a falha dos servidores DNS. As etapas acima também ajudam com servidores DNS configurados incorretamente com a especificação de servidores de nomes inacessíveis.

    

Answer 2

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:

options timeout:1

    

Answer 3

O software de cluster, como heartbeat ou pacemaker / corosync, é seu amigo aqui. Como exemplo, configuramos o pacemaker / corosync da seguinte forma:

• Emparelhe cada servidor com outro
• Por par tem 2 dns vips, geralmente um em cada
• Caso a ligação ou o servidor falhe, o vip é 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 girar é meramente uma solução alternativa, eu não faria isso.

    

Answer 4

Run a local dns server on each node, and have resolv.conf point to localhost. This would work, but it would give us a lot more services to monitor and manage.

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 tem eliminou completamente os usuários que notaram interrupções de DNS em nosso ambiente.

Um efeito colateral interessante é que, se o servidor localhost ficar inativo por algum motivo, as bibliotecas do resolvedor padrão parecem lidar com o failover para o próximo servidor muito mais rapidamente do que no caso padrão.

Fazemos isso há cerca de três anos e não vi nenhum problema que possa estar relacionado à falha / interrupção de um servidor dns em execução no host local.

    

Answer 5

Se um servidor de nomes estiver sendo interrompido para manutenção, é um procedimento normal reduzir antecipadamente os tempos limite no SOA para esse domínio, de modo que, quando a manutenção ocorrer, mude (como remover registros NS antes da manutenção e colocá-los de volta após a manutenção) se propagam rapidamente. Note que esta é uma abordagem do lado do servidor - mudar os resolvedores é uma abordagem do lado do cliente e ... a menos que você possa conversar com cada um dos seus clientes e fazer com que eles façam esse ajuste em suas máquinas ... pode não ser a abordagem correta. Bem, eu acho que você disse apenas uma centena de clientes em um data center usando servidores DNS internos, mas você realmente quer mudar a configuração de uma centena de clientes quando você pode simplesmente mudar de zona?

Eu diria quais valores no SOA devem ser ajustados, mas eu estava navegando na Web para descobrir as informações exatas quando fiz essa pergunta.

    

Answer 6

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

    

Answer 7

Eu sei que isso pode parecer banal, mas que tal construir uma infraestrutura DNS mais estável e resiliente como uma solução permanente para o problema?

    

Answer 8

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

Enquanto os dois estiverem ativos, o servidor mais próximo é usado. Se uma pessoa ficar inativa, o tráfego para esse IP será roteado para o outro nó até que apareça novamente. Isso faz sentido especialmente se você tiver dois ou mais locais ou data centers.