Maneira correta de configurar o DNS primário / secundário /… para redundância e redução de latência?

Eu pensei que o DNS primário / secundário para fins de redundância fosse direto. Meu entendimento é que você deve ter um primário e pelo menos um secundário e configurar seu secundário em um local geograficamente diferente, mas também atrás de um roteador diferente (veja, por exemplo, /server/48087 / por que existem vários servidores de nomes para meu domínio )

Atualmente, temos dois servidores de nomes, ambos em nosso data center principal. Recentemente, sofremos algumas interrupções por vários motivos que eliminaram os dois servidores de nomes e deixamos a nós e nossos clientes sem trabalhar no DNS por algumas horas. Pedi à minha equipe do sysadmin para concluir a configuração de um servidor DNS em outro data center e configurá-lo como o servidor de nome secundário.

No entanto, nossos administradores de sistemas afirmam que isso não ajuda muito se o outro datacenter não for pelo menos tão confiável quanto o datacenter primário. Eles afirmam que a maioria dos clientes ainda não consegue procurar adequadamente ou fica muito tempo esgotada quando o data center principal está inoperante.

Pessoalmente, estou convencido de que não somos a única empresa com esse tipo de problema e que provavelmente já é um problema resolvido. Não consigo imaginar todas essas empresas de internet sendo afetadas pelo nosso tipo de problema. No entanto, não consigo encontrar bons documentos on-line que expliquem o que acontece em casos de falha (por exemplo, tempos limite do cliente) e como solucionar esses problemas.

Quais argumentos eu posso usar para abrir brechas no raciocínio de nossos administradores de sistemas? Algum recurso on-line que posso consultar para entender melhor os problemas que eles alegam existir?

Algumas notas adicionais depois de ler as respostas:

• estamos no Linux
• temos necessidades adicionais de DNS complicadas; nossas entradas de DNS são gerenciadas por algum software personalizado, com o BIND atualmente sendo escravo de uma implementação de DNS torcido e também com algumas visualizações no mix. No entanto, somos completamente capazes de configurar nossos próprios servidores DNS em outro data center.
• Estou falando de DNS autoritário para pessoas de fora encontrarem nossos servidores, não servidores DNS recursivos para nossos clientes locais.

Existe um documento "Boas Práticas" realmente ótimo, embora bastante técnico, que pode ser útil ao combater o administrador do sistema. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

Se ele / ela não reconhecer a validade dos artigos escritos pela Cisco, é melhor parar de discutir com o administrador do sistema - subir um nível de gerenciamento.

Muitos outros documentos de "Práticas recomendadas" recomendam a separação dos servidores de nome primário e secundário, não apenas pelo bloco IP, mas também pelo local físico. De fato, o RFC 2182 recomenda que os serviços DNS secundários sejam separados geograficamente. Para muitas empresas, isso significa alugar um servidor em outro datacenter ou assinar um provedor DNS hospedado, como ZoneEdit ou UltraDNS .

No entanto, nossos administradores de sistemas afirmam que isso não ajuda muito se o outro datacenter não for pelo menos tão confiável quanto o datacenter primário. Eles afirmam que a maioria dos clientes ainda não consegue procurar adequadamente ou fica muito tempo esgotada quando o data center principal está inoperante.

Ah, o foco é confiável . Parece que eles estão dando um soco no seu link para o exterior, em vez de configurar o DNS secundário. Mesmo assim, configure o DNS secundário e prossiga a partir daí. Isso ajudará na carga e sustentará as coisas em uma pitada ... mas pergunte por que eles acham que o outro local não é confiável .

Pessoalmente, estou convencido de que não somos a única empresa com esse tipo de problema e que provavelmente já é um problema resolvido. Não consigo imaginar todas essas empresas de internet sendo afetadas pelo nosso tipo de problema.

Você não é a única empresa, e isso provavelmente foi revisado um milhão de vezes em empresas em todo o mundo.

No entanto, não consigo encontrar bons documentos on-line que expliquem o que acontece em casos de falha (por exemplo, tempos limite do cliente) e como solucionar esses problemas.

Quais argumentos eu posso usar para abrir brechas no raciocínio de nossos administradores de sistemas? Algum recurso on-line que posso consultar para entender melhor os problemas que eles alegam existir?

• Estou falando de DNS autoritário para pessoas de fora encontrarem nossos servidores, não servidores DNS recursivos para nossos clientes locais.

Você pode fazer todos os tipos de coisas, incluindo a configuração de um serviço DNS externo registrado como autoridade para sua zona, mas secretamente tornando secundários os servidores autorizados (externos) aos seus próprios servidores DNS (internos). Essa configuração é horrível, errada, mostra que eu sou realmente um SysAdmin maligno, e um gatinho morre toda vez que eu o recomendo. Mas faz duas coisas:

• Você recebe seu serviço DNS para lidar com o peso da carga, fazendo perguntas sobre a capacidade do seu próprio DNS (interno) como discutível.
• Você faz com que seu serviço DNS permaneça ativo enquanto seus servidores DNS internos podem estar inativos, por isso não importa o quão confiável seja o seu link - o que importa é o quão confiável é o seu provedor de serviços DNS .

Os motivos pelos quais isso é errado :

• Você configuraria o que é chamado de "servidor de nomes furtivo", porque, embora seja exibido nos registros de zona e possa consultar o IP pelo nome do servidor, ele nunca será tocado pelo exterior. As consultas do cliente nunca chegarão a ele.
• Embora seu DNS continue funcionando bem (porque o serviço hospedado resolveria o problema), isso não significa que qualquer site que você tenha funcione se a sua conexão à Internet estiver inoperante, ou seja, ele aborda apenas metade do problema . Realmente parece que existem outros problemas com os quais os administradores estão preocupados.

Infelizmente, o resolvedor DNS do Linux não parece ter suporte direto para detectar e executar failovers nos servidores DNS. Ele mantém as solicitações de alimentação para o servidor de nomes de resolução principal, aguarda um tempo limite configurado, tenta novamente etc.

Isso geralmente significa atrasos de até 30 anos para qualquer solicitação. Sem primeiro tentar o secundário, enquanto o primário estiver inativo.

Queria resolver isso, pois nosso servidor de nomes de resolução do Amazon EC2 é inacessível para muitos de nossos trabalhadores. Isso causa grandes atrasos em nossos processos e até tempo de inatividade em alguns casos, porque dependemos da resolução. Eu queria um bom failover para servidores de nomes do Google / Level3, caso a Amazon caísse novamente. E volte o mais rápido possível, pois a Amazon resolverá os nomes de host para endereços locais, quando aplicável, resolvendo com menor latência, por exemplo, para comunicação de instância.

Seja qual for o caso, é necessário um melhor failover. Eu queria resolver isso. Eu queria ficar longe de daemons de proxy, serviços etc. Como isso apenas introduziria mais pontos únicos de falhas. Eu queria usar a tecnologia mais arcaica e robusta possível.

Decidi usar o crontab & bash e escrevi nsfailover.sh . Espero que isto ajude.

Parece que o problema é que os clientes - que podem ser qualquer um, em qualquer lugar - veem dois servidores DNS e, se um falhar, eles não fazem failover no servidor secundário ou há um longo tempo limite antes deles.

Concordo que os servidores DNS primário e secundário devem estar localizados em diferentes instalações como uma prática recomendada, mas não vejo como isso resolveria esse problema específico.

Se o cliente insistir em consultar um endereço IP específico, ignorar o endereço IP do secundário (ou demorar um pouco para expirar), basta criar uma solução que mantenha esse endereço IP funcionando, mesmo se o servidor principal está inoperante.

Algumas instruções a serem exploradas seriam um balanceador de carga que possa redirecionar o tráfego para um único endereço IP para vários servidores em diferentes datacenters; ou talvez roteamento anycast.

Desde que cada um dos seus datacenters esteja em circuitos diferentes (idealmente com diferentes provedores de upstream na nuvem), você pode configurar um DNS bastante confiável com apenas os dois datacenters. Você só precisa garantir que o seu registrador preferido preencha os registros de cola apropriados para os grandes servidores no céu.

Nossa configuração é:

• 2 datacenters físicos (circuitos separados, ISPs e fornecedores upstream)
• 2 servidores de consulta físicos em um cluster atrás de um SLB em cada instalação
• 2 dispositivos de balanceamento de carga para atender a registros específicos dos quais queremos gerenciar o equilíbrio entre os dois datacetners
• mestre oculto acessível internamente por ambos os clusters de servidores (acredito muito fortemente em configurações ocultas de mestre para segurança)

Essa configuração foi eficaz o suficiente para fornecer aproximadamente 5 9s de tempo de atividade nos últimos 6 ou 7 anos, mesmo com o tempo de inatividade ocasional do servidor para atualizações, etc. hospedagem da zona com alguém como ultradns ...

Quanto à conversa sobre carregamento mencionada pelo KPWINC, isso é 100% correto. Se o menor datacenter não puder lidar com 100% da sua carga, é provável que você esteja desossado de qualquer maneira, porque sua interrupção ocorrerá quando você menos desejar =)

Pego a carga máxima de todos os meus roteadores de borda, os adiciono todos juntos e divido por 0,65 ... que é a largura de banda mínima que devemos ter em cada datacenter. Eu coloquei essa regra em prática há cerca de 5 anos, com alguns documentos para justificá-la, reuni no CCO e na Internet e nunca nos falhou. No entanto, você deve verificar essas estatísticas pelo menos trimestralmente. Nosso tráfego aumentou quase três vezes entre novembro e fevereiro do ano passado e eu não estava preparado para isso. O lado positivo é que a situação me permitiu gerar alguns dados concretos muito claros que dizem que, com uma carga de 72% em nosso circuito WAN, começamos a soltar pacotes. Nenhuma justificativa adicional jamais foi exigida de mim por mais largura de banda.

Ao ler sua descrição, percebi que não está claro se você quer dizer DNS autoritativo para que terceiros encontrem seus servidores ou servidores DNS recursivos para seus clientes locais. O comportamento desses dois é muito diferente.

Para servidores DNS autoritativos, os "clientes" serão outros servidores DNS com cache e muita inteligência. Eles tendem a tentar vários servidores ao mesmo tempo, se o primeiro for lento, e preferem o que oferece respostas mais rápidas. O tempo de inatividade de um data center nesse caso teria um impacto muito pequeno no desempenho.

Para servidores DNS recursivos, os clientes são seus clientes locais que provavelmente possuem os servidores DNS listados no DHCP. Eles tentam seus servidores na ordem listada todas as vezes, com um tempo limite dolorosamente longo (de vários segundos) antes de passar do primeiro para o segundo servidor.

Se o seu datacenter principal estiver inoperante, ninguém poderá acessar esses servidores de qualquer maneira, mas geralmente os erros deles são mais inteligíveis do que os erros de servidores DNS inacessíveis. "não foi possível entrar em contato com o servidor" ou "a conexão expirou" em vez de "não foi possível encontrar o servidor" ou "nenhum servidor desse tipo". Por exemplo, a maioria dos servidores SMTP enfileirará o correio por uma semana se virem o servidor no DNS, mas não conseguirem acessá-lo; se eles não conseguirem encontrá-lo no DNS, poderão se recusar imediatamente a tentar entregá-lo ao seu domínio.

O DNS secundário ser geograficamente separado por rede é uma coisa boa. Você pode negociar o DNS secundário com uma empresa amigável e há muitos fornecedores de DNS que você pode pagar para fazer isso por você. Alguns registradores também têm DNS secundário como serviço.

Thomas,

Depois de ler sua atualização, revisei minha postagem (a postagem anterior faz referência ao software Windows).

Parece-me que seus administradores de sistemas estão dizendo que seu local secundário não possui o hardware necessário para lidar com a CARGA COMPLETA?

Parece que ele está dizendo: "Ei, pessoal, se a nossa localização principal (que inclui o DNS primário) ficar inativa, o DNS será a MENOR das nossas preocupações, porque se o COLO1 estiver inativo, o COLO2 não poderá lidar com a carga".

Se for esse o caso, sugiro que você examine sua infraestrutura e tente criar um design melhor. É mais fácil falar do que fazer, especialmente agora que você vive em um ambiente de produção.

Tudo isso aparte, em um mundo perfeito, COLO1 e COLO2 seriam capazes de ficar sozinhos e lidar com sua carga.

Uma vez instalado, o DNS nada mais é do que ter servidores DNS suficientes com uma atualização rápida o suficiente e, se um lado falhar, você poderá reescrever o DNS para apontar para os servidores que estão em UP.

Eu usei esse método em ambientes de tamanho pequeno a razoável e funciona muito bem. O failover normalmente leva menos de 10 minutos.

Você só precisa garantir que seus servidores DNS possam lidar com a carga extra de um TTL curto (tempo de vida).

Espero que isto ajude.

Seus administradores de sistema estão (principalmente) errados.

Os servidores recursivos que consultam seus servidores autorizados notarão muito rapidamente se um dos sites não responder.

Sim, há alguma chance de os clientes sofrerem atrasos muito modestos na resolução de DNS quando houver uma interrupção, mas eles serão apenas um ou dois segundos e, assim que os servidores DNS do cliente descobrirem que um dos servidores está inativo, eles usarão os servidores restantes, de preferência ao servidor com falha.

Se necessário (para apaziguar os administradores de sistema), continue executando dois servidores no seu datacenter primário, mas coloque pelo menos mais um fora.

Um servidor DNS secundário nunca é prejudicial, dependendo de onde está hospedado, ele fornecerá mais ou menos funcionalidade.

Se o host principal falhar, um secundário poderá assumir o controle, independentemente de estar sentado ao lado dele ou em um local remoto. Se, no entanto, o uplink do datacenter falhar, você ainda poderá obter respostas DNS do servidor em outro datacenter, mas não poderá acessar seus servidores de qualquer maneira. Portanto, seus usuários finais não se beneficiarão diretamente do DNS secundário no local remoto.

Diferentes clientes reagem de outras maneiras aos servidores DNS que não estão disponíveis, portanto, existe uma certa verdade para os clientes atingirem o tempo limite, mas não todos.

Um DNS secundário em um datacenter remoto, no entanto, ainda será capaz de resolver o endereço IP do servidor que você deseja acessar para poder depurar o roteamento e ver quando ele será exibido novamente. E se você configurou os servidores MX secundários corretamente, nem perderá nenhum correio.