Esta é uma pergunta canônica sobre redundância geográfica do DNS.

É um conhecimento extremamente comum que os servidores DNS com redundância geográfica localizados em locais físicos separados são altamente desejáveis ​​ao fornecer serviços da Web resilientes. Isso é abordado em profundidade pelo documento BCP 16 , mas alguns dos motivos mencionados com mais freqüência incluem:

• Proteção contra desastres no datacenter. Terremotos acontecem. Os incêndios acontecem nos racks e eliminam servidores e equipamentos de rede próximos. Vários servidores DNS não farão muito bem se problemas físicos no datacenter derrubarem os dois servidores DNS de uma vez, mesmo que não estejam na mesma linha.

• Proteção contra problemas de pares a montante. Vários servidores DNS não evitarão problemas se um par de rede upstream compartilhado tirar um cochilo. Se o problema do upstream o coloca completamente offline, ou simplesmente isola todos os seus servidores DNS de uma fração da sua base de usuários, o resultado final é que as pessoas não podem acessar seu domínio, mesmo que os próprios serviços estejam localizados em um datacenter completamente diferente.

Tudo bem, mas os servidores DNS redundantes são realmente necessários se eu estiver executando todos os meus serviços com o mesmo endereço IP? Não vejo como ter um segundo servidor DNS me traria algum benefício se, de qualquer maneira, ninguém pudesse acessar qualquer coisa fornecida pelo meu domínio.

Entendo que essa é uma prática recomendada, mas isso realmente parece inútil!

Nota: Conteúdo em disputa, consulte os comentários para ambas as respostas. Foram encontrados erros e essas perguntas e respostas precisam de uma revisão.

Por enquanto, estou removendo a aceitação desta resposta até que o estado dessas perguntas e respostas canônicas seja devidamente abordado. (excluir esta resposta também excluiria os comentários anexados, o que não é o caminho para a IMO. provavelmente a transformará em uma resposta do wiki da comunidade após uma extensa edição.)

Eu poderia citar RFCs aqui e usar termos técnicos, mas esse é um conceito que muitas pessoas sentem falta dos dois extremos do espectro do conhecimento e vou tentar responder isso para o público mais amplo.

Entendo que essa é uma prática recomendada, mas isso realmente parece inútil!

Pode parecer inútil ... mas na verdade não é!

Servidores recursivos são muito bons em lembrar quando servidores remotos não respondem a uma consulta, principalmente quando tentam novamente e ainda assim nunca veem uma resposta. Muitos implementam o cache negativo dessas falhas de comunicação e colocam temporariamente servidores de nomes que não respondem na caixa de penalidades por um período não superior a cinco minutos. Eventualmente, esse período de "penalidade" expira e eles retomarão a comunicação. Se a consulta incorreta falhar novamente, eles voltarão imediatamente para a caixa, caso contrário, voltará aos negócios normalmente.

É aqui que encontramos o problema do servidor de nomes único:

• O período de penalidade é, por natureza, a implementação sempre maior ou igual à duração do problema de rede. Em quase todos os casos, será maior, no máximo por mais cinco minutos.
• Se o seu servidor DNS único for para a caixa de penalidade, a consulta associada à falha ficará completamente inativa por toda a duração.
• Breves interrupções de roteamento acontecem na internet mais do que a maioria das pessoas imagina. As retransmissões TCP / IP e salvaguardas de aplicativos semelhantes fazem um bom trabalho em esconder isso do usuário, mas é um tanto inevitável. A Internet faz um bom trabalho para contornar esse dano, em grande parte devido a salvaguardas incorporadas nos vários padrões que suportam a pilha de rede ... mas isso também inclui os embutidos no DNS, e ter servidores DNS com redundância geográfica é um parte disso.

Para encurtar a história, se você optar por um único servidor DNS (isso inclui o uso do mesmo endereço IP várias vezes nos NSregistros), isso acontecerá. Também acontecerá muito mais do que você imagina, mas o problema será tão esporádico que as chances da falha 1) ser relatada a você, 2) ser reproduzida e 3) estar ligada a esse problema específico estão extremamente próximas zero. Eles praticamente eram zero se você participasse das perguntas e respostas sem saber como esse processo funcionava, mas, felizmente, isso não deveria ser o caso agora!

Isso deveria incomodá-lo? Não é realmente o meu lugar para dizer. Algumas pessoas não se importam com esse problema de interrupção de cinco minutos, e eu não estou aqui para convencê-lo disso. O que estou aqui para convencê-lo é que, de fato, você sacrifica algo executando apenas um único servidor DNS e em todos os cenários.

O OP pergunta:

Tudo bem, mas os servidores DNS redundantes são realmente necessários se eu estiver executando todos os meus serviços com o mesmo endereço IP? Não vejo como ter um segundo servidor DNS me traria algum benefício se, de qualquer maneira, ninguém pudesse acessar qualquer coisa fornecida pelo meu domínio.

Ótima pergunta!

A melhor resposta é dada pelo professor Daniel J. Bernstein, PhD Berkeley , que não é apenas um pesquisador, cientista e criptologista de renome mundial, mas também escreveu um pacote DNS muito popular e bem recebido, conhecido como DJBDNS ( lançado em 2001- 02-11 , ainda popular até hoje).

http://cr.yp.to/djbdns/third-party.html (11-01-2003)

Custos e benefícios do serviço DNS de terceiros

Preste atenção a esta parte curta e sucinta:

Argumentos errôneos para serviço DNS de terceiros

...

A segunda tática é afirmar que os clientes DNS generalizados farão algo particularmente ruim quando não conseguirem acessar todos os servidores DNS. O problema com esse argumento é que a afirmação é falsa. Qualquer cliente desse tipo está claramente com problemas e não poderá sobreviver no mercado: considere o que acontece se os roteadores do cliente ficarem inativos por pouco tempo ou se a rede do cliente for temporariamente inundada.

Como tal, a resposta original para esta pergunta não poderia estar mais errada.

Sim, falhas de rede temporárias curtas, com duração de alguns segundos, acontecem de vez em quando. Não, uma falha na resolução de um nome durante essa interrupção não seria armazenada em cache por nenhum número de minutos (caso contrário, mesmo ter a melhor configuração de servidores de nomes autoritativos altamente disponíveis no mundo não ajudará).

Qualquer software que implemente liberalmente a diretriz conservadora de até 5 minutos da RFC 1998-03 para cache de falhas é simplesmente quebrado por design, e ter um servidor extra-redundante geograficamente não será prejudicial.

De fato, por quanto tempo um tempo limite de DNS é armazenado em cache? , no BIND, a SERVFAILcondição NÃO era tradicionalmente armazenada em cache antes de 2014 e, desde 2015, é armazenada em cache por padrão por apenas 1 segundo , menos do que seria necessário para um usuário comum atingir um tempo limite do resolvedor e pressionar o botão Atualizar novamente .

(E mesmo antes de chegarmos ao ponto acima de saber se uma tentativa de resolução deve ou não ser armazenada em cache, são necessários mais do que alguns pacotes descartados até que o primeiro SERVFAIL ocorra em primeiro lugar.)

Além disso, os desenvolvedores do BIND implementaram um teto para o recurso, de apenas 30 anos, que, mesmo como teto (por exemplo, o valor máximo que o recurso jamais aceitará), já é 10 vezes menor que a sugestão de 5 minutos (300 segundos) da RFC, garantindo que mesmo os administradores mais bem-intencionados (dos usuários de bola ocular) não consigam atirar nos próprios usuários no pé.

Além disso, existem muitas razões pelas quais você pode não querer executar um serviço DNS de terceiros - leia o todo djbdns/third-party.htmlpara obter todos os detalhes e alugar um pequeno servidor extra apenas para o DNS administrar por si mesmo dificilmente é necessário quando não há necessidade diferente do BCP 16 existe para tal empreendimento.

Na minha experiência "anedótica" pessoal de possuir e configurar nomes de domínio desde pelo menos 2002, posso dizer com toda a certeza e honestidade que, na verdade, eu realmente tive um tempo de inatividade significativo dos meus vários domínios devido à administração profissional. servidores de terceiros de meus registradores e provedores de hospedagem , que, um provedor por vez e ao longo dos anos, todos tiveram seus incidentes, não estavam disponíveis, reduziram meus domínios desnecessariamente, no mesmo momento em que meu próprio endereço IP (onde o HTTP e o SMTP de um determinado domínio foram hospedados a partir de) estavam totalmente acessíveis. Observe que essas interrupções ocorreram com vários fornecedores independentes, respeitados e administrados por profissionais, e não são de forma alguma incidentes isolados, e acontecem anualmente e, como serviço de terceiros,estão totalmente fora do seu controle ; acontece que poucas pessoas falam sobre isso a longo prazo.

Em resumo:

O DNS com redundância geográfica NÃO é necessário para sites pequenos.

Se você estiver executando todos os seus serviços com o mesmo endereço IP , a adição de um segundo DNS provavelmente resultará em um ponto adicional de falha e prejudicará a disponibilidade contínua do seu domínio. A "sabedoria" de sempre fazer isso em qualquer situação imaginável é um mito muito popular, de fato; BUSTED.

Obviamente, o conselho seria totalmente diferente caso alguns dos serviços do domínio, sejam web (HTTP / HTTPS), correio (SMTP / IMAP) ou voz / texto (SIP / XMPP), já sejam atendidos por terceiros fornecedores, nesse caso, eliminar o seu próprio IP como um ponto de falha único seria realmente uma abordagem muito sábia e a redundância geográfica seria realmente muito útil.

Da mesma forma, se você possui um site particularmente popular com milhões de visitantes e precisa de flexibilidade e proteções adicionais de DNS com redundância geográfica conforme o BCP 16, então… Você provavelmente não está usando um único servidor / site para web / email / voz / texto, portanto, essa pergunta e resposta obviamente não se aplicam. Boa sorte!