Prácticas recomendadas de Amazon Route 53 DNS

Siga estas prácticas recomendadas para obtener los mejores resultados al utilizar el servicio DNS de Amazon Route 53.

Utilice las funciones del plano de datos para la conmutación por error de DNS y la recuperación de aplicaciones

Los planos de datos de Route 53, incluidas las comprobaciones de estado y el control de enrutamiento de Amazon Route 53 Application Recovery Controller, se distribuyen a nivel mundial y están diseñados para ofrecer una disponibilidad y funcionalidad del 100 %, incluso durante eventos graves. Se integran entre sí y no dependen de la funcionalidad del plano de control. Si bien los planos de control de estos servicios, incluidas sus consolas, suelen ser muy fiables, están diseñados de forma más centralizada y priorizan la durabilidad y la consistencia en lugar de la alta disponibilidad. Para escenarios como la conmutación por error durante la recuperación de desastres, se recomienda que utilice funciones como las comprobaciones de estado de Route 53 y Route 53 ARC que dependen de la funcionalidad del plano de datos para actualizar el DNS. Para obtener más información, consulte Conceptos de plano de datos y control y Blog: Creating Disaster Recovery Mechanisms Using Amazon Route 53 (Creación de mecanismos de recuperación de desastres mediante Amazon Route 53).

Elección de valores TTL para registros DNS

El TTL de DNS es el valor numérico (en segundos) que utilizan los solucionadores de DNS para decidir durante cuánto tiempo se puede almacenar en caché un registro sin realizar otra consulta a Route 53. Todos los registros de DNS deben tener un TTL especificado para ellos. El intervalo recomendado para los valores de TTL es de 60 a 172,800 segundos.

La elección de un TTL implica un compromiso entre latencia y fiabilidad y la capacidad de respuesta a los cambios. Con TTL más cortos en un registro, los solucionadores de DNS detectan las actualizaciones del registro más rápido, ya que deben realizar consultas con más frecuencia. Esto aumenta el volumen de consultas (y el costo). A medida que se alarga el TTL, los solucionadores de DNS responden a las consultas de la caché con más frecuencia, lo que suele ser más rápido, económico y, en algunas situaciones, más fiable porque evita consultas en Internet. No hay un valor ideal, pero vale la pena considerar qué es más importante para usted, si la capacidad de respuesta o la fiabilidad.

Entre los aspectos a tener en cuenta al configurar los valores de TTL se cuentan:

• Establezca los TTL de registros de DNS según el tiempo que pueda esperar a que surta efecto un cambio. Esto es especialmente cierto en las delegaciones (conjuntos de registros NS) u otros registros que rara vez cambian, por ejemplo, registros MX. Para estos registros, se recomiendan TTL más largos. Una opción común es un valor de entre una hora (3600 s) o un día (86,400 s).

• Para los registros que deben modificarse como parte de un mecanismo de conmutación por error rápido (especialmente los registros que requieren comprobación de estado), lo más adecuado es utilizar TTL más bajos. Configurar un TTL de 60 o 120 segundos es una opción común para esta situación.

• Cuando desee realizar cambios a las entradas de DNS críticas, le recomendamos que abrevie temporalmente los TTL. A continuación, puede realizar los cambios, observar y revertir rápidamente de ser necesario. Una vez finalizados los cambios y funcionando como se esperaba, puede aumentar el TTL.

Para obtener más información, consulte TTL (segundos).

Registros CNAME

Los registros CNAME en DNS son una forma de indicar un nombre de dominio a otro. Si un solucionador de DNS resuelve el dominio-1.ejemplo.com y encuentra un CNAME que indica al domain-2.example.com, el solucionador de DNS debe proceder a solucionar el domain-2.example.com antes de poder responder. Estos registros son útiles en muchas situaciones, por ejemplo, para garantizar la consistencia cuando un sitio web tiene más de un nombre de dominio.

Sin embargo, los solucionadores de DNS deben realizar más consultas para responder a los CNAME, lo que aumenta la latencia y los costos. Siempre que sea posible, una alternativa más rápida y económica es utilizar un registro de alias de Route 53. Los registros de alias permiten a Route 53 responder con una respuesta directa para AWS los recursos (por ejemplo, un balanceador de carga) y para otros dominios dentro de la misma zona hospedada.

Para obtener más información, consulte Enrutamiento del tráfico de Internet a los recursos de AWS.

Enrutamiento de DNS avanzado

• Al utilizar la geolocalización, la geoproximidad o el enrutamiento basado en la latencia, establezca siempre un valor predeterminado, a menos que desee que algunos clientes reciban un mensaje de tipo sin respuesta.

• Para minimizar la latencia de las aplicaciones, utilice el enrutamiento basado en la latencia. Este tipo de datos de enrutamiento puede cambiar con frecuencia.

• Para proporcionar estabilidad y previsibilidad en el enrutamiento, utilice el enrutamiento por geolocalización o por geoproximidad.

Para obtener más información, consulte Enrutado de geolocalización, Enrutamiento de geoproximidad y Enrutado basado en latencia.

Propagación de cambios de DNS

Al crear o actualizar un registro o una zona alojada mediante la consola o la API de Route 53, el cambio tarda un tiempo en reflejarse en Internet. Esto se llama propagación de cambios. Si bien la propagación generalmente es inferior a un minuto a nivel mundial, en ocasiones hay retrasos, por ejemplo, debido a problemas de sincronización con una ubicación o, en raras ocasiones, a problemas dentro del plano de control central. Si está creando flujos de trabajo de aprovisionamiento automatizados y es importante esperar a que se complete la propagación de los cambios antes de continuar con el siguiente paso del flujo de trabajo, utilice la GetChangeAPI para comprobar que los cambios de DNS se han aplicado (Status =INSYNC).

Delegación de DNS

Al delegar varios niveles de subdominios en DNS, es importante delegar siempre desde la zona principal. Por ejemplo, si va a delegar www.dept.example.com, debería hacerlo desde la zona dept.example.com, y no desde la zona example.com. Las delegaciones de una zona de abuelos a una de niños pueden no funcionar en absoluto o hacerlo de forma inconsistente. Para obtener más información, consulte Direccionamiento del tráfico de subdominios.

Tamaño de la respuesta de DNS

Evite crear respuestas individuales de gran tamaño. Por encima de 512 bytes, muchos solucionadores de DNS deben volver a intentarlo a través de TCP en lugar de UDP, lo que puede reducir la fiabilidad y generar respuestas más lentas. Recomendamos utilizar enrutamiento de respuestas de varios valores que elijan 8 direcciones IP aleatorias y en buen estado para mantener las respuestas dentro del límite de 512 bytes.

Para obtener más información, consulte Direccionamiento de respuesta con varios valores y Servidor de prueba de tamaño de respuesta DNS.