Como 8.8.8.8 é mantido * sempre * vivo?

Question

Eu sei como você pode gerenciar a redundância do datacenter se há servidor DNS funcionando que pode apontar para qualquer site de trabalho da sua empresa - há VRRP, multi WAN etc etc. Mas como os próprios servidores DNS são mantidos online ? É o primeiro hit quando alguém se conecta ao serviço e não pode ser realmente provisionado. Por exemplo, 8.8.8.8 ou 8.8.4.4 . Não me lembro de eles estarem abatidos. Sempre. Como os ISPs conseguem manter esses IPs sempre online?

Eu sei que provavelmente é uma questão muito ampla, mas eu gostaria de ouvir apenas nomes de protocolos / técnicas que podem ser usados para isso. Eu posso ler detalhes sobre eles por conta própria.

    

Answer 1

Primeiro de tudo, o VRRP não depende de DNS de forma alguma. Para redundância em um único site, você pode executar servidores DNS em um endereço VRRP compartilhado muito bem.

Mas, como outros já mencionaram nos comentários, os serviços também usam roteamento anycast , o que essencialmente significa que o mesmo endereço IP existe em vários lugares ao redor do mundo. Quando um site inteiro fica inativo, as rotas de todo o mundo são recalculadas para que seus pacotes acabem indo para outro site de trabalho.

Um exemplo melhor do que o DNS público do Google seriam os servidores DNS root - aqueles que veiculam a . zone e mantêm ponteiros para com , org , eu e assim por diante - porque eles têm um mapa de cada instância dos 13 endereços lógicos. O "L" da ICANN é servido por 160 sites diferentes!

Note que anycast não tem nada a ver com round-robins baseados em DNS (onde o mesmo nome tem múltiplos endereços). Anycast é feito essencialmente mentindo para o protocolo de roteamento.

A Internet usa o BGP para trocar informações de roteamento entre organizações.

O

BGP inerentemente suporta a seleção do melhor de várias rotas para a mesma rede, com base em vários critérios. Por exemplo, o mesmo cliente pode ter uplinks redundantes para o mesmo ISP (anunciando duas rotas que diferem apenas em peso / preferência). Ou o cliente pode ter uplinks por meio de vários ISPs, e todos selecionarão sua rota preferida (principalmente o caminho AS mais curto) - essa é a essência da "verdadeira" multi-WAN.

Multihoming

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter--+            │
             ¦    │             ¦--DNSserver │
client 2 ---ISP---│--BGProuter--+            │
                  └──────────────────────────┘

No entanto, o BGP só leva o tráfego para as portas de entrada, mas não se importa com o que acontece além disso. Então, se você configurar internamente ambas as rotas para o mesmo servidor, você obterá multihoming. Mas se cada "entrada" leva a um servidor diferente (configurado para o mesmo IP), você recebe anycast.

Anycast... kind of?

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    │                          │
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

Importante, isso também significa que o BGP não se importa se o AS não é contíguo a todos. Para obter redundância em todo o mundo, basta anunciar a mesma rede a partir de vários locais físicos - se você conectar esses locais juntos (para que eles rotearem essa rede para um único local), você obterá multihoming; se são ilhas, você recebe anycast.

Anycast

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    └──────────────────────────┘
             ¦
             ¦    ┌────────[AS 65535]────────┐
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

(Aliás, nem precisa ser o mesmo AS - por exemplo, os relés 6to4 são executados por várias organizações independentes, cada um deles anunciando sua própria rota em direção a 192.88.99.0/24 .)

Advertências:

• O Anycast fornece redundância, mas não balanceamento de carga. Depois que o BGP convergir, cada roteador terá escolhido uma única rota preferencial (ou ocasionalmente algumas) e continuará usando-a até que a rede seja alterada.

• No entanto, você não pode prever quanto tempo as rotas permanecerão estáveis, portanto, serviços com previsão de anycasting podem ser complicados. O DNS leva a cabo devido a ser apátrida e usar principalmente UDP (o EDNS reduz a necessidade de conexões TCP).

• Deve haver coordenação entre o serviço real e o roteador BGP, para que a rota seja retirada se o serviço falhar.

Veja também "História de 4.2.2.2. Qual é a história?" na lista de discussão do NANOG: postar 1 , postar 2 .

    

Answer 2

Uma maneira de conseguir isso é usar balanceadores do lado do servidor . Quando você se conecta ao gateway no IP 8.8.8.8, ele distribuirá a solicitação para um servidor livre dentro do sistema. Como resultado, quando um servidor morre, ele não desativa todo o sistema.

For Internet services, server-side load balancer is usually a software program that is listening on the port where external clients connect to access services. The load balancer forwards requests to one of the "backend" servers, which usually replies to the load balancer. This allows the load balancer to reply to the client without the client ever knowing about the internal separation of functions. It also prevents clients from contacting back-end servers directly, which may have security benefits by hiding the structure of the internal network and preventing attacks on the kernel's network stack or unrelated services running on other ports.

Some load balancers provide a mechanism for doing something special in the event that all backend servers are unavailable. This might include forwarding to a backup load balancer, or displaying a message regarding the outage.

It is also important that the load balancer itself does not become a single point of failure. Usually load balancers are implemented in high-availability pairs which may also replicate session persistence data if required by the specific application.[5]