Cambié mi TTL de 24 horas a 5 minutos. ¿Tengo que esperar 24 horas antes de cambiar los registros?

37

Estoy migrando nuestra aplicación desde un servidor en la nube en Rackspace a un servidor dedicado.

Quiero desactivar la aplicación durante ~ 5 minutos para copiar los datos del servidor de la nube al servidor dedicado, por lo que no quiero que las solicitudes vayan al servidor anterior después de haber copiado los datos.

Quiero apuntar nuestro registro DNS al nuevo servidor, pero el TTL se configuró en 24 horas. Lo he cambiado a 300 segundos. ¿Debo esperar las 24 horas antes de actualizar la dirección IP a la que apunta el dominio / copiar los datos?

domain-name-system  rackspace  ttl 
— wobbily_col
fuente
99
Por cierto, incluso si espera el TTL, le recomiendo que edite la configuración en el servidor anterior para asegurarse de que no se aceptarán más actualizaciones allí. No todos los solucionadores de DNS siguen los estándares.
— Peter Green
55
Lo que hice al mover una aplicación web de un proveedor de hosting a otro fue usar un reenvío de puerto ssh para que los visitantes aún usaran la antigua IP dirigida al nuevo servidor.
— kasperd

Respuestas:

58

Cualquiera que tenga una copia en caché del registro de dominio no se molestará en actualizarlo durante 24 horas, por lo que sí, si su intención es tener una ventana de indisponibilidad de 5 minutos como máximo, debe esperar hasta que todas las memorias caché pendientes se hayan actualizado para no vivir más. de 5 minutos

— Jeff Meden
fuente
23
... por 24 horas since they last cached it. Esto podría ser de 1 a 86399 segundos.
— user9517 es compatible con GoFundMonica
66
@Iain Tienes que asumir lo peor, ya que cualquiera o todos ellos podrían haberlo almacenado en caché justo antes del cambio.
— Barmar
66
@Barmar No asumas nada. Muchos ISP simplemente ignoran TTL.
— user9517 es compatible con GoFundMonica
13
@Iain Solía ​​trabajar para Akamai, una CDN que hace un uso intensivo de TTL cortos (como 60 segundos) para equilibrar la carga. Recuerdo que hicimos un estudio y descubrimos que la mayoría de los ISP obedecían nuestros TTL.
— Barmar
1
Trabajo para una empresa de alojamiento web, nuestra experiencia es que los TTL bajos tienen más probabilidades de ser ignorados que los más altos.
— Henrik - deja de lastimar a Monica
39

Es (potencialmente) incluso peor que eso: debe esperar 24 horas después de que todos sus servidores autorizados se hayan actualizado. La forma normal de que ocurran las actualizaciones es que realice un cambio en la zona en el servidor primario, y luego cada una de las secundarias transfiera los datos de la nueva zona la próxima vez que se registren con el primario. La frecuencia de verificación se controla mediante el intervalo de actualización en el registro SOA de la zona. Por lo tanto, en el peor de los casos, tendría que esperar el intervalo de actualización de la zona + el TTL del registro.

Es posible que también tenga que esperar tanto tiempo para los cambios de registro reales. Un TTL de 5 minutos no servirá de mucho si las secundarias solo se actualizan cada 6 horas. Por lo tanto, es probable que también desee disminuir el intervalo de actualización en la zona durante el período en que desea poder realizar cambios rápidos.

Eso sí, esto puede no aplicarse a su configuración. Si tiene un sistema que actualiza todos los servidores autorizados juntos, esto no es un problema (y no estoy familiarizado con la configuración de DNS de Rackspace). Pero recomiendo consultar todos sus servidores autorizados individualmente ( dig server.example.com @secondaryserver.example.com) para asegurarse de que tengan el nuevo TTL antes de comenzar su cuenta regresiva de 24 horas.

— Gordon Davisson
fuente
1
Esta debería ser la respuesta aceptada.
— dotancohen
44
Parece que está ignorando el protocolo de notificación DNS, que le dice a los servidores esclavos que se actualicen poco después de que se actualice el maestro. La mayoría de los servidores DNS usan esta función.
— Barmar
@Barmar: Eso es cierto, pero al mismo tiempo el maestro podría tardar un poco en actualizarse dependiendo del proveedor. (Por ejemplo, algunos proveedores solo reconstruyen zonas de la base de datos cada 5 o 15 minutos, aunque los modernos lo hacen instantáneamente)
— Grawity
1
Mi comentario solo abordaba el problema de esperar el intervalo de actualización, que actualmente es obsoleto. Esperar a que el maestro se actualice es cierto, a menos que opere su propio maestro. Pero creo que es poco probable que tengan que lidiar con el momento exacto en que todo se actualiza con seguridad; 5-15 minutos extra no deberían hacer mucha diferencia. El punto de la pregunta original es si necesitan esperar un día entero.
— Barmar
1
@GordonDavisson: Si no confías, verifica. dig +nssearch example.comes una herramienta útil para comparar rápidamente SOA en todos los servidores; nsdiff muestra diferencias reales.
— Grawity
23

Sí, deberías esperar. Incluso entonces, por supuesto, no está garantizado que todos respeten el TTL.

— Sven
fuente
66
+1 porque no todos obedecen el TTL, he visto rezagados venir una semana después de hacer un cambio de DNS. Una forma en que lo manejé en el pasado fue configurar un nuevo nombre único como un alias en el nuevo sitio y usé una redirección desde el sitio anterior para redirigir a los usuarios del dominio anterior a los nuevos, como desde www.mycompany .com -> newsite.mycompany.com
— Johnny
Sí, pero muchas personas despreciarán legítimamente la idea de tener que usar un nuevo nombre. Los nombres son marcas. Además, esto solo funciona para HTTP y prácticamente para nada más.
— Sven
8
Otra opción es configurar el servidor antiguo como un proxy inverso para el nuevo servidor. Luego puede dejarlo así durante una semana más o menos después del interruptor y apagarlo cuando no haya tráfico entrando.
— bdsl
1
Las personas que tienen servidores DNS que se comportan bien y obedecen el TTL nunca verán el nuevo dominio. Y aunque "solo" funciona con HTTP (S), creo que encontrará que HTTP es un protocolo bastante común en Internet. La sugerencia de bdsl de configurar un proxy inverso es aún mejor, pero es más trabajo
— Johnny
@Johnny El problema con un nuevo dominio es que corres el riesgo de que la gente marque ese dominio. A menos que planee dejar dicho dominio nuevo accesible para siempre.
— Bob
5

Reunir varios comentarios y respuestas sobre el procedimiento completo sería algo así.

  1. Asegúrese de que puede actualizar sus servidores de autorratación de manera oportuna.
  2. Reduce el TTL.
  3. Verifique que todos los servidores autoritativos tengan el nuevo ttl.
  4. Espere el antiguo TTL para que los valores almacenados en caché con el antiguo TTL se eliminen (en su mayoría) de los cachés (no puede garantizar que desaparecerán de cada caché porque algunos cachés pueden ignorar los estándares).
  5. Coloque el sitio en el antiguo servidor en modo de solo lectura (o si no puede hacerlo, reemplácelo con una página "estamos inactivos por mantenimiento").
  6. Realice la copia final del antiguo servidor al nuevo servidor (lo que da como resultado un sitio de solo lectura en el nuevo servidor).
  7. Cambiar los registros DNS.
  8. Asegúrese de que todos los servidores automáticos tengan los nuevos registros DNS.
  9. Espere el nuevo ttl (puede omitir este paso si no le importa que algunos usuarios puedan contribuir al sitio y que otros usuarios no vean los resultados de esas contribuciones).
  10. Ponga el sitio en el nuevo servidor en modo de lectura / escritura.
  11. Ponga un aviso en el servidor anterior de que es una copia obsoleta de solo lectura y que el usuario probablemente ha roto el DNS.
  12. Espere un momento a que se eliminen los registros de las memorias caché DNS no compatibles.
  13. Retirar el antiguo servidor.
— Peter Green
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.