Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Prácticas recomendadas de Amazon Route 53
Esta sección proporciona las prácticas recomendadas para varios componentes de Amazon Route 53, entre ellos:
1. **Prácticas recomendadas de DNS:**
+ Comprenda el equilibrio entre los valores del periodo de vida (TTL) y la capacidad de respuesta frente a la fiabilidad.
+ Utilice registros de alias en lugar de registros CNAME siempre que sea posible para mejorar el rendimiento y ahorrar costos.
+ Configure políticas de enrutamiento predeterminadas para garantizar que todos los clientes reciban una respuesta.
+ Aproveche el enrutamiento basado en la latencia para minimizar la latencia de las aplicaciones y el geolocation/geoproximity enrutamiento para lograr estabilidad y previsibilidad.
+ Verifique la propagación de los cambios mediante la API `GetChange` para flujos de trabajo automatizados.
+ Delegue subdominios de la zona principal para un enrutamiento consistente.
+ Evite las respuestas únicas de gran tamaño mediante el enrutamiento de respuesta con varios valores.
1. **Prácticas recomendadas de Resolver:**
+ Prevenga los bucles de enrutamiento al evitar asociar la misma VPC tanto a una regla de Resolver como al punto de conexión de entrada.
+ Implemente reglas de grupos de seguridad para reducir la sobrecarga de seguimiento de las conexiones y maximizar el rendimiento de las consultas.
+ Configure los puntos de conexión de entrada con direcciones IP en varias zonas de disponibilidad para la redundancia.
+ Esté al tanto de los posibles ataques de desplazamiento por zonas de DNS y póngase en contacto con AWS Support si sus puntos finales sufren una limitación.
1. **Prácticas recomendadas de comprobación de estado:**
+ Siga las recomendaciones para optimizar las comprobaciones de estado de Amazon Route 53 y garantizar una supervisión fiable de los recursos.
Si sigue estas prácticas recomendadas, puede optimizar el rendimiento, la fiabilidad y la seguridad de su infraestructura de DNS, lo que garantiza un enrutamiento eficiente y efectivo del tráfico a las aplicaciones y los servicios
**Topics**
+ [Prácticas recomendadas de Amazon Route 53 DNS](best-practices-dns.md)
+ [Mejores prácticas para VPC Resolver](best-practices-resolver.md)
+ [Prácticas recomendadas de las comprobaciones de estado de Amazon Route 53](best-practices-healthchecks.md)
# 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 del Control de recuperación de aplicaciones de Amazon Route 53 (ARC), 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 ante desastres, se recomienda que utilice características como las comprobaciones de estado de Route 53 y el control de enrutamiento de 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](route-53-concepts.md#route-53-concepts-control-and-data-plane) y [Blog: Creating Disaster Recovery Mechanisms Using Amazon Route 53 (Creación de mecanismos de recuperación de desastres mediante Amazon Route 53).](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-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. Cuando un registro es más corto TTLs , los solucionadores de DNS detectan las actualizaciones del registro con mayor rapidez, 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:
+ Establece un registro de DNS TTLs durante el tiempo que puedas permitirte esperar a que se produzca 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, TTLs se recomienda que sean más largos. Una opción común es un valor de entre una hora (3600 s) o un día (86,400 s).
+ En el caso de los registros que deben modificarse como parte de un mecanismo de conmutación por error rápida (especialmente los registros cuyo estado ha sido comprobado), lo más adecuado es reducir el TTLs valor. Configurar un TTL de 60 o 120 segundos es una opción común para esta situación.
+ Si desea realizar cambios en las entradas de DNS críticas, le recomendamos que las TTLs acorte temporalmente. 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)](resource-record-sets-values-shared.md#rrsets-values-common-ttl).
**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 CNAMEs, lo que aumenta la latencia y los costes. 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 [Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
**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](routing-policy-geo.md), [Enrutamiento por geoproximidad](routing-policy-geoproximity.md) y [Enrutado basado en latencia](routing-policy-latency.md).
**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 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API para comprobar que los cambios de DNS se hayan 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](dns-routing-traffic-for-subdomains.md).
**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](routing-policy-multivalue.md) y [Servidor de prueba de tamaño de respuesta DNS](https://www.dns-oarc.net/oarc/services/replysizetest/).
# Mejores prácticas para VPC Resolver
En esta sección se proporcionan las prácticas recomendadas para optimizar la resolución de VPC de Amazon Route 53 y se tratan los siguientes temas:
1. **Cómo evitar las configuraciones en bucle con los puntos de conexión de Resolver**
+ Evite los bucles de enrutamiento al garantizar que la misma VPC no esté asociada tanto a una regla de Resolver como a su punto de conexión de entrada.
+ AWS RAM Utilícelo para compartir VPCs entre cuentas y, al mismo tiempo, mantener las configuraciones de enrutamiento adecuadas.
Para obtener más información, consulte [Evitar las configuraciones en bucle con los puntos de enlace de Resolver](best-practices-resolver-endpoints.md)
1. **Escalado de los puntos de conexión de Resolver:**
+ Implemente reglas de grupos de seguridad que permitan el tráfico en función del estado de la conexión para reducir la sobrecarga de seguimiento de las conexiones.
+ Siga las reglas de los grupos de seguridad recomendadas para los puntos de conexión de Resolver, tanto de entrada como de salida, a fin de maximizar el rendimiento de las consultas.
+ Supervise las combinaciones únicas de direcciones IP y puertos que generan tráfico de DNS para evitar limitaciones de capacidad.
Para obtener más información, consulte [Escalado de los puntos de enlace de Resolver](best-practices-resolver-endpoint-scaling.md)
1. **Alta disponibilidad para puntos de conexión de Resolver:**
+ Cree puntos de conexión de entrada con las direcciones IP al menos en dos zonas de disponibilidad para la redundancia.
+ Aprovisionamiento de interfaces de red adicionales para garantizar la disponibilidad durante el mantenimiento o los picos de tráfico
Para obtener más información, consulte [Alta disponibilidad para puntos de enlace de Resolver](best-practices-resolver-endpoint-high-availability.md)
1. **Prevención de los ataques de desplazamiento por zonas DNS:**
+ Esté atento a los posibles ataques de desplazamiento de zonas DNS, en los que los atacantes intentan recuperar todo el contenido de las zonas DNS firmadas por DNSSEC.
+ Si sus puntos finales sufren una ralentización debido a la sospecha de que están caminando por zonas, póngase en contacto con AWS Support para obtener ayuda.
Para obtener más información, consulte [Consulta exhaustiva de nombres de zona DNS](best-practices-resolver-zone-walking.md)
Si sigue estas prácticas recomendadas, puede optimizar el rendimiento, la escalabilidad y la seguridad de sus implementaciones de VPC Resolver, lo que garantiza una resolución de DNS fiable y eficiente para sus aplicaciones y recursos.
# Evitar las configuraciones en bucle con los puntos de enlace de Resolver
No asocie la misma VPC a una regla de Resolver y a su punto de conexión de entrada (tanto si se trata de un destino directo del punto de conexión como si se realiza a través de un servidor DNS en las instalaciones). Cuando el punto de conexión de salida de una regla de Resolver apunta a un punto de conexión de entrada que comparte una VPC con la regla, puede provocar un bucle en el que la consulta se pasa continuamente entre los puntos de conexión de entrada y salida.
La regla de reenvío puede seguir asociándose a otras VPCs que se compartan con otras cuentas mediante (). AWS Resource Access Manager AWS RAM Las zonas alojadas privadas asociadas al centro, o una VPC central, seguirán resolviendo desde las consultas hasta los puntos de enlace de entrada, porque las reglas de resolución de reenvío no cambian esta resolución.
# Escalado de los puntos de enlace de Resolver
Los grupos de seguridad de los puntos de enlace de Resolver utilizan el seguimiento de las conexiones para recopilar información sobre el tráfico hacia y desde los puntos de enlace. Cada interfaz de punto final tiene un número máximo de conexiones de las que se puede realizar un seguimiento, pero un gran volumen de consultas de DNS puede superar las conexiones y causar limitación controlada y pérdida de consultas. El seguimiento de conexiones AWS es el comportamiento predeterminado para supervisar el estado del tráfico que fluye a través de los grupos de seguridad (SGs). Si utiliza el seguimiento de SGs conexiones para reducir el rendimiento del tráfico, puede implementar conexiones sin seguimiento para reducir la sobrecarga y mejorar el rendimiento. Para obtener más información, consulte [Conexiones sin seguimiento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections).
Si el seguimiento de conexiones se aplica mediante reglas restrictivas del grupo de seguridad o las consultas se enrutan a través del Equilibrador de carga de red (consulte [Conexiones con seguimiento automático](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking)), el número máximo total de consultas por segundo por dirección IP para un punto de conexión puede ser tan bajo como 1500.
**Recomendaciones de reglas del grupo de seguridad de entrada y salida para el punto de conexión de entrada de Resolver**
****
|
|
| **Reglas de entrada** |
| --- |
| Tipo de protocolo | Número de puerto | IP de origen |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
| **Reglas de salida** |
| --- |
| Tipo de protocolo | Número de puerto | IP de destino |
| TCP | Todos | 0.0.0.0/0 |
| UDP | Todos | 0.0.0.0/0 |
**Recomendaciones de reglas de grupos de seguridad de entrada y salida para el punto de conexión de salida de Resolver**
****
|
|
| **Reglas de entrada** |
| --- |
| Tipo de protocolo | Número de puerto | IP de origen |
| TCP | Todos | 0.0.0.0/0 |
| UDP | Todos | 0.0.0.0/0 |
| **Reglas de salida** |
| --- |
| Tipo de protocolo | Número de puerto | IP de destino |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
**nota**
**Requisitos de puerto del grupo de seguridad:**
Los **puntos de conexión de entrada** requieren reglas de entrada que permitan que el TCP y el UDP del puerto 53 reciban consultas de DNS de su red. Las reglas de salida pueden permitir todos los puertos, ya que es posible que el punto de conexión deba responder a las consultas de diferentes puertos de origen.
Los **puntos de conexión de salida** requieren reglas de salida que permitan que el TCP y UDP accedan a los puertos que utiliza para las consultas de DNS en su red. En el ejemplo anterior se muestra el puerto 53 porque es el puerto DNS más común, pero es posible que su red utilice puertos diferentes. Las reglas de entrada pueden permitir que todos los puertos admitan las respuestas de sus servidores DNS.
**Puntos de enlace de entrada de Resolver**
Para los clientes que utilizan un punto de conexión de entrada de Resolver, la capacidad de la interfaz de red elástica se verá afectada si tiene más de 40 000 combinaciones únicas de direcciones IP y puertos que generan el tráfico DNS.
# Alta disponibilidad para puntos de enlace de Resolver
Al crear los puntos finales de entrada de VPC Resolver, Route 53 requiere que cree al menos dos direcciones IP a las que los resolutores de DNS de su red reenviarán las consultas. También debe especificar las direcciones IP en dos zonas de disponibilidad como mínimo para la redundancia.
Si necesita más de un punto de conexión para la interfaz de red elástica para garantizar la disponibilidad en todo momento, le recomendamos que cree al menos una interfaz de red más de la que necesita para asegurarse de disponer de capacidad adicional para gestionar posibles sobretensiones de tráfico. La interfaz de red adicional también garantiza la disponibilidad durante las operaciones de servicio, como mantenimiento o actualizaciones.
Para obtener más información, consulte este artículo detallado del blog: [Cómo lograr una alta disponibilidad de DNS con los puntos finales](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/) de Resolver y. [Valores que se especifican al crear o editar puntos de conexión de entrada](resolver-forwarding-inbound-queries-values.md)
# Consulta exhaustiva de nombres de zona DNS
Los ataques de consulta exhaustiva de nombres de zona DNS intentan obtener todo el contenido de las zonas DNS firmadas por DNSSEC. Si el equipo de resolución de VPC detecta un patrón de tráfico que coincide con los que se generan cuando se recorren zonas de DNS en su punto final, el equipo de servicio reducirá el tráfico en su punto final. Como consecuencia, puede observar un alto porcentaje de las consulta de DNS que agotan su tiempo de espera.
Si observa una reducción de la capacidad en sus terminales y cree que se ha reducido el límite de carga por error, vaya a home\$1/ para https://console.aws.amazon.com/support/ crear un caso de soporte.
# Prácticas recomendadas de las comprobaciones de estado de Amazon Route 53
Una configuración eficaz de la comprobación de estado es esencial para mantener una infraestructura resistente y de alta disponibilidad. Estas son algunas prácticas recomendadas para tener en cuenta al configurar y administrar las comprobaciones de estado de Amazon Route 53:
1. **Uso de direcciones IP elásticas para los puntos de conexión de comprobación de estado:**
+ Utilice direcciones IP elásticas para los puntos de conexión de comprobación de estado a fin de garantizar una supervisión uniforme.
+ Si ya no utiliza una instancia de Amazon EC2, recuerde eliminar cualquier comprobación de estado asociada para evitar posibles riesgos de seguridad o comprometer los datos.
Para obtener más información, consulte [Valores que especifica al crear o actualizar comprobaciones de estado](health-checks-creating-values.md).
1. **Configuración de los intervalos de comprobación de estado adecuados:**
+ Establezca intervalos de comprobación de estado en función de los requisitos de la aplicación y de la importancia de los recursos supervisados.
+ Los intervalos más cortos permiten detectar las fallas con mayor rapidez, pero pueden aumentar los costos de Route 53 y aumentar la carga de recursos.
+ Los intervalos más largos reducen los costos y la carga de recursos, pero pueden retrasar la detección de fallas.
Para obtener más información, consulte [Configuración avanzada (solo “Monitor an endpoint” (Monitorización de un punto de conexión))](health-checks-creating-values.md#health-checks-creating-values-advanced).
1. **Implementación de notificaciones de alarma:**
+ Configura Amazon CloudWatchalarms para recibir notificaciones cuando los controles de estado fallen o se recuperen.
+ Establezca los umbrales de alarma adecuados en función de los requisitos de la aplicación y del comportamiento esperado de los recursos.
+ Integre las notificaciones en los procesos de supervisión y de respuesta a incidentes.
Para obtener más información, consulte [Supervisar los controles de estado mediante CloudWatch](monitoring-health-checks.md).
1. **Utilización de las regiones de comprobación de estado de forma estratégica:**
+ Elija las regiones de comprobación de estado en función de la distribución geográfica de los usuarios y recursos.
+ Considere la posibilidad de utilizar varias regiones de comprobación de estado para los recursos esenciales a efectos de mejorar la fiabilidad y reducir el impacto de las interrupciones regionales.
1. **Supervisión de las métricas y los registros de comprobación de estado:**
+ Revisa periódicamente los registros y las CloudWatch métricas de los chequeos de estado de Route 53 para identificar posibles problemas o cuellos de botella en el rendimiento
+ Analice los motivos de los errores en la comprobación de estado y tome las medidas adecuadas para resolver los problemas subyacentes.
1. **Implementación de estrategias de conmutación por error y conmutación por recuperación:**
+ Aproveche las políticas de enrutamiento de conmutación por error de Route 53 para enrutar de manera automática el tráfico a recursos en buen estado en caso de que se produzcan fallas.
+ Planifique y pruebe los procesos de conmutación por error y conmutación por recuperación para garantizar una transición fluida durante las interrupciones y la recuperación.
Para obtener más información, consulte [Configuración de la recuperación ante errores a nivel de DNS](dns-failover-configuring.md).
1. **Revisión y actualización periódica de las comprobaciones de estado:**
+ Actualice los puntos de conexión, los intervalos y los umbrales de alarma de las comprobaciones de estado según sea necesario para mantener una supervisión y un rendimiento óptimos.
Si sigue estas prácticas recomendadas, puede aprovechar eficazmente las comprobaciones de estado de Amazon Route 53 para supervisar el estado y la disponibilidad de nuestros recursos, lo que garantiza una infraestructura fiable y de alto rendimiento para las aplicaciones y los servicios.