¿Puedes configurar una IP de respaldo para tu servidor en DNS?

¿Hay alguna manera de que el protocolo DNS pueda contener naturalmente una dirección de servidor de registros de respaldo A, como el servidor de nombres de respaldo o los registros del servidor de correo? Al buscar esto, solo vi resultados en servidores de nombres de respaldo (registros NS).

Si no hay una manera para que DNS admita registros de respaldo A, ¿cuál es la mejor manera de simular los resultados para que los usuarios sean dirigidos a un servidor en funcionamiento en caso de que el servidor primario no responda?

Sí ... más o menos.

Hay dos cosas que puede hacer aquí: si coloca varios registros A en su servidor DNS para un nombre dado, todos se servirán a los clientes y esos clientes elegirán uno del conjunto para conectarse, lo que significa que el tráfico se estar distribuido "de manera equitativa" entre todos los sitios simultáneamente. Esto no es realmente lo que parece estar describiendo, pero es una situación común (aunque no confío en él, por varias razones).

La otra opción es que solo coloque un registro A en su servidor DNS, y el servidor DNS (o algo auxiliar, como un script de monitoreo) vigila la dirección principal de su sitio, y si falla, entonces el servidor A de DNS el registro se cambia a su otro sitio. Esto significa que solo un sitio obtendrá tráfico a la vez.

La desventaja de esta segunda estrategia es el almacenamiento en caché de DNS. Cualquiera que haya obtenido la dirección del sitio anterior será SOL hasta que se eliminen las entradas de caché de DNS que contienen la dirección anterior. Esto significa que debe mantener bajos sus TTL (aumentando la carga en su infraestructura de DNS, aunque eso rara vez es un problema práctico), pero aún existe el problema de los cachés de DNS "no autorizados", que no respetan los TTL. Estos son un dolor masivo para cualquiera quien alguna vez tiene que cambiar las entradas de DNS, pero son un millón de veces peores para cualquiera que necesite cambiar las entradas de DNS "a menudo" (es de esperar que su sitio no se caiga varias veces al día, pero aún así ...) Básicamente, cualquiera detrás de uno de estos cachés de DNS que se comportan mal verá su sitio como "inactivo" durante un período de tiempo extremadamente extenso, y solo trate de explicarles que es su caché de DNS el que tiene la culpa ... Eugh.

En resumen, no lo haría para un sitio, porque hay mejores maneras de mitigar cualquier riesgo en el que esté pensando, pero deberá describir ese riesgo si desea sugerencias sobre cómo mitigarlo.

Todo el mundo parece pensar que estás hablando de servidores WWW, a pesar de que escribiste explícitamente

como un servidor de nombres o un servidor de correo de respaldo

Con SRVlos registros de recursos, se les indica a los clientes una lista de servidores, con prioridades y pesos, y se les exige que prueben los servidores en orden de prioridad, seleccionando entre servidores con iguales prioridades de acuerdo con el peso, eligiendo servidores de mayor peso que los de menor peso. unos. Entonces, con SRVlos registros de recursos, los administradores del servidor pueden decirle a los clientes cuáles son los servidores de reserva y cómo distribuir su carga en un conjunto de servidores de igual prioridad.

Ahora los servidores DNS de contenido están ubicados por un tipo especial de registro de NSrecursos propio, registros de recursos, que no tienen información de prioridad y peso. Del mismo modo, los servidores de retransmisión SMTP están ubicados por su propio tipo especial de registro de recursos MX, que tiene información de prioridad pero no información de ponderación. Por lo tanto, para los servidores DNS de contenido no existe ninguna disposición para publicar información de distribución alternativa y de carga; y si uno está utilizando MXregistros de recursos, entonces, para los servidores de retransmisión SMTP, no existe ninguna disposición para publicar información de distribución de carga.

Sin embargo, SRVahora existen MTS con capacidad. (La primera fue exim, que ha sido SRVcapaz desde 2005). Y para otros protocolos de servicio, sin gravámenes con el equipaje MXy NSlos registros de recursos, la SRVadopción es mucho más exhaustiva y generalizada. Si tiene un dominio de Microsoft Windows, por ejemplo, toda una serie de servicios se encuentran a través de SRVbúsquedas en el DNS . Ese ha sido el caso durante más de una década, en este momento.

El problema es que todos piensan en HTTP, cuando HTTP es con diferencia, hoy en día en 2011, la excepción y no la regla aquí.

si está sirviendo contenido dinámico y no es práctico simplemente tener dos servidores que brinden contenido simultáneamente, entonces su otra opción es tener múltiples registros en su DNS de todos modos y configurar el servidor de respaldo para que el puerto ICMP no sea accesible a los clientes que intentan conectarse a él ; Si en algún momento el servidor principal se cae, simplemente elimine el bloqueo del puerto 80 en la copia de seguridad y el tráfico comenzará a llegar.

La única otra forma (económica) que podrá hacerlo es configurar una máquina separada (o dos) para realizar NAT en las solicitudes, por lo tanto, si un servidor web muere, simplemente puede eliminar la regla NAT para ello.

No hay registros A de respaldo, pero puede haber varios registros A que se distribuyen en orden aleatorio.

La mayoría de los navegadores son capaces de probar otro servidor si uno falla. (Ver: Resiliencia web con DNS de Round Robin )

Puede tener una dirección IP de clúster respaldada por varios servidores con VRRP o CARP . El servidor de respaldo se hace cargo de la dirección cuando falla el servidor primario.

Sí, pero tienes que hacerlo tú mismo ;-)

¿Podría dar más información sobre por qué desea un "registro A de respaldo" y cómo y en qué circunstancias le gustaría ir al respaldo.

Además, sería útil conocer la relación desde una perspectiva de red entre los hosts primario y de respaldo.

Esta es una pregunta bastante antigua, pero no se han mencionado dos tecnologías bastante significativas en las respuestas: DNS dinámico y CDN.

El DNS dinámico está configurado para que los registros DNS se puedan modificar casi en tiempo real, de modo que un cliente de monitoreo pueda desencadenar cambios en los registros DNS A públicos según lo dicte la disponibilidad del servicio. (Por supuesto, su servicio de alojamiento de DNS debe ser compatible con DNS dinámico).

Los CDN también se pueden usar para entregar DNS, como por ejemplo Cloudflare (que se lanzó en 2010, creo).