El DNS y su funcionamiento tal vez estén acompañados de más malentendidos, leyendas, supersticiones y mitologías como cualquier aspecto de TI.
Incluso aquellos de nosotros que sabemos que esencialmente estamos mintiendo (o al menos simplificando drásticamente) cuando hablamos de "propagación" de cambios, todavía tendemos a usar el término para describir algo que es, simultáneamente, extremadamente simple y directo ... pero difícil de explicar ... y no tiene nada que ver con la propagación per se , pero tiene que ver con el almacenamiento en caché y el almacenamiento en caché negativo, los cuales son un componente esencial de cómo funciona el sistema (y, posiblemente, cómo evita el colapso total bajo su propio peso) - esencialmente el revés, opuesto a la "propagación" real, jalar - no empujar.
A pesar de todas las preocupaciones y reticencias sobre los TTL cortos, tienden a funcionar con mayor frecuencia, hasta el punto de que puede ser de su interés simplemente probarlos. En $ {day_job}, cuando nuestros sitios migran de una plataforma "antigua" a una plataforma "nueva", a menudo significa que están migrando de tal manera que no se comparte nada en la infraestructura. Mi primer paso en una migración de este tipo es reducir el TTL a 60 segundos con suficiente anticipación al corte para que el TTL antiguo tenga múltiples múltiplos para agotarse, lo que me da una garantía razonable de que estos RR transitorios con TTL cortos "se propagarán". ". Cuando estoy listo para el corte, vuelvo a configurar el viejo equilibrador¹ para reducir el tráfico al nuevo sistema, a través de Internet, de modo que el equilibrador ya no esté equilibrando múltiples sistemas internos, sino que es "
Luego paso el DNS y miro el nuevo equilibrador y el viejo.
Siempre estoy gratamente sorprendido de lo rápido que ocurre la transición. Los holdouts parecen ser casi siempre arañas de búsqueda y sitios de "control de salud" de terceros que se aferran inexplicablemente a los registros antiguos.
Pero hay un escenario que se descompone de manera predecible: cuando las ventanas del navegador de un usuario permanecen abiertas, tienden a engancharse a la dirección ya descubierta, y a menudo persiste hasta que se cierran todas las ventanas del navegador.
Pero en la descripción anterior, encuentra la solución al problema: un "equilibrador de carga", específicamente y más precisamente, un proxy inverso, puede ser el sistema al que apunta su registro DNS expuesto.
Luego, el proxy inverso reenvía la solicitud a la dirección IP de destino correcta, que resuelve usando un segundo nombre de host "ficticio" con un TTL corto, que apunta al servidor de fondo real.³ Porque el proxy siempre respeta el DNS TTL en ese entrada ficticia de DNS, tiene la seguridad de un cambio rápido y completo.
El inconveniente es que puede enrutar el tráfico a través de una infraestructura adicional innecesaria, o pagar más por el transporte a través de múltiples límites de red, de forma redundante.
Hay servicios que proporcionan este tipo de capacidad a escala global, y el que estoy más familiarizado es CloudFront. (Lo más probable es que Cloudflare sirva exactamente para el mismo propósito, ya que la pequeña duda de las pruebas que he hecho indica que también se comporta correctamente, y estoy seguro de que hay otras).
Aunque se comercializa principalmente como una CDN, CloudFront es, en esencia, una red global de servidores proxy inversos con la capacidad de almacenar en caché las respuestas opcionalmente . Si los www.example.compuntos a CloudFront y CloudFront están configurados para reenviar estas solicitudes backend.example.com, y el registro DNS backend.example.comutiliza un TTL corto, CloudFront hará lo correcto, ya que respeta ese TTL corto. Cuando el registro de fondo cambia, el tráfico se migrará cuando el TTL se agote.
El TTL en el registro frontal apunta a CloudFront, y si los navegadores y los resolutores de almacenamiento en caché lo están cumpliendo no es importante, porque los cambios en el destino de fondo no requieren cambios en el www.example.comregistro ... así que la noción de que "Internet" tiene, con respecto al objetivo correcto, www.example.comes consistente, independientemente de dónde esté el sistema de fondo.
Esto, para mí, resuelve el problema por completo al aliviar al navegador de cualquier necesidad de "seguir" los cambios en la IP del servidor de origen.
tl; dr: enruta las solicitudes a un sistema que sirve como proxy para el servidor web real, de modo que solo la configuración del proxy necesita acomodar el cambio en la IP del servidor de origen, no el DNS orientado al navegador.
Tenga en cuenta que CloudFront también minimiza la latencia por parte de la magia DNS que impone en la parte frontal, lo que resulta en la www.example.comresolución a la ubicación más óptima de borde de CloudFront en función de la ubicación del navegador que está consultando www.example.com, por lo que hay una mínima posibilidad de que el tráfico tome una ruta innecesariamente tortuosa desde el navegador hasta el borde hasta el origen ... pero esta parte es transparente y automática y está fuera del alcance de la pregunta.
Y, por supuesto, el almacenamiento en caché de contenido también puede ser valioso al reducir la carga en el servidor de origen o el transporte: he configurado sitios web en CloudFront donde el servidor de origen estaba en un circuito ADSL, y ADSL está inherentemente restringido para el ancho de banda ascendente. El servidor de origen donde CloudFront se conecta para recuperar el contenido no necesita ser un servidor dentro del ecosistema de AWS.
¹ Hablo de equilibrador como una entidad única cuando en realidad tiene múltiples nodos. Cuando el equilibrador es un ELB, una máquina detrás del equilibrador actúa como un servidor de aplicaciones ficticio y realiza la fijación real al equilibrador de la nueva plataforma, ya que ELB no puede hacer esto por sí solo.
² El único conocimiento del nuevo equilibrador sobre el antiguo es que necesita confiar en el X-Forward-For del antiguo equilibrador y que no debe limitar la velocidad basada en IP en las direcciones de origen del antiguo equilibrador.
³ Cuando el proxy es uno o más servidores que usted controla, tiene la opción de omitir el uso de DNS en la parte posterior y simplemente usar las direcciones IP en la configuración del proxy, pero el escenario alojado / distribuido discutido posteriormente necesita esa segunda capa de DNS .