Você pode olhar para dnsmasq em vez de confiar apenas na biblioteca de resolvedores - o dnsmasq consulta os servidores upstream em paralelo, não é uma moda serial, então ter um desistir não deve causar tantos problemas.
Atualmente, sou o administrador de algumas máquinas RHEL Linux, em uma rede mista. Nossos servidores DNS são controladores do Windows AD. Como tal, eles ocasionalmente precisam descer para manutenção. (por exemplo: patching) Isso significa que, em algum momento, o controlador de DNS primário para minhas máquinas Linux estará inacessível.
No mundo do Windows, isso é tratado muito bem. Quando as consultas DNS ao primário falham, os clientes Windows param de usá-lo por 15 minutos. Então, salvo o soluço inicial, todos eles se comportaram bem. Mas o Linux continua tentando o mesmo servidor principal (com falha). Por padrão, ele espera pelo menos 5 segundos antes de tentar um servidor secundário. Isso se traduz em que TUDO demora muito, e até mesmo os aplicativos se esgotam se houver um bom número de pesquisas de DNS.
Então, estou procurando tornar meu servidor mais robusto. Meu plano atual é: A) modificar o resolv.conf para esperar apenas 1/2 segundo por uma resposta e não tentar novamente. e B) possivelmente fazer algumas entradas estratégicas para / etc / hosts para que os principais servidores ainda sejam alcançados rapidamente.
Tudo o que foi dito, eu adoraria ter uma solução melhor. Como alternativa, gostaria de ouvir o que outras pessoas estão fazendo com suas configurações. Ou apenas teórica " A sua ideia é boa / má, eis o porquê. "
- Christopher Karel
Você pode olhar para dnsmasq em vez de confiar apenas na biblioteca de resolvedores - o dnsmasq consulta os servidores upstream em paralelo, não é uma moda serial, então ter um desistir não deve causar tantos problemas.
Talvez executar um nscd e adicionar
options rotate
para /etc/resolv.conf já faz o truque para você.
Uma solução mais fácil é redirecionar o tráfego por um determinado tempo (janela de manutenção).
Se você tem uma máquina de reposição, você poderia dar temporariamente o ip do seu servidor primário. Caso contrário, você poderia implantar o redirecionamento no roteador. Se um pacote tem como destino o seu servidor principal, você pode redirecioná-lo para o servidor secundário
Uma solução mais difícil, porém mais robusta, seria configurar dois servidores de nomes (slaved off AD) e usar anycast. link