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 .