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 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).