Um servidor de nomes poderia resolver endereços IP dinamicamente com base em alguma estratégia?

11

Registramos alguns servidores de nomes para resolução de DNS em nosso site, implantado em vários datacenters.

Nossa estratégia atual de resolução de DNS é que, com base nos diferentes endereços IP do cliente, o servidor de nomes retornará endereços IP diferentes para o mesmo domínio. Por exemplo, se o endereço IP do cliente for da América do Norte, o servidor de nomes retornará um endereço IP, que é o endereço IP do nosso data center na América do Norte.

Mas o endereço IP do cliente às vezes não é o endereço IP real dos usuários. Pode ser um endereço IP do DNS que pertence a um ISP ou a um servidor proxy. Por outro lado, se um de nossos datacenters estiver inativo, queremos que nosso servidor de nomes exclua o endereço IP que pertence ao datacenter com falha. Portanto, esperamos poder obter uma estratégia mais dinâmica para nossa resolução de DNS. Existe uma solução para isso?

networking  domain-name-system 
— yifan
fonte
Isso soa como um caso para anycast.
— Ron Maupin
1
@RonMaupin Deve-se salientar que, para fazer qualquer transmissão, é necessário ter uma alocação de bloco de endereço independente do provedor e, mais importante, executar o BGP para anunciar os prefixos de cada centro de dados. Esse é um nível totalmente novo de operações e não é algo com o qual muitas empresas "orientadas a conteúdo" tenham experiência. A solução baseada em DNS parece muito mais fácil.
— IPX
@IPX, eu imaginaria que uma empresa com data centers ao redor do mundo, como parece na pergunta, terá endereçamento independente de provedor e seu próprio número AS. Com isso, o anycast é gratuito e fácil.
— precisa
1
@ RonMaupin, se a empresa do OP estivesse realmente operando vários datacenters em todo o mundo, sim, mas provavelmente eles não estariam fazendo uma pergunta relativamente simples por aqui. Aposto que eles simplesmente colocam seu próprio HW ou contrataram HW em vários datacenters comerciais e realmente não se importam com operações de rede avançadas. É o que tenho visto muitas empresas de médio porte fazer por redundância. Se for esse o caso, o DNS é a resposta, não o roteamento .
— IPX
@IPX, o que recordo da pergunta é que a empresa possui data centers em todo o mundo e, se um data center travar, o tráfego direcionado deve ser direcionado para um data center diferente (" se um de nossos data centers estiver inoperante .. . "). Simplesmente respondi à pergunta conforme solicitado, em vez de tentar adivinhar sobre hospedagem de terceiros, e também fazemos parte disso, mas ainda temos nosso próprio endereço independente de provedor e número AS usado para fazer parceria com os ISPs. Isso permite a negociação de contratos e a mudança de ISPs sem interromper a rede de readdressing.
— Ron Maupin

Respostas:

16

Parece que você quer anycast. Esse é o tipo de coisa que sites como o Google usam. Você tem um único endereço (resolvido pelo DNS) para todos os seus sites e permite que o BGP direcione os usuários ao site mais próximo (pelo protocolo de roteamento). Se um site for desativado, o próximo site mais próximo será colocado na tabela de roteamento da Internet automaticamente pelo BGP.

O exemplo clássico é 8.8.8.8para DNS. Ele é resolvido para diferentes locais ao redor do mundo e, se um local ficar inativo, será direcionado para o próximo local mais próximo.

A resposta não é DNS, é roteamento.

— Ron Maupin
fonte
2
O Anycast normalmente não é útil para protocolos baseados em TCP, porque pacotes pertencentes à mesma conexão podem ir para servidores diferentes.
— Paŭlo Ebermann 25/11/19
2
@ PaŭloEbermann que não é um problema quando você faz isso com roteamento BGP, como as rotas geralmente não mudam quando anunciou (apenas pequenas alterações)
— Ferrybig
2
@ PaŭloEbermann Você pode fazer qualquer transmissão nos balanceadores de carga baseados em DSR, desde que todos os balanceadores de carga concordem em como escolher back-ends.
— kasperd
3
@ PaŭloEbermann, isso é um equívoco. Todo o tráfego de um host irá para um servidor, a menos que o servidor fique inoperante, o tráfego será direcionado para um servidor diferente. Sim, isso interromperia a conexão TCP, mas esse seria o caso sempre que o servidor ao qual você está conectado cair. Anycast não é uma coisa rotineira. O roteamento é determinístico, portanto, anycast é determinístico.
— Ron Maupin
2
O roteamento @RonMaupin Anycast não é tão estável quanto você sugere. E o Google não usa anycast do jeito que você está dizendo. Se você quiser saber como o Google realmente faz isso, consulte a página 227 em A pasta de trabalho de confiabilidade do site publicada pelo Google. Em resumo, a camada de balanceamento de carga por trás do roteamento anycast compensa as mudanças inevitáveis ​​no roteamento que, de outra forma, interromperiam as conexões TCP.
— kasperd
9

O que você precisa é exatamente o que o serviço DNS do Amazon Route53 oferece:

Você não precisa hospedar seu site na AWS para poder usar o Route53; ele funcionará com os serviços implantados em centros de dados privados.

A menos que você seja um preço no Facebook ou no Google, também não deve ser um problema, a partir de US $ 0,40 por milhão de solicitações (consulte os detalhes do preço ).

Espero que ajude :)

— MLu
fonte
Você já usou algum produto que não seja da Amazon para isso?
— chicks
@icks nope eu não tenho. Costumo sempre usar a melhor ferramenta para o trabalho e o Route53 se encaixa na conta na maioria dos casos. No entanto, se você pesquisar no Google algo como "serviço de DNS geográfico", obterá algumas opções. Olhei rapidamente alguns, mas eles parecem muito caros (cerca de US $ 50 / mês - muito mais do que você provavelmente gastaria com o AWS Route53).
— MLU
2
Eu ampliaria minha perspectiva um pouco mais antes de chamar a primeira ferramenta que encontrei a melhor para a maioria dos casos. O Route53 pode ser o melhor para todos, mas como você saberia se não tentou mais nada?
— pintainhos
-1

Eu tive essa ideia e comecei a codificá-la, mas nunca terminei, pois a necessidade evaporou primeiro.

O servidor DNS possui os nomes de host e endereços MAC de todas as máquinas em sua LAN e uma maneira de alcançá-los. Quando recebe uma solicitação de uma máquina que conhece, envia um ARP reverso para o endereço IP, dado o endereço MAC e usa a resposta para construir a resposta DNS.

Isso não tem nada a ver com o que você está tentando fazer, mas ilustra o ponto. Um servidor DNS pode, em teoria, ser codificado para executar qualquer esquema novo que você queira resolver nomes para endereços IP.

A questão real parece ser como obter o endereço IP do cliente para decidir para onde enviá-lo. Este é um pequeno problema de XY. O que você realmente deseja é que o ISP do cliente faça a geolocalização, e você pode obtê-lo diretamente do endereço IP que faz a solicitação, supondo que não seja 8.8.4.4 ou algum outro serviço de redirecionamento de DNS. Na minha opinião, a melhor solução para os redirecionadores de DNS é ignorar o problema e fazer uma geolocalização auto-relativa (ou seja, do servidor DNS tentar localizar o endereço IP de chamada) e redirecionar adequadamente. Veja aqui como obter a localização geográfica: /programming/2574542/location-detecting-techniques-for-ip-addresses

Você realmente não quer anycast aqui, mas algo mais são. O Anycast tem a propriedade irritante, pois pode redirecionar pacotes no meio do seu fluxo TCP, causando confusão em massa.

Ron Maupin afirma que o anycast é confiável para o TCP. Aqui está o traceroute mostrando o contrário:

 3  cr1-rhe-a-be153.bb.as11404.net (174.127.183.14)  20.657 ms  20.763 ms  19.660 ms
 4  cr1-che-b-be-2.as11404.net (192.175.29.161)  22.550 ms  23.562 ms  23.538 ms
 5  * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108)  24.409 ms  38.083 ms
 6  72.14.222.146 (72.14.222.146)  40.038 ms  39.106 ms  39.125 ms
 7  108.170.242.225 (108.170.242.225)  37.930 ms 108.170.243.1 (108.170.243.1)  35.434 ms 108.170.242.225 (108.170.242.225)  33.694 ms
 8  209.85.240.249 (209.85.240.249)  33.476 ms 108.170.232.65 (108.170.232.65)  31.683 ms 108.170.234.155 (108.170.234.155)  30.754 ms
 9  google-public-dns-b.google.com (8.8.4.4)  30.491 ms  28.644 ms  25.718 ms

Se você tentar geolocalizar os endereços IP upstream da maneira óbvia, obtém os dois em Wichita. Isso não está correto, pelo qual uma simples demonstração de física será suficiente.

O intervalo para 8.8.4.4 é medido em 30ms, dos quais os primeiros 18ms são a penalidade local (o salto 3 é o roteador local do meu ISP). Minha distância para Wichita é de 1297 milhas. O tempo mínimo de ida e volta é, portanto, (225.000 quilômetros por segundo (velocidade da luz no vidro)), que é de 18,55ms. Portanto, eu não deveria receber resposta mais rápido que 28ms, mas recebi uma resposta em 25ms.

Os pacotes estão chegando ao Google por duas rotas BGP diferentes. BGP não escolheu o mais próximo.

— Joshudson
fonte
— yifan
Comentários não são para discussão prolongada; esta conversa foi movida para o bate-papo .
— Ward - Restabelece Monica
Mudei todos os comentários para o bate-papo, mas, como havia muitos e alguns foram movidos automaticamente, não tenho certeza se o bate-papo posterior possui todos eles. De qualquer forma, uma discussão mais aprofundada sobre a validade dessa resposta e como os roteadores funcionam etc. não deve estar nos comentários, mantenha-a em uma das salas de bate-papo. Quaisquer outros comentários aqui serão excluídos.
— Ward - Restabelece Monica
-2

O que você precisa pode ser alcançado com alguma combinação de DNS anycast e RFC-7871.

— Edheldil
fonte
1
Mais detalhes melhorariam sua resposta
— Dave M
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.