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

Question

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

Nossa atual estratégia de resolução de DNS é baseada 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 de 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 data centers estiver inoperante, queremos que nosso servidor de nomes exclua esse endereço IP que pertence ao data center com falha. Portanto, esperamos poder obter uma estratégia mais dinâmica para nossa resolução de DNS. Existe uma solução para isso?

    

Answer 1

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 protocolo de roteamento da Internet (BGP) direcione os usuários para o 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.8 para DNS. Ele é resolvido em diferentes locais ao redor do mundo e, se um local ficar inativo, ele vai para o próximo local mais próximo.

A resposta não é DNS, é roteamento.

    

Answer 2

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

• Roteamento baseado em latência - direcione os usuários finais para a região da AWS que fornece a menor latência possível.

• Geo DNS - Rotear os usuários finais para um endpoint específico que você especificar com base na localização geográfica do usuário final.

• Verificações de saúde e tolerância a falhas - o Amazon Route 53 pode monitorar a integridade e o desempenho de seu aplicativo, bem como seus servidores da Web e outros recursos.

• ... e muitos recursos avançados de DNS . . p>

Você não precisa hospedar seu site na AWS para poder usar o Route53, ele trabalhará com muito prazer com serviços implantados em datacenters particulares.

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

Espero que ajude:)

    

Answer 3

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

O servidor DNS tem 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 por uma máquina, ela sabe que envia um ARP reverso para o endereço IP dado o endereço MAC e usa a resposta para construir a resposta do 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 realizar qualquer novo esquema que você queira resolver nomes para endereços IP.

A pergunta atual parece ser como obter o endereço IP do cliente para decidir para onde enviá-lo. Este é um pequeno problema XY. O que você realmente quer é o ISP do cliente para geolocalizar, e você pode fazer isso diretamente do endereço IP fazendo a solicitação, assumindo que não é 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 (isto é, a partir do servidor DNS tente localizar o endereço IP de chamada) e redirecionar adequadamente. Veja aqui como geolocalizar: link

Você realmente não quer anycast aqui, mas algo mais sensato. Anycast tem a propriedade chata de redirecionar pacotes no meio do seu fluxo TCP causando confusão em massa.

Ron Maupin afirma que anycast é confiável para 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 a montante, a maneira óbvia é que ambos estão em Wichita. Isso não é correto, pelo que uma simples demonstração de física será suficiente.

O intervalo para 8.8.4.4 é medido a 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 é 1297 milhas. O tempo mínimo de ida e volta é, portanto, (1297 * 2 milhas / 225.000 quilômetros por segundo (velocidade da luz em vidro)) que é 18,55ms. Portanto, eu não deveria ter resposta de volta mais rápida do que 28ms, mas consegui uma de volta em 25ms.

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

    

Answer 4

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