Um registro DNS que mudará frequentemente? [fechadas]

Como faço para gravar um registro de domínio que pode mudar com frequência?

Vamos dizer example.orgpontos para 203.0.113.0. Dois minutos depois, ele tem que apontar para 198.51.100.0.

Serão sites normais atrás do domínio ("normais" apenas no sentido de serem acessados ​​usando navegadores comuns), mas com uma vida útil muito curta. O domínio apontará para um endereço por três a quatro horas, no máximo, antes de ser trocado ou desligado. Não há necessidade de proteger o servidor DNS de consultas frequentes.

Minha abordagem seria definir o TTL para 60 segundos e simplesmente alterar o registro quando a troca fosse feita. Na pior das hipóteses, faria com que o usuário esperasse no máximo 60 segundos antes que um novo servidor fosse acessível.

De alguma forma, não confio nisso ... Alguns ISPs ou navegadores poderiam ignorar ou substituir o TTL, não podiam? Se é uma preocupação válida, o que seria de esperar um TTL razoável?

Obrigado!

Isso é chamado de registros DNS de fluxo rápido . E geralmente é como os autores de malware ocultam seus servidores de infraestrutura.

Embora isso funcione para o seu plano, não é o melhor. Você provavelmente precisará ter um servidor sobressalente ou mais on-line e não fazer nada quase o tempo todo. Somente quando você tiver um problema com o servidor principal, você mudará para o próximo.

Mesmo se você tiver um TTL de 1 minuto, um registro provavelmente será válido por mais do que isso:

1. Caches do navegador

   Os navegadores geralmente armazenam em cache os registros DNS por um período variável de tempo. O Firefox usa 60 segundos , o Chrome também usa 60 segundos , IE 3.xe em cache anterior por 24 horas , IE 4.xe acima em cache por 30 minutos.

2. Cache do SO

   O Windows geralmente não respeita o TTL . Um TTL para DND não é como o TTL para um pacote IPv4. É mais uma indicação de atualização do que uma atualização obrigatória. O Linux pode ter o nscd configurado para definir a quantidade de tempo que o usuário deseja, desconsiderando o DNS TTL. Ele pode armazenar em cache entradas por uma semana, por exemplo.

3. Cache do ISP

   Os ISPs podem (e alguns usarão) usar cache agressivo para diminuir o tráfego. Eles podem não apenas alterar o TTL, mas armazenar em cache os registros e devolvê-los aos clientes sem nem mesmo pedir aos servidores DNS upstream. Isso é mais prevalente nos ISPs móveis, pois eles alteram o TTL para que os clientes móveis não se queixem da latência do tráfego.

Um balanceador de carga é feito para fazer exatamente o que você deseja. Com um balanceador de carga, você pode ter 2, 4 ou 10 servidores on-line ao mesmo tempo, dividindo a carga. Se um deles ficar offline, o serviço não será afetado. A alteração dos registros DNS terá um tempo de inatividade entre o momento em que o servidor desligar e o DNS for alterado. Levará mais de um minuto, porque você precisa detectar o tempo de inatividade, alterar os registros e aguardar a propagação.

Portanto, use um balanceador de carga. É feito para fazer o que você quer e você sabe exatamente o que esperar. Uma configuração de DNS de fluxo rápido terá resultados mistos e inconsistentes.

O DNS e como ele funciona talvez seja acompanhado por mais mal-entendidos, lendas, superstições e mitologia, como qualquer aspecto da TI.

Mesmo aqueles de nós que sabem que estamos essencialmente mentindo (ou pelo menos drasticamente simplificando demais) quando falamos sobre "propagação" de mudanças ainda tendem a usar o termo para descrever algo que é - simultaneamente - extremamente simples e direto ... ainda difícil de explicar ... e não tem nada a ver com propagação em si , mas tudo a ver com cache e cache negativo, os quais são um componente essencial de como o sistema funciona (e, sem dúvida, como evita o colapso total sob seu próprio peso) - essencialmente o avesso, o oposto da "propagação" real - puxar - não empurrar.

Apesar de toda a preocupação e preocupação com TTLs curtos, eles tendem a funcionar com mais frequência, a ponto de ser do seu interesse simplesmente experimentá-los. No $ {day_job}, quando nossos sites migram de uma plataforma "antiga" para uma plataforma "nova", isso significa que eles estão migrando de maneira que nada na infraestrutura seja compartilhado. Meu primeiro passo nessa migração é reduzir o TTL para os 60 anos o suficiente antes do corte, para que o antigo TTL tenha múltiplos múltiplos de si mesmo, dando-me uma garantia razoável de que esses RRs de transição com TTLs curtos "se propagarão" . " Quando estou pronto para o corte, reconfiguro o balanceador antigo¹ para fixar o tráfego no novo sistema - através da Internet - de modo que o balanceador não esteja mais equilibrando vários sistemas internos, mas sim "

Então eu passo o DNS e assisto o novo balanceador e o antigo.

Sempre fico agradavelmente surpreso com a rapidez com que a transição ocorre. Os holdouts quase sempre são aranhas de busca e sites de "verificação de saúde" de terceiros que inexplicavelmente se prendem aos registros antigos.

Mas há um cenário que se quebra de forma previsível: quando as janelas do navegador de um usuário permanecem abertas, elas tendem a trancar-se no endereço já descoberto e geralmente persiste até que todas as janelas do navegador sejam fechadas.

Mas na narrativa acima, você encontra a solução para o problema: um "balanceador de carga" - especificamente e mais precisamente, um proxy reverso - pode ser o sistema para o qual o registro DNS exposto aponta.

O proxy reverso encaminha a solicitação para o endereço IP de destino correto, que é resolvido usando um segundo nome de host "fictício" com um TTL curto, que aponta para o servidor de back-end real.³ Como o proxy sempre respeita o TTL do DNS nesse entrada DNS fictícia, você tem a garantia de uma troca rápida e completa.

A desvantagem é que você pode rotear o tráfego através de infraestrutura extra desnecessária ou pagar mais pelo transporte através de vários limites da rede, de forma redundante.

Existem serviços que fornecem esse tipo de capacidade em escala global, e o que eu estou mais familiarizado é o CloudFront. (Provavelmente, o Cloudflare serviria exatamente para o mesmo propósito, pois a pequena quantidade de testes que fiz indica que ele também se comporta corretamente, e tenho certeza de que existem outros.)

Embora comercializado principalmente como CDN, o CloudFront é uma rede global de proxies reversos com a capacidade de armazenar em cache opcionalmente as respostas. Se www.example.comapontar para o CloudFront e o CloudFront estiver configurado para encaminhar essas solicitações para backend.example.com, e o registro DNS backend.example.comusar um TTL curto, o CloudFront fará a coisa certa, porque honra esse TTL curto. Quando o registro de back-end é alterado, todo o tráfego é migrado no momento em que o TTL acaba.

O TTL no registro frontal apontando para o CloudFront e se os navegadores e os resolvedores de cache estão honrando isso não são importantes, porque as alterações no destino de back-end não exigem alterações no www.example.comregistro ... portanto, a noção de "A Internet" tem, em relação ao destino correto, www.example.comé consistente, independentemente de onde esteja o sistema de back-end.

Isso, para mim, resolve o problema completamente, aliviando o navegador de qualquer necessidade de "seguir" as alterações no IP do servidor de origem.

tl; dr: direcione as solicitações para um sistema que serve como proxy para o servidor Web real, para que apenas a configuração do proxy precise acomodar a alteração no IP do servidor de origem - não no DNS voltado para o navegador.

Observe que o CloudFront também minimiza a latência de alguma mágica de DNS que impõe na parte frontal, o que resulta na www.example.comresolução para o local de borda do CloudFront mais ideal com base no local do navegador que está consultando www.example.com, para que haja uma chance mínima de tráfego seguindo uma rota desnecessariamente tortuosa do navegador à borda até a origem ... mas essa parte é transparente e automática e está fora do escopo da pergunta.

E, é claro, o cache de conteúdo também pode ser útil ao reduzir a carga no servidor ou transporte de origem - configurei sites no CloudFront onde o servidor de origem estava em um circuito ADSL, e o ADSL é inerentemente restrito à largura de banda upstream. O servidor de origem ao qual o CloudFront se conecta para buscar o conteúdo não precisa ser um servidor dentro do ecossistema da AWS.

Speak Falo do balancer como uma entidade única quando, na verdade, possui vários nós. Quando o balanceador é um ELB, uma máquina atrás do balanceador age como um servidor de aplicativos fictício e faz o hairpin real para o balanceador da nova plataforma, pois o ELB não pode fazer isso sozinho.

² O único conhecimento do novo balanceador sobre o antigo é que ele precisa confiar no X-Forwarded-For do balanceador antigo e que não deve limitar a taxa baseada em IP nos endereços de origem do balanceador antigo.

³ Quando o proxy é um ou mais servidores que você controla, você tem a opção de ignorar o DNS no verso e simplesmente usar endereços IP na configuração do proxy, mas o cenário hospedado / distribuído discutido posteriormente precisa da segunda camada do DNS .

Quando altero os registros DNS, muitas vezes o endereço IP antigo será usado por meses. Dito isso, um TTL de apenas alguns segundos é o que a Amazon usa para criar um serviço de fallback, por exemplo.

Em vez de alterar o DNS, você pode colocar um servidor proxy / balanceador de carga na frente dele.

Você pode usar o DNS dinâmico. Isso foi projetado para precisamente o cenário mencionado pelo @glglgl em um comentário acima. Eu acredito que eles usam um TTL baixo que, como foi apontado anteriormente, pode não ser 100% eficaz, pois os clientes podem ignorá-lo. Mas funciona "muito bem".

Mesmo se você não estiver alterando seu IP com frequência, é importante manter seu TTL razoável. Muitos anos atrás, a empresa em que eu trabalhava para ISPs alterados fazia com que nossos IPs mudassem. Infelizmente, tínhamos definido nosso TTL para algo ridículo como um mês, para que os antigos registros DNS estivessem sendo mantidos por um longo tempo.