As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Como configurar a assinatura de DNSSEC no Amazon Route 53 A assinatura de Domain Name System Security Extensions (DNSSEC) permite que os resolvedores DNS validem que uma resposta DNS veio do Amazon Route 53 e não foi adulterada. Quando você usa a assinatura de DNSSEC, cada resposta para uma zona hospedada é assinada usando criptografia de chave pública. Para obter uma visão geral do DNSSEC, consulte a seção sobre DNSSEC do [AWS re:Invent 2021 - Amazon Route 53: A year in review](https://www.youtube.com/watch?v=77V23phAaAE). Neste capítulo, explicamos como habilitar a assinatura de DNSSEC para o Route 53, como trabalhar com chaves de assinatura de chave (KSKs) e como solucionar problemas. Você pode trabalhar com a assinatura do DNSSEC Console de gerenciamento da AWS ou programaticamente com a API. Para obter mais informações sobre como usar a CLI ou SDKs trabalhar com o Route 53, consulte. [Configurar o Amazon Route 53](setting-up-route-53.md) Antes de habilitar a assinatura de DNSSEC, observe o seguinte: + Para ajudar a evitar uma interrupção da zona e evitar que problemas com o seu domínio se tornem indisponíveis, você deve tratar e resolver rapidamente os erros de DNSSEC. É altamente recomendável que você configure um CloudWatch alarme que o alerte sempre que um `DNSSECKeySigningKeysNeedingAction` erro `DNSSECInternalFailure` ou for detectado. Para obter mais informações, consulte [Monitoramento de zonas hospedadas usando a Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). + Existem dois tipos de chaves no DNSSEC: uma chave de assinatura de chave (KSK) e uma chave de assinatura de zonas (ZSK). Na assinatura de DNSSEC do Route 53, cada KSK é baseada em uma [chave assimétrica gerenciada pelo cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept) no seu AWS KMS . Você é responsável pelo gerenciamento da KSK, que inclui alterná-la, se necessário. O gerenciamento de ZSK é realizado pelo Route 53. + Quando você habilita a assinatura de DNSSEC para uma zona hospedada, o Route 53 limita o TTL a uma semana. Se você definir um TTL de mais de uma semana para registros na zona hospedada, você não receberá um erro. No entanto, o Route 53 impõe um TTL de uma semana para os registros. Registros que têm um TTL de menos de uma semana e registros em outras zonas hospedadas que não têm a assinatura de DNSSEC habilitada não são afetados. + Quando você usa a assinatura de DNSSEC, configurações de vários fornecedores não são suportadas. Se você configurou servidores de nomes de white-label (também conhecidos como servidores de nomes personalizados ou servidores de nomes privados), certifique-se de que esses servidores de nomes sejam fornecidos por um único provedor de DNS. + Alguns provedores de DNS não oferecem suporte a registros de Signatário de Delegação (Delegation Signer, DS) em seu DNS autoritativo. Se sua zona pai for hospedada por um provedor de DNS que não oferece suporte a consultas DS (não definindo um sinalizador AA na resposta da consulta ao DS), quando você habilitar o DNSSEC em sua zona filho, a zona filho ficará sem solução. Certifique-se de que seu provedor de DNS ofereça suporte a registros DS. + Pode ser útil configurar permissões do IAM para permitir que outro usuário, além do proprietário da zona, adicione ou remova registros na região. Por exemplo, um proprietário de zona pode adicionar uma KSK e habilitar a assinatura, e também pode ser responsável pela rotação de chaves. No entanto, outra pessoa pode ser responsável por trabalhar com outros registros para a zona hospedada. Para ver um exemplo de política do IAM, consulte [Permissões de exemplo para um proprietário de registro de domínio](access-control-managing-permissions.md#example-permissions-record-owner). + Para verificar se o TLD é compatível com DNSSEC, consulte [Domínios que você pode registrar com o Amazon Route 53](registrar-tld-list.md). **Topics** + [Como habilitar a assinatura de DNSSEC e estabelecer uma cadeia de confiança](dns-configuring-dnssec-enable-signing.md) + [Como desabilitar a assinatura de DNSSEC](dns-configuring-dnssec-disable.md) + [Como trabalhar com chaves gerenciadas pelo cliente para DNSSEC](dns-configuring-dnssec-cmk-requirements.md) + [Trabalhando com chaves de assinatura de chaves () KSKs](dns-configuring-dnssec-ksk.md) + [Gerenciamento de chaves do KMS e de ZSK no Route 53](dns-configuring-dnssec-zsk-management.md) + [Provas do DNSSEC de inexistência no Route 53](dns-configuring-dnssec-proof-of-nonexistence.md) + [Como solucionar problemas de assinatura de DNSSEC](dns-configuring-dnssec-troubleshoot.md) # Como habilitar a assinatura de DNSSEC e estabelecer uma cadeia de confiança **** As etapas incrementais são aplicáveis ao proprietário da zona hospedada e ao responsável por manter a zona pai. Eles podem ser a mesma pessoa, mas, se não forem, o proprietário da zona deve notificar e trabalhar com o responsável por mantê-la. Recomendamos as etapas deste artigo para que sua zona seja assinada e incluída na cadeia de confiança. As seguintes etapas minimizam o risco de integração no DNSSEC. **nota** Certifique-se de ler os prerrequisitos antes de começar a usar [Como configurar a assinatura de DNSSEC no Amazon Route 53](dns-configuring-dnssec.md). Existem três etapas a serem seguidas para habilitar a assinatura de DNSSEC, conforme descrito nas seções abaixo: **Topics** + [Etapa 1: Preparar-se para habilitar a assinatura de DNSSEC](#dns-configuring-dnssec-enable-signing-step-1) + [Etapa 2: Habilitar a assinatura de DNSSEC e criar uma KSK](#dns-configuring-dnssec-enable) + [Etapa 3: Estabelecer uma cadeia de confiança](#dns-configuring-dnssec-chain-of-trust) ## Etapa 1: Preparar-se para habilitar a assinatura de DNSSEC As etapas de preparação ajudam você a minimizar o risco de integração ao DNSSEC, monitorando a disponibilidade da zona e diminuindo os tempos de espera entre habilitar a assinatura e inserir o registro de signer da delegação (DS). **Para preparar-se para habilitar a assinatura de DNSSEC** 1. Faça o monitoramento da disponibilidade da zona É possível fazer o monitoramento da zona para verificar a disponibilidade dos seus nomes de domínio. Isso pode ajudar você a resolver problemas que possam justificar um passo para trás depois que você habilitar a assinatura de DNSSEC. É possível fazer o monitoramento dos seus nomes de domínio com a maior parte do tráfego utilizando o registro de consultas em log. Para obter mais informações sobre como configurar o registro de consultas em log, consulte [Como monitorar o Amazon Route 53](monitoring-overview.md). O monitoramento pode ser feito com o uso de um shell script ou de um serviço de terceiros. Porém, ele não deve ser o único sinal para determinar a necessidade de uma reversão. Você também pode obter feedback dos seus clientes devido à indisponibilidade de um domínio. 1. Reduza o TTL máximo da zona. O TTL máximo da zona é o registro de TTL mais longo que ela contém. No seguinte exemplo de zona, o TTL máximo da zona é de 1 dia (86.400 segundos). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) Diminuir o TTL máximo da zona ajudará a reduzir o tempo de espera entre habilitar a assinatura e inserir o registro de signer de delegação (DS). Recomendamos reduzir o TTL máximo da zona para 1 hora (3.600 segundos). Isso permitirá uma reversão depois de apenas uma hora se algum resolvedor apresentar problemas com o armazenamento em cache de registros assinados. **Reversão:** desfaça as alterações no TTL. 1. Diminua o campo de TTL SOA e SOA mínimo. O campo de SOA mínimo é o último nos dados do registro SOA. No seguinte exemplo de registro SOA, o campo mínimo tem o valor de 5 minutos (300 segundos). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) O campo de TTL SOA e SOA mínimo determina por quanto tempo os resolvedores memorizam respostas negativas. Depois que você habilitar a assinatura, os servidores de nomes do Route 53 começarão a retornar registros NSEC para respostas negativas. O NSEC contém informações que os resolvedores podem usar para sintetizar uma resposta negativa. Se uma reversão for necessária porque as informações do NSEC fizeram com que um resolvedor considerasse uma resposta negativa para um nome, basta esperar o máximo do campo de TTL SOA e SOA mínimo para que o resolvedor interrompa essa suposição. **Reversão:** desfaça as alterações do SOA. 1. Certifique-se de que as alterações no campo de TTL e SOA mínimo estejam efetivadas. Use [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)para garantir que suas alterações até agora tenham sido propagadas para todos os servidores DNS do Route 53. ## Etapa 2: Habilitar a assinatura de DNSSEC e criar uma KSK Você pode habilitar a assinatura do DNSSEC e criar uma chave de assinatura de chave (KSK) usando AWS CLI ou no console do Route 53. + [CLI](#dnssec_CLI) + [Console](#dnssec_console) Quando você fornece ou cria uma chave do KMS, existem vários requisitos. Para obter mais informações, consulte [Como trabalhar com chaves gerenciadas pelo cliente para DNSSEC](dns-configuring-dnssec-cmk-requirements.md). ------ #### [ CLI ] É possível usar uma chave existente ou criar uma nova, executando um comando da AWS CLI como o seguinte e usando seus próprios valores para `hostedzone_id`, `cmk_arn`, `ksk_name` e `unique_string` (para tornar a solicitação exclusiva): ``` 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 obter mais informações sobre chaves gerenciadas pelo cliente, consulte [Como trabalhar com chaves gerenciadas pelo cliente para DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Consulte também [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html). Para habilitar a assinatura do DNSSEC, execute um AWS CLI comando como o seguinte, usando seu próprio valor para: `hostedzone_id` ``` aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` Para obter mais informações, consulte [enable-hosted-zone-dnssecEnableHostedZone](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html)[DNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html). ------ #### [ Console ] **Para habilitar a assinatura de DNSSEC e criar uma KSK** 1. Faça login no Console de gerenciamento da AWS e abra o console do Route 53 em [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. No painel de navegação, escolha **Hosted zones** (Zonas hospedadas) e depois escolha uma zona hospedada na qual você deseja habilitar a assinatura de DNSSEC. 1. Na guia **DNSSEC signing** (Assinatura de DNSSEC), escolha **Enable DNSSEC signing** (Habilitar assinatura de DNSSEC). **nota** Se a opção nesta seção for **Disable DNSSEC signing** (Desabilitar a assinatura de DNSSEC), você já concluiu a primeira etapa para habilitar a assinatura de DNSSEC. Certifique-se de estabelecer, ou de que já existe, uma cadeia de confiança para a zona hospedada da DNSSEC e, em seguida, está concluído. Para obter mais informações, consulte [Etapa 3: Estabelecer uma cadeia de confiança](#dns-configuring-dnssec-chain-of-trust). 1. Na seção **Key-signing key (KSK) creation** (Criação de chaves de assinatura de chaves), selecione **Create new KSK** (Criar novo KSK) e, em **Provide KSK name** (Forneça um nome para a KSK), insira um nome para a KSK que o Route 53 criará para você. O nome só pode conter números, letras e sublinhados (\$1). Essa opção deve ser exclusiva. 1. Em **Customer managed CMK** (CMK gerenciada pelo cliente), escolha a chave gerenciada pelo cliente para o Route 53 a ser usada quando ele criar a KSK para você. Você pode usar uma chave gerenciada pelo cliente existente que se aplica à assinatura de DNSSEC ou criar uma nova chave gerenciada pelo cliente. Quando você fornece ou cria uma chave gerenciada pelo cliente, há vários requisitos. Para obter mais informações, consulte [Como trabalhar com chaves gerenciadas pelo cliente para DNSSEC](dns-configuring-dnssec-cmk-requirements.md). 1. Insira o alias para uma chave gerenciada pelo cliente existente. Se quiser usar uma nova chave gerenciada pelo cliente, insira um alias para a chave gerenciada pelo cliente, e o Route 53 criará uma para você. **nota** Se você optar por fazer com que o Route 53 crie uma chave gerenciada pelo cliente, esteja ciente de que cobranças separadas se aplicam a cada chave gerenciada pelo cliente. Para mais informações, consulte [Preço do serviço gerenciado pela chave da AWS](https://aws.amazon.com/kms/pricing/). 1. Escolha **Enable DNSSEC signing** (Habilitar assinatura de DNSSEC). ------ **Depois de habilitar a assinatura da zona, conclua as etapas a seguir** (independentemente de ter usado o console ou a CLI): 1. Verifique se a assinatura da zona está efetiva. Se você usou AWS CLI, você pode usar o ID de operação da saída da `EnableHostedZoneDNSSEC()` chamada para executar [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) ou [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)para garantir que todos os servidores DNS do Route 53 estejam assinando respostas (status =). `INSYNC` 1. Aguarde pelo menos o TTL máximo da zona anterior. Aguarde até que os resolvedores liberem todos os registros não assinados de seus caches. Para isso, você deve aguardar pelo menos o TTL máximo da zona anterior. No zona `example.com` acima, o tempo de espera é de 1 dia. 1. Monitore relatórios de problemas de clientes. Depois de habilitar a assinatura da zona, seus clientes podem começar a perceber problemas relacionados a dispositivos de rede e a resolvedores. O período de monitoramento recomendado é de duas semanas. Os seguintes são exemplos de problemas com os quais você pode se deparar: + Alguns dispositivos de rede podem limitar o tamanho das respostas de DNS a menos de 512 bytes, o que é um limite muito pequeno para algumas respostas assinadas. Esses dispositivos devem ser reconfigurados para permitirem tamanhos maiores de resposta de DNS. + Alguns dispositivos de rede fazem uma inspeção profunda nas respostas de DNS e removem certos registros que não compreendem, como os utilizados para o DNSSEC. Esses dispositivos precisam ser reconfigurados. + Os resolvedores de alguns clientes declaram que podem aceitar uma resposta UDP maior do que aquelas com suporte pela rede. Você pode testar a capacidade da sua rede e configurar resolvedores de acordo. Para saber mais, consulte [Servidor de teste de tamanho de respostas de DNS](https://www.dns-oarc.net/oarc/services/replysizetest/). **Reversão: chame** o [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) e, em seguida, reverta as etapas. [Etapa 1: Preparar-se para habilitar a assinatura de DNSSEC](#dns-configuring-dnssec-enable-signing-step-1) ## Etapa 3: Estabelecer uma cadeia de confiança Depois de habilitar a assinatura de DNSSEC para uma zona hospedada no Route 53, estabeleça uma cadeia de confiança para que a zona hospedada conclua sua configuração de assinatura de DNSSEC. Para fazer isso, crie um registro de Signatário da Delegação (DS) na zona hospedada *pai*, para sua zona hospedada, usando as informações fornecidas pelo Route 53. Dependendo de onde seu domínio está registrado, você adiciona o registro à zona hospedada pai no Route 53 ou em outro registrador de domínio. **Para estabelecer uma cadeia de confiança para assinatura de DNSSEC** 1. Faça login no Console de gerenciamento da AWS e abra o console do Route 53 em [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. No painel de navegação, escolha **Hosted zones** (Zonas hospedadas) e escolha uma zona hospedada para a qual você deseja estabelecer uma cadeia de confiança de DNSSEC. *Você deve habilitar primeiro a assinatura de DNSSEC.* 1. Na guia **DNSSEC signing** (Assinatura de DNSSEC), em **DNSSEC signing** (Assinatura de DNSSEC), escolha **View information to create DS record** (Exibir informações para criar registro DS). **nota** Se você não vir **View information to create DS record** (Exibir informações para criar registro DS) nesta seção, você deve habilitar a assinatura de DNSSEC antes de estabelecer a cadeia de confiança. Escolha **Enable DNSSEC signing** (Habilitar assinatura de DNSSEC) e conclua as etapas descritas em [Etapa 2: Habilitar a assinatura de DNSSEC e criar uma KSK](#dns-configuring-dnssec-enable). Depois, retorne a essas etapas para estabelecer a cadeia de confiança. 1. Em **Establish a chain of trust** (Estabelecer uma cadeia de confiança), escolha **Route 53 registrar** (Registrador do Route 53) ou **Another domain registrar** (Outro registrador de domínio), dependendo de onde seu domínio está registrado. 1. Use os valores fornecidos da etapa 3 para criar um registro de DS para a zona hospedada pai no Route 53. Se o domínio não estiver hospedado no Route 53, utilize os valores fornecidos para criar um registro de DS no site do registrador de domínios. Estabelecer uma cadeia de confiança para a zona superior: + Se seu domínio for gerenciado pelo Route 53, siga as etapas abaixo: Certifique-se de configurar o algoritmo de assinatura (ECDSAP256SHA256 e tipo 13) e o algoritmo de resumo (SHA-256 e tipo 2) corretos. Se o Route 53 for o registrador, siga este procedimento no console do Route 53: 1. Observe os valores de **Key type** (Tipo de chave), **Signing algorithm** (Algoritmo de assinatura) e **Public key** (Chave pública). No painel de navegação, escolha **Registered domains** (Domínios registrados). 1. Selecione um domínio e, na guia **Chaves de DNSSEC**, escolha **Adicionar chave**. 1. Na caixa de diálogo **Gerenciar chaves de DNSSEC**, escolha o **Tipo de chave** apropriado e o **Algoritmo** para o **Registrador do Route 53** nos menus suspensos. 1. Copiar a **Public key** (Chave pública) para o registrador do Route 53. Na caixa de diálogo **Manage DNSSEC keys** (Gerenciar chaves de DNSSEC), cole o valor na caixa **Public key** (Chave pública). 1. Escolha **Add** (Adicionar). O Route 53 adicionará o registro DS à zona pai da chave pública. Por exemplo, se o seu domínio for `example.com`, o registro DS será adicionado à zona DNS .com. + Se seu domínio for gerenciado em outro registro, siga as instruções na seção **Outro registrador de domínio**. Para garantir que as seguintes etapas funcionem sem problemas, introduza um TTL de DS baixo na zona pai. Convém configurar o TTL de DS como 5 minutos (300 segundos) para uma recuperação mais rápida caso você precise reverter as alterações. + Estabelecer uma cadeia de confiança para a zona inferior: Caso sua zona pai seja administrada por outro registro, entre em contato com o registrador para introduzir o registro de DS da sua zona. Em geral, você não poderá ajustar o TTL do registro de DS. + Se a zona pai estiver hospedada no Route 53, entre em contato com o proprietário da zona pai para introduzir o registro de DS da sua zona. Forneça o `$ds_record_value` ao proprietário da zona pai. Você pode obtê-lo clicando em **Exibir informações para criar um registro DS** no console e copiar o campo de **registro DS**, ou chamando a API [GetDNSsec](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) e recuperando o valor do campo '': DSRecord ``` aws --region us-east-1 route53 get-dnssec --hosted-zone-id $hostedzone_id ``` O proprietário da zona pai pode inserir o registro usando o console do Route 53 ou a CLI. + Para inserir o registro DS usando AWS CLI, o proprietário da zona principal cria e nomeia um arquivo JSON semelhante ao exemplo a seguir. O proprietário da zona pai pode atribuir ao arquivo um nome semelhante a `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" } ] } } ] } } ``` Em seguida, execute o seguinte comando: ``` aws --region us-east-1 route53 change-resource-record-sets --cli-input-json file://inserting_ds.json ``` + Para inserir o registro de DS usando o console: Abra o console do Route 53 em [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). No painel de navegação, escolha **Hosted zones** (Zonas hospedadas), o nome da zona hospedada e depois **Create record** (Criar registro). Escolha o roteamento simples para **Routing policy** (Política de roteamento). No campo **Nome de registro**, insira o mesmo nome que `$zone_name`, selecione DS para a lista suspensa **Tipo de registro** e insira o valor de `$ds_record_value` no campo **Valor** e escolha **Criar registros**. **Reversão:** remova o DS da zona pai, aguarde o TTL do DS e depois reverta as etapas para estabelecer confiança. Se a zona pai estiver hospedada no Route 53, seu proprietário poderá alterar `Action` de `UPSERT` para `DELETE` no arquivo JSON e executar novamente o exemplo de CLI acima. 1. Aguarde até que as atualizações sejam propagadas, com base no TTL para seus registros de domínio. Se a zona principal estiver no serviço DNS do Route 53, o proprietário da zona principal poderá confirmar a propagação completa por meio da [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Caso contrário, você poderá sondar periodicamente a zona pai no que diz respeito ao registro DS e aguardar mais 10 minutos depois para aumentar a probabilidade de a inserção do registro de DS ser completamente propagada. Alguns registradores agendam a inserção do DS, por exemplo, uma vez ao dia. Quando você introduz o registro de signer de delegação (DS) na zona pai, os resolvedores validados que escolheram o DS começam a validar as respostas da zona. Para garantir que as etapas para estabelecer a confiança sigam sem problemas, faça o seguinte: 1. Localize o TTL de NS máximo. Existem dois conjuntos de registros de NS associados às suas zonas: + O registro de NS de delegação, ou seja, o registro de NS da sua zona mantida pela zona pai. Você pode encontrá-lo executando os seguintes comandos Unix (se sua zona for example.com, a zona pai será com): `dig -t NS com` Escolha um dos registros de NS e execute o seguinte: `dig @one of the NS records of your parent zone -t NS example.com` Por exemplo: `dig @b.gtld-servers.net. -t NS example.com` + O registro de NS na zona, ou seja, o registro de NS na sua zona. Você pode localizá-lo executando o seguinte comando Unix: `dig @one of the NS records of your zone -t NS example.com` Por exemplo: `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` Observe o TTL máximo de ambas as zonas. 1. Aguarde o TTL de NS máximo. Antes da inserção do DS, os resolvedores recebem uma resposta assinada, mas não validam a assinatura. Quando o registro de DS for inserido, os resolvedores apenas o verão quando o registro de NS da zona expirar. Quando os resolvedores voltarem a buscar o registro de NS, o registro de DS também será retornado. Se o seu cliente estiver executando um resolvedor em um host com um relógio fora de sincronia, verifique se esse relógio está dentro de 1 hora após a hora correta. Depois que você concluir essa etapa, todos os resolvedores com reconhecimento de DNSSEC validarão sua zona. 1. Observe a resolução de nomes. Você deve observar que não existem problemas com resolvedores validando sua zona. Não deixe de considerar o tempo necessário para os seus clientes informarem problemas para você. Convém fazer um monitoramento por até 2 semanas. 1. (Opcional) Aumente o DS e o NS TTLs. Se estiver satisfeito com a configuração, você poderá salvar as alterações de TTL e SOA feitas. O Route 53 limita o TTL a 1 semana para zonas assinadas. Para obter mais informações, consulte [Como configurar a assinatura de DNSSEC no Amazon Route 53](dns-configuring-dnssec.md). Se você puder alterar o TTL de DS, recomendamos defini-lo como 1 hora. # Como desabilitar a assinatura de DNSSEC As etapas para desabilitar a assinatura de DNSSEC no Route 53 variam, dependendo da cadeia de confiança da qual sua zona hospedada faz parte. Por exemplo, sua zona hospedada pode ter uma zona pai que tenha um registro de Signatário da Delegação (DS), como parte de uma cadeia de confiança. Sua zona hospedada também pode ser uma zona pai para zonas filho que habilitaram a assinatura de DNSSEC, que é outra parte da cadeia de confiança. Investigue e determine toda a cadeia de confiança para sua zona hospedada antes de executar as etapas para desabilitar a assinatura de DNSSEC. A cadeia de confiança para sua zona hospedada que habilita a assinatura de DNSSEC deve ser cuidadosamente desfeita à medida que você desabilita a assinatura. Para remover sua zona hospedada da cadeia de confiança, você remove todos os registros DS que estão em vigor para a cadeia de confiança que inclui essa zona hospedada. Isso significa que você deve fazer o seguinte, na ordem: 1. Remover todos os registros DS que esta zona hospedada tem para zonas filho que fazem parte de uma cadeia de confiança. 1. Remova o registro de DS da zona pai. Ignore essa etapa se tiver uma ilha de confiança (não há registros de DS na zona pai e não há registros de DS para zonas filho nessa zona). 1. Se você não conseguir remover registros DS, para remover a zona da cadeia de confiança, remova os registros NS da zona pai. Para obter mais informações, consulte [Adicionar ou alterar servidores de nome e registros cola de um domínio](domain-name-servers-glue-records.md). As seguintes etapas incrementais permitem monitorar a eficácia das etapas individuais para evitar problemas de disponibilidade de DNS na sua zona. **Para desabilitar a assinatura de DNSSEC** 1. Faça o monitoramento da disponibilidade da zona É possível fazer o monitoramento da zona para verificar a disponibilidade dos seus nomes de domínio. Isso pode ajudar você a resolver problemas que possam justificar um passo para trás depois que você habilitar a assinatura de DNSSEC. É possível fazer o monitoramento dos seus nomes de domínio com a maior parte do tráfego utilizando o registro de consultas em log. Para obter mais informações sobre como configurar o registro de consultas em log, consulte [Como monitorar o Amazon Route 53](monitoring-overview.md). O monitoramento pode ser feito com o uso de um shell script ou de um serviço pago. Porém, ele não deve ser o único sinal para determinar a necessidade de uma reversão. Você também pode obter feedback dos seus clientes devido à indisponibilidade de um domínio. 1. Localize o TTL de DS atual. Você pode localizar o TTL de DS executando o seguinte comando Unix: `dig -t DS example.com example.com` 1. Localize o TTL de NS máximo. Existem dois conjuntos de registros de NS associados às suas zonas: + O registro de NS de delegação, ou seja, o registro de NS da sua zona mantida pela zona pai. Você pode alterar isso executando os seguintes comandos Unix: Primeiro, localize o NS da sua zona pai (se sua zona for exemplo.com, a zona pai será com): `dig -t NS com` Escolha um dos registros de NS e execute o seguinte: `dig @one of the NS records of your parent zone -t NS example.com` Por exemplo: `dig @b.gtld-servers.net. -t NS example.com` + O registro de NS na zona, ou seja, o registro de NS na sua zona. Você pode localizá-lo executando o seguinte comando Unix: `dig @one of the NS records of your zone -t NS example.com` Por exemplo: `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` Observe o TTL máximo de ambas as zonas. 1. Remova o registro de DS da zona pai. Entre em contato com o proprietário da zona pai para remover o registro de DS. **Reversão:** reinsira registro do DS, confirme que a inserção do DS foi efetivada e aguarde o TTL máximo do NS (não do DS) antes que todos os resolvers comecem a validar novamente. 1. Confirme se a remoção do DS foi efetivada. Se a zona principal estiver no serviço DNS do Route 53, o proprietário da zona principal poderá confirmar a propagação completa por meio da [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Caso contrário, você poderá sondar periodicamente a zona pai no que diz respeito ao registro DS e aguardar mais 10 minutos depois para aumentar a probabilidade de a remoção do registro de DS ser completamente propagada. Alguns registradores agendam a remoção do DS, por exemplo, uma vez ao dia. 1. Aguarde o TTL de DS. Aguarde até que todos os resolvedores tenham expirado o registro de DS de seus caches. 1. Desabilite a assinatura de DNSSEC e desative a chave de assinatura de chaves (KSK). + [CLI](#CLI_dnssec_disable) + [Console](#console_dnssec_disable) ------ #### [ CLI ] Ligue para o [DisableHostedZoneDNSSEC e. [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html)](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) APIs Por exemplo: ``` 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 desabilitar a assinatura de DNSSEC** 1. Faça login no Console de gerenciamento da AWS e abra o console do Route 53 em [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. No painel de navegação, escolha **Hosted zones** (Zonas hospedadas) e escolha uma zona hospedada na qual você deseja desabilitar a assinatura de DNSSEC. 1. Na guia **DNSSEC signing** (Assinatura do DNSSEC), escolha **Disable DNSSEC signing** (Desabilitar assinatura de DNSSEC). 1. Na página **Disable DNSSEC signing** (Desabilitar a assinatura de DNSSEC), escolha uma das opções a seguir, dependendo do cenário da zona para a qual você está desabilitando a assinatura de DNSSEC. + **Parent zone only** (Somente zona pai): esta zona tem uma zona pai com um registro DS. Nesse cenário, você deve remover o registro DS da zona pai. + **Child zones only** (Somente zonas filho): esta zona tem um registro DS para uma cadeia de confiança com uma ou mais zonas filho. Nesse cenário, você deve remover registros DS da zona. + **Parent and child zones** (Zonas pai e filho): esta zona tem um registro DS para uma cadeia de confiança com uma ou mais zonas filho *e* uma zona pai com um registro DS. Para esse cenário, faça o seguinte na ordem: 1. Remova os registros DS da zona. 1. Remova o registro DS da zona pai. Se tiver uma ilha de confiança, ignore essa etapa. 1. Determine qual é o TTL de cada registro de DS que você remover na Etapa 4 e verifique se o período de TTL mais longo expirou. 1. Marque a caixa de seleção para confirmar que você seguiu as etapas na ordem. 1. Digite *disable* (desabilitar) no campo, conforme mostrado, e escolha **Disable** (Desabilitar). **Para desativar a chave de assinatura de chaves (KSK)** 1. Faça login no Console de gerenciamento da AWS e abra o console do Route 53 em [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. No painel de navegação, escolha **Hosted zones** (Zonas hospedadas) e escolha uma zona hospedada cuja chave de assinatura de chaves (KSK) você queira desativar. 1. **Na seção **Chaves de assinatura de chave (KSKs)**, escolha a KSK que você deseja desativar e, em **Ações**, escolha **Editar KSK, defina o status da KSK** **como **Inativo** e escolha Salvar KSK**.** ------ **Reversão: chamada ActivateKeySigningKey[https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) e EnableHostedZone DNSSEC**[.](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) APIs Por exemplo: ``` 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 a ação de desabilitar a assinatura da zona foi efetivada. Use o ID da `EnableHostedZoneDNSSEC()` chamada a ser executada [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)para garantir que todos os servidores DNS do Route 53 tenham parado de assinar respostas (status =`INSYNC`). 1. Observe a resolução de nomes. Você deve observar que não há problemas resultando na validação da sua zona pelos resolvedores. Aguarde de uma a duas semanas para também considerar o tempo necessário para os seus clientes informarem problemas para você. 1. (Opcional) Limpe. Se você não reativar a assinatura, poderá limpar a chave gerenciada KSKs pelo cliente correspondente [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)e excluir a chave gerenciada pelo cliente correspondente para economizar custos. # Como trabalhar com chaves gerenciadas pelo cliente para DNSSEC Quando você habilita a assinatura DNSSEC no Amazon Route 53, o Route 53 cria uma chave de assinatura de chave (KSK). Para criar um KSK, o Route 53 deve usar uma chave gerenciada pelo cliente AWS Key Management Service que ofereça suporte ao DNSSEC. Esta seção descreve os detalhes e os requisitos para a chave gerenciada pelo cliente que são úteis conhecer ao trabalhar com o DNSSEC. Lembre-se do seguinte ao trabalhar com chaves gerenciadas pelo cliente para DNSSEC: + A chave gerenciada pelo cliente que você usa com a assinatura de DNSSEC deve estar na região Leste dos EUA (Norte da Virgínia). + A chave gerenciada pelo cliente deve ser uma [chave assimétrica gerenciada pelo cliente](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks) com uma [especificação principal ECC\$1NIST\$1P256](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc). Essas chaves gerenciadas pelo cliente são usadas somente para assinatura e verificação. Para obter ajuda na criação de uma chave assimétrica gerenciada pelo cliente, consulte [Criação de chaves assimétricas gerenciadas pelo cliente](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) no Guia do desenvolvedor. AWS Key Management Service Para obter ajuda para encontrar a configuração criptográfica de uma chave gerenciada pelo cliente existente, consulte [Visualização da configuração criptográfica das chaves gerenciadas pelo cliente](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html) no Guia do AWS Key Management Service desenvolvedor. + Se você criar uma chave gerenciada pelo cliente para usar com o DNSSEC no Route 53, deverá incluir instruções de política de chave específicas que concedam ao Route 53 as permissões necessárias. O Route 53 deve ser capaz de acessar sua chave gerenciada pelo cliente para que ele possa criar uma KSK para você. Para obter mais informações, consulte [Permissões de chave gerenciada pelo cliente do Route 53 necessárias para assinatura DNSSEC](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC). + O Route 53 pode criar uma chave gerenciada pelo cliente para você usar com AWS KMS a assinatura do DNSSEC sem permissões adicionais AWS KMS . No entanto, você deve ter permissões específicas se quiser editar a chave depois que ela for criada. As permissões específicas que você deve ter são as seguintes: `kms:UpdateKeyDescription`, `kms:UpdateAlias` e `kms:PutKeyPolicy`. + Esteja ciente de que cobranças separadas se aplicam a cada chave gerenciada pelo cliente que você possui, quer você crie a chave gerenciada pelo cliente ou o Route 53 a crie para você. Para obter mais informações, consulte [Preços do AWS Key Management Service](https://aws.amazon.com/kms/pricing/). # Trabalhando com chaves de assinatura de chaves () KSKs Quando você habilita a assinatura de DNSSEC, o Route 53 cria uma chave de assinatura de chave (KSK) para você. Você pode ter até duas KSKs por zona hospedada no Route 53. Depois de habilitar a assinatura do DNSSEC, você pode adicionar, remover ou editar seu. KSKs Observe o seguinte ao trabalhar com o seu KSKs: + Antes de excluir uma KSK, você deve editar a KSK para definir seu status como **Inactive** (Inativo). + Quando a assinatura de DNSSEC estiver habilitada para uma zona hospedada, o Route 53 limitará o TTL a uma semana. Se você definir um TTL para registros na zona hospedada como mais de uma semana, não receberá um erro, mas o Route 53 vai impor um TTL de uma semana. + Para ajudar a evitar uma interrupção da zona e evitar que problemas com o seu domínio se tornem indisponíveis, você deve tratar e resolver rapidamente os erros de DNSSEC. É altamente recomendável que você configure um CloudWatch alarme que o alerte sempre que um `DNSSECKeySigningKeysNeedingAction` erro `DNSSECInternalFailure` ou for detectado. Para obter mais informações, consulte [Monitoramento de zonas hospedadas usando a Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). + As operações KSK descritas nesta seção permitem que você gire as da sua zona. KSKs Para obter mais informações e um step-by-step exemplo, consulte *DNSSEC Key Rotation* na postagem do blog [Configurando a assinatura e validação do DNSSEC com](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/) o Amazon Route 53. Para trabalhar com KSKs o Console de gerenciamento da AWS, siga as orientações nas seções a seguir. ## Adicionar uma chave de assinatura de chave (KSK) Quando você habilita a assinatura de DNSSEC, o Route 53 cria uma assinatura de chave (KSK) para você. Você também pode adicionar KSKs separadamente. Você pode ter até duas KSKs por zona hospedada no Route 53. Ao criar uma KSK, você deve fornecer ou solicitar ao Route 53 a criação de uma chave gerenciada pelo cliente para usar com a KSK. Quando você fornece ou cria uma chave gerenciada pelo cliente, há vários requisitos. Para obter mais informações, consulte [Como trabalhar com chaves gerenciadas pelo cliente para DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Siga estas etapas para adicionar uma KSK no Console de gerenciamento da AWS. **Como adicionar uma KSK** 1. Faça login no Console de gerenciamento da AWS e abra o console do Route 53 em [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. No painel de navegação, escolha **Hosted zones** (Zonas hospedadas) e, em seguida, escolha uma zona hospedada. 1. **Na guia **Assinatura do DNSSEC**, em **Chaves de assinatura de chave (KSKs), escolha **Alternar para exibição avançada** e, em **Ações**, escolha Adicionar KSK**.** 1. Em **KSK**, insira um nome para a KSK que o Route 53 criará para você. O nome só pode conter números, letras e sublinhados (\$1). Essa opção deve ser exclusiva. 1. Insira o alias para uma chave gerenciada pelo cliente que se aplica à assinatura DNSSEC ou insira um alias para uma nova chave gerenciada pelo cliente que o Route 53 criará para você. **nota** Se você optar por fazer com que o Route 53 crie uma chave gerenciada pelo cliente, esteja ciente de que cobranças separadas se aplicam a cada chave gerenciada pelo cliente. Para obter mais informações, consulte [Preços do AWS Key Management Service](https://aws.amazon.com/kms/pricing/). 1. Escolha **Create KSK** (Criar KSK). ## Edite uma chave de assinatura de chave (KSK) Você pode editar o status de uma KSK para ser **Active** (Ativo) ou **Inactive** (Inativo). Quando uma KSK está ativa, o Route 53 usa essa KSK para assinatura de DNSSEC. Antes de excluir uma KSK, você deve editar a KSK para definir seu status como **Inactive** (Inativo). Siga estas etapas para editar uma KSK no Console de gerenciamento da AWS. **Para editar uma KSK** 1. Faça login no Console de gerenciamento da AWS e abra o console do Route 53 em [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. No painel de navegação, escolha **Hosted zones** (Zonas hospedadas) e, em seguida, escolha uma zona hospedada. 1. **Na guia **Assinatura do DNSSEC**, em **Chaves de assinatura de chave (KSKs)**, escolha **Alternar para exibição avançada** e, em **Ações**, escolha Editar KSK.** 1. Faça as atualizações desejadas na KSK e escolha **Save** (Salvar). ## Excluir uma chave de assinatura de chave (KSK) Antes de excluir uma KSK, você deve editar a KSK para definir seu status como **Inactive** (Inativo). Um dos motivos pelos quais você pode excluir uma KSK é como parte da rotação de chaves de rotina. É uma prática recomendada rotacionar chaves criptográficas periodicamente. Sua organização pode ter orientação padrão para a frequência de rotação das chaves. Siga estas etapas para excluir uma KSK no Console de gerenciamento da AWS. **Para excluir uma KSK** 1. Faça login no Console de gerenciamento da AWS e abra o console do Route 53 em [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. No painel de navegação, escolha **Hosted zones** (Zonas hospedadas) e, em seguida, escolha uma zona hospedada. 1. **Na guia **Assinatura do DNSSEC**, em **Chaves de assinatura de chave (KSKs)**, escolha **Alternar para exibição avançada** e, em **Ações**, escolha Excluir KSK.** 1. Siga as orientações para confirmar a exclusão da KSK. # Gerenciamento de chaves do KMS e de ZSK no Route 53 Esta seção descreve a prática atual que o Route 53 usa em suas zonas habilitadas para assinatura de DNSSEC. **nota** O Route 53 usa a regra a seguir, que pode ser alterada. Alterações futuras não reduzirão o procedimento de segurança de sua zona ou do Route 53. **Como o Route 53 usa o AWS KMS associado ao seu KSK** No DNSSEC, utiliza-se a KSK para gerar a assinatura de registro do recurso (RRSIG) para o conjunto de registros do recurso da DNSKEY. Todos `ACTIVE` KSKs são usados na geração RRSIG. O Route 53 gera um RRSIG chamando a `Sign` AWS KMS API na chave KMS associada. Para obter mais informações, consulte [Sign](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) (Assinar) no *Guia de referência da API do AWS KMS *. Eles RRSIGs não contam para o limite do conjunto de registros de recursos da zona. O RRSIG tem validade. Para evitar que RRSIGs expirem, eles RRSIGs são atualizados regularmente, regenerando-os a cada um a sete dias. Eles também RRSIGs são atualizados toda vez que você liga para qualquer um desses: 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) Sempre que o Route 53 realiza uma atualização, geramos 15 RRSIGs para cobrir os próximos dias, caso a chave KMS associada fique inacessível. Para uma estimativa de custo da chave do KMS, considere uma atualização regular uma vez por dia. Uma chave do KMS pode ficar inacessível por alterações inesperadas na política de chaves do KMS. A chave do KMS inacessível definirá o status da KSK associada como `ACTION_NEEDED`. É altamente recomendável que você monitore essa condição configurando um CloudWatch alarme sempre que um `DNSSECKeySigningKeysNeedingAction` erro for detectado, pois a validação dos resolvedores iniciará pesquisas com falha após a expiração do último RRSIG. Para obter mais informações, consulte [Monitoramento de zonas hospedadas usando a Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). **Como o Route 53 gerencia a ZSK da zona** Cada nova zona hospedada com assinatura DNSSEC ativada terá uma chave de assinatura de zona (ZSK) `ACTIVE`. A ZSK é gerada separadamente para cada zona hospedada e pertence ao Route 53. O algoritmo chave atual é ECDSAP256SHA256. Começaremos a executar a alternância regular da ZSK na zona no período de 7 a 30 dias após o início da assinatura. Atualmente, o Route 53 usa o método de sobreposição de chave pré-publicação. Para obter mais informações, consulte [Pre-Publish Zone Signing Key Rollover](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1) (Sobreposição de chave de assinatura de zona pré-publicação). Esse método introduzirá outro ZSK à zona. A alternância será repetida a cada período de 7 a 30 dias. O Route 53 suspenderá a rotação do ZSK se algum KSK da zona estiver em `ACTION_NEEDED` status, pois o Route 53 não poderá regenerar os conjuntos de registros de recursos do DNSKEY RRSIGs para contabilizar as alterações no ZSK da zona. A alternância da ZSK será retomada automaticamente após a condição ser apagada. # Provas do DNSSEC de inexistência no Route 53 **nota** O Route 53 usa a regra a seguir, que pode ser alterada. Alterações futuras não reduzirão o procedimento de segurança de sua zona ou do Route 53. Há três tipos de prova de inexistência no DNSSEC: + Prova de inexistência de um registro correspondente ao nome da consulta. + Prova de inexistência de um tipo correspondente ao tipo da consulta. + Prova de existência de um registro curinga usado para gerar o registro em resposta. O Route 53 implementa a prova de inexistência de um registro correspondente ao nome da consulta usando o método BL. Para obter mais informações, consulte [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00). É um método que produz uma representação compacta da prova e evita a verificação de zona. Nos casos em que há um registro que corresponde ao nome da consulta, mas não ao tipo de consulta (como consultar web.example). com/AAAA but there is only web.example.com/Apresent), retornamos um registro NSEC (próximo seguro) mínimo contendo todos os tipos de registro de recursos compatíveis. Quando o Route 53 sintetizar uma resposta de um registro coringa, a resposta não será acompanhada com um próximo registro seguro ou um registro NSEC para o coringa. Esse registro NSEC é usado em algumas implementações, geralmente naquelas que executam assinatura offline, para evitar que as assinaturas de registro do recurso (RRSIG) na resposta sejam reutilizadas para falsificar uma resposta diferente. O Route 53 usa assinatura on-line para registros que não sejam DNSKey para gerar dados RRSIGs específicos para a resposta, que não podem ser reutilizados para uma resposta diferente. # Como solucionar problemas de assinatura de DNSSEC As informações nesta seção podem ajudá-lo a resolver problemas com a assinatura do DNSSEC, incluindo ativação, desativação e com suas chaves de assinatura de chaves (). KSKs Como habilitar DNSSEC Certifique-se de ler os prerrequisitos em [Como configurar a assinatura de DNSSEC no Amazon Route 53](dns-configuring-dnssec.md) antes de começar a habilitar assinatura DNSSEC. Como desabilitar DNSSEC Para desabilitar o DNSSEC com segurança, o Route 53 verificará se a zona de destino está na cadeia de confiança. Ele verifica se o pai da zona de destino tem algum registro NS da zona de destino e registros DS da zona de destino. Se a zona de destino não puder ser resolvida publicamente, por exemplo, obtendo uma resposta SERVFAIL ao consultar NS e DS, o Route 53 não poderá determinar se é seguro desabilitar o DNSSEC. Você pode entrar em contato com sua zona pai para corrigir esses problemas e tentar desabilitar o DNSSEC novamente mais tarde. O status da KSK é **Action needed** (Ação necessária) Uma KSK pode mudar seu status para **Ação necessária** (ou `ACTION_NEEDED` em um [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)status) quando o Route 53 DNSSEC perde acesso a uma correspondente AWS KMS key (devido a uma alteração nas permissões ou AWS KMS key exclusão). Se o status de uma KSK for **Action needed** (Ação necessária), significa que, eventualmente, ele causará uma interrupção de zona para clientes que usam resolvedores de validação de DNSSEC, e você deverá agir rapidamente para evitar que uma zona de produção se torne incapaz de ser resolvida. Para corrigir o problema, certifique-se de que a chave gerenciada pelo cliente na qual a KSK se baseia está habilitada e tem as permissões corretas. Para mais informações sobre as permissões necessárias, consulte [Permissões de chave gerenciada pelo cliente do Route 53 necessárias para assinatura DNSSEC](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC). Depois de corrigir o KSK, ative-o novamente usando o console ou o AWS CLI, conforme descrito em[Etapa 2: Habilitar a assinatura de DNSSEC e criar uma KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable). Para evitar esse problema no futuro, considere adicionar uma Amazon CloudWatch métrica para rastrear o estado do KSK, conforme sugerido em[Como configurar a assinatura de DNSSEC no Amazon Route 53](dns-configuring-dnssec.md). O status da KSK é **Internal failure** (Falha interna) Quando uma KSK tem um status de **falha interna** (ou `INTERNAL_FAILURE` em um [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)status), você não pode trabalhar com nenhuma outra entidade do DNSSEC até que o problema seja resolvido. Você deve tomar medidas antes de poder trabalhar com a assinatura de DNSSEC, inclusive trabalhar com esta KSK ou com outra KSK. Para corrigir o problema, tente novamente habilitar ou desabilitar a KSK. [Para corrigir o problema ao trabalhar com o APIs, tente ativar a assinatura ([EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)) ou desativar a assinatura (DisableHostedZoneDNSSEC).](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) É importante que você corrija os problemas de **Internal failure** (Falha interna) prontamente. Você não pode fazer outras alterações na zona hospedada até que você corrija o problema, exceto as operações para corrigir a **Internal failure** (Falha interna).