Você pode definir um IP de backup para o seu servidor no DNS?

10

Existe uma maneira de o protocolo DNS naturalmente conter um endereço de servidor de registro A de backup, como o servidor de nomes de backup ou o servidor de correio? Ao pesquisar isso, vi apenas resultados em servidores de backup (registros NS).

Se não houver uma maneira de o DNS oferecer suporte aos registros de backup A, qual é a melhor maneira de simular os resultados para que os usuários sejam direcionados para um servidor ativo, caso o servidor principal não esteja respondendo?

domain-name-system backup-restoration redundancy kjones1876
fonte

Respostas:

12

Sim ... mais ou menos.

Há duas coisas que você pode fazer aqui: se você colocar vários registros A no servidor DNS para um determinado nome, todos eles serão servidos aos clientes e esses clientes escolherão um do conjunto ao qual se conectar, o que significa que o tráfego será ser "razoavelmente" distribuído igualmente entre todos os sites simultaneamente. Isso não é realmente o que você parece descrever, mas é uma situação comum (embora eu não confie nela, por várias razões).

A outra opção é que você coloque apenas um registro A no servidor DNS, e o servidor DNS (ou algo semelhante a ele, como um script de monitoramento) fica de olho no endereço principal do site e, se falhar, o servidor DNS do servidor DNS. registro é alterado para seu outro site. Isso significa que apenas um site estará recebendo tráfego por vez.

A desvantagem dessa segunda estratégia é o cache do DNS. Qualquer pessoa que tenha obtido o endereço do site antigo será SOL até que as entradas de cache DNS que contêm o endereço antigo sejam eliminadas. Isso significa que você precisa manter seus TTLs baixos (aumentando a carga na sua infraestrutura DNS, embora isso raramente seja um problema prático), mas ainda há o problema de caches DNS "não autorizados", que não respeitam os TTLs. Estes são uma dor enorme para qualquer um quem precisa alterar as entradas DNS, mas é um milhão de vezes pior para quem precisa alterar as entradas DNS "frequentemente" (espero que seu site não seja desativado várias vezes por dia, mas ainda assim ...) Basicamente, qualquer pessoa por trás de um desses caches de DNS com comportamento inadequado, o site ficará "inativo" por um período extremamente longo e tente explicar a eles que é o cache do DNS que está com falha ... Eugh.

Em resumo, eu não faria isso por um site, porque existem maneiras melhores de mitigar qualquer risco em que você estiver pensando, mas precisará descrevê-lo se quiser sugestões sobre como mitigá-lo.

mulher
fonte
O risco é que, se o servidor principal cair (por qualquer motivo), eu quero que meus usuários sejam encaminhados para um servidor de backup. Quero dizer, no ano passado, meu servidor caiu uma vez (falha catastrófica no ataque). Eu tinha backups para que os dados estivessem seguros, mas meu site ficou inativo por 12 horas. Eu pensei que isso seria um problema comum com uma correção "adequada". Embora as empresas desejassem um plano de backup.
precisa saber é o seguinte
9
Você não deseja failover de DNS, deseja um hardware mais confiável e, possivelmente, um servidor em espera.
Womble
Os "caches DNS desonestos" são um conto de mulheres velhas. Nenhum software de servidor DNS real exibe o comportamento de ignorar TTLs. Os locais em que os dados DNS são armazenados em cache de maneira a causar problemas são os aplicativos , como o infame problema de cache de pesquisa do Netscape Navigator, por exemplo.
JdeBP
@JdeBP: Nas palavras de Kevin Costner: "caches DNS desonestos não são um mito ... eu os vi!" Eu fiz as escavações e vi os resultados insanos e alucinantes. Os mais populares entre os serviços com restrição de largura de banda e com latência nos dias em que esse tipo de coisa era comum (ISPs de discagem cujo link upstream era ISDN, por exemplo), agora são usados ​​principalmente por pessoas que ouviram falar que eles eram bons. há muito tempo e simplesmente não mudaram de idéia desde então (não que eles fossem uma idéia particularmente boa ... mas sim).
Womble
6

Todo mundo parece pensar que você está falando sobre servidores da WWW, mesmo que você tenha escrito explicitamente

como um servidor de nomes ou servidor de email de backup

A verdade muitas vezes esquecida é que o serviço HTTP é a exceção e não a norma quando se trata disso. No caso normal, sim, há é um mecanismo para a publicação de informações aos clientes através do DNS para que eles adequadamente fallback de servidores primários para servidores de backup. Esse mecanismo é SRVregistros de recursos, conforme usado pelos clientes de serviço para muitos outros protocolos além do HTTP. Veja RFC 2782.

Com os SRVregistros de recursos, os clientes recebem uma lista de servidores, com prioridades e pesos, e são obrigados a tentar servidores em ordem de prioridade, escolhendo entre servidores com prioridades iguais de acordo com o peso, escolhendo servidores com maior peso com mais frequência do que com baixo peso uns. Portanto, com os SRVregistros de recursos, os administradores de servidores podem informar aos clientes quais são os servidores de fallback e como distribuir sua carga por um conjunto de servidores de prioridade igual.

Agora, os servidores DNS de conteúdo estão localizados por um tipo especial de registro de NSrecurso próprio, registros de recurso, que não têm informações de prioridade e peso. Da mesma forma, os servidores de retransmissão SMTP estão localizados por seu próprio tipo especial de registro de recurso MX, que possui informações prioritárias, mas não pesa. Portanto, para servidores DNS de conteúdo, não há disposição para publicar informações de fallback e distribuição de carga; e se alguém estiver usando MXregistros de recursos, para os servidores de retransmissão SMTP, não há disposição para publicar informações de distribuição de carga.

No entanto, SRVMTSes compatíveis agora existem. (A primeira foi exim, com capacidade SRVdesde 2005.) E para outros protocolos de serviço, sem ônus com a bagagem MXe os NSregistros de recursos, a SRVadoção é muito mais abrangente e generalizada. Se você possui um domínio do Microsoft Windows, por exemplo, toda uma série de serviços é localizada por meio de SRVpesquisas no DNS . Esse é o caso há mais de uma década, neste momento.

O problema é que todo mundo pensa em HTTP, quando o HTTP é de longe, hoje em dia em 2011, a exceção e não a regra aqui.

JdeBP
fonte
enquanto os registros srv são ótimos para uso em rede interna quando o ambiente é controlado, eles não são suficientes para algo como um servidor externo com clientes heterogêneos. você não sabe que o registro será acessado, pois não sabe se o cliente suportará o acesso a registros srv.
22611 Michael Lowman
1
Novamente, você está deixando o HTTP governar seu pensamento. Para muitos dos clientes mencionados acima, os SRVregistros são a maneira definida de localizar os serviços. Observe também que a questão era se o mecanismo existe e o que era. O mecanismo existe, e este é o mecanismo. Tem sido amplamente utilizado por uma década.
JdeBP
Você certamente está certo, srv é certamente o mecanismo correto e, na verdade, faz outras coisas que, embora o DNS não pudesse fazer, desejava que pudesse. Infelizmente, nenhum suporte ao navegador srv. Além disso, a pergunta era específica do HTTP porque eu disse "como servidor de nome ou servidor de email de backup", o que significa que já existem soluções de backup para eles.
Kjones1876
1

se você estiver exibindo conteúdo dinâmico e não for prático simplesmente ter dois servidores fornecendo conteúdo simultaneamente, sua outra opção é ter vários registros no DNS de qualquer maneira e configurar o servidor de backup para ativar a porta ICMP inacessível aos clientes que tentam se conectar a ele ; se a qualquer momento o servidor principal ficar inativo, basta remover o bloco da porta 80 no backup e o tráfego começará a chegar.

A única outra maneira (de orçamento) que você poderá fazer é configurar uma máquina (ou duas) separada para executar o NAT em solicitações; portanto, se um servidor da web morrer, você poderá simplesmente remover a regra do NAT.

Olipro
fonte
Inicialmente, eu cansei sua primeira ideia, acabei de desativar o apache no servidor principal, mas o navegador continuava tentando se conectar de qualquer maneira. Mas, transformar o curso do apache em erro do ICMP? Caso contrário, como faço para tornar o servidor um erro de ICMP?
precisa saber é o seguinte
não, a conexão só vai expirar, você deve obter iptables para rejeitá-la corretamente assim:
Olipro
iptables ENTRADA -I -p tcp dport 80 -j REJECT --reject-com-porta-ICMP inacessível
Olipro
Eu cansei isso e as pessoas simplesmente não conseguiam se conectar ... Eu até desconectei o servidor em que estava testando.
precisa saber é o seguinte
O interlocutor não estava falando especificamente sobre apenas servidores da WWW. De fato, o xe mencionou explicitamente os servidores de correio e nome.
JdeBP
0

Não há registros A de backup, mas pode haver vários registros A que são fornecidos em ordem aleatória.

A maioria dos navegadores é capaz de tentar outro servidor se um falhar. (Consulte: Resiliência da Web com DNS Round Robin )

Você pode ter um endereço IP de cluster suportado por vários servidores com VRRP ou CARP . O servidor de backup assume o endereço quando o servidor principal falha.

jkj
fonte
O interlocutor não estava falando especificamente sobre apenas servidores da WWW. De fato, o xe mencionou explicitamente os servidores de correio e nome.
JdeBP
@JdeBP: Oh. Eu pareço ser cego. Desculpe: P
jkj
0

Sim, mas você tem que fazer isso sozinho ;-)

Você poderia fornecer mais informações sobre por que deseja um "registro A de backup" e como e em que circunstâncias você gostaria de ir para o backup.

Além disso, seria útil conhecer o relacionamento da perspectiva da rede entre os hosts principal e de backup.

dmourati
fonte
0

Essa é uma pergunta bastante antiga, mas duas tecnologias bastante significativas não foram levantadas nas respostas: DNS dinâmico e CDNs.

O DNS dinâmico é configurado para que os registros DNS possam ser modificados quase em tempo real, para que um cliente de monitoramento possa acionar alterações nos registros DNS A públicos conforme a disponibilidade do serviço. (Obviamente, seu serviço de hospedagem DNS deve oferecer suporte ao DNS dinâmico.)

As CDNs também podem ser usadas para fornecer DNS, como por exemplo o Cloudflare (que foi lançado em 2010, acredito).

yourcomputergenius
fonte