Mudei meu TTL de 24 horas para 5 minutos. Preciso esperar 24 horas antes de alterar os registros?

37

Estou migrando nosso aplicativo de um servidor em nuvem da Rackspace para um servidor dedicado.

Quero reduzir o aplicativo por ~ 5 minutos para copiar os dados do servidor em nuvem para o servidor dedicado, portanto, não desejo que as solicitações sejam enviadas para o servidor antigo após a cópia dos dados.

Quero apontar nosso registro DNS para o novo servidor, mas o TTL foi definido para 24 horas. Eu mudei para 300 segundos. Preciso esperar as 24 horas antes de atualizar o ip que o domínio aponta para / copiar os dados?

domain-name-system  rackspace  ttl 
— wobbily_col
fonte
9
Aliás, mesmo se você esperar pelo TTL, recomendo fortemente que você edite a configuração no servidor antigo para garantir que não sejam aceitas mais atualizações lá. Nem todos os resolvedores de DNS realmente seguem os padrões.
— Peter Green
5
O que fiz ao mover um aplicativo Web de um provedor de hospedagem para outro foi usar um encaminhamento de porta ssh para obter visitantes ainda usando o IP antigo direcionado para o novo servidor.
— Kasperd #

Respostas:

58

Qualquer pessoa que possua uma cópia em cache do registro de domínio não se incomodará em atualizá-lo por 24 horas; portanto, se sua intenção é ter uma janela de indisponibilidade de no máximo 5 minutos, você deve esperar até que todos os caches pendentes sejam atualizados para não viver mais. de 5 minutos.

— Jeff Meden
fonte
23
... por 24 horas since they last cached it. Isso pode variar de 1 a 86399 segundos.
— user9517 suporta GoFundMonica
6
@Iain Você deve assumir o pior, já que qualquer um ou todos eles poderiam apenas armazená-lo em cache imediatamente antes da alteração.
— Barmar
6
@ Barmar Não assuma nada. Muitos ISPs simplesmente ignoram o TTL.
— user9517 suporta GoFundMonica
13
@Iain eu trabalhava na Akamai, uma CDN que faz uso pesado de TTLs curtos (como 60 segundos) para balanceamento de carga. Lembro que fizemos um estudo e descobrimos que a maioria dos ISPs obedeceu aos nossos TTLs.
— Barmar
1
Eu trabalho para uma empresa de hospedagem na web, nossa experiência é que TTLs baixos são mais propensos a serem ignorados do que superiores.
— Henrik - pare de magoar Monica
39

É (potencialmente) ainda pior do que isso - você precisa esperar 24 horas após a atualização de todos os seus servidores autorizados. A maneira normal de as atualizações acontecerem é que você faça uma alteração na zona no servidor principal e, em seguida, cada um dos secundários transfira os novos dados da zona na próxima vez que eles fizerem check-in com o primário. A frequência de check-in é controlada pelo intervalo de atualização no registro SOA da zona. Portanto, no pior caso, você teria que esperar o intervalo de atualização da zona + o TTL do registro.

Você também pode ter que esperar tanto tempo para que as alterações reais do registro. Um TTL de 5 minutos não será muito bom se os secundários forem atualizados apenas a cada 6 horas. Portanto, você provavelmente deseja diminuir o intervalo de atualização na zona e também para o período em que deseja fazer alterações rápidas.

Lembre-se, isso pode não se aplicar à sua configuração. Se você possui um sistema que atualiza todos os servidores autorizados, isso não é um problema (e eu não estou familiarizado com a configuração de DNS da Rackspace). Mas recomendo consultar todos os seus servidores autorizados individualmente ( dig server.example.com @secondaryserver.example.com) para garantir que eles tenham o novo TTL antes de iniciar sua contagem regressiva de 24 horas.

— Gordon Davisson
fonte
1
Essa deve ser a resposta aceita.
— dotancohen
4
Você parece estar ignorando o protocolo DNS Notify, que solicita que os servidores escravos atualizem logo após a atualização do mestre. A maioria dos servidores DNS usa esse recurso.
— Barmar
@ Barmar: Isso é verdade, mas ao mesmo tempo o mestre pode demorar um pouco para atualizar, dependendo do provedor. (Por exemplo, alguns provedores única reconstruir zonas do banco de dados a cada 5 ou 15 minutos, embora os modernos fazê-lo instantaneamente.)
— grawity
1
Meu comentário foi abordar apenas a questão de aguardar o intervalo de atualização, que está obsoleto na atualidade. Esperar a atualização do mestre é verdadeiro, a menos que você opere seu próprio mestre. Mas acho improvável que eles precisem lidar com a hora exata em que tudo se torna seguro para atualizar; 5-15 minutos extras não devem fazer muita diferença. O ponto da pergunta original é se eles precisam esperar um dia inteiro.
— Barmar
1
@GordonDavisson: Se você não confia - verifique. dig +nssearch example.comé uma ferramenta útil para comparar rapidamente SOAs em todos os servidores; nsdiff mostra diferenças reais.
— grawity 5/05
23

Sim, você deveria esperar. Mesmo assim, é claro que não é garantido que todos respeitem o TTL.

— Sven
fonte
6
+1 para nem todo mundo obedece ao TTL; já vi retardatários chegarem uma semana depois de fazer uma alteração no DNS. Uma maneira de lidar com isso no passado foi configurar um novo nome exclusivo como um alias no novo site e usar um redirecionamento do site antigo para redirecionar usuários do domínio antigo para os novos, como www.mycompany .com -> newsite.mycompany.com
— Johnny
Sim, mas muitas pessoas desprezam por direito a ideia de ter que usar um novo nome. Nomes são marcas. Além disso, isso funciona apenas para HTTP e para praticamente nada mais.
— Sven
8
Outra opção é configurar o servidor antigo como um proxy reverso para o novo servidor. Você pode deixar isso por mais ou menos uma semana após a troca e desligá-lo quando não houver tráfego.
— Bdsl
1
As pessoas que têm um bom comportamento de servidores DNS que obedecem ao TTL nunca verão o novo domínio. E embora "apenas" funcione com HTTP (S), acho que você descobrirá que o HTTP é um protocolo bastante comum na Internet. de bdsl sugerem da criação de um proxy reverso é ainda melhor, mas é mais trabalho
— Johnny
@ Johnny O problema com um novo domínio é que você corre o risco de as pessoas marcarem esse domínio. A menos que você planeje deixar o novo domínio acessível para sempre.
— Bob
5

Reunir vários comentários e respostas ao procedimento completo seria algo parecido.

  1. Verifique se você pode atualizar seus servidores autorativos em tempo hábil.
  2. Reduza o TTL.
  3. Verifique se todos os servidores com autorização de autor possuem o novo ttl.
  4. Aguarde o TTL antigo para que os valores armazenados em cache com o antigo TTL sejam (principalmente) eliminados dos caches (você não pode garantir que eles desaparecerão de todos os cache, porque alguns caches podem ignorar os padrões).
  5. Coloque o site no servidor antigo no modo somente leitura (ou se você não puder fazer isso, substitua-o por uma página "estamos em manutenção").
  6. Execute a cópia final do servidor antigo para o novo servidor (resultando em um site somente leitura no novo servidor).
  7. Mude os registros DNS.
  8. Verifique se todos os servidores autorativos têm os novos registros DNS.
  9. Aguarde o novo ttl (você pode pular esta etapa se não se importar com o fato de alguns usuários poderem contribuir com o site e outros não verem os resultados dessas contribuições).
  10. Coloque o site no novo servidor no modo de leitura / gravação.
  11. Coloque um aviso no servidor antigo de que é uma cópia somente leitura desatualizada e que o usuário provavelmente quebrou o DNS.
  12. Aguarde um pouco até que os registros saiam dos caches DNS não compatíveis.
  13. Descomissione o servidor antigo.
— Peter Green
fonte
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.