¿Un registro DNS que cambiará con frecuencia? [cerrado]

¿Cómo hago un registro de dominio que puede cambiar con frecuencia?

Digamos example.orgpuntos a 203.0.113.0. Dos minutos después tiene que señalar 198.51.100.0.

Habrá sitios web normales detrás del dominio ("normal" solo en el sentido de que se accede mediante navegadores web comunes) pero con una vida útil muy corta. El dominio apuntará a una dirección durante 3-4 horas como máximo antes de que se cambie o se apague. No es necesario proteger el servidor DNS de consultas frecuentes.

Mi enfoque sería establecer TTL en 60 segundos y simplemente cambiar el registro cuando se debe hacer el cambio. En el peor de los casos, el usuario esperaría un máximo de 60 segundos antes de que se pueda acceder a un nuevo servidor.

De alguna manera no confío en esto ... Algunos ISP o navegadores podrían ignorar o anular el TTL, ¿no? Si es una preocupación válida, ¿cuál sería un TTL razonable de esperar?

¡Gracias!

Esto se llama Fast Flux registros DNS . Y generalmente es cómo los autores de malware ocultan sus servidores de infraestructura.

Si bien esto funcionará para su plan, no es el mejor plan. Es probable que necesite tener un servidor adicional o más, en línea, y no hacer nada casi todo el tiempo. Solo cuando tenga un problema con el servidor principal, cambiaría al siguiente.

Incluso si tiene un TTL de 1 minuto, lo más probable es que un registro sea válido por más de eso:

1. Cachés del navegador

   Los navegadores generalmente almacenan en caché los registros DNS durante un período de tiempo variable. Firefox usa 60 segundos , Chrome también usa 60 segundos , IE 3.xy anterior en caché durante 24 horas , IE 4.xy superior en caché durante 30 minutos.

2. Caché del sistema operativo

   Windows no suele honrar el TTL . Un TTL para DND no es como el TTL para un paquete IPv4. Es más una indicación de frescura que una actualización obligatoria. Linux puede tener nscd configurado para establecer la cantidad de tiempo que el usuario desea, sin tener en cuenta DNS TTL. Puede almacenar en caché las entradas durante una semana, por ejemplo.

3. Caché de ISP

   Los ISP pueden (y algunos lo harán) usar el almacenamiento en caché agresivo para disminuir el tráfico. No solo pueden cambiar TTL, sino también almacenar en caché los registros y devolverlos a los clientes sin siquiera preguntar a los servidores DNS ascendentes. Esto es más frecuente en los ISP móviles, ya que cambian el TTL para que los clientes móviles no se quejen por la latencia del tráfico.

Un equilibrador de carga está hecho para hacer exactamente lo que quieres. Con un equilibrador de carga en su lugar, puede tener 2 o 4 o 10 servidores en línea al mismo tiempo, dividiendo la carga. Si uno de ellos se desconecta, el servicio no se verá afectado. El cambio de registros DNS tendrá un tiempo de inactividad entre el momento en que se apaga el servidor y se cambia el DNS. Tomará más de un minuto, porque debe detectar el tiempo de inactividad, cambiar los registros y esperar a que se propaguen.

Entonces use un equilibrador de carga. Está hecho para hacer lo que quieras, y sabes exactamente qué esperar. Una configuración de DNS de flujo rápido tendrá resultados mixtos e inconsistentes.

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 .

Cuando cambio los registros DNS, muchas veces la antigua dirección IP se usará durante meses. Dicho esto, un TTL de solo unos segundos es lo que Amazon usa para crear un servicio alternativo, por ejemplo.

En lugar de cambiar el DNS, puede colocar un servidor proxy / equilibrador de carga frente a él.

Podrías considerar el uso de DNS dinámico. Esto está diseñado precisamente para el escenario que @glglgl mencionó en un comentario anterior. Creo que usan un TTL bajo que, como se señaló anteriormente, puede no ser 100% efectivo ya que los clientes pueden ignorarlo. Pero funciona "bastante bien".

Incluso si no está cambiando su IP con frecuencia, es importante mantener su TTL razonable. Hace muchos años, la compañía en la que solía trabajar para ISP cambiados, lo que causó que nuestras IP cambiaran. Desafortunadamente, habíamos establecido nuestro TTL en algo ridículo como un mes, por lo que los viejos registros DNS se mantuvieron durante mucho tiempo.