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.
# Configuración de Amazon Route 53 como servicio DNS
Puede utilizar Amazon Route 53 como el servicio DNS de su dominio, como example.com. Cuando Route 53 es su servicio DNS, dirige el tráfico de Internet a su sitio web convirtiendo los nombres de dominio legibles, como www.example.com, en direcciones IP numéricas, como 192.0.2.1, que los sistemas utilizan para conectarse entre sí. Cuando un usuario escribe su nombre de dominio en un navegador o le envía un mensaje de email, se reenvía una consulta de DNS a Route 53, que responde con el valor correspondiente. Por ejemplo, Route 53 podría responder con la dirección IP del servidor web correspondiente a example.com.
**Comparación del alojamiento de DNS con el registro de dominios**
Este capítulo trata sobre el uso de Route 53 *únicamente para el alojamiento de DNS*. Esto significa que el registro de su dominio permanece con su registrador actual y usted seguirá pagándole por las renovaciones de dominio. Route 53 solo administrará su configuración de DNS y gestionará las consultas de DNS correspondientes a su dominio.
Si quiere transferir también el registro de su dominio a Route 53 (lo que convertiría a Route 53 en su registrador y en su servicio de DNS), consulte [Lista de verificación previa a la transferencia para transferencias de dominios](domain-transfer-checklist.md) y[Transferencia del registro de un dominio a Amazon Route 53](domain-transfer-to-route-53.md).
En este capítulo, explicamos cómo configurar Route 53 para dirigir su tráfico de Internet a los lugares correctos. También se explica cómo migrar el servicio DNS a Route 53 si utiliza otro servicio DNS y cómo utilizar Route 53 como el servicio DNS para un nuevo dominio.
**Topics**
+ [Establecer Amazon Route 53 como servicio DNS de un dominio existente](MigratingDNS.md)
+ [Configuración del direccionamiento de DNS para un nuevo dominio](dns-configuring-new-domain.md)
+ [Direccionamiento del tráfico a sus recursos](dns-routing-traffic-to-resources.md)
+ [Uso de zonas alojadas](hosted-zones-working-with.md)
+ [Uso de registros](rrsets-working-with.md)
+ [Configuración de la firma de DNSSEC en Amazon Route 53](dns-configuring-dnssec.md)
+ [Uso de AWS Cloud Map para crear registros y comprobaciones de estado](autonaming.md)
+ [Restricciones y comportamientos de DNS](DNSBehavior.md)
+ [Temas relacionados](dns-configuring-related-topics.md)
# Establecer Amazon Route 53 como servicio DNS de un dominio existente
Si va a transferir uno o varios registros de dominio a Route 53 y está utilizando actualmente un registrador de dominios que no proporciona un servicio DNS de pago, debe migrar el servicio DNS antes de migrar el dominio. De lo contrario, el registrador dejará de proporcionar el servicio DNS cuando transfiera sus dominios y los sitios y aplicaciones web asociados dejarán de estar disponible en Internet. (También puede migrar el servicio DNS desde el registrador actual a otro proveedor de servicios DNS. No es necesario usar Route 53 como el proveedor de servicios DNS para los dominios que están registrados con Route 53).
El proceso depende de si está utilizando actualmente el dominio:
+ Si el dominio tiene actualmente tráfico (por ejemplo, si los usuarios utilizan el nombre de dominio para navegar por un sitio web u obtener acceso a una aplicación web), consulte [Establecer Route 53 como el servicio DNS para un dominio que se está utilizando](migrate-dns-domain-in-use.md).
+ Si el dominio no tiene tráfico (o tiene muy poco tráfico), consulte [Establecer Route 53 como el servicio DNS de un dominio inactivo](migrate-dns-domain-inactive.md).
En ambas opciones, su dominio debe permanecer disponible durante todo el proceso de migración. Sin embargo, en el caso poco probable de que haya problemas, la primera opción le permite restaurar la migración de forma rápida. Con la segunda opción, su dominio podría no estar disponible durante un par de días.
Si desea ponerse en contacto con un experto en AWS, visite [Soporte de ventas](https://aws.amazon.com/contact-us/sales-support/?pg=ln&sec=hs).
# Establecer Route 53 como el servicio DNS para un dominio que se está utilizando
Si desea migrar el servicio DNS a Amazon Route 53 en el caso de un dominio que tenga actualmente tráfico (por ejemplo, si los usuarios utilizan el nombre de dominio para navegar a un sitio web u obtener acceso a una aplicación web), siga los procedimientos que indicamos en esta sección.
**Topics**
+ [Paso 1: Obtener la configuración de DNS actual del proveedor de servicios DNS actual (opcional pero recomendado)](#migrate-dns-get-zone-file)
+ [Paso 2: Crear una zona alojada](#migrate-dns-create-hosted-zone)
+ [Paso 3: Crear los registros](#migrate-dns-create-records)
+ [Paso 4: Reducir la configuración de TTL](#migrate-dns-lower-ttl)
+ [Paso 5: (Si DNSSEC está configurado) Quitar el registro de DS de la zona principal](#migrate-remove-ds)
+ [Paso 6: Esperar a que caduque el TTL anterior](#migrate-dns-wait-for-ttl)
+ [Paso 7: Actualizar los registros NS para utilizar servidores de nombres de Route 53](#migrate-dns-change-name-servers-with-provider)
+ [Paso 8: Monitorear el tráfico del dominio](#migrate-dns-monitor-traffic)
+ [Paso 9: Volver a cambiar el TTL del registro NS a un valor más alto](#migrate-dns-change-ttl-back)
+ [Paso 10: Transferir el registro del dominio a Amazon Route 53](#migrate-dns-transfer-domain-registration)
+ [Paso 11: Volver a habilitar la firma de DNSSEC (si es necesario)](#migrate-dns-re-enable-dnssec)
## Paso 1: Obtener la configuración de DNS actual del proveedor de servicios DNS actual (opcional pero recomendado)
Al migrar el servicio DNS desde otro proveedor a Route 53, reproduce su configuración de DNS actual en Route 53. En Route 53, debe crear una zona alojada que tenga el mismo nombre que su dominio y crear registros en la zona alojada. Cada registro indica cómo desea dirigir el tráfico de un nombre de dominio o subdominio especificado. Por ejemplo, cuando alguien introduce su nombre de dominio en un navegador web, ¿desea que el tráfico se dirija a un servidor web de su centro de datos, a una instancia de Amazon EC2, a CloudFront una distribución o a alguna otra ubicación?
El proceso que utilice dependerá de la complejidad de la configuración de DNS que tenga:
+ **Si la configuración de DNS actual es sencilla**. Si está dirigiendo tráfico de Internet solo para unos cuantos subdominios a un pequeño número de recursos, como servidores web o buckets de Amazon S3, puede crear manualmente varios registros en la consola de Route 53.
+ **Si la configuración de DNS actual es más compleja y solo quiere reproducir su configuración actual**. Puede simplificar la migración si puede obtener un archivo de zona del proveedor de servicios DNS actual e importar dicho archivo a Route 53. (No todos los proveedores de servicios DNS ofrecen archivos de zona). Al importar un archivo de zona, Route 53 reproduce automáticamente la configuración existente creando los registros correspondientes en la zona alojada.
Pregunte al servicio de atención al cliente de su proveedor de servicios DNS actual cómo obtener un *archivo de zona* o una *lista de registros*. Para obtener más información acerca del formato que un archivo de zona ha de tener, consulte [Creación de registros mediante la importación de un archivo de zona](resource-record-sets-creating-import.md).
+ **Si su configuración de DNS actual es más compleja y está interesado en las características de enrutamiento de Route 53**. Lea la documentación siguiente para ver si quiere utilizar las características de Route 53 que no están disponibles en otros proveedores de servicios DNS. En caso afirmativo, puede crear registros manualmente o puede importar un archivo de zona y, a continuación, crear o actualizar registros en otro momento:
+ [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md)explica las ventajas de los registros de alias de Route 53, que redirigen el tráfico a algunos AWS recursos, como CloudFront distribuciones y buckets de Amazon S3, de forma gratuita.
+ [Elección de una política de enrutado](routing-policy.md) explica las opciones de direccionamiento de Route 53, como, por ejemplo, el enrutamiento basado en la ubicación de los usuarios, el enrutamiento basado en la latencia entre sus usuarios y los recursos, el enrutamiento basado en si los recursos son correctos y el que está basado en ponderaciones que usted mismo especifica.
**nota**
También puede importar un archivo de zona y más tarde cambiar la configuración para aprovechar los registros de alias y las políticas de direccionamiento complejas.
Si no puede obtener un archivo de zona o si desea crear manualmente registros en Route 53, los registros que probablemente migrará son los siguientes:
+ **Registros A (direcciones)**: asocie un nombre de dominio o un nombre de subdominio a la IPv4 dirección (por ejemplo, 192.0.2.3) del recurso correspondiente
+ **Registros AAAA (direcciones)**: asocie un nombre de dominio o subdominio a la IPv6 dirección (por ejemplo, 2001:0 db 8:85 a 3:0000:0000:abcd: 0001:2345) del recurso correspondiente
+ **Registros de servidor de correo (MX)**: dirigen tráfico a servidores de correo
+ **Registros CNAME**: redirigen el tráfico de un nombre de dominio (example.net) a otro nombre de dominio (example.com)
+ **Registros para otros tipos de registros DNS admitidos**: para consultar una lista de tipos de registros admitidos, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
## Paso 2: Crear una zona alojada
Para indicar a Amazon Route 53 cómo quiere dirigir el tráfico de su dominio, cree una zona alojada que tenga el mismo nombre que el dominio y después cree registros en la zona alojada.
**importante**
Puede crear una zona alojada solo para los dominios para los que tenga permiso para administrar. Por lo general, esto indicará que es el propietario del dominio, aunque también podría estar desarrollando una aplicación para el registrador del dominio.
Cuando crea una zona alojada, Route 53 genera automáticamente un registro del servidor de nombres (NS) y un registro de inicio de autoridad (SOA) para dicha zona. El registro NS identifica los cuatro servidores de nombres que Route 53 asoció a su zona alojada. Para que Route 53 sea el servicio DNS de su dominio, puede actualizar el registro del dominio para que utilice estos cuatro servidores de nombres.
**importante**
No cree registros de servidor de nombres (NS) o de inicio de autoridad (SOA) adicionales ni elimine los registros SOA y NS existentes.
**Para crear una zona alojada**
1. Inicie Consola de administración de AWS sesión en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)la consola de Route 53 y ábrala en.
1. Si no está familiarizado con Route 53, elija **Get started** (Introducción) en **DNS management** (Administración de DNS) y, a continuación, elija **Create hosted zones** (Crear zonas alojadas).
Si ya trabaja con Route 53, elija **Hosted zones** (Zonas alojadas) en el panel de navegación y, a continuación, elija **Create hosted zones** (Crear zonas alojadas).
1. En el panel **Create hosted zone** (Crear zona alojada), ingrese un nombre de dominio y, si lo desea, un comentario. Para obtener más información sobre una configuración, elija abrir el panel de ayuda en el lado derecho.
Para obtener información sobre cómo especificar caracteres distintos de a-z, 0-9 y - (guion), y cómo especificar nombres de dominio internacionalizados, consulte [Formato de nombres de dominio DNS](DomainNameFormat.md).
1. En **Type** (Tipo), acepte el valor predeterminado de **Public hosted zone** (Zona alojada pública).
1. Elija **Create hosted zone** (Crear zona alojada).
## Paso 3: Crear los registros
Después de crear una zona alojada, debe crear registros en dicha zona que definan adónde desea dirigir el tráfico de un dominio (example.com) o subdominio (www.example.com). Por ejemplo, si desea dirigir el tráfico de example.com y www.example.com a un servidor web en una instancia de Amazon EC2, debe crear dos registros, uno denominado example.com y otro denominado www.example.com. En cada registro debe especificar la dirección IP de la instancia de EC2.
Puede crear registros de diversas formas:
**Importando un archivo de zona.**
Este es el método más fácil si tiene un archivo de zona de su servicio DNS actual en [Paso 1: Obtener la configuración de DNS actual del proveedor de servicios DNS actual (opcional pero recomendado)](#migrate-dns-get-zone-file). Amazon Route 53 no puede predecir cuándo crear registros de alias o utilizar tipos de direccionamiento especiales como el direccionamiento ponderado o de conmutación por error. Como resultado, si importa un archivo de zona, Route 53 crea registros DNS estándar con la política de direccionamiento sencilla.
Para obtener más información, consulte [Creación de registros mediante la importación de un archivo de zona](resource-record-sets-creating-import.md).
**Creando registros individualmente en la consola**
Si no ha recibido un archivo de zona y quiere crear unos cuantos registros con una política de direccionamiento sencilla para comenzar, puede crear los registros en la consola de Route 53. Puede crear registros de alias y registros sin alias.
Para obtener más información, consulte los temas siguientes:
+ [Elección de una política de enrutado](routing-policy.md)
+ [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md)
+ [Creación de registros con la consola de Amazon Route 53](resource-record-sets-creating.md)
**Creando registros mediante programación**
Puede crear registros utilizando una de las AWS SDKs AWS CLI, las o AWS Tools for Windows PowerShell. Para obtener más información, consulte la [Documentación de AWS](https://docs.aws.amazon.com/).
Si utilizas un lenguaje de programación que AWS no incluye un SDK, también puedes usar la API de Route 53. Para obtener más información, consulte la [referencia de API de Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/).
## Paso 4: Reducir la configuración de TTL
La opción TTL (tiempo de vida) de un registro especifica el tiempo que quiere que los solucionadores de DNS tengan en caché el registro y se use la información de la memoria caché. Cuando el TTL vence, un solucionador envía otra consulta al proveedor de servicios DNS para que un dominio obtenga la información más reciente.
Normalmente, la configuración de TTL para el registro NS es de 172 800 segundos o dos días. El registro NS muestra una lista de los servidores de nombres que el sistema de nombres de dominio (DNS) puede utilizar para obtener información acerca de cómo dirigir el tráfico para su dominio. Si reduce el TTL del registro NS, tanto en su proveedor de servicios DNS actual como en Amazon Route 53, reducirá el tiempo de inactividad de su dominio si descubre un problema mientras realiza la migración de DNS a Route 53. Si no reduce el TTL, su dominio podría no estar disponible en Internet durante un máximo de dos días si algo va mal.
**nota**
Algunos solucionadores completos pueden almacenar en caché el TTL del registro NS del servidor autorizado principal, por lo que también se debe reducir el TTL de los registros NS registrados en el servidor DNS autorizado principal.
Le recomendamos que cambie el TTL en los siguientes registros NS:
+ En el registro NS de la zona alojada del proveedor de servicios DNS actual. (Puede que su proveedor actual utilice otra terminología).
+ En el registro NS de la zona alojada que ha creado en [Paso 2: Crear una zona alojada](#migrate-dns-create-hosted-zone).
**Para reducir la configuración de TTL en el registro NS del proveedor de servicios DNS actual**
+ Utilice el método proporcionado por el proveedor de servicios DNS actual para que el dominio cambie el TTL del registro NS de la zona alojada de su dominio.
**Para reducir la configuración de TTL en el registro NS de una zona alojada de Route 53**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Elija **Hosted Zones** (Zonas alojadas) en el panel de navegación.
1. Elija el nombre de la zona alojada.
1. Elija el registro NS y, a continuación, elija **Edit** (Editar).
1. Cambie el valor de **TTL (Seconds)** (Segundos). Le recomendamos que especifique un valor entre 60 segundos y 900 segundos (15 minutos).
1. Elija **Save changes** (Guardar cambios).
## Paso 5: (Si DNSSEC está configurado) Quitar el registro de DS de la zona principal
Si ha configurado DNSSEC para su dominio, quite el registro de Delegation Signer (DS) de la zona principal antes de migrar el dominio a Route 53.
Si la zona principal está alojada a través de Route 53 u otro registrador, contacte con él para eliminar el registro DS.
Como actualmente no es posible habilitar la firma de DNSSEC en dos proveedores, debe eliminar cualquier DS o DNSKEYs desactivar el DNSSEC. Esto envía una señal temporal a los solucionadores de DNS para que desactiven la validación DNSSEC. En el [paso 11](#migrate-dns-re-enable-dnssec), puede volver a habilitar la validación de DNSSEC si lo desea, una vez completada la transición a Route 53.
Para obtener más información, consulte [Eliminar claves públicas de un dominio](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys).
## Paso 6: Esperar a que caduque el TTL anterior
Si está utilizando el dominio, como, por ejemplo, si los usuarios utilizan el nombre de dominio para navegar a un sitio web u obtener acceso a una aplicación web, los solucionadores de DNS tienen en caché los nombres de los servidores de nombres que ha proporcionado el proveedor de servicios DNS actual. Un solucionador de DNS que haya guardado en la memoria caché esa información tan solo unos minutos antes, la guardará durante casi dos días más.
Para asegurarse de que la migración del servicio DNS a Route 53 se produzca de una sola vez, espere dos días después de haber reducido el TTL. Una vez transcurridos esos dos días, el TTL vencerá y los solucionadores solicitarán a los servidores de nombres su dominio, obtendrán los servidores de nombres actuales y también obtendrán el nuevo TTL especificado en [Paso 4: Reducir la configuración de TTL](#migrate-dns-lower-ttl).
## Paso 7: Actualizar los registros NS para utilizar servidores de nombres de Route 53
Para comenzar a utilizar Amazon Route 53 como servicio DNS para un dominio, utilice el método proporcionado por el proveedor de servicios DNS actual para reemplazar los servidores de nombres actuales en el registro NS por servidores de nombres de Route 53.
**nota**
Cuando actualiza el registro NS con el proveedor de servicios DNS actual para utilizar servidores de nombres de Route 53, actualiza la configuración DNS del dominio. (Esto equivale a la actualización del registro NS en la zona alojada de Route 53 para un dominio, con la excepción de que está actualizando la configuración con el servicio DNS desde el que está migrando).
**Para actualizar el registro NS en el registrador, o en la zona principal, para utilizar los servidores de nombres de Route 53**
1. En la consola de Route 53, obtenga los servidores de nombres de la zona alojada:
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. En el panel de navegación, elija **Zonas alojadas**.
1. En la página **Hosted zones** (Zonas alojadas), seleccione el nombre de la zona alojada pertinente.
1. Anote los cuatro nombres que figuran en **Name servers** (Servidores de nombres) en la sección **Hosted zone details** (Detalles de la zona alojada).
1. Utilice el método que proporciona el servicio DNS actual para que el dominio actualice el registro NS de la zona alojada. Si el dominio está registrado con Route 53, consulte [Adición o modificación de servidores de nombres y registros de conexión de un dominio](domain-name-servers-glue-records.md). El proceso dependerá de si el servicio DNS actual le permite eliminar servidores de nombres:
**Si puede eliminar los servidores de nombres**
+ Anote los nombres de los servidores de nombres actuales del registro NS para la zona alojada. Si necesita volver a la configuración de DNS actual, estos son los servidores que especificará.
+ Elimine los servidores de nombres actuales del registro NS.
+ Actualice el registro NS con los nombres de los cuatros servidores de nombres de Route 53 que obtuvo en el paso 1 de este procedimiento.
**nota**
Cuando termine, los únicos servidores de nombres del registro NS serán los cuatro servidores de nombres de Route 53.
**Si no puede eliminar los servidores de nombres**
+ Elija la opción para utilizar servidores de nombres personalizados.
+ Añada los cuatro servidores de nombres de Route 53 que obtuvo en el paso 1 de este procedimiento.
## Paso 8: Monitorear el tráfico del dominio
Monitoree el tráfico del dominio, incluido el tráfico del sitio web o la aplicación, y el correo electrónico:
+ **Si el tráfico se reduce o se detiene**: utilice el método proporcionado por el servicio DNS anterior para cambiar los servidores de nombres del dominio por los servidores de nombres anteriores. Estos son los servidores de nombres que anotó en el paso 7 de [Para actualizar el registro NS en el registrador, o en la zona principal, para utilizar los servidores de nombres de Route 53](#migrate-dns-change-name-servers-with-provider-procedure). A continuación, determine qué ha fallado.
+ **Si el tráfico no se ve afectado**: continúe en [Paso 9: Volver a cambiar el TTL del registro NS a un valor más alto](#migrate-dns-change-ttl-back).
## Paso 9: Volver a cambiar el TTL del registro NS a un valor más alto
En la zona alojada de Amazon Route 53 del dominio, cambie el TTL del registro NS a un valor más habitual, como, por ejemplo, 172800 segundos (dos días). Esto mejorará la latencia de los usuarios, ya que no tendrán que esperar tan a menudo para que los solucionadores de DNS envíen una consulta para obtener los servidores de nombres de su dominio.
**Para cambiar el TTL del registro NS de la zona alojada de Route 53**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Elija **Hosted Zones** (Zonas alojadas) en el panel de navegación.
1. Elija el nombre de la zona alojada.
1. En la lista de registros de la zona alojada, elija el registro NS.
1. Elija **Edit (Edición de)**.
1. Cambie **TTL (Seconds)** por el número de segundos que desea que los solucionadores de DNS almacenen en caché los nombres de los servidores de nombres de su dominio. Le recomendamos un valor de 172 800 segundos.
1. Seleccione **Save changes (Guardar cambios)**.
## Paso 10: Transferir el registro del dominio a Amazon Route 53
Ahora que ha transferido el servicio DNS de un dominio a Amazon Route 53, tiene la opción de transferir el registro del dominio a Route 53. Para obtener más información, consulte [Transferencia del registro de un dominio a Amazon Route 53](domain-transfer-to-route-53.md).
## Paso 11: Volver a habilitar la firma de DNSSEC (si es necesario)
Ahora que ha transferido el servicio DNS de un dominio a Amazon Route 53, tiene la opción de volver a habilitar la firma de DNSSEC.
Habilitar la firma de DNSSEC es un proceso de dos pasos:
+ Paso 1: Habilite la firma DNSSEC para Route 53 y solicite que Route 53 cree una clave de firma clave (KSK) basada en una clave administrada por el cliente en AWS Key Management Service ().AWS KMS
+ Paso 2: Crear una cadena de confianza para la zona alojada agregando un registro de Delegation Signer (DS) a la zona principal, de modo que las respuestas DNS se puedan autenticar con firmas criptográficas de confianza.
Para obtener instrucciones, consulte [Activar la firma de DNSSEC y establecer una cadena de confianza](dns-configuring-dnssec-enable-signing.md).
# Establecer Route 53 como el servicio DNS de un dominio inactivo
Si desea migrar a Amazon Route 53 el servicio DNS de un dominio que no tiene tráfico (o muy poco tráfico), siga el procedimiento que se indica en esta sección.
**Topics**
+ [Paso 1: Solicitar la configuración de DNS actual al proveedor de servicios DNS actual (dominios inactivos)](#migrate-dns-get-zone-file-domain-inactive)
+ [Paso 2: Crear una zona alojada (dominios inactivos)](#migrate-dns-create-hosted-zone-domain-inactive)
+ [Paso 3: Crear los registros (dominios inactivos)](#migrate-dns-create-records-domain-inactive)
+ [Paso 4: Actualizar el registro de dominio para que utilice los servidores de nombres de Amazon Route 53 (dominios inactivos)](#migrate-dns-update-domain-inactive)
## Paso 1: Solicitar la configuración de DNS actual al proveedor de servicios DNS actual (dominios inactivos)
Al migrar el servicio DNS desde otro proveedor a Route 53, reproduce su configuración de DNS actual en Route 53. En Route 53, debe crear una zona alojada que tenga el mismo nombre que su dominio y crear registros en la zona alojada. Cada registro indica cómo desea dirigir el tráfico de un nombre de dominio o subdominio especificado. Por ejemplo, cuando alguien introduce su nombre de dominio en un navegador web, ¿desea que el tráfico se dirija a un servidor web de su centro de datos, a una instancia de Amazon EC2, a CloudFront una distribución o a alguna otra ubicación?
El proceso que utilice dependerá de la complejidad de la configuración de DNS que tenga:
+ **Si la configuración de DNS actual es sencilla**. Si está dirigiendo tráfico de Internet solo para unos cuantos subdominios a un pequeño número de recursos, como servidores web o buckets de Amazon S3, puede crear manualmente varios registros en la consola de Route 53.
+ **Si la configuración de DNS actual es más compleja y solo quiere reproducir su configuración actual**. Puede simplificar la migración si puede obtener un archivo de zona del proveedor de servicios DNS actual e importar dicho archivo a Route 53. (No todos los proveedores de servicios DNS ofrecen archivos de zona). Al importar un archivo de zona, Route 53 reproduce automáticamente la configuración existente creando los registros correspondientes en la zona alojada.
Pregunte al servicio de atención al cliente de su proveedor de servicios DNS actual cómo obtener un *archivo de zona* o una *lista de registros*. Para obtener más información acerca del formato que un archivo de zona ha de tener, consulte [Creación de registros mediante la importación de un archivo de zona](resource-record-sets-creating-import.md).
+ **Si su configuración de DNS actual es más compleja y está interesado en las características de enrutamiento de Route 53**. Lea la documentación siguiente para ver si quiere utilizar las características de Route 53 que no están disponibles en otros proveedores de servicios DNS. En caso afirmativo, puede crear registros manualmente o puede importar un archivo de zona y, a continuación, crear o actualizar registros en otro momento:
+ [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md)explica las ventajas de los registros de alias de Route 53, que redirigen el tráfico a algunos AWS recursos, como CloudFront distribuciones y buckets de Amazon S3, de forma gratuita.
+ [Elección de una política de enrutado](routing-policy.md) explica las opciones de direccionamiento de Route 53, como, por ejemplo, el enrutamiento basado en la ubicación de los usuarios, el enrutamiento basado en la latencia entre sus usuarios y los recursos, el enrutamiento basado en si los recursos son correctos y el que está basado en ponderaciones que usted mismo especifica.
**nota**
También puede importar un archivo de zona y más tarde cambiar la configuración para aprovechar los registros de alias y las políticas de direccionamiento complejas.
Si no puede obtener un archivo de zona o si desea crear manualmente registros en Route 53, los registros que probablemente migrará son los siguientes:
+ **Registros A (direcciones)**: asocie un nombre de dominio o un nombre de subdominio a la IPv4 dirección (por ejemplo, 192.0.2.3) del recurso correspondiente
+ **Registros AAAA (direcciones)**: asocie un nombre de dominio o subdominio a la IPv6 dirección (por ejemplo, 2001:0 db 8:85 a 3:0000:0000:abcd: 0001:2345) del recurso correspondiente
+ **Registros de servidor de correo (MX)**: dirigen tráfico a servidores de correo
+ **Registros CNAME**: redirigen el tráfico de un nombre de dominio (example.net) a otro nombre de dominio (example.com)
+ **Registros para otros tipos de registros DNS admitidos**: para consultar una lista de tipos de registros admitidos, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
## Paso 2: Crear una zona alojada (dominios inactivos)
Para indicar a Amazon Route 53 cómo quiere dirigir el tráfico de su dominio, cree una zona alojada que tenga el mismo nombre que el dominio y después cree registros en la zona alojada.
**importante**
Puede crear una zona alojada solo para los dominios para los que tenga permiso para administrar. Por lo general, esto indicará que es el propietario del dominio, aunque también podría estar desarrollando una aplicación para el registrador del dominio.
Cuando crea una zona alojada, Route 53 genera automáticamente un registro del servidor de nombres (NS) y un registro de inicio de autoridad (SOA) para dicha zona. El registro NS identifica los cuatro servidores de nombres que Route 53 asoció a su zona alojada. Para que Route 53 sea el servicio DNS de su dominio, puede actualizar el registro del dominio para que utilice estos cuatro servidores de nombres.
**importante**
No cree registros de servidor de nombres (NS) o de inicio de autoridad (SOA) adicionales ni elimine los registros SOA y NS existentes.
**Para crear una zona alojada**
1. Inicie Consola de administración de AWS sesión en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)la consola de Route 53 y ábrala en.
1. Si no conoce Route 53, elija **Get started** (Introducción).
Si ya trabaja con Route 53, seleccione **Hosted zones** (Zonas alojadas) en el panel de navegación.
1. Elija **Create hosted zone** (Crear zona alojada).
1. En el panel **Create hosted zone** (Crear zona alojada), ingrese un nombre de dominio y, si lo desea, un comentario. Si necesita más información sobre una opción de configuración, sitúe el puntero del ratón sobre el nombre de la opción para que aparezca la información sobre herramientas.
Para obtener información sobre cómo especificar caracteres distintos de a-z, 0-9 y - (guion), y cómo especificar nombres de dominio internacionalizados, consulte [Formato de nombres de dominio DNS](DomainNameFormat.md).
1. En **Record type** (Tipo de registro), acepte el valor predeterminado de **Public hosted zone** (Zona alojada pública).
1. Elija **Create hosted zone** (Crear zona alojada).
## Paso 3: Crear los registros (dominios inactivos)
Después de crear una zona alojada, debe crear registros en dicha zona que definan adónde desea dirigir el tráfico de un dominio (example.com) o subdominio (www.example.com). Por ejemplo, si desea dirigir el tráfico de example.com y www.example.com a un servidor web en una instancia de Amazon EC2, debe crear dos registros, uno denominado example.com y otro denominado www.example.com. En cada registro debe especificar la dirección IP de la instancia de EC2.
Puede crear registros de diversas formas:
**Importando un archivo de zona.**
Este es el método más fácil si tiene un archivo de zona de su servicio DNS actual en [Paso 1: Solicitar la configuración de DNS actual al proveedor de servicios DNS actual (dominios inactivos)](#migrate-dns-get-zone-file-domain-inactive). Amazon Route 53 no puede predecir cuándo crear registros de alias o utilizar tipos de direccionamiento especiales como el direccionamiento ponderado o de conmutación por error. Como resultado, si importa un archivo de zona, Route 53 crea registros DNS estándar con la política de direccionamiento sencilla.
Para obtener más información, consulte [Creación de registros mediante la importación de un archivo de zona](resource-record-sets-creating-import.md).
**Creando registros individualmente en la consola**
Si no ha recibido un archivo de zona y quiere crear unos cuantos registros con una política de direccionamiento sencilla para comenzar, puede crear los registros en la consola de Route 53. Puede crear registros de alias y registros sin alias.
Para obtener más información, consulte los temas siguientes:
+ [Elección de una política de enrutado](routing-policy.md)
+ [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md)
+ [Creación de registros con la consola de Amazon Route 53](resource-record-sets-creating.md)
**Creando registros mediante programación**
Puede crear registros utilizando una de las AWS SDKs AWS CLI, las o AWS Tools for Windows PowerShell. Para obtener más información, consulte la [Documentación de AWS](https://docs.aws.amazon.com/).
Si utilizas un lenguaje de programación que AWS no incluye un SDK, también puedes usar la API de Route 53. Para obtener más información, consulte la [referencia de API de Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/).
## Paso 4: Actualizar el registro de dominio para que utilice los servidores de nombres de Amazon Route 53 (dominios inactivos)
Cuando haya terminado de crear registros para el dominio, puede cambiar el servicio DNS de su dominio a Amazon Route 53. Ejecute el procedimiento siguiente para actualizar la configuración en el registrador de dominio.
**Para actualizar los servidores de nombres del dominio**
1. En la consola de Route 53, obtenga los servidores de nombres de la zona alojada de Route 53:
1. Abra la consola de Route 53 en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas**.
1. En la página **Hosted zones** (Zonas alojadas), elija el botón de radio (no el nombre) de la zona alojada y luego **View details** (Ver detalles).
1. En la página de detalles de la zona alojada, elija **Hosted zone details** (Detalles de la zona alojada).
1. Anote los nombres de los cuatro servidores que aparecen en **Name servers** (Servidores de nombres).
1. Use el método proporcionado por el registrador del dominio para cambiar los servidores de nombres para que el dominio use los cuatro servidores de nombres de Route 53 que obtuvo en el paso 2 de este procedimiento.
Si el dominio está registrado en Route 53, consulte [Adición o modificación de servidores de nombres y registros de conexión de un dominio](domain-name-servers-glue-records.md).
# Configuración del direccionamiento de DNS para un nuevo dominio
**Un dominio nuevo que compró en Route 53**
Al registrar un dominio con Route 53, convertimos automáticamente a Route 53 en el servicio DNS del dominio. Route 53 crea una zona alojada que tiene el mismo nombre que el dominio, asigna cuatro servidores de nombres a la zona alojada y actualiza el dominio para utilizar esos servidores de nombres.
**Un dominio nuevo que compró de otro registrador**
Cuando compra un dominio de otro registrador, por ejemplo, porque Route 53 no ofrece el dominio de nivel superior (TLD), tiene dos opciones:
+ **Utilice Route 53 únicamente para el alojamiento de DNS:** mantenga su registrador actual, pero delegue la administración del DNS a Route 53. Siga el procedimiento que se indica a continuación para crear una zona alojada y actualizar los servidores de nombres de su registrador.
+ **Transfiera el registro del dominio a Route 53:** convierta a Route 53 en su registrador y servicio de DNS. Consulte [Lista de verificación previa a la transferencia para transferencias de dominios](domain-transfer-checklist.md) para conocer los requisitos previos y [Transferencia del registro de un dominio a Amazon Route 53](domain-transfer-to-route-53.md) para conocer el proceso de transferencia.
Para obtener más información acerca de los TLD que admite Route 53, consulte [Dominios que puede registrar con Amazon Route 53](registrar-tld-list.md).
Siga estas instrucciones para crear una zona alojada pública y, a continuación, utilice los servidores de nombres creados con el registrador:
**Cómo crear una zona alojada para un dominio no proveniente de Route 53**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Route 53 en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas** y, luego, **Crear zona alojada**.
1. En **Nombre**, introduzca el nombre del dominio para el que desea crear una zona alojada, como `example.com`, y una descripción opcional. Seleccione **Zona alojada pública** y, a continuación, **Crear zona alojada**.
1. Después de crear la zona alojada, anote los cuatro registros del servidor de nombres (NS) que se crearon. Estos empezarán con «ns-».
En el registrador de dominios, introduzca los servidores de nombres anteriores para delegar la administración de los dominios a la zona alojada de Route 53.
**Enrute el tráfico de DNS**
Para especificar la forma en que desea que Route 53 dirija el tráfico de Internet del dominio, debe crear registros en la zona alojada. Por ejemplo, si desea direccionar las solicitudes de example.com a un servidor web que se ejecuta en una instancia de Amazon EC2, debe crear un registro en la zona alojada example.com y especificar la dirección IP elástica de la instancia de EC2. Para obtener más información, consulte los temas siguientes:
+ Para obtener información sobre cómo crear registros en su zona alojada, consulte [Uso de registros](rrsets-working-with.md).
+ Para obtener información sobre cómo dirigir el tráfico a recursos de AWS seleccionados, consulte [Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
+ Para obtener información sobre cómo funciona DNS, consulte [se dirige el tráfico de Internet a su sitio web o aplicación web](welcome-dns-service.md).
+ Para comprobar el reposo del DNS, consulte [Comprobación de las respuestas de DNS de Route 53](dns-test.md).
# Direccionamiento del tráfico a sus recursos
Cuando los usuarios solicitan su sitio web o una aplicación web, por ejemplo, escribiendo el nombre de su dominio en un navegador web, Amazon Route 53 ayuda a dirigir a los usuarios a sus recursos, como un bucket de Amazon S3 o un servidor web de su centro de datos. Para configurar Route 53 para que dirija el tráfico a sus recursos, debe hacer lo siguiente:
1. Cree una zona alojada. Puede crear una zona alojada pública o una zona alojada privada:
**Zona alojada pública**
Cree una zona alojada pública si desea dirigir el tráfico de Internet a sus recursos, por ejemplo, para que los clientes puedan ver el sitio web de la empresa que se aloja en instancias de EC2. Para obtener más información, consulte [Trabajar con zonas públicas alojadas](AboutHZWorkingWith.md).
**Zona alojada privada**
Cree una zona alojada privada si desea dirigir el tráfico dentro de una Amazon VPC. Para obtener más información, consulte [Uso de zonas alojadas privadas](hosted-zones-private.md).
1. Creación de registros en la zona alojada. Los registros definen a dónde quiere dirigir el tráfico para cada nombre de dominio o de subdominio. Por ejemplo, para dirigir el tráfico de www.example.com a un servidor web de su centro de datos, se suele crear un registro de www.example.com en la zona alojada de example.com.
Para obtener más información, consulte los temas siguientes:
+ [Uso de registros](rrsets-working-with.md)
+ [Direccionamiento del tráfico de subdominios](dns-routing-traffic-for-subdomains.md)
+ [Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md)
# Direccionamiento del tráfico de subdominios
Cuando desee dirigir el tráfico a sus recursos para un subdominio como acme.example.com o zenith.example.com, dispone de dos opciones:
**Creación de registros en la zona alojada para el dominio**
Normalmente, para dirigir el tráfico de un subdominio, se crea un registro en la zona alojada que tenga el mismo nombre que el dominio. Por ejemplo, para dirigir el tráfico de Internet de acme.example.com a un servidor web de su centro de datos, se crea un registro llamado acme.example.com en la zona alojada de example.com. Para obtener más información, consulte el tema [Uso de registros](rrsets-working-with.md) y sus subtemas.
**Creación una zona alojada para el subdominio y creación de registros en la nueva zona alojada**
También puede crear una zona alojada para el subdominio. Usar una zona alojada independiente para dirigir el tráfico de Internet de un subdominio a veces recibe el nombre de “delegar la responsabilidad de un subdominio a una zona alojada” o “delegar un subdominio a otros servidores de nombres”, o alguna combinación de términos similar. Aquí se ofrece información general de cómo funciona:
1. Cree una zona alojada que tiene el mismo nombre que el subdominio para el que desea enrutar el tráfico, como acme.example.com.
1. Cree registros en la nueva zona alojada, que definan cómo desea dirigir el tráfico para el subdominio (acme.example.com) y sus subdominios, como, por ejemplo, backend.acme.example.com.
1. Obtiene los servidores de nombres que asignó Route 53 a la nueva zona alojada cuando la creó.
1. Se crea un registro NS nuevo en la zona alojada para el dominio (example.com). El nombre del registro NS debe ser el nombre del subdominio (acme.example.com) y debe especificar los cuatro servidores de nombres que obtuvo en el paso 3 como valores de registro.
Cuando se usa una zona alojada independiente para dirigir el tráfico de un subdominio, se pueden utilizar permisos de IAM para restringir el acceso a la zona alojada del subdominio. Si tiene varios subdominios administrados por diferentes grupos, la creación de una zona alojada para cada subdominio puede reducir significativamente el número de personas que deben tener acceso a los registros de la zona alojada del dominio.
Para implementar este proceso de delegación, necesita los siguientes permisos de IAM. Para obtener más información sobre las políticas de IAM de Route 53, consulte[Identity and Access Management en Amazon Route 53](security-iam.md):
**Cuenta principal (es propietaria de example.com)**
El usuario o rol necesita permisos para modificar los registros en la zona alojada del dominio principal:
**Cuenta secundaria (crea acme.example.com)**
El usuario o el rol necesitan permisos para crear y administrar la zona alojada del subdominio:
El uso de una zona alojada de un subdominio también le permite utilizar servicios DNS diferentes para el dominio y el subdominio. Para obtener más información, consulte [Uso de Amazon Route 53 como el servicio DNS de subdominios sin migrar el dominio principal](creating-migrating.md).
Esta configuración tiene un pequeño impacto sobre el desempeño para la primera consulta de DNS de cada servicio de resolución de nombres DNS. El servicio de resolución debe obtener información de la zona alojada del dominio raíz y, a continuación, obtener información de la zona alojada para el subdominio. Después de la primera consulta de DNS a un subdominio, el servicio de resolución de nombres almacena la información en caché y no necesita volver a obtenerla hasta que transcurra el tiempo de vida (TTL) y otro cliente solicite el subdominio a ese servicio de resolución. Para obtener más información, consulte [TTL (segundos)](resource-record-sets-values-basic.md#rrsets-values-basic-ttl) en la sección [Valores que hay que especificar al crear o editar los registros de Amazon Route 53.](resource-record-sets-values.md).
**Topics**
+ [Creación de otra zona alojada para dirigir el tráfico para un subdominio](#dns-routing-traffic-for-subdomains-new-hosted-zone)
+ [Direccionamiento del tráfico para niveles adicionales de subdominios](#dns-routing-traffic-for-sub-subdomains)
## Creación de otra zona alojada para dirigir el tráfico para un subdominio
Una forma de dirigir el tráfico de un subdominio es crear una zona alojada para el subdominio y, a continuación, crear registros para el subdominio en la nueva zona alojada. (La opción más habitual es crear registros para el subdominio en la zona alojada del dominio).
**nota**
Este procedimiento muestra cómo delegar un subdominio a Route 53. También puede delegar un subdominio a otros servicios de DNS mediante la creación de registros NS que, en su lugar, apunten a los servidores de nombres de esos servicios.
A continuación se ofrece información general sobre el proceso:
1. Creación de una zona alojada para el subdominio. Para obtener más información, consulte [Creación de una nueva zona alojada para un subdominio](#dns-routing-traffic-for-subdomains-creating-hosted-zone).
1. Adición de registros a la zona alojada para el subdominio. Si la zona alojada del dominio contiene algún registro que pertenece a la zona alojada del subdominio, duplique esos registros en la zona alojada del subdominio. Para obtener más información, consulte [Creación de registros en la zona alojada para el subdominio](#dns-routing-traffic-for-subdomains-creating-records)
1. Cree un registro NS para el subdominio en la zona alojada del dominio que delegue la responsabilidad sobre el subdominio a los servidores de nombres en la nueva zona alojada. Si la zona alojada del dominio contiene algún registro que pertenece a la zona alojada del subdominio, elimine los registros de la zona alojada del dominio. (Creó copias en la zona alojada del subdominio en el paso 2). Para obtener más información, consulte [Actualización de la zona alojada para el dominio](#dns-routing-traffic-for-subdomains-delegating-responsibility).
### Creación de una nueva zona alojada para un subdominio
Para crear una zona alojada para un subdominio con la consola de Route 53, siga estos pasos.
**Para crear una zona alojada para un subdominio (consola)**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Si no conoce Route 53, elija **Get started** (Introducción).
Si ya trabaja con Route 53, seleccione **Hosted zones** (Zonas alojadas) en el panel de navegación.
1. Elija **Create hosted zone** (Crear zona alojada).
1. En el panel de la derecha, escriba el nombre del subdominio (por ejemplo, acme.example.com). Si lo desea, también puede escribir un comentario.
Para obtener información sobre cómo especificar caracteres distintos de a-z, 0-9 y - (guion), y cómo especificar nombres de dominio internacionalizados, consulte [Formato de nombres de dominio DNS](DomainNameFormat.md).
1. En **Type** (Tipo), acepte el valor predeterminado de **Public hosted zone** (Zona alojada pública).
1. En la parte inferior del panel derecho, elija **Create hosted zone** (Crear zona alojada).
### Creación de registros en la zona alojada para el subdominio
Para definir cómo quiere que dirija el tráfico Route 53 para el subdominio (acme.example.com) y sus subdominios (backend.acme.example.com), puede crear registros en la zona alojada para el subdominio.
Tenga en cuenta lo siguiente acerca de la creación de registros en la zona alojada del subdominio:
+ No cree registros de servidor de nombres (NS) o de inicio de autoridad (SOA) adicionales en la zona alojada para el subdominio y no elimine los registros SOA y NS existentes.
+ Cree todos los registros del subdominio en la zona alojada del subdominio. Por ejemplo, si tiene zonas alojadas para example.com y para el dominio acme.example.com, cree todos los registros para el subdominio acme.example.com en la zona alojada de acme.example.com. Entre estos se incluyen registros como backend.acme.example.com y beta.backend.acme.example.com.
+ Si la zona alojada del dominio (example.com) ya contiene algún registro que pertenece a la zona alojada del subdominio (acme.example.com), duplique esos registros en la zona alojada del subdominio. En el último paso del proceso, eliminará los registros duplicados de la zona alojada del dominio.
**importante**
Si tiene algunos registros del subdominio tanto en la zona alojada del dominio como en la zona alojada del subdominio, el funcionamiento de DNS será incoherente. El funcionamiento dependerá de los servidores de nombres que un servicio de resolución de nombres DNS haya almacenado en caché, de los servidores de nombres de la zona alojada del dominio (example.com) o de los servidores de nombres de la zona alojada del subdominio (acme.example.com). En algunos casos, Route 53 devolverá NXDOMAIN (dominio inexistente) cuando el registro existe, pero no en la zona alojada a la que los servicios de resolución de nombres DNS envían la consulta.
Para obtener más información, consulte [Uso de registros](rrsets-working-with.md).
### Actualización de la zona alojada para el dominio
Al crear una zona alojada, Route 53 asigna automáticamente un conjunto de cuatro servidores a la zona. El registro NS de una zona alojada identifica los servidores de nombres que responden a las consulta de DNS del dominio o subdominio. Para comenzar a utilizar los registros de la zona alojada del subdominio para dirigir el tráfico de Internet, debe crear un nuevo registro NS en la zona alojada del dominio (example.com) y asignarle el nombre del subdominio (acme.example.com). Para el valor del registro NS, debe especificar los nombres de los servidores de nombres de la zona alojada del subdominio.
Esto es lo que ocurre cuando Route 53 recibe una consulta de DNS de un servicio de resolución de nombres DNS para el subdominio acme.example.com o uno de sus subdominios:
1. Route 53 busca en la zona alojada del dominio (example.com) y encuentra el registro NS para el subdominio (acme.example.com).
1. Route 53 obtiene los servidores de nombres del registro NS de acme.example.com de la zona alojada del dominio, example.com, y devuelve esos servidores de nombres al servicio de resolución de nombres DNS.
1. El servicio de resolución de nombres vuelve a enviar la consulta para acme.example.com a los servidores de nombres para la zona alojada acme.example.com.
1. Route 53 responde a la consulta mediante un registro en la zona alojada acme.example.com.
Para configurar Route 53 de forma que dirija el tráfico del subdominio utilizando la zona alojada del subdominio y que elimine los registros duplicados de la zona alojada del dominio, siga el procedimiento que se indica a continuación:
**Para configurar Route 53 de modo que use la zona alojada del subdominio (consola)**
1. En la consola de Route 53, obtenga los servidores de nombres de la zona alojada para el subdominio:
1. En el panel de navegación, elija **Zonas alojadas**.
1. En la página **Hosted zones** (Zonas alojadas), seleccione el nombre de la zona alojada para el subdominio.
1. En el panel de la derecha, copie los nombres de los cuatro servidores que aparecen en **Name servers** (Servidores de nombres) en la sección **Hosted zones details** (Detalles de zonas alojadas).
1. Elija el nombre de la zona alojada correspondiente al dominio (example.com), no para el subdominio.
1. Elija **Crear registro**.
1. Elija **Simple routing** (Enrutamiento sencillo) y **Next** (Siguiente).
1. Elija **Define simple record (Definir registro simple)**.
1. Especifique los siguientes valores:
**Name**
Introduzca el nombre del subdominio (por ejemplo,`acme.example.com`). Debe coincidir exactamente con el nombre de la zona alojada del subdominio que creó.
**Valor/ruta de destino del tráfico**
Elija **IP address** (Dirección IP) u otro valor en función del tipo de registro y pegue los nombres de los servidores de nombres que haya copiado en el paso 1.
**Tipo de registro**
Elija **NS — Servidores de nombres de una zona alojada**.
**TTL (Seconds)**
Cambie a un valor más común de un registro NS, como, por ejemplo, 172 800 segundos.
1. Elija **Define simple record** (Definir registro simple) y, a continuación, **Create records** (Crear registros).
1. Si la zona alojada del dominio contiene algún registro que ha vuelto a crear en la zona alojada del subdominio, elimine esos registros de la zona alojada del dominio. Para obtener más información, consulte [Eliminar registros](resource-record-sets-deleting.md).
Cuando haya terminado, todos los registros del subdominio deberían estar en la zona alojada del subdominio.
## Direccionamiento del tráfico para niveles adicionales de subdominios
Puede dirigir el tráfico a un subdominio de un subdominio, como backend.acme.example.com, de la misma manera que dirige el tráfico a un subdominio, como acme.example.com. Puede crear registros en la zona alojada para el dominio o crear una zona alojada para el subdominio de nivel inferior y, a continuación, crear registros en esa nueva zona alojada.
Si decide crear una zona alojada independiente para el subdominio de nivel inferior, cree el registro de NS para el subdominio de nivel inferior en la zona alojada del subdominio que se encuentre un nivel más cerca del nombre de dominio. Esto ayuda a garantizar que el tráfico se dirija correctamente a los recursos. Por ejemplo, suponga que desea dirigir el tráfico para los siguientes subdominios:
+ subdomain1.example.com
+ subdomain2.subdomain1.example.com
Para utilizar otra zona alojada para dirigir el tráfico de subdomain2.subdomain1.example.com, debe hacer lo siguiente:
1. Cree una zona alojada denominada subdomain2.subdomain1.example.com.
1. Cree registros en la zona alojada denominada subdomain2.subdomain1.example.com. Para obtener más información, consulte [Creación de registros en la zona alojada para el subdominio](#dns-routing-traffic-for-subdomains-creating-records).
1. Copie los nombres de los servidores de nombres para la zona alojada subdomain2.subdomain1.example.com.
1. En la zona alojada subdomain1.example.com, cree un registro NS llamado subdomain2.subdomain1.example.com y pegue los nombres de los servidores de nombres para la zona alojada subdomain2.subdomain1.example.com.
Además, elimine los registros duplicados de subdomain1.example.com. Para obtener más información, consulte [Actualización de la zona alojada para el dominio](#dns-routing-traffic-for-subdomains-delegating-responsibility).
Después de crear este registro NS, Route 53 comienza a utilizar la zona alojada subdomain2.subdomain1.example.com para dirigir el tráfico para el subdominio subdomain2.subdomain1.example.com.
# Uso de zonas alojadas
Una zona alojada es un contenedor de registros y los registros contienen información sobre cómo desea direccionar el tráfico hacia un dominio específico (como example.com) y sus subdominios (como acme.example.com, zenith.example.com). Una zona alojada y el dominio correspondiente tienen el mismo nombre. Existen dos tipos de zonas alojadas:
+ Las *zonas alojadas públicas* contienen registros que especifican cómo desea direccionar el tráfico en Internet. Para obtener más información, consulte [Trabajar con zonas públicas alojadas](AboutHZWorkingWith.md).
+ Las *zonas alojadas privadas* contienen registros que especifican cómo desea direccionar el tráfico en una VPC de Amazon. Para obtener más información, consulte [Uso de zonas alojadas privadas](hosted-zones-private.md).
# Trabajar con zonas públicas alojadas
Una zona alojada pública es un contenedor que incluye información sobre cómo desea direccionar el tráfico en Internet hacia un dominio específico (como example.com) y sus subdominios (como acme.example.com, zenith.example.com). Puede obtener una zona alojada pública de una de las dos formas siguientes:
+ Al registrar un dominio con Route 53, creamos automáticamente una zona alojada.
+ Al transferir el servicio DNS de un dominio existente a Route 53, comience con la creación de una zona alojada para el dominio. Para obtener más información, consulte [Establecer Amazon Route 53 como servicio DNS de un dominio existenteEstablecer Route 53 como servicio DNS de un dominio existente](MigratingDNS.md).
En ambos casos, cree registros en la zona alojada para especificar cómo desea dirigir el tráfico del dominio y los subdominios. Por ejemplo, puede crear un registro para enrutar el tráfico de www.example.com a una CloudFront distribución o a un servidor web de su centro de datos. Para obtener más información acerca de los registros, consulte [Uso de registros](rrsets-working-with.md).
En este tema se explica cómo utilizar la consola de Amazon Route 53 para crear, enumerar y eliminar las zonas alojadas públicas.
**nota**
También puede usar una zona alojada *privada* de Route 53 para enrutar el tráfico dentro de una o varias VPCs que cree con el servicio Amazon VPC. Para obtener más información, consulte [Uso de zonas alojadas privadas](hosted-zones-private.md).
**Topics**
+ [Consideraciones sobre el uso de zonas alojadas públicas](hosted-zone-public-considerations.md)
+ [Crear una zona alojada pública](CreatingHostedZone.md)
+ [Obtener los servidores de nombres para una zona alojada pública](GetInfoAboutHostedZone.md)
+ [Enumeración de zonas alojadas públicas](ListInfoOnHostedZone.md)
+ [Visualización de métricas de consultas de DNS para una zona alojada pública](hosted-zone-public-viewing-query-metrics.md)
+ [Eliminación de una zona alojadas pública](DeleteHostedZone.md)
+ [Comprobación de las respuestas de DNS de Route 53](dns-test.md)
+ [Configuración de servidores de nombres de etiqueta blanca](white-label-name-servers.md)
+ [Registros SOA y NS que crea Amazon Route 53 para una zona alojada pública](SOA-NSrecords.md)
+ [Permite una recuperación acelerada para administrar los registros DNS públicos](accelerated-recovery.md)
# Consideraciones sobre el uso de zonas alojadas públicas
Tenga en cuenta las siguientes consideraciones al trabajar con zonas alojadas públicas:
**Registros NS y SOA**
Cuando crea una zona alojada, Amazon Route 53 genera automáticamente un registro del servidor de nombres (NS) y un registro de inicio de autoridad (SOA) para dicha zona. El registro NS identifica los cuatro servidores de nombres que se proporcionan al registrador o al servicio DNS para que las consultas de DNS se redirijan a los servidores de nombres de Route 53. Para obtener más información acerca de los registros NS y SOA, consulte [Registros SOA y NS que crea Amazon Route 53 para una zona alojada pública](SOA-NSrecords.md).
**Varias zonas alojadas que tienen el mismo nombre**
Puede crear más de una zona alojada que tenga el mismo nombre y agregar diferentes registros para cada zona alojada. Route 53 asigna cuatro servidores de nombres a cada zona alojada, diferentes para cada una de ellas. Al actualizar los registros del servidor de nombres de su registrador, asegúrese de utilizar los servidores de nombres de Route 53 para la zona alojada correcta (es decir, la que contiene los registros que desea que utilice Route 53 al responder a las consultas del dominio). Route 53 nunca devuelve valores de registros de otras zonas alojadas que tengan el mismo nombre.
**Conjuntos de delegación reutilizables**
De forma predeterminada, Route 53 asigna un conjunto único de cuatro servidores de nombres (conocido colectivamente como un conjunto de delegación) para cada zona alojada creada. Si desea crear un número elevado de zonas alojadas, puede crear un conjunto de delegación reutilizable mediante programación. (Los conjuntos de delegación reutilizables no están disponibles en la consola de Route 53). A continuación, puede crear zonas alojadas mediante programación y asignar el mismo conjunto de delegaciones reutilizable (los mismos cuatro servidores de nombres) a cada zona alojada.
Los conjuntos de delegación reutilizables simplifican la migración del servicio DNS a Route 53, ya que puede indicar a su registrador de nombres de dominio que use los mismos cuatro servidores de nombres para todos los dominios para los que desea usar Route 53 como el servicio DNS. Para obtener más información, consulte [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)la *referencia de la API de Amazon Route 53*.
# Crear una zona alojada pública
Una zona alojada pública es un contenedor que incluye información sobre cómo desea dirigir el tráfico en Internet hacia un dominio específico (como example.com) y sus subdominios (como acme.example.com, zenith.example.com). Después de crear una zona alojada, cree registros que especifiquen cómo desea dirigir el tráfico del dominio y los subdominios.
**Restricciones**
Tenga en cuenta las siguientes restricciones para crear zonas alojadas con Route 53.
Puede crear una zona alojada solo para los dominios para los que tenga permiso para administrar. Por lo general, esto indicará que es el propietario del dominio, aunque también podría estar desarrollando una aplicación para el registrador del dominio.
Solo puede crear zonas alojadas para dominios y subdominios. Route 53 no admite el alojamiento de dominios de nivel superior (TLD), como `.com`.
**Para crear una zona alojada pública a través de la consola de Route 53**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Si es la primera vez que utiliza Route 53, seleccione **Get started** (Introducción) en **DNS management** (Administración de DNS).
Si ya trabaja con Route 53, seleccione **Hosted zones** (Zonas alojadas) en el panel de navegación.
1. Elija **Create hosted zone** (Crear zona alojada).
1. En el panel **Create Hosted Zone** (Crear zona alojada) escriba el nombre del dominio cuyo tráfico desea dirigir. Si lo desea, también puede escribir un comentario.
Para obtener información sobre cómo especificar caracteres distintos de a-z, 0-9 y - (guion), y cómo especificar nombres de dominio internacionalizados, consulte [Formato de nombres de dominio DNS](DomainNameFormat.md).
1. En **Type** acepte el valor predeterminado de **Public Hosted Zone**.
1. Elija **Create** (Crear).
1. Cree registros que especifiquen cómo desea dirigir el tráfico del dominio y los subdominios. Para obtener más información, consulte [Uso de registros](rrsets-working-with.md).
1. Para utilizar los registros de la nueva zona alojada para dirigir el tráfico de su dominio, consulte el tema pertinente:
+ Si hace que Route 53 sea el servicio DNS de un dominio registrado en otro registrador de dominios, consulte [Establecer Amazon Route 53 como servicio DNS de un dominio existenteEstablecer Route 53 como servicio DNS de un dominio existente](MigratingDNS.md).
+ Si el dominio está registrado en Route 53, consulte [Adición o modificación de servidores de nombres y registros de conexión de un dominio](domain-name-servers-glue-records.md).
# Obtener los servidores de nombres para una zona alojada pública
Obtendrá los servidores de los nombres de una zona alojada pública si quiere cambiar el servicio DNS del registro de su dominio. Para obtener información acerca de cómo cambiar el servicio DNS, consulte [Establecer Amazon Route 53 como servicio DNS de un dominio existenteEstablecer Route 53 como servicio DNS de un dominio existente](MigratingDNS.md).
**nota**
Algunos registradores solo permiten especificar servidores de nombres a través de direcciones IP; no permiten especificar nombres de dominio completos. Si su registrador requiere el uso de direcciones IP, puede obtener las direcciones IP de sus servidores de nombres mediante la herramienta dig (para Mac, Unix o Linux) o la herramienta nslookup (para Windows). No solemos cambiar las direcciones IP de los servidores de nombres; si tenemos que cambiar las direcciones IP, se lo notificaremos por adelantado.
**Para obtener los servidores de nombres de una zona alojada a través de la consola de Route 53**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, haga clic en **Hosted zones** (Zonas alojadas).
1. En la página **Hosted zones** (Zonas alojadas), elija el botón de radio (no el nombre) de la zona alojada y luego **View details** (Ver detalles).
1. En la página de detalles de la zona alojada, elija **Hosted zone details** (Detalles de la zona alojada).
1. Anote los nombres de los cuatro servidores que aparecen en **Name servers** (Servidores de nombres).
# Enumeración de zonas alojadas públicas
Puede usar la consola de Amazon Route 53 para enumerar todas las zonas alojadas que creó con la AWS cuenta actual. Para obtener información sobre cómo enumerar las zonas alojadas mediante la API de Route 53, consulte [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)la *referencia de la API de Amazon Route 53*.
**Para ver una lista de las zonas alojadas públicas asociadas a una AWS cuenta mediante la consola de Route 53**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas**. La página muestra una lista de las zonas alojadas que están asociadas a la AWS cuenta con la que ha iniciado sesión actualmente.
1. Para filtrar las zonas alojadas, utilice la barra de búsqueda situada en la parte superior de la tabla.
El comportamiento de búsqueda depende de si la zona alojada contiene hasta 2000 registros o más de 2000 registros:
**Hasta 2000 zonas alojadas**
+ Para visualizar los registros que tengan valores específicos, haga clic en la barra de búsqueda, elija una propiedad en la lista desplegable e ingrese un valor. También puede ingresar un valor directamente en la barra de búsqueda y pulsar Entrar. Por ejemplo, para mostrar las zonas alojadas que tienen un nombre que comience por **abc**, ingrese ese valor en la barra de búsqueda y pulse Entrar.
+ Para visualizar solo las zonas alojadas que tengan el mismo tipo de zona alojada, seleccione el tipo en la lista desplegable e ingrese el tipo.
**Más de 2000 zonas alojadas**
+ Puede buscar propiedades basadas en el nombre de dominio exacto, todas las propiedades y el tipo.
+ Busque con el nombre de dominio exacto para obtener resultados de búsqueda más rápidos.
# Visualización de métricas de consultas de DNS para una zona alojada pública
Puede ver el número total de consultas de DNS a las que responde Route 53 para una zona alojada pública especificada o una combinación de zonas alojadas públicas. Las métricas aparecen en CloudWatch, lo que te permite ver un gráfico, elegir el período de tiempo que quieres ver y personalizar las métricas de muchas otras formas. También puede crear alarmas y configurar notificaciones para recibir una notificación cuando el número de consultas de DNS de un periodo de tiempo especificado quede por encima o por debajo de un nivel especificado.
**nota**
Route 53 envía automáticamente el número de consultas de DNS a CloudWatch todas las zonas alojadas públicas, por lo que no es necesario configurar nada para poder ver las métricas de las consultas. No se aplican cargos por las métricas de consulta de DNS.
**¿Qué consultas de DNS se cuentan?**
Las métricas incluyen solo las consultas que los solucionadores de DNS reenvíen a Route 53. Si un solucionador de DNS ya ha almacenado en caché la respuesta a una consulta (por ejemplo, la dirección IP de un balanceador de carga para example.com), el solucionador continuará devolviendo la respuesta almacenada en caché sin reenviar la consulta a Route 53 hasta que venza el TTL del registro correspondiente.
Dependiendo de la cantidad de las consultas de DNS que se envíen para un nombre de dominio (example.com) o nombre de subdominio (www.example.com), cuyos solucionadores están utilizando sus usuarios y el TTL para el registro, las métricas de consulta de DNS pueden contener información sobre una única consulta de cada varios miles de consultas que se enviaron a los solucionadores de DNS. Para obtener más información sobre cómo funciona DNS, consulte [Cómo dirige Amazon Route 53 el tráfico de su dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
**¿Cuándo empiezan a aparecer las métricas de consultas de una zona alojada en CloudWatch?**
Después de crear una zona alojada, transcurren hasta varias horas antes de que la zona alojada aparezca en CloudWatch. Además, debe enviar una consulta de DNS de un registro de la zona alojada para que haya datos que mostrar.
**Las métricas solo están disponibles en EE. UU. Este (Norte de Virginia)**
Para obtener métricas en la consola, debe especificar EE. UU. Este (Norte de Virginia) para la región. Para obtener métricas mediante la AWS CLI, debe dejar la AWS región sin especificar o especificarla `us-east-1` como región. Las métricas de Route 53 no están disponibles si elige otra región.
**CloudWatch métrica y dimensión para las consultas de DNS**
Para obtener información sobre la CloudWatch métrica y la dimensión de las consultas de DNS, consulte[Supervisión de zonas alojadas mediante Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). Para obtener información sobre CloudWatch las métricas, consulta [Uso de CloudWatch las métricas de Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) en la *Guía del CloudWatch usuario de Amazon*.
**Obtención de datos más detallados sobre las consultas de DNS**
Para obtener información más detallada acerca de cada consulta de DNS a la que responde Route 53, incluidos los siguientes valores, puede configurar el registro de consultas:
+ Dominio o subdominio que se solicitó
+ La fecha y la hora de la solicitud
+ El tipo de registro de DNS (por ejemplo, A o AAAA)
+ La ubicación periférica de Route 53 que ha respondido a la consulta de DNS
+ El código de respuesta de DNS como, por ejemplo, `NoError` o `ServFail`
Para obtener más información, consulte [Registro de consultas de DNS públicas](query-logs.md).
**Cómo obtener métricas de consulta de DNS**
Poco después de crear una zona alojada, Amazon Route 53 comienza a enviar métricas y dimensiones una vez por minuto a CloudWatch. Puede usar los siguientes procedimientos para ver las métricas en la CloudWatch consola o verlas mediante AWS Command Line Interface (AWS CLI).
**Topics**
+ [Ver las métricas de consultas de DNS de una zona alojada pública en la CloudWatch consola](#hosted-zone-public-viewing-query-metrics-console)
+ [Obtener métricas de consultas de DNS mediante AWS CLI](#hosted-zone-public-viewing-query-metrics-cli)
## Ver las métricas de consultas de DNS de una zona alojada pública en la CloudWatch consola
Para ver las métricas de consultas de DNS de las zonas alojadas públicas en la CloudWatch consola, lleve a cabo el siguiente procedimiento.
**Para ver las métricas de consultas de DNS de una zona alojada pública en la CloudWatch consola**
1. Inicie sesión en Consola de administración de AWS y abra la CloudWatch consola en [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. En el panel de navegación, seleccione **Métricas**.
1. En la lista de AWS regiones de la esquina superior derecha de la consola, selecciona **EE.UU. Este (Norte de Virginia)**. Las métricas de Route 53 no están disponibles si eliges otra AWS región.
1. En la pestaña **All metrics**, elija **Route 53**.
1. Elija **Hosted Zone Metrics (Métricas de zona alojada)**.
1. Selecciona la casilla de verificación de una o más zonas alojadas que tengan el nombre de la métrica **DNSQueries**.
1. En la pestaña **Graphed metrics (Métricas incluidas en el gráfico)** cambie los valores aplicables para ver las métricas en el formato que desee.
En **Estadística**, elija **Suma** o **SampleCount**; ambas estadísticas muestran el mismo valor.
## Obtener métricas de consultas de DNS mediante AWS CLI
Para obtener las métricas de consultas de DNS mediante el AWS CLI, utilice el [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html)comando. Tenga en cuenta lo siguiente:
+ La mayoría de los valores del comando se especifican en un archivo JSON independiente. Para obtener más información, consulte [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html).
+ El comando devuelve un valor para cada intervalo que especifique para `Period` en el archivo JSON. `Period` está en segundos, por lo que si especifica un periodo de tiempo de cinco minutos y especifica `60` para `Period`, obtendrá cinco valores. Si especifica un periodo de cinco minutos y especifica `300` en `Period`, obtendrá un valor.
+ En el archivo JSON, puede especificar cualquier valor para `Id`.
+ Deje la AWS región sin especificar o especifíquela `us-east-1` como región. Las métricas de Route 53 no están disponibles si elige otra región. Para obtener más información, consulte [Configuración de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) en la *Guía del AWS Command Line Interface usuario*.
Este es el AWS CLI comando que se utiliza para obtener las métricas de las consultas de DNS correspondientes al período de cinco minutos comprendido entre las 4:01 y las 4:07 del 1 de mayo de 2019. El parámetro `metric-data-queries` hace referencia al archivo JSON de ejemplo que sigue al comando.
```
aws cloudwatch get-metric-data --metric-data-queries file://./metric.json --start-time 2019-05-01T04:01:00Z --end-time 2019-05-01T04:07:00Z
```
A continuación se muestra el archivo JSON de ejemplo:
```
[
{
"Id": "my_dns_queries_id",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Route53",
"MetricName": "DNSQueries",
"Dimensions": [
{
"Name": "HostedZoneId",
"Value": "Z1D633PJN98FT9"
}
]
},
"Period": 60,
"Stat": "Sum"
},
"ReturnData": true
}
]
```
Esta es la salida de este comando. Tenga en cuenta lo siguiente:
+ La hora de inicio y la hora de finalización del comando abarcan un periodo de tiempo de siete minutos, de `2019-05-01T04:01:00Z` a `2019-05-01T04:07:00Z`.
+ Solo hay seis valores devueltos. No hay ningún valor para `2019-05-01T04:05:00Z` porque no había consultas de DNS durante ese minuto.
+ El valor de `Period` especificado en el archivo JSON es `60` (segundos), por lo que los valores se notifican en intervalos de un minuto.
```
{
"MetricDataResults": [
{
"Id": "my_dns_queries_id",
"StatusCode": "Complete",
"Label": "DNSQueries",
"Values": [
101.0,
115.0,
103.0,
127.0,
111.0,
120.0
],
"Timestamps": [
"2019-05-01T04:07:00Z",
"2019-05-01T04:06:00Z",
"2019-05-01T04:04:00Z",
"2019-05-01T04:03:00Z",
"2019-05-01T04:02:00Z",
"2019-05-01T04:01:00Z"
]
}
]
}
```
# Eliminación de una zona alojadas pública
En esta sección, se explica cómo eliminar una zona alojada pública con la consola de Amazon Route 53.
Solamente puede eliminar una zona alojada si los únicos registros son los registros SOA y NS predeterminados. Si su zona alojada contiene otros registros, debe eliminarlos para poder eliminar su zona alojada. Esto le impide eliminar accidentalmente una zona alojada que siga conteniendo registros.
**Topics**
+ [Cómo evitar que el tráfico se dirija a su dominio](#delete-public-hosted-zone-stop-routing)
+ [Eliminación de zonas alojadas públicas creadas por otro servicio](#delete-public-hosted-zone-created-by-another-service)
+ [Elimine una zona alojada pública mediante la consola de Route 53.](#delete-public-hosted-zone-procedure)
## Cómo evitar que el tráfico se dirija a su dominio
Si desea conservar el registro del dominio pero desea detener el enrutamiento del tráfico de Internet a su sitio web o aplicación web, le recomendamos que elimine *registros* en la zona alojada en lugar de eliminar la zona alojada.
**importante**
La eliminación de una zona alojada es una acción que no se puede deshacer. Debe crear una nueva zona alojada y actualizar los servidores de nombres de su registro de dominio, proceso que puede requerir hasta 48 horas en surtir efecto. Además, si elimina una zona alojada, alguien podría piratear el dominio y dirigir el tráfico a sus propios recursos utilizando su nombre de dominio.
Si ha delegado la responsabilidad de un subdominio a una zona alojada y desea eliminar la zona alojada secundaria, también debe actualizar la zona alojada principal eliminando el registro de NS que tiene el mismo nombre que la zona alojada secundaria. Por ejemplo, si desea eliminar la zona alojada acme.example.com, también debe eliminar el registro de NS acme.example.com en la zona alojada example.com. Se recomienda eliminar primero el registro de NS y esperar a que transcurra el tiempo del TTL en el registro de NS antes de eliminar la zona alojada secundaria. Esto garantiza que no se pueda piratear la zona alojada secundaria durante el período en el que los solucionadores de DNS todavía tengan los servidores de nombres para la zona alojada secundaria en caché.
Si desea evitar la tarifa mensual correspondiente a la zona alojada, puede transferir el servicio de DNS del dominio a un servicio de DNS gratuito. Cuando transfiere el servicio de DNS, debe actualizar los servidores de nombres del registro de dominio. Si el dominio está registrado en Route 53, consulte [Adición o modificación de servidores de nombres y registros de conexión de un dominio](domain-name-servers-glue-records.md) para obtener información sobre cómo sustituir los servidores de nombres de Route 53 por los servidores de nombres del nuevo servicio DNS. Si el dominio está registrado en otro registrador, utilice el método proporcionado por el registrador para actualizar los servidores de nombres del registro de dominio. Para obtener más información, busque en Internet “servicio DNS gratis”.
## Eliminación de zonas alojadas públicas creadas por otro servicio
Si otro servicio ha creado una zona alojada, no puede eliminarla con la consola de Route 53. En su lugar, ha de utilizar el proceso correspondiente del otro servicio:
+ **AWS Cloud Map**— Para eliminar una zona alojada que se AWS Cloud Map creó al crear un espacio de nombres DNS público, elimine el espacio de nombres. AWS Cloud Map elimina la zona alojada automáticamente. Para obtener más información, consulte [Eliminación de espacios de nombres](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) en la *AWS Cloud Map Guía para desarrolladores de *.
+ **Descubrimiento de servicios de Amazon Elastic Container Service (Amazon ECS)**: para eliminar una zona alojada pública que Amazon ECS creó al crear un servicio mediante la detección de servicios, elimine los servicios de Amazon ECS que utilizan el espacio de nombres y elimine el espacio de nombres. Para obtener más información, consulte [Eliminación de un servicio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) en la *Guía para desarrolladores de Amazon Elastic Container Service*.
## Elimine una zona alojada pública mediante la consola de Route 53.
Para utilizar la consola de Route 53 para eliminar una zona alojada pública, realice el siguiente procedimiento.
**Elimine una zona alojada pública mediante la consola de Route 53.**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Hosted zones** (Zonas alojadas) y elija el enlace resaltado de la zona alojada que quiera eliminar.
1. Confirme que la zona alojada que desea eliminar solo contiene un registro NS y SOA. Si contiene registros adicionales, elimínelos: También tendrá que desactivar la firma de DNNSSEC:
**nota**
Si intenta eliminar la zona alojada sin cumplir estos requisitos, Route 53 arrojará un error:
Si la firma de DNSSEC está activada: la zona alojada especificada contiene claves de firma de claves de DNSSEC y, por lo tanto, no se puede eliminar.
Si existen otros conjuntos de registros de recursos (distintos de los registros SOA y NS predeterminados): la zona alojada especificada contiene conjuntos de registros de recursos no obligatorios y, por lo tanto, no se puede eliminar.
1. En la lista **Records** (Registros) de la página de detalles de la zona alojada, si la lista de registros incluye registros cuyo valor para la columna **Type** (Tipo) es distinto de NS o SOA, elija la fila y, a continuación, elija **Delete** (Eliminar).
Para seleccionar varios registros s consecutivos, elija la primera fila, mantenga presionada la tecla **Mayús** y elija la última fila. Para seleccionar varios registros no consecutivos, elija la primera fila, mantenga presionada la tecla **Ctrl** y elija las filas restantes.
**nota**
Si ha creado cualquier registro NS para subdominios en la zona alojada, elimine también esos registros.
1. Regrese a la página **Hosted zones** (Zonas alojadas) y elija la fila de la zona alojada que desea eliminar.
1. Elija **Eliminar**.
1. Escriba la clave de confirmación y elija **Delete** (Eliminar).
1. Si desea hacer que el dominio no esté disponible en Internet, le recomendamos que transfiera el servicio DNS a un servicio DNS gratuito y, a continuación, eliminar la zona alojada de Route 53. Esto evita que las futuras consultas DNS puedan dirigirse erróneamente.
Si el dominio está registrado en Route 53, consulte [Adición o modificación de servidores de nombres y registros de conexión de un dominio](domain-name-servers-glue-records.md) para obtener información sobre cómo sustituir los servidores de nombres de Route 53 por los servidores de nombres del nuevo servicio DNS. Si el dominio está registrado en otro registrador, utilice el método proporcionado por el registrador para cambiar servidores de nombres en el dominio.
**nota**
Si desea eliminar una zona alojada para un subdominio (acme.example.com), no es necesario cambiar servidores de nombres del dominio (example.com).
# Comprobación de las respuestas de DNS de Route 53
Si ha creado una zona alojada de Amazon Route 53 para su dominio, puede utilizar la herramienta de comprobación de DNS de la consola para ver cómo responderá Route 53 a las consultas de DNS si configura su dominio para utilizar Route 53 como servicio DNS. Para los registros de geolocalización, geoproximidad y latencia, también puede simular las consultas desde una dirección IP concreta de un and/or cliente de resolución de DNS para averiguar qué respuesta devolvería Route 53.
**importante**
La herramienta no envía consultas al sistema de nombres de dominio, solo responde en función de la configuración de los registros de la zona alojada. La herramienta devuelve la misma información independientemente de si la zona alojada se está utilizando actualmente para dirigir el tráfico del dominio.
La herramienta de comprobación de DNS funciona solo para zonas alojadas públicas.
**nota**
La herramienta de comprobación de DNS muestra información similar a la que cabría esperar de la sección de respuestas del comando `dig`. Por lo tanto, si consulta los servidores de nombres de un subdominio que apuntan a los servidores de nombres principales, no se mostrará esta información.
**Topics**
+ [Uso de la herramienta de comprobación para ver cómo responde Amazon Route 53 a consultas de DNS](#dns-test-how-route-53-responds)
+ [Uso de la herramienta de comprobación para simular consultas desde direcciones IP específicas (solo para registros de geolocalización y latencia)](#dns-test-simulate-requests)
## Uso de la herramienta de comprobación para ver cómo responde Amazon Route 53 a consultas de DNS
Puede utilizar la herramienta para ver qué respuesta devuelve Amazon Route 53 a una consulta de DNS para un registro.
**Para usar la herramienta de comprobación y ver cómo responde Route 53 a consultas de DNS**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. En el panel de navegación, elija **Hosted Zones**.
1. En la página **Hosted Zones**, elija el nombre de una zona alojada nueva. La consola muestra la lista de registros de dicha zona alojada.
1. Para ir directamente a la página **Check response from Route 53** (Verificar respuesta de Route 53), elija **Test record** (Registro de prueba).
1. Especifique los siguientes valores:
+ El nombre del registro, excepto el nombre de la zona alojada. Por ejemplo, para comprobar **www.example.com**, ingrese **www**. Para comprobar **example.com**, deje el campo **Record name (Nombre de registro)** en blanco.
+ El tipo del registro que desea comprobar, como **A** o **CNAME**.
1. Elija **Get Response**.
1. La sección **Response returned by Route 53** incluye los siguientes valores:
**Código de respuesta de DNS**
Un código que indica si la consulta era válida o no. El código de respuesta más habitual es **NOERROR**, para indicar que la consulta era válida. Si la respuesta no es válida, Route 53 devuelve un código de respuesta que explica el motivo. Para obtener una lista de posibles códigos de respuesta, consulte [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) en el sitio web de IANA.
**Protocolo**
El protocolo que Amazon Route 53 utilizó para responder a la consulta, **UDP** o **TCP**.
**Respuesta devuelta por Route 53**
El valor que devolvería Route 53 a una aplicación web. Puede ser uno de los siguientes:
+ Para los registros sin alias, la respuesta contiene el valor o los valores del registro.
+ Para varios registros que tengan el mismo nombre y tipo, que incluyan ponderación, geolocalización, latencia y conmutación por error, la respuesta contiene el valor del registro adecuado, en función de la solicitud.
+ En el caso de los registros de alias que hacen referencia a AWS recursos distintos de otro registro, la respuesta contiene una dirección IP o un nombre de dominio para el AWS recurso, según el tipo de recurso.
+ Para registros de alias que hacen referencia a otros registros, la respuesta contiene el valor o los valores del registro al que se hace referencia.
## Uso de la herramienta de comprobación para simular consultas desde direcciones IP específicas (solo para registros de geolocalización y latencia)
Si ha creado registros de latencia o de geolocalización, puede utilizar la herramienta de comprobación para simular consultas desde la dirección IP para un solucionador de DNS y un cliente.
**Para utilizar la herramienta de comprobación para simular consultas desde direcciones IP específicas**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Hosted Zones**.
1. En la página **Hosted Zones**, elija el nombre de una zona alojada nueva. La consola muestra la lista de registros de dicha zona alojada.
1. Para ir directamente a la página **Check response from Route 53**, elija **Test record set**.
Para ir a la página **Check response from Route 53** (Comprobar respuesta de Route 53) de un registro específico, seleccione la casilla para ese registro y elija **Test record set** (Probar conjunto de registros).
1. Si elige **Test record set (Probar conjunto de registros)** sin seleccionar antes un registro, especifique los siguientes valores:
+ El nombre del registro, excepto el nombre de la zona alojada. Por ejemplo, para comprobar **www.example.com**, ingrese **www**. Para comprobar **example.com**, deje el campo **Record name (Nombre de registro)** en blanco.
+ El tipo del registro que desea comprobar, como **A** o **CNAME**.
1. Especifique los valores aplicables:
**Dirección IP de solucionador**
Especifique una IPv6 dirección IPv4 o para simular la ubicación del solucionador de DNS que utiliza un cliente para realizar las solicitudes. Esto resulta útil para comprobar los registros de latencia y geolocalización. Si omite este valor, la herramienta utilizará la dirección IP de un solucionador de DNS de la región AWS EE.UU. Este (Virginia del Norte) (us-east-1).
**EDNS0 IP de subred del cliente**
Si el solucionador lo admite EDNS0, introduzca la IP de la subred del cliente para una dirección IP en la ubicación geográfica correspondiente, por ejemplo, **192.0.2.0** o **2001:db 8:85** a3: :8a2e: 370:7334.
**Máscara de subred**
Si especifica una dirección IP para la IP de la **subred del EDNS0 cliente, si lo desea, puede especificar el número de bits de la dirección IP** que desea que la herramienta de comprobación incluya en la consulta de DNS. **Por ejemplo, si especifica **192.0.2.44** para la **IP de la subred del EDNS0 cliente y **24** para la máscara de subred****, la herramienta de comprobación simulará** una consulta desde 192.0.2.0/24.** El valor predeterminado es 24 bits para las direcciones y 64 bits para las direcciones. IPv4 IPv6
1. Elija **Get Response**.
1. La sección **Response returned by Route 53** incluye los siguientes valores:
**Consulta de DNS enviada a Route 53**
La consulta, en [formato BIND](https://en.wikipedia.org/wiki/Zone_file), que la herramienta de comprobación envió a Route 53. Este es el mismo formato que usaría una aplicación web para enviar una consulta. Los tres valores suelen ser el nombre del registro, **IN** (es decir, Internet) y el tipo de registro.
**Código de respuesta de DNS**
Un código que indica si la consulta era válida o no. El código de respuesta más habitual es **NOERROR**, para indicar que la consulta era válida. Si la respuesta no es válida, Route 53 devuelve un código de respuesta que explica el motivo. Para obtener una lista de posibles códigos de respuesta, consulte [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) en el sitio web de IANA.
**Protocolo**
El protocolo que Amazon Route 53 utilizó para responder a la consulta, **UDP** o **TCP**.
**Respuesta devuelta por Route 53**
El valor que devolvería Route 53 a una aplicación web. Puede ser uno de los siguientes:
+ Para los registros sin alias, la respuesta contiene el valor o los valores del registro.
+ Para varios registros que tengan el mismo nombre y tipo, que incluyan ponderación, geolocalización, latencia y conmutación por error, la respuesta contiene el valor del registro adecuado, en función de la solicitud.
+ En el caso de los registros de alias que hacen referencia a AWS recursos distintos de otro registro, la respuesta contiene una dirección IP o un nombre de dominio para el AWS recurso, según el tipo de recurso.
+ Para registros de alias que hacen referencia a otros registros, la respuesta contiene el valor o los valores del registro al que se hace referencia.
# Configuración de servidores de nombres de etiqueta blanca
Cada zona alojada de Amazon Route 53 se asocia a cuatro servidores de nombres, conocidos colectivamente como conjunto de delegación. El nombre predeterminado de los servidores de nombres es similar a ns-2048.awsdns-64.com. Si desea que el nombre de dominio de sus servidores de nombres sea el mismo que el nombre de dominio de la zona alojada, por ejemplo, ns1.example.com, puede configurar servidores de nombres de etiqueta blanca, también conocidos como servidores de nombres personalizados o servidores de nombres privados.
Los siguientes pasos explican cómo configurar un conjunto de cuatro servidores de nombres de etiqueta blanca que puede reutilizar para varios dominios. Por ejemplo, suponga que posee los dominios example.com, example.org y example.net. Con este procedimiento, puede configurar servidores de nombres de etiqueta blanca para example.com y reutilizarlos con example.org y example.net.
**Topics**
+ [Paso 1: Crear un conjunto de delegación reutilizable de Route 53](#white-label-name-servers-create-reusable-delegation-set)
+ [Paso 2: Crear o volver a crear zonas alojadas de Amazon Route 53 y cambiar el TTL de los registros SOA y NS](#white-label-name-servers-create-hosted-zones)
+ [Paso 3: Volver a crear los registros para las zonas alojadas](#white-label-name-servers-create-resource-record-sets)
+ [Paso 4: Obtener direcciones IP](#white-label-name-servers-get-ip-addresses)
+ [Paso 5: Crear registros para servidores de nombres de etiqueta blanca](#white-label-name-servers-create-white-label-resource-record-sets)
+ [Paso 6: Actualizar los registros SOA y NS](#white-label-name-servers-update-ns-soa-records)
+ [Paso 7: Crear registros de adherencia y cambiar los servidores de nombres del registrador](#white-label-name-servers-create-glue-records)
+ [Paso 8: Monitorizar el tráfico para el sitio web o aplicación](#white-label-name-servers-monitor-traffic)
+ [Paso 9: TTLs Vuelva a sus valores originales](#white-label-name-servers-change-ttls-back)
+ [Paso 10: Ponerse en contacto con los servicios DNS recursivos (opcional)](#white-label-name-servers-contact-recursive-dns-services)
## Paso 1: Crear un conjunto de delegación reutilizable de Route 53
Los servidores de nombres de etiqueta blanca están asociados a un conjunto de delegación de Route 53 reutilizable. Puede usar servidores de nombres de marca blanca para una zona alojada solo si la zona alojada y el conjunto de delegación reutilizable los creó la misma AWS cuenta.
Para crear un conjunto de delegación reutilizable, puede usar la API de Route 53, la AWS CLI o una de las AWS SDKs. Para obtener más información, consulte la siguiente documentación sobre :
+ **API de Route 53**: consulte [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)la *referencia de la API de Amazon Route 53*
+ **AWS CLI**: consulte [create-reusable-delegation-set](https://docs.aws.amazon.com/cli/latest/reference/route53/create-reusable-delegation-set.html)en la *referencia de AWS CLI comandos*
+ **AWS SDKs**Consulte la documentación del SDK correspondiente en la página de [AWS documentación](https://docs.aws.amazon.com/)
## Paso 2: Crear o volver a crear zonas alojadas de Amazon Route 53 y cambiar el TTL de los registros SOA y NS
Cree o vuelva a crear las zonas alojadas de Amazon Route 53:
+ **Si no utiliza Route 53 como servicio DNS para los dominios en los que desea utilizar servidores de nombres de etiqueta blanca**: cree las zonas alojadas y especifique el conjunto de delegación reutilizable que creó en el paso anterior con cada zona alojada. Para obtener más información, consulte [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)la *referencia de la API de Amazon Route 53*.
+ **Si está utilizando Route 53 como servicio DNS para los dominios en los que desea utilizar servidores de nombres de marca blanca**: debe volver a crear las zonas alojadas en las que desea utilizar servidores de nombres de marca blanca y especificar el conjunto de delegación reutilizable que creó en el paso anterior para cada zona alojada.
**importante**
No puede cambiar los servidores de nombres que están asociados a una zona alojada existente. Puede asociar un conjunto de delegación reutilizable a una zona alojada solo cuando crea esta.
Al crear las zonas alojadas y antes de intentar acceder a los recursos de los dominios correspondientes, cambie los siguientes valores de TTL para cada zona alojada:
+ Cambie el valor del TTL para el registro NS para la zona alojada a 60 segundos o menos.
+ Cambie el valor del TTL mínimo para el registro de SOA para la zona alojada a 60 segundos o menos. Este es el último valor del registro de SOA.
Si por error proporciona a su registrador direcciones IP incorrectas para sus servidores de nombres de etiqueta blanca, su sitio web dejará de estar disponible y permanecerá así durante el período que dure el TTL después de corregir el problema. Al configurar un valor de TTL bajo, reduce el tiempo que su sitio web no está disponible.
Para obtener más información sobre la creación de zonas alojadas y la especificación de un conjunto de delegación reutilizable para los servidores de nombres de las zonas alojadas, consulte [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)la *referencia de la API de Amazon Route 53*.
## Paso 3: Volver a crear los registros para las zonas alojadas
Cree registros en las zonas alojadas que creó en el paso 2:
+ **Si está migrando un servicio DNS para sus dominios a Amazon Route 53**: es posible que pueda crear registros importando información sobre los registros existentes. Para obtener más información, consulte [Creación de registros mediante la importación de un archivo de zona](resource-record-sets-creating-import.md).
+ **Si está sustituyendo las zonas alojadas existentes para utilizar servidores de nombres de etiqueta blanca**: en las nuevas zonas alojadas, vuelva a crear los registros que aparecen en las zonas alojadas actuales. Route 53 no proporciona ningún método de exportación de registros desde una zona alojada, pero algunos proveedores externos sí lo hacen. A continuación, puede utilizar la característica de importación de Route 53 para importar registros sin alias cuya política de direccionamiento sea simple. No hay forma de exportar y reimportar registros de alias o registros cuya política de direccionamiento sea distinta de la simple.
Para obtener información sobre la creación de registros mediante la API de Route 53, consulte [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)la *referencia de la API de Amazon Route 53*. Para obtener información sobre cómo crear registros mediante la consola de Route 53, consulte [Uso de registros](rrsets-working-with.md).
## Paso 4: Obtener direcciones IP
Obtenga las IPv6 direcciones IPv4 y las direcciones de los servidores de nombres del conjunto de delegación reutilizable y complete la siguiente tabla.
****
| Nombre de un servidor de nombres en el conjunto de delegación reutilizable (ejemplo: ns-2048.awsdns-64.com) | IPv4 y IPv6 direcciones | Nombre que desea asignar al servidor de nombres de etiqueta blanca (por ejemplo: ns1.example.com) |
| --- | --- | --- |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
Por ejemplo, suponga que los cuatro servidores de nombres de su conjunto de delegación reutilizable son:
+ ns-2048.awsdns-64.com
+ ns-2049.awsdns-65.net
+ ns-2050.awsdns-66.org
+ ns-2051.awsdns-67.co.uk
Estos son los comandos de Linux y Windows que podría ejecutar a fin de obtener las direcciones IP para los primeros de los cuatro servidores de nombres:
**comandos dig para Linux**
```
% dig A ns-2048.awsdns-64.com +short
192.0.2.117
```
```
% dig AAAA ns-2048.awsdns-64.com +short
2001:db8:85a3::8a2e:370:7334
```
**comando nslookup para Windows**
```
c:\> nslookup ns-2048.awsdns-64.com
Non-authoritative answer:
Name: ns-2048.awsdns-64.com
Addresses: 2001:db8:85a3::8a2e:370:7334
192.0.2.117
```
## Paso 5: Crear registros para servidores de nombres de etiqueta blanca
En la zona alojada que tenga el mismo nombre (como example.com) que el nombre de dominio de los servidores de nombres de etiqueta blanca (como ns1.example.com), cree ocho registros:
+ Un registro A para cada servidor de nombres de etiqueta blanca
+ Un registro AAAA para cada servidor de nombres de etiqueta blanca
**importante**
Si utiliza los mismos servidores de nombres de etiqueta blanca para dos o más zonas alojadas, no ejecute este paso para las demás zonas alojadas.
Para cada registro, especifique los valores siguientes. Consulte la tabla que rellenó en el paso anterior:
**Política de direccionamiento**
Especifique **Simple routing** (Enrutamiento simple).
**Nombre del registro**
Nombre que desea asignar a uno de sus servidores de nombres de etiqueta blanca; por ejemplo, ns1.example.com. Para el prefijo (ns1 en este ejemplo), puede utilizar cualquier valor aceptable para un nombre de dominio.
**Valor/ruta de destino del tráfico**
La IPv6 dirección IPv4 o la dirección de uno de los servidores de nombres de Route 53 del conjunto de delegación reutilizable.
Si se equivocó al especificar las direcciones IP al crear los registros para sus servidores de nombres de etiqueta blanca, su sitio o aplicación web no estarán disponibles en Internet al realizar los pasos siguientes. Aunque corrija inmediatamente las direcciones IP, su sitio o aplicación web no estarán disponibles durante el tiempo que dure el TTL.
**Tipo de registro**
Especifique **A** cuando cree registros para las IPv4 direcciones.
Especifique **AAAA** al crear registros para las IPv6 direcciones.
**TTL (segundos)**
Este valor es la cantidad de tiempo que los solucionadores de DNS almacenan en caché la información de este registro antes de transmitir otra consulta de DNS a Route 53. Le recomendamos que especifique un valor inicial de 60 segundos o menos, para que pueda recuperarse rápidamente si especifica valores incorrectos en estos registros accidentalmente.
## Paso 6: Actualizar los registros SOA y NS
Actualice los registros SOA y NS en las zonas alojadas para las que desee utilizar servidores de nombres de etiqueta blanca. Realice los Pasos 6 a 8 para una zona alojada y el correspondiente dominio cada vez. Después, repita para otra zona alojada y dominio.
**importante**
Comience por la zona alojada de Amazon Route 53 que tenga el mismo nombre de dominio (como example.com) que los servidores de nombres de etiqueta blanca (como ns1.example.com).
1. Actualice el registro de SOA reemplazando el nombre del servidor de nombres de Route 53 por el nombre de uno de los servidores de nombres de etiqueta blanca
**Ejemplo**
Reemplazar el nombre del servidor de nombres de Route 53:
`ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 60`
por el nombre de uno de los servidores de nombres de etiqueta blanca:
`ns1.example.com. hostmaster.example.com. 1 7200 900 1209600 60`
**nota**
Ha cambiado el último valor, el tiempo mínimo de vida (TTL), en [Paso 2: Crear o volver a crear zonas alojadas de Amazon Route 53 y cambiar el TTL de los registros SOA y NS](#white-label-name-servers-create-hosted-zones).
Para obtener información sobre cómo actualizar registros mediante la consola de Route 53, consulte [Editar registros](resource-record-sets-editing.md).
1. En el registro NS, anote los nombres de los servidores de nombres actuales para el dominio, para que pueda volver a estos servidores de nombres si fuera necesario.
1. Actualizar el registro NS. Cambie el nombre de los servidores de nombres de Route 53 por los nombres de sus cuatro servidores de nombres de etiqueta blanca; por ejemplo, `ns1.example.com`, `ns2.example.com`, `ns3.example.com` y `ns4.example.com`.
## Paso 7: Crear registros de adherencia y cambiar los servidores de nombres del registrador
Utilice el método proporcionado por el registrador para crear registros de adherencia y cambiar los servidores de nombres del registrador:
1. Agregar registros de adherencia:
+ **Si está actualizando el dominio que tiene el mismo nombre de dominio que los servidores de nombres de etiqueta blanca**: Cree cuatro registros de adherencia para que los nombres y direcciones IP coincidan con los valores que ha obtenido en el paso 4. Incluya IPv4 tanto la dirección como la IPv6 dirección de un servidor de nombres de marca blanca en el registro adhesivo correspondiente, por ejemplo:
**ns1.example.com**: direcciones IP = 192.0.2.117 y 2001:db8:85a3::8a2e:370:7334
Los registradores utilizan una terminología variada para los registros de adherencia. Podría hacerse referencia a esto como registro de nuevos servidores de nombres o algo similar.
+ **Si está actualizando otro dominio**: en le caso de que Route 53 sea su servicio DNS, primero debe completar el paso indicado en la viñeta anterior y crear los registros de adherencia que coincidan con el nombre de dominio. A continuación, vaya al paso 2 en este procedimiento.
1. Cambie los servidores de nombres del dominio por los nombres de los servidores de nombres de etiqueta blanca.
Si utiliza Amazon Route 53 como servicio DNS, consulte [Adición o modificación de servidores de nombres y registros de conexión de un dominio](domain-name-servers-glue-records.md).
## Paso 8: Monitorizar el tráfico para el sitio web o aplicación
Supervise el tráfico para el sitio web o aplicación para los que ha creado registros de adherencia y ha cambiado los servidores de nombres en el paso 7:
+ **Si el tráfico se detiene**: utilice el método proporcionado por el registrador para devolver los servidores de nombres del dominio a los servidores de nombres de Route 53 anteriores. Se trata de los servidores de nombres que anotó en el paso 6b. A continuación, determine qué ha fallado.
+ **Si el tráfico no se ve afectado**: repita los pasos 6 a 8 para el resto de las zonas alojadas con las que desea utilizar los mismos servidores de nombres de etiqueta blanca.
## Paso 9: TTLs Vuelva a sus valores originales
Para todas las zonas alojadas que están utilizando ahora servidores de nombres de etiqueta blanca, cambie los siguientes valores:
+ Cambie el TTL para el registro NS de la zona alojada a un valor más habitual; por ejemplo, 172800 segundos (dos días).
+ Cambie el TTL mínimo para el registro de SOA de la zona alojada a un valor más normal; por ejemplo, 900 segundos. Este es el último valor del registro de SOA.
## Paso 10: Ponerse en contacto con los servicios DNS recursivos (opcional)
*Opcional* Si utiliza el enrutamiento de geolocalización de Amazon Route 53, póngase en contacto con los servicios de DNS recursivo que admiten la edns-client-subnet extensión de y EDNS0 asígneles los nombres de sus servidores de nombres de marca blanca. De este modo, se garantiza que estos servicios de DNS seguirán dirigiendo consultas de DNS a la ubicación óptima de Route 53 en función de la ubicación geográfica aproximada de la que provino la consulta.
# Registros SOA y NS que crea Amazon Route 53 para una zona alojada pública
Para cada zona alojada pública que se crea, Amazon Route 53 genera automáticamente un registro de servidor de nombres (NS) y un registro de inicio autoridad (SOA). Apenas necesita cambiar estos registros.
**Topics**
+ [El registro de servidor de nombres (NS)](#NSrecords)
+ [El registro de inicio de autoridad (SOA)](#SOArecords)
## El registro de servidor de nombres (NS)
Amazon Route 53 crea automáticamente un registro de servidor de nombres (NS) que tiene el mismo nombre que la zona alojada. Enumera los cuatro servidores de nombres que son los autorizados para su zona alojada. Excepto en raras circunstancias, le recomendamos que no añada, cambie o elimine servidores de nombres en este registro.
Los ejemplos siguientes muestran el formato para los nombres de servidores de nombres de Route 53 (son solo ejemplos; no los utilice cuando actualice los registros de servidor de nombres de su registrador):
+ *ns-2048.awsdns-64.com*
+ *ns-2049.awsdns-65.net*
+ *ns-2050.awsdns-66.org*
+ *ns-2051.awsdns-67.co.uk*
Para obtener la lista de los servidores de nombres para su zona alojada:
1. Inicie sesión en la consola de Route Consola de administración de AWS 53 y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. En el panel de navegación, haga clic en **Hosted zones** (Zonas alojadas).
1. En la página **Hosted zones** (Zonas alojadas), elija el botón de radio (no el nombre) de la zona alojada y luego **View details** (Ver detalles).
1. En la página de detalles de la zona alojada, elija **Hosted zone details** (Detalles de la zona alojada).
1. Anote los nombres de los cuatro servidores que aparecen en **Name servers** (Servidores de nombres).
Para obtener información acerca de cómo migrar el servicio DNS de otro proveedor de servicios DNS a Route 53, consulte [Establecer Amazon Route 53 como servicio DNS de un dominio existenteEstablecer Route 53 como servicio DNS de un dominio existente](MigratingDNS.md).
## El registro de inicio de autoridad (SOA)
El registro de inicio de autoridad (SOA) identifica la información de DNS básica sobre el dominio, por ejemplo:
```
1. ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 86400
```
Un registro de SOA incluye los siguientes elementos:
+ El servidor de nombres de Route 53 que creó el registro de SOA; por ejemplo, `ns-2048.awsdns-64.net`.
+ La dirección de correo electrónico del administrador. El símbolo `@` se sustituye por un punto; por ejemplo, `hostmaster.example.com`. El valor predeterminado es una dirección de correo electrónico amazon.com que no se supervisa.
+ Un número de serie que dispone de la opción de incremento siempre que se actualiza un registro en la zona alojada. Route 53 no incrementa el número de forma automática. (Los servicios DNS usan que admiten DNS secundario usan el número de serie). En este ejemplo, el valor es `1`.
+ El tiempo de actualización (en segundos) que los servidores DNS secundarios esperan antes de consultar el registro de SOA del servidor DNS primario y comprobar si hay cambios. En este ejemplo, el valor es `7200`.
+ El intervalo de reintento (en segundos) que un servidor secundario espera antes de reintentar una transferencia de zona errónea. Normalmente, el tiempo de reintento es inferior al de actualización. En este ejemplo, el valor es `900` (15 minutos).
+ El tiempo en segundos durante el cual un servidor secundario seguirá intentando completar una transferencia de zona. Si este tiempo finaliza antes de efectuar una transferencia de zona correcta, el servidor secundario dejará de responder a las consultas, ya que considera sus datos demasiado antiguos para ser de confianza. En este ejemplo el valor es `1209600` (dos semanas).
+ El tiempo mínimo de vida (TTL). Este valor permite definir el período de tiempo durante el que los solucionadores recursivos deben almacenar en caché las siguientes respuestas de Route 53:
**NXDOMAIN**
No hay ningún registro de ningún tipo con el nombre especificado en la consulta DNS; por ejemplo, ejemplo.com. Tampoco hay registros que sean elementos secundarios del nombre especificado en la consulta DNS; por ejemplo, zenith.ejemplo.com.
**NODATA**
Hay al menos un registro con el nombre especificado en la consulta DNS, pero ninguno de esos registros tiene el tipo especificado en la consulta DNS (por ejemplo, A).
Cuando un solucionador DNS almacena en caché una respuesta NXDOMAIN o NODATA, esto se denomina *almacenamiento en caché negativo*.
La duración del almacenamiento en caché negativo es el valor más bajo de los siguientes valores:
+ Este valor: el TTL mínimo del registro de SOA. En el ejemplo el valor es `86400` (un día).
+ Valor de TTL para el registro de SOA. El valor de predeterminado es de 900 segundos. Para obtener más información acerca de cómo cambiar este valor, consulte [Editar registros](resource-record-sets-editing.md).
Si Route 53 responde a las consulta de DNS con una respuesta NXDOMAIN o NODATA (una respuesta negativa), se le cobrará la tarifa de las consultas estándar. (Vea “Consultas” en [Precios de Amazon Route 53 ](https://aws.amazon.com/route53/pricing/)). Si le preocupa el coste de las respuestas negativas, una opción es cambiar el TTL del registro de SOA y el TTL mínimo del registro de SOA (este valor o ambos). Tenga en cuenta que aumentarlas TTLs, que se aplican a las respuestas negativas en toda la zona alojada, puede tener efectos tanto positivos como negativos:
+ Los solucionadores DNS de Internet almacenan en caché la inexistencia de registros durante períodos más largos, lo que reduce el número de consultas que se reenvían a Route 53. Esto reduce los gastos de Route 53 por las consulta de DNS.
+ Sin embargo, si alguna vez elimina por error un registro válido y posteriormente lo vuelve a crear, los solucionadores DNS almacenarán en caché la respuesta negativa (este registro no existe) durante un período más largo. Esto aumentará el tiempo que los clientes o usuarios no pueden acceder al recurso correspondiente; por ejemplo, un servidor web de acme.ejemplo.com.
**Para encontrar sus registros SOA en Route 53**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas**.
1. Seleccione el nombre vinculado del dominio para el que desea ver los registros.
1. En la sección **Records** (Registros) puede ver todos los registros enumerados y también puede filtrar registros para encontrar su valor SOA.
# Permite una recuperación acelerada para administrar los registros DNS públicos
La recuperación acelerada de Route 53 para administrar registros DNS públicos está diseñada para alcanzar un objetivo de tiempo de recuperación (RTO) de 60 minutos en caso de que el servicio no esté disponible en la región de EE. UU. Este (Virginia del Norte). Si está activado en una zona alojada pública de Route 53, podrá volver a realizar cambios en los registros de DNS de la zona alojada pública en aproximadamente 60 minutos después de AWS detectar que las operaciones en la región EE.UU. Este (Virginia del Norte) están alteradas.
**importante**
La recuperación acelerada solo está disponible para las zonas de alojamiento público. No se admiten las zonas alojadas privadas.
**nota**
La resolución de consultas de DNS desde el plano de datos de Route 53 sigue funcionando con normalidad durante el deterioro del servicio regional. Consulte [Resiliencia en Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/disaster-recovery-resiliency.html) para comprender mejor las operaciones del plano de datos en comparación con las del plano de control.
**Topics**
+ [Cómo funciona la recuperación acelerada de los registros DNS públicos](#accelerated-recovery-how-it-works)
+ [Volver a enviar los cambios de DNS tras la conmutación por error](#accelerated-recovery-resubmit)
+ [Vuelva a la región EE.UU. Este (Virginia del Norte)](#accelerated-recovery-failback)
+ [Consideraciones adicionales](#accelerated-recovery-considerations)
+ [¿Cómo habilitar la recuperación acelerada para administrar los registros DNS públicos](#accelerated-recovery-enable)
## Cómo funciona la recuperación acelerada de los registros DNS públicos
Cuando la recuperación acelerada esté habilitada, Route 53 conservará una copia de la zona alojada pública en la región EE.UU. Oeste (Oregón). Si los servicios de la región de EE. UU. Este (Virginia del Norte) dejan de estar disponibles durante un período prolongado, Route 53 ejecutará la conmutación por error en 60 minutos y redirigirá automáticamente las operaciones del plano de control de las zonas alojadas públicamente habilitadas para la recuperación acelerada a la región de EE. UU. Oeste (Oregón). A continuación, puede seguir realizando cambios en el DNS mediante programación mediante la CLI, el SDK y la API. Tenga en cuenta que estará disponible un conjunto limitado de métodos de API durante la conmutación por error. Consulte la sección «Consideraciones adicionales» para obtener más información. Cuando la región se recupere, la Ruta 53 ejecutará el procedimiento de recuperación por recuperación y redirigirá automáticamente las operaciones del avión de control a la región Este de EE. UU. (Virginia del Norte).
**nota**
Antes de que se produzca algún problema en la región EE.UU. Este (Virginia del Norte), primero debe activar la recuperación acelerada para administrar los registros DNS públicos en su zona de alojamiento público. Esto se puede hacer a través de la consola, la CLI, el SDK o la API (consulte la sección titulada *Cómo habilitar la recuperación acelerada para administrar registros DNS públicos* en esta página a continuación). No puede habilitar la recuperación acelerada para administrar los registros DNS públicos después de que se produzca una conmutación por error.
## Volver a enviar los cambios de DNS tras la conmutación por error
En condiciones normales, los cambios en las zonas de alojamiento público que tengan habilitada la recuperación acelerada serán aceptados en la región EE.UU. Este (Virginia del Norte) y, a continuación, se replicarán correctamente en la región EE.UU. Oeste (Oregón). Sin embargo, cuando se produce una interrupción del servicio en la región EE.UU. Este (Norte de Virginia), es posible que algunos cambios sean aceptados por la región EE.UU. Este (Virginia Norte), pero no replicables en la región EE.UU. Oeste (Oregón). Estos cambios durante el vuelo se denominan «cambios temporales». Una vez finalizada la conmutación por error, Route 53 recomienda volver a enviar los cambios pendientes antes de reanudar los flujos de trabajo de DNS. Puede lograrlo mediante la API o mediante AWS CloudFormation los métodos que se describen a continuación.
### Uso de la API para realizar un seguimiento de los cambios en el DNS y enviarlos
Si usa la API, la AWS CLI o AWS SDKs la administración de registros de DNS de Route 53, necesitará usar la [ChangeResourceRecordSets API y la [GetChange API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) para enviar y realizar un seguimiento de los cambios de DNS, respectivamente.
Cuando usa la ChangeResourceRecordSets API para realizar cambios en el DNS, Route 53 devuelve un identificador (ID) para el cambio realizado (consulte [ChangeInfo](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeInfo.html)los detalles del objeto de respuesta al cambio). Puede proporcionar este ID en una solicitud posterior a la GetChange API y observar el estado del cambio. Los cambios de DNS con el estado INSYNC se han replicado en la región EE.UU. Oeste (Oregón) y se han propagado a todos los servidores DNS de Route 53. No es necesario realizar ninguna otra acción en relación con estos cambios antes o después de una conmutación por error. Sin embargo, si el cambio se produce en la región EE. UU. Este (Virginia del Norte), GetChange puede volver a estar PENDIENTE, lo que indica que es posible que el cambio no se haya replicado en la región EE. UU. Oeste (Oregón). Si ese es el caso, cuando se complete la conmutación por error, GetChange volverá NoSuchChange, lo que indica que Route 53 no ha podido replicar este cambio de DNS. Por lo tanto, después de la conmutación por error, puede ignorar estos cambios de DNS inactivos y volver a enviarlos como nuevos cambios de DNS. Sabrá que el proceso de conmutación por error se ha completado cuando Route 53 publique un mensaje en el AWS Health Dashboard.
### Se utiliza AWS CloudFormation para realizar un seguimiento de los cambios y enviarlos
AWS CloudFormation Realiza un seguimiento automático del estado de replicación de los cambios de DNS mediante la GetChange API y solo completa una actualización una vez que los cambios de DNS se confirman como INSYNC. Si la utilizas CloudFormation para gestionar los registros de DNS y la región EE.UU. Este (Virginia del Norte) deja de estar disponible, las acciones que utilices no se CloudFormation completarán correctamente durante el período de no disponibilidad. Sin embargo, solo tiene que volver a intentar realizar las mismas acciones para volver a enviar los cambios de DNS, una vez que CloudFormation se complete el proceso de conmutación por error de Route 53.
## Vuelva a la región EE.UU. Este (Virginia del Norte)
Una vez que la región se recupere, la Ruta 53 suspenderá las operaciones del avión de control de su zona de acogida pública con destino a la región de EE. UU. Este (Virginia del Norte). Durante la recuperación, no tendrá que volver a enviar los cambios de DNS, ya que no se introducirán cambios innecesarios durante este proceso.
## Consideraciones adicionales
Hay algunas consideraciones adicionales que debes tener en cuenta en relación con la función de recuperación acelerada:
1. No podrá crear nuevas zonas alojadas, eliminar las zonas alojadas existentes, habilitar la firma de DNSSEC ni deshabilitar la firma de DNSSEC durante la conmutación por error.
1. AWS PrivateLink las conexiones no funcionarán después de una conmutación por error, pero volverán a funcionar después de una conmutación por recuperación a la región EE.UU. Este (Norte de Virginia).
1. CloudFront Por el momento, no se admiten [planes de tarifa fija](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html).
1. Las zonas alojadas con la recuperación acelerada habilitada no se pueden eliminar. Debe deshabilitar la recuperación acelerada antes de intentar eliminar la zona alojada.
1. Durante la conmutación por error, los siguientes métodos de API seguirán siendo compatibles en las zonas alojadas públicas con la recuperación acelerada habilitada. Sin embargo, los demás métodos de la API de Route 53 no funcionarán hasta que se produzca una conmutación por recuperación.
+ `ChangeResourceRecordSets`
+ `GetChange`
+ `GetGeoLocation`
+ `GetHostedZone`
+ `GetHostedZoneCount`
+ `GetHostedZoneLimit`
+ `GetReusableDelegationSet`
+ `GetReusableDelegationSetLimit`
+ `ListGeoLocations`
+ `ListHostedZones`
+ `ListHostedZonesByName`
+ `ListResourceRecordSets`
+ `ListReusableDelegationSets`
## ¿Cómo habilitar la recuperación acelerada para administrar los registros DNS públicos
Puede habilitar la recuperación acelerada para administrar los registros DNS públicos mediante la consola, la API, la CLI o el SDK de Route 53. El tiempo necesario para habilitar la recuperación acelerada dependerá del tamaño de la zona alojada pública y de otros factores. Debe planificar el proceso de habilitación de la recuperación acelerada para que tarde varias horas. Puede comprobar el estado del proceso de activación en la pestaña de recuperación acelerada de su zona alojada pública o mediante la `GetHostedZone` API. A medida que finalice el proceso, habrá un breve período de tiempo que durará varios minutos y en el que no se aceptarán los cambios de DNS. Una vez completados, los cambios de DNS pueden continuar con normalidad.
**Para habilitar y deshabilitar la recuperación acelerada mediante la consola Route 53**
1. Abra la consola de Route 53 en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas**.
1. Elija la zona alojada pública en la que desee habilitar la recuperación acelerada.
1. En la pestaña **Recuperación acelerada**, seleccione **Activar**.
1. Seleccione **Save changes (Guardar cambios)**.
1. Supervise el estado de la zona alojada. El estado muestra **Habilitar la recuperación acelerada** durante la configuración y cambia a **Habilitado** cuando se completa.
Puede deshabilitar la recuperación acelerada siguiendo los mismos pasos anteriores, pero en su lugar seleccionando **Desactivar**.
Ejemplo de CLI para habilitar
```
aws route53 update-hosted-zone-features --enable-accelerated-recovery --hosted-zone-id Z123456789
```
Ejemplo de CLI para deshabilitar
```
aws route53 update-hosted-zone-features --no-enable-accelerated-recovery --hosted-zone-id Z123456789
```
# Uso de zonas alojadas privadas
Una *zona alojada privada* es un contenedor que contiene información sobre cómo desea que Amazon Route 53 responda a las consultas de DNS de un dominio y sus subdominios dentro de uno o varios VPCs que cree con el servicio Amazon VPC. A continuación, se explica cómo funcionan las zonas alojadas privadas:
1. Se crea una zona alojada privada, como example.com, y se especifica la VPC que se desea asociar a la zona alojada. Después de crear la zona alojada, puede VPCs asociar más a ella.
1. Se crean registros en la zona alojada que determinan cómo responderá Route 53 a las consultas de DNS del dominio y los subdominios en las VPC y entre ellas. Por ejemplo, supongamos que tiene un servidor de base de datos que se ejecuta en una instancia de EC2 en la VPC que ha asociado a la zona alojada privada. Usted crea un registro A o AAAA, como db.example.com, y especifica la dirección IP del servidor de base de datos.
Para obtener más información acerca de los registros, consulte [Uso de registros](rrsets-working-with.md). Para obtener información acerca de los requisitos de Amazon VPC para usar zonas alojadas privadas, consulte [Uso de zonas alojadas privadas](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones) en la *Guía del usuario de Amazon VPC*.
1. Cuando una aplicación envía una consulta de DNS para db.example.com, Route 53 devuelve la dirección IP correspondiente. Para obtener una respuesta de una zona alojada privada, también debe ejecutar una instancia EC2 en una de las asociadas VPCs (o tener un punto final de entrada desde una configuración híbrida). Si intenta consultar una zona alojada privada desde fuera de la configuración VPCs o de la configuración híbrida, la consulta se resolverá de forma recursiva en Internet.
1. La aplicación utiliza la dirección IP que ha obtenido de Route 53 para establecer una conexión con el servidor de base de datos.
Al crear una zona alojada privada, se utilizan los siguientes servidores de nombres:
+ ns-0.awsdns-00.com
+ ns-512.awsdns-00.net
+ ns-1024.awsdns-00.org
+ ns-1536.awsdns-00.co.uk
Estos servidores de nombres se usan porque el protocolo DNS requiere que cada zona alojada tenga un conjunto de registros NS. Estos servidores de nombres están reservados y las zonas alojadas públicas de Route 53 nunca los utilizan. Solo puede consultar esas zonas a través de VPC Resolver en una VPC que se haya asociado a la zona alojada mediante un punto final de entrada conectado al VPCs especificado en la zona alojada privada.
Si bien los servidores de nombres están visibles en Internet, VPC Resolver no se conecta a las direcciones de los servidores de nombres. Además, la información de la zona alojada privada no se devuelve si consulta directamente los servidores de nombres a través de Internet. En cambio, el solucionador de VPC detecta que las consultas se encuentran dentro de un espacio de nombres privado basado en las asociaciones de VPC a zonas alojadas y utiliza conectividad privada y directa para llegar a los servidores DNS privados.
**nota**
Si lo desea, puede cambiar el conjunto de registros NS en una zona alojada privada y la resolución de DNS privada seguirá funcionando. No lo recomendamos, pero si elige hacerlo, debe usar nombres de dominio reservados que no sean usados por los servidores DNS públicos.
Si desea dirigir el tráfico de su dominio en Internet, utilice una zona alojada *pública* de Route 53. Para obtener más información, consulte [Trabajar con zonas públicas alojadas](AboutHZWorkingWith.md).
**Topics**
+ [Consideraciones sobre el uso de una zona alojada privada](hosted-zone-private-considerations.md)
+ [Creación de una zona alojada privada](hosted-zone-private-creating.md)
+ [Descripción de zonas alojadas privadas](hosted-zone-private-listing.md)
+ [Asociarse más a una zona VPCs alojada privada](hosted-zone-private-associate-vpcs.md)
+ [Asociar una Amazon VPC y una zona alojada privada que haya creado con cuentas diferentes AWS](hosted-zone-private-associate-vpcs-different-accounts.md)
+ [Desasociarse de una zona VPCs alojada privada](hosted-zone-private-disassociate-vpcs.md)
+ [Eliminar una zona alojada privada](hosted-zone-private-deleting.md)
+ [Permisos de VPC](hosted-zone-private-vpc-permissions.md)
# Consideraciones sobre el uso de una zona alojada privada
Al utilizar zonas alojadas privadas, tenga en cuenta las siguientes consideraciones.
+ [Amazon VPC settings](#hosted-zone-private-considerations-vpc-settings)
+ [Route 53 health checks](#hosted-zone-private-considerations-health-checks)
+ [Supported routing policies for records in a private hosted zone](#hosted-zone-private-considerations-routing-policies)
+ [Split-view DNS](#hosted-zone-private-considerations-split-view-dns)
+ [Public and private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-public-private-overlapping)
+ [Private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-private-overlapping)
+ [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules)
+ [Delegating responsibility for a subdomain](#hosted-zone-private-considerations-delegating-subdomain)
+ [Custom DNS servers](#hosted-zone-private-considerations-custom-dns)
+ [Required IAM permissions](#hosted-zone-private-considerations-required-permissions)
**Configuración de Amazon VPC**
Para utilizar las zonas alojadas privadas, debe definir la siguiente configuración de Amazon VPC en `true`:
+ `enableDnsHostnames`
+ `enableDnsSupport`
Para obtener más información, consulte [Ver y actualizar los atributos de DNS de su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html) en la *Guía del usuario de Amazon VPC*.
**Controles de estado de Route 53**
En una zona alojada privada, solo puede asociar comprobaciones de estado de Route 53 con registros de conmutación por error, de respuestas con varios valores, ponderados, de latencia, de geolocalización y de geoproximidad. Para obtener información acerca de cómo asociar las comprobaciones de estado a registros de conmutación por error, consulte [Configuración de la conmutación por error en una zona alojada privada](dns-failover-private-hosted-zones.md).
**Políticas de direccionamiento admitidas para registros de una zona alojada privada**
Puede utilizar las siguientes políticas de direccionamiento al crear registros de una zona alojada privada:
+ [Direccionamiento simple](routing-policy-simple.md)
+ [Enrutado de conmutación por error](routing-policy-failover.md)
+ [Direccionamiento de respuesta con varios valores](routing-policy-multivalue.md)
+ [Direccionamiento ponderado](routing-policy-weighted.md)
+ [Enrutado basado en latencia](routing-policy-latency.md)
+ [Enrutado de geolocalización](routing-policy-geo.md)
+ [Enrutamiento por geoproximidad](routing-policy-geoproximity.md)
No se admite la creación de registros en una zona alojada privada mediante otras políticas de direccionamiento.
**DNS de vista dividida**
Puede usar Route 53 para configurar split-view DNS, también conocido como split-horizon DNS. En el DNS de vista dividida, se utiliza el mismo nombre de dominio (example.com) para usos internos (accounting.example.com) y externos, tales como su sitio web público (www.example.com). Es posible que también desee utilizar el mismo nombre de subdominio de forma interna y externa, pero distribuir contenido distinto o requerir una autenticación diferente para los usuarios internos y externos.
Para configurar DNS de vista dividida, siga estos pasos:
1. Cree zonas alojadas públicas y privadas que tengan el mismo nombre. (El DNS de vista dividida sigue funcionando si utiliza otro servicio DNS para la zona alojada pública).
1. Asocia uno o más Amazon VPCs a la zona alojada privada. El solucionador de VPC de Route 53 usa la zona alojada privada para enrutar las consultas de DNS en la zona especificada. VPCs
1. Cree registros en cada zona alojada. Los registros de la zona alojada pública controlan cómo se enruta el tráfico de Internet y los registros de la zona alojada privada controlan cómo se enruta el tráfico en Amazon. VPCs
Si necesita realizar la resolución de nombres de sus cargas de trabajo de VPC y locales, puede usar Route 53 VPC Resolver. Para obtener más información, consulte [¿Qué es Route 53 VPC Resolver?](resolver.md).
**Zonas alojadas públicas y privadas que tienen espacios de nombres que se superponen**
Si tienes zonas alojadas públicas y privadas con espacios de nombres superpuestos, como example.com y accounting.example.com, VPC Resolver direcciona el tráfico en función de la coincidencia más específica. Cuando los usuarios inician sesión en una instancia EC2 de una Amazon VPC que usted ha asociado a la zona alojada privada, así es como Route 53 VPC Resolver gestiona las consultas de DNS:
1. El solucionador de VPC evalúa si el nombre de la zona alojada privada coincide con el nombre de dominio de la solicitud, como accounting.example.com. Una coincidencia se define como cualquiera de las siguientes:
+ Una coincidencia idéntica
+ El nombre de la zona alojada privada es un elemento principal del nombre de dominio de la solicitud. Por ejemplo, suponga que el nombre de dominio de la solicitud es el siguiente:
**seattle.accounting.example.com**
Las siguientes zonas alojadas coinciden porque son elementos principales de seattle.accounting.example.com:
+ **accounting.example.com**
+ **example.com**
Si no hay ninguna zona alojada privada que coincida, el Resolver de VPC reenvía la solicitud a un solucionador de DNS público y la solicitud se resuelve como una consulta de DNS normal.
1. Si hay un nombre de zona alojada privada que coincida con el nombre de dominio de la solicitud, en la zona alojada se busca un registro que coincida con el nombre de dominio y tipo de DNS de la solicitud, como un registro A para accounting.example.com.
**nota**
Si hay una zona alojada privada coincidente, pero no hay ningún registro que coincida con el nombre de dominio y el tipo de la solicitud, VPC Resolver no reenvía la solicitud a un solucionador de DNS público. En su lugar, devuelve NXDOMAIN (dominio no existente) al cliente.
**Zonas alojadas privadas que tienen espacios de nombres que se superponen**
Si tienes dos o más zonas alojadas privadas que tienen espacios de nombres superpuestos, como example.com y accounting.example.com, VPC Resolver direcciona el tráfico en función de la coincidencia más específica.
Si tiene una zona alojada privada (example.com) y una regla de resolución de VPC de Route 53 que enruta el tráfico a su red para el mismo nombre de dominio, la regla de resolución de VPC tiene prioridad. Consulte [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules).
Cuando los usuarios inician sesión en una instancia EC2 de una Amazon VPC que usted ha asociado a todas las zonas alojadas privadas, así es como VPC Resolver gestiona las consultas de DNS:
1. El solucionador de VPC evalúa si el nombre de dominio de la solicitud, como accounting.example.com, coincide con el nombre de una de las zonas alojadas privadas.
1. Si no hay ninguna zona alojada que coincida exactamente con el nombre de dominio de la solicitud, el Resolver de VPC busca una zona alojada que tenga un nombre que sea el principal del nombre de dominio de la solicitud. Por ejemplo, suponga que el nombre de dominio de la solicitud es el siguiente:
`seattle.accounting.example.com`
Las siguientes zonas alojadas coinciden porque son elementos principales de `seattle.accounting.example.com`:
+ `accounting.example.com`
+ `example.com`
VPC Resolver elige `accounting.example.com` porque es más específico que. `example.com`
1. El solucionador de VPC busca en la zona `accounting.example.com` alojada un registro que coincida con el nombre de dominio y el tipo de DNS de la solicitud, como un registro A de. `seattle.accounting.example.com`
Si no hay ningún registro que coincida con el nombre de dominio y el tipo de la solicitud, VPC Resolver devuelve NXDOMAIN (dominio inexistente) al cliente.
**Zonas alojadas privadas y reglas de resolución de VPC de Route 53**
Si tiene una zona alojada privada (example.com) y una regla de resolución de VPC que enruta el tráfico a su red para el mismo nombre de dominio, la regla de resolución de VPC tiene prioridad.
Supongamos que tiene la siguiente configuración:
+ Tiene una zona alojada privada llamada example.com y la asocia a una VPC.
+ Cree una regla de resolución de VPC de Route 53 que reenvíe el tráfico de example.com a su red y asocie la regla a la misma VPC.
En esta configuración, la regla de resolución de VPC tiene prioridad sobre la zona alojada privada. Las consultas DNS se reenvían a la red en lugar de resolverse en función de los registros de la zona alojada privada.
**Delegación de la responsabilidad de un subdominio**
Ahora puede crear registros NS en una zona alojada privada para delegar la responsabilidad sobre un subdominio. Para obtener más información, consulte [Tutorial sobre las reglas de delegación de Resolver](outbound-delegation-tutorial.md).
**Servidores DNS personalizados**
Si ha configurado servidores DNS personalizados en instancias de Amazon EC2 de su VPC, debe configurar los servidores DNS para dirigir las consultas de DNS privado a la dirección IP de los servidores DNS proporcionados por Amazon para la VPC. Esta dirección IP es la dirección IP en la base del rango de red de VPC “más dos”. Por ejemplo, si el rango de CIDR de la VPC es 10.0.0.0/16, la dirección IP del servidor DNS es 10.0.0.2.
Si quieres enrutar las consultas de DNS entre VPCs y tu red, puedes usar VPC Resolver. Para obtener más información, consulte [¿Qué es Route 53 VPC Resolver?](resolver.md).
**Permisos de IAM necesarios**
Para crear zonas alojadas privadas, debe conceder permisos de IAM para las acciones de Amazon EC2, además de los permisos para las acciones de Route 53. Para obtener más información, consulte [Acciones, recursos y claves de condición para Amazon Route 53](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html) en la *Referencia de autorizaciones de servicio*.
# Creación de una zona alojada privada
Una zona alojada privada es un contenedor de registros de un dominio que se aloja en una o más nubes privadas virtuales de Amazon (VPCs). Usted crea una zona alojada para un dominio (como example.com) y, a continuación, crea registros para indicar a Amazon Route 53 cómo desea que se redirija el tráfico de ese dominio dentro y entre sus dominios. VPCs
**importante**
Al crear una zona alojada privada, debe asociar una VPC con la zona alojada y la VPC que especifique debe haberse creado utilizando la misma cuenta que utiliza para crear la zona alojada. Tras crear la zona alojada, puede asociarle más, incluida la VPCs que haya creado VPCs con otra AWS cuenta.
Para asociar lo VPCs que creó con una cuenta a una zona alojada privada que creó con una cuenta diferente, debe autorizar la asociación y, a continuación, crearla mediante programación. Para obtener más información, consulte [Asociar una Amazon VPC y una zona alojada privada que haya creado con cuentas diferentes AWS](hosted-zone-private-associate-vpcs-different-accounts.md).
Para obtener información sobre la creación de una zona alojada privada mediante la API de Route 53, consulte la [Referencia de la API de Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/).
**Para crear una zona alojada privada a través de la consola de Route 53**
1. Por cada VPC que desee asociar a la zona alojada de Route 53, cambie las siguientes opciones de VPC a `true`:
+ `enableDnsHostnames`
+ `enableDnsSupport`
A fin de obtener más información, consulte [Actualización de soporte de DNS para su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) en la *guía del usuario de Amazon VPC*.
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Si no conoce Route 53, elija **Get started** (Introducción).
Si ya trabaja con Route 53, seleccione **Hosted zones** (Zonas alojadas) en el panel de navegación.
1. Elija **Create hosted zone** (Crear zona alojada).
1. En el panel **Create private hosted zone** (Crear zona alojada privada), ingrese un nombre de dominio y, si lo desea, un comentario.
Para obtener información sobre cómo especificar caracteres distintos de a-z, 0-9 y - (guion), y cómo especificar nombres de dominio internacionalizados, consulte [Formato de nombres de dominio DNS](DomainNameFormat.md).
1. En la lista **Type** (Tipo), elija **Private hosted zone** (Zona alojada privada).
1. En la lista **VPC ID**, elija la VPC que desea asociar con la zona alojada.
**nota**
Si la consola muestra el siguiente mensaje, significa que está intentando asociar una zona alojada que utiliza el mismo espacio de nombres que el de otra zona alojada dentro de la misma VPC:
“Un dominio en conflicto ya está asociado a la VPC o al conjunto de delegación indicados”.
Por ejemplo, si las zonas alojadas A y B utilizan el mismo nombres de dominio, como `example.com`, no puede asociar ambas zonas alojadas con la misma VPC.
1. Elija **Create hosted zone** (Crear zona alojada).
# Descripción de zonas alojadas privadas
Puede usar la consola de Amazon Route 53 para enumerar todas las zonas alojadas que creó con la AWS cuenta actual. Para obtener información sobre cómo enumerar las zonas alojadas mediante la API de Route 53, consulte [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)la *referencia de la API de Amazon Route 53*.
**Para ver una lista de las zonas alojadas asociadas a una AWS cuenta**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas**.
La página **Zonas alojadas** muestra automáticamente una lista de todas las zonas alojadas que se crearon con la AWS cuenta corriente. La columna **Type** indica si una zona alojada es privada o pública. Elija el encabezado de columna para agrupar todas las zonas alojadas privadas y públicas.
# Asociarse más a una zona VPCs alojada privada
Puede utilizar la consola de Amazon Route 53 para VPCs asociar más a una zona alojada privada si ha creado la zona alojada y la ha VPCs utilizado la misma AWS cuenta.
**importante**
Si desea asociar lo VPCs que creó con una cuenta con una zona alojada privada que creó con una cuenta diferente, primero debe autorizar la asociación. Además, no puede utilizar la AWS consola para autorizar la asociación ni para asociarla a la VPCs zona alojada. Para obtener más información, consulte [Asociar una Amazon VPC y una zona alojada privada que haya creado con cuentas diferentes AWS](hosted-zone-private-associate-vpcs-different-accounts.md).
Para obtener información sobre cómo asociar más VPCs a una zona alojada privada mediante la API de Route 53, consulte [Associate VPCWith HostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html) en la *referencia de la API de Amazon Route 53*.
**Para asociarse adicionalmente VPCs a una zona alojada privada mediante la consola de Route 53**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas**.
1. Selecciona el botón de radio de la zona alojada privada a la que quieras asociarte más VPCs .
1. Elija **Edit (Edición de)**.
1. Elija **Add VPC** (Agregar VPC).
1. Elija la región y el ID de la VPC; que desea asociar con la zona alojada.
1. Para VPCs asociar más a esta zona alojada, repita los pasos 5 y 6.
1. Seleccione **Save changes (Guardar cambios)**.
# Asociar una Amazon VPC y una zona alojada privada que haya creado con cuentas diferentes AWS
Si desea asociar una VPC que creó con una AWS cuenta a una zona alojada privada que creó con una cuenta diferente, lleve a cabo el siguiente procedimiento:
**Para asociar una Amazon VPC y una zona alojada privada que haya creado con cuentas diferentes AWS**
1. Con la cuenta que ha creado la zona alojada, autorice la asociación de la VPC con la zona alojada privada mediante uno de los siguientes métodos:
+ **AWS CLI**— Consulte [create-vpc-association-authorization](https://docs.aws.amazon.com/cli/latest/reference/route53/create-vpc-association-authorization.html)en la Referencia de *AWS CLI comandos*
+ ** AWS SDK** o **AWS Tools for Windows PowerShell**: consulte la documentación correspondiente en la página de [AWS documentación](https://docs.aws.amazon.com/)
+ **API de Amazon Route 53**: consulte [Crear VPCAssociation autorización](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) en la *referencia de la API de Amazon Route 53*
Tenga en cuenta lo siguiente:
+ Si desea asociar varias de las VPCs que creó con una cuenta a una zona alojada que creó con una cuenta diferente, debe enviar una solicitud de autorización para cada VPC.
+ Al autorizar la asociación, debe especificar el ID de la zona alojada, por lo que la zona alojada privada ya debe existir.
+ No puede utilizar la consola de Route 53 para autorizar la asociación de una VPC con una zona alojada privada o para realizar la asociación.
1. Con la cuenta que ha creado la VPC, asocie la VPC con la zona alojada. Al igual que al autorizar la asociación, puede utilizar el AWS SDK, las herramientas para Windows PowerShell, la API de Route 53 o la AWS CLI API de Route 53. Si usas la API, usa la VPCWith HostedZone acción [Asociar](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html).
1. *Recomendado*: elimine la autorización para asociar la VPC a la zona alojada. La eliminación de la autorización no afecta a la asociación, solo le impide volver a asociar la VPC con la zona alojada en el futuro. Si desea volver a asociar la VPC con la zona alojada, repita los pasos 1 y 2 de este procedimiento.
**importante**
`ListHostedZonesByVPC`Devuelve las zonas alojadas a las que se ha dado una VPC y la `GetHostedZone` API devuelve las VPCs asociadas a la zona alojada. APIs Solo consideran la asociación de la zona alojada a la VPC creada por la `AssociateVPCWithHostedZone` API o cuando se crea la zona alojada privada. Si desea obtener una lista completa de las asociaciones de zonas alojadas a una VPC, llame también. [ListProfileResourceAssociations](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53profiles_ListProfileResourceAssociations.html)
**nota**
Para conocer el número máximo de autorizaciones que puede crear, consulte [Cuotas de entidades](DNSLimitations.md#limits-api-entities).
# Desasociarse de una zona VPCs alojada privada
Puede usar la consola de Amazon Route 53 para desvincularse VPCs de una zona alojada privada. Esto hace que Route 53 detenga el tráfico de enrutamiento utilizando registros en la zona alojada para las consultas de DNS que se originan en la VPC. Por ejemplo, si la zona alojada example.com está asociada a una VPC y desasocia la zona alojada de dicha VPC, Route 53 deja de resolver las consultas de DNS para example.com o cualquiera de los demás registros de la zona alojada example.com.
**nota**
No puede desasociar la última VPC de una zona alojada privada. Si desea desasociar esa VPC, primero debe asociar otra VPC a la zona alojada.
**Para desasociarse VPCs de una zona alojada privada**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas**.
1. Elija el botón de radio de la zona alojada privada de la que desee desvincular una o más VPCs .
1. Elija **Edit (Edición de)**.
1. Elija **Remove VPC** (Eliminar VPC) junto a la VPC que desea desvincular de esta zona alojada.
1. Seleccione **Save changes (Guardar cambios)**.
# Eliminar una zona alojada privada
En esta sección, se explica cómo eliminar una zona alojada privada con la consola de Amazon Route 53.
Puede eliminar una zona alojada privada solo si los únicos registros son los registros SOA y NS predeterminados. Si su zona alojada contiene otros registros, debe eliminarlos para poder eliminar su zona alojada. Esto le impide eliminar accidentalmente una zona alojada que siga conteniendo registros.
**Topics**
+ [Eliminar zonas alojadas privadas creadas por otro servicio](#delete-private-hosted-zone-created-by-another-service)
+ [Uso de la consola de Route 53 para eliminar una zona alojada privada](#delete-private-hosted-zone-procedure)
## Eliminar zonas alojadas privadas creadas por otro servicio
Si otro servicio ha creado una zona alojada privada, no puede eliminarla con la consola de Route 53. En su lugar, ha de utilizar el proceso correspondiente del otro servicio:
+ **AWS Cloud Map**— Para eliminar una zona alojada que se AWS Cloud Map creó al crear un espacio de nombres DNS privado, elimine el espacio de nombres. AWS Cloud Map elimina la zona alojada automáticamente. Para obtener más información, consulte [Eliminación de espacios de nombres](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) en la *Guía para desarrolladores de AWS Cloud Map *.
+ **Descubrimiento de servicios de Amazon Elastic Container Service (Amazon ECS)**: para eliminar una zona alojada privada que Amazon ECS creó al crear un servicio mediante la detección de servicios, elimine los servicios de Amazon ECS que utilizan el espacio de nombres y elimine el espacio de nombres. Para obtener más información, consulte [Eliminación de un servicio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) en la *Guía para desarrolladores de Amazon Elastic Container Service*.
## Uso de la consola de Route 53 para eliminar una zona alojada privada
Para utilizar la consola de Route 53 para eliminar una zona alojada privada, realice el siguiente procedimiento.
**Para eliminar una zona alojada privada a través de la consola de Route 53**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Confirme que la zona alojada que desea eliminar solo contiene un registro NS y SOA. Si contiene registros adicionales, elimínelos:
1. Elija el nombre de la zona alojada que desea eliminar.
1. En la página **Record** (Registro), si la lista de registros incluye registros cuyo valor para la columna **Type** (Tipo) es distinto de **NS** o **SOA**, elija la fila y, a continuación, elija **Delete** (Eliminar).
Para seleccionar varios registros s consecutivos, elija la primera fila, mantenga presionada la tecla **Mayús** y elija la última fila. Para seleccionar varios registros no consecutivos, elija la primera fila, mantenga presionada la tecla **Ctrl** y elija las filas restantes.
1. En la página Hosted Zones (Zonas alojadas), elija la fila de la zona alojada que desea eliminar.
1. Elija **Eliminar**.
1. Escriba la clave de confirmación y elija **Delete** (Eliminar).
# Permisos de VPC
[Los permisos de VPC utilizan una condición de política de administración de identidad y acceso (IAM) que le permite establecer permisos granulares para VPCs cuando utilice [Associate VPCWith HostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html), [Disassociation](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisassociateVPCFromHostedZone.html), [Create VPCAssociation Authorization VPCFromHostedZone, [Delete VPCAssociation](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html) Authorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) y VPC. [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)ListHostedZonesBy](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZonesByVPC.html) APIs
Con la condición de política de IAM`route53:VPCs`, puedes conceder derechos administrativos detallados a otros usuarios. AWS Esto le permite conceder a alguien permisos para asociar la zona alojada, desasociar la zona alojada, crear una autorización de asociación de VPC, eliminar una autorización de asociación de VPC, crear una zona alojada o enumerar zonas alojadas para lo siguiente:
+ Una sola VPC.
+ Cualquiera VPCs dentro de la misma región.
+ Múltiple VPCs.
Para obtener más información sobre los permisos de VPC, consulte [Uso de condiciones de las políticas de IAM para control de acceso preciso](specifying-conditions-route53.md).
Para obtener información sobre cómo autenticar a AWS los usuarios, consulte [Autenticación con identidades](security-iam.md#security_iam_authentication) y aprenda a controlar el acceso a los recursos de Route 53, consulte[Control de acceso](security-iam.md#access-control).
# Migración de una zona alojada a una cuenta diferente AWS
Al migrar una zona alojada a otra Cuenta de AWS, sigue estos pasos recomendados.
Estos pasos son los más adecuados para las zonas alojadas con cambios de registro poco frecuentes. En el caso de las zonas alojadas con actualizaciones de registro frecuentes, tenga en cuenta lo siguiente:
+ No actualice ningún registro de recursos durante la migración.
+ Publique los cambios en los registros de recursos tanto en las zonas alojadas antiguas como en las nuevas una vez transferida la delegación.
**Requisitos previos**
Instale o actualice: AWS CLI
Para obtener información sobre la descarga, la instalación y la configuración AWS CLI, consulte la [Guía del AWS Command Line Interface usuario](https://docs.aws.amazon.com/cli/latest/userguide/).
**nota**
Configure la CLI de forma que pueda usarla cuando utilice tanto la cuenta que ha creado la zona alojada como la cuenta a la que está migrando dicha zona. Para obtener más información, consulte [Configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) (Configurar) en la *Guía del usuario de AWS Command Line Interface *.
Si ya utiliza AWS CLI, le recomendamos que actualice a la última versión de la CLI para que los comandos de la CLI admitan las funciones más recientes de Route 53.
**Topics**
+ [Paso 1: prepare todo para la migración](#hosted-zones-migrating-prepare)
+ [Paso 2: Crear la zona alojada nueva](#hosted-zones-migrating-create-hosted-zone)
+ [Paso 3 (opcional): migre las comprobaciones de estado](#hosted-zones-migrating-health-checks)
+ [Paso 4: migre los registros de la zona alojada anterior a la nueva zona alojada](#hosted-zones-migrating-old-to-new)
+ [Paso 5: compare los registros de las zonas alojadas antiguas y nuevas](#hosted-zones-migrating-compare)
+ [Paso 6: Actualice el registro del dominio para usar servidores de nombres para la nueva zona alojada](#hosted-zones-migrating-update-domain)
+ [Paso 7: Cambie el TTL del registro NS a un valor superior](#hosted-zones-migrating-change-ttl)
+ [Paso 8: vuelva a activar la firma de DNSSEC y establezca la cadena de confianza (si es necesario)](#hosted-zones-migrating-enable-dnssec)
+ [Paso 9: (opcional) elimine la antigua zona alojada](#hosted-zones-migrating-delete-old-hosted-zone)
## Paso 1: prepare todo para la migración
Los pasos de preparación ayudan a minimizar los riesgos asociados a la migración de una zona alojada.
**1. Controle la disponibilidad de zonas**
Puede supervisar la zona para comprobar la disponibilidad de sus nombres de dominio. Esto puede ayudar a solucionar cualquier problema que pueda provocar la reversión de la migración. Puede supervisar los nombres de dominio con más tráfico mediante CloudWatch el registro de consultas. Para obtener más información sobre la configuración del registro de consultas, consulte [Monitoreo de Amazon Route 53](monitoring-overview.md).
La supervisión se puede realizar a través de un script de shell o mediante un servicio de terceros. Sin embargo, no debería ser la única señal para determinar si se requiere una reversión, ya que es posible que también reciba comentarios de sus clientes debido a que un dominio no está disponible.
**2. Reduzca la configuración del TTL**
La opción TTL (tiempo de vida) de un registro especifica el tiempo que quiere que los solucionadores de DNS tengan en caché el registro y se use la información de la memoria caché. Cuando el TTL vence, un solucionador envía otra consulta al proveedor de servicios DNS para que un dominio obtenga la información más reciente.
Normalmente, la configuración de TTL para el registro NS es de 172 800 segundos o dos días. El registro NS muestra una lista de los servidores de nombres que el sistema de nombres de dominio (DNS) puede utilizar para obtener información acerca de cómo dirigir el tráfico para su dominio. Si reduce el TTL del registro NS, tanto en su proveedor de servicios DNS actual como en Route 53, se reducirá el tiempo de inactividad de su dominio si descubre un problema mientras realiza la migración de DNS a Route 53. Si no reduce el TTL, su dominio podría no estar disponible en Internet durante un máximo de dos días si algo va mal.
**Cómo reducir el TTL**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Seleccione **Zonas alojadas** en el panel de navegación.
1. Elija el nombre de la zona alojada.
1. Seleccione el registro NS y, en el panel **Detalles del registro**, seleccione **Editar registro**.
1. Cambie el valor de **TTL (Seconds)** (Segundos). Le recomendamos que especifique un valor entre 60 segundos y 900 segundos (15 minutos).
1. Seleccione **Save**.
**3. Elimine el registro de DS de la zona principal (si DNSSEC está configurado)**
Si ha configurado DNSSEC para su dominio, quite el registro de Delegation Signer (DS) de la zona principal antes de migrar el dominio a Route 53.
Si la zona principal está alojada a través de Route 53, consulte [Eliminar claves públicas de un dominio](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys) para obtener más información. Si la zona principal está alojada a través de otro registrador, comuníquese con este para eliminar el registro DS.
Actualmente, Route 53 no admite la migración de la configuración de DNSSEC. Por lo tanto, deberá desactivar la validación de DNSSEC realizada en su dominio antes de la migración. Para ello, elimine el registro DS de la zona principal. Tras la migración, podrá volver a activar la validación de DNSSEC, para lo que deberá configurar DNSSEC en la nueva zona alojada y añadir el registro DS correspondiente a la zona principal.
**4. Asegúrese de que no haya otras operaciones en curso que dependan de la zona alojada que se está migrando**
Algunas operaciones dependerán de la resolución del DNS en la zona hospedada que se esté migrando; por ejemplo, el proceso de renovación del TLS/SSL certificado puede requerir cambios en el registro DNS y el proveedor intentará resolver el registro DNS como método de validación. Antes de hacer la migración, debe asegurarse de que no se esté llevando a cabo ninguna otra operación para evitar que la migración de la zona alojada se vea afectada de forma inesperada.
## Paso 2: Crear la zona alojada nueva
Cree la zona alojada nueva en la cuenta a la que desea migrar la zona alojada.
Selecciona la pestaña para ver las instrucciones de la consola AWS CLI o de la consola.
+ [CLI](#migrate-hz-cli)
+ [Consola](#migrate-hz-console)
------
#### [ CLI ]
Introduzca el siguiente comando:
```
aws route53 create-hosted-zone \
--name $hosted_zone_name \
--caller-reference $unique_string
```
Para obtener más información, consulte [create-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/create-hosted-zone.html).
------
#### [ Console ]
**Para crear la zona alojada nueva utilizando otra cuenta**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
Inicie sesión con las credenciales de la cuenta a la que desea migrar la zona alojada.
1. Cree una zona alojada. Para obtener más información, consulte [Crear una zona alojada pública](CreatingHostedZone.md).
1. Anote el ID de la zona alojada. En algunos casos, necesitará esta información más adelante durante el proceso.
1. Cierre la sesión en la consola de Route 53.
Reduzca también el TTL de NS en la nueva zona, de forma similar al ajuste para reducir el TTL como preparación en el paso 1.
------
## Paso 3 (opcional): migre las comprobaciones de estado
Puede asociar los registros de DNS de la nueva cuenta con las comprobaciones de estado de Route 53 de la cuenta desde la que está realizando la migración. Para migrar una comprobación de estado de Route 53, debe crear nuevas comprobaciones de estado en la cuenta nueva con la misma configuración que las existentes. Para obtener más información, consulte [Creación de comprobaciones de estado de Amazon Route 53](dns-failover.md).
## Paso 4: migre los registros de la zona alojada anterior a la nueva zona alojada
Puede migrar registros de uno Cuenta de AWS a otro mediante la consola o el AWS CLI.
------
#### [ Console ]
Si su zona contiene solo unos pocos registros, puede utilizar la consola de Route 53 para enumerar los registros de la zona anterior, anotarlos y crearlos en la nueva zona. Si migró la comprobación de estado en [Paso 3 (opcional): migre las comprobaciones de estado](#hosted-zones-migrating-health-checks), cuando cree los registros en la nueva zona alojada, deberá especificar el nuevo identificador de comprobación de estado. Para obtener más información, consulte los temas siguientes:
+ [Descripción de registros](resource-record-sets-listing.md)
+ [Creación de registros con la consola de Amazon Route 53](resource-record-sets-creating.md)
+ [Configuración de la recuperación ante errores a nivel de DNS](dns-failover-configuring.md)
También debe reducir el TTL de NS en la nueva zona, de forma similar a la configuración para reducir el TTL en el paso 1.
------
#### [ CLI ]
Si su zona contiene una gran cantidad de registros, puede exportar los registros que quiere migrar a un archivo, editar el archivo y, a continuación, utilizar el archivo editado para crear los registros en la zona alojada nueva. El siguiente procedimiento utiliza comandos AWS CLI, aunque también hay herramientas de terceros disponibles para este fin.
****
1. Use el siguiente comando:
```
aws route53 list-resource-record-sets --hosted-zone-id hosted-zone-id > path-to-output-file
```
Tenga en cuenta lo siguiente:
+ Para *hosted-zone-id* ello, especifique el ID de la antigua zona alojada que contiene los registros que desea migrar.
+ En *path-to-output-file*, especifique la ruta del directorio y el nombre del archivo en el que desea guardar la salida.
+ El carácter `>` envía la salida al archivo especificado.
+ Gestiona AWS CLI automáticamente la paginación de las zonas alojadas que contienen más de 100 registros. Para obtener más información, consulte [Uso de las opciones de paginación de la interfaz de línea de AWS comandos](https://docs.aws.amazon.com/cli/latest/userguide/pagination.html) en la Guía del *AWS Command Line Interface usuario*.
Si utiliza otro método programático para enumerar los registros, como uno de los AWS SDKs, puede obtener un máximo de 100 registros por página de resultados. Si la zona alojada contiene más de 100 registros, debe enviar varias solicitudes para conseguir todos los registros.
Haga una copia de esta salida. Tras crear los registros en la nueva zona alojada, se recomienda ejecutar el AWS CLI `list-resource-record-sets` comando en la nueva zona alojada y comparar los dos resultados para asegurarse de que se han creado todos los registros.
1. Edite los registros que quiera migrar.
Edite el archivo exportado para poder usarlo con el comando `change-resource-record-sets`. Para efectuar estos cambios, puede usar la función de búsqueda y sustitución en un editor de texto.
**nota**
En los pasos siguientes se describe la edición manual mediante un editor de texto. Los usuarios avanzados pueden automatizar estas transformaciones con herramientas programáticas como jq, Python u otros lenguajes de secuencias de comandos.
Abra una copia del archivo que creó en el paso 1 de este procedimiento que contenga los registros que desee migrar y realice los siguientes cambios:
+ Sustituya el ResourceRecordSets elemento de la parte superior del archivo por el `Changes` elemento.
+ Opcional: agregue un elemento `Comment`.
+ Elimine las líneas relacionadas con los registros SOA y NS del nombre de la zona alojada. La zona alojada nueva ya tiene esos registros.
+ Para cada registro, añada un elemento `Action` y `ResourceRecordSets`, y añada corchetes de apertura y cierre (`{ }`) según sea necesario para que el código JSON sea válido.
**nota**
Puede utilizar un validador JSON para verificar que todas las llaves y corchetes están en los lugares correctos. Para encontrar un validador de JSON en línea, busque “validador de JSON” en su navegador.
+ Si la zona alojada contiene algún alias que hace referencia a otros registros de la misma zona alojada, realice los siguientes cambios:
+ Cambie el ID de la zona alojada por el ID de la zona alojada nueva.
**importante**
Si el registro de alias apunta a otro recurso, como un equilibrador de carga, no cambie el ID de zona alojada al ID de zona alojada del dominio. Si cambia el ID de zona alojada por accidente, revierta el ID de zona alojada al ID de zona alojada del recurso en sí, no al ID de zona alojada del dominio. El identificador de la zona alojada en el recurso se encuentra en la AWS consola en la que se creó el recurso.
+ Mueva los registros de alias a la parte inferior del archivo. Route 53 debe crear el registro al que hace referencia un registro de alias antes de crear el propio registro de alias.
**importante**
Si uno o varios registros de alias hacen referencia a otros registros de alias, los registros que son el destino del alias deben aparecer en el archivo antes que los registros de alias que hacen de referencia a ellos. Por ejemplo, si `alias.example.com` es el destino de alias para `alias.alias.example.com`, `alias.example.com` debe aparecer primero en el archivo.
+ Elimine los registros de alias que dirijan el tráfico a una instancia de políticas de tráfico. Anote los registros para que pueda volver a crearlos más adelante.
+ Si migró las comprobaciones de estado[Paso 3 (opcional): migre las comprobaciones de estado](#hosted-zones-migrating-health-checks), cambie los registros para asociarlos a la comprobación de estado recién creada IDs.
En el siguiente ejemplo se muestra la versión editada de los registros de una zona alojada para example.com. El texto en cursiva y en color rojo es nuevo:
```
{
"Comment": "string",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet":{
"ResourceRecords": [
{
"Value": "192.0.2.4"
},
{
"Value": "192.0.2.5"
},
{
"Value": "192.0.2.6"
}
],
"Type": "A",
"Name": "route53documentation.com.",
"TTL": 300
}
},
{
"Action": "CREATE",
"ResourceRecordSet":{
"AliasTarget": {
"HostedZoneId": "Z3BJ6K6RIION7M",
"EvaluateTargetHealth": false,
"DNSName": "s3-website-us-west-2.amazonaws.com."
},
"Type": "A",
"Name": "www.route53documentation.com."
}
}
]
}
```
1. Divida los archivos grandes en archivos más pequeños.
Si tiene una gran cantidad de registros o registros con muchos valores (por ejemplo, una gran cantidad de direcciones IP), es posible que tenga que dividir el archivo en archivos más pequeños. Los valores máximos son:
+ Cada archivo puede contener un máximo de 1 000 registros.
+ La longitud combinada máxima de los valores de todos los elementos `Value` es de 32 000 bytes.
1. Cree registros en la zona alojada nueva.
Ingrese la siguiente CLI:
```
aws route53 change-resource-record-sets \
--hosted-zone-id new-hosted-zone-id \
--change-batch file://path-to-file-that-contains-records
```
Especifique los siguientes valores:
+ En `new-hosted-zone-id`, especifique el ID de la zona alojada nueva.
+ En `path-to-file-that-contains-records`, especifique la ruta del directorio y el nombre del archivo que editó en los pasos anteriores.
Si ha eliminado registros de alias que dirigen el tráfico a una instancia de políticas de tráfico, vuelva a crearlos mediante la consola de Route 53. Para obtener más información, consulte [Creación de registros con la consola de Amazon Route 53](resource-record-sets-creating.md).
------
## Paso 5: compare los registros de las zonas alojadas antiguas y nuevas
Para confirmar que haya creado correctamente todos los registros en la zona alojada nueva, ingrese el siguiente comando de la CLI para obtener una lista de los registros que contiene la zona alojada nueva y compare la salida con la lista de registros de la zona alojada antigua.
```
aws route53 list-resource-record-sets \
--hosted-zone-id new-hosted-zone-id \
--output json > path-to-output-file
```
Especifique los siguientes valores:
+ En `new-hosted-zone-id`, especifique el ID de la zona alojada nueva.
+ En `path-to-output-file`, especifique la ruta del directorio y el nombre del archivo en el que desea guardar la salida. Utilice un nombre de archivo diferente al que ha utilizado en el paso 4.
El carácter `>` envía la salida al archivo especificado.
Compare la salida con la salida del paso 4. Con excepción de los valores de los registros NS y SOA y de cualquier cambio que haya realizado en el paso 4 (como nombres de dominio IDs o zonas alojadas diferentes), los dos resultados deben ser idénticos.
Si los registros de la zona alojada nueva no coinciden con los registros de la antigua, opte por alguna de estas posibilidades:
+ Realice pequeñas correcciones mediante la consola de Route 53. Para obtener más información, consulte [Editar registros](resource-record-sets-editing.md).
+ Elimine todos los registros, excepto los registros SOA y NS, de la zona alojada nueva y repita el procedimiento del paso 4.
## Paso 6: Actualice el registro del dominio para usar servidores de nombres para la nueva zona alojada
Cuando termine de migrar los registros a la zona alojada nueva, cambie los servidores de nombres del registro de dominio para utilizar los servidores de nombres de la zona alojada nueva. Para obtener más información, consulte Establecimiento de Amazon Route 53 como el servicio DNS de un dominio existente.
Si está utilizando la zona alojada, por ejemplo, si los usuarios utilizan el nombre de dominio para navegar a un sitio web u obtener acceso a una aplicación web, debe seguir supervisando el tráfico y la disponibilidad de la zona alojada, incluido el tráfico del sitio web o la aplicación, el correo electrónico, etc.
+ **Si el tráfico se reduce o se detiene**: cambie el servicio de nombres del registro de dominio por los servidores de nombres anteriores de la zona alojada anterior. A continuación, determine qué ha fallado.
+ **Si el tráfico no se ve afectado**: continúe con el próximo paso.
## Paso 7: Cambie el TTL del registro NS a un valor superior
En la zona alojada nueva, cambie el TTL del registro NS a un valor más normal como, por ejemplo, 172 800 segundos (dos días). Esto mejorará la latencia de los usuarios, ya que no tendrán que esperar tan a menudo para que los solucionadores de DNS envíen una consulta para obtener los servidores de nombres de su dominio.
**Cómo cambiar el TTL:**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Seleccione **Zonas alojadas** en el panel de navegación.
1. Elija el nombre de la zona alojada.
1. Seleccione el registro NS y, en el panel **Detalles del registro**, seleccione **Editar registro**.
1. Cambie el valor de **TTL (segundos)** por el número de segundos en que desea que los solucionadores de DNS almacenen en caché los nombres de los servidores de nombres de su dominio. Le recomendamos un valor de 172 800 segundos.
1. Seleccione **Save**.
## Paso 8: vuelva a activar la firma de DNSSEC y establezca la cadena de confianza (si es necesario)
Para volver a habilitar la firma de DNSSEC, siga estos dos pasos:
1. Habilite la firma de DNSSEC para Route 53 y solicite que Route 53 cree una clave de firma de claves (KSK) basada en una clave administrada por el cliente en AWS Key Management Service.
1. Cree una cadena de confianza para la zona alojada. Para ello, agregue un registro de firmante de delegación (DS) a la zona principal, de modo que las respuestas de DNS se puedan autenticar con firmas criptográficas de confianza.
Para obtener instrucciones, consulte [Activar la firma de DNSSEC y establecer una cadena de confianza](dns-configuring-dnssec-enable-signing.md).
## Paso 9: (opcional) elimine la antigua zona alojada
Cuando esté seguro de que ya no necesita la zona alojada antigua, puede eliminarla si lo desea. Para obtener instrucciones, consulte [Eliminación de una zona alojadas pública](DeleteHostedZone.md).
**importante**
No elimine la antigua zona alojada o ningún registro de dicha zona durante al menos 48 horas después de actualizar el registro de dominio para que use servidores de nombres de la nueva zona alojada. Si elimina la antigua zona alojada antes de que los solucionadores de DNS dejen de utilizar los registros de dicha zona, puede que su dominio deje de estar disponible en Internet hasta que los solucionadores comiencen a usar la nueva zona alojada.
# Uso de registros
Después de crear una zona alojada para su dominio, como example.com, puede crear registros para indicar al sistema de nombres de dominio (DNS) cómo desea redirigir el tráfico para ese dominio.
Por ejemplo, puede crear registros para que el DNS haga lo siguiente:
+ Redirigir el tráfico de Internet de example.com a la dirección IP de un host de su centro de datos.
+ Redirigir el correo electrónico de ese dominio (ichiro@example.com) a un servidor de correo (mail.example.com).
+ Redirigir el tráfico para un subdominio llamado operations.tokyo.example.com a la dirección IP de un host diferente.
Cada registro incluye el nombre de un dominio o un subdominio, un tipo de registro (por ejemplo, un registro con tipo de correo electrónico redirigido MX) y otros datos del tipo de registro (para los registros MX, el nombre de host de uno o varios servidores de correo electrónico y una prioridad para cada servidor). Para obtener más información acerca de los distintos tipos de registros, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
El nombre de cada registro de una zona alojada debe terminar con el nombre de la zona alojada. Por ejemplo, la zona alojada example.com puede contener registros de www.example.com y subdominios accounting.tokyo.example.com, pero no registros para un subdominio www.example.ca.
**nota**
Para crear registros para las configuraciones de enrutamiento complejas, también puede utilizar el editor visual de Flujo de tráfico y guardar la configuración como una política de tráfico. A continuación, puede asociar la política de tráfico con uno o varios nombres de dominio (como example.com) o nombres de subdominio (como www.example.com) en la misma zona alojada o en varias zonas hospedadas. Además, puede revertir las actualizaciones si la nueva configuración no tiene el desempeño previsto. Para obtener más información, consulte [Uso de flujo de tráfico para dirigir el tráfico DNS](traffic-flow.md).
Amazon Route 53 no cobra por los registros que agregue a una zona alojada. Para obtener más información acerca del número máximo de registros que puede crear en una zona alojada, consulte [Cuotas](DNSLimitations.md).
**Topics**
+ [Elección de una política de enrutado](routing-policy.md)
+ [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md)
+ [Tipos de registros de DNS admitidos](ResourceRecordTypes.md)
+ [Creación de registros con la consola de Amazon Route 53](resource-record-sets-creating.md)
+ [Permisos del conjunto de registros de recursos](resource-record-sets-permissions.md)
+ [Valores que hay que especificar al crear o editar los registros de Amazon Route 53.](resource-record-sets-values.md)
+ [Creación de registros mediante la importación de un archivo de zona](resource-record-sets-creating-import.md)
+ [Editar registros](resource-record-sets-editing.md)
+ [Eliminar registros](resource-record-sets-deleting.md)
+ [Descripción de registros](resource-record-sets-listing.md)
# Elección de una política de enrutado
Al crear un registro, puede seleccionar una política de direccionamiento, que determina cómo Amazon Route 53 responde a las consultas:
+ **Política de direccionamiento simple**: se utiliza para un único recurso que realiza una función determinada para su dominio; por ejemplo, un servidor web que ofrece contenido para el sitio web example.com. Puede usar el enrutamiento simple para crear registros en una zona alojada privada.
+ **Política de direccionamiento de conmutación por error**: se utiliza si desea configurar la conmutación por error activa-pasiva. Puede usar el enrutamiento de conmutación por error para crear registros en una zona alojada privada.
+ **Política de direccionamiento de geolocalización**: se utiliza si desea dirigir el tráfico en función de la ubicación de los usuarios. Puede usar el enrutamiento por geolocalización para crear registros en una zona alojada privada.
+ **Política de enrutamiento de geoproximidad**: se utiliza si desea dirigir el tráfico en función de la ubicación de los recursos y, opcionalmente, desviar el tráfico desde los recursos de una ubicación a los de otra. Puede usar el enrutamiento por geoproximidad para crear registros en una zona alojada privada.
+ **Política de enrutamiento de latencia**: utilícela cuando tenga varios recursos Regiones de AWS y desee enrutar el tráfico a la región que proporciona la mejor latencia. Puede usar el enrutamiento de latencia para crear registros en una zona alojada privada.
+ **Política de direccionamiento basada en IP**: se usa cuando se quiere enrutar el tráfico en función de la ubicación de los usuarios, y tener las direcciones IP de las que se origina el tráfico.
+ **Política de direccionamiento de respuesta con varios valores**: se utiliza si desea que Route 53 responda a consultas de DNS con hasta ocho registros de estado seleccionados al azar. Puede usar el enrutamiento de respuesta multivalor para crear registros en una zona alojada privada.
+ **Política de direccionamiento ponderada**: se utiliza para dirigir el tráfico a varios recursos en las proporciones que especifique. Puede usar el enrutamiento ponderado para crear registros en una zona alojada privada.
**Topics**
+ [Direccionamiento simple](routing-policy-simple.md)
+ [Enrutado de conmutación por error](routing-policy-failover.md)
+ [Enrutado de geolocalización](routing-policy-geo.md)
+ [Enrutamiento por geoproximidad](routing-policy-geoproximity.md)
+ [Enrutado basado en latencia](routing-policy-latency.md)
+ [Direccionamiento basado en IP](routing-policy-ipbased.md)
+ [Direccionamiento de respuesta con varios valores](routing-policy-multivalue.md)
+ [Direccionamiento ponderado](routing-policy-weighted.md)
+ [Cómo utiliza Amazon Route 53 EDNS0 para estimar la ubicación de un usuario](routing-policy-edns0.md)
# Direccionamiento simple
El direccionamiento simple le permite configurar registros DNS estándar, sin direccionamiento de Route 53 especial, como ponderado o de latencia. Con el direccionamiento simple, el tráfico se dirige normalmente a un único recurso, como un servidor web de su sitio web.
Puede utilizar una política de enrutamiento sencillo para los registros de una zona alojada privada.
Si elige la política de direccionamiento simple en la consola de Route 53, no puede crear varios registros que tengan el mismo nombre y tipo, pero puede especificar varios valores en el mismo registro, como varias direcciones IP. (Si elige la política de enrutamiento simple para un registro de alias, puede especificar solo un AWS recurso o un registro en la zona alojada actual). Si especifica varios valores en un registro, Route 53 devuelve todos los valores al servicio de resolución de nombres recursivo en orden aleatorio y el servicio devuelve los valores al cliente (como un navegador web) que envió la consulta de DNS. A continuación, el cliente elige un valor y vuelve a enviar la consulta. Con una política de enrutamiento sencillo, si bien puede especificar varias direcciones IP, no se puede comprobar el estado de estas direcciones.
Para obtener información acerca de los valores que especifica cuando se utiliza la política de direccionamiento simple para crear registros, consulte los siguientes temas:
+ [Valores específicos para registros simples](resource-record-sets-values-basic.md)
+ [Valores específicos para registros de alias simples](resource-record-sets-values-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)
# Enrutado de conmutación por error
El direccionamiento de conmutación por error permite redirigir el tráfico a un recurso cuando este está en buen estado o a uno diferente cuando el primer recurso no está en buen estado. Los registros primarios y secundarios pueden dirigir el tráfico a cualquier elemento desde un bucket de Amazon S3 configurado como un sitio web a un árbol complejo de registros. Para obtener más información, consulte [Conmutación por error activa-pasiva](dns-failover-types.md#dns-failover-types-active-passive).
Puede utilizar una política de enrutamiento de conmutación por error para los registros de una zona alojada privada.
Para obtener información acerca de los valores que especifica cuando se utiliza la política de direccionamiento de conmutación por error para crear registros, consulte los siguientes temas:
+ [Valores específicos de registros de conmutación por error](resource-record-sets-values-failover.md)
+ [Valores específicos de registros de alias de conmutación por error](resource-record-sets-values-failover-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)
# Enrutado de geolocalización
El direccionamiento de geolocalización permite elegir los recursos que dan servicio al tráfico en función de la ubicación geográfica de los usuarios, es decir, la procedencia de las consultas de DNS. Por ejemplo, puede hacer que todas las consultas de Europa se enruten a un equilibrador de carga elástico de la región de Fráncfort.
Cuando usa el direccionamiento de geolocalización, puede localizar su contenido y presentar todo su sitio web o parte de este en el idioma de sus usuarios. También puede utilizar el direccionamiento de geolocalización para restringir la distribución de contenido solo a los lugares para los que tiene derechos de distribución. Otro posible uso es equilibrar la carga entre los puntos finales de forma predecible, de easy-to-manage modo que la ubicación de cada usuario se dirija de forma coherente al mismo punto final.
Puede especificar ubicaciones geográficas por continente, por país o por estado en Estados Unidos. Si crea registros independientes para superponer regiones geográficas (por ejemplo, un registro para América del Norte y otro para Canadá), la región geográfica más pequeña recibirá la mayor prioridad. De esta manera, puede redirigir algunas consultas de un continente a un recurso y las consultas de países seleccionados de dicho continente a otro recurso. (Para ver una lista de los países de cada continente, consulte [Ubicación](resource-record-sets-values-geo.md#rrsets-values-geo-location)).
La geolocalización funciona mediante el mapeo de direcciones IP a ubicaciones. No obstante, algunas direcciones IP no se mapean a ubicaciones geográficas por lo que, aunque cree conjuntos de registros de geolocalización que abarquen los siete continentes, Amazon Route 53 recibirá algunas consultas de DNS de ubicaciones que no puede identificar. Puede crear un registro predeterminado que administre tanto las consultas de direcciones IP no mapeadas a ninguna ubicación como las que procedan de ubicaciones para las que no haya creado registros de geolocalización. Si no crea un registro predeterminado, Route 53 devuelve un mensaje de tipo “sin respuesta” a las consultas de esas ubicaciones.
Se puede utilizar el enrutamiento de geolocalización para los registros de zonas alojadas privadas y públicas.
Para obtener más información, consulte [Cómo utiliza Amazon Route 53 EDNS0 para estimar la ubicación de un usuario](routing-policy-edns0.md).
Para obtener información acerca de los valores que especifica cuando se utiliza la política de direccionamiento de geolocalización para crear registros, consulte los siguientes temas:
+ [Valores específicos de registros de geolocalización](resource-record-sets-values-geo.md)
+ [Valores específicos de registros de alias de geolocalización](resource-record-sets-values-geo-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)
# Enrutado de geolocalización en zonas alojadas privadas
En el caso de las zonas alojadas privadas, Route 53 responde a las consultas de DNS en función Región de AWS de la VPC de la que se originó la consulta. Para ver la lista Regiones de AWS, consulte [Regiones y zonas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) en la guía del *usuario de Amazon EC2*.
Si la consulta de DNS se origina en una parte en las instalaciones de una red híbrida, se considerará que se originó en la Región de AWS en la que se encuentra la VPC.
Si incluye comprobaciones de estado, puede crear registros predeterminados para:
+ Direcciones IP que no están asignadas a ubicaciones geográficas.
+ Consultas de DNS que provienen de ubicaciones para las que no ha creado registros de geolocalización.
Si el registro de geolocalización de la región de la consulta de DNS no está en buen estado, se devolverá el registro predeterminado (si está en buen estado).
En la configuración de ejemplo de la siguiente figura, las consultas de DNS procedentes de un Región de AWS us-east-1 (Virginia) se enrutarán al punto final 1.1.1.1.
![\[Una captura de pantalla que muestra un registro de geolocalización de una zona alojada privada.\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/geolocation-phz.png)
# Enrutamiento por geoproximidad
El direccionamiento de geoproximidad permite a Amazon Route 53 dirigir el tráfico a sus recursos en función de la ubicación geográfica de sus usuarios y recursos. Enruta el tráfico al recurso más cercano disponible. También puede optar por enrutar más o menos tráfico a un determinado recurso especificando un valor, conocido como *sesgo*. Un sesgo expande o reduce el tamaño de la región geográfica desde la que se direcciona el tráfico a un recurso.
Puede crear reglas de geoproximidad para sus recursos y especificar uno de los siguientes valores para cada regla:
+ Si utiliza AWS recursos, especifique el grupo de zonas locales Región de AWS o el grupo de zonas en el que creó el recurso.
+ Si utiliza recursos que no son AWS recursos, especifique la latitud y la longitud del recurso.
Para usar las Zonas AWS Locales, primero debe habilitarlas. Para obtener más información, consulte la sección [Introducción al uso de zonas locales](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html), en la *AWS Guía del usuario de zonas locales*.
Para obtener más información sobre las diferencias entre las Zonas Locales Regiones de AWS y las Zonas, consulte [Regiones y zonas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) en la Guía del *usuario de Amazon EC2*.
Para cambiar opcionalmente el tamaño de la región geográfica en la que Route 53 dirige el tráfico a un recurso, especifique el valor aplicable para el sesgo:
+ Para ampliar el tamaño de la región geográfica en la que Route 53 dirige el tráfico a un recurso, especifique un número entero positivo de 1 a 99 para el sesgo. Route 53 reduce el tamaño de las regiones adyacentes.
+ Para contraer el tamaño de la región geográfica en la que Route 53 dirige el tráfico a un recurso, especifique un sesgo negativo de -1 a -99. Route 53 expande el tamaño de las regiones adyacentes.
**nota**
Estamos actualizando la consola de Flujo de tráfico para Route 53. Durante el periodo de transición, puede seguir utilizando la consola anterior.
Seleccione la pestaña de la consola que esté utilizando.
+ [Nueva consola](#traffic-flow-geoprox-routing-map-new)
+ [Consola antigua](#traffic-flow-geoprox-routing-map-old)
------
#### [ New console ]
El siguiente mapa muestra cuatro Regiones de AWS (numeradas del 1 al 5):
1. Oeste de EE. UU. (Oregón)
1. Europa (Fráncfort)
1. Asia-Pacífico (Tokio)
1. África (Ciudad del Cabo)
1. Middle East (Bahrain)
**nota**
Los mapas solo están disponibles con el Flujo de tráfico.
![\[Un mapa del mundo donde se muestra cómo se enruta el tráfico cuando se tienen registros de geoproximidad para recursos en las Regiones de AWS de Oeste de EE. UU. (Oregón), Europa (Fráncfort), Asia Pacífico (Tokio), África (Ciudad del Cabo) y Medio Oriente (Baréin).\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png)
En el siguiente mapa se muestra lo que sucede si agrega un sesgo de \$125 para la región Oeste de EE. UU. (Oregón) (número **1** en el mapa). El tráfico se enruta al recurso de esa región desde una parte mayor de Norteamérica que antes y desde toda Sudamérica.
![\[Un mapa del mundo que muestra cómo se dirige el tráfico cuando se agrega un sesgo de +25 en la región EE. UU. Este (Norte de Virginia).\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png)
En el siguiente mapa se muestra lo que sucede si cambia el sesgo a -25 para la región Oeste de EE. UU. (Oregón). **El tráfico se enruta al recurso de esa región desde partes más pequeñas de Norteamérica y Sudamérica que antes, y se dirige más tráfico a los recursos de las regiones **2**, **3** y 4 adyacentes.**
![\[Un mapa del mundo donde se muestra cómo se enruta el tráfico cuando se agrega un sesgo de -25 en la región Oeste de EE. UU. (Oregón).\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png)
------
#### [ Old console ]
El siguiente mapa muestra cuatro Regiones de AWS (numerados del 1 al 4) y una ubicación en Johannesburgo (Sudáfrica) que se especifica por latitud y longitud (5).
**nota**
Los mapas solo están disponibles con el Flujo de tráfico.
![\[Un mapa del mundo que muestra cómo se enruta el tráfico cuando tiene registros de geoproximidad de recursos en EE. UU. Oeste (Oregón), EE. UU. Este (Virginia del Norte), Europa (París) y Asia Pacífico (Tokio), y tiene un registro para una organización sin fines de lucro en Johannesburgo (Sudáfrica). Regiones de AWS AWS\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png)
El siguiente mapa muestra lo que sucede si agrega un sesgo de \$125 para la región Este de EE. UU. (Norte de Virginia) (número **2** en el mapa). El tráfico se direcciona al recurso de esa región desde una parte mayor de Norteamérica que antes y desde toda Sudamérica.
![\[Un mapa del mundo que muestra cómo se dirige el tráfico cuando se agrega un sesgo de +25 en la región EE. UU. Este (Norte de Virginia).\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png)
El siguiente mapa muestra lo que sucede si cambia el sesgo a -25 para la región Este de EE. UU. (Norte de Virginia). El tráfico se direcciona al recurso de esa región desde partes más pequeñas de América del Norte y del Sur que antes, y más tráfico se direcciona a los recursos de las regiones adyacentes **1**, **3** y **5**.
![\[Un mapa del mundo que muestra cómo se enruta el tráfico cuando se agrega un sesgo de -25 en la región Este de EE. UU. (Norte de Virginia).\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png)
------
El efecto de cambiar el sesgo de sus recursos depende de una serie de factores, entre los que se incluyen los siguientes:
+ El número de recursos de los que dispone.
+ Lo cercanos que están los recursos están entre si.
+ El número de usuarios que haya cerca de la zona fronteriza entre regiones geográficas. Por ejemplo, supongamos que tiene recursos en Regiones de AWS EE.UU. Este (Norte de Virginia) y EE.UU. Oeste (Oregón), y tiene muchos usuarios en Dallas, Austin y San Antonio, Texas, EE. UU. Esas ciudades están aproximadamente a la misma distancia entre sus recursos, por lo que un pequeño cambio en el sesgo podría provocar un gran cambio en el tráfico de los recursos de una Región de AWS a otra.
Le recomendamos que cambie el sesgo en incrementos pequeños para evitar desbordar los recursos debido a una oscilación no prevista en el tráfico.
Para obtener más información, consulte [Cómo utiliza Amazon Route 53 EDNS0 para estimar la ubicación de un usuario](routing-policy-edns0.md).
## Cómo utiliza Amazon Route 53 el sesgo para dirigir el tráfico
Esta es la fórmula que Amazon Route 53 utiliza para determinar cómo dirigir el tráfico:
**Sesgo**
`Biased distance = actual distance * [1 - (bias/100)]`
Cuando el valor del sesgo es positivo, Route 53 trata el origen de una consulta de DNS y el recurso que especifique en un registro de geoproximidad (como una instancia de EC2 en un registro Región de AWS) como si estuvieran más cerca de lo que realmente están. Suponga, por ejemplo, que tiene los siguientes registros de geoproximidad:
+ Un registro para el servidor web A, que tiene un sesgo positivo de 50.
+ Un registro para el servidor web B, que no tiene sesgos.
Cuando un registro de geoproximidad tiene un sesgo positivo de 50, Route 53 recorta a la mitad la distancia entre el origen de una consulta y el recurso para el registro. A continuación, Route 53 calcula qué recurso está más cerca del origen de la consulta. Supongamos que un servidor web A está a 150 kilómetros del origen de la consulta y que el servidor web B está a 100 kilómetros de dicho origen. Si ningún registro tiene un sesgo, Route 53 dirigirá la consulta al servidor web B porque está más cerca. No obstante, dado que el registro del servidor web A tiene un sesgo positivo de 50, Route 53 considera al servidor web A como si estuviera a 75 kilómetros del origen de la consulta. Como resultado, Route 53 dirige la consulta al servidor web A.
Este es el cálculo de un sesgo positivo de 50:
```
Bias = 50
Biased distance = actual distance * [1 - (bias/100)]
Biased distance = 150 kilometers * [1 - (50/100)]
Biased distance = 150 kilometers * (1 - .50)
Biased distance = 150 kilometers * (.50)
Biased distance = 75 kilometers
```
# Enrutado basado en latencia
Si la aplicación está alojada en varios servidores Regiones de AWS, puede mejorar el rendimiento de los usuarios atendiendo sus solicitudes desde el Región de AWS que ofrezca la latencia más baja.
**nota**
Los datos sobre la latencia entre los usuarios y sus recursos se basan totalmente en el tráfico entre los usuarios y los centros de datos de AWS . Si no utilizas los recursos en una Región de AWS, la latencia real entre tus usuarios y tus recursos puede variar considerablemente de los datos de AWS latencia. Esto es así aunque sus recursos se encuentren en la misma ciudad que una región de Región de AWS.
Para utilizar el enrutamiento basado en la latencia, debe crear registros de latencia para los recursos en varias Regiones de AWS. Cuando recibe una consulta de DNS para su dominio o subdominio (ejemplo.com o acme.ejemplo.com), Route 53 determina para qué Regiones de AWS usted ha creado registros de latencia, decide qué región ofrece a los usuarios la menor latencia y, finalmente, selecciona un registro de latencia para dicha región. Route 53 responde con el valor del registro seleccionado, como la dirección IP de un servidor web.
Por ejemplo, suponga que tiene equilibradores de carga elásticos en la región Oeste de EE. UU. (Oregón) y en la región Asia-Pacífico (Singapur). Crea un registro de latencia para cada equilibrador de carga. Esto es lo que ocurre cuando un usuario en Londres escribe el nombre de su dominio en un navegador:
1. DNS dirige la consulta a un servidor de nombres de Route 53.
1. Route 53 consulta los datos sobre latencia entre Londres y la región de Singapur, y entre Londres y la región de Oregón.
1. Si la latencia es menor entre las regiones de Londres y Oregón, Route 53 responde a la consulta con la dirección IP del equilibrador de carga de Oregón. Si la latencia es menor entre las regiones de Londres y Singapur, Route 53 responde a la consulta con la dirección IP del equilibrador de carga de Singapur.
La latencia entre hosts en Internet puede cambiar con el tiempo como consecuencia de los cambios en la conectividad de la red y el direccionamiento. El enrutamiento basado en la latencia se fundamenta en mediciones de latencia realizadas durante un periodo, y estas mediciones reflejan estos cambios. Una solicitud que se direccionó a la región de Oregón esta semana puede enrutarse a la región de Singapur la próxima semana.
**nota**
Cuando un navegador u otro visor utiliza una resolución de DNS que admite la edns-client-subnet extensión de EDNS0, la resolución de DNS envía a Route 53 una versión truncada de la dirección IP del usuario. Si configura el direccionamiento basado en la latencia, Route 53 considera este valor al dirigir el tráfico a sus recursos. Para obtener más información, consulte [Cómo utiliza Amazon Route 53 EDNS0 para estimar la ubicación de un usuario](routing-policy-edns0.md).
Puede utilizar una política de enrutamiento de latencia para los registros de una zona alojada privada.
Para obtener información acerca de los valores que especifica cuando se utiliza la política de direccionamiento de latencia para crear registros, consulte los siguientes temas:
+ [Valores específicos de registros de latencia](resource-record-sets-values-latency.md)
+ [Valores específicos de registros de alias de latencia](resource-record-sets-values-latency-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)
# Enrutado basado en latencia en zonas alojadas privadas
En el caso de las zonas alojadas privadas, Route 53 responde a las consultas de DNS con un punto final que se encuentra en el mismo Región de AWS punto final de la VPC Región de AWS de la que se originó la consulta o que está más cerca en cuanto a la distancia de la misma.
**nota**
Si se reenvía un punto de conexión saliente a un punto de conexión entrante, el registro se resolverá en función de dónde se encuentre el punto de conexión entrante, no el punto de conexión saliente.
Si incluye comprobaciones de estado y el registro con la latencia más baja hasta el origen de la consulta no está en buen estado, se devuelve un punto de conexión en buen estado con la siguiente latencia más baja.
En la configuración de ejemplo de la siguiente figura, las consultas de DNS procedentes de un Región de AWS us-east-1, o el más cercano a él, se enrutarán al punto final 1.1.1.1. Las consultas de DNS de us-west-2, o las más cercanas a esa región, se enrutarán al punto de conexión 2.2.2.2.
![\[Una captura de pantalla que muestra dos registros de latencia para una zona alojada privada.\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/latency-phz.png)
# Direccionamiento basado en IP
Con el enrutamiento basado en IP en Amazon Route 53, puede ajustar su enrutamiento DNS usando lo que sabe acerca de su red, aplicaciones y clientes para tomar las mejores decisiones de enrutamiento DNS para sus usuarios finales. El enrutamiento basado en IP le brinda un control detallado para optimizar el rendimiento o reducir los costos de la red al cargar sus datos a Route 53 en forma de mapeos. user-IP-to-endpoint
El enrutamiento basado en la geolocalización y la latencia se basa en los datos que Route 53 recopila y mantiene actualizados. Este enfoque funciona bien para la mayoría de los clientes, pero el enrutamiento basado en IP le ofrece la capacidad adicional de optimizar el enrutamiento en función del conocimiento específico de su base de clientes. Por ejemplo, un proveedor de contenidos global de video puede querer enrutar a los usuarios finales de un determinado proveedor de servicio de Internet (ISP).
Algunos casos de usos comunes para el enrutamiento basado en IP son los siguientes:
+ Desea dirigir a los usuarios finales desde determinados puntos finales a puntos finales específicos ISPs para poder optimizar los costos o el rendimiento del tránsito de la red.
+ Desea agregar anulaciones a los tipos de enrutamiento de Route 53 existentes, como el enrutamiento de geolocalización basado en su conocimiento de las ubicaciones físicas de sus clientes.
**Administrar los rangos de IP y asociarlos a un conjunto de registros de recursos () RRSet**
Para IPv4, puede usar bloques CIDR de entre 1 y 24 bits de longitud, ambos inclusive, mientras que paraIPv6, puede usar bloques CIDR de entre 1 y 48 bits de longitud, ambos inclusive. Para definir un bloque de CIDR de cero bits (0.0.0.0/0 o: ::/0), utilice la ubicación predeterminada (“\$1”).
Para consultas DNS con un CIDR más largo que el especificado en la colección CIDR, Route 53 las asociará con el CIDR más corto. Por ejemplo, si especificas 2001:0DB8: :/32 como bloque CIDR de tu colección CIDR y una consulta se origina en DB8 2001:0:0000:1234: :/48, coincidirá. Si, por otro lado, especifica 2001:0DB8: 0000:1234: :/48 en su colección CIDR y una consulta se origina en 2001:0DB8: :/32, no coincidirá y Route 53 responderá con el registro de la ubicación predeterminada («\$1»).
Puede agrupar conjuntos de bloques CIDR (o rangos de IP) en ubicaciones CIDR, que a su vez se agrupan en entidades reutilizables llamadas colecciones CIDR:
**Bloque CIDR**
Un rango de IP en notación CIDR, por ejemplo, 192.0.2.0/24 o 2001:: :/32. DB8
**Ubicación CIDR**
Una lista con nombre de bloques CIDR. Por ejemplo, example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001: :/32]. DB8 Los bloques de una lista de localización CIDR no tienen por qué ser adyacentes o del mismo rango.
Una única ubicación puede tener IPv6 bloques IPv4 y, y esta ubicación se puede asociar a los conjuntos de registros A y AAAA, respectivamente.
El nombre de la ubicación suele ser un lugar por convención, pero puede ser cualquier cadena, por ejemplo *Compañía-A*.
**Colección CIDR**
Una colección de ubicaciones con nombre. Por ejemplo, mycollection = [example-isp-seattle, example-isp-tokyo].
Los conjuntos de registros de recursos de enrutamiento basados en IP hacen referencia a una ubicación en una colección, y todos los conjuntos de registros de recursos para el mismo nombre y tipo de conjunto de registros deben hacer referencia a la misma colección. Por ejemplo, si crea sitios web en dos regiones y desea dirigir las consultas de DNS desde dos ubicaciones CIDR diferentes a un sitio web específico en función de las direcciones IP de origen, entonces ambas ubicaciones deben figurar en la misma colección CIDR.
No puede utilizar una política de enrutamiento basado en IP para los registros de una zona alojada privada.
Para obtener información sobre los valores que se especifican cuando se usa la política de enrutamiento basada en IP para crear registros, consulte los siguientes temas:
+ [Valores específicos para los registros basados en IP](resource-record-sets-values-ipbased.md)
+ [Valores específicos para los registros de alias basados en IP](resource-record-sets-values-ipbased-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)
**Topics**
+ [Creación de una colección de CIDR con ubicaciones y bloques CIDR](resource-record-sets-creating-cidr-collection.md)
+ [Trabajo con ubicaciones y bloques CIDR](resource-record-sets-working-with-cidr-locations.md)
+ [Eliminar una colección CIDR](resource-record-sets-delete-cidr-collection.md)
+ [Mover una geolocalización a un enrutamiento basado en IP](resource-record-sets-move-geolocation-to-cidr.md)
# Creación de una colección de CIDR con ubicaciones y bloques CIDR
Para empezar, cree una colección de CIDR y agregue a ella bloques y ubicaciones CIDR.
**Para crear una colección de CIDR mediante la consola de Route 53**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **IP-based routing** (Enrutamiento basado en IP) y, luego, **CIDR collections** (Recopilaciones de CIDR).
1. Seleccione **Create CIDR collection** (Crear una colección de CIDR).
1. En el panel **Create CIDR collection** en **Details** (Detalles), ingrese un nombre para la colección.
1. Elija **Create collection** (Crear colección) para crear una colección vacía.
-o bien-
En la sección **Crear ubicaciones del CIDR**, introduzca un nombre para la ubicación del CIDR en el cuadro de **Ubicación del CIDR**. El nombre de la ubicación puede ser cualquier cadena identificativa, por ejemplo **company 1**, o bien **Seattle**. No tiene por qué ser una ubicación geográfica real.
**importante**
El nombre de la ubicación del CIDR tiene una longitud máxima de 16 caracteres.
Introduzca los bloques del CIDR en el cuadro **Bloques del CIDR**, uno por línea. Pueden ser IPv6 direcciones IPv4 o direcciones comprendidas entre /0 y /24 y entre /0 IPv4 y /48. IPv6
1. Una vez ingresados los bloques CIDR, elija **Create CIDR collection**, o bien **Add another location** (Agregar otra ubicación) ingresando ubicaciones y bloque CIDR. Puede introducir varias ubicaciones CIDR por colección.
1. Una vez ingresadas las ubicaciones CIDR, seleccione **Create CIDR collection**.
# Trabajo con ubicaciones y bloques CIDR
**Para trabajar con ubicaciones CIDR mediante la consola de Route 53**
1. Inicie sesión en la consola de Route Consola de administración de AWS 53 y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. En el panel de navegación, seleccione **Enrutamiento basado en IP**, **Recopilaciones de CIDR** y, a continuación, en la sección **Recopilaciones de CIDR**, haga clic en un enlace a una recopilación de CIDR en la lista **Nombre de la recopilación**.
En la página **CIDR locations** (Ubicaciones CIDR), puede crear una ubicación CIDR, eliminarla o editar una ubicación y sus bloques.
+ Para crear una ubicación, seleccione **Create CIDR location** (Crear ubicación CIDR).
+ En el panel **Create CIDR location**, ingrese un nombre para la ubicación, los bloques CIDR asociados con la ubicación y, luego, seleccione **Create** (Crear).
+ Para ver una ubicación CIDR y los bloques que contiene, elija el botón de opción situado junto a una ubicación para mostrar su nombre y los bloques CIDR en el panel de ubicación.
En este panel, también puede elegir **Editar** para actualizar el nombre de la ubicación o sus bloques CIDR. Cuando haya terminado de editar, elija **Save** (Guardar).
+ Para eliminar una ubicación CIDR y los bloques de su interior, seleccione el botón de opción situado junto a la ubicación que desea eliminar y, a continuación, seleccione **Delete** (Borrar). Para confirmar la eliminación, escriba el nombre de la ubicación en el campo de entrada de texto y elija **Delete** de nuevo.
**importante**
No se puede deshacer la eliminación de una ubicación CIDR. Si tiene algún registro DNS asociado a la ubicación, es posible que no se pueda acceder a su dominio.
# Eliminar una colección CIDR
**Para eliminar una colección CIDR, sus ubicaciones y bloques mediante la consola de Route 53**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **IP-based routing** (Enrutamiento basado en IP) y, luego, **CIDR collections** (Recopilaciones de CIDR).
1. En la sección **CIDR collections**, haga clic en el nombre vinculado de la colección que desea eliminar.
1. En la página **CIDR locations** (Ubicaciones CIDR), seleccione cada ubicación de una en una, elija **Delete** (Eliminar), ingrese su nombre en el cuadro de diálogo y luego elija **Delete**. Debe eliminar cada ubicación asociada a una colección CIDR para poder eliminar la colección.
1. Una vez finalizada la eliminación de cada ubicación CIDR, en la página **CIDR locations**, elija el botón de opción junto a la colección que desea eliminar y, a continuación, elija **Delete**.
# Mover una geolocalización a un enrutamiento basado en IP
Si usa políticas de enrutamiento de geolocalización o geoproximidad, y ve constantemente clientes específicos enrutados a un punto de conexión que no es óptimo basado en su ubicación física o topología de red, puede orientar mejor los rangos de IP pública de estos clientes mediante el enrutamiento basado en IP.
La siguiente tabla contiene un ejemplo de configuración de geolocalización para un enrutamiento de geolocalización existente que afinaremos para los rangos IP de California.
| Nombre del conjunto de registros | Política de enrutamiento y origen | Dirección IP del punto de conexión de la aplicación |
| --- | --- | --- |
| example.com | Enrutamiento de geolocalización (EE. UU.) | `198.51.100.1` |
| example.com | Enrutamiento de geolocalización (UE) | `198.51.100.2` |
Para anular los rangos de IP de California para ir a un nuevo punto de conexión de la aplicación, primero vuelva a crear el enrutamiento de geolocalización bajo un nuevo nombre de conjunto de registros.
| Nombre del conjunto de registros | Política de enrutamiento y origen | Dirección IP del punto de conexión de la aplicación |
| --- | --- | --- |
| geo.ejemplo.com | Enrutamiento de geolocalización (EE.UU.) | `198.51.100.1` |
| geo.ejemplo.com | Enrutamiento de geolocalización (UE) | `198.51.100.2` |
Luego, cree registros de enrutamiento basados en IP y un registro por defecto que apunte a su conjunto de registros de enrutamiento de geolocalización recientemente recreado.
| Nombre del conjunto de registros | Política de enrutamiento y origen | Dirección IP del punto de conexión de la aplicación |
| --- | --- | --- |
| example.com | Enrutamiento basado en IP (predeterminado) | Registro de alias del punto de conexión de la aplicación geo.example.com que desea que sea el predeterminado. Por ejemplo, `198.51.100.1`. |
| example.com | Enrutamiento basado en IP (rangos IP de California) | `198.51.100.3` |
# Direccionamiento de respuesta con varios valores
El direccionamiento de respuesta con varios valores permite configurar Amazon Route 53 para devolver varios valores, como direcciones IP a los servidores web, en respuesta a las consultas de DNS. Puede especificar varios valores para casi cualquier registro, pero este direccionamiento también permite verificar el estado de cada recurso, por lo que Route 53 devuelve los valores únicamente para los recursos en buen estado. No es sustituto de un balanceador de carga, pero la capacidad de devolver varias direcciones IP (cuyo estado sea comprobable) constituye una forma de usar el DNS para mejorar la disponibilidad y el equilibrio de la carga.
Para dirigir el tráfico de forma aproximativa aleatoriamente a varios recursos, como servidores web, cree un registro de respuesta con varios valores para cada recurso y, de manera opcional, asocie una comprobación de estado de Route 53 a cada registro. Route 53 responde a las consultas de DNS con hasta ocho registros en buen estado y da diferentes respuestas a distintos solucionadores de DNS. Si un servidor web deja de estar disponible después de que un solucionador almacene una respuesta en memoria caché, el software de cliente puede intentar utilizar otra dirección IP en la respuesta.
Tenga en cuenta lo siguiente:
+ Si asocia una comprobación de estado a un registro de respuesta con varios valores, Route 53 responde a las consultas de DNS con la correspondiente dirección IP solo si se verifica que está en buen estado.
+ Si no asocia ninguna comprobación de estado a un registro de respuesta con varios valores, Route 53 siempre considera que el registro está en buen estado.
+ Si tiene ocho registros o menos en buen estado, Route 53 responde a todas las consultas de DNS con todos los registros en buen estado.
+ Cuando todos los registros están en mal estado, Route 53 responde a las consultas de DNS con hasta ocho registros en mal estado.
Puede utilizar una política de enrutamiento de respuesta con varios valores para los registros de una zona alojada privada.
Para obtener más información acerca de los valores que especifica cuando se utiliza la política de enrutamiento de respuesta multivalor para crear registros, consulte [Valores específicos de registros de respuesta de varios valores](resource-record-sets-values-multivalue.md) y [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md).
# Direccionamiento ponderado
El direccionamiento ponderado permite asociar varios recursos a un solo nombre de dominio (example.com) o nombre de subdominio (acme.example.com) y elegir cuánto tráfico se redirige a cada recurso. Esto puede resultar útil para distintos fines, entre otros, equilibrar la carga y probar nuevas versiones de software.
Para configurar el direccionamiento ponderado, debe crear registros que tengan el mismo nombre y tipo para cada uno de sus recursos. Asigne a cada registro un peso relativo que se corresponda con la cantidad de tráfico que desea enviar a cada recurso. Amazon Route 53 envía el tráfico a un recurso en función del peso que se asigna al registro, como una proporción del peso total de todos los registros del grupo:
![\[Fórmula para determinar cuánto tráfico se dirige a un recurso determinado: ponderación de un registro especificado/suma de las ponderaciones de todos los registros.\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/WRR_calculation.png)
Por ejemplo, si desea enviar una pequeña parte del tráfico a un recurso y el resto a otro recurso, puede especificar pesos de 1 y 255. El recurso con un peso de 1 se lleva una fracción de 1/256 del tráfico (1/(1\$1255)), y el otro recurso, 255/256 (255/(1\$1255)). Para modificar gradualmente el equilibrio puede cambiar los pesos. Si desea detener el envío de tráfico a un recurso, puede cambiar por 0 el peso de ese registro.
Para obtener información acerca de los valores que especifica cuando se utiliza la política de direccionamiento ponderado para crear registros, consulte los siguientes temas:
+ [Valores específicos de registros ponderados](resource-record-sets-values-weighted.md)
+ [Valores específicos de registros de alias ponderados](resource-record-sets-values-weighted-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)
Puede utilizar una política de enrutamiento ponderado para los registros de una zona alojada privada.
## Comprobaciones de estado y enrutamiento ponderado
Si agrega comprobaciones de estado a todos los registros de un grupo de registros ponderados, pero asigna ponderaciones distintas de cero a algunos registros y ponderaciones cero a otros, las comprobaciones de estado funcionan igual que si todos los registros tuvieran ponderaciones distintas de cero con las excepciones siguientes:
+ Route 53 tiene en cuenta inicialmente solo los registros con ponderación distinta de cero, si los hubiera.
+ Si todos los registros con una ponderación mayor que 0 tienen un estado incorrecto, Route 53 tiene en cuenta los registros con ponderación cero.
En la siguiente tabla, se detalla el comportamiento cuando el registro de ponderación 0 incluye una comprobación de estado:
| | Registro 1 | Registro 2 | Registro 3 |
| --- |--- |--- |--- |
| Peso | 1 | 1 | 0 |
| ¿Incluye comprobación de estado? | Sí | Sí | Sí |
| |
| --- |
| Health check status (Estado de la comprobación de estado) | Mal estado | Mal estado | Buen estado |
| ¿Consulta de DNS respondida? | No | No | Sí |
| |
| --- |
| Health check status (Estado de la comprobación de estado) | Mal estado | Mal estado | Mal estado |
| ¿Consulta de DNS respondida? | Sí | Sí | No |
| |
| --- |
| Health check status (Estado de la comprobación de estado) | Mal estado | Buen estado | Mal estado |
| ¿Consulta de DNS respondida? | No | Sí | No |
| |
| --- |
| Health check status (Estado de la comprobación de estado) | Buen estado | Buen estado | Mal estado |
| ¿Consulta de DNS respondida? | Sí | Sí | No |
| |
| --- |
| Health check status (Estado de la comprobación de estado) | Buen estado | Buen estado | Buen estado |
| ¿Consulta de DNS respondida? | Sí | Sí | No |
En la siguiente tabla, se detalla el comportamiento cuando el registro de ponderación 0 no incluye una comprobación de estado:
| | Registro 1 | Registro 2 | Registro 3 |
| --- |--- |--- |--- |
| Peso | 1 | 1 | 0 |
| ¿Incluye comprobación de estado? | Sí | Sí | No |
| |
| --- |
| Health check status (Estado de la comprobación de estado) | Buen estado | Buen estado | N/A |
| ¿Consulta de DNS respondida? | Sí | Sí | No |
| |
| --- |
| Health check status (Estado de la comprobación de estado) | Mal estado | Mal estado | N/A |
| ¿Consulta de DNS respondida? | No | No | Sí |
| |
| --- |
| Health check status (Estado de la comprobación de estado) | Mal estado | Buen estado | N/A |
| ¿Consulta de DNS respondida? | No | Sí | No |
# Cómo utiliza Amazon Route 53 EDNS0 para estimar la ubicación de un usuario
Para mejorar la precisión de la geolocalización, la geoproximidad, el enrutamiento basado en IP y la latencia, Amazon Route 53 admite la extensión de. edns-client-subnet EDNS0 (EDNS0 añade varias extensiones opcionales al protocolo DNS). Route 53 edns-client-subnet solo se puede usar cuando los resolutores de DNS lo admiten:
+ Cuando un navegador u otro visor usa una resolución de DNS que no es compatible edns-client-subnet, Route 53 usa la dirección IP de origen de la resolución de DNS para aproximar la ubicación del usuario y responde a las consultas de geolocalización con el registro DNS de la ubicación de la resolución.
+ Cuando un navegador u otro visor utiliza una resolución de DNS compatible edns-client-subnet, la resolución de DNS envía a Route 53 una versión truncada de la dirección IP del usuario. Route 53 determina la ubicación del usuario a través de la dirección IP truncada, en lugar de hacerlo mediante la dirección IP de origen del solucionador de DNS; este método suele proporcionar una estimación más precisa de la ubicación del usuario. Después, Route 53 responde a las consultas de geolocalización con el registro de DNS de la ubicación del usuario.
+ EDNS0 no se aplica a las zonas alojadas privadas. En el caso de las zonas alojadas privadas, Route 53 utiliza los datos de los solucionadores de VPC en los Región de AWS que se encuentra la zona alojada privada para tomar decisiones de geolocalización y enrutamiento de latencia.
[Para obtener más información edns-client-subnet, consulte el RFC de la subred del cliente de EDNS y la subred del cliente en las solicitudes de DNS.](https://www.rfc-editor.org/rfc/rfc7871)
# Elección entre registros de alias y sin alias
Los *registros de alias* de Amazon Route 53 proporcionan una extensión específica de Route 53 para la funcionalidad de DNS. Los registros de alias le permiten enrutar el tráfico a AWS los recursos seleccionados, incluidas, entre otras, las CloudFront distribuciones y los buckets de Amazon S3. También le permiten dirigir el tráfico de un registro de una zona alojada a otro registro.
A diferencia de un registro CNAME, puede crear un registro de alias en el nodo superior de un espacio de nombres de DNS, también conocido como *vértice de zona*. Por ejemplo, si registra el nombre DNS example.com, el vértice de zona será example.com. No puede crear un registro CNAME para example.com, aunque sí puede crear un registro de alias para example.com que dirige el tráfico a www.example.com (siempre que el tipo de registro para www.example.com no sea el tipo CNAME).
Cuando Route 53 recibe una consulta de DNS para un registro de alias, Route 53 responde con el valor aplicable de dicho recurso:
+ **Una API regional personalizada o una optimizada para periferia de Amazon API Gateway**: Route 53 responde con una o varias direcciones IP para la API.
+ **Un punto de conexión de interfaz de Amazon VPC**: Route 53 responde con una o varias direcciones IP para el punto de conexión de interfaz.
+ **Una CloudFront distribución**: Route 53 responde con una o más direcciones IP para los servidores CloudFront perimetrales que pueden ofrecer su contenido.
+ **Servicio de App Runner**: Route 53 responde con una o varias direcciones IP.
+ **Un entorno de Elastic Beanstalk**: Route 53 responde con una o varias direcciones IP para el entorno.
+ **Un equilibrador de carga elástico**: Route 53 responde con una o varias direcciones IP para el equilibrador de carga. Esto incluye el equilibrador de carga de aplicación, el equilibrador de carga clásico y el equilibrador de carga de red.
+ **Un AWS Global Accelerator acelerador**: Route 53 responde con las direcciones IP del acelerador.
+ **Un OpenSearch servicio**: Route 53 responde con una o más direcciones IP para el dominio personalizado del OpenSearch servicio.
+ **Un bucket de Amazon S3 configurado como sitio web estático**: Route 53 responde con una dirección IP para el bucket de Amazon S3.
+ **Otro registro de Route 53 del mismo tipo de la misma zona alojada**: Route 53 responde como si la consulta fuera para el registro al que hace referencia el registro de alias (consulte [Comparación de los registros de alias y CNAME](#resource-record-sets-choosing-alias-non-alias-comparison)).
+ **AWS AppSync nombre de dominio**: Route 53 responde con una o más direcciones IP para el punto final de la interfaz.
Para obtener más información, consulte [Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
Cuando usa un registro de alias para enrutar el tráfico a un AWS recurso, Route 53 reconoce automáticamente los cambios en el recurso. Por ejemplo, suponga que un registro de alias para ejemplo.com apunta a un equilibrador de carga elástico en lb1-1234.us-east-2.elb.amazonaws.com. Si la dirección IP del balanceador de carga cambia, Route 53 se inicia automáticamente para responder a las consultas de DNS utilizando la nueva dirección IP.
Si un registro de alias apunta a un AWS recurso, no puede establecer el tiempo de vida (TTL); Route 53 usa el TTL predeterminado para el recurso. Si un registro de alias apunta a otro registro de la misma zona alojada, Route 53 utiliza el TTL del registro al que apunta el registro de alias. Para obtener más información sobre el valor de TTL actual de Elastic Load Balancing, consulte [Enrutamiento de solicitudes](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing) en la *Guía del usuario de Elastic Load Balancing* y busque “ttl”.
Para obtener información sobre cómo crear registros mediante la consola de Route 53, consulte [Creación de registros con la consola de Amazon Route 53](resource-record-sets-creating.md). Para obtener información acerca de los valores que especifique para registros de alias, consulte el tema correspondiente en [Valores que hay que especificar al crear o editar los registros de Amazon Route 53.](resource-record-sets-values.md):
+ [Valores específicos para registros de alias simples](resource-record-sets-values-alias.md)
+ [Valores específicos de registros de alias ponderados](resource-record-sets-values-weighted-alias.md)
+ [Valores específicos de registros de alias de latencia](resource-record-sets-values-latency-alias.md)
+ [Valores específicos de registros de alias de conmutación por error](resource-record-sets-values-failover-alias.md)
+ [Valores específicos de registros de alias de geolocalización](resource-record-sets-values-geo-alias.md)
+ [Valores específicos de registros de alias de geoproximidad](resource-record-sets-values-geoprox-alias.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)
## Comparación de los registros de alias y CNAME
Los registros de alias se parecen a los registros CNAME, pero hay algunas diferencias importantes. La siguiente lista compara los registros de alias y los registros CNAME.
**Recursos a los que puede redirigir consultas**
**Registros de alias**
Un registro de alias solo puede redirigir las consultas a AWS los recursos seleccionados, incluidos, entre otros, los siguientes:
+ Buckets de Amazon S3
+ CloudFront distribuciones
+ Otro registro de la misma zona alojada de Route 53
Por ejemplo, puede crear un registro de alias denominado acme.example.com que redirija las consultas a un bucket de Amazon S3 que también se denomine acme.example.com. También puede crear un registro de alias de acme.example.com que redirija las consultas a un registro denominado zenith.example.com de la zona alojada de example.com.
**Registros CNAME**
Un registro CNAME puede redirigir las consultas de DNS a cualquier registro de DNS. Por ejemplo, puede crear un registro CNAME que redirija las consultas de acme.example.com a zenith.example.com o a acme.example.org. No tiene que utilizar Route 53 como servicio de DNS para el dominio al que está redirigiendo las consultas.
**Crear registros que tengan el mismo nombre que el dominio (registros en el vértice de zona)**
**Registros de alias**
En la mayoría de las configuraciones, puede crear un registro de alias que tenga el mismo nombre que la zona alojada (vértice de zona). La única excepción se da cuando desea redirigir consultas desde el vértice de zona (como example.com) a un registro de la misma zona alojada que tiene un tipo de CNAME (como zenith.example.com). El registro de alias debe tener el mismo tipo que el registro al que está redirigiendo el tráfico y no es posible crear un registro CNAME para el vértice de zona (ni siquiera para un registro de alias).
**Registros CNAME**
No se puede crear un registro CNAME que tenga el mismo nombre que la zona alojada (vértice de zona). Esto es válido tanto para las zonas hospedadas de nombres de dominio (example.com) como para las zonas hospedadas de subdominios (zenith.example.com).
**Precios para consultas de DNS**
**Registros de alias**
Route 53 no cobra por las consultas de alias a AWS los recursos. Para obtener más información, consulte [Precios de Amazon Route 53](https://aws.amazon.com/route53/pricing/).
**Registros CNAME**
Route 53 cobra por las consultas CNAME.
Si crea un registro CNAME que redirige al nombre de otro registro en una zona alojada de Route 53 (la misma zona alojada u otra), cada consulta de DNS se carga como dos consultas:
+ Route 53 responde a la primera consulta de DNS con el nombre del registro al que desea redirigir.
+ A continuación, el solucionador de DNS debe enviar otra consulta para el registro en la primera respuesta para obtener información sobre dónde dirigir el tráfico, por ejemplo, la dirección IP de un servidor web.
Si el registro CNAME redirige al nombre de un registro alojado con otro servicio de DNS, Route 53 carga una consulta. El otro servicio de DNS podría cargar la segunda consulta.
**Tipo de registro especificado en la consulta de DNS**
**Registros de alias**
Route 53 responde a una consulta de DNS solo cuando el nombre del registro de alias (como acme.example.com) y el tipo del registro de alias (como A o AAAA) coinciden con el nombre y el tipo de la consulta de DNS.
**Registros CNAME**
Un registro CNAME redirige las consultas de DNS para un nombre de registro independientemente del tipo de registro especificado en la consulta de DNS, como A o AAAA.
**Cómo se enumeran los registros en las consultas de dig o nslookup**
**Registros de alias**
En la respuesta a una consulta de dig o nslookup, se muestra un registro de alias como el tipo de registro que especificó al crear el registro, como A o AAAA. (El tipo de registro que especifique para un registro de alias depende del recurso al que esté dirigiendo el tráfico. Por ejemplo, para dirigir tráfico a un bucket de S3, especifique A en el tipo). La propiedad alias solo está visible en la consola de Route 53 o en la respuesta a una solicitud programática, como un `list-resource-record-sets` comando AWS CLI.
**Registros CNAME**
Un registro CNAME aparece como registro CNAME en respuesta a consultas dig o nslookup.
# Tipos de registros de DNS admitidos
Amazon Route 53 admite los tipos de registros de DNS que se indican en esta sección. Cada tipo de registro incluye también un ejemplo de cómo formatear el elemento `Value` cuando tenga acceso a Route 53 mediante la API.
**nota**
Para los tipos de registros que incluyen un nombre de dominio, especifique un nombre de dominio completo (por ejemplo, *www.example.com*). El punto final es opcional; Route 53 presupone que el nombre de dominio es completo. Esto significa que Route 53 trata a *www.example.com* (sin punto final) y *www.example.com.* (con punto final) de idéntica forma.
Route 53 proporciona una extensión a la funcionalidad DNS conocida como registros de alias. De forma parecida a los registros CNAME, los registros de alias le permiten dirigir el tráfico a recursos de AWS seleccionados, como, por ejemplo, distribuciones de CloudFront o buckets de Amazon S3. Para obtener más información, incluida una comparación de registros CNAME y alias, consulte [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Un tipo de registro](#AFormat)
+ [Tipo de registro AAAA](#AAAAFormat)
+ [Tipo de registro de CAA](#CAAFormat)
+ [Tipo de registro CNAME](#CNAMEFormat)
+ [Tipo de registro DS](#DSFormat)
+ [Tipo de registro HTTPS](#HTTPSFormat)
+ [Tipo de registro MX](#MXFormat)
+ [Tipo de registro NAPTR](#NAPTRFormat)
+ [Tipo de registro NS](#NSFormat)
+ [Tipo de registro PTR](#PTRFormat)
+ [Tipo de registro SOA](#SOAFormat)
+ [Tipo de registro SPF](#SPFFormat)
+ [Tipo de registro SRV](#SRVFormat)
+ [Registro de tipo SSHFP](#SSHFPFormat)
+ [Registro de tipo SVCB](#SVCBFormat)
+ [Registro de tipo TLSA](#TLSAFormat)
+ [Tipo de registro TXT](#TXTFormat)
## Un tipo de registro
Utilice un registro A para enrutar el tráfico a un recurso, por ejemplo un servidor web, mediante una dirección IPv4 en notación decimal con puntos.
**Ejemplo de la consola de Amazon Route 53**
```
192.0.2.1
```
**Ejemplo de la API de Route**
```
192.0.2.1
```
## Tipo de registro AAAA
Utilice un registro AAAA para enrutar el tráfico a un recurso, como un servidor web, mediante una dirección IPv6 en formato hexadecimal separada con el carácter de dos puntos.
**Ejemplo de la consola de Amazon Route 53**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
**Ejemplo de la API de Route**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
## Tipo de registro de CAA
Un registro de CAA especifica qué entidades de certificación (CA) están autorizadas a emitir certificados para un dominio o subdominio. La creación de un registro de CAA ayuda a evitar que una CA errónea emita certificados para sus dominios. Un registro de CAA no es un sustituto de los requisitos de seguridad que especifica su entidad de certificación como, por ejemplo, la necesidad de validar que usted es el propietario de un dominio.
Puede utilizar los registros CAA para especificar lo siguiente:
+ Qué autoridades de certificación (CA, Certificate Authority) pueden emitir certificados SSL/TLS, si procede.
+ La dirección de correo electrónico o URL con la que hay que contactar en caso de que una CA emita un certificado para el dominio o subdominio.
Cuando añade un registro de CAA a su zona alojada, debe especificar tres valores separados por espacios:
`flags tag "value"`
Tenga en cuenta lo siguiente en relación con el formato de los registros CAA:
+ El valor de `tag` solo puede contener los caracteres A-Z, a-z y 0-9.
+ Encuadre siempre `value` entre comillas ("").
+ Algunas CA permiten o requieren valores adicionales para `value`. Especifique valores adicionales como pares nombre-valor y sepárelos con punto y coma (;), por ejemplo:
`0 issue "ca.example.net; account=123456"`
+ En caso de que una CA reciba una solicitud de certificado para un subdominio (como www.example.com) y si no existe registro de CAA del subdominio, la CA enviará una consulta de DNS para un registro de CAA para el dominio principal (como example.com). Si existe un registro de dominio principal y si la solicitud de certificado es válida, la CA genera el certificado para el subdominio.
+ Le recomendamos que consulte a su CA para determinar qué valores especificar para un registro de CAA.
+ No se puede crear un registro de CAA y un registro CNAME que tengan el mismo nombre, ya que el DNS no permite utilizar el mismo nombre para un registro CNAME y cualquier otro tipo de registro.
**Topics**
+ [Autorización a una CA a emitir un certificado para un dominio o subdominio](#CAAFormat-issue)
+ [Autorización a una CA a emitir un certificado comodín para un dominio o subdominio](#CAAFormat-issue-wild)
+ [Evitar que cualquier CA emita un certificado para un dominio o un subdominio](#CAAFormat-prevent-issue)
+ [Solicitar que cualquier CA se ponga en contacto con usted si la CA recibe una solicitud de certificado no válida](#CAAFormat-contact)
+ [Uso de otra opción compatible con la CA](#CAAFormat-custom-setting)
+ [Ejemplos](#CAAFormat-examples)
### Autorización a una CA a emitir un certificado para un dominio o subdominio
Para autorizar a una CA a emitir un certificado para un dominio o un subdominio, cree un registro que tenga el mismo nombre que el dominio o subdominio y especifique la siguiente configuración:
+ **marcadores** – `0`
+ **etiqueta** – `issue`
+ **valor**: el código de la CA a la que autoriza a emitir un certificado para el dominio o subdominio
Por ejemplo, suponga que desea autorizar ca.example.net para que emita un certificado para example.com. Puede crear un registro de CAA para example.com con la siguiente configuración:
```
0 issue "ca.example.net"
```
Para obtener información sobre cómo autorizar AWS Certificate Manager para emitir un certificado, consulte [Configuración de un registro de CAA](https://docs.aws.amazon.com/acm/latest/userguide/setup-caa.html) en la *Guía del usuario de AWS Certificate Manager*.
### Autorización a una CA a emitir un certificado comodín para un dominio o subdominio
Para autorizar a una CA a emitir un certificado comodín para un dominio o subdominio, cree un registro que tenga el mismo nombre que el dominio o subdominio y especifique la siguiente configuración: Un certificado comodín se aplica al dominio o subdominio y a todos sus subdominios.
+ **marcadores** – `0`
+ **etiqueta** – `issuewild`
+ **valor**: el código de la CA a la que autoriza a emitir un certificado para un dominio o subdominio y sus subdominios
Por ejemplo, suponga que desea autorizar a ca.example.net a emitir un certificado comodín para example.com, que se aplica a example.com y todos sus subdominios. Puede crear un registro de CAA para example.com con la siguiente configuración:
```
0 issuewild "ca.example.net"
```
Cuando quiera autorizar a una CA a emitir un certificado comodín para un dominio o subdominio, cree un registro que tenga el mismo nombre que el dominio o subdominio y especifique la siguiente configuración: Un certificado comodín se aplica al dominio o subdominio y a todos sus subdominios.
### Evitar que cualquier CA emita un certificado para un dominio o un subdominio
Para evitar que cualquier CA emita un certificado para un dominio o un subdominio, cree un registro que tenga el mismo nombre que el dominio o subdominio y especifique la siguiente configuración:
+ **marcadores** – `0`
+ **etiqueta** – `issue`
+ **valor** – `";"`
Por ejemplo, suponga que no desea que ninguna CA emita un certificado para example.com. Puede crear un registro de CAA para example.com con la siguiente configuración:
`0 issue ";"`
Si no quiere que ninguna CA emita un certificado para example.com o sus subdominios, debe crear un registro de CAA para example.com con la siguiente configuración:
`0 issuewild ";"`
**nota**
Si crea un registro de CAA para example.com y especifica los dos valores siguientes, una CA que utiliza el valor ca.example.net puede emitir el certificado para example.com:
```
0 issue ";"
0 issue "ca.example.net"
```
### Solicitar que cualquier CA se ponga en contacto con usted si la CA recibe una solicitud de certificado no válida
Si desea que toda CA que reciba una solicitud no válida de certificado se ponga en contacto con usted, especifique la siguiente configuración:
+ **marcadores** – `0`
+ **etiqueta** – `iodef`
+ **valor**: la dirección URL o la dirección de correo electrónico a la que desea que la CA envíe una notificación si recibe una solicitud no válida de certificado. Use el formato aplicable:
`"mailto:email-address"`
`"http://URL"`
`"https://URL"`
Por ejemplo, si desea que toda CA que recibe una solicitud no válida de certificado envíe un correo electrónico a admin@example.com, cree un registro de CAA con la siguiente configuración:
```
0 iodef "mailto:admin@example.com"
```
### Uso de otra opción compatible con la CA
Si la CA admite una característica que no está definida en RFC para registros de CAA, especifique la siguiente configuración:
+ **marcadores**: 128 (este valor impide que la CA emita un certificado si esta no es compatible con la característica especificada).
+ **etiqueta**: la etiqueta que la CA tiene permiso para utilizar
+ **valor**: el valor que corresponde al valor de etiqueta
Por ejemplo, suponga que la CA admita el envío de un mensaje de texto si recibe una solicitud de certificado no válida. (No somos conscientes de que haya ninguna CA que admita esta opción). La configuración del registro podría ser la siguiente:
```
128 exampletag "15555551212"
```
### Ejemplos
**Ejemplo de la consola de Route**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
**Ejemplo de la API de Route**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
## Tipo de registro CNAME
Un registro CNAME asigna consultas DNS para el nombre del registro actual, como acme.example.com, a otro dominio (example.com o example.net) o subdominio (acme.example.com o zenith.example.org).
**importante**
El protocolo DNS no permite crear un registro CNAME para el nodo superior de un espacio de nombres de DNS, también conocido como ápex de zona. Por ejemplo, si registra el nombre DNS example.com, el vértice de zona será example.com. No puede crear un registro CNAME para ejemplo.com, pero puede crear registros CNAME para www.ejemplo.com, nuevoproducto.ejemplo.com, etcétera.
Además, si crea un registro CNAME para un subdominio, no puede crear ningún otro registro para ese subdominio. Por ejemplo, si crea un CNAME para www.example.com, no puede crear ningún otro registro para el que el valor del campo **Name (Nombre)** sea www.example.com.
Amazon Route 53 admite también registros de alias, que le permiten dirigir las consultas a recursos de AWS seleccionados, como distribuciones de CloudFront y buckets de Amazon S3. Los alias son similares en cierto sentido al tipo de registro CNAME; sin embargo, puede crear un alias para el ápex de zona. Para obtener más información, consulte [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md).
**Ejemplo de la consola de Route**
```
hostname.example.com
```
**Ejemplo de la API de Route**
```
hostname.example.com
```
## Tipo de registro DS
Un registro de firmante de delegación (DS) hace referencia a una clave de zona para una zona de subdominio delegada. Puede crear un registro DS cuando establezca una cadena de confianza al configurar la firma DNSSEC. Para obtener más información sobre la configuración de DNSSEC en Route 53, consulte [Configuración de la firma de DNSSEC en Amazon Route 53](dns-configuring-dnssec.md).
Los tres primeros valores son números decimales que representan la etiqueta de clave, el algoritmo y el tipo de resumen. El cuarto valor es el resumen de la clave de zona. Para obtener más información acerca del formato del registro DS, consulte [RFC 4034](https://www.ietf.org/rfc/rfc4034.txt).
**Ejemplo de la consola de Route**
```
123 4 5 1234567890abcdef1234567890absdef
```
**Ejemplo de la API de Route**
```
123 4 5 1234567890abcdef1234567890absdef
```
## Tipo de registro HTTPS
Un registro de recursos HTTPS es un tipo de registro de DNS de Service Binding (SVCB) que proporciona información de configuración adicional, lo que permite al cliente conectarse de forma fácil y segura a un servicio con un protocolo HTTP. La información de configuración se proporciona en parámetros que permiten la conexión en una consulta de DNS, en lugar de necesitar varias consultas de DNS.
El formato de los registros de recursos HTTPS es:
`SvcPriority TargetName SvcParams(optional)`
Los siguientes parámetros están descritos en la [sección 9.1 del RFC 9460](https://www.rfc-editor.org/rfc/rfc9460.html#section-9.1).
**SvcPriority**
Un número entero que representa la prioridad. La prioridad 0 significa modo de alias y, por lo general, está destinada para la creación de alias en el vértice de zona. Este valor es un número entero del 0 al 32 767 para Route 53, de los cuales 1 a 32 767 son registros de modo de servicio. Cuanto menor sea la prioridad, mayor será la preferencia.
**TargetName**
El nombre de dominio del alias objetivo (para el modo de alias) o del punto de conexión alternativo (para ServiceMode).
**SvcParams (opcional)**
Una lista separada por espacios en blanco en la que cada parámetro consta de un par clave=valor o de una clave independiente. En caso de haber más de un valor, se presentan en forma de lista separada por comas. A continuación se detallan los SvcParams definidos:
+ `1:alpn`: identificadores de protocolos de negociación de protocolo de capa de aplicación. El valor predeterminado es HTTP/1.1, `h2` es HTTP/2 sobre TLS y `h3` es HTTP/3 (HTTP sobre el protocolo QUIC).
+ `2:no-default-alpn`: el valor predeterminado no es compatible y debe proporcionar un parámetro `alpn`.
+ `3:port`: el punto de conexión alternativo o el puerto en el que se puede acceder al servicio.
+ `4:ipv4hint`: sugerencias de la dirección IPv4.
+ `5:ech`: saludo del cliente cifrado.
+ `6:ipv6hint`: sugerencias de la dirección IPv6.
+ `7:dohpath`: plantilla de DNS sobre HTTPS.
+ `8:ohttp`: el servicio opera con un objetivo Oblivious HTTP.
**Ejemplo de la consola de Amazon Route 53 para el modo de alias**
```
0 example.com
```
**Ejemplo de la consola de Amazon Route 53 para el modo de servicio**
```
16 example.com alpn="h2,h3" port=808
```
**Ejemplo de la API de Amazon Route 53 para el modo de alias**
```
0 example.com
```
**Ejemplo de la API de Amazon Route 53 para el modo de servicio**
```
16 example.com alpn="h2,h3" port=808
```
Para obtener más información, consulte el [RFC 9460, Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)](https://datatracker.ietf.org/doc/html/rfc9460).
**nota**
Route 53 no admite el formato de presentación arbitrario de clave desconocida `keyNNNNN`.
## Tipo de registro MX
Un registro MX especifica los nombres de los servidores de correo y, si tiene dos o más servidores de este tipo, el orden de prioridad. Cada valor de un registro MX contiene dos valores, que son la prioridad y el nombre del dominio.
**Prioridad**
Un número entero que representa la prioridad de un servidor de correo electrónico. Si especifica un único servidor, la prioridad puede ser cualquier número entero comprendido entre 0 y 65535. Si especifica varios servidores, el valor que especifique para la prioridad indica el primer servidor de correo electrónico al que se debe enviar el correo electrónico, el segundo y así sucesivamente. El servidor que tenga el valor más bajo para la prioridad será el prioritario. Por ejemplo, si tiene dos servidores de correo electrónico y especifica los valores de 10 y 20 para la prioridad, el correo electrónico siempre se envía al servidor con la prioridad de 10 a menos que no esté disponible. Si especifica los valores de 10 y 10, el correo electrónico se redirige a los dos servidores aproximadamente en partes iguales.
**Nombre del dominio**
El nombre del dominio del servidor de correo electrónico. Especifique el nombre (por ejemplo, mail.example.com) de un registro A o AAAA. En [RFC 2181, Clarifications to the DNS Specification](https://tools.ietf.org/html/rfc2181), la sección 10.3 prohíbe especificar el nombre de un registro CNAME para valor del nombre de dominio. (Cuando la especificación RFC habla de “alias”, se refiere a un registro CNAME, no a un registro de alias de Route 53).
**Ejemplo de la consola de Amazon Route 53**
```
10 mail.example.com
```
**Ejemplo de la API de Route**
```
10 mail.example.com
```
## Tipo de registro NAPTR
Un NAPTR (Name Authority Pointer, Señalizador de autoridad de asignación de nombres) es un tipo de registro que usan las aplicaciones DDDS (Dynamic Delegation Discovery System, Sistema de detección de delegación dinámica) para convertir un valor en otro o para sustituir un valor por otro. Por ejemplo, un uso habitual es convertir los números de teléfono en URI de SIP.
El elemento `Value` de un registro NAPTR consta de seis valores separados por espacios:
**Order**
Cuando especifica más de un registro, el orden en que desea que la aplicación DDDS evalúe los registros. Valores válidos: 0 - 65535.
**Preference**
Cuando especifica dos o más registros que tienen el mismo valor de **Order**, el orden preferido en el que desea que se evalúen esos registros. Por ejemplo, si dos registros tienen un valor de **Order** de 1, la primera aplicación DDDS evalúa el registro que tiene el valor de **Preference** menor. Valores válidos: 0 - 65535.
**Indicadores**
Un valor específico de las aplicaciones DDDS. Los valores definidos actualmente en [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt) son las letras mayúsculas y minúsculas **"A"**, **"P"**, **"S"** y **"U"** y la cadena vacía, **""**. Incluya los valores de **Flags** entre comillas.
**Servicio**
Un valor específico de las aplicaciones DDDS. Incluya los valores de **Service** entre comillas.
Para obtener más información, consulte los RFC correspondientes:
+ **Aplicación DDDS URI**: [https://tools.ietf.org/html/rfc3404\$1section-4.4](https://tools.ietf.org/html/rfc3404#section-4.4)
+ **Aplicación DDDS S-NAPTR**: [https://tools.ietf.org/html/rfc3958\$1section-6.5](https://tools.ietf.org/html/rfc3958#section-6.5)
+ **Aplicación DDDS U-NAPTR**: [https://tools.ietf.org/html/rfc4848\$1section-4.5](https://tools.ietf.org/html/rfc4848#section-4.5)
**Regexp**
Una expresión regular que la aplicación DDDS utiliza para convertir un valor de entrada en un valor de salida. Por ejemplo, un sistema de telefonía por IP podría utilizar una expresión regular para convertir un número de teléfono introducido por un usuario en un URI de SIP. Incluya los valores de **Regexp** entre comillas. Especifique un valor para **Regexp** o un valor para **Replacement**, pero no ambos.
Las expresiones regulares pueden incluir cualquiera de los siguientes caracteres ASCII imprimibles:
+ a-z
+ 0-9
+ - (guion)
+ (espacio)
+ \$1 \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ ] ^ \$1 ` \$1 \$1 \$1 \$1 .
+ " (comillas). Para incluir un carácter de comillas literal en una cadena, incluya un carácter \$1 delante: \$1".
+ \$1 (barra diagonal invertida). Para incluir una barra diagonal invertida en una cadena, incluya un carácter \$1 delante: \$1\$1.
Especifique el resto de los valores, como los nombres de dominio internacionalizados, en formato octal.
Para ver la sintaxis de **Regexp**, consulte [RFC 3402, sección 3.2, Substitution Expression Syntax](https://tools.ietf.org/html/rfc3402#section-3.2)
**Reemplazo**
El nombre de dominio completo (FQDN) del siguiente nombre de dominio para el que desea que la aplicación DDDS envíe una consulta DNS. La aplicación DDDS sustituye el valor de entrada por el valor que especifique para **Replacement**, si especifica alguno. Especifique un valor para **Regexp** o un valor para **Replacement**, pero no ambos. Si especifica un valor para **Regexp**, especifique un punto (**.**) para **Replacement (Sustituto)**.
El nombre de dominio puede incluir a-z, 0-9 y - (guion).
Para obtener más información acerca de las aplicaciones DDDS y los registros NAPTR, consulte los siguientes RFC:
+ [RFC 3401](https://www.ietf.org/rfc/rfc3401.txt)
+ [RFC 3402](https://www.ietf.org/rfc/rfc3402.txt)
+ [RFC 3403](https://www.ietf.org/rfc/rfc3403.txt)
+ [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt)
**Ejemplo de la consola de Amazon Route 53**
```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```
**Ejemplo de la API de Route**
```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```
## Tipo de registro NS
Un registro NS identifica los servidores de nombres de la zona alojada. Tenga en cuenta lo siguiente:
+ El uso más común de un registro NS es controlar cómo se enruta el tráfico de Internet para un dominio. Para utilizar los registros de una zona alojada para enrutar el tráfico de un dominio, actualice la configuración del registro de dominio para utilizar los cuatro servidores de nombres en el registro NS predeterminado. (Este es el registro NS que tiene el mismo nombre que la zona alojada).
+ Puede crear una zona alojada independiente para un subdominio (acme.example.com) y utilizarla para enrutar el tráfico de Internet del subdominio y de los subdominios de este (subdominio.acme.example.com). Para establecer esta configuración, conocida como “delegar la responsabilidad de un subdominio a una zona alojada”, se crea otro registro NS en la zona alojada para el dominio raíz (example.com). Para obtener más información, consulte [Direccionamiento del tráfico de subdominios](dns-routing-traffic-for-subdomains.md).
+ También se utilizan registros NS para configurar servidores de nombres de etiqueta blanca. Para obtener más información, consulte [Configuración de servidores de nombres de etiqueta blanca](white-label-name-servers.md).
+ Otro uso de un registro NS es para las zonas alojadas privadas, cuando se crea una regla de delegación para delegar la autoridad sobre un subdominio al solucionador en las instalaciones. Debe crear este registro NS antes de crear una regla de delegación. Para obtener más información, consulte [Cómo los puntos finales de Resolver reenvían las consultas de DNS de su red a su red VPCs](resolver-overview-forward-vpc-to-network.md).
Para obtener más información acerca de los registros NS, consulte [Registros SOA y NS que crea Amazon Route 53 para una zona alojada pública](SOA-NSrecords.md).
**Ejemplo de la consola de Amazon Route 53**
```
ns-1.example.com
```
**Ejemplo de la API de Route**
```
ns-1.example.com
```
## Tipo de registro PTR
Un registro PTR asigna una dirección IP al nombre de dominio correspondiente.
**Ejemplo de la consola de Amazon Route 53**
```
hostname.example.com
```
**Ejemplo de la API de Route**
```
hostname.example.com
```
## Tipo de registro SOA
Un registro de inicio de autoridad (SOA) proporciona información sobre un dominio y la zona alojada de Amazon Route 53 correspondiente. Para obtener información sobre los campos de un registro SOA, consulte [Registros SOA y NS que crea Amazon Route 53 para una zona alojada pública](SOA-NSrecords.md).
**Ejemplo de la consola de Route**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
**Ejemplo de la API de Route**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
## Tipo de registro SPF
Los registros SPF se usaban anteriormente para verificar la identidad del remitente de mensajes de correo electrónico. Sin embargo, ya no se recomienda crear registros para los que el tipo de registro sea SPF. El RFC 7208, *Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, versión 1*, se ha actualizado y ahora indica, “...su existencia y el mecanismo definido en [RFC4408] han producido algunos problemas de interoperabilidad. Por lo tanto, su uso ya no es adecuado para SPF, versión 1; las implementaciones no van a utilizarlo”. En RFC 7208, consulte la sección 14.1, [The SPF DNS Record Type](http://tools.ietf.org/html/rfc7208#section-14.1).
En lugar de un registro SPF, le recomendamos que cree un registro TXT que contenga el valor correspondiente. Para obtener más información sobre valores válidos, consulte el artículo de Wikipedia [Sender Policy Framework](https://en.wikipedia.org/wiki/Sender_Policy_Framework).
**Ejemplo de la consola de Amazon Route 53**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
**Ejemplo de la API de Route**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
## Tipo de registro SRV
El elemento `Value` de un registro SRV consta de cuatro valores separados por espacios. Los tres primeros valores son números decimales que representan la prioridad, el peso y el puerto. El cuarto valor es un nombre de dominio. Los registros SRV se utilizan para acceder a servicios, como un servicio de correo electrónico o comunicaciones. Para obtener información sobre el formato del registro SRV, consulte la documentación del servicio al que desee conectarse.
**Ejemplo de la consola de Amazon Route 53**
```
10 5 80 hostname.example.com
```
**Ejemplo de la API de Route**
```
10 5 80 hostname.example.com
```
## Registro de tipo SSHFP
Los registros de huellas dactilares de Secure Shell (SSHFP) identifican las claves SSH asociadas al nombre de dominio. Los registros de SSHFP deben estar protegidos con DNSSEC para poder establecer una cadena de confianza. Para obtener más información acerca de DNSSEC, consulte [Configuración de la firma de DNSSEC en Amazon Route 53](dns-configuring-dnssec.md).
El formato de los registros de recursos SSHFP es:
`[Key Algorithm] [Hash Type] Fingerprint`
Los siguientes parámetros están definidos en el [RFC 4255](https://datatracker.ietf.org/doc/html/rfc4255).
**Algoritmo clave**
Tipo de algoritmo:
+ `0`: reservado y no utilizado.
+ `1: RSA`: el algoritmo Rivest-Shamir-Adleman es uno de los primeros criptosistemas de clave pública y todavía se utiliza para la transmisión segura de datos.
+ `2: DSA`: el algoritmo de firma digital es un estándar federal de procesamiento de información para firmas digitales. El DSA se basa en la exponenciación modular y en los modelos matemáticos de logaritmos discretos.
+ `3: ECDSA`: el algoritmo de firma digital de curva elíptica es una variante del DSA que utiliza criptografía de curva elíptica.
+ `4: Ed25519`: el algoritmo Ed25519 es el esquema de firma EdDSA que utiliza SHA-512 (SHA-2) y Curve25519.
+ `6: Ed448`: Ed448 es el esquema de firma EdDSA que utiliza SHAKE256 y Curve448.
**Tipo de hash**
Algoritmo utilizado para crear el hash de clave pública:
+ `0`: reservado y no utilizado.
+ `1: SHA-1`
+ `2: SHA-256`
**Huella digital**
Representación hexadecimal del hash.
**Ejemplo de la consola de Amazon Route 53**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
**Ejemplo de la API de Route**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
Para obtener más información, consulte el [RFC 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints](https://datatracker.ietf.org/doc/html/rfc4255).
## Registro de tipo SVCB
Los registros SVCB se utilizan para proporcionar información de configuración para acceder a los puntos de conexión de los servicios. El SVCB es un registro de DNS genérico y se puede utilizar para negociar los parámetros de una variedad de protocolos de aplicación.
El formato de los registros de recursos SVCB es:
`SvcPriority TargetName SvcParams(optional)`
Los siguientes parámetros están descritos en la [sección 2.3 del RFC 9460](https://www.rfc-editor.org/rfc/rfc9460.html#section-2.3).
**SvcPriority**
Un número entero que representa la prioridad. La prioridad 0 significa modo de alias y, por lo general, está destinada para la creación de alias en el vértice de zona. Cuanto menor sea la prioridad, mayor será la preferencia.
**TargetName**
El nombre de dominio del alias objetivo (para el modo de alias) o del punto de conexión alternativo (para ServiceMode).
**SvcParams (opcional)**
Una lista separada por espacios en blanco en la que cada parámetro consta de un par clave=valor o de una clave independiente. En caso de haber más de un valor, se presentan en forma de lista separada por comas. Este valor es un número entero del 0 al 32 767 para Route 53, de los cuales 1 a 32 767 son registros de modo de servicio. A continuación se detallan los SvcParams definidos:
+ `1:alpn`: identificadores de protocolos de negociación de protocolo de capa de aplicación. El valor predeterminado es HTTP/1.1, `h2` es HTTP/2 sobre TLS y `h3` es HTTP/3 (HTTP sobre el protocolo QUIC).
+ `2:no-default-alpn`: el valor predeterminado no es compatible y debe proporcionar un parámetro `alpn`.
+ `3:port`: el puerto del punto de conexión alternativo desde el que se puede acceder al servicio.
+ `4:ipv4hint`: sugerencias de la dirección IPv4.
+ `5:ech`: saludo del cliente cifrado.
+ `6:ipv6hint`: sugerencias de la dirección IPv6.
+ `7:dohpath`: plantilla de DNS sobre HTTPS.
+ `8:ohttp`: el servicio opera con un objetivo Oblivious HTTP.
**Ejemplo de la consola de Amazon Route 53 para el modo de alias**
```
0 example.com
```
**Ejemplo de la consola de Amazon Route 53 para el modo de servicio**
```
16 example.com alpn="h2,h3" port=808
```
**Ejemplo de la API de Amazon Route 53 para el modo de alias**
```
0 example.com
```
**Ejemplo de la API de Amazon Route 53 para el modo de servicio**
```
16 example.com alpn="h2,h3" port=808
```
Para obtener más información, consulte el [RFC 9460, Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)](https://datatracker.ietf.org/doc/html/rfc9460).
**nota**
Route 53 no admite el formato de presentación arbitrario de clave desconocida `keyNNNNN`.
## Registro de tipo TLSA
Los registros TLSA se utilizan para usar la autenticación de entidades con nombre basada en DNS (DANE). Los registros TLSA asocian un certificado o clave pública a un punto de conexión de seguridad de la capa de transporte (TLS), y los clientes pueden validar el certificado o la clave pública mediante un registro TLSA firmado con DNSSEC.
Solo se puede confiar en los registros de TLSA si DNSSEC está habilitado en su dominio. Para obtener más información acerca de DNSSEC, consulte [Configuración de la firma de DNSSEC en Amazon Route 53](dns-configuring-dnssec.md).
El formato de los registros de recursos TLSA es:
`[Certificate usage] Selector [Matching type] [Certificate association data]`
Los siguientes parámetros están especificados en la [sección 3 del RFC 6698](https://datatracker.ietf.org/doc/html/rfc6698#section-3).
**Uso de certificados**
Especifica la asociación proporcionada que se utilizará para que coincida con el certificado presentado en el establecimiento de comunicación TLS:
+ 0: Restricción de CA: el certificado o la clave pública debe encontrarse en alguna de las rutas de certificación de la infraestructura de la clave pública (PKIX) del certificado de entidad final proporcionado por el servidor en TLS. Esta restricción limita qué CA pueden utilizarse para emitir certificados para un servicio especificado.
+ 1: Restricción de certificado de servicio: especifica un certificado de entidad final (o la clave pública) que debe coincidir con el certificado de entidad final proporcionado por el servidor en TLS. Esta certificación limita qué certificado de entidad final puede usar un servicio específico en un host.
+ 2: Una afirmación de anclaje de veracidad: especifica un certificado (o la clave pública) que debe usarse como el «anclaje de veracidad» al validar el certificado de entidad final emitido por el servidor en TLS. Permite al administrador de dominios especificar un anclaje de veracidad.
+ 3: Certificación emitida por dominio: especifica un certificado (o la clave pública) que debe coincidir con el certificado de entidad final proporcionado por el servidor en TLS. Esta certificación permite al administrador de dominios emitir certificados para un dominio sin la participación de una CA externa. No es necesario que este certificado pase la validación de PKIX.
**Selector**
Especifica qué parte del certificado presentado por el servidor en el establecimiento de comunicación coincide con el valor de la asociación:
+ 0: Debe coincidir todo el certificado.
+ 1: La clave pública del sujeto, o la estructura binaria codificada en DER, debe coincidir.
**Tipo coincidente**
Especifica la presentación (según lo determinado por el campo Selector) de la coincidencia del certificado:
+ 0: Coincidencia exacta del contenido.
+ 1: hash SHA-256.
+ 2: hash SHA-512.
**Datos de asociación del certificado**
Los datos que se van a comparar en función de la configuración de los demás campos.
**Ejemplo de la consola de Amazon Route 53**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
**Ejemplo de la API de Route**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
Para obtener más información, consulte el [RFC 6698, The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA](https://datatracker.ietf.org/doc/html/rfc6698).
## Tipo de registro TXT
Un registro TXT contiene una o varias cadenas que se encierran entre comillas dobles (`"`). Al utilizar la [política de direccionamiento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) sencilla, incluye todos los valores de un dominio (example.com) o subdominio (www.example.com) en el mismo registro TXT.
**Topics**
+ [Introducción de valores de registro TXT](#TXTformat-limits)
+ [Caracteres especiales en un valor de registro TXT](#TXTformat-special-characters)
+ [Mayúsculas y minúsculas en un valor de registro TXT](#TXTformat-case)
+ [Ejemplos](#TXTformat-examples)
### Introducción de valores de registro TXT
Una única cadena puede incluir hasta 255 caracteres, entre las que se incluyen las siguientes:
+ a-z
+ A-Z
+ 0-9
+ Espacio
+ - (guion)
+ \$1 " \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ \$1 ] ^ \$1 ` \$1 \$1 \$1 \$1 .
Si necesita introducir un valor de más de 255 caracteres, divida el valor en cadenas de 255 caracteres o menos e incluya cada cadena entre comillas dobles (`"`). En la consola, enumere todas las cadenas de la misma línea:
```
"String 1" "String 2" "String 3"
```
En la API, incluya todas las cadenas en el mismo elemento `Value`:
```
"String 1" "String 2" "String 3"
```
La longitud máxima de un valor en un registro TXT es de 4000 caracteres.
Para ingresar más de un valor TXT, ingrese un valor por fila.
### Caracteres especiales en un valor de registro TXT
Si su registro TXT contiene alguno de los siguientes caracteres, debe especificar los caracteres usando códigos de escape en el formato `\`*código octal de tres dígitos*:
+ Caracteres de 000 a 040 octales (de 0 a 32 decimales, de 0x20 a 0x00 hexadecimales)
+ Caracteres de 177 a 377 octales (de 127 a 255 decimales, de 0x7F a 0xFF hexadecimales)
Por ejemplo, si el valor de su registro TXT es `"exämple.com"`, especifique `"ex\344mple.com"`.
Para consultar un mapeo entre caracteres ASCII y códigos octales, busque en Internet «códigos octales ASCII». Una referencia útil es [ASCII Code - The extended ASCII table](https://www.ascii-code.com/).
Para incluir una comilla (`"`) en una cadena, ponga una contrabarra (`\`) delante de esta: `\"`.
### Mayúsculas y minúsculas en un valor de registro TXT
Se distingue entre mayúsculas y minúsculas, por lo que `"Ab"` y `"aB"` son valores diferentes.
### Ejemplos
**Ejemplo de la consola de Amazon Route 53**
Ponga cada valor en una línea independiente:
```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```
**Ejemplo de la API de Route**
Ponga cada valor en un elemento `Value` independiente:
```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```
# Creación de registros con la consola de Amazon Route 53
En el siguiente procedimiento se explica cómo crear registros mediante la consola de Amazon Route 53. Para obtener información sobre cómo crear registros mediante la API de Route 53, consulte la *referencia [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)de la API de Amazon Route 53*.
**nota**
Para crear registros para las configuraciones de enrutamiento complejas, también puede utilizar el editor visual de Flujo de tráfico y guardar la configuración como una política de tráfico. A continuación, puede asociar la política de tráfico con uno o varios nombres de dominio (como example.com) o nombres de subdominio (como www.example.com) en la misma zona alojada o en varias zonas hospedadas. Además, puede revertir las actualizaciones si la nueva configuración no tiene el desempeño previsto. Para obtener más información, consulte [Uso de flujo de tráfico para dirigir el tráfico DNS](traffic-flow.md).
**Creación de un registro mediante la consola de Route 53**
1. Si no está creando un registro de alias, vaya al paso 2.
Vaya también al paso 2 si va a crear un registro de alias que dirija el tráfico de DNS a un AWS recurso que no sea un balanceador de cargas de Elastic Load Balancing u otro registro de Route 53.
Si va a crear un registro de alias que enrute el tráfico a un equilibrador de carga elástico, y si creó la zona alojada y el equilibrador de carga con cuentas diferentes, siga el procedimiento [Obtención del nombre DNS de un equilibrador de carga elástico](#resource-record-sets-elb-dns-name-procedure) para obtener el nombre DNS del equilibrador de carga.
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas**.
1. Si ya tiene una zona alojada para su dominio, vaya al paso 5. De lo contrario, realice el procedimiento correspondiente para crear una zona alojada:
+ Para dirigir el tráfico de Internet a sus recursos, como buckets de Amazon S3 o instancias de Amazon EC2, consulte [Crear una zona alojada pública](CreatingHostedZone.md).
+ Para direccionar el tráfico de la VPC, consulte [Creación de una zona alojada privada](hosted-zone-private-creating.md).
1. En la página **Zonas alojadas**, elija el nombre de la zona alojada en la que desea crear registros.
1. Elija **Crear registro**.
1. Elija y defina la política de direccionamiento y los valores aplicables. Para obtener más información, consulte el tema para el tipo de registro que desea crear:
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)
+ [Valores específicos para registros simples](resource-record-sets-values-basic.md)
+ [Valores específicos para registros de alias simples](resource-record-sets-values-alias.md)
+ [Valores específicos de registros de conmutación por error](resource-record-sets-values-failover.md)
+ [Valores específicos de registros de alias de conmutación por error](resource-record-sets-values-failover-alias.md)
+ [Valores específicos de registros de geolocalización](resource-record-sets-values-geo.md)
+ [Valores específicos de registros de alias de geolocalización](resource-record-sets-values-geo-alias.md)
+ [Valores específicos de registros de geoproximidad](resource-record-sets-values-geoprox.md)
+ [Valores específicos de registros de alias de geoproximidad](resource-record-sets-values-geoprox-alias.md)
+ [Valores específicos de registros de latencia](resource-record-sets-values-latency.md)
+ [Valores específicos de registros de alias de latencia](resource-record-sets-values-latency-alias.md)
+ [Valores específicos para los registros basados en IP](resource-record-sets-values-ipbased.md)
+ [Valores específicos para los registros de alias basados en IP](resource-record-sets-values-ipbased-alias.md)
+ [Valores específicos de registros de respuesta de varios valores](resource-record-sets-values-multivalue.md)
+ [Valores específicos de registros ponderados](resource-record-sets-values-weighted.md)
+ [Valores específicos de registros de alias ponderados](resource-record-sets-values-weighted-alias.md)
1. Elija **Crear registros**.
**nota**
Los nuevos registros tardan un tiempo en propagarse a los servidores DNS de Route 53. Actualmente, la única forma de comprobar que los cambios se han propagado es mediante la acción de la [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Por lo general, los cambios se propagan a todos los servidores de Route 53 en un plazo de 60 segundos.
1. Si está creando varios registros, repita los pasos 7 a 8.
**Obtención del nombre DNS de un equilibrador de carga elástico**
1. Inicie sesión Consola de administración de AWS con la AWS cuenta que se utilizó para crear el Classic, Application o Network Load Balancer para el que desee crear un registro de alias.
1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. En el panel de navegación, seleccione **Equilibradores de carga**.
1. En la lista de balanceadores de carga, seleccione uno para el que desea crear un registro de alias.
1. En la pestaña **Description**, obtenga el valor de **DNS name**.
1. Si desea crear registros de alias para otros equilibradores de carga elásticos, repita los pasos 4 y 5.
1. Cierre sesión en. Consola de administración de AWS
1. Consola de administración de AWS Vuelva a iniciar sesión con la AWS cuenta que utilizó para crear la zona alojada de Route 53.
1. Volver al paso 3 del procedimiento [Creación de registros con la consola de Amazon Route 53](#resource-record-sets-creating).
# Permisos del conjunto de registros de recursos
Los permisos del conjunto de registros de recursos utilizan las condiciones de la política de administración de identidad y acceso (IAM) para poder establecer permisos detallados para las acciones en la consola de Route 53 o para usar la [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)API.
Un conjunto de registros de recursos se define como varios registros de recursos con el mismo nombre y tipo (y clase, aunque para la mayoría de los propósitos la clase siempre es IN o Internet), pero con datos diferentes. Por ejemplo, si elige el enrutamiento de geolocalización, puede tener varios registros A o AAAA que apunten a diferentes puntos de conexión para el mismo dominio. Todos estos registros A o AAAA se combinan para formar un conjunto de registros de recursos. Para obtener más información acerca de la terminología de DNS, consulte [RFC 7719](https://datatracker.ietf.org/doc/html/rfc7719).
Con las condiciones de la política de IAM `route53:ChangeResourceRecordSetsNormalizedRecordNames``route53:ChangeResourceRecordSetsRecordTypes`, y`route53:ChangeResourceRecordSetsActions`, puede conceder derechos administrativos detallados a otros AWS usuarios de cualquier otra AWS cuenta. Esto le permite conceder permisos a alguien para:
+ Un único conjunto de registros de recursos.
+ Todos los conjuntos de registros de recursos de un tipo de registro de DNS específico.
+ Conjuntos de registros de recursos en los que los nombres contienen una cadena específica.
+ Realice alguna o todas las `CREATE | UPSERT | DELETE ` acciones cuando utilice la [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)API o la consola de Route 53.
También puede crear permisos de acceso que combinen cualquiera de las condiciones de la política de Route 53. Por ejemplo, puede conceder permisos a alguien para modificar los datos del registro A de marketing-example.com, pero no permitir que ese usuario elimine ningún registro.
Para obtener más información sobre los permisos de conjuntos de registros de recursos y ejemplos de cómo utilizarlos, consulte [Uso de condiciones de las políticas de IAM para control de acceso preciso](specifying-conditions-route53.md).
Para obtener información sobre cómo autenticar a AWS los usuarios, consulte [Autenticación con identidades](security-iam.md#security_iam_authentication) y aprenda a controlar el acceso a los recursos de Route 53, consulte[Control de acceso](security-iam.md#access-control).
# Valores que hay que especificar al crear o editar los registros de Amazon Route 53.
Cuando crea registros con la consola de Amazon Route 53, los valores que especifique dependen de la política de enrutamiento que desee usar y de si va a crear registros de alias, que enrutan el tráfico a AWS los recursos.
Registros de alias que redirigen el tráfico a determinados AWS recursos para los que se especifica el recurso de destino (por ejemplo, Elastic Load Balancing, CloudFront distribución o bucket de Amazon S3). Si lo desea, también puede asociar las comprobaciones de estado y configurar la evaluación del estado de destino. En los siguientes temas, se proporciona información detallada sobre los valores necesarios para cada política de enrutamiento y tipo de registro, lo que lo ayuda a configurar los registros de Route 53 de manera eficaz.
**Topics**
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)
+ [Valores específicos para registros simples](resource-record-sets-values-basic.md)
+ [Valores específicos para registros de alias simples](resource-record-sets-values-alias.md)
+ [Valores específicos de registros de conmutación por error](resource-record-sets-values-failover.md)
+ [Valores específicos de registros de alias de conmutación por error](resource-record-sets-values-failover-alias.md)
+ [Valores específicos de registros de geolocalización](resource-record-sets-values-geo.md)
+ [Valores específicos de registros de alias de geolocalización](resource-record-sets-values-geo-alias.md)
+ [Valores específicos de registros de geoproximidad](resource-record-sets-values-geoprox.md)
+ [Valores específicos de registros de alias de geoproximidad](resource-record-sets-values-geoprox-alias.md)
+ [Valores específicos de registros de latencia](resource-record-sets-values-latency.md)
+ [Valores específicos de registros de alias de latencia](resource-record-sets-values-latency-alias.md)
+ [Valores específicos para los registros basados en IP](resource-record-sets-values-ipbased.md)
+ [Valores específicos para los registros de alias basados en IP](resource-record-sets-values-ipbased-alias.md)
+ [Valores específicos de registros de respuesta de varios valores](resource-record-sets-values-multivalue.md)
+ [Valores específicos de registros ponderados](resource-record-sets-values-weighted.md)
+ [Valores específicos de registros de alias ponderados](resource-record-sets-values-weighted-alias.md)
# Valores comunes a todas las políticas de enrutamiento
Estos son los valores comunes que puede especificar al crear o editar registros de Amazon Route 53. Todas las políticas de enrutamiento utilizan estos valores.
**Topics**
+ [Nombre del registro](#rrsets-values-common-name)
+ [Valor/ruta de destino del tráfico](#rrsets-values-common-value)
+ [TTL (segundos)](#rrsets-values-common-ttl)
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no escriba un valor (por ejemplo, un símbolo @) en el campo **Name (Nombre)**.
**Registros CNAME**
Si crea un registro con el valor **CNAME** (CNAME) para **Record type** (Tipo de registro), el nombre del registro no puede ser el mismo que el de la zona alojada.
**Caracteres especiales**
Para obtener información sobre cómo especificar caracteres distintos de a-z, 0-9 y - (guion), y cómo especificar nombres de dominio internacionalizados, consulte [Formato de nombres de dominio DNS](DomainNameFormat.md).
**Caracteres comodín**
Puede usar un asterisco (\$1) en el nombre. DNS trata el asterisco como comodín o como el carácter ASCII (42) \$1, en función de dónde aparece en el nombre. Para obtener más información, consulte [Uso de un asterisco (\$1) en nombres de zonas alojadas y registros](DomainNameFormat.md#domain-name-format-asterisk).
No puede usar el carácter comodín \$1 para los conjuntos de registros de recursos con el tipo **NS**.
## Valor/ruta de destino del tráfico
Elija **IP address or another value depending on the record type (Dirección IP u otro valor en función del tipo de registro)**. Ingrese un valor que sea adecuado para el valor de **Record type** (Tipo de registro). Para todos los tipos excepto **CNAME**, puede escribir más de un valor. Escriba cada valor en una línea independiente.
**A — IPv4 dirección**
Una dirección IP en IPv4 formato, por ejemplo, **192.0.2.235**.
**AAAA: dirección IPv6 **
Una dirección IP en IPv6 formato, por ejemplo, **2001:0 db 8:85 a 3:0:0:8 a2e: 0370:7334**.
**CAA: autorización de la entidad de certificación**
Tres valores separados por espacios que controlan qué autoridades de certificación están autorizadas para emitir certificados (normales o comodín) para el dominio o subdominio especificado en **Record name** (Nombre del registro). Puede utilizar los registros CAA para especificar lo siguiente:
+ ¿CAsQué autoridades SSL/TLS de certificación () pueden emitir certificados, si los hay
+ La dirección de correo electrónico o URL con la que hay que contactar en caso de que una CA emita un certificado para el dominio o subdominio.
**CNAME: nombre canónico**
El nombre de dominio completo (por ejemplo, *www.example.com*) que desea que Route 53 devuelva como respuesta a las consultas de DNS para este registro. El punto final es opcional; Route 53 presupone que el nombre de dominio es completo. Esto significa que Route 53 trata a *www.example.com* (sin punto final) y *www.example.com.* (con punto final) de idéntica forma.
**MX: intercambio de correo**
Una prioridad y un nombre de dominio que especifican un servidor de correo, por ejemplo, **10 mailserver.ejemplo.com**. El punto final se trata como opcional.
**NAPTR: señalizador de autoridad de asignación de nombres**
Seis valores separados por espacios que las aplicaciones DDDS (Dynamic Delegation Discovery System, Sistema de detección de delegación dinámica) usan para convertir un valor en otro o para reemplazar un valor por otro. Para obtener más información, consulte [Tipo de registro NAPTR](ResourceRecordTypes.md#NAPTRFormat).
**PTR: puntero**
El nombre de dominio que desea que Route 53 devuelva.
**NS: servidor de nombres**
El nombre de dominio de un servidor de nombres, por ejemplo, **ns1.ejemplo.com**.
Puede especificar un registro NS con solo una política de enrutamiento simple.
**SPF: marco de políticas de remitente**
Un registro SPF envuelto en comillas, por ejemplo, **“v=spf1 ip4:192.168.0.1/16-all”**. El uso de registros SPF no es recomendado. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
**SRV: localizador de servicios**
Un registro SRV. Los registros SRV se utilizan para acceder a servicios, como un servicio de correo electrónico o comunicaciones. Para obtener información sobre el formato del registro SRV, consulte la documentación del servicio al que desee conectarse. El punto final se trata como opcional.
El formato de un registro SRV es el siguiente:
**[prioridad] [ponderación] [puerto] [nombre del host de servidor]**
Por ejemplo:
**1 10 5269 xmpp-servidor.ejemplo.com.**
**TXT: texto**
Un registro de texto. Entrecomille el texto; por ejemplo, **“Entrada de texto de ejemplo”**.
## TTL (segundos)
El tiempo, en segundos, en que desea que los solucionadores recursivos de DNS almacenen en caché información sobre este registro. Si especifica un valor más largo (por ejemplo, 172 800 segundos o dos días), se reduce el número de llamadas que los solucionadores recursivos de DNS deben realizar a Route 53 para obtener la información más reciente de este registro. Esto reduce la latencia y la factura del servicio Route 53. Para obtener más información, consulte [Cómo dirige Amazon Route 53 el tráfico de su dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Sin embargo, si especifica un valor más largo para TTL, los cambios realizados en el registro (por ejemplo, una nueva dirección IP) tardarán más tiempo en surtir efecto, ya que los solucionadores recursivos usan los valores de la memoria caché durante periodos más largos antes de solicitar la información más reciente a Route 53. Si está cambiando la configuración de un dominio o subdominio que ya está en uso, le recomendamos que inicialmente especifique un valor más corto, por ejemplo, 300 segundos y que aumente el valor después de confirmar que la configuración nueva es correcta.
Si asocia este registro a una comprobación de estado, es recomendable que especifique un TTL de 60 segundos o menos para que los clientes respondan rápidamente a los cambios de estado.
# Valores comunes de registros de alias para todas las políticas de enrutamiento
Estos son los valores de alias comunes que puede especificar al crear o editar registros de Amazon Route 53. Todas las políticas de enrutamiento utilizan estos valores.
**Topics**
+ [Nombre del registro](#rrsets-values-common-alias-name)
+ [Valor/ruta de destino del tráfico](#rrsets-values-alias-common-target)
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no escriba un valor (por ejemplo, un símbolo @) en el campo **Name (Nombre)**.
**Registros CNAME**
Si crea un registro con el valor **CNAME** para **Type (Tipo)**, el nombre del registro no puede ser el mismo que el de la zona alojada.
**Alias para CloudFront distribuciones y buckets de Amazon S3**
El valor que especifique depende en parte del AWS recurso al que dirija el tráfico:
+ **CloudFront distribución**: la distribución debe incluir un nombre de dominio alternativo que coincida con el nombre del registro. Por ejemplo, si el nombre del registro es **acme.ejemplo.com**, la distribución de CloudFront debe incluir **acme.ejemplo.com** como uno de los nombres de dominio alternativos. Para obtener más información, consulte [Uso de nombres de dominio alternativos (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) en la *Guía para CloudFront desarrolladores de Amazon*.
+ **Bucket de Amazon S3**: el nombre del registro debe coincidir con el nombre del bucket de Amazon S3. Por ejemplo, si el nombre del bucket es **acme.ejemplo.com**, el nombre de este registro también debe ser **acme.ejemplo.com**.
Además, debe configurar el bucket para el hospedaje de sitio web. Para obtener más información, consulte [Configuración de un bucket para un alojamiento de sitio web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) en la *Guía del usuario de Amazon Simple Storage Service*.
**Caracteres especiales**
Para obtener información sobre cómo especificar caracteres distintos de a-z, 0-9 y - (guion), y cómo especificar nombres de dominio internacionalizados, consulte [Formato de nombres de dominio DNS](DomainNameFormat.md).
**Caracteres comodín**
Puede usar un asterisco (\$1) en el nombre. DNS trata el asterisco como comodín o como el carácter ASCII (42) \$1, en función de dónde aparece en el nombre. Para obtener más información, consulte [Uso de un asterisco (\$1) en nombres de zonas alojadas y registros](DomainNameFormat.md#domain-name-format-asterisk).
## Valor/ruta de destino del tráfico
El valor que elija de la lista o que escriba en el campo depende del AWS recurso al que dirija el tráfico.
Para obtener más información sobre cómo configurar Route 53 para enrutar el tráfico a AWS recursos específicos, consulte[Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
**importante**
Si usó la misma AWS cuenta para crear la zona alojada y el recurso al que está enrutando el tráfico, y si su recurso no aparece en la lista de **puntos finales**, compruebe lo siguiente:
Confirme que ha elegido un valor admitido para **Record type** (Tipo de registro). Los valores admitidos son específicos del recurso al que restá redirigiendo el tráfico. Por ejemplo, para enrutar el tráfico a un bucket de S3, debe elegir **una IPv4 dirección** A como **Tipo de registro**.
Confirme que la cuenta tiene los permisos de IAM necesarios para enumerar los recursos aplicables. Por ejemplo, para que las distribuciones de CloudFront aparezcan en la lista **Endpoint** (Punto de conexión), la cuenta debe tener permiso para realizar la siguiente acción: `cloudfront:ListDistributions`.
Para ver una política de IAM de ejemplo, consulte [Permisos necesarios para usar la consola de Amazon Route 53](access-control-managing-permissions.md#console-required-permissions).
Si usó AWS cuentas diferentes para crear la zona alojada y el recurso, la lista **de puntos finales** no mostrará su recurso. Consulte la siguiente documentación sobre su tipo de recurso para determinar el valor que debe ingresar en **Punto de conexión**.
**API Gateway personalizado, regional APIs y optimizado para entornos periféricos APIs**
Para API Gateway personalizado, regional APIs y optimizado para bordes APIs, realice una de las siguientes acciones:
+ **Si ha usado la misma cuenta para crear la zona alojada de Route 53 y la API**: elija **Punto de conexión** y luego una API de la lista. Si tiene muchos APIs, puede introducir los primeros caracteres del punto final de la API para filtrar la lista.
**nota**
El nombre del registro debe coincidir con un nombre de dominio personalizado para su API, como **api.ejemplo.com**.
+ **Si ha usado cuentas diferentes para crear la zona alojada de Route 53 y la API**: ingrese el punto de conexión de API de la API, como, por ejemplo, **api.example.com**.
Si has utilizado una AWS cuenta para crear la zona alojada actual y otra para crear una API, la API no aparecerá en la lista de **puntos finales** de **API Gateway APIs**.
Si utilizaste una cuenta para crear la zona alojada actual y una o más cuentas diferentes para crear todas las tuyas APIs, la lista de **puntos finales** muestra **No hay destinos disponibles** en **API Gateway APIs**. Para obtener más información, consulte [Enrutamiento del tráfico a una API de Amazon API Gateway mediante su nombre de dominio](routing-to-api-gateway.md).
**CloudFront distribuciones**
Para CloudFront las distribuciones, realice una de las siguientes acciones:
+ **Si usó la misma cuenta para crear su zona alojada de Route 53 y su CloudFront distribución**, elija **Endpoint** y elija una distribución de la lista. Si tiene muchas distribuciones, puede escribir los primeros caracteres del nombre de dominio de la distribución para filtrar la lista.
Si la distribución no aparece en la lista, tenga en cuenta lo siguiente:
+ El nombre de este registro debe coincidir con un nombre de dominio alternativo de la distribución.
+ Si acaba de agregar un nombre de dominio alternativo a su distribución, los cambios pueden tardar 15 minutos en propagarse a todas las ubicaciones CloudFront periféricas. Hasta que no se hayan propagado los cambios, Route 53 no puede saber nada del nuevo nombre de dominio alternativo.
+ **Si utilizó cuentas diferentes para crear su zona alojada de Route 53 y su distribución, introduzca el nombre de CloudFront dominio de la distribución**, como **d111111abcdef8.cloudfront.net**.
**Si usó una AWS cuenta para crear la zona alojada actual y otra para crear una distribución, la distribución no aparecerá en la lista de puntos finales.**
**Si ha utilizado una cuenta para crear la zona alojada actual y una o más cuentas diferentes para crear todas las distribuciones, la lista de **puntos finales** muestra que **no hay destinos disponibles** en las distribuciones. CloudFront **
No dirija las consultas a una CloudFront distribución que no se haya propagado a todas las ubicaciones de borde o sus usuarios no podrán acceder al contenido correspondiente.
CloudFront La distribución debe incluir un nombre de dominio alternativo que coincida con el nombre del registro. Por ejemplo, si el nombre del registro es **acme.example.com, la CloudFront distribución debe incluir **acme.example.com**** como uno de los nombres de dominio alternativos. Para obtener más información, consulte [Uso de nombres de dominio alternativos (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) en la *Guía para CloudFront desarrolladores de Amazon*.
Si IPv6 está habilitado para la distribución, cree dos registros, uno con el valor **A ( IPv4 dirección** para el **tipo de registro**) y otro con el valor **AAAA ( IPv6dirección)**. Para obtener más información, consulte [Enrutar el tráfico a una CloudFront distribución de Amazon mediante tu nombre de dominio](routing-to-cloudfront-distribution.md).
**Servicio de App Runner**
En el caso del servicio de App Runner, realice una de las siguientes operaciones:
+ **Si usó la misma cuenta para crear su zona alojada de Route 53 y su servicio de App Runner**, elija el nombre de dominio del entorno al que quiere enrutar el tráfico de la lista y Región de AWS, a continuación, elija el nombre de dominio del entorno al que desea enrutar el tráfico.
+ **Si ha usado cuentas diferentes para crear la zona alojada de Route 53 y App Runner**: ingrese el nombre de dominio personalizado. Para obtener más información, consulte [Managing custom domain names for App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains.html) (Administración de nombres de dominio personalizados para App Runner).
Si usó una AWS cuenta para crear la zona alojada actual y otra para crear una App Runner, esta no aparecerá en la lista de **puntos finales**.
Para obtener más información, consulte [Configuración de Amazon Route 53 para dirigir el tráfico a un servicio de App Runner](routing-to-app-runner.md#routing-to-app-runner-configuring).
**Entornos de Elastic Beanstalk que tienen subdominios regionalizados**
Si el nombre de dominio del entorno de Elastic Beanstalk incluye la región en la que implementó el entorno, puede crear un registro de alias que dirija el tráfico al entorno. Por ejemplo, el nombre de dominio `my-environment.us-west-2.elasticbeanstalk.com` es un nombre de dominio regionalizado.
Para los entornos creados antes de principios de 2016, el nombre de dominio no incluye la región. Para dirigir el tráfico a estos entornos, debe crear un registro CNAME en lugar de un registro de alias. Tenga en cuenta que no puede un crear un registro CNAME para el nombre de dominio raíz. Por ejemplo, si su nombre de dominio es example.com, puede crear un registro que dirija el tráfico de acme.example.com a su entorno de Elastic Beanstalk, pero no puede crear un registro que dirija el tráfico de example.com a su entorno de Elastic Beanstalk.
Para los entornos de Elastic Beanstalk que tienen subdominios regionalizados, realice una de las siguientes acciones:
+ **Si ha usado la misma cuenta para crear la zona alojada de Route 53 y el entorno de Elastic Beanstalk**: elija **Punto de conexión** y luego un entorno de la lista. Si tiene muchos entornos, puede escribir los primeros caracteres del atributo CNAME del entorno para filtrar la lista.
+ **Si ha usado cuentas diferentes para crear la zona alojada de Route 53 y el entorno de Elastic Beanstalk**: ingrese el atributo CNAME del entorno de Elastic Beanstalk.
Para obtener más información, consulte [Enrutar el tráfico a un AWS Elastic Beanstalk entorno](routing-to-beanstalk-environment.md).
**Balanceadores de carga de ELB**
Para los equilibradores de carga de ELB, realice una de las siguientes operaciones:
+ **Si ha usado la misma cuenta para crear la zona alojada de Route 53 y el equilibrador de carga**: elija **Punto de conexión** y luego un equilibrador de carga de la lista. Si tiene muchos equilibradores de carga, puede escribir los primeros caracteres del nombre DNS para filtrar la lista.
+ **Si ha usado cuentas distintas para crear la zona alojada de Route 53 y el balanceador de carga**: ingrese el valor que obtuvo en el procedimiento [Obtención del nombre DNS de un equilibrador de carga elástico](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure).
**Si usaste una AWS cuenta para crear la zona alojada actual y otra para crear un balanceador de cargas, el balanceador de cargas no aparecerá en la lista de endpoints.**
Si ha usado una cuenta para crear la zona alojada actual, y una o varias cuentas diferentes para crear todos los equilibradores de carga, en la lista **Endpoints** (Puntos de conexión) se muestra **No targets available** (Sin destinos disponibles) en **Elastic Load Balancers** (Elastic Load Balancers).
La consola agrega **dualstack.** para la aplicación y el balanceador de carga clásico desde una cuenta diferente. Cuando un cliente, como un navegador web, solicita la dirección IP de su nombre de dominio (example.com) o nombre de subdominio (www.example.com), el cliente puede solicitar una IPv4 dirección (un registro A), una IPv6 dirección (un registro AAAA) o ambas IPv4 y IPv6 direcciones (en solicitudes separadas). La designación **dualstack.** permite a Route 53 responder con la dirección IP adecuada del balanceador de carga en función del formato de dirección IP que ha solicitado el cliente.
Para obtener más información, consulte [Direccionamiento del tráfico a un balanceador de carga ELB](routing-to-elb-load-balancer.md).
**AWS Aceleradores de Global Accelerator**
En el AWS caso de los aceleradores de Global Accelerator, introduzca el nombre DNS del acelerador. Puede introducir el nombre DNS de un acelerador que haya creado con la AWS cuenta corriente o con una cuenta diferente. AWS
**Buckets de Amazon S3**
Para los buckets de Amazon S3 configurados en los puntos de enlace de sitio web, realice una de las siguientes acciones:
+ **Si ha usado la misma cuenta para crear la zona alojada de Route 53 y el bucket de Amazon S3**: elija **Punto de conexión** y luego un bucket de la lista. Si tiene muchos buckets, puede escribir los primeros caracteres del nombre DNS para filtrar la lista.
El valor de **Punto de conexión** cambia al punto de conexión del sitio web de Amazon S3 para el bucket.
+ **Si ha usado cuentas diferentes para crear la zona alojada de Route 53 y el bucket de Amazon S3**: ingrese el nombre de la región en la que ha creado el bucket de S3. Use el valor que aparece en la columna **punto de conexión del sitio web ** de la tabla [Punto de conexión de sitio web de Amazon S3](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints) en *Referencia general de Amazon Web Services*.
Si ha utilizado AWS cuentas distintas de la cuenta actual para crear sus buckets de Amazon S3, el bucket no aparecerá en la lista de **puntos de conexión**.
Debe configurar el bucket para el hospedaje de sitio web. Para obtener más información, consulte [Configuración de un bucket para un alojamiento de sitio web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) en la *Guía del usuario de Amazon Simple Storage Service*.
El nombre del registro debe coincidir con el nombre del bucket de Amazon S3. Por ejemplo, si el nombre del bucket de Amazon S3 es **acme.example.com**, el nombre de este registro también debe ser **acme.example.com**.
En un grupo de registros de alias ponderados, alias de latencia, alias de conmutación por error o alias de geolocalización, solo puede crear un registro que dirija las consultas a un bucket de Amazon S3, porque el nombre del registro debe coincidir con el nombre del bucket, y los nombres de bucket deben ser únicos de forma global.
** OpenSearch Servicio Amazon**
Para el OpenSearch servicio, realice una de las siguientes acciones:
+ **OpenSearch Dominio personalizado del servicio**: el nombre del registro debe coincidir con el dominio personalizado. Por ejemplo, si el nombre del dominio personalizado es test.example.com, el nombre de este registro también debe ser test.example.com.
+ **Si usó la misma cuenta para crear su zona alojada de Route 53 y su dominio de OpenSearch servicio, elija el nombre de dominio** y Región de AWS, a continuación, elija el nombre de dominio.
+ **Si utilizó cuentas diferentes para crear su zona alojada de Route 53 y su dominio de OpenSearch servicio**, introduzca el nombre de dominio personalizado. Para obtener más información, consulte [Create a custom endpoint](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/customendpoint.html).
Si utilizó una AWS cuenta para crear la zona alojada actual y otra cuenta para crear un dominio de OpenSearch servicio, el dominio no aparecerá en la lista de **puntos finales**.
**Si ha utilizado una cuenta para crear la zona alojada actual y una o más cuentas diferentes para crear todos sus dominios de OpenSearch servicio, la lista de **puntos finales** muestra que **no hay destinos disponibles** en OpenSearch el servicio.**
Para obtener más información, consulte [Configuración de Amazon Route 53 para enrutar el tráfico a un punto final OpenSearch de dominio de Amazon Service](routing-to-open-search-service.md#routing-to-open-search-service-configuring).
**Puntos de enlace de interfaz de Amazon VPC**
Para los puntos de interfaz de Amazon VPC, realice una de las siguientes opciones:
+ **Si ha usado la misma cuenta para crear la zona alojada de Route 53 y el punto de conexión de interfaz**: elija **Punto de conexión** y luego un punto de conexión de interfaz de la lista. Si tiene muchos puntos de conexión de interfaz, puede escribir los primeros caracteres del nombre de host DNS para filtrar la lista.
+ **Si utilizó cuentas diferentes para crear la zona alojada de Route 53 y el punto de enlace de la interfaz**, introduzca el nombre de host DNS del punto de enlace de la interfaz, como **vpce-123456789abcdef01- example-us-east -1a.elasticloadbalancing.us-east-1.vpce.amazonaws.com**.
Si ha utilizado una AWS cuenta para crear la zona alojada actual y otra cuenta para crear un punto de enlace de interfaz, el punto de enlace de interfaz no aparecerá en la lista de **puntos** de enlace de **VPC**.
Si ha usado una cuenta para crear la zona alojada actual, y una o varias cuentas diferentes para crear todos los puntos de conexión de interfaz, en la lista **Endpoint** (Punto de conexión) se muestra **No targets available** (Sin destinos disponibles) en **VPC Endpoints** (Puntos de conexión de VPC).
Para obtener más información, consulte [Enrutamiento del tráfico a un punto de conexión de interfaz de Amazon Virtual Private Cloud mediante el nombre de dominio](routing-to-vpc-interface-endpoint.md).
**Registros de esta zona alojada**
Para los registros de esta zona alojada, elija **Endpoint** (Punto de conexión) y luego el registro correspondiente. Si tiene muchos registros, puede escribir los primeros caracteres del nombre para filtrar la lista.
Si en la zona alojada se incluyen solo los registros de NS y SOA predeterminados, en la lista **Endpoints** (Puntos de conexión) se muestra **No targets available** (Sin destinos disponibles).
Si va a crear un registro de alias con el mismo nombre que la zona alojada (lo que se conoce como *ápex de zona*), no podrá elegir un registro en el que el valor de **Record type** (Tipo de registro) sea **CNAME** (CNAME). Esto se debe a que el registro de alias debe tener el mismo tipo que el registro al que está redirigiendo el tráfico y no es posible crear un registro CNAME para el ápex de zona (ni siquiera para un registro de alias).
# Valores específicos para registros simples
Cuando se crean registros simples, hay que especificar los siguientes valores.
**Topics**
+ [Política de direccionamiento](#rrsets-values-basic-routing-policy)
+ [Nombre del registro](#rrsets-values-basic-name)
+ [Valor/ruta de destino del tráfico](#rrsets-values-basic-value)
+ [Tipo de registro](#rrsets-values-basic-type)
+ [TTL (segundos)](#rrsets-values-basic-ttl)
## Política de direccionamiento
Elija **Direccionamiento simple**.
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no escriba un valor (por ejemplo, un símbolo @) en el campo **Name (Nombre)**.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Valor/ruta de destino del tráfico
Elija **IP address or another value depending on the record type (Dirección IP u otro valor en función del tipo de registro)**. Ingrese un valor que sea adecuado para el valor de **Record type** (Tipo de registro). Para todos los tipos excepto **CNAME**, puede escribir más de un valor. Escriba cada valor en una línea independiente.
Puede dirigir el tráfico a, o especificar los siguientes valores:
+ **A — IPv4 dirección**
+ **AAAA — IPv6 dirección**
+ **CAA: autorización de la entidad de certificación**
+ **CNAME: nombre canónico**
+ **MX: intercambio de correo**
+ **NAPTR: señalizador de autoridad de asignación de nombres**
+ **NS: servidor de nombres**
El nombre de dominio de un servidor de nombres, por ejemplo, **ns1.ejemplo.com**.
**nota**
Puede especificar un registro NS con solo una política de enrutamiento simple.
+ **PTR: puntero**
+ **SPF: marco de políticas de remitente**
+ **SRV: localizador de servicios**
+ **TXT: texto**
Para obtener más información sobre los valores anteriores, consulte [los valores comunes Value/Route del tráfico hacia](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el valor de **Record type** (Tipo de registro) en función de cómo desee que Route 53 responda a las consultas de DNS.
## TTL (segundos)
El tiempo, en segundos, en que desea que los solucionadores recursivos de DNS almacenen en caché información sobre este registro. Si especifica un valor más largo (por ejemplo, 172 800 segundos o dos días), se reduce el número de llamadas que los solucionadores recursivos de DNS deben realizar a Route 53 para obtener la información más reciente de este registro. Esto reduce la latencia y la factura del servicio Route 53. Para obtener más información, consulte [Cómo dirige Amazon Route 53 el tráfico de su dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Sin embargo, si especifica un valor más largo para TTL, los cambios realizados en el registro (por ejemplo, una nueva dirección IP) tardarán más tiempo en surtir efecto, ya que los solucionadores recursivos usan los valores de la memoria caché durante periodos más largos antes de solicitar la información más reciente a Route 53. Si está cambiando la configuración de un dominio o subdominio que ya está en uso, le recomendamos que inicialmente especifique un valor más corto, por ejemplo, 300 segundos y que aumente el valor después de confirmar que la configuración nueva es correcta.
# Valores específicos para registros de alias simples
Cuando se crean registros de alias, hay que especificar los siguientes valores. Para obtener más información, consulte [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md).
**nota**
Si utiliza Route 53 en AWS GovCloud (US) Region, esta función tiene algunas restricciones. Para obtener más información, consulte la [Página de Amazon Route 53](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html) en la *Guía del usuario de AWS GovCloud (US) *.
**Topics**
+ [Política de direccionamiento](#rrsets-values-alias-routing-policy)
+ [Nombre del registro](#rrsets-values-alias-name)
+ [Valor/ruta de destino del tráfico](#rrsets-values-alias-alias-target)
+ [Tipo de registro](#rrsets-values-alias-type)
+ [Evaluate target health](#rrsets-values-alias-evaluate-target-health)
## Política de direccionamiento
Elija **Direccionamiento simple**.
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no escriba un valor (por ejemplo, un símbolo @) en el campo **Name (Nombre)**.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Valor/ruta de destino del tráfico
El valor que elija de la lista o que escriba en el campo depende del AWS recurso al que dirija el tráfico.
Para obtener información sobre AWS los recursos a los que puede dirigirse, consulte [los valores comunes de los registros de alias a los que se dirige value/route el tráfico](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Para obtener más información sobre cómo configurar Route 53 para enrutar el tráfico a AWS recursos específicos, consulte[Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el valor aplicable en función del AWS recurso al que está enrutando el tráfico:
**API regionales personalizadas o API optimizadas para bordes de API Gateway**
Selecciona **A — IPv4 dirección**.
**Puntos de conexión de interfaz de Amazon VPC**
Seleccione **A — IPv4 dirección**.
**CloudFront distribución**
Seleccione **A — IPv4 dirección**.
Si IPv6 está habilitada para la distribución, cree dos registros, uno con el valor **A ( IPv4 dirección** para el **tipo**) y otro con el valor **AAAA ( IPv6 dirección)**.
**Servicio de App Runner**
Seleccione **A — dirección IPv4 **
**Entorno de Elastic Beanstalk con subdominios regionalizados**
Seleccione **A — IPv4 dirección**
**Balanceador de carga de ELB**
Seleccione la ** IPv4 dirección A** o la dirección **AAAA IPv6 **
**Bucket de Amazon S3**
Seleccione **A — dirección IPv4 **
**OpenSearch Servicio**
Seleccione **una IPv4 dirección** o una dirección **AAAA IPv6 **
**Otro registro en esta zona alojada**
Seleccione el tipo de registro para el que va a crear el alias. Se admiten todos los tipos, excepto **NS** y **SOA**.
Si va a crear un registro de alias con el mismo nombre que la zona alojada (lo que se conoce como *ápex de zona*), no podrá dirigir el tráfico a un registro en el que el valor de **Type (Tipo)** sea **CNAME**. Esto se debe a que el registro de alias debe tener el mismo tipo que el registro al que está redirigiendo el tráfico y no es posible crear un registro CNAME para el ápex de zona (ni siquiera para un registro de alias).
## Evaluate target health
Cuando el valor de **Política de enrutamiento** es **Sencillo**, puede elegir los valores **No** o el valor predeterminado **Sí**, porque **Evaluar estado del destino** no tiene ningún efecto para el enrutamiento **Sencillo**. Si solo tiene un registro que tiene un nombre y un tipo determinados, Route 53 responde las consultas de DNS utilizando los valores de ese registro, independientemente de si el recurso está o no en buen estado.
Para otras políticas de enrutamiento, **Evaluar estado del destino** determina si Route 53 comprueba el estado del recurso al que hace referencia el registro de alias:
+ **Servicios en los que Evaluar estado del destino proporciona beneficios operativos**: en el caso de los equilibradores de carga (ELB) y los entornos de AWS Elastic Beanstalk con equilibradores de carga, establecer la opción **Evaluar estado del destino** en **Sí** permite a Route 53 enrutar el tráfico y alejarlo de los recursos insalubres.
+ **Servicios de alta disponibilidad**: para servicios como los buckets de Amazon S3, los puntos de enlace de la interfaz de VPC, Amazon API Gateway AWS Global Accelerator, Amazon Service y OpenSearch Amazon VPC Lattice**, Evaluate Target** Health no ofrece ningún beneficio operativo porque estos servicios están diseñados para una alta disponibilidad. Para situaciones de conmutación por error con estos servicios, utilice en su lugar las [comprobaciones de estado de Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html).
Para obtener información detallada sobre cómo funciona **Evaluate Target Health** con los diferentes AWS servicios, consulte la [ EvaluateTargetHealth](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth)documentación de la referencia de la API.
# Valores específicos de registros de conmutación por error
Cuando se crean registros de conmutación por error, hay que especificar los siguientes valores.
**nota**
Para obtener información sobre cómo crear registros de conmutación por error en una zona alojada privada, consulte [Configuración de la conmutación por error en una zona alojada privada](dns-failover-private-hosted-zones.md).
**Topics**
+ [Política de direccionamiento](#rrsets-values-failover-routing-policy)
+ [Nombre del registro](#rrsets-values-failover-name)
+ [Tipo de registro](#rrsets-values-failover-type)
+ [TTL (segundos)](#rrsets-values-failover-ttl)
+ [Valor/ruta de destino del tráfico](#rrsets-values-failover-value)
+ [Tipo de registro de conmutación por error](#rrsets-values-failover-record-type)
+ [Chequeo de salud](#rrsets-values-failover-associate-with-health-check)
+ [ID de registro](#rrsets-values-failover-set-id)
## Política de direccionamiento
Elija **Failover** (Conmutación por error).
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no ingrese un valor (por ejemplo, un símbolo @) en el campo **Record name** (Nombre del registro).
Escriba el mismo nombre para los dos registros del grupo de registros de conmutación por error.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el mismo valor para los registros de conmutación por error principales y secundarios.
## TTL (segundos)
El tiempo, en segundos, en que desea que los solucionadores recursivos de DNS almacenen en caché información sobre este registro. Si especifica un valor más largo (por ejemplo, 172 800 segundos o dos días), se reduce el número de llamadas que los solucionadores recursivos de DNS deben realizar a Route 53 para obtener la información más reciente de este registro. Esto reduce la latencia y la factura del servicio Route 53. Para obtener más información, consulte [Cómo dirige Amazon Route 53 el tráfico de su dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Sin embargo, si especifica un valor más largo para TTL, los cambios realizados en el registro (por ejemplo, una nueva dirección IP) tardarán más tiempo en surtir efecto, ya que los solucionadores recursivos usan los valores de la memoria caché durante periodos más largos antes de solicitar la información más reciente a Route 53. Si está cambiando la configuración de un dominio o subdominio que ya está en uso, le recomendamos que inicialmente especifique un valor más corto, por ejemplo, 300 segundos y que aumente el valor después de confirmar que la configuración nueva es correcta.
Si asocia este registro a una comprobación de estado, es recomendable que especifique un TTL de 60 segundos o menos para que los clientes respondan rápidamente a los cambios de estado.
## Valor/ruta de destino del tráfico
Elija **IP address or another value depending on the record type (Dirección IP u otro valor en función del tipo de registro)**. Ingrese un valor que sea adecuado para el valor de **Record type** (Tipo de registro). Para todos los tipos excepto **CNAME**, puede escribir más de un valor. Escriba cada valor en una línea independiente.
Puede dirigir el tráfico a, o especificar los siguientes valores:
+ **A — IPv4 dirección**
+ **AAAA — IPv6 dirección**
+ **CAA: autorización de la entidad de certificación**
+ **CNAME: nombre canónico**
+ **MX: intercambio de correo**
+ **NAPTR: señalizador de autoridad de asignación de nombres**
+ **PTR: puntero**
+ **SPF: marco de políticas de remitente**
+ **SRV: localizador de servicios**
+ **TXT: texto**
Para obtener más información sobre los valores anteriores, consulte [los valores comunes Value/Route del tráfico hacia](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Tipo de registro de conmutación por error
Elija el valor aplicable para este registro. Para que la conmutación por error funcione correctamente, debe crear un registro de conmutación por error principal y uno secundario.
No puede crear registros sin conmutación por error que tengan los mismos valores de **Record name** (Nombre del registro) y **Record type** (Tipo de registro) que los registros de conmutación por error.
## Chequeo de salud
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Yes** (Sí) en **Evaluate Target Health** (Evaluar el estado del destino) para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias de latencia, alias basado en IP o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain Name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name (Nombre de dominio)** coincide con el nombre de los registros y a continuación la asocia con estos, los resultados de la comprobación serán impredecibles.
## ID de registro
Escriba un valor que identifique de manera exclusiva los registros principal y secundario.
# Valores específicos de registros de alias de conmutación por error
Cuando se crean registros de alias de conmutación por error, hay que especificar los siguientes valores.
Para obtener información, consulte los siguientes temas:
+ Para obtener información sobre cómo crear registros de conmutación por error en una zona alojada privada, consulte [Configuración de la conmutación por error en una zona alojada privada](dns-failover-private-hosted-zones.md).
+ Para obtener información sobre los registros de alias, consulte [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Política de direccionamiento](#rrsets-values-failover-alias-routing-policy)
+ [Nombre del registro](#rrsets-values-failover-alias-name)
+ [Tipo de registro](#rrsets-values-failover-alias-type)
+ [Valor/ruta de destino del tráfico](#rrsets-values-failover-alias-alias-target)
+ [Tipo de registro de conmutación por error](#rrsets-values-failover-alias-failover-record-type)
+ [Health check](#rrsets-values-failover-alias-associate-with-health-check)
+ [Evaluate target health](#rrsets-values-failover-alias-evaluate-target-health)
+ [ID de registro](#rrsets-values-failover-alias-set-id)
## Política de direccionamiento
Elija **Failover** (Conmutación por error).
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no ingrese un valor (por ejemplo, un símbolo @) en el campo **Record name** (Nombre del registro).
Escriba el mismo nombre para los dos registros del grupo de registros de conmutación por error.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el valor aplicable en función del AWS recurso al que está enrutando el tráfico. Seleccione el mismo valor para los registros de conmutación por error principales y secundarios:
**API regionales personalizadas o API optimizadas para bordes de API Gateway**
Selecciona **A — IPv4 dirección**.
**Puntos de conexión de interfaz de Amazon VPC**
Seleccione **A — IPv4 dirección**.
**CloudFront distribución**
Seleccione **A — IPv4 dirección**.
Si IPv6 está habilitada para la distribución, cree dos registros, uno con el valor **A ( IPv4 dirección** de **tipo**) y otro con el valor **AAAA ( IPv6 dirección)**.
**Servicio de App Runner**
Seleccione **A — dirección IPv4 **
**Entorno de Elastic Beanstalk con subdominios regionalizados**
Seleccione **A — IPv4 dirección**
**Balanceador de carga de ELB**
Seleccione **una IPv4 dirección** O una dirección **AAAA IPv6 **
**Bucket de Amazon S3**
Seleccione **A — dirección IPv4 **
**OpenSearch Servicio**
Seleccione **una IPv4 dirección** o una dirección **AAAA IPv6 **
**Otro registro en esta zona alojada**
Seleccione el tipo de registro para el que va a crear el alias. Se admiten todos los tipos, excepto **NS** y **SOA**.
Si va a crear un registro de alias con el mismo nombre que la zona alojada (lo que se conoce como *ápex de zona*), no podrá dirigir el tráfico a un registro en el que el valor de **Type (Tipo)** sea **CNAME**. Esto se debe a que el registro de alias debe tener el mismo tipo que el registro al que está redirigiendo el tráfico y no es posible crear un registro CNAME para el ápex de zona (ni siquiera para un registro de alias).
## Valor/ruta de destino del tráfico
El valor que elija de la lista o que escriba en el campo depende del AWS recurso al que dirija el tráfico.
Para obtener información sobre AWS los recursos a los que puede dirigirse, consulte [los valores comunes de los registros de alias a los que se dirige value/route el tráfico](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Para obtener más información sobre cómo configurar Route 53 para enrutar el tráfico a AWS recursos específicos, consulte[Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
**nota**
Cuando cree registros de conmutación por error principales y secundarios, tiene la opción de crear un registro de conmutación por error y un registro de *alias* de conmutación por error con los mismos valores para **Name** (Nombre) y **Record type** (Tipo de registro). Si combina registros de conmutación por error y de alias de conmutación por error, cualquiera de ellos puede ser el registro principal.
## Tipo de registro de conmutación por error
Elija el valor aplicable para este registro. Para que la conmutación por error funcione correctamente, debe crear un registro de conmutación por error principal y uno secundario.
No puede crear registros sin conmutación por error que tengan los mismos valores de **Record name** (Nombre del registro) y **Record type** (Tipo de registro) que los registros de conmutación por error.
## Health check
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Yes** (Sí) en **Evaluate Target Health** (Evaluar el estado del destino) para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias de latencia, alias basado en IP o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain Name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name (Nombre de dominio)** coincide con el nombre de los registros y a continuación la asocia con estos, los resultados de la comprobación serán impredecibles.
## Evaluate target health
Seleccione **Sí**, si desea que Route 53 determine si debe responder a las consultas de DNS mediante este registro al verificar el estado del recurso especificado mediante **Punto de conexión**.
Tenga en cuenta lo siguiente:
**API Gateway personalizado, regional APIs y optimizado para entornos periféricos APIs**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es una API regional personalizada o una API optimizada para periferias de API Gateway.
**CloudFront distribuciones**
No puede establecer **Evaluar el estado del objetivo** en **Sí** cuando el punto final es una CloudFront distribución.
**Entornos de Elastic Beanstalk que tienen subdominios regionalizados**
Si especifica un entorno de Elastic Beanstalk en **Punto de conexión** y el entorno contiene un equilibrador de carga de ELB, Elastic Load Balancing dirige las consultas solo a las instancias de Amazon EC2 en buen estado que están registradas en el equilibrador de carga. (Un entorno contiene automáticamente un balanceador de carga de ELB si incluye más de una instancia Amazon EC2). Si establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) y no hay instancias de Amazon EC2 en buen estado, o el balanceador de carga en sí no está en buen estado, Route 53 dirige las consultas a otros recursos disponibles en buen estado, si los hay.
Si el entorno contiene una sola instancia Amazon EC2, no hay requisitos especiales.
**Balanceadores de carga de ELB**
El comportamiento de la comprobación de estado depende del tipo de balanceador de carga:
+ **Equilibradores de carga clásicos**: si especifica un equilibrador de carga clásico de ELB en **Punto de conexión**, Elastic Load Balancing dirigirá las consultas solo a las instancias de Amazon EC2 en buen estado que estén registradas con el equilibrador de carga. Si establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) y no hay instancias de EC2 en buen estado o el balanceador de carga en sí no está en buen estado, Route 53 dirige las consultas a otros recursos.
+ **Balanceadores de carga de red y aplicaciones**: si especifica un balanceador de carga de red o aplicaciones ELB, y establece **Evaluate Target health** (Evaluar estado del destino) en **Yes** (Sí), Route 53 dirige consultas al balanceador de carga en función del estado de los grupos de destino asociados al balanceador de carga:
+ Para que se considere que una aplicación o un equilibrador de carga de red está en buen estado, cada grupo de destinos que contenga destinos debe tener al menos un destino en buen estado. Si cualquier grupo de destinos contiene únicamente destinos en mal estado, se considera que el balanceador de carga está en mal estado y Route 53 envía las consultas a otros recursos.
+ Un grupo de destinos que no tiene destinos registrados se considera que no está en buen estado.
Al crear un balanceador de carga, configura las opciones de las comprobaciones de estado de Elastic Load Balancing. Estas no son comprobaciones de estado de Route 53, pero realizan una función similar. No cree comprobaciones de estado de Route 53 para las instancias de EC2 que registre en un balanceador de carga de ELB.
**Buckets de S3**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es un bucket de S3.
**Puntos de enlace de interfaz de Amazon VPC**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es uno de interfaz de Amazon VPC.
**Otros registros de la misma zona alojada**
Si el AWS recurso que especifica en el **punto final** es un registro o un grupo de registros (por ejemplo, un grupo de registros ponderados) pero no es otro registro de alias, le recomendamos que asocie una comprobación de estado a todos los registros del punto final. Para obtener más información, consulte [¿Qué sucede cuando se omiten las comprobaciones de estado?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID de registro
Escriba un valor que identifique de manera exclusiva los registros principal y secundario.
# Valores específicos de registros de geolocalización
Cuando se crean registros de geolocalización, hay que especificar los siguientes valores.
**Topics**
+ [Política de direccionamiento](#rrsets-values-geo-routing-policy)
+ [Nombre del registro](#rrsets-values-geo-name)
+ [Tipo de registro](#rrsets-values-geo-type)
+ [TTL (segundos)](#rrsets-values-geo-ttl)
+ [Valor/ruta de destino del tráfico](#rrsets-values-geo-value)
+ [Ubicación](#rrsets-values-geo-location)
+ [Estados de Estados Unidos](#rrsets-values-geo-sublocation)
+ [Health check](#rrsets-values-geo-associate-with-health-check)
+ [ID de registro](#rrsets-values-geo-set-id)
## Política de direccionamiento
Elija **Geolocation** (Geolocalización).
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no escriba un valor (por ejemplo, un símbolo @) en el campo **Name (Nombre)**.
Escriba el mismo nombre para todos los registros del grupo de registros de geolocalización.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el mismo valor para todos los registros del grupo de registros de geolocalización.
## TTL (segundos)
El tiempo, en segundos, en que desea que los solucionadores recursivos de DNS almacenen en caché información sobre este registro. Si especifica un valor más largo (por ejemplo, 172 800 segundos o dos días), se reduce el número de llamadas que los solucionadores recursivos de DNS deben realizar a Route 53 para obtener la información más reciente de este registro. Esto reduce la latencia y la factura del servicio Route 53. Para obtener más información, consulte [Cómo dirige Amazon Route 53 el tráfico de su dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Sin embargo, si especifica un valor más largo para TTL, los cambios realizados en el registro (por ejemplo, una nueva dirección IP) tardarán más tiempo en surtir efecto, ya que los solucionadores recursivos usan los valores de la memoria caché durante periodos más largos antes de solicitar la información más reciente a Route 53. Si está cambiando la configuración de un dominio o subdominio que ya está en uso, le recomendamos que inicialmente especifique un valor más corto, por ejemplo, 300 segundos y que aumente el valor después de confirmar que la configuración nueva es correcta.
Si asocia este registro a una comprobación de estado, es recomendable que especifique un TTL de 60 segundos o menos para que los clientes respondan rápidamente a los cambios de estado.
## Valor/ruta de destino del tráfico
Elija **IP address or another value depending on the record type (Dirección IP u otro valor en función del tipo de registro)**. Ingrese un valor que sea adecuado para el valor de **Record type** (Tipo de registro). Para todos los tipos excepto **CNAME**, puede escribir más de un valor. Escriba cada valor en una línea independiente.
Puede dirigir el tráfico a, o especificar los siguientes valores:
+ **A — IPv4 dirección**
+ **AAAA — IPv6 dirección**
+ **CAA: autorización de la entidad de certificación**
+ **CNAME: nombre canónico**
+ **MX: intercambio de correo**
+ **NAPTR: señalizador de autoridad de asignación de nombres**
+ **PTR: puntero**
+ **SPF: marco de políticas de remitente**
+ **SRV: localizador de servicios**
+ **TXT: texto**
Para obtener más información sobre los valores anteriores, consulte [los valores comunes Value/Route del tráfico hacia](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Ubicación
Cuando configure Route 53 para que responda a las consultas de DNS según la ubicación de origen de estas, seleccione el continente o el país para el que quiere que Route 53 responda con la configuración de este registro. Si quiere que Route 53 responda a las consultas de DNS para estados individuales de Estados Unidos, seleccione **United States** (Estados Unidos) de la lista **Location** (Ubicación) y luego el estado en el grupo **Sublocation** (Sublocalización).
Para una zona alojada privada, selecciona el continente, país o subdivisión más cercano al lugar en el Región de AWS que se encuentra tu recurso. Por ejemplo, si el recurso se encuentra en us-east-1, puede especificar Norteamérica, Estados Unidos o Virginia.
**importante**
Es recomendable crear un registro de geolocalización con el valor **Default (Predeterminada)** para **Location (Ubicación)**. Esto cubre las ubicaciones geográficas para las que no se hayan creado registros y las direcciones IP para las que Route 53 no puede identificar la ubicación.
No puede crear registros sin geolocalización que tengan los mismos valores de **Record name** (Nombre del registro) y **Record type** (Tipo de registro) que los registros de geolocalización.
Para obtener más información, consulte [Enrutado de geolocalización](routing-policy-geo.md).
Estos son los países que Amazon Route 53 asocia con cada continente. Los códigos de país son de ISO 3166. Para obtener más información, consulte el artículo de Wikipedia [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2):
**África (AF)**
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW
**Antártida (AN)**
AQ, GS, TF
**Asia (AS)**
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE
**Europa (UE)**
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK
Algunos proveedores consideran que TR está en Asia, y esto se verá reflejado en las direcciones IP.
**América del Norte (NA)**
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI
**Oceanía (OC)**
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS
**América del Sur (SA)**
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE
**nota**
Route 53 no permite crear registros de geolocalización para los siguientes países: Isla Bouvet (BV), Isla de Navidad (CX), Sáhara Occidental (EH) e Isla e Islas Heard McDonald (HM). No hay datos disponibles sobre las direcciones IP de estos países.
## Estados de Estados Unidos
Cuando configure Route 53 para que responda a las consultas de DNS según el estado de Estados Unidos de origen de las consultas, seleccione el estado de la lista **U.S. states** (Estados de Estados Unidos). En la lista **Location (Ubicación)**, los territorios de Estados Unidos (por ejemplo, Puerto Rico) figuran como países.
**importante**
Algunas direcciones IP están asociadas con Estados Unidos, pero no con un estado individual. Si crea registros para todos los estados de Estados Unidos, es recomendable que también cree un registro para Estados Unidos con objeto de dirigir las consultas de estas direcciones IP no asociadas. Si no crea un registro para Estados Unidos, Route 53 responde a las consultas de DNS procedentes de las direcciones IP de Estados Unidos no asociadas con la configuración del registro de geolocalización predeterminado (si ha creado uno) o con una respuesta “sin respuesta”.
## Health check
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Yes** (Sí) en **Evaluate Target Health** (Evaluar el estado del destino) para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias de latencia, alias basado en IP o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain Name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name (Nombre de dominio)** coincide con el nombre de los registros y a continuación la asocia con estos, los resultados de la comprobación serán impredecibles.
En el caso de los registros de geolocalización, si un punto de conexión no está en buen estado, Route 53 busca un registro para la región geográfica asociada de mayor tamaño. Por ejemplo, supongamos que tiene registros para un estado en Estados Unidos, para Estados Unidos, para América del Norte y para todas las ubicaciones (**Location (Ubicación)** es **Default (Predeterminada)**). Si el punto de conexión del registro de estado no está en buen estado, Route 53 verifica los registros para Estados Unidos, para América del Norte y para todas las ubicaciones, en ese orden, hasta que encuentre un registro con un punto de conexión en buen estado. Si ninguno de los registros está en buen estado, incluido el registro de todas las ubicaciones, Route 53 responde a la consulta de DNS utilizando el valor del registro de la región geográfica más pequeña.
## ID de registro
Escriba un valor que identifique de manera exclusiva este registro en el grupo de registros de geolocalización.
# Valores específicos de registros de alias de geolocalización
Cuando se crean registros de alias de geolocalización, hay que especificar los siguientes valores.
Para obtener más información, consulte [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Política de direccionamiento](#rrsets-values-geo-alias-routing-policy)
+ [Nombre del registro](#rrsets-values-geo-alias-name)
+ [Tipo de registro](#rrsets-values-geo-alias-type)
+ [Valor/ruta de destino del tráfico](#rrsets-values-geo-alias-alias-target)
+ [Ubicación](#rrsets-values-geo-alias-location)
+ [Estados de Estados Unidos](#rrsets-values-geo-alias-sublocation)
+ [Health check](#rrsets-values-geo-alias-associate-with-health-check)
+ [Evaluate target health](#rrsets-values-geo-alias-evaluate-target-health)
+ [ID de registro](#rrsets-values-geo-alias-set-id)
## Política de direccionamiento
Elija **Geolocation** (Geolocalización).
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no ingrese un valor (por ejemplo, un símbolo @) en el campo **Record name** (Nombre del registro).
Escriba el mismo nombre para todos los registros del grupo de registros de geolocalización.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el valor aplicable en función del AWS recurso al que está enrutando el tráfico. Seleccione el mismo valor para todos los registros del grupo de registros de geolocalización:
**API regionales personalizadas o API optimizadas para bordes de API Gateway**
Selecciona **A — IPv4 dirección**.
**Puntos de conexión de interfaz de Amazon VPC**
Seleccione **A — IPv4 dirección**.
**CloudFront distribución**
Seleccione **A — IPv4 dirección**.
Si IPv6 está habilitada para la distribución, cree dos registros, uno con el valor **A ( IPv4 dirección** de **tipo**) y otro con el valor **AAAA ( IPv6 dirección)**.
**Servicio de App Runner**
Seleccione **A — dirección IPv4 **
**Entorno de Elastic Beanstalk con subdominios regionalizados**
Seleccione **A — IPv4 dirección**
**Balanceador de carga de ELB**
Seleccione la ** IPv4 dirección A** o la dirección **AAAA IPv6 **
**Bucket de Amazon S3**
Seleccione **A — dirección IPv4 **
**OpenSearch Servicio**
Seleccione **una IPv4 dirección** o una dirección **AAAA IPv6 **
**Otro registro en esta zona alojada**
Seleccione el tipo de registro para el que va a crear el alias. Se admiten todos los tipos, excepto **NS** y **SOA**.
Si va a crear un registro de alias con el mismo nombre que la zona alojada (lo que se conoce como *ápex de zona*), no podrá dirigir el tráfico a un registro en el que el valor de **Type (Tipo)** sea **CNAME**. Esto se debe a que el registro de alias debe tener el mismo tipo que el registro al que está redirigiendo el tráfico y no es posible crear un registro CNAME para el ápex de zona (ni siquiera para un registro de alias).
## Valor/ruta de destino del tráfico
El valor que elija de la lista o que escriba en el campo depende del AWS recurso al que dirija el tráfico.
Para obtener información sobre AWS los recursos a los que puede dirigirse, consulte[Valor/ruta de destino del tráfico](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Para obtener más información sobre cómo configurar Route 53 para enrutar el tráfico a AWS recursos específicos, consulte[Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
## Ubicación
Cuando configure Route 53 para que responda a las consultas de DNS según la ubicación de origen de estas, seleccione el continente o el país para el que quiere que Route 53 responda con la configuración de este registro. Si quiere que Route 53 responda a las consultas de DNS para estados individuales de Estados Unidos, seleccione **United States** (Estados Unidos) de la lista **Location** (Ubicación) y luego el estado en la lista **U.S. states** (Estados de Estados Unidos).
Para una zona alojada privada, seleccione el continente, país o subdivisión más cercano al lugar en el Región de AWS que se encuentra su recurso. Por ejemplo, si el recurso se encuentra en us-east-1, puede especificar Norteamérica, Estados Unidos o Virginia.
**importante**
Es recomendable crear un registro de geolocalización con el valor **Default (Predeterminada)** para **Location (Ubicación)**. Esto cubre las ubicaciones geográficas para las que no se hayan creado registros y las direcciones IP para las que Route 53 no puede identificar la ubicación.
No puede crear registros sin geolocalización que tengan los mismos valores de **Record name** (Nombre del registro) y **Record type** (Tipo de registro) que los registros de geolocalización.
Para obtener más información, consulte [Enrutado de geolocalización](routing-policy-geo.md).
Estos son los países que Amazon Route 53 asocia con cada continente. Los códigos de país son de ISO 3166. Para obtener más información, consulte el artículo de Wikipedia [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2):
**África (AF)**
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW
**Antártida (AN)**
AQ, GS, TF
**Asia (AS)**
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE
**Europa (UE)**
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK
Algunos proveedores consideran que TR está en Asia, y esto se verá reflejado en las direcciones IP.
**América del Norte (NA)**
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI
**Oceanía (OC)**
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS
**América del Sur (SA)**
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE
**nota**
Route 53 no permite crear registros de geolocalización para los siguientes países: Isla Bouvet (BV), Isla de Navidad (CX), Sáhara Occidental (EH) e Isla e Islas Heard McDonald (HM). No hay datos disponibles sobre las direcciones IP de estos países.
## Estados de Estados Unidos
Cuando configure Route 53 para que responda a las consultas de DNS según el estado de Estados Unidos de origen de las consultas, seleccione el estado de la lista **U.S. states** (Estados de Estados Unidos). En la lista **Location (Ubicación)**, los territorios de Estados Unidos (por ejemplo, Puerto Rico) figuran como países.
**importante**
Algunas direcciones IP están asociadas con Estados Unidos, pero no con un estado individual. Si crea registros para todos los estados de Estados Unidos, es recomendable que también cree un registro para Estados Unidos con objeto de dirigir las consultas de estas direcciones IP no asociadas. Si no crea un registro para Estados Unidos, Route 53 responde a las consultas de DNS procedentes de las direcciones IP de Estados Unidos no asociadas con la configuración del registro de geolocalización predeterminado (si ha creado uno) o con una respuesta “sin respuesta”.
## Health check
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Yes** (Sí) en **Evaluate Target Health** (Evaluar el estado del destino) para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias de latencia, alias basado en IP o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name** coincide con el nombre de los registros y luego la asocia con estos, los resultados de la comprobación serán impredecibles.
En el caso de los registros de geolocalización, si un punto de conexión no está en buen estado, Route 53 busca un registro para la región geográfica asociada de mayor tamaño. Por ejemplo, supongamos que tiene registros para un estado en Estados Unidos, para Estados Unidos, para América del Norte y para todas las ubicaciones (**Location (Ubicación)** es **Default (Predeterminada)**). Si el punto de conexión del registro de estado no está en buen estado, Route 53 verifica los registros para Estados Unidos, para América del Norte y para todas las ubicaciones, en ese orden, hasta que encuentre un registro con un punto de conexión en buen estado. Si ninguno de los registros está en buen estado, incluido el registro de todas las ubicaciones, Route 53 responde a la consulta de DNS utilizando el valor del registro de la región geográfica más pequeña.
## Evaluate target health
Seleccione **Sí**, si desea que Route 53 determine si debe responder a las consultas de DNS mediante este registro al verificar el estado del recurso especificado mediante **Punto de conexión**.
Tenga en cuenta lo siguiente:
**API Gateway personalizado, regional APIs y optimizado para entornos periféricos APIs**
No existen requisitos especiales para establecer **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) cuando el punto de conexión es una API regional personalizada o una API optimizada para bordes de API Gateway.
**CloudFront distribuciones**
No puede establecer **Evaluar el estado del objetivo** en **Sí** cuando el punto final es una CloudFront distribución.
**Entornos de Elastic Beanstalk que tienen subdominios regionalizados**
Si especifica un entorno de Elastic Beanstalk en **Punto de conexión** y el entorno contiene un equilibrador de carga de ELB, Elastic Load Balancing dirige las consultas solo a las instancias de Amazon EC2 en buen estado que están registradas en el equilibrador de carga. (Un entorno contiene automáticamente un balanceador de carga de ELB si incluye más de una instancia Amazon EC2). Si establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) y no hay instancias de Amazon EC2 en buen estado, o el balanceador de carga en sí no está en buen estado, Route 53 dirige las consultas a otros recursos disponibles en buen estado, si los hay.
Si el entorno contiene una sola instancia Amazon EC2, no hay requisitos especiales.
**Balanceadores de carga de ELB**
El comportamiento de la comprobación de estado depende del tipo de balanceador de carga:
+ **Equilibradores de carga clásicos**: si especifica un equilibrador de carga clásico de ELB en **Punto de conexión**, Elastic Load Balancing dirigirá las consultas solo a las instancias de Amazon EC2 en buen estado que estén registradas con el equilibrador de carga. Si establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) y no hay instancias de EC2 en buen estado o el balanceador de carga en sí no está en buen estado, Route 53 dirige las consultas a otros recursos.
+ **Network Load Balancers y aplicaciones**: si especifica un Network Load Balancers o aplicaciones ELB, y establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí), Route 53 dirige consultas al balanceador de carga en función del estado de los grupos de destino asociados al balanceador de carga:
+ Para que se considere que un Application Load Balancer o un Network Load Balancer está en buen estado, cada grupo de destinos que contenga destinos debe contener al menos un destino en buen estado. Si cualquier grupo de destinos contiene únicamente destinos en mal estado, se considera que el balanceador de carga está en mal estado y Route 53 envía las consultas a otros recursos.
+ Un grupo de destinos que no tiene destinos registrados se considera que no está en buen estado.
Al crear un balanceador de carga, configura las opciones de las comprobaciones de estado de Elastic Load Balancing. Estas no son comprobaciones de estado de Route 53, pero realizan una función similar. No cree comprobaciones de estado de Route 53 para las instancias de EC2 que registre en un balanceador de carga de ELB.
**Buckets de S3**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es un bucket de S3.
**Puntos de enlace de interfaz de Amazon VPC**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es uno de interfaz de Amazon VPC.
**Otros registros de la misma zona alojada**
Si el AWS recurso que especifica en el **punto final** es un registro o un grupo de registros (por ejemplo, un grupo de registros ponderados) pero no es otro registro de alias, le recomendamos que asocie una comprobación de estado a todos los registros del punto final. Para obtener más información, consulte [¿Qué sucede cuando se omiten las comprobaciones de estado?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID de registro
Escriba un valor que identifique de manera exclusiva este registro en el grupo de registros de geolocalización.
# Valores específicos de registros de geoproximidad
Cuando se crean registros de geoproximidad, debe especificar los siguientes valores.
**Topics**
+ [Política de direccionamiento](#rrsets-values-geoprox-routing-policy)
+ [Nombre del registro](#rrsets-values-geoprox-name)
+ [Tipo de registro](#rrsets-values-geoprox-type)
+ [TTL (segundos)](#rrsets-values-geoprox-ttl)
+ [Valor/ruta de destino del tráfico](#rrsets-values-geoprox-value)
+ [Ubicación de puntos de conexión](#rrsets-values-geoprox-endpoint-location)
+ [Sesgo](#rrsets-values-geoprox-bias)
+ [Health check](#rrsets-values-geoprox-associate-with-health-check)
+ [ID de registro](#rrsets-values-geoprox-set-id)
## Política de direccionamiento
Elija **Geoproximidad**.
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no escriba un valor (por ejemplo, un símbolo @) en el campo **Name (Nombre)**.
Escriba el mismo nombre para todos los registros del grupo de registros de geoproximidad.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el mismo valor para todos los registros del grupo de registros de geoproximidad.
## TTL (segundos)
El tiempo, en segundos, en que desea que los solucionadores recursivos de DNS almacenen en caché información sobre este registro. Si especifica un valor más largo (por ejemplo, 172 800 segundos o dos días), se reduce el número de llamadas que los solucionadores recursivos de DNS deben realizar a Route 53 para obtener la información más reciente de este registro. Esto reduce la latencia y la factura del servicio Route 53. Para obtener más información, consulte [Cómo dirige Amazon Route 53 el tráfico de su dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Sin embargo, si especifica un valor más largo para TTL, los cambios realizados en el registro (por ejemplo, una nueva dirección IP) tardarán más tiempo en surtir efecto, ya que los solucionadores recursivos usan los valores de la memoria caché durante periodos más largos antes de solicitar la información más reciente a Route 53. Si está cambiando la configuración de un dominio o subdominio que ya está en uso, le recomendamos que inicialmente especifique un valor más corto, por ejemplo, 300 segundos y que aumente el valor después de confirmar que la configuración nueva es correcta.
Si asocia este registro a una comprobación de estado, es recomendable que especifique un TTL de 60 segundos o menos para que los clientes respondan rápidamente a los cambios de estado.
## Valor/ruta de destino del tráfico
Elija **IP address or another value depending on the record type (Dirección IP u otro valor en función del tipo de registro)**. Ingrese un valor que sea adecuado para el valor de **Record type** (Tipo de registro). Para todos los tipos excepto **CNAME**, puede escribir más de un valor. Escriba cada valor en una línea independiente.
Puede dirigir el tráfico a, o especificar los siguientes valores:
+ **A — IPv4 dirección**
+ **AAAA — IPv6 dirección**
+ **CAA: autorización de la entidad de certificación**
+ **CNAME: nombre canónico**
+ **MX: intercambio de correo**
+ **NAPTR: señalizador de autoridad de asignación de nombres**
+ **PTR: puntero**
+ **SPF: marco de políticas de remitente**
+ **SRV: localizador de servicios**
+ **TXT: texto**
Para obtener más información sobre los valores anteriores, consulte [los valores comunes Value/Route del tráfico hacia](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Ubicación de puntos de conexión
Puede especificar la ubicación del punto de conexión del recurso mediante uno de los siguientes métodos:
**Coordenadas personalizadas**
Especifique la longitud y la latitud de un área geográfica.
**Región de AWS**
Elija una región disponible en la lista de **Ubicaciones**.
Para obtener más información acerca de las regiones, consulte [Infraestructura global de AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
**AWS Grupo de zonas locales**
Elija un grupo de zonas locales disponible de la lista de **Ubicaciones**.
Para obtener más información acerca de las zonas locales, consulte [Zonas locales disponibles](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) en la *Guía del usuario de zonas locales de AWS *. Un grupo de zonas locales suele ser la zona local sin el carácter final. Por ejemplo, si la zona local es `us-east-1-bue-1a`, el grupo de zonas locales es `us-east-1-bue-1`.
También puede identificar el grupo de zonas locales de una zona local específica mediante el comando [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI:
```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```
Este comando devuelve `"GroupName": "us-west-2-den-1"` y se especifica que la zona local `us-west-2-den-1a` pertenece al grupo de zonas locales `us-west-2-den-1`.
No puede crear registros sin geoproximidad que tengan los mismos valores de **Nombre del registro** y **Tipo de registro** que los registros de geoproximidad.
Tampoco puede crear dos conjuntos de registros de recursos de geoproximidad que especifiquen la misma ubicación para el mismo nombre y tipo de registro.
## Sesgo
Un sesgo expande o reduce el área geográfica desde la que Route 53 direcciona el tráfico a un recurso. Un sesgo positivo expande el área y un sesgo negativo la reduce. Para obtener más información, consulte [Cómo utiliza Amazon Route 53 el sesgo para dirigir el tráfico](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).
## Health check
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Sí** en **Evaluar el estado del destino** para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias de geoproximidad, alias de latencia, alias basado en IP o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain Name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name (Nombre de dominio)** coincide con el nombre de los registros y a continuación la asocia con estos, los resultados de la comprobación serán impredecibles.
En el caso de los registros de geoproximidad, si un punto de conexión no está en buen estado, Route 53 busca el punto de conexión más cercano que todavía esté en buen estado.
## ID de registro
Escriba un valor que identifique de manera exclusiva este registro en el grupo de registros de geoproximidad.
# Valores específicos de registros de alias de geoproximidad
Cuando se crean registros de alias de geoproximidad, hay que especificar los siguientes valores.
Para obtener más información, consulte [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Política de direccionamiento](#rrsets-values-geoprox-alias-routing-policy)
+ [Nombre del registro](#rrsets-values-geoprox-alias-name)
+ [Tipo de registro](#rrsets-values-geoprox-alias-type)
+ [Valor/ruta de destino del tráfico](#rrsets-values-geoprox-alias-alias-target)
+ [Ubicación de puntos de conexión](#rrsets-values-geoprox-alias-endpoint-location)
+ [Sesgo](#rrsets-values-geoprox-alias-bias)
+ [Chequeo de salud](#rrsets-values-geoprox-alias-associate-with-health-check)
+ [Evaluate target health](#rrsets-values-geoprox-alias-evaluate-target-health)
+ [ID de registro](#rrsets-values-geoprox-alias-set-id)
## Política de direccionamiento
Elija **Geoproximidad**.
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no ingrese un valor (por ejemplo, un símbolo @) en el campo **Record name** (Nombre del registro).
Escriba el mismo nombre para todos los registros del grupo de registros de geoproximidad.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el valor aplicable en función del AWS recurso al que está enrutando el tráfico. Seleccione el mismo valor para todos los registros del grupo de registros de geoproximidad:
**API regionales personalizadas o API optimizadas para bordes de API Gateway**
Selecciona **A — IPv4 dirección**.
**Puntos de conexión de interfaz de Amazon VPC**
Seleccione **A — IPv4 dirección**.
**CloudFront distribución**
Seleccione **A — IPv4 dirección**.
Si IPv6 está habilitada para la distribución, cree dos registros, uno con el valor **A ( IPv4 dirección** para el **tipo**) y otro con el valor **AAAA ( IPv6 dirección)**.
**Servicio de App Runner**
Seleccione **A — dirección IPv4 **
**Entorno de Elastic Beanstalk con subdominios regionalizados**
Seleccione **A — IPv4 dirección**
**Balanceador de carga de ELB**
Seleccione la ** IPv4 dirección A** o la dirección **AAAA IPv6 **
**Bucket de Amazon S3**
Seleccione **A — dirección IPv4 **
**OpenSearch Servicio**
Seleccione **una IPv4 dirección** o una dirección **AAAA IPv6 **
**Otro registro en esta zona alojada**
Seleccione el tipo de registro para el que va a crear el alias. Se admiten todos los tipos, excepto **NS** y **SOA**.
Si va a crear un registro de alias con el mismo nombre que la zona alojada (lo que se conoce como *ápex de zona*), no podrá dirigir el tráfico a un registro en el que el valor de **Type (Tipo)** sea **CNAME**. Esto se debe a que el registro de alias debe tener el mismo tipo que el registro al que está redirigiendo el tráfico y no es posible crear un registro CNAME para el ápex de zona (ni siquiera para un registro de alias).
## Valor/ruta de destino del tráfico
El valor que elija de la lista o que escriba en el campo depende del AWS recurso al que dirija el tráfico.
Para obtener información sobre AWS los recursos a los que puede dirigirse, consulte[Valor/ruta de destino del tráfico](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Para obtener más información sobre cómo configurar Route 53 para enrutar el tráfico a AWS recursos específicos, consulte[Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
## Ubicación de puntos de conexión
Puede especificar la ubicación del punto de conexión del recurso mediante uno de los siguientes métodos:
**Coordenadas personalizadas**
Especifique la longitud y la latitud de un área geográfica.
**Región de AWS**
Elija una región disponible en la lista de **Ubicaciones**.
Para obtener más información acerca de las regiones, consulte [Infraestructura global de AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
**AWS Grupo de zonas locales**
Elija una región de zona local disponible de la lista de **Ubicaciones**.
Para obtener más información acerca de las zonas locales, consulte [Zonas locales disponibles](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) en la *Guía del usuario de zonas locales de AWS *. Un grupo de zonas locales suele ser la zona local sin el carácter final. Por ejemplo, si la zona local es `us-east-1-bue-1a`, el grupo de zonas locales es `us-east-1-bue-1`.
También puede identificar el grupo de zonas locales de una zona local específica mediante el comando [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI:
```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```
Este comando devuelve `"GroupName": "us-west-2-den-1"` y se especifica que la zona local `us-west-2-den-1a` pertenece al grupo de zonas locales `us-west-2-den-1`.
No puede crear registros sin geoproximidad que tengan los mismos valores de **Nombre del registro** y **Tipo de registro** que los registros de geoproximidad.
Tampoco puede crear dos conjuntos de registros de recursos de geoproximidad que especifiquen la misma ubicación para el mismo nombre y tipo de registro.
Para obtener más información, consulte available-local-zones .html
## Sesgo
Un sesgo expande o reduce el área geográfica desde la que Route 53 direcciona el tráfico a un recurso. Un sesgo positivo expande el área y un sesgo negativo la reduce. Para obtener más información, consulte [Cómo utiliza Amazon Route 53 el sesgo para dirigir el tráfico](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).
## Chequeo de salud
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Sí** en **Evaluar el estado del destino** para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias de geoproximidad, alias de latencia, alias basado en IP o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name** coincide con el nombre de los registros y luego la asocia con estos, los resultados de la comprobación serán impredecibles.
En el caso de los registros de geoproximidad, si un punto de conexión no está en buen estado, Route 53 busca el punto de conexión más cercano que todavía esté en buen estado.
## Evaluate target health
Seleccione **Sí**, si desea que Route 53 determine si debe responder a las consultas de DNS mediante este registro al verificar el estado del recurso especificado mediante **Punto de conexión**.
Tenga en cuenta lo siguiente:
**API Gateway personalizado, regional APIs y optimizado para entornos periféricos APIs**
No existen requisitos especiales para establecer **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) cuando el punto de conexión es una API regional personalizada o una API optimizada para bordes de API Gateway.
**CloudFront distribuciones**
No puede establecer **Evaluar el estado del objetivo** en **Sí** cuando el punto final es una CloudFront distribución.
**Entornos de Elastic Beanstalk que tienen subdominios regionalizados**
Si especifica un entorno de Elastic Beanstalk en **Punto de conexión** y el entorno contiene un equilibrador de carga de ELB, Elastic Load Balancing dirige las consultas solo a las instancias de Amazon EC2 en buen estado que están registradas en el equilibrador de carga. (Un entorno contiene automáticamente un balanceador de carga de ELB si incluye más de una instancia Amazon EC2). Si establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) y no hay instancias de Amazon EC2 en buen estado, o el balanceador de carga en sí no está en buen estado, Route 53 dirige las consultas a otros recursos disponibles en buen estado, si los hay.
Si el entorno contiene una sola instancia Amazon EC2, no hay requisitos especiales.
**Balanceadores de carga de ELB**
El comportamiento de la comprobación de estado depende del tipo de balanceador de carga:
+ **Equilibradores de carga clásicos**: si especifica un equilibrador de carga clásico de ELB en **Punto de conexión**, Elastic Load Balancing dirigirá las consultas solo a las instancias de Amazon EC2 en buen estado que estén registradas con el equilibrador de carga. Si establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) y no hay instancias de EC2 en buen estado o el balanceador de carga en sí no está en buen estado, Route 53 dirige las consultas a otros recursos.
+ **Network Load Balancers y aplicaciones**: si especifica un Network Load Balancers o aplicaciones ELB, y establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí), Route 53 dirige consultas al balanceador de carga en función del estado de los grupos de destino asociados al balanceador de carga:
+ Para que se considere que un Application Load Balancer o un Network Load Balancer está en buen estado, cada grupo de destinos que contenga destinos debe contener al menos un destino en buen estado. Si cualquier grupo de destinos contiene únicamente destinos en mal estado, se considera que el balanceador de carga está en mal estado y Route 53 envía las consultas a otros recursos.
+ Un grupo de destinos que no tiene destinos registrados se considera que no está en buen estado.
Al crear un balanceador de carga, configura las opciones de las comprobaciones de estado de Elastic Load Balancing. Estas no son comprobaciones de estado de Route 53, pero realizan una función similar. No cree comprobaciones de estado de Route 53 para las instancias de EC2 que registre en un balanceador de carga de ELB.
**Buckets de S3**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es un bucket de S3.
**Puntos de enlace de interfaz de Amazon VPC**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es uno de interfaz de Amazon VPC.
**Otros registros de la misma zona alojada**
Si el AWS recurso que especifica en el **punto final** es un registro o un grupo de registros (por ejemplo, un grupo de registros ponderados) pero no es otro registro de alias, le recomendamos que asocie una comprobación de estado a todos los registros del punto final. Para obtener más información, consulte [¿Qué sucede cuando se omiten las comprobaciones de estado?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID de registro
Escriba un valor que identifique de manera exclusiva este registro en el grupo de registros de geoproximidad.
# Valores específicos de registros de latencia
Cuando se crean registros de latencia, hay que especificar los siguientes valores.
**Topics**
+ [Política de direccionamiento](#rrsets-values-latency-routing-policy)
+ [Nombre del registro](#rrsets-values-latency-name)
+ [Tipo de registro](#rrsets-values-latency-type)
+ [TTL (segundos)](#rrsets-values-latency-ttl)
+ [Valor/ruta de destino del tráfico](#rrsets-values-latency-value)
+ [Region](#rrsets-values-latency-region)
+ [Chequeo de salud](#rrsets-values-latency-associate-with-health-check)
+ [ID de registro](#rrsets-values-latency-set-id)
## Política de direccionamiento
Elija **Latency** (Latencia).
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no ingrese un valor (por ejemplo, un símbolo @) en el campo **Record name** (Nombre del registro).
Escriba el mismo nombre para todos los registros del grupo de registros de latencia.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el valor de **Type** (Tipo) en función de cómo desee que Route 53 responda a las consultas de DNS.
Seleccione el mismo valor para todos los registros del grupo de registros de latencia.
## TTL (segundos)
El tiempo, en segundos, en que desea que los solucionadores recursivos de DNS almacenen en caché información sobre este registro. Si especifica un valor más largo (por ejemplo, 172 800 segundos o dos días), se reduce el número de llamadas que los solucionadores recursivos de DNS deben realizar a Route 53 para obtener la información más reciente de este registro. Esto reduce la latencia y la factura del servicio Route 53. Para obtener más información, consulte [Cómo dirige Amazon Route 53 el tráfico de su dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Sin embargo, si especifica un valor más largo para TTL, los cambios realizados en el registro (por ejemplo, una nueva dirección IP) tardarán más tiempo en surtir efecto, ya que los solucionadores recursivos usan los valores de la memoria caché durante periodos más largos antes de solicitar la información más reciente a Route 53. Si está cambiando la configuración de un dominio o subdominio que ya está en uso, le recomendamos que inicialmente especifique un valor más corto, por ejemplo, 300 segundos y que aumente el valor después de confirmar que la configuración nueva es correcta.
Si asocia este registro a una comprobación de estado, es recomendable que especifique un TTL de 60 segundos o menos para que los clientes respondan rápidamente a los cambios de estado.
## Valor/ruta de destino del tráfico
Elija **IP address or another value depending on the record type (Dirección IP u otro valor en función del tipo de registro)**. Ingrese un valor que sea adecuado para el valor de **Record type** (Tipo de registro). Para todos los tipos excepto **CNAME**, puede escribir más de un valor. Escriba cada valor en una línea independiente.
Puede dirigir el tráfico a, o especificar los siguientes valores:
+ **A — IPv4 dirección**
+ **AAAA — IPv6 dirección**
+ **CAA: autorización de la entidad de certificación**
+ **CNAME: nombre canónico**
+ **MX: intercambio de correo**
+ **NAPTR: señalizador de autoridad de asignación de nombres**
+ **PTR: puntero**
+ **SPF: marco de políticas de remitente**
+ **SRV: localizador de servicios**
+ **TXT: texto**
Para obtener más información sobre los valores anteriores, consulte [los valores comunes Value/Route del tráfico hacia](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Region
Región de Amazon EC2 en la que reside el recurso especificado en este registro. Route 53 recomienda una región de Amazon EC2 en función de otros valores especificados. Esto también se aplica a las zonas alojadas privadas. Es recomendable que no cambie este valor.
Tenga en cuenta lo siguiente:
+ Solo puede crear un registro de latencia para cada región de Amazon EC2.
+ No es necesario crear registros de latencia para todas las regiones de Amazon EC2. Route 53 elige la región con la mejor latencia entre aquellas en las que creó registros de latencia.
+ No puede crear registros sin latencia que tengan los mismos valores de **Record name** (Nombre del registro) y **Record type** (Tipo de registro) que los registros de latencia.
+ Si crea un registro etiquetado con la región **cn-north-1**, Route 53 responderá siempre a las consultas procedentes de China utilizando este registro, independientemente de la latencia.
Para obtener más información acerca del uso de registros de latencia, consulte [Enrutado basado en latencia](routing-policy-latency.md).
## Chequeo de salud
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Yes** (Sí) en **Evaluate Target Health** (Evaluar el estado del destino) para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias de latencia, alias basado en IP o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name** coincide con el nombre de los registros y luego la asocia con estos, los resultados de la comprobación serán impredecibles.
## ID de registro
Escriba un valor que identifique de manera exclusiva este registro en el grupo de registros de latencia.
# Valores específicos de registros de alias de latencia
Cuando crean registros de alias de latencia, hay que especificar los siguientes valores.
Para obtener más información, consulte [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Política de direccionamiento](#rrsets-values-latency-alias-routing-policy)
+ [Nombre del registro](#rrsets-values-latency-alias-name)
+ [Tipo de registro](#rrsets-values-latency-alias-type)
+ [Valor/ruta de destino del tráfico](#rrsets-values-latency-alias-alias-target)
+ [Region](#rrsets-values-latency-alias-region)
+ [Chequeo de salud](#rrsets-values-latency-alias-associate-with-health-check)
+ [Evaluate target health](#rrsets-values-latency-alias-evaluate-target-health)
+ [ID de registro](#rrsets-values-latency-alias-set-id)
## Política de direccionamiento
Elija **Latency** (Latencia).
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no ingrese un valor (por ejemplo, un símbolo @) en el campo **Record name** (Nombre del registro).
Escriba el mismo nombre para todos los registros del grupo de registros de latencia.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name)
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el valor aplicable en función del AWS recurso al que está enrutando el tráfico:
**API regionales personalizadas o API optimizadas para bordes de API Gateway**
Selecciona **A — IPv4 dirección**.
**Puntos de conexión de interfaz de Amazon VPC**
Seleccione **A — IPv4 dirección**.
**CloudFront distribución**
Seleccione **A — IPv4 dirección**.
Si IPv6 está habilitada para la distribución, cree dos registros, uno con el valor **A ( IPv4 dirección** para el **tipo**) y otro con el valor **AAAA ( IPv6 dirección)**.
**Servicio de App Runner**
Seleccione **A — dirección IPv4 **
**Entorno de Elastic Beanstalk con subdominios regionalizados**
Seleccione **A — IPv4 dirección**
**Balanceador de carga de ELB**
Seleccione la ** IPv4 dirección A** o la dirección **AAAA IPv6 **
**Bucket de Amazon S3**
Seleccione **A — dirección IPv4 **
**OpenSearch Servicio**
Seleccione **una IPv4 dirección** o una dirección **AAAA IPv6 **
**Otro registro en esta zona alojada**
Seleccione el tipo de registro para el que va a crear el alias. Se admiten todos los tipos, excepto **NS** y **SOA**.
Si va a crear un registro de alias con el mismo nombre que la zona alojada (lo que se conoce como *ápex de zona*), no podrá dirigir el tráfico a un registro en el que el valor de **Type (Tipo)** sea **CNAME**. Esto se debe a que el registro de alias debe tener el mismo tipo que el registro al que está redirigiendo el tráfico y no es posible crear un registro CNAME para el ápex de zona (ni siquiera para un registro de alias).
Seleccione el mismo valor para todos los registros del grupo de registros de latencia.
## Valor/ruta de destino del tráfico
El valor que elija de la lista o que escriba en el campo depende del AWS recurso al que dirija el tráfico.
Para obtener información sobre AWS los recursos a los que puede dirigirse, consulte [los valores comunes de los registros de alias a los que se dirige value/route el tráfico](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Para obtener más información sobre cómo configurar Route 53 para enrutar el tráfico a AWS recursos específicos, consulte[Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
## Region
Región de Amazon EC2 en la que reside el recurso especificado en este registro. Route 53 recomienda una región de Amazon EC2 en función de otros valores especificados. Esto también se aplica a las zonas alojadas privadas. Es recomendable que no cambie este valor.
Tenga en cuenta lo siguiente:
+ Solo puede crear un registro de latencia para cada región de Amazon EC2.
+ No es necesario crear registros de latencia para todas las regiones de Amazon EC2. Route 53 elige la región con la mejor latencia entre aquellas en las que creó registros de latencia.
+ No puede crear registros sin latencia que tengan los mismos valores de **Record name** (Nombre del registro) y **Record type** (Tipo de registro) que los registros de latencia.
+ Si crea un registro etiquetado con la región **cn-north-1**, Route 53 responderá siempre a las consultas procedentes de China utilizando este registro, independientemente de la latencia.
Para obtener más información acerca del uso de registros de latencia, consulte [Enrutado basado en latencia](routing-policy-latency.md).
## Chequeo de salud
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Yes** (Sí) en **Evaluate Target Health** (Evaluar el estado del destino) para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias de latencia, alias basado en IP o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name (Nombre de dominio)** coincide con el nombre de los registros y a continuación la asocia con estos, los resultados de la comprobación serán impredecibles.
## Evaluate target health
Seleccione **Sí**, si desea que Route 53 determine si debe responder a las consultas de DNS mediante este registro al verificar el estado del recurso especificado mediante **Punto de conexión**.
Tenga en cuenta lo siguiente:
**API Gateway personalizado, regional APIs y optimizado para entornos periféricos APIs**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es una API regional personalizada o una API optimizada para periferias de API Gateway.
**CloudFront distribuciones**
No puede establecer **Evaluate Target Health** en **Sí** cuando el punto final es una CloudFront distribución.
**Entornos de Elastic Beanstalk que tienen subdominios regionalizados**
Si especifica un entorno de Elastic Beanstalk en **Punto de conexión** y el entorno contiene un equilibrador de carga de ELB, Elastic Load Balancing dirige las consultas solo a las instancias de Amazon EC2 en buen estado que están registradas en el equilibrador de carga. (Un entorno contiene automáticamente un balanceador de carga de ELB si incluye más de una instancia Amazon EC2). Si establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) y no hay instancias de Amazon EC2 en buen estado, o el balanceador de carga en sí no está en buen estado, Route 53 dirige las consultas a otros recursos disponibles en buen estado, si los hay.
Si el entorno contiene una sola instancia Amazon EC2, no hay requisitos especiales.
**Balanceadores de carga de ELB**
El comportamiento de la comprobación de estado depende del tipo de balanceador de carga:
+ **Equilibradores de carga clásicos**: si especifica un equilibrador de carga clásico de ELB en **Punto de conexión**, Elastic Load Balancing dirigirá las consultas solo a las instancias de Amazon EC2 en buen estado que estén registradas con el equilibrador de carga. Si establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) y no hay instancias de EC2 en buen estado o el balanceador de carga en sí no está en buen estado, Route 53 dirige las consultas a otros recursos.
+ **Network Load Balancers y aplicaciones**: si especifica un Network Load Balancers o aplicaciones ELB, y establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí), Route 53 dirige consultas al balanceador de carga en función del estado de los grupos de destino asociados al balanceador de carga:
+ Para que se considere que un Application Load Balancer o un Network Load Balancer está en buen estado, cada grupo de destinos que contenga destinos debe contener al menos un destino en buen estado. Si cualquier grupo de destinos contiene únicamente destinos en mal estado, se considera que el balanceador de carga está en mal estado y Route 53 envía las consultas a otros recursos.
+ Un grupo de destinos que no tiene destinos registrados se considera que no está en buen estado.
Al crear un balanceador de carga, configura las opciones de las comprobaciones de estado de Elastic Load Balancing. Estas no son comprobaciones de estado de Route 53, pero realizan una función similar. No cree comprobaciones de estado de Route 53 para las instancias de EC2 que registre en un balanceador de carga de ELB.
**Buckets de S3**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es un bucket de S3.
**Puntos de enlace de interfaz de Amazon VPC**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es uno de interfaz de Amazon VPC.
**Otros registros de la misma zona alojada**
Si el AWS recurso que especifica en el **punto final** es un registro o un grupo de registros (por ejemplo, un grupo de registros ponderados) pero no es otro registro de alias, le recomendamos que asocie una comprobación de estado a todos los registros del punto final. Para obtener más información, consulte [¿Qué sucede cuando se omiten las comprobaciones de estado?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID de registro
Escriba un valor que identifique de manera exclusiva este registro en el grupo de registros de latencia.
# Valores específicos para los registros basados en IP
Cuando se crean registros basados en IP, se especifican los siguientes valores.
**nota**
Aunque la creación de registros basados en IP en una zona alojada privada está permitida, no es compatible.
**Topics**
+ [Política de direccionamiento](#rrsets-values-ipbased-routing-policy)
+ [Nombre del registro](#rrsets-values-ibased-name)
+ [Tipo de registro](#rrsets-values-ibased-type)
+ [TTL (segundos)](#rrsets-values-ibased-ttl)
+ [Valor/ruta de destino del tráfico](#rrsets-values-ibased-value)
+ [Ubicación](#rrsets-values-ibased-location)
+ [Comprobación de estado](#rrsets-values-ibased-associate-with-health-check)
+ [ID de registro](#rrsets-values-ipbased-set-id)
## Política de direccionamiento
Elija **IP-based** (Basado en IP).
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no ingrese un valor (por ejemplo, un símbolo @) en el campo **Record name** (Nombre del registro).
Ingrese el mismo nombre para todos los registros en el grupo de registros basados en IP.
**Registros CNAME**
Si crea un registro con el valor **CNAME** (CNAME) para **Record type** (Tipo de registro), el nombre del registro no puede ser el mismo que el de la zona alojada.
**Caracteres especiales**
Para obtener información sobre cómo especificar caracteres distintos de a-z, 0-9 y - (guion), y cómo especificar nombres de dominio internacionalizados, consulte [Formato de nombres de dominio DNS](DomainNameFormat.md).
**Caracteres comodín**
Puede usar un asterisco (\$1) en el nombre. DNS trata el asterisco como comodín o como el carácter ASCII (42) \$1, en función de dónde aparece en el nombre. Para obtener más información, consulte [Uso de un asterisco (\$1) en nombres de zonas alojadas y registros](DomainNameFormat.md#domain-name-format-asterisk).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el valor de **Type** (Tipo) en función de cómo desee que Route 53 responda a las consultas de DNS.
Seleccione el mismo valor para todos los registros del grupo de registros basados en IP.
## TTL (segundos)
El tiempo, en segundos, en que desea que los solucionadores recursivos de DNS almacenen en caché información sobre este registro. Si especifica un valor más largo (por ejemplo, 172 800 segundos o dos días), se reduce el número de llamadas que los solucionadores recursivos de DNS deben realizar a Route 53 para obtener la información más reciente de este registro. Esto reduce la latencia y la factura del servicio Route 53. Para obtener más información, consulte [Cómo dirige Amazon Route 53 el tráfico de su dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Sin embargo, si especifica un valor más largo para TTL, los cambios realizados en el registro (por ejemplo, una nueva dirección IP) tardarán más tiempo en surtir efecto, ya que los solucionadores recursivos usan los valores de la memoria caché durante periodos más largos antes de solicitar la información más reciente a Route 53. Si está cambiando la configuración de un dominio o subdominio que ya está en uso, le recomendamos que inicialmente especifique un valor más corto, por ejemplo, 300 segundos y que aumente el valor después de confirmar que la configuración nueva es correcta.
Si asocia este registro a una comprobación de estado, es recomendable que especifique un TTL de 60 segundos o menos para que los clientes respondan rápidamente a los cambios de estado.
## Valor/ruta de destino del tráfico
Elija **IP address or another value depending on the record type (Dirección IP u otro valor en función del tipo de registro)**. Ingrese un valor que sea adecuado para el valor de **Record type** (Tipo de registro). Para todos los tipos excepto **CNAME**, puede escribir más de un valor. Escriba cada valor en una línea independiente.
Puede dirigir el tráfico a, o especificar los siguientes valores:
+ **A: dirección IPv**
+ **AAAA: dirección IPv**
+ **CAA: autorización de la entidad de certificación**
+ **CNAME: nombre canónico**
+ **MX: intercambio de correo**
+ **NAPTR: señalizador de autoridad de asignación de nombres**
+ **PTR: puntero**
+ **SPF: marco de políticas de remitente**
+ **SRV: localizador de servicios**
+ **TXT: texto**
Para más información acerca de los valores anteriores, consulte los [Valor/ruta de destino del tráfico](resource-record-sets-values-shared.md#rrsets-values-common-value) [valores comunes del valor/ruta de destino del tráfico](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Ubicación
El nombre de la ubicación CIDR donde se encuentra el recurso especificado en este registro por los valores del bloque CIDR dentro de la ubicación CIDR.
Para más información acerca del uso de los registros basados en IP, consulte [Direccionamiento basado en IP](routing-policy-ipbased.md).
## Comprobación de estado
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Va a comprobar el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica los identificadores de comprobación de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Yes** (Sí) en **Evaluate Target Health** (Evaluar el estado del destino) para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias basado en IP, alias de latencia o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name** coincide con el nombre de los registros y luego la asocia con estos, los resultados de la comprobación serán impredecibles.
## ID de registro
Ingrese un valor que identifique de manera única este registro en el grupo de registros basados en IP.
# Valores específicos para los registros de alias basados en IP
Cuando se crean registros de alias basados en IP, se especifican los siguientes valores.
**nota**
Aunque la creación de registros de alias basados en IP en una zona alojada privada está permitida, no es compatible.
Para obtener más información, consulte [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Política de direccionamiento](#rrsets-values-ipbased-alias-routing-policy)
+ [Nombre del registro](#rrsets-values-ipbased-alias-name)
+ [Tipo de registro](#rrsets-values-ipbased-alias-type)
+ [Valor/ruta de destino del tráfico](#rrsets-values-ipbased-alias-alias-target)
+ [Ubicación](#rrsets-values-ipbased-alias-location)
+ [Chequeo de salud](#rrsets-values-ipbased-alias-associate-with-health-check)
+ [Evaluate target health](#rrsets-values-ipbased-alias-evaluate-target-health)
+ [ID de registro](#rrsets-values-ipbased-alias-set-id)
## Política de direccionamiento
Elija **IP-based** (Basado en IP).
**nota**
Aunque la creación de registros de alias basados en IP en una zona alojada privada está permitida, no es compatible.
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no ingrese un valor (por ejemplo, un símbolo @) en el campo **Record name** (Nombre del registro).
Ingrese el mismo nombre para todos los registros en el grupo de registros basados en IP.
**Registros CNAME**
Si crea un registro con el valor **CNAME** (CNAME) para **Record type** (Tipo de registro), el nombre del registro no puede ser el mismo que el de la zona alojada.
**Alias para CloudFront distribuciones y buckets de Amazon S3**
El valor que especifique depende en parte del AWS recurso al que dirija el tráfico:
+ **CloudFront distribución**: la distribución debe incluir un nombre de dominio alternativo que coincida con el nombre del registro. Por ejemplo, si el nombre del registro es **acme.ejemplo.com**, la distribución de CloudFront debe incluir **acme.ejemplo.com** como uno de los nombres de dominio alternativos. Para obtener más información, consulte [Uso de nombres de dominio alternativos (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) en la *Guía para CloudFront desarrolladores de Amazon*.
+ **Bucket de Amazon S3**: el nombre del registro debe coincidir con el nombre del bucket de Amazon S3. Por ejemplo, si el nombre del bucket es **acme.ejemplo.com**, el nombre de este registro también debe ser **acme.ejemplo.com**.
Además, debe configurar el bucket para el hospedaje de sitio web. Para obtener más información, consulte [Configuración de un bucket para un alojamiento de sitio web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) en la *Guía del usuario de Amazon Simple Storage Service*.
**Caracteres especiales**
Para obtener información sobre cómo especificar caracteres distintos de a-z, 0-9 y - (guion), y cómo especificar nombres de dominio internacionalizados, consulte [Formato de nombres de dominio DNS](DomainNameFormat.md).
**Caracteres comodín**
Puede usar un asterisco (\$1) en el nombre. DNS trata el asterisco como comodín o como el carácter ASCII (42) \$1, en función de dónde aparece en el nombre. Para obtener más información, consulte [Uso de un asterisco (\$1) en nombres de zonas alojadas y registros](DomainNameFormat.md#domain-name-format-asterisk).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el valor aplicable en función del AWS recurso al que está enrutando el tráfico. Seleccione el mismo valor para todos los registros del grupo de registros basados en IP:
**API regionales personalizadas o API optimizadas para bordes de API Gateway**
Selecciona **A — IPv4 dirección**.
**Puntos de conexión de interfaz de Amazon VPC**
Seleccione **A — IPv4 dirección**.
**CloudFront distribución**
Seleccione **A — IPv4 dirección**.
Si IPv6 está habilitada para la distribución, cree dos registros, uno con el valor **A ( IPv4 dirección** para el **tipo**) y otro con el valor **AAAA ( IPv6 dirección)**.
**Servicio de App Runner**
Seleccione **A — dirección IPv4 **
**Entorno de Elastic Beanstalk con subdominios regionalizados**
Seleccione **A — IPv4 dirección**
**Balanceador de carga de ELB**
Seleccione la ** IPv4 dirección A** o la dirección **AAAA IPv6 **
**Bucket de Amazon S3**
Seleccione **A — dirección IPv4 **
**OpenSearch Servicio**
Seleccione **una IPv4 dirección** o una dirección **AAAA IPv6 **
**Otro registro en esta zona alojada**
Seleccione el tipo de registro para el que va a crear el alias. Se admiten todos los tipos, excepto **NS** y **SOA**.
Si va a crear un registro de alias con el mismo nombre que la zona alojada (lo que se conoce como *ápex de zona*), no podrá dirigir el tráfico a un registro en el que el valor de **Type (Tipo)** sea **CNAME**. Esto se debe a que el registro de alias debe tener el mismo tipo que el registro al que está redirigiendo el tráfico y no es posible crear un registro CNAME para el ápex de zona (ni siquiera para un registro de alias).
## Valor/ruta de destino del tráfico
El valor que elija de la lista o que escriba en el campo depende del AWS recurso al que dirija el tráfico.
Para obtener información sobre AWS los recursos a los que puede dirigirse, consulte [los valores comunes de los registros de alias a los que se dirige value/route el tráfico](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Para obtener más información sobre cómo configurar Route 53 para enrutar el tráfico a AWS recursos específicos, consulte[Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
## Ubicación
Cuando configure Route 53 para que responda a las consultas DNS en función de la ubicación desde la que se originan las consultas, seleccione la ubicación CIDR para la que desea que Route 53 responda con la configuración de este registro.
**importante**
Le recomendamos que cree un registro basado en la IP que tenga el valor **Default** (Predeterminado) para **Location** (Ubicación). Esto cubre las ubicaciones geográficas para las que no se hayan creado registros y las direcciones IP para las que Route 53 no puede identificar la ubicación.
No puede crear non-IP-based registros que tengan los mismos valores de **nombre** y **tipo de registro** que los registros basados en IP.
Para obtener más información, consulte [Direccionamiento basado en IP](routing-policy-ipbased.md).
## Chequeo de salud
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Yes** (Sí) en **Evaluate Target Health** (Evaluar el estado del destino) para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias basado en IP, alias de latencia o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name** coincide con el nombre de los registros y luego la asocia con estos, los resultados de la comprobación serán impredecibles.
En el caso de los registros de alias basados en IP, si un punto de conexión no está en buen estado, Route 53 busca un registro dentro de la ubicación asociada más grande. Por ejemplo, supongamos que tiene registros para un estado en Estados Unidos, para Estados Unidos, para América del Norte y para todas las ubicaciones (**Location (Ubicación)** es **Default (Predeterminada)**). Si el punto de conexión del registro de estado no está en buen estado, Route 53 verifica los registros para Estados Unidos, para América del Norte y para todas las ubicaciones, en ese orden, hasta que encuentre un registro con un punto de conexión en buen estado. Si ninguno de los registros está en buen estado, incluido el registro de todas las ubicaciones, Route 53 responde a la consulta de DNS utilizando el valor del registro de la región geográfica más pequeña.
## Evaluate target health
Seleccione **Sí**, si desea que Route 53 determine si debe responder a las consultas de DNS mediante este registro al verificar el estado del recurso especificado mediante **Punto de conexión**.
Tenga en cuenta lo siguiente:
**API Gateway personalizado, regional APIs y optimizado para entornos periféricos APIs**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es una API regional personalizada o una API optimizada para periferias de API Gateway.
**CloudFront distribuciones**
No puede establecer **Evaluar el estado del objetivo** en **Sí** cuando el punto final es una CloudFront distribución.
**Entornos de Elastic Beanstalk que tienen subdominios regionalizados**
Si especifica un entorno de Elastic Beanstalk en Endpoint y el **entorno** contiene un balanceador de carga ELB, Elastic Load Balancing direcciona las consultas únicamente a las instancias de Amazon en EC2 buen estado que estén registradas en el balanceador de carga. (Un entorno contiene automáticamente un balanceador de cargas ELB si incluye más de una EC2 instancia de Amazon). Si estableces **Evaluar el estado del objetivo** en **Sí** y ninguna EC2 instancia de Amazon está en buen estado o el propio balanceador de carga no está en buen estado, Route 53 redirige las consultas a otros recursos disponibles que estén en buen estado, si los hay.
Si el entorno contiene una sola EC2 instancia de Amazon, no hay requisitos especiales.
**Balanceadores de carga de ELB**
El comportamiento de la comprobación de estado depende del tipo de balanceador de carga:
+ **Classic Load Balancers**: si especificas un balanceador de carga clásico ELB **en** Endpoint, Elastic Load Balancing direcciona las consultas únicamente a las instancias de EC2 Amazon en buen estado que estén registradas en el balanceador de carga. Si estableces **Evaluar el estado del objetivo** en **Sí** y ninguna EC2 instancia está en buen estado o el propio balanceador de carga no está en buen estado, Route 53 redirige las consultas a otros recursos.
+ **Network Load Balancers y aplicaciones**: si especifica un Network Load Balancers o aplicaciones ELB, y establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí), Route 53 dirige consultas al balanceador de carga en función del estado de los grupos de destino asociados al balanceador de carga:
+ Para que se considere que un Application Load Balancer o un Network Load Balancer está en buen estado, cada grupo de destinos que contenga destinos debe contener al menos un destino en buen estado. Si cualquier grupo de destinos contiene únicamente destinos en mal estado, se considera que el balanceador de carga está en mal estado y Route 53 envía las consultas a otros recursos.
+ Un grupo de destinos que no tiene destinos registrados se considera que no está en buen estado.
Al crear un balanceador de carga, configura las opciones de las comprobaciones de estado de Elastic Load Balancing. Estas no son comprobaciones de estado de Route 53, pero realizan una función similar. No cree comprobaciones de estado de Route 53 para las EC2 instancias que registre en un balanceador de cargas ELB.
**Buckets de S3**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es un bucket de S3.
**Puntos de enlace de interfaz de Amazon VPC**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es uno de interfaz de Amazon VPC.
**Otros registros de la misma zona alojada**
Si el AWS recurso que especifica en **Endpoint** es un registro o un grupo de registros (por ejemplo, un grupo de registros ponderados) pero no es otro registro de alias, le recomendamos que asocie una comprobación de estado a todos los registros del punto final. Para obtener más información, consulte [¿Qué sucede cuando se omiten las comprobaciones de estado?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID de registro
Ingrese un valor que identifique de manera única este registro en el grupo de registros basados en IP.
# Valores específicos de registros de respuesta de varios valores
Cuando se crean registros de respuesta de varios valores, hay que especificar los siguientes valores.
**nota**
No se permite la creación de alias de respuesta de varios valores.
**Topics**
+ [Política de direccionamiento](#rrsets-values-multivalue-routing-policy)
+ [Nombre del registro](#rrsets-values-multivalue-name)
+ [Tipo de registro](#rrsets-values-multivalue-type)
+ [TTL (segundos)](#rrsets-values-multivalue-ttl)
+ [Valor/ruta de destino del tráfico](#rrsets-values-multivalue-value)
+ [Chequeo de salud](#rrsets-values-multivalue-associate-with-health-check)
+ [ID de registro](#rrsets-values-multivalue-set-identifier)
## Política de direccionamiento
Elija **Multivalue answer** (Respuesta con varios valores).
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no ingrese un valor (por ejemplo, un símbolo @) en el campo **Record name** (Nombre del registro).
Escriba el mismo nombre para todos los registros del grupo de registros de varios valores.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione cualquier valor excepto **NS** o **CNAME**.
Seleccione el mismo valor para todos los registros del grupo de registros de respuesta con varios valores.
## TTL (segundos)
El tiempo, en segundos, en que desea que los solucionadores recursivos de DNS almacenen en caché información sobre este registro. Si especifica un valor más largo (por ejemplo, 172 800 segundos o dos días), se reduce el número de llamadas que los solucionadores recursivos de DNS deben realizar a Route 53 para obtener la información más reciente de este registro. Esto reduce la latencia y la factura del servicio Route 53. Para obtener más información, consulte [Cómo dirige Amazon Route 53 el tráfico de su dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Sin embargo, si especifica un valor más largo para TTL, los cambios realizados en el registro (por ejemplo, una nueva dirección IP) tardarán más tiempo en surtir efecto, ya que los solucionadores recursivos usan los valores de la memoria caché durante periodos más largos antes de solicitar la información más reciente a Route 53. Si está cambiando la configuración de un dominio o subdominio que ya está en uso, le recomendamos que inicialmente especifique un valor más corto, por ejemplo, 300 segundos y que aumente el valor después de confirmar que la configuración nueva es correcta.
Si asocia este registro a una comprobación de estado, es recomendable que especifique un TTL de 60 segundos o menos para que los clientes respondan rápidamente a los cambios de estado.
**nota**
Si crea dos o más registros de respuesta con varios valores que tienen el mismo nombre y el mismo tipo, está usando la consola y especifica valores distintos para **TTL**, Route 53 cambia el valor de **TTL** de todos los registros al último valor especificado.
## Valor/ruta de destino del tráfico
Elija **IP address or another value depending on the record type (Dirección IP u otro valor en función del tipo de registro)**. Ingrese un valor que sea adecuado para el valor de **Record type** (Tipo de registro). Si escribe más de un valor, escriba cada uno en una línea independiente.
Puede dirigir el tráfico a, o especificar los siguientes valores:
+ **A — IPv4 dirección**
+ **AAAA — IPv6 dirección**
+ **CAA: autorización de la entidad de certificación**
+ **MX: intercambio de correo**
+ **NAPTR: señalizador de autoridad de asignación de nombres**
+ **PTR: puntero**
+ **SPF: marco de políticas de remitente**
+ **SRV: localizador de servicios**
+ **TXT: texto**
Para obtener más información sobre los valores anteriores, consulte [los valores comunes Value/Route del tráfico hacia](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Chequeo de salud
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Ha seleccionado **Yes** (Sí) para **Evaluate target health** (Evaluar estado del destino) para un registro de alias o para los registros de un grupo de registros de alias de conmutación por error, alias de geolocalización, alias de latencia o alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name** coincide con el nombre de los registros y luego la asocia con estos, los resultados de la comprobación serán impredecibles.
## ID de registro
Escriba un valor que identifique de manera exclusiva este registro en el grupo de registros de respuesta con varios valores.
# Valores específicos de registros ponderados
Cuando se crean registros ponderados, hay que especificar los siguientes valores.
**Topics**
+ [Política de direccionamiento](#rrsets-values-weighted-routing-policy)
+ [Nombre del registro](#rrsets-values-weighted-name)
+ [Tipo de registro](#rrsets-values-weighted-type)
+ [TTL (segundos)](#rrsets-values-weighted-ttl)
+ [Valor/ruta de destino del tráfico](#rrsets-values-weighted-value)
+ [Peso](#rrsets-values-weighted-weight)
+ [Health check](#rrsets-values-weighted-associate-with-health-check)
+ [ID de registro](#rrsets-values-weighted-set-identifier)
## Política de direccionamiento
Seleccione **Weighted (Ponderado)**.
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no ingrese un valor (por ejemplo, un símbolo @) en el campo **Record name** (Nombre del registro).
Escriba el mismo nombre para todos los registros del grupo de registros ponderados.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el mismo valor para todos los registros del grupo de registros ponderados.
## TTL (segundos)
El tiempo, en segundos, en que desea que los solucionadores recursivos de DNS almacenen en caché información sobre este registro. Si especifica un valor más largo (por ejemplo, 172 800 segundos o dos días), se reduce el número de llamadas que los solucionadores recursivos de DNS deben realizar a Route 53 para obtener la información más reciente de este registro. Esto reduce la latencia y la factura del servicio Route 53. Para obtener más información, consulte [Cómo dirige Amazon Route 53 el tráfico de su dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Sin embargo, si especifica un valor más largo para TTL, los cambios realizados en el registro (por ejemplo, una nueva dirección IP) tardarán más tiempo en surtir efecto, ya que los solucionadores recursivos usan los valores de la memoria caché durante periodos más largos antes de solicitar la información más reciente a Route 53. Si está cambiando la configuración de un dominio o subdominio que ya está en uso, le recomendamos que inicialmente especifique un valor más corto, por ejemplo, 300 segundos y que aumente el valor después de confirmar que la configuración nueva es correcta.
Si asocia este registro a una comprobación de estado, es recomendable que especifique un TTL de 60 segundos o menos para que los clientes respondan rápidamente a los cambios de estado.
Debe especificar el mismo valor de **TTL** para todos los registros de este grupo de registros ponderados.
**nota**
Si crea dos o más registros ponderados que tienen el mismo nombre y el mismo tipo, y especifica valores distintos para **TTL** (TTL), Route 53 cambia el valor de **TTL** (TTL) de todos los registros al último valor especificado.
Si un grupo de registros ponderados incluye uno o más registros de alias ponderados que dirigen tráfico a un balanceador de carga de ELB, es recomendable especificar un TTL de 60 segundos para todos los registros ponderados sin alias que tengan el mismo nombre y tipo. Los valores distintos de 60 segundos (el TTL de los equilibradores de carga) cambiarán el efecto de los valores que especifique para **Weight (Ponderación)**.
## Valor/ruta de destino del tráfico
Elija **IP address or another value depending on the record type (Dirección IP u otro valor en función del tipo de registro)**. Ingrese un valor que sea adecuado para el valor de **Record type** (Tipo de registro). Para todos los tipos excepto **CNAME**, puede escribir más de un valor. Escriba cada valor en una línea independiente.
Puede dirigir el tráfico a, o especificar los siguientes valores:
+ **A — IPv4 dirección**
+ **AAAA — IPv6 dirección**
+ **CAA: autorización de la entidad de certificación**
+ **CNAME: nombre canónico**
+ **MX: intercambio de correo**
+ **NAPTR: señalizador de autoridad de asignación de nombres**
+ **PTR: puntero**
+ **SPF: marco de políticas de remitente**
+ **SRV: localizador de servicios**
+ **TXT: texto**
Para obtener más información sobre los valores anteriores, consulte [los valores comunes Value/Route del tráfico hacia](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Peso
Un valor que determina la proporción de consultas de DNS a las que Route 53 responde usando el registro actual. Route 53 calcula la suma de las ponderaciones de los registros que tienen la misma combinación de nombre y tipo de DNS. Luego, Route 53 responde a las consultas en función de la relación entre el peso de un recurso y el total.
No puede crear registros sin ponderación que tengan los mismos valores de **Record name** (Nombre del registro) y **Record type** (Tipo de registro) que los registros ponderados.
Escriba un número entero entre 0 y 255. Para deshabilitar el direccionamiento a un recurso, establezca **Weight (Ponderación)** en 0. Si establece **Weight (Ponderación)** en 0 para todos los registros del grupo, el tráfico se dirige a todos los recursos con una probabilidad equivalente. De este modo, se asegurará de que no desactivará por error el enrutamiento de un grupo de registros ponderados.
El efecto de establecer **Weight (Ponderación)** en 0 es diferente cuando se asocian comprobaciones de estado a los registros ponderados. Para obtener más información, consulte [Cómo elige Amazon Route 53 registros cuando está configurado la comprobación de estadoCómo elige Route 53 registros cuando está configurado la comprobación de estado](health-checks-how-route-53-chooses-records.md).
## Health check
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Yes** (Sí) en **Evaluate Target Health** (Evaluar el estado del destino) para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias de latencia, alias basado en IP o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name** coincide con el nombre de los registros y luego la asocia con estos, los resultados de la comprobación serán impredecibles.
## ID de registro
Escriba un valor que identifique de manera exclusiva este registro en el grupo de registros ponderados.
# Valores específicos de registros de alias ponderados
Cuando se crean registros de alias ponderados, hay que especificar los siguientes valores. Para obtener más información, consulte [Elección entre registros de alias y sin alias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Política de direccionamiento](#rrsets-values-weighted-alias-routing-policy)
+ [Nombre del registro](#rrsets-values-weighted-alias-name)
+ [Tipo de registro](#rrsets-values-weighted-alias-type)
+ [Valor/ruta de destino del tráfico](#rrsets-values-weighted-alias-alias-target)
+ [Peso](#rrsets-values-weighted-alias-weight)
+ [Chequeo de salud](#rrsets-values-weighted-alias-associate-with-health-check)
+ [Evaluate target health](#rrsets-values-weighted-alias-evaluate-target-health)
+ [ID de registro](#rrsets-values-weighted-alias-set-identifier)
## Política de direccionamiento
Elija **Weighted** (Ponderada).
## Nombre del registro
Escriba el nombre del dominio o subdominio para el que desea dirigir el tráfico. El valor predeterminado es el nombre de la zona alojada.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no escriba un valor (por ejemplo, un símbolo @) en el campo **Name (Nombre)**.
Escriba el mismo nombre para todos los registros del grupo de registros ponderados.
Para obtener más información acerca de nombres de registro, consulte [Nombre del registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name)
## Tipo de registro
El tipo de registro de DNS. Para obtener más información, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
Seleccione el valor aplicable en función del AWS recurso al que está enrutando el tráfico:
**API regionales personalizadas o API optimizadas para bordes de API Gateway**
Selecciona **A — IPv4 dirección**.
**Puntos de conexión de interfaz de Amazon VPC**
Seleccione **A — IPv4 dirección**.
**CloudFront distribución**
Seleccione **A — IPv4 dirección**.
Si IPv6 está habilitada para la distribución, cree dos registros, uno con el valor **A ( IPv4 dirección** para el **tipo**) y otro con el valor **AAAA ( IPv6 dirección)**.
**Servicio de App Runner**
Seleccione **A — dirección IPv4 **
**Entorno de Elastic Beanstalk con subdominios regionalizados**
Seleccione **A — IPv4 dirección**
**Balanceador de carga de ELB**
Seleccione la ** IPv4 dirección A** o la dirección **AAAA IPv6 **
**Bucket de Amazon S3**
Seleccione **A — dirección IPv4 **
**OpenSearch Servicio**
Seleccione **una IPv4 dirección** o una dirección **AAAA IPv6 **
**Otro registro en esta zona alojada**
Seleccione el tipo de registro para el que va a crear el alias. Se admiten todos los tipos, excepto **NS** y **SOA**.
Si va a crear un registro de alias con el mismo nombre que la zona alojada (lo que se conoce como *ápex de zona*), no podrá dirigir el tráfico a un registro en el que el valor de **Type (Tipo)** sea **CNAME**. Esto se debe a que el registro de alias debe tener el mismo tipo que el registro al que está redirigiendo el tráfico y no es posible crear un registro CNAME para el ápex de zona (ni siquiera para un registro de alias).
Seleccione el mismo valor para todos los registros del grupo de registros ponderados.
## Valor/ruta de destino del tráfico
El valor que elija de la lista o que escriba en el campo depende del AWS recurso al que dirija el tráfico.
Para obtener información sobre AWS los recursos a los que puede dirigirse, consulte [los valores comunes de los registros de alias a los que se dirige value/route el tráfico](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Para obtener más información sobre cómo configurar Route 53 para enrutar el tráfico a AWS recursos específicos, consulte[Enrutar el tráfico de Internet a sus AWS recursos](routing-to-aws-resources.md).
## Peso
Un valor que determina la proporción de consultas de DNS a las que Route 53 responde usando el registro actual. Route 53 calcula la suma de las ponderaciones de los registros que tienen la misma combinación de nombre y tipo de DNS. Luego, Route 53 responde a las consultas en función de la relación entre el peso de un recurso y el total.
No puede crear registros sin ponderación que tengan los mismos valores de **Record name** (Nombre del registro) y **Record type** (Tipo de registro) que los registros ponderados.
Escriba un número entero entre 0 y 255. Para deshabilitar el direccionamiento a un recurso, establezca **Weight (Ponderación)** en 0. Si establece **Weight (Ponderación)** en 0 para todos los registros del grupo, el tráfico se dirige a todos los recursos con una probabilidad equivalente. De este modo, se asegurará de que no desactivará por error el enrutamiento de un grupo de registros ponderados.
El efecto de establecer **Weight (Ponderación)** en 0 es diferente cuando se asocian comprobaciones de estado a los registros ponderados. Para obtener más información, consulte [Cómo elige Amazon Route 53 registros cuando está configurado la comprobación de estadoCómo elige Route 53 registros cuando está configurado la comprobación de estado](health-checks-how-route-53-chooses-records.md).
## Chequeo de salud
Si desea que Route 53 verifique el estado de un punto de conexión dado y que solamente responda a las consultas de DNS utilizando este registro cuando el punto de conexión esté en buen estado, seleccione una comprobación de estado.
Route 53 no verifica el estado del punto de conexión especificado en el registro; por ejemplo, el punto de conexión que especifica la dirección IP en el campo **Valor**. Cuando se selecciona una comprobación de estado para un registro, Route 53 verifica el estado del punto de conexión especificado. Para obtener información sobre cómo Route 53 determina si un punto de conexión tiene un estado correcto, consulte [Cómo determina Amazon Route 53 si la comprobación de estado es correctaCómo determina Route 53 si la comprobación de estado es correcta](dns-failover-determining-health-of-endpoints.md).
La asociación de una comprobación de estado a un conjunto de registros de recursos solo es útil cuando Route 53 elige entre dos o más registros para responder a una consulta de DNS y desea que Route 53 base la elección parcialmente en el estado de la comprobación de estado. Use las comprobaciones de estado solamente en las siguientes configuraciones:
+ Está comprobando el estado de todos los registros de un grupo de registros que tienen el mismo nombre, tipo y política de enrutamiento (como los registros de conmutación por error o ponderados) y especifica la comprobación IDs de estado de todos los registros. Si en la comprobación de estado de un registro se especifica un punto de conexión que no está en buen estado, Route 53 deja de responder a las consultas mediante el valor de dicho registro.
+ Seleccione **Yes** (Sí) en **Evaluate Target Health** (Evaluar el estado del destino) para un registro de alias o los registros de un grupo de alias de conmutación por error, alias de geolocalización, alias de latencia, alias basado en IP o registro de alias ponderado. Si los registros de alias hacen referencia a registros que no son alias en la misma zona alojada, también debe especificar comprobaciones de estado para estos últimos. Si asocia una comprobación de estado a un registro de alias y también selecciona **Yes** para **Evaluate Target Health**, ambos deben evaluarse como verdaderos. Para obtener más información, consulte [¿Qué sucede cuando se asocia una comprobación de estado a un registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Si en las comprobaciones de estado se especifica el punto de conexión solo por nombre de dominio, es recomendable crear una comprobación de estado independiente para cada punto de conexión. Por ejemplo, cree una comprobación de estado para cada servidor HTTP que sirva contenido de www.ejemplo.com. Para el valor de **Domain name** (Nombre de dominio), especifique el nombre de dominio del servidor (por ejemplo, us-east-2-www.example.com), no el nombre de los registros (example.com).
**importante**
En esta configuración, si crea una comprobación de estado cuyo valor de **Domain name** coincide con el nombre de los registros y luego la asocia con estos, los resultados de la comprobación serán impredecibles.
## Evaluate target health
Seleccione **Sí**, si desea que Route 53 determine si debe responder a las consultas de DNS mediante este registro al verificar el estado del recurso especificado mediante **Punto de conexión**.
Tenga en cuenta lo siguiente:
**API Gateway personalizado, regional APIs y optimizado para entornos periféricos APIs**
No existen requisitos especiales para establecer **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) cuando el punto de conexión es una API regional personalizada o una API optimizada para bordes de API Gateway.
**CloudFront distribuciones**
No puede establecer **Evaluar el estado del objetivo** en **Sí** cuando el punto final es una CloudFront distribución.
**Entornos de Elastic Beanstalk que tienen subdominios regionalizados**
Si especifica un entorno de Elastic Beanstalk en **Punto de conexión** y el entorno contiene un equilibrador de carga de ELB, Elastic Load Balancing dirige las consultas solo a las instancias de Amazon EC2 en buen estado que están registradas en el equilibrador de carga. (Un entorno contiene automáticamente un balanceador de carga de ELB si incluye más de una instancia Amazon EC2). Si establece **Evaluate target health** (Evaluar estado del destino) en **Yes** (Sí) y no hay instancias de Amazon EC2 en buen estado, o el balanceador de carga en sí no está en buen estado, Route 53 dirige las consultas a otros recursos disponibles en buen estado, si los hay.
Si el entorno contiene una sola instancia Amazon EC2, no hay requisitos especiales.
**Balanceadores de carga de ELB**
El comportamiento de la comprobación de estado depende del tipo de balanceador de carga:
+ **Equilibradores de carga clásicos**: si especifica un equilibrador de carga clásico de ELB en **Punto de conexión**, Elastic Load Balancing dirigirá las consultas solo a las instancias de Amazon EC2 en buen estado que estén registradas con el equilibrador de carga. Si establece **Evaluate Target Health** (Evaluar estado del destino) en **Yes** (Sí) y no hay instancias de EC2 en buen estado o el balanceador de carga en sí no está en buen estado, Route 53 dirige las consultas a otros recursos.
+ **Balanceadores de carga de red y aplicaciones**: si especifica un balanceador de carga de red o aplicaciones ELB, y establece **Evaluate Target Health** (Evaluar estado del destino) en **Yes** (Sí), Route 53 dirige consultas al balanceador de carga en función del estado de los grupos de destino asociados al balanceador de carga:
+ Para que se considere que un Application Load Balancer o un Network Load Balancer está en buen estado, cada grupo de destinos que contenga destinos debe contener al menos un destino en buen estado. Si cualquier grupo de destinos contiene únicamente destinos en mal estado, se considera que el balanceador de carga está en mal estado y Route 53 envía las consultas a otros recursos.
+ Un grupo de destinos que no tiene destinos registrados se considera que no está en buen estado.
Al crear un balanceador de carga, configura las opciones de las comprobaciones de estado de Elastic Load Balancing. Estas no son comprobaciones de estado de Route 53, pero realizan una función similar. No cree comprobaciones de estado de Route 53 para las instancias de EC2 que registre en un balanceador de carga de ELB.
**Buckets de S3**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es un bucket de S3.
**Puntos de enlace de interfaz de Amazon VPC**
No existen requisitos especiales para establecer **Evaluar estado del destino** en **Sí** cuando el punto de conexión es uno de interfaz de Amazon VPC.
**Otros registros de la misma zona alojada**
Si el AWS recurso que especifica en el **punto final** es un registro o un grupo de registros (por ejemplo, un grupo de registros ponderados) pero no es otro registro de alias, le recomendamos que asocie una comprobación de estado a todos los registros del punto final. Para obtener más información, consulte [¿Qué sucede cuando se omiten las comprobaciones de estado?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID de registro
Escriba un valor que identifique de manera exclusiva este registro en el grupo de registros ponderados.
# Creación de registros mediante la importación de un archivo de zona
Si está migrando desde otro proveedor de servicios DNS, y si su proveedor de servicios DNS actual le permite exportar la configuración DNS actual a un archivo de zona, puede crear rápidamente todos los registros para una zona alojada de Amazon Route 53 importando un archivo de zona.
**nota**
Un archivo de zona utiliza un formato estándar conocido como BIND para representar registros en un formato de texto. Para obtener más información sobre el formato de un archivo de zona, consulte la página de Wikipedia [Zone file](https://en.wikipedia.org/wiki/Zone_file). Encontrará más información en [RFC 1034, Domain Names—Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) (sección 3.6.1) y en [RFC 1035, Domain Names—Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035) (sección 5).
Si desea crear registros importando un archivo de zona, tenga en cuenta lo siguiente:
+ El archivo de zona debe estar en formato compatible con RFC.
+ El nombre de dominio de los registros del archivo de zona debe coincidir con el nombre de la zona alojada.
+ Route 53 es compatible con las palabras clave `$ORIGIN` y `$TTL`. Si el archivo de zona incluye las palabras clave `$GENERATE` o `$INCLUDE`, no se podrá realizar la importación y Route 53 devuelve un error.
+ Al importar el archivo de zona, Route 53 ignora el registro de SOA del archivo de zona. Route 53 también ignora cualquier registro NS que tenga el mismo nombre que la zona alojada.
+ Puede importar un máximo de 1000 registros.
+ Si la zona alojada ya contiene registros que aparecen en el archivo de zona, se produce un error en el proceso de importación y no se crean registros.
+ En el caso de los registros TXT que contienen caracteres de barra invertida, el proceso de importación del archivo de zona interpreta determinadas secuencias de barras invertidas como caracteres de control. Para incluir caracteres de barra invertida verdaderos en los valores de los registros TXT:
+ Utilice barras invertidas dobles (`\\\\`) en el archivo de zona para representar verdaderamente una sola barra invertida en el registro TXT final.
+ Por ejemplo, si el registro TXT debe contener `\\jYTDWqH...` (una barra invertida verdadera y j), especifique `\\\\jYTDWqH...` en el archivo de zona.
Esto es especialmente importante para los registros de desafío de ACME y otros registros TXT que contienen verdaderamente caracteres de barra invertida.
+ En el caso de los registros TXT largos (como los registros DKIM), el proceso de importación de archivos de zona permite dividir el contenido en varias cadenas. Para crear registros TXT con varias cadenas:
+ Utilice líneas distintas en el archivo de zona con el mismo nombre y tipo de registro.
**Example**
```
example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC"
example.com. 300 IN TXT "7fCC6C13dM9tXuJmUBH7D4Vw8y1ByJ8z9QX2fvLm3pN4sR5tU6vW7xY8zA9bC0dE1f"
example.com. 300 IN TXT "G2hI3jK4lM5nO6pQ7rS8tU9vW0xY1zA2bC3dE4fG5hI6jK7lM8nO9pQ0rS1tU2vW3x"
```
El proceso de importación las combina automáticamente en un único registro TXT con varias cadenas. Cada cadena individual puede contener hasta 65 535 caracteres. No concatene cadenas largas en un solo valor entre comillas.
+ Le recomendamos que revise el contenido del archivo de zona para confirmar que los nombres de registro incluyen o excluyen un punto final según corresponda:
+ Cuando el nombre de un registro del archivo de zona incluye un punto final (`example.com.`), la importación lo interpreta como un nombre de dominio completo y crea un registro de Route 53 con ese nombre.
+ Si el nombre de un registro del archivo de zona no lleva un punto final (`www`), el proceso de importación lo concatena con el nombre del dominio del archivo de zona (`example.com`) y crea un registro de Route 53 con el nombre concatenado (`www.example.com`).
Si el proceso de exportación no agrega un punto final a los nombres de dominio completos de un registro, el proceso de importación de Route 53 agregará el nombre de dominio al nombre del registro. Por ejemplo, suponga que está importando registros a la zona alojada `example.com` y el nombre de un registro MX del archivo de zona es `mail.example.com`, sin punto final. El proceso de importación de Route 53 crea un registro MX denominado `mail.example.com.example.com`.
**importante**
Para los registros CNAME, MX, PTR y SRV, este comportamiento también se aplica al nombre de dominio que se incluye en el valor de RDATA. Por ejemplo, supongamos que tiene un archivo de zona para `example.com`. Si un registro CNAME del archivo de zona (`support`, sin punto final) tiene un valor de RDATA de `www.example.com` (también sin punto final), el proceso de importación crea un registro de Route 53 con el nombre `support.example.com`, que dirige el tráfico a `www.example.com.example.com`. Antes de importar su archivo de zona, revise los valores RDATA y actualícelos si es necesario. En el caso de los registros TXT que contienen barras invertidas, utilice barras invertidas dobles (`\\\\`) en el archivo de zona para representar realmente barras invertidas.
Route 53 no admite la exportación de registros a un archivo de zona.
**nota**
Si crea un registro con el mismo nombre que el de la zona alojada, no escriba un valor (por ejemplo, un símbolo @) en el campo Name (Nombre).
**Para crear registros mediante la importación de un archivo de zona**
1. Obtener un archivo de zona del proveedor de servicios DNS que administra el dominio actualmente. El proceso y la terminología varían de un proveedor de servicios a otro. Consulte la interfaz y la documentación de su proveedor para saber cómo exportar o guardar sus registros en un archivo de zona o un archivo BIND.
Si el proceso no es evidente, solicite al servicio de soporte de su proveedor de DNS actual la información sobre su *lista de recursos* o su *archivo de zona*.
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas**.
1. En la página **Zonas alojadas**, cree una zona alojada:
1. Elija **Crear zona alojada**.
1. Escriba el nombre de su dominio y, opcionalmente, un comentario.
1. Elija **Create** (Crear).
1. Elija **Import zone file** (Importar archivo de zona).
1. En el panel **Import zone file** (Importar archivo de zona), pegue el contenido de su archivo de zona en el cuadro de texto **Zone file** (Archivo de zona).
1. Seleccione **Importar**.
**nota**
En función de la cantidad de registros de su archivo de zona, es posible que tenga que esperar unos minutos hasta que se creen dichos registros.
1. Si utiliza otro servicio DNS para el dominio (algo habitual si registró el dominio con otro registrador), migre el servicio DNS a Route 53. Cuando se haya completado ese paso, el registrador comenzará a identificar Route 53 como su servicio DNS en respuesta a las consultas de DNS para su dominio, y las consultas comenzarán a enviarse a los servidores DNS de Route 53. (En general, pasan uno o dos días hasta que las consultas de DNS comienzan a dirigirse a Route 53, porque los solucionadores de DNS almacenan en su caché la información sobre su servicio DNS anterior todo ese tiempo). Para obtener más información, consulte [Establecer Amazon Route 53 como servicio DNS de un dominio existenteEstablecer Route 53 como servicio DNS de un dominio existente](MigratingDNS.md).
# Editar registros
En el siguiente procedimiento se explica cómo editar registros mediante la consola de Amazon Route 53. Para obtener información sobre cómo editar registros mediante la API de Route 53, consulte la *referencia [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)de la API de Amazon Route 53*.
**nota**
Sus cambios en los registros tardan tiempo en propagarse en los servidores DNS de Route 53. Actualmente, la única forma de comprobar que los cambios se han propagado es mediante la acción de la [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Por lo general, los cambios se propagan a todos los servidores de Route 53 en un plazo de 60 segundos.
**Edición de registros mediante la consola de Route 53**
1. Si no está editando registros de alias, vaya al paso 2.
Si va a editar registros de alias que enruten el tráfico a equilibradores de carga clásicos elásticos, equilibradores de carga de aplicación o equilibradores de carga de red, y si creó la zona alojada de Route 53 y el equilibrador de carga con cuentas diferentes, siga el procedimiento [Obtención del nombre DNS de un equilibrador de carga elástico](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure) para obtener el nombre de DNS del equilibrador de carga.
Si vas a editar los registros de alias de cualquier otro AWS recurso, continúa con el paso 2.
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Crear zona alojada**.
1. En la página **Zonas alojadas**, elija la fila de la zona alojada que contiene los registros que desea editar.
1. Seleccione la fila del registro que desea editar y, a continuación, ingrese los cambios en el panel **Edit record** (Editar registro).
1. Ingrese los valores aplicables. Para obtener más información, consulte [Valores que hay que especificar al crear o editar los registros de Amazon Route 53.](resource-record-sets-values.md).
1. Elija **Save changes (Guardar cambios)**.
1. Si está editando varios registros, repita los pasos 5 a 7.
# Eliminar registros
En el siguiente procedimiento, se explica cómo eliminar registros mediante la consola de Route 53. Para obtener información sobre cómo eliminar registros mediante la API de Route 53, consulte la *referencia [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)de la API de Amazon Route 53*.
**nota**
Sus cambios en los registros tardan tiempo en propagarse en los servidores DNS de Route 53. Actualmente, la única forma de comprobar que los cambios se han propagado es mediante la acción de la [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Por lo general, los cambios se propagan a todos los servidores de Route 53 en un plazo de 60 segundos.
**Para eliminar registros**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En la página Zonas alojadas, elija la fila de la zona alojada que contiene los registros que desea eliminar.
1. En la lista de registros, seleccione el registro que desea eliminar.
Para seleccionar varios registros consecutivos, elija la primera fila, mantenga pulsada la tecla **Mayús** y elija la última fila. Para seleccionar varios registros no consecutivos, elija la primera fila, mantenga pulsada la tecla **Ctrl** y elija las demás filas.
No puede eliminar los registros que tengan el valor **NS** o **SOA** en **Type (Tipo)**.
1. Elija **Eliminar**.
1. Elija **Delete** (Eliminar) para cerrar el cuadro de diálogo.
# Descripción de registros
En el siguiente procedimiento se explica cómo enumerar los registros de una zona alojada mediante la consola de Amazon Route 53. Para obtener información sobre cómo enumerar registros mediante la API de Route 53, consulte [ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html)la *referencia de la API de Amazon Route 53*.
**Para enumerar los registros**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Zonas alojadas**.
1. En la página **Zonas alojadas**, elija el nombre de una zona alojada nueva.
1. Para cambiar el modo de búsqueda, seleccione el ícono de engranaje en la esquina superior derecha de la tabla **Registros**. Elija una de las siguientes opciones:
+ **Automático**
Con este modo, el servicio utiliza un filtro basado en varios registros. Completo para menos de 2000 y rápido para más de 2000 registros.
+ **Completo**
Con este modo, todos los filtros de búsqueda están disponibles, pero es posible que el rendimiento de la búsqueda sea más lento.
+ **Rápido**
Con este modo, algunas características avanzadas no están disponibles, pero el rendimiento de la búsqueda será más rápido.
Para visualizar únicamente registros seleccionados, escriba los criterios de búsqueda sobre la lista de registros. En el modo automático, el comportamiento de búsqueda depende de si la zona alojada contiene hasta 2000 registros o más de 2000 registros:
**Hasta 2000 registros y modo completo**
+ Para visualizar los registros que tengan valores específicos, ingrese un valor en la barra de búsqueda y luego pulse **Entrar**. Por ejemplo, para mostrar los registros que tengan una dirección IP que empiece por **192.0**, escriba el valor en el campo **Search (Buscar)** y pulse **Enter (Intro)**.
+ Para visualizar solo los registros que tengan el mismo tipo de registro de DNS, seleccione **Record type** (Tipo de registro) en la lista desplegable e ingrese el tipo de registro.
+ Para visualizar únicamente registros de alias, seleccione **Alias** (Alias) en la lista desplegable e ingrese **Yes**.
+ Para visualizar únicamente registros ponderados, seleccione **Routing policy** (Política de direccionamiento) en la lista desplegable e ingrese **WEIGHTED**.
**Más de 2000 registros y modo rápido**
+ Puede buscar solo en los nombres de registro, no en los valores de registro. Tampoco puede filtrar en función del tipo de registro o en los registros de alias o ponderados.
Para ello, coloque el cursor en el cuadro de texto **Filtro**, seleccione **Propiedades** y, a continuación, **Nombre del registro**.
+ En el caso de los registros que tienen tres etiquetas (tres partes separadas por puntos), al escribir un valor en el campo de búsqueda y pulsar **Entrar**, la consola de Route 53 realiza automáticamente una búsqueda de comodín en la tercera etiqueta desde la derecha del nombre de registro. Por ejemplo, suponga que la zona alojada example.com contiene 100 registros denominados record1.example.com a record100.example.com. (Record1 es la tercera etiqueta desde la derecha). A continuación se indica lo que sucede cuando se busca en los siguientes valores:
+ **record1**: la consola de Route 53 busca **record1\$1.example.com** (record1\$1.example.com), que devuelve **record1.example.com** (record1.example.com), **record10.example.com** (record10.example.com) a través de **record19.example.com** (record19.example.com) y **record100.example.com** (record100.example.com).
+ **record1.example.com**: como en el ejemplo anterior, la consola busca **record1\$1.example.com** (record1\$1.example.com) y devuelve los mismos registros.
+ **1** (1): la consola busca **1\$1.example.com** (1\$1.example.com) y no devuelve ningún registro.
+ **example** (ejemplo): la consola busca **example\$1.example.com** (example\$1.example.com) y no devuelve ningún registro.
+ **example.com** (example.com): en este ejemplo, la consola no realiza una búsqueda de comodín. Devuelve todos los registros de la zona alojada.
+ **Modo de búsqueda automática**: cuando utilice este modo de búsqueda, primero debe proporcionar una propiedad, como el nombre del registro, para poder realizar la búsqueda.
**nota**
Si la tercera etiqueta desde la derecha contiene uno o varios guiones (como, por ejemplo `third-label.example.com`) y si busca la parte de la tercera etiqueta justo delante del guion (`third`, en este ejemplo), Route 53 no devolverá ningún registro. En su lugar, incluya el guion (busque `third-`) u omita el carácter que aparece justo delante de este (busque `third`).
+ En el caso de los registros que tienen cuatro o más etiquetas, debe especificar el nombre exacto del registro. No se admiten las búsquedas de comodín. Por ejemplo, si la zona alojada incluye un registro llamado label4.record1.example.com, puede encontrarlo solo si especifica **label4.record1.example.com** en el campo de búsqueda.
# Configuración de la firma de DNSSEC en Amazon Route 53
La firma de extensiones de seguridad del sistema de nombres de dominio (DNSSEC: Domain Name System Security Extensions), permite a los solucionadores de DNS validar que una respuesta DNS proviene de Amazon Route 53 y que no se ha manipulado. Cuando utiliza la firma de DNSSEC, cada respuesta para una zona alojada se firma utilizando criptografía de clave pública. Para obtener información general sobre DNSSEC, consulte la sección DNSSEC de [AWS re:Invent 2021 - Amazon Route 53: A year in review](https://www.youtube.com/watch?v=77V23phAaAE).
En este capítulo, explicamos cómo habilitar la firma de DNSSEC para Route 53, cómo trabajar con las claves de firma de claves (KSKs) y cómo solucionar problemas. Puede trabajar con la firma de DNSSEC en la API o mediante programación con ella. Consola de administración de AWS Para obtener más información sobre el uso de la CLI o SDKs el trabajo con Route 53, consulte[Configuración de Amazon Route 53](setting-up-route-53.md).
Antes de habilitar la firma de DNSSEC, tenga en cuenta lo siguiente:
+ Para ayudar a evitar una interrupción de la zona y problemas de que el dominio deje de estar disponible, debe abordar y resolver rápidamente los errores de DNSSEC. Le recomendamos encarecidamente que configure una CloudWatch alarma que le avise cada vez que se detecte un `DNSSECKeySigningKeysNeedingAction` error `DNSSECInternalFailure` o error. Para obtener más información, consulte [Supervisión de zonas alojadas mediante Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
+ En las DNSSEC hay dos tipos de claves: la clave de firma de claves (KSK) y la clave de firma de zonas (ZSK). En la firma de DNSSEC de Route 53, cada KSK se basa en una [clave asimétrica administrada por el cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept) en AWS KMS que posea. Usted es responsable de la administración de la KSK, lo que incluye su rotación, en caso de que sea necesario. Route 53 lleva a cabo la administración de ZSK.
+ Cuando habilita la firma de DNSSEC para una zona alojada, Route 53 limita el TTL a una semana. Si establece un TTL de más de una semana para los registros de la zona alojada, no aparece ningún error. No obstante, Route 53 impone un TTL de una semana para los registros. Los registros que tienen un TTL de menos de una semana y los registros en otras zonas alojadas que no tienen habilitadas la firma DNSSEC no se ven afectados.
+ Cuando utiliza la firma de DNSSEC, no se admiten configuraciones de varios proveedores. Si ha configurado servidores de nombres de etiqueta blanca (también conocidos como servidores de nombres personalizados o de nombres privados), asegúrese de que estos los proporcione un único proveedor de DNS.
+ Algunos proveedores de DNS no admiten registros de firmantes de delegación (DS) en su DNS autoritativo. Si su zona principal está alojada en un proveedor de DNS que no admite consultas de DS (no establece un indicador AA en la respuesta a la consulta de DS), cuando habilite DNSSEC en su zona secundaria, esta no se podrá resolver. Asegúrese de que su proveedor de DNS admita los registros de DS.
+ Puede ser útil configurar permisos de IAM para permitir que otro usuario, además del propietario de la zona, agregue o elimine registros en la zona. Por ejemplo, un propietario de zona puede agregar una KSK y habilitar la firma y también puede ser responsable de la rotación de claves. No obstante, otra persona podría ser responsable de trabajar con otros registros para la zona alojada. Para ver una política de IAM de ejemplo, consulte [Permisos de ejemplo para el propietario de un registro de dominio](access-control-managing-permissions.md#example-permissions-record-owner).
+ Para comprobar si el TLD es compatible con DNSSEC, consulte [Dominios que puede registrar con Amazon Route 53](registrar-tld-list.md).
**Topics**
+ [Activar la firma de DNSSEC y establecer una cadena de confianza](dns-configuring-dnssec-enable-signing.md)
+ [Desactivar la firma de DNSSEC](dns-configuring-dnssec-disable.md)
+ [Trabajar con claves administradas por el cliente para DNSSEC](dns-configuring-dnssec-cmk-requirements.md)
+ [Trabajar con claves de firma de claves () KSKs](dns-configuring-dnssec-ksk.md)
+ [Administración de claves KMS y ZSK en Route 53](dns-configuring-dnssec-zsk-management.md)
+ [Pruebas de inexistencia de DNSSEC en Route 53](dns-configuring-dnssec-proof-of-nonexistence.md)
+ [Solución de problemas de firma de DNSSEC](dns-configuring-dnssec-troubleshoot.md)
# Activar la firma de DNSSEC y establecer una cadena de confianza
****
Los pasos progresivos se aplican al propietario de la zona alojada y al encargado de la zona principal. Puede ser la misma persona, pero si no, el propietario de la zona debe notificar y trabajar con el responsable de la zona principal.
Recomendamos seguir los pasos de este artículo para que su zona se firme e incluya en la cadena de confianza. Los siguientes pasos minimizarán el riesgo de incorporación a DNSSEC.
**nota**
Asegúrese de leer los requisitos previos antes de comenzar en [Configuración de la firma de DNSSEC en Amazon Route 53](dns-configuring-dnssec.md).
Hay tres pasos que deben realizar para habilitar la firma de DNSSEC, que se describe en las secciones siguientes.
**Topics**
+ [Paso 1: Preparación para activar la firma de DNSSEC](#dns-configuring-dnssec-enable-signing-step-1)
+ [Paso 2: Habilitar la firma DNSSEC y crear un KSK](#dns-configuring-dnssec-enable)
+ [Paso 3: Establecer una cadena de confianza](#dns-configuring-dnssec-chain-of-trust)
## Paso 1: Preparación para activar la firma de DNSSEC
Los pasos de preparación ayudan a minimizar el riesgo de incorporación a DNSSEC mediante la supervisión de la disponibilidad de la zona y la reducción de los tiempos de espera entre activar la firma y la inserción del registro firmante de delegación (DS).
**Para prepararse para activar la firma DNSSEC**
1. Supervisar la disponibilidad de zonas.
Puede supervisar la zona para comprobar la disponibilidad de sus nombres de dominio. Esto puede ayudarle a solucionar cualquier problema que pueda justificar retroceder un paso atrás después de habilitar la firma DNSSEC. Puede supervisar los nombres de dominio con la mayor parte del tráfico mediante el registro de consultas. Para obtener más información sobre la configuración del registro de consultas, consulte [Monitoreo de Amazon Route 53](monitoring-overview.md).
La supervisión se puede realizar a través de un script de shell o mediante un servicio de terceros. Sin embargo, no debería ser la única señal para determinar si se requiere una reversión. Es posible que también reciba comentarios de sus clientes debido a que un dominio no está disponible.
1. Reduzca el TTL máximo de la zona.
El TTL máximo de la zona es el registro TTL más largo de la zona. En la siguiente zona de ejemplo, el TTL máximo de la zona es de 1 día (86 400 segundos).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)
La reducción del TTL máximo de la zona ayudará a reducir el tiempo de espera entre activar la firma y la inserción del registro firmante de delegación (DS). Recomendamos reducir el TTL máximo de la zona a 1 hora (3600 segundos). Esto le permite retroceder después de solo una hora si algún solucionador tiene problemas para almacenar en caché los registros firmados.
**Reversión:** deshacer los cambios TTL.
1. Reduzca el campo mínimo de SOA TTL y de SOA.
El campo mínimo de SOA es el último campo de los datos de registro SOA. En el siguiente registro SOA de ejemplo, el campo mínimo tiene el valor de 5 minutos (300 segundos).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)
El campo mínimo de SOA TTL y de SOA determina cuánto tiempo los solucionadores recuerdan las respuestas negativas. Después de habilitar la firma, los servidores de nombres de Route 53 empiezan a devolver registros NSEC para obtener respuestas negativas. El NSEC contiene información que los solucionadores pueden utilizar para sintetizar una respuesta negativa. Si tiene que retroceder porque la información de NSEC provocó que un solucionador asuma una respuesta negativa para un nombre, solo tendrá que esperar el máximo del campo mínimo TTL de SOA y de SOA para que el solucionador filtre las palabras irrelevantes.
**Reversión:** deshacer los cambios de SOA.
1. Asegúrese de que los cambios mínimos de campo TTL y de SOA sean efectivos.
Úselo [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)para asegurarse de que los cambios realizados hasta ahora se hayan propagado a todos los servidores DNS de Route 53.
## Paso 2: Habilitar la firma DNSSEC y crear un KSK
Puede habilitar la firma de DNSSEC y crear una clave de firma de claves (KSK) mediante la consola de Route 53 AWS CLI o en ella.
+ [CLI](#dnssec_CLI)
+ [Consola](#dnssec_console)
Cuando proporciona o crea una clave de KMS, existen varios requisitos. Para obtener más información, consulte [Trabajar con claves administradas por el cliente para DNSSEC](dns-configuring-dnssec-cmk-requirements.md).
------
#### [ CLI ]
Puede utilizar una clave que ya tenga o crear una ejecutando un AWS CLI comando como el siguiente utilizando sus propios valores para `hostedzone_id`, `cmk_arn`, `ksk_name`, y `unique_string` (para que la solicitud sea única):
```
aws --region us-east-1 route53 create-key-signing-key \
--hosted-zone-id $hostedzone_id \
--key-management-service-arn $cmk_arn --name $ksk_name \
--status ACTIVE \
--caller-reference $unique_string
```
Para obtener más información sobre las claves administradas por el cliente, consulte [Trabajar con claves administradas por el cliente para DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Véase también [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html).
Para habilitar la firma de DNSSEC, ejecute un AWS CLI comando como el siguiente, utilizando su propio valor para: `hostedzone_id`
```
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
```
[Para obtener más información, consulte [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html)y EnableHostedZone DNSSEC.](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)
------
#### [ Console ]
**Para habilitar la firma de DNSSEC y crear una KSK**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. En el panel de navegación, elija **Hosted zones** (Zonas alojadas) y elija una zona alojada para la que desea habilitar la firma de DNSSEC.
1. En la página **DNSSEC**, elija **Enable DNSSEC signing** (Habilitar firma de DNSSEC).
**nota**
Si la opción de esta sección es **Disable DNSSEC signing** (Desactivar la firma DNSSEC), ya ha completado el primer paso para activar la firma de DNSSEC. Para terminar, asegúrese de establecer, o de que ya exista, una cadena de confianza para la zona alojada para DNSSEC. Para obtener más información, consulte [Paso 3: Establecer una cadena de confianza](#dns-configuring-dnssec-chain-of-trust).
1. En la sección **Key-signing key (KSK) creation** (Creación de clave de la firma de clave), elija **Provide KSK name** (Crear nuevo KSK) y en **Provide KSK name** (Proporcione el nombre de KSK), ingrese un nombre para el KSK que Route 53 creará para usted. Los nombres pueden contener letras, números y guiones bajos (\$1). Deben ser únicos.
1. En **Customer managed CMK** (CMK administrada por el cliente), elija la clave administrada por el cliente que debe utilizar Route 53 al crear la KSK por usted. Puede usar una clave administrada por el cliente aplicada a la firma de DNSSEC o crear una nueva clave administrada por el cliente.
Cuando proporciona o crea una clave administrada por el cliente, existen varios requisitos. Para obtener más información, consulte [Trabajar con claves administradas por el cliente para DNSSEC](dns-configuring-dnssec-cmk-requirements.md).
1. Ingrese el alias de una clave administrada por el cliente existente. Si desea utilizar una nueva clave administrada por el cliente, ingrese un alias para una clave administrada por el cliente y Route 53 creará una para usted.
**nota**
Si elige que Route 53 cree una clave administrada por el cliente, tenga en cuenta que se aplican cargos aparte por cada clave administrada por el cliente. Para obtener más información, consulte [Precios de AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
1. Elija **Enable DNSSEC signing** (Habilitar firma de DNSSEC).
------
**Después de habilitar la firma de zona, complete los pasos siguientes** (si ha utilizado la consola o la CLI):
1. Asegúrese de que la firma de zona sea efectiva.
Si la usó AWS CLI, puede usar el identificador de operación que aparece en el resultado de la `EnableHostedZoneDNSSEC()` llamada para ejecutar [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) o [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)para asegurarse de que todos los servidores DNS de Route 53 firmen las respuestas (status =`INSYNC`).
1. Espere al menos el TTL máximo de la zona anterior.
Espere a que los solucionadores eliminen todos los registros sin firmar de su caché. Para lograrlo, debe esperar al menos el TTL máximo de la zona anterior. En la zona `example.com` anterior, el tiempo de espera sería de 1 día.
1. Supervisar los informes de problemas de los clientes.
Una vez habilitada la firma de zona, es posible que sus clientes empiecen a ver problemas relacionados con los dispositivos de red y los solucionadores. El período de supervisión recomendado es de 2 semanas.
A continuación, se muestra un ejemplo de cómo podría hacerlo:
+ Algunos dispositivos de red pueden limitar el tamaño de la respuesta DNS a menos de 512 bytes, lo que es demasiado pequeño para algunas respuestas firmadas. Estos dispositivos de red deben reconfigurarse para permitir tamaños de respuesta DNS más grandes.
+ Algunos dispositivos de red realizan una inspección profunda de las respuestas DNS y eliminan ciertos registros que no entienden, como los utilizados para DNSSEC. Estos dispositivos deben volver a configurarse.
+ Los solucionadores de algunos clientes afirman que pueden aceptar una respuesta UDP mayor que la que admite su red. Puede probar la capacidad de red y configurar los solucionadores de forma adecuada. Para obtener más información, consulte [Servidor de prueba de tamaño de respuesta DNS](https://www.dns-oarc.net/oarc/services/replysizetest/).
**Reversión:** llame a [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) y, a continuación, revierta los pasos anteriores. [Paso 1: Preparación para activar la firma de DNSSEC](#dns-configuring-dnssec-enable-signing-step-1)
## Paso 3: Establecer una cadena de confianza
Tras habilitar la firma de DNSSEC para una zona alojada en Route 53, establezca una cadena de confianza para esa zona alojada para completar la configuración de firma de DNSSEC. Para ello, cree un registro de Delegation Signer (DS) en la zona alojada *principal* para su zona alojada utilizando la información que proporciona Route 53. En función de dónde esté registrado su dominio, agregue el registro a la zona alojada principal en Route 53 o en otro registrador de dominios.
**Para establecer una cadena de confianza para la firma de DNSSEC**
1. Inicie sesión en la consola de Route Consola de administración de AWS 53 y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. En el panel de navegación, elija **Hosted zones** (Zonas alojadas) y elija una zona alojada para la que desea establecer la cadena de confianza de DNSSEC. *Debe habilitar primero la firma de DNSSEC.*
1. En la pestaña **DNSSEC signing** (Firma de DNSSEC), en **DNSSEC signing** (Firma de DNSSEC), elija **View information to create DS record** (Ver información para crear un registro de DS).
**nota**
Si no ve **View information to create DS record** (Ver información para crear un registro DS) en esta sección, debe habilitar la firma de DNSSEC antes de establecer la cadena de confianza. Elija **Enable DNSSEC signing** (Habilitar firma de DNSSEC) y complete los pasos descritos en [Paso 2: Habilitar la firma DNSSEC y crear un KSK](#dns-configuring-dnssec-enable), y a continuación, vuelva a estos pasos para establecer la cadena de confianza.
1. En **Establish a chain of trust** (Establecer una cadena de confianza), elija **Route 53 registrar** (Registrador Route 53) o **Another domain registrar** (Otro registrador de dominios), en función de dónde esté registrado su dominio.
1. Utilice los valores proporcionados desde el paso 3 para crear un registro DS para la zona alojada principal en Route 53. Si su dominio no está alojado en Route 53, utilice los valores proporcionados para crear un registro DS en el sitio web del registrador de dominios.
Cómo establecer una cadena de confianza para la zona principal:
+ Si el dominio se administra a través de Route 53, siga estos pasos:
Asegúrese de configurar el algoritmo de firma (ECDSAP256SHA256 y escriba 13) y el algoritmo de resumen (SHA-256 y tipo 2) correctos.
Si Route 53 es su registrador, haga lo siguiente en la consola de Route 53:
1. Tenga en cuenta los valores **Key type** (Tipo de clave), **Signing algorithm** (Algoritmo de firma) y**Public key** (Clave pública). En el panel de navegación, elija **Registered domains**.
1. Seleccione un dominio y, a continuación, en la pestaña de **claves de DNSSEC**, elija **Agregar clave**.
1. En el cuadro de diálogo **Administrar claves de DNSSEC**, elija el **Tipo de clave** y el **Algoritmo** correctos para el **Registrador de Route 53** en los menús desplegables.
1. Copie la **Public key** (Clave pública) para el registrador de Route 53. En el diálogo **Manage DNSSEC keys** (Administrar claves de DNSSEC), pegue el valor en el cuadro **Public key** (Clave pública).
1. Elija **Añadir**.
Route 53 agregará el registro de DS a la zona principal desde la clave pública. Por ejemplo, si su dominio es `example.com`, el registro de DS se agrega a la zona DNS .com.
+ Si el dominio se administra en otro registro, siga las instrucciones de la sección **Otro registrador de dominio**.
Para asegurarse de que los siguientes pasos se realizan sin problemas, introduzca un TTL DS bajo en la zona principal. Recomendamos configurar el TTL DS en 5 minutos (300 segundos) para una recuperación más rápida si necesita retroceder los cambios.
+ Cómo establecer una cadena de confianza para la zona secundaria:
Si su zona principal está administrada por otro registro, contacte con el registrador para introducir el registro DS de su zona. Normalmente no podrá ajustar el TTL del registro DS.
+ Si su zona principal está alojada en Route 53, póngase en contacto con el propietario de la zona principal para introducir el registro DS de su zona.
Proporcione la `$ds_record_value` al propietario de la zona principal. Puede obtenerlo haciendo clic en **Ver información para crear un registro DS** en la consola y copiando el campo de **registro DS**, o llamando a la API [GetDNSSec](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) y recuperando el valor del campo '': DSRecord
```
aws --region us-east-1 route53 get-dnssec
--hosted-zone-id $hostedzone_id
```
El propietario de la zona principal puede insertar el registro a través de la consola de Route 53 o la CLI.
+ Para insertar el registro DS mediante el uso AWS CLI, el propietario de la zona principal crea y asigna un nombre a un archivo JSON similar al siguiente ejemplo. El propietario de la zona principal podría nombrar al archivo algo así como `inserting_ds.json`.
```
{
"HostedZoneId": "$parent_zone_id",
"ChangeBatch": {
"Comment": "Inserting DS for zone $zone_name",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "$zone_name",
"Type": "DS",
"TTL": 300,
"ResourceRecords": [
{
"Value": "$ds_record_value"
}
]
}
}
]
}
}
```
A continuación, ejecute el siguiente comando:
```
aws --region us-east-1 route53 change-resource-record-sets
--cli-input-json file://inserting_ds.json
```
+ Para insertar el registro DS mediante la consola,
Abra la consola de Route 53 en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
En el panel de navegación, elija **Hosted zones** (Zonas alojadas), el nombre de la zona alojada y luego el botón **Create record** (Crear registro). Asegúrese de elegir el Enrutamiento sencillo para la **Routing policy** (Política de enrutamiento).
En el campo **Nombre del registro**, ingrese el mismo nombre que el `$zone_name`, seleccione DS en el menú desplegable **Tipo de registro**, ingrese el valor de `$ds_record_value` en el campo **Valor** y seleccione **Crear registros**.
**Reversión:** elimine el DS de la zona principal, espere el TTL DS y, a continuación, revierta los pasos para establecer la confianza. Si la zona principal está alojada en Route 53, el propietario de la zona principal puede cambiar la `Action` desde `UPSERT` a `DELETE` en el archivo JSON y vuelva a ejecutar la CLI de ejemplo anterior.
1. Espere a que las actualizaciones se propaguen, en función del TTL para los registros de dominio.
Si la zona principal está en el servicio DNS de Route 53, el propietario de la zona principal puede confirmar la propagación completa a través de la [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API.
De lo contrario, puede sondear periódicamente la zona principal del registro DS y esperar otros 10 minutos después para aumentar la probabilidad de que la inserción del registro DS se propague por completo. Tenga en cuenta que algunos registradores han programado la inserción de DS, por ejemplo, una vez al día.
Cuando introduzca el registro Delegation Signer (DS) en la zona principal, los solucionadores validados que han recogido el DS comenzarán a validar las respuestas de la zona.
Para asegurarse de que los pasos para establecer la confianza se desarrollen sin problemas, complete lo siguiente:
1. Busque el TTL NS máximo.
Hay 2 conjuntos de registros NS asociados a sus zonas:
+ El registro NS de la delegación: es el registro NS de su zona mantenida por la zona principal. Puede encontrarlo ejecutando los siguientes comandos Unix (si su zona es ejemplo.com, la zona principal es com):
`dig -t NS com`
Elija uno de los registros NS y, a continuación, ejecute lo siguiente:
`dig @one of the NS records of your parent zone -t NS example.com`
Por ejemplo:
`dig @b.gtld-servers.net. -t NS example.com`
+ El registro NS de la zona: es el registro NS de su zona. Puede encontrarlo ejecutando el siguiente comando Unix:
`dig @one of the NS records of your zone -t NS example.com`
Por ejemplo:
`dig @ns-0000.awsdns-00.co.uk. -t NS example.com`
Tenga en cuenta el TTL máximo para ambas zonas.
1. Espere el TTL NS máximo.
Antes de la inserción de DS, los solucionadores reciben una respuesta firmada, pero no están validando la firma. Cuando se inserta el registro DS, los solucionadores no lo verán hasta que caduque el registro NS de la zona. Cuando los solucionadores recuperen el registro NS, también se devolverá el registro DS.
Si su cliente ejecuta un solucionador en un host con un reloj dessincronizado, asegúrese de que el reloj esté dentro de 1 hora desde la hora correcta.
Tras completar este paso, todos los solucionadores compatibles con DNSSEC validarán su zona.
1. Observe la resolución de nombres.
Debería observar que no hay problemas con los solucionadores que validan su zona. Asegúrese también de tener en cuenta el tiempo necesario para que sus clientes le informen de los problemas.
Recomendamos supervisar hasta 2 semanas.
1. (Opcional) Alargue el DS y el NS. TTLs
Si está satisfecho con la configuración, puede guardar los cambios de TTL y SOA realizados. Tenga en cuenta que Route 53 limita el TTL a 1 semana para las zonas firmadas. Para obtener más información, consulte [Configuración de la firma de DNSSEC en Amazon Route 53](dns-configuring-dnssec.md).
Si puede cambiar el TTL DS, le recomendamos que lo configure en 1 hora.
# Desactivar la firma de DNSSEC
Los pasos para desactivar la firma DNSSEC en Route 53 varían en función de la cadena de confianza de la que forma parte la zona alojada.
Por ejemplo, la zona alojada puede tener una zona principal que tenga un registro de Delegation Signer (DS) como parte de una cadena de confianza. Su zona alojada también puede ser una zona principal para zonas secundarias que han habilitado la firma de DNSSEC, que es otra parte de la cadena de confianza. Investigue y determine la cadena de confianza completa para su zona alojada antes de realizar los pasos necesarios para desactivar la firma de DNSSEC.
La cadena de confianza de la zona alojada que habilita la firma de DNSSEC se debe deshacer cuidadosamente a medida que desactiva la firma. Para eliminar la zona alojada de la cadena de confianza, elimine todos los registros de DS que haya en la cadena de confianza que incluye esta zona alojada. Debe hacer lo siguiente, en orden:
1. Elimine todos los registros de DS que esta zona alojada tenga para las zonas secundarias que forman parte de una cadena de confianza.
1. Elimine el registro de DS desde la zona principal. Si tiene una isla de confianza (no hay registros de DS en la zona principal ni registros de DS para zonas secundarias en esta zona), puede omitir este paso.
1. Si no puede eliminar los registros de DS, para eliminar la zona de la cadena de confianza, elimine los registros de NS de la zona principal. Para obtener más información, consulte [Adición o modificación de servidores de nombres y registros de conexión de un dominio](domain-name-servers-glue-records.md).
Los siguientes pasos progresivos le permiten supervisar la eficacia de los pasos individuales para evitar problemas de disponibilidad de DNS en su zona.
**Para desactivar la firma de DNSSEC**
1. Supervisar la disponibilidad de zonas.
Puede supervisar la zona para comprobar la disponibilidad de sus nombres de dominio. Esto puede ayudarle a solucionar cualquier problema que pueda justificar retroceder un paso atrás después de habilitar la firma DNSSEC. Puede supervisar los nombres de dominio con la mayor parte del tráfico mediante el registro de consultas. Para obtener más información sobre la configuración del registro de consultas, consulte [Monitoreo de Amazon Route 53](monitoring-overview.md).
La supervisión se puede realizar a través de un script de shell o mediante un servicio de pago. Sin embargo, no debería ser la única señal para determinar si se requiere una reversión. Es posible que también reciba comentarios de sus clientes debido a que un dominio no está disponible.
1. Busque el DS TTL actual.
Puede encontrar el TTL DS ejecutando el siguiente comando Unix:
`dig -t DS example.com example.com`
1. Busque el TTL NS máximo.
Hay 2 conjuntos de registros NS asociados a sus zonas:
+ El registro NS de la delegación: es el registro NS de su zona mantenida por la zona principal. Puede encontrarlo ejecutando los siguientes comandos de Unix:
Busque primero el NS de su zona principal (si su zona es ejemplo.com, la zona principal es com):
`dig -t NS com`
Elija uno de los registros NS y, a continuación, ejecute lo siguiente:
`dig @one of the NS records of your parent zone -t NS example.com`
Por ejemplo:
`dig @b.gtld-servers.net. -t NS example.com`
+ El registro NS de la zona: es el registro NS de su zona. Puede encontrarlo ejecutando el siguiente comando Unix:
`dig @one of the NS records of your zone -t NS example.com`
Por ejemplo:
`dig @ns-0000.awsdns-00.co.uk. -t NS example.com`
Tenga en cuenta el TTL máximo para ambas zonas.
1. Elimine el registro de DS desde la zona principal.
Póngase en contacto con el propietario de la zona principal para eliminar el registro DS.
**Reversión:** vuelva a insertar el registro de DS, confirme que la inserción de DS es efectiva y espere al TTL NS (no DS) máximo antes de que todos los Resolvers comiencen a validar de nuevo.
1. Confirme que la eliminación del DS es efectiva.
Si la zona principal está en el servicio DNS de Route 53, el propietario de la zona principal puede confirmar la propagación completa a través de la [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API.
De lo contrario, puede sondear periódicamente la zona principal del registro DS y esperar otros 10 minutos después para aumentar la probabilidad de que la eliminación del registro DS se propague por completo. Tenga en cuenta que algunos registradores han programado la retirada del DS, por ejemplo, una vez al día.
1. Espere al TTL DS.
Espere a que todos los solucionadores hayan caducado el registro DS de sus cachés.
1. Desactive la firma de DNSSEC y la clave de firma de clave (KSK).
+ [CLI](#CLI_dnssec_disable)
+ [Consola](#console_dnssec_disable)
------
#### [ CLI ]
Llame a [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) y. [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) APIs
Por ejemplo:
```
aws --region us-east-1 route53 disable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
aws --region us-east-1 route53 deactivate-key-signing-key \
--hosted-zone-id $hostedzone_id --name $ksk_name
```
------
#### [ Console ]
**Para desactivar la firma de DNSSEC**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. En el panel de navegación, elija **Hosted zones** (Zonas alojadas) y elija una zona alojada para la que desea desactivar la firma de DNSSEC.
1. En la página **DNSSEC**, elija **Disable DNSSEC signing** (Desactivar firma de DNSSEC).
1. En la página **Disable DNSSEC signing** (Desactivar firma de DNSSEC), elija una de las siguientes opciones, según el escenario de la zona cuya firma de DNSSEC esté desactivando.
+ **Parent zone only** (Solo la zona principal) — Esta zona tiene una zona principal con un registro de DS. En este escenario, debe eliminar el registro de DS de la zona principal.
+ **Child zones only** (Solo las zonas secundarias) — Esta zona tiene un registro de DS para una cadena de confianza con una o más zonas secundarias. En este escenario, debe eliminar los registros de DS de la zona.
+ **Parent and child zones** (Zonas principales y secundarias) — Esta zona tiene un registro de DS para una cadena de confianza con una o más zonas secundarias *y* una zona principal con un registro de DS. En este escenario, haga lo siguiente en orden:
1. Elimine los registros de DS de la zona.
1. Elimine el registro de DS de la zona principal.
Si tiene una isla de confianza, puede omitir este paso.
1. Determine cuál es el TTL para cada registro de DS que elimine en el paso 4. Asegúrese de que el periodo TTL más largo haya caducado.
1. Seleccione la casilla de verificación para confirmar que ha seguido los pasos en orden.
1. Escriba *disable* (desactivar) en el campo, como se muestra, y elija **Disable** (Desactivar).
**Para desactivar la clave de firma de claves (KSK)**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Hosted zones** (Zonas alojadas) y elija una zona alojada para la que desea desactivar la clave de firma de calves (KSK).
1. **En la sección **Claves de firma de claves (KSKs)**, elige el KSK que quieres desactivar y, en **Acciones**, elige **Editar KSK, establece el estado del KSK** **como **Inactivo** y, a continuación, selecciona Guardar KSK**.**
------
**[ActivateKeySigningKeyEnableHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)[ APIsReversión](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)**: llamada y DNSSEC.
Por ejemplo:
```
aws --region us-east-1 route53 activate-key-signing-key \
--hosted-zone-id $hostedzone_id --name $ksk_name
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
```
1. Confirme que la desactivación de la firma de zona es efectiva.
Use el identificador de la `EnableHostedZoneDNSSEC()` llamada [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)para ejecutar y asegurarse de que todos los servidores DNS de Route 53 hayan dejado de firmar las respuestas (status =). `INSYNC`
1. Observe la resolución de nombres.
Debe observar que no hay problemas que provoquen que los solucionadores validen su zona. Deje pasar entre 1 y 2 semanas para tener en cuenta el tiempo necesario para que sus clientes le comuniquen los problemas.
1. (Opcional) Limpieza.
Si no va a volver a habilitar la firma, puede limpiar [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)y eliminar la clave gestionada KSKs por el cliente correspondiente para ahorrar costes.
# Trabajar con claves administradas por el cliente para DNSSEC
Al habilitar la firma de DNSSEC en Amazon Route 53, este servicio crea una clave de firma de claves (KSK) por usted. Para crear una KSK, Route 53 debe usar una clave administrada por el cliente AWS Key Management Service que sea compatible con DNSSEC. En esta sección, se describen los detalles y los requisitos de la clave administrada por el cliente que resultan de utilidad al trabajar con DNSSEC.
Tenga en cuenta lo siguiente cuando trabaje con claves administradas por el cliente para DNSSEC:
+ La clave administrada por el cliente que utiliza con la firma de DNSSEC debe estar en la región EE. UU. Este (Norte de Virginia).
+ La clave administrada por el cliente debe ser una [clave asimétrica administrada por el cliente](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks) con una [especificación de clave ECC\$1NIST\$1P256](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc). Estas claves administradas por el cliente se utilizan únicamente para firmar y verificar. Para obtener ayuda para crear una clave administrada por el cliente asimétrica, consulte [Creación de claves asimétricas administradas por el cliente en la Guía para](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) desarrolladores. AWS Key Management Service Para obtener ayuda para encontrar la configuración criptográfica de una clave gestionada por el cliente existente, consulte [Visualización de la configuración criptográfica de las claves gestionadas por el cliente](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html) en la Guía para desarrolladores. AWS Key Management Service
+ Si crea una clave administrada por el cliente para usarla con DNSSEC en Route 53, debe incluir instrucciones de política de claves específicas que otorguen a Route 53 los permisos necesarios. Route 53 debe poder acceder a la clave administrada por el cliente a fin de que pueda crear la KSK automáticamente. Para obtener más información, consulte [Permisos de clave administrados por el cliente de Route 53 necesarios para firmar DNSSEC](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC).
+ Route 53 puede crear una clave administrada por el cliente AWS KMS para utilizarla con la firma de DNSSEC sin permisos adicionales. AWS KMS No obstante, debe tener permisos específicos si desea editar la clave después de crearla. Los permisos específicos que debe tener son los siguientes: `kms:UpdateKeyDescription`, `kms:UpdateAlias`, y `kms:PutKeyPolicy`.
+ Tenga en cuenta que se aplican cargos aparte por cada clave administrada por el cliente que tenga, independientemente de que usted cree la clave administrada por el cliente o sea Route 53 quien la cree por usted. Para obtener más información, consulte [Precios de AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
# Trabajar con claves de firma de claves () KSKs
Cuando se habilita la firma de DNSSEC, Route 53 crea una clave de firma de claves (KSK) por usted. Puede tener hasta dos KSKs por zona alojada en Route 53. Después de habilitar la firma de DNSSEC, puede agregar, eliminar o editar su. KSKs
Tenga en cuenta lo siguiente cuando trabaje con su: KSKs
+ Antes de poder eliminar una KSK, debe editarla para establecer su estado en **Inactive** (Inactivo).
+ Al habilitar la firma de DNSSEC para una zona alojada, Route 53 limita el TTL a una semana. Si establece un TTL para los registros en la zona alojada en de más de una semana, no aparece ningún error, pero Route 53 aplica un TTL obligatorio de una semana.
+ Para ayudar a evitar una interrupción de la zona y problemas de que el dominio deje de estar disponible, debe abordar y resolver rápidamente los errores de DNSSEC. Le recomendamos encarecidamente que configure una CloudWatch alarma que le avise cada vez que se detecte un `DNSSECKeySigningKeysNeedingAction` error `DNSSECInternalFailure` o error. Para obtener más información, consulte [Supervisión de zonas alojadas mediante Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
+ Las operaciones de KSK descritas en esta sección le permiten rotar las de KSKs su zona. Para obtener más información y un step-by-step ejemplo, consulte *Rotación de claves de DNSSEC* en la entrada del blog [Configuración de la firma y la validación de DNSSEC con Amazon](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/) Route 53.
Para trabajar con ella KSKs Consola de administración de AWS, siga las instrucciones de las siguientes secciones.
## Agregar una clave de firma de claves (KSK)
Cuando se habilita la firma de DNSSEC, Route 53 crea una clave de firma (KSK) por usted. También puede añadirlos KSKs por separado. Puede tener hasta dos KSKs por zona hospedada en Route 53.
Al crear una KSK, debe proporcionar o solicitar a Route 53 que cree una clave administrada por el cliente para utilizarla con la KSK. Cuando proporciona o crea una clave administrada por el cliente, existen varios requisitos. Para obtener más información, consulte [Trabajar con claves administradas por el cliente para DNSSEC](dns-configuring-dnssec-cmk-requirements.md).
Siga estos pasos para agregar una KSK en la Consola de administración de AWS.
**Para agregar una KSK**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. En el panel de navegación, elija **Hosted zones** (Zonas alojadas) y elija una zona alojada.
1. **En la pestaña de **firma de DNSSEC**, en Teclas de **firma de claves (KSKs)**, elija **Cambiar a la vista avanzada y, a** continuación, en **Acciones**, elija Agregar KSK.**
1. En **KSK**, ingrese un nombre para la KSK que Route 53 creará para usted. Los nombres pueden contener letras, números y guiones bajos (\$1). Deben ser únicos.
1. Ingrese el alias de una clave administrada por el cliente que se aplique a la firma de DNSSEC o ingrese un alias para la nueva clave administrada por el cliente que Route 53 creará para usted.
**nota**
Si elige que Route 53 cree una clave administrada por el cliente, tenga en cuenta que se aplican cargos aparte por cada clave administrada por el cliente. Para obtener más información, consulte [Precios de AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
1. Elija **Create KSK** (Crear KSK).
## Editar una clave de firma de claves (KSK)
Puede editar el estado de una KSK para establecerlo en **Active** (Activo) o **Inactive** (Inactivo). Cuando una KSK está activa, Route 53 usa esa KSK para la firma de DNSSEC. Antes de poder eliminar una KSK, debe editarla para establecer su estado en **Inactive** (Inactivo).
Siga estos pasos para editar una KSK en la Consola de administración de AWS.
**Para editar una KSK**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. En el panel de navegación, elija **Hosted zones** (Zonas alojadas) y elija una zona alojada.
1. **En la pestaña de **firma de DNSSEC**, en Teclas de **firma de claves (KSKs)**, elija **Cambiar a la vista avanzada y, a** continuación, en **Acciones**, elija Editar KSK.**
1. Realice las actualizaciones que desee para la KSK y elija **Save** (Guardar).
## Eliminar una clave de firma de claves (KSK)
Antes de poder eliminar una KSK, debe editarla para establecer su estado en **Inactive** (Inactivo).
Una de las razones por las que puede eliminar una KSK es como parte de la rotación rutinaria de claves. Rotar claves criptográficas periódicamente es una práctica recomendada. Es posible que su organización tenga una guía estándar sobre la frecuencia con la que debe rotar las claves.
Siga estos pasos para eliminar una KSK en la Consola de administración de AWS.
**Para eliminar una KSK**
1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. En el panel de navegación, elija **Hosted zones** (Zonas alojadas) y elija una zona alojada.
1. **En la pestaña de **firma de DNSSEC**, en Teclas de **firma de claves (KSKs)**, elija **Cambiar a la vista avanzada y, a** continuación, en **Acciones**, elija Eliminar KSK.**
1. Siga las instrucciones para confirmar la eliminación de la KSK.
# Administración de claves KMS y ZSK en Route 53
En esta sección se describe la práctica actual que Route 53 utiliza para las zonas habilitadas para la firma de DNSSEC.
**nota**
Route 53 utiliza la siguiente regla que podría cambiar. Cualquier cambio futuro no reducirá la posición de seguridad de su zona ni de Route 53.
**Cómo usa Route 53 lo asociado a tu KSK AWS KMS **
En DNSSEC, la KSK se utiliza para generar la firma de registro de recursos (RRSIG) del conjunto de registros de recursos DNSKEY. Todos `ACTIVE` KSKs se utilizan en la generación RRSIG. Route 53 genera un RRSIG llamando a la `Sign` AWS KMS API en la clave KMS asociada. Para obtener más información, consulte [Sign](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) (Firmar) en la *Guía de la API de AWS KMS *. RRSIGsNo se tienen en cuenta para el límite establecido de registros de recursos de la zona.
RRSIG tiene fecha de vencimiento. Para evitar que caduquen, se RRSIGs actualizan periódicamente regenerándolos cada uno a siete días. RRSIGs
También RRSIGs se actualizan cada vez que llamas a cualquiera de las siguientes opciones: APIs
+ [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)
+ [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)
+ [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html)
+ [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)
+ [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)
+ [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)
Cada vez que Route 53 realiza una actualización, generamos 15 RRSIGs para cubrir los próximos días en caso de que no se pueda acceder a la clave KMS asociada. Para la estimación del costo de la clave KMS, puede basarse en una actualización periódica una vez al día. Es posible que no se pueda acceder a una clave KMS debido a cambios involuntarios en la política de claves de KMS. La clave KMS inaccesible establecerá el estado de la KSK asociada en `ACTION_NEEDED`. Le recomendamos encarecidamente que supervise esta situación configurando una CloudWatch alarma cada vez que se detecte un `DNSSECKeySigningKeysNeedingAction` error, ya que al validar las resoluciones, las búsquedas comenzarán a fallar cuando caduque la última RRSIG. Para obtener más información, consulte [Supervisión de zonas alojadas mediante Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
**Cómo administra Route 53 la ZSK de su zona**
Cada nueva zona alojada con firma DNSSEC habilitada tendrá una clave de firma de zona (ZSK) `ACTIVE`. La ZSK se genera por separado para cada zona alojada y es propiedad de Route 53. El algoritmo clave actual es. ECDSAP256 SHA256
Comenzaremos a realizar una rotación ZSK regular en la zona en un plazo de 7 a 30 días desde el inicio de la firma. En la actualidad, Route 53 utiliza el método de transferencia de claves previa a la publicación. Para obtener más información, consulte [Pre-Publish Zone Signing Key Rollover](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1) (Transferencia de claves de firma de zona previa a la publicación). Este método introducirá otra ZSK en la zona. La rotación se repetirá cada 7 a 30 días.
La Ruta 53 suspenderá la rotación de la ZSK si alguna de las KSK de la zona está en `ACTION_NEEDED` estado, ya que la Ruta 53 no podrá regenerar los conjuntos de registros de recursos de DNSKEY RRSIGs para tener en cuenta los cambios en la ZSK de la zona. La rotación de ZSK se reanudará automáticamente después de que se haya borrado la condición.
# Pruebas de inexistencia de DNSSEC en Route 53
**nota**
Route 53 utiliza la siguiente regla que podría cambiar. Cualquier cambio futuro no reducirá la posición de seguridad de su zona ni de Route 53.
Hay tres tipos de pruebas de inexistencia en DNSSEC:
+ Prueba de la inexistencia de un registro que coincida con el nombre de la consulta.
+ Prueba de la inexistencia de un tipo que coincida con el tipo de consulta.
+ Prueba de la existencia de un registro comodín utilizado para generar el registro en respuesta.
Route 53 implementa la prueba de inexistencia de un registro que coincide con el nombre de la consulta utilizando el método BL. Para obtener más información, consulte [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00). Es un método que produce una representación compacta de la prueba y evita la consulta exhaustiva de nombres de zona.
En los casos en que haya un registro que coincida con el nombre de la consulta pero no con el tipo de consulta (por ejemplo, si se busca web.example). com/AAAA but there is only web.example.com/Apresente), devolvemos un registro NSEC (siguiente seguro) mínimo que contiene todos los tipos de registros de recursos admitidos.
Cuando Route 53 sintetiza una respuesta de un registro comodín, la respuesta no irá acompañada de un registro seguro siguiente o de un registro NSEC para el comodín. Este registro NSEC se utiliza en algunas implementaciones, normalmente en las que realizan la firma sin conexión, para evitar que las firmas de registros de recursos (RRSIG) de la respuesta se vuelvan a utilizar para falsificar una respuesta diferente. Route 53 utiliza la firma en línea para los registros que no son de DNSKEY a fin de generar datos RRSIGs específicos para la respuesta que no se pueden reutilizar para una respuesta diferente.
# Solución de problemas de firma de DNSSEC
La información de esta sección puede ayudarlo a abordar los problemas relacionados con la firma de DNSSEC, incluida la activación, la inhabilitación y la utilización de las claves de firma de claves (). KSKs
Habilitación de DNSSEC
Asegúrese de leer los requisitos previos en [Configuración de la firma de DNSSEC en Amazon Route 53](dns-configuring-dnssec.md) antes de habilitar la firma de DNSSEC.
Deshabilitación de DNSSEC
Para deshabilitar DNSSEC de manera segura, Route 53 comprobará si la zona de destino está en la cadena de confianza. Comprueba si el elemento principal de la zona de destino tiene algún registro de NS o de DS de la zona de destino. Si la zona de destino no se puede resolver públicamente, por ejemplo, al obtener una respuesta SERVFAIL al consultar NS y DS, Route 53 no puede determinar si es seguro deshabilitar DNSSEC. Puede contactar con su zona principal para solucionar esos problemas y volver a intentar deshabilitar DNSSEC más adelante.
El estado de KSK es **Action needed** (Acción necesaria)
Una KSK puede cambiar su estado a **Acción necesaria** (o `ACTION_NEEDED` en [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)estado) cuando el DNSSEC de Route 53 pierde el acceso a uno correspondiente AWS KMS key (debido a un cambio en los permisos o a una eliminación). AWS KMS key
Si el estado de un KSK es **Action needed** (Acción necesaria), significa que eventualmente provocará una interrupción de la zona para los clientes que utilizan los solucionadores de validación de DNSSEC y debe actuar rápidamente para evitar que una zona de producción no pueda resolverse.
Para corregir el problema, asegúrese de que la clave administrada por el cliente en la que se basa su KSK está habilitada y tiene los permisos correctos. Para obtener más información sobre los permisos necesarios, consulte [Permisos de clave administrados por el cliente de Route 53 necesarios para firmar DNSSEC](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC).
Una vez que haya arreglado el KSK, actívelo de nuevo mediante la consola o el AWS CLI, tal y como se describe en. [Paso 2: Habilitar la firma DNSSEC y crear un KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable)
Para evitar este problema en el futuro, considere la posibilidad de añadir una Amazon CloudWatch métrica para rastrear el estado de la KSK, tal y como se sugiere en[Configuración de la firma de DNSSEC en Amazon Route 53](dns-configuring-dnssec.md).
El estado de la KSK es **Internal failure** (Error interno)
Cuando un KSK tiene el estado de **fallo interno** (o se encuentra `INTERNAL_FAILURE` en un [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)estado), no puede trabajar con ninguna otra entidad del DNSSEC hasta que se resuelva el problema. Debe adoptar medidas antes de poder trabajar con la firma de DNSSEC, incluido el trabajo con esta KSK o con su otra KSK.
Para corregir el problema, vuelva a intentar activar o desactivar la KSK.
[Para corregir el problema al trabajar con el APIs, prueba a habilitar la firma ([EnableHostedZoneDNSSEC) o inhabilitarla (DNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)). DisableHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)
Es importante que corrija los problemas de tipo **Internal failure** (Error interno) lo antes posible. No puede realizar ningún otro cambio en la zona alojada hasta que corrija el problema, excepto las operaciones para corregir el **Internal failure** (Error interno).
# Uso de AWS Cloud Map para crear registros y comprobaciones de estado
Si desea dirigir el tráfico de Internet o el tráfico de una Amazon VPC a componentes de aplicaciones o microservicios, puede utilizar AWS Cloud Map para crear registros y, opcionalmente, crear comprobaciones de estado automáticamente. Para obtener más información, consulte la [Guía para desarrolladores de AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/).
# Restricciones y comportamientos de DNS
La mensajería DNS está sujeta a factores que afectan a cómo crea y utiliza las zonas alojadas y los registros. En esta sección se explican estos factores.
## Tamaño de respuesta máximo
Para cumplir con los estándares de DNS, las respuestas enviadas a través de UDP tienen un tamaño máximo de 512 bytes. Las respuestas que superen los 512 bytes se truncan y el servicio de resolución debe volver a emitir la solicitud a través de TCP. Si el solucionador admite EDNS0 (tal y como se define en [RFC 2671](https://tools.ietf.org/html/rfc2671)) y anuncia la opción EDNS0 a Amazon Route 53, este servicio permite respuestas de hasta 4096 bytes en UDP, sin truncamiento.
## Procesamiento de sección de Authoritative
Para que las consultas se realicen correctamente, Route 53 adjunta registros de servidor de nombres (NS) para la zona alojada correspondiente en la sección de autoridad de la respuesta DNS. En el caso de los nombres que no se encuentran (respuestas NXDOMAIN), Route 53 adjunta el registro del inicio de autoridad (SOA) (tal y como se define en [RFC 1035](https://tools.ietf.org/html/rfc1035)) para la zona alojada a la sección de autoridad de la respuesta DNS.
## Procesamiento de la sección Additional
Route 53 adjunta registros a la sección Additional (Adicional). Si los registros son conocidos y adecuados, el servicio adjunta registros A o AAAA para cualquier objetivo de un registro MX, CNAME, NS o SRV enumerados en la sección de respuesta. Para obtener más información acerca de estos tipos de registros DNS, consulte [Tipos de registros de DNS admitidos](ResourceRecordTypes.md).
# Temas relacionados
Para obtener información acerca de cómo transferir el registro de dominios (no solo el alojamiento de DNS) a Route 53, consulte los temas siguientes:
+ [Lista de verificación previa a la transferencia para transferencias de dominios](domain-transfer-checklist.md): complete esta lista de verificación antes de transferir el registro de dominios para evitar errores de transferencia comunes.
+ [Transferencia del registro de un dominio a Amazon Route 53](domain-transfer-to-route-53.md): proceso paso a paso para transferir el registro de dominios de otro registrador a Route 53.
+ [Transferencia de dominios](domain-transfer.md): descripción general de todas las opciones de transferencia de dominios, incluidas las transferencias entre cuentas de AWS.