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

Question

Eu achava que o DNS primário / secundário para fins de redundância era simples. Meu entendimento é que você deve ter um primário e pelo menos um secundário, e que deve configurar seu secundário em um local geograficamente diferente, mas também atrás de um roteador diferente (veja, por exemplo, link )

Atualmente, temos dois servidores de nomes no nosso data center principal. Recentemente, sofremos algumas interrupções por vários motivos que eliminaram os dois servidores de nomes e nos deixaram e nossos clientes sem trabalhar com o DNS por algumas horas. Eu pedi à minha equipe de administradores para terminar de configurar um servidor DNS em outro data center e configurá-lo como o servidor de nomes secundário.

No entanto, nossos administradores afirmam que isso não ajuda muito se o outro data center não for pelo menos tão confiável quanto o data center principal. Eles alegam que a maioria dos clientes ainda não conseguirá procurar corretamente ou expirará por muito tempo, quando o data center principal estiver inativo.

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 as empresas da 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 contorná-los.

Que argumentos posso usar para criar falhas no raciocínio dos nossos administradores? Quaisquer recursos online que eu possa consultar para entender melhor os problemas que eles afirmam 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 alguns softwares personalizados, com o BIND atualmente funcionando a partir de uma implementação de DNS contorcido e algumas visualizações no mix também. No entanto, somos completamente capazes de configurar nossos próprios servidores DNS em outro data center.
• Estou falando de DNS autoritativo para que pessoas de fora encontrem nossos servidores, e não servidores DNS recursivos para nossos clientes locais.

Answer 1

Existe um documento muito bom, embora bastante técnico, de "Melhores Práticas", que pode ser útil ao combater seu administrador de sistema. link

Se ele / ela não reconhecer a validade dos artigos escritos pela Cisco, então você também pode parar de discutir com o administrador de sistema - subir um nível de gerenciamento.

Muitos outros documentos de "Melhores práticas" recomendam a separação de seus servidores de nomes primário e secundário não apenas por bloqueio de IP, mas por local físico. Na verdade, a 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 inscrever-se em um provedor DNS hospedado, como ZoneEdit ou UltraDNS .

    

Answer 2

However, our sysadmins claim that this doesn't help much if the other data center is not at least as dependable as the primary data center. They claim that most clients will still fail to look up properly, or time out too long, when the primary data center is down.

Ah, o foco é confiável . Parece que eles estão fazendo um jab no seu link para o exterior, em vez de configurar o DNS secundário. De qualquer forma, configure o DNS secundário e continue a partir dele. Ele ajudará com a carga e irá sustentar as coisas em um piscar de olhos ... mas indague por que eles acham que a outra localização não é confiável .

Personally, I'm convinced we're not the only company with this kind of problem and that it most likely is already a solved problem. I can't imagine all those internet companies being affected by our kind of problem.

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

However, I can't find good online docs that explain what happens in failure cases (for example, client timeouts) and how to work around them.

What arguments can I use to poke holes in our sysadmins' reasoning ? Any online resources I can consult to better understand the problems they claim exist ?

• I'm talking about authoritative DNS for outsiders to find our servers, not recursive DNS servers for our local clients.

Você pode fazer todo tipo de coisas, incluindo a configuração de um serviço DNS externo registrado como autoridade para sua zona, mas secretamente tornando os servidores autoritários (externos) secundários para 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 ele faz duas coisas:

• Você faz com que seu serviço de DNS lide com o peso da carga, fazendo perguntas sobre a capacidade de seu próprio DNS (interno) como irrelevante.
• Você faz seu serviço DNS ficar ativo enquanto seus servidores DNS internos podem estar inativos, portanto, não importa o quanto seu link seja confiável - o que importa é o quanto seu provedor de serviços DNS é confiável é.

As razões pelas quais essa é a coisa errada a ser feita:

• Você configuraria o que é chamado de "servidor de nomes invisível", porque embora ele apareça nos registros da zona e você possa consultar o IP para o nome do servidor, ele nunca será tocado pelo lado de fora. As consultas do cliente nunca chegarão a ele.
• Embora o DNS continue funcionando bem (porque o serviço hospedado resolveria o problema), isso não significa que qualquer site que você tenha funcionaria se a conexão com a Internet estivesse inativa, ou seja, aborda metade do problema . Parece mesmo que existem outros problemas com os quais os administradores se preocupam.

Answer 3

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

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

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

Mas, seja qual for o uso, há necessidade de um melhor failover. Eu queria resolver isso. Eu queria ficar longe de daemons de proxy, serviços, etc. Como isso seria apenas introduzir mais Ponto único de falhas. Eu queria usar como arcaico & robusto uma tecnologia que pude.

Eu decidi usar crontab & bash, e escreveu nsfailover.sh . Espero que isso ajude.

    

Answer 4

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

Concordo que os servidores DNS primário e secundário devem estar localizados em instalações diferentes 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, ignorando o endereço IP do secundário (ou demorando um pouco até o tempo limite), você simplesmente terá que criar uma solução que mantenha esse endereço IP funcionando, mesmo que o servidor principal esteja inativo.

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

    

Answer 5

Desde que cada um dos seus datacenters esteja em circuitos diferentes (de preferência com diferentes provedores upstream até a nuvem), você pode configurar DNS bastante confiável com apenas os dois datacenters. Você precisa apenas certificar-se de que seu registrador de escolha preenche os registros de cola apropriados para os grandes servidores no céu.

Nossa configuração é:

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

Esta configuração foi eficaz o suficiente para nos dar aproximadamente 5 9 de tempo de atividade nos últimos 6 ou 7 anos, mesmo com o tempo de inatividade ocasional do servidor para atualizações, etc. Se você estiver disposto a gastar alguns dólares adicionais, você pode olhe para hospedagem terceirizada da zona com alguém como ultradns ...

Quanto à conversa de carga que o KPWINC mencionou, isso é 100% correto. Se o seu menor datacenter não pode suportar 100% da sua carga, então você provavelmente está desossado de qualquer maneira, porque sua interrupção ocorrerá quando você menos desejar =)

Eu pego a carga máxima de todos os meus roteadores de borda, adiciono todos eles e, em seguida, divido por 0,65 ... essa é a largura de banda mínima que precisamos ter em cada datacenter. Eu coloquei essa regra em prática cerca de 5 anos atrás, com alguns documentos para justificar isso, eu juntei do CCO e da internet, e isso nunca falhou conosco. No entanto, você deve verificar essas estatísticas pelo menos trimestralmente. Nosso tráfego aumentou quase 3 vezes entre novembro e fevereiro do ano passado e eu não estava preparada para isso. O lado bom é que a situação me permitiu gerar alguns dados muito claros que dizem que a carga de 72% no nosso circuito WAN, nós começamos a derrubar pacotes. Nenhuma justificativa adicional foi solicitada por mais largura de banda.

    

Answer 6

Percebi, lendo sua descrição, que não está claro se você quer dizer que o DNS autoritativo para pessoas de fora encontre 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 armazenamento em cache e muita inteligência. Eles tendem a tentar vários servidores ao mesmo tempo, se o primeiro é lento, e tendem a preferir aquele que lhes dá 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 têm os servidores DNS listados no DHCP. Eles tentarão seus servidores na ordem listada toda vez, com um tempo limite dolorosamente longo (vários segundos) antes de passar do primeiro servidor para o segundo servidor.

Se o seu datacenter principal estiver inativo, ninguém conseguirá acessar esses servidores de qualquer maneira, mas geralmente os erros 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 entrará na fila por uma semana se eles virem o servidor no DNS, mas não conseguirem acessá-lo; se eles não conseguirem encontrá-lo no DNS, eles podem se recusar a tentar entregá-lo imediatamente ao seu domínio.

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

    

Answer 7

Thomas,

Depois de ler sua atualização, eu revisei minha publicação (a postagem anterior é referente ao software Windows).

Parece-me quase que o (s) seu (s) administrador (s) informou (m) que a sua localização secundária não possui o hardware necessário para lidar com a CARREGADA TOTAL?

Parece que ele está dizendo: "Ei amigo, se a nossa localização principal (que inclui o DNS primário) cair, então o DNS é o menor de nossas preocupações, porque se o COLO1 estiver inativo, COLO2 não conseguirá lidar com a carga de qualquer maneira. "

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

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

Assim que estiver em vigor ... o DNS é realmente nada mais do que ter servidores DNS suficientes com uma atualização rápida o suficiente e se um lado falhar, você pode reescrever seu 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 os servidores DNS suportem a carga extra de um TTL curto (tempo de vida).

Espero que isso ajude.

    

Answer 8

Seus sysadmins estão (principalmente) errados.

Os servidores recursivos que consultam seus servidores autoritativos perceberão rapidamente se um dos sites não responder.

Sim, há algumas chances de os clientes experimentarem atrasos de resolução de DNS muito modestos quando há uma interrupção, mas eles serão apenas um segundo ou dois, e assim que os servidores DNS do cliente souberem que um dos servidores está inoperante, usará os servidores restantes em preferência ao que falhou.

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

    

Answer 9

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

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

Diferentes clientes reagem de outras formas a servidores DNS que não estão disponíveis, por isso há alguma verdade no tempo limite dos clientes, mas não em 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 que você possa depurar o roteamento e ver quando eles aparecem novamente. E se você tiver configurado os servidores MX secundários corretamente, você nem perderá nenhum e-mail.