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á. # Configurar o Amazon Route 53 como serviço DNS Você pode usar o Amazon Route 53 como o serviço DNS para seu domínio, como example.com. Quando o Route 53 for o seu serviço DNS, ele encaminhará o tráfego da Internet para o seu site convertendo nomes de domínio amigáveis, como www.example.com, em endereços IP numéricos, como 192.0.2.1, que os computadores usam para se conectar uns aos outros. Quando alguém digita seu nome de domínio em um navegador ou envia um e-mail para você, uma consulta de DNS é encaminhada para o Route 53, que responde com o valor apropriado. Por exemplo, o Route 53 pode responder com o endereço IP para o servidor da Web para example.com. **Hospedagem de DNS x registro de domínio** Este capítulo aborda o uso do Route 53 *somente para hospedagem de DNS*. Isso significa que o registro do seu domínio permanecerá com o seu registrador atual e você continuará pagando a ele pelas renovações do domínio. O Route 53 apenas gerencia suas configurações de DNS e lida com consultas ao DNS para o seu domínio. Se você deseja transferir seu registro de domínio para o Route 53 também (tornando o Route 53 seu registrador e serviço DNS), consulte [Lista de verificação pré-transferência para transferências de domínios](domain-transfer-checklist.md) e [Como transferir registro de um domínio para o Amazon Route 53](domain-transfer-to-route-53.md). Neste capítulo, explicaremos como configurar o Route 53 para encaminhar seu tráfego de Internet para locais apropriados. Também explicaremos como migrar o serviço DNS para o Route 53, se você estiver usando outro serviço DNS e como usar o Route 53 como o serviço DNS de um novo domínio. **Topics** + [Como transformar o Amazon Route 53 no serviço de DNS para um domínio existente](MigratingDNS.md) + [Configurar o roteamento de DNS para um novo domínio](dns-configuring-new-domain.md) + [Rotear tráfego para seus recursos](dns-routing-traffic-to-resources.md) + [Trabalhar com zonas hospedadas](hosted-zones-working-with.md) + [Trabalhar com registros](rrsets-working-with.md) + [Como configurar a assinatura de DNSSEC no Amazon Route 53](dns-configuring-dnssec.md) + [Usar o AWS Cloud Map para criar registros e verificações de integridade](autonaming.md) + [Restrições e comportamentos de DNS](DNSBehavior.md) + [Tópicos relacionados](dns-configuring-related-topics.md) # Como transformar o Amazon Route 53 no serviço de DNS para um domínio existente Se você estiver transferindo um ou mais registros de domínio para o Route 53 e estiver usando um registrador de domínio que não forneça um serviço de DNS pago, será necessário migrar o serviço DNS antes de migrar o domínio. Caso contrário, o registrador deixará de fornecer serviços de DNS quando você transferir seus domínios, e os sites e aplicações Web associados ficarão indisponíveis na Internet. (Você também pode migrar o serviço de DNS do registrador atual para outro provedor de serviços de DNS. Nós não exigimos que você use o Route 53 como o provedor de serviços DNS para domínios registrados com o Route 53.) O processo depende se você está usando o domínio na ocasião: + Se o domínio estiver recebendo tráfego atualmente, por exemplo, se os usuários estiverem usando o nome de domínio para navegar em um site ou acessar uma aplicação Web, consulte [Tornar o Route 53 o serviço de DNS para um domínio que está em uso](migrate-dns-domain-in-use.md). + Se o domínio não estiver recebendo nenhum tráfego (ou recebendo pouquíssimo tráfego), consulte [Tornar o Route 53 o serviço DNS para um domínio inativo](migrate-dns-domain-inactive.md). Em ambas as opções, seu domínio deve permanecer disponível durante todo o processo de migração. No entanto, no caso improvável de ocorrer algum problema, a primeira opção permite reverter a migração rapidamente. Com a segunda opção, seu domínio pode ficar indisponível para alguns dias. Se você quiser entrar em contato com um especialista em AWS, visite o [suporte de vendas](https://aws.amazon.com/contact-us/sales-support/?pg=ln&sec=hs). # Tornar o Route 53 o serviço de DNS para um domínio que está em uso Se quiser migrar o serviço DNS para o Amazon Route 53 para um domínio que atualmente está recebendo tráfego, por exemplo, se os usuários estiverem usando o nome de domínio para navegar em um site ou acessar uma aplicação Web, execute os procedimentos desta seção. **Topics** + [Etapa 1: descobrir a configuração atual do DNS com o provedor de serviço de DNS atual (opcional, mas recomendado)](#migrate-dns-get-zone-file) + [Etapa 2: criar uma zona hospedada](#migrate-dns-create-hosted-zone) + [Etapa 3: criar registros](#migrate-dns-create-records) + [Etapa 4: reduzir as configurações de TTL](#migrate-dns-lower-ttl) + [Etapa 5: (Se você tiver o DNSSEC configurado) Remova o registro DS da zona pai](#migrate-remove-ds) + [Etapa 6: Aguardar pela expiração do TTL antigo](#migrate-dns-wait-for-ttl) + [Etapa 7: Atualizar os registros NS para usar servidores de nome do Route 53](#migrate-dns-change-name-servers-with-provider) + [Etapa 8: Monitorar o tráfego do domínio](#migrate-dns-monitor-traffic) + [Etapa 9: alterar o TTL para o registro de NS de volta para um valor maior](#migrate-dns-change-ttl-back) + [Etapa 10: Transferir o registro de um domínio para o Amazon Route 53](#migrate-dns-transfer-domain-registration) + [Etapa 11: Reabilite a assinatura de DNSSEC (se necessário)](#migrate-dns-re-enable-dnssec) ## Etapa 1: descobrir a configuração atual do DNS com o provedor de serviço de DNS atual (opcional, mas recomendado) Ao migrar o serviço DNS de outro provedor para o Route 53, você reproduz a configuração DNS atual no Route 53. No Route 53, você cria uma zona hospedada que tem o mesmo nome que seu domínio e cria registros nela. Cada registro indica como você deseja direcionar o tráfego para um nome de domínio ou nome de subdomínio especificado. Por exemplo, quando alguém insere seu nome de domínio em um navegador da web, você quer que o tráfego seja roteado para um servidor web em seu data center, para uma instância do Amazon EC2, para CloudFront uma distribuição ou para algum outro local? O processo usado depende da complexidade da sua configuração DNS atual: + **Se sua configuração DNS atual for simples**: se você estiver encaminhando o tráfego da Internet de apenas alguns subdomínios para um pequeno número de recursos, como servidores Web ou buckets do Amazon S3, você poderá criar alguns registros manualmente no console do Route 53. + **Se sua configuração DNS atual for mais complexa e você quiser apenas reproduzir a configuração atual**: você poderá simplificar a migração se puder obter um arquivo de zona do provedor de serviço DNS atual e importar o arquivo de zona no Route 53. (Nem todos os provedores de serviço de DNS disponibilizam os arquivos de zona.) Quando você importa um arquivo de zona, o Route 53 reproduz automaticamente a configuração existente, criando os registros correspondentes em sua zona hospedada. Entre em contato com o suporte ao cliente do atual provedor de serviço de DNS para obter um *arquivo de zona* ou uma *lista de registros*. Para mais informações sobre o formato exigido do arquivo de zona, consulte [Criar registros importando um arquivo de zona](resource-record-sets-creating-import.md). + **Se a sua configuração DNS atual for mais complexa, e você estiver interessado nos recursos de roteamento do Route 53**: analise a documentação a seguir para ver se deseja usar os recursos do Route 53 que não estão disponíveis em outros provedores de serviço DNS. Se for o caso, você pode criar registros manualmente ou pode importar um arquivo de zona e, em seguida, criar ou atualizar registros posteriormente: + [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md)explica as vantagens dos registros de alias do Route 53, que roteiam o tráfego para alguns AWS recursos, como CloudFront distribuições e buckets do Amazon S3, gratuitamente. + A [Escolher uma política de roteamento](routing-policy.md) explica as opções de roteamento do Route 53, por exemplo, roteamento com base na localização de seus usuários, roteamento com base na latência entre seus usuários e seus recursos, roteamento com base na integridade de seus recursos e roteamento para recursos com base em ponderações especificadas por você. **nota** Você também pode importar um arquivo de zona e depois alterar sua configuração de aproveitar os registros de alias e as políticas de roteamento complexas. Se não for possível obter um arquivo de zona ou se você quiser criar registros manualmente no Route 53, os registros que você vai migrar incluirão o seguinte: + **Registros A (endereço)** — associe um nome de domínio ou nome de subdomínio ao IPv4 endereço (por exemplo, 192.0.2.3) do recurso correspondente + **Registros AAAA (endereço)** — associe um nome de domínio ou nome de subdomínio ao IPv6 endereço (por exemplo, 2001:0 db 8:85 a 3:0000:0000:abcd: 0001:2345) do recurso correspondente + **Mail server (MX) records** (Registros de servidor de e-mail (MX): encaminham tráfego para os servidores de e-mail + **CNAME records** (Registros CNAME): reencaminham o tráfego de um nome de domínio (exemplo.net) para outro nome de domínio (exemplo.com) + **Records for other supported DNS record types** (Registros de outros tipos de registros DNS compatíveis): para obter uma lista de tipos de registros compatíveis, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). ## Etapa 2: criar uma zona hospedada Para informar ao Amazon Route 53 como você quer encaminhar o tráfego para seu domínio, crie uma zona hospedada com o mesmo nome que o seu domínio e, em seguida, crie registros nela. **Importante** Você pode criar uma zona hospedada somente para um domínio que você tenha permissão para administrar. Normalmente, isso significa que você tem o domínio, mas também pode estar desenvolvendo uma aplicação para o proprietário dele. Quando você cria uma zona hospedada, o Route 53 cria automaticamente um registro de servidor de nome (NS) e de início de autoridade (SOA) para a zona. O registro NS identifica os quatro servidores de nome que o Route 53 associou à sua zona hospedada. Para tornar o Route 53 o serviço de DNS do seu domínio, atualize o registro do domínio para usar esses quatro servidores de nome. **Importante** Não crie registros adicionais de NS (servidor de nome) ou SOA (início de autoridade) e não exclua os registros de NS e SOA existentes. **Para criar uma zona hospedada** 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. Se você for novo no Route 53, escolha **Get started** (Conceitos básicos) em **DNS management** (Gerenciamento de DNS) e, depois, escolha **Create hosted zones** (Criar zonas hospedadas). Se já estiver usando o Route 53, escolha **Hosted zones** (Zonas hospedadas) no painel de navegação e escolha **Create hosted zones** (Criar zonas hospedadas). 1. No painel **Create hosted zone** (Criar zona hospedada), insira um nome de domínio e, se preferir, um comentário. Para obter mais informações sobre uma configuração, escolha abrir o painel de ajuda no lado direito. Para obter informações sobre como especificar caracteres que não sejam a-z, 0-9 e - (hífen) e como especificar nomes de domínio internacionalizados, consulte [Formato de nome de domínio DNS](DomainNameFormat.md). 1. Para **Type** (Tipo), aceite o valor padrão da **Public hosted zone** (Zona pública hospedada). 1. Escolha **Create hosted zone** (Criar zona hospedada). ## Etapa 3: criar registros Depois de criar uma zona hospedada, crie registros na zona hospedada que define onde você deseja redirecionar o tráfego para um domínio (exemplo.com) ou subdomínio (www.exemplo.com). Por exemplo, se você deseja encaminhar o tráfego para exemplo.com e www.exemplo.com para um servidor Web em uma instância do Amazon EC2, crie dois registros, um chamado exemplo.com e o outro chamado www.exemplo.com. Em cada registro, especifique o endereço IP para sua instância do EC2. Você pode criar registros em uma série de formas: **Importar um arquivo de zona** Este é o método mais fácil se você tiver um arquivo de zona do seu serviço de DNS atual em [Etapa 1: descobrir a configuração atual do DNS com o provedor de serviço de DNS atual (opcional, mas recomendado)](#migrate-dns-get-zone-file). O Amazon Route 53 não prevê quando deve criar registros de alias ou usar tipos de roteamento especiais, como ponderado ou failover. Como resultado, se você importar um arquivo de zona, o Route 53 cria registros de DNS padrão usando a política de roteamento simples. Para obter mais informações, consulte [Criar registros importando um arquivo de zona](resource-record-sets-creating-import.md). **Criar registros individualmente no console** Se você não obteve o arquivo de zona e apenas deseja criar alguns registros com uma política de roteamento Simples para começar, você pode criar os registros no console do Route 53. Você pode criar registros com alias e sem alias. Para mais informações, consulte os tópicos a seguir: + [Escolher uma política de roteamento](routing-policy.md) + [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md) + [Criar registros usando o console do Amazon Route 53](resource-record-sets-creating.md) **Criar registros de forma programática** Você pode criar registros usando um dos AWS SDKs AWS CLI, o ou AWS Tools for Windows PowerShell. Para obter mais informações, consulte a [Documentação do AWS](https://docs.aws.amazon.com/). Se você estiver usando uma linguagem de programação que AWS não fornece um SDK para, você também pode usar a API do Route 53. Para obter mais informações, consulte [Referência de API do Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/). ## Etapa 4: reduzir as configurações de TTL A configuração de TTL (vida útil) de um registro especifica por quanto tempo você deseja que os resolvedores de DNS armazenem o registro e usem as informações em cache. Quando o TTL expira, um resolvedor envia outra consulta para o provedor de serviço de DNS para um domínio a fim de obter as informações mais recentes. A configuração de TTL típica para o registro de NS é de 172.800 segundos, ou dois dias. O registro de NS lista os servidores de nome que o Sistema de Nomes de Domínio (DNS) pode usar para obter informações sobre como direcionar o tráfego para o seu domínio. Reduzir o TTL do registro de NS, tanto no provedor de serviço DNS atual quanto no Amazon Route 53, reduz o tempo de inatividade do seu domínio quando você descobre um problema durante a migração do DNS para o Route 53. Se você não reduzir o TTL, seu domínio pode ficar indisponível na Internet por até dois dias se algo der errado. **nota** Alguns resolvedores completos podem armazenar em cache o TTL do registro de NS do servidor superior confiável, portanto, o TTL dos registros de NS registrados no servidor DNS confiável também deve ser reduzido. Recomendamos que você altere o TTL nos seguintes registros de NS: + No registro de NS na zona hospedada para o provedor de serviço de DNS atual. (O provedor atual pode usar uma terminologia diferente.) + No registro de NS na zona hospedada que você criou em [Etapa 2: criar uma zona hospedada](#migrate-dns-create-hosted-zone). **Para reduzir a configuração de TTL no registro de NS com o provedor de serviço de DNS atual** + Use o método fornecido pelo provedor de serviço de DNS atual para o domínio a fim de alterar o TTL para o registro de NS na zona hospedada de seu domínio. **Para reduzir a configuração de TTL no registro de NS em uma zona hospedada do Route 53** 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. Escolha **Hosted Zones** (Zonas hospedadas) no painel de navegação. 1. Escolha o nome da zona hospedada. 1. Escolha o registro de NS e escolha **Edit** (Editar). 1. Altere o valor de **TTL (Seconds)** (TTL [segundos]). Recomendamos que você especifique um valor entre 60 segundos e 900 segundos (15 minutos). 1. Escolha **Salvar alterações**. ## Etapa 5: (Se você tiver o DNSSEC configurado) Remova o registro DS da zona pai Se você configurou o DNSSEC para seu domínio, remova o registro DS (Delegation Signer) da zona pai antes de migrar seu domínio para o Route 53. Caso a zona pai esteja hospedada por meio do Route 53 ou de outro registrador, entre em contato com eles para remover o registro DS. Como atualmente não é possível habilitar a assinatura do DNSSEC em dois provedores, você deve remover qualquer DS ou DNSKEYs desativar o DNSSEC. Isso é sinalizado temporariamente para os resolvedores DNS para desabilitar a validação DNSSEC. Na [etapa 11](#migrate-dns-re-enable-dnssec), você poderá reabilitar a validação DNSSEC, se desejar, após a conclusão da transição para o Route 53. Para obter mais informações, consulte [Excluir chaves públicas de um domínio](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys). ## Etapa 6: Aguardar pela expiração do TTL antigo Se seu domínio estiver em uso, por exemplo, se os usuários estiverem usando o nome de domínio para navegar em um site ou acessar uma aplicação Web, os resolvedores DNS terão armazenado em cache os nomes dos servidores de nomes que foram fornecidos por seu provedor de serviço DNS atual. Um resolvedor de DNS que armazenou essas informações em cache alguns minutos atrás irá salvá-los por quase dois dias adicionais. Para garantir que a migração do serviço de DNS para o Route 53 aconteça de uma vez só, aguarde dois dias após reduzir o TTL. Após o TTL de dois dias expirar e os resolvedores solicitarem os servidores de nome para o seu domínio, os resolvedores receberão os servidores de nome atuais e também o novo TTL que você especificou em [Etapa 4: reduzir as configurações de TTL](#migrate-dns-lower-ttl). ## Etapa 7: Atualizar os registros NS para usar servidores de nome do Route 53 Para começar a usar o Amazon Route 53 como o serviço DNS para um domínio, use o método fornecido pelo registrador, ou pela zona pai, para substituir os servidores de nomes atuais no registro NS por servidores de nomes do Route 53. **nota** Ao atualizar o registro NS com o provedor atual de serviços DNS para usar servidores de nomes do Route 53, você está atualizando a configuração de DNS para o domínio. (Isso é comparável a atualizar o registro de NS na zona hospedada do Route 53 para um domínio, exceto que você está atualizando a configuração com o serviço DNS do qual você está migrando.) **Para atualizar o registro NS no registrador ou na zona pai, use os servidores de nome do Route 53** 1. No console do Route 53, obtenha os servidores de nomes de sua zona hospedada: 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 **Zonas hospedadas**. 1. Na página **Hosted zones** (Zonas hospedadas), escolha o nome para a zona hospedada aplicável. 1. Anote os quatro nomes listados para **Name servers** (Servidores de nome) na seção **Hosted zone details** (Detalhes da zona hospedada). 1. Use o método que é fornecido pelo serviço de DNS atual para o domínio, a fim de atualizar o registro de NS para a zona hospedada. Se o domínio estiver registrado no Route 53, consulte [Adicionar ou alterar servidores de nome e registros cola de um domínio](domain-name-servers-glue-records.md). O processo vai depender se o serviço de DNS atual permitir ou não que você exclua os servidores de nome: **Se você pode excluir os servidores de nome** + Anote os nomes dos servidores de nome atuais no registro de NS da zona hospedada. Se precisar reverter para a configuração de DNS atual, esses são os servidores que você especificará. + Exclua os servidores de nome atuais do registro de NS. + Atualize o registro de NS com os nomes de todos os quatro servidores de nome do Route 53 que você obteve na etapa 1 deste procedimento. **nota** Quando você tiver terminado, os únicos servidores de nome no registro de NS serão os quatro servidores de nome do Route 53. **Se você não pode excluir os servidores de nome** + Escolha a opção para usar servidores de nome personalizados. + Adicione todos os quatro servidores de nome do Route 53 que você obteve na etapa 1 deste procedimento. ## Etapa 8: Monitorar o tráfego do domínio Monitore o tráfego do domínio, incluindo o tráfego do site ou da aplicação e do e-mail: + **Se o tráfego diminuir ou for interrompido**: use o método fornecido pelo serviço DNS anterior para alterar os servidores de nomes do domínio de volta para os servidores de nomes anteriores. Esses são os servidores de nome que você anotou na etapa 7 de [Para atualizar o registro NS no registrador ou na zona pai, use os servidores de nome do Route 53](#migrate-dns-change-name-servers-with-provider-procedure). Em seguida, determine o que deu errado. + **Se o tráfego não for afetado**: continue em [Etapa 9: alterar o TTL para o registro de NS de volta para um valor maior](#migrate-dns-change-ttl-back). ## Etapa 9: alterar o TTL para o registro de NS de volta para um valor maior Na zona hospedada do Amazon Route 53 para o domínio, altere o TTL do registro de NS para um valor mais comum. Por exemplo, 172.800 segundos (dois dias). Isso melhora a latência para seus usuários, pois eles não precisam esperar que os resolvedores de DNS enviem uma consulta para os servidores de nome do seu domínio. **Para alterar o TTL para o registro de NS na zona hospedada do Route 53** 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. Escolha **Hosted Zones** (Zonas hospedadas) no painel de navegação. 1. Escolha o nome da zona hospedada. 1. Na lista de registros da zona hospedada, escolha o registro de NS. 1. Selecione **Edit** (Editar). 1. Altere **TTL (Seconds)** (TTL [segundos]) para o número de segundos que você deseja que os resolvedores de DNS armazenem em cache os nomes dos servidores de nome do seu domínio. Recomendamos um valor de 172.800 segundos. 1. Escolha **Salvar alterações**. ## Etapa 10: Transferir o registro de um domínio para o Amazon Route 53 Agora que você transferiu o serviço DNS de um domínio para o Amazon Route 53, existe a opção de transferir o registro desse domínio para o Route 53. Para obter mais informações, consulte [Como transferir registro de um domínio para o Amazon Route 53](domain-transfer-to-route-53.md). ## Etapa 11: Reabilite a assinatura de DNSSEC (se necessário) Agora que você transferiu o serviço DNS de um domínio para o Amazon Route 53, é possível reabilitar a assinatura de DNSSEC. A habilitação da assinatura de DNSSEC tem duas etapas: + Etapa 1: habilite a assinatura DNSSEC para o Route 53 e solicite que o Route 53 crie uma chave de assinatura de chave (KSK) com base em uma chave gerenciada pelo cliente em AWS Key Management Service ().AWS KMS + Etapa 2: Criar uma cadeia de confiança para a zona hospedada adicionando um registro DS (Delegation Signer) à zona pai, para que as respostas DNS possam ser autenticadas com assinaturas criptográficas confiáveis. Para instruções, consulte [Como habilitar a assinatura de DNSSEC e estabelecer uma cadeia de confiança](dns-configuring-dnssec-enable-signing.md). # Tornar o Route 53 o serviço DNS para um domínio inativo Se você quiser migrar o serviço de DNS do Amazon Route 53 para um domínio que não está recebendo nenhum tráfego (ou apresenta muito pouco tráfego), realize os procedimentos nesta seção. **Topics** + [Etapa 1: descobrir a configuração atual do DNS com o provedor de serviço de DNS atual (domínios inativos)](#migrate-dns-get-zone-file-domain-inactive) + [Etapa 2: criar uma zona hospedada (domínios inativos)](#migrate-dns-create-hosted-zone-domain-inactive) + [Etapa 3: criar registros (domínios inativos)](#migrate-dns-create-records-domain-inactive) + [Etapa 4: Atualizar o registro de domínio para usar servidores de nome do Amazon Route 53 (domínios inativos)](#migrate-dns-update-domain-inactive) ## Etapa 1: descobrir a configuração atual do DNS com o provedor de serviço de DNS atual (domínios inativos) Ao migrar o serviço DNS de outro provedor para o Route 53, você reproduz a configuração DNS atual no Route 53. No Route 53, você cria uma zona hospedada que tem o mesmo nome que seu domínio e cria registros nela. Cada registro indica como você deseja direcionar o tráfego para um nome de domínio ou nome de subdomínio especificado. Por exemplo, quando alguém insere seu nome de domínio em um navegador da web, você quer que o tráfego seja roteado para um servidor web em seu data center, para uma instância do Amazon EC2, para CloudFront uma distribuição ou para algum outro local? O processo usado depende da complexidade da sua configuração DNS atual: + **Se sua configuração DNS atual for simples**: se você estiver encaminhando o tráfego da Internet de apenas alguns subdomínios para um pequeno número de recursos, como servidores Web ou buckets do Amazon S3, você poderá criar alguns registros manualmente no console do Route 53. + **Se sua configuração DNS atual for mais complexa e você quiser apenas reproduzir a configuração atual**: você poderá simplificar a migração se puder obter um arquivo de zona do provedor de serviço DNS atual e importar o arquivo de zona no Route 53. (Nem todos os provedores de serviço de DNS disponibilizam os arquivos de zona.) Quando você importa um arquivo de zona, o Route 53 reproduz automaticamente a configuração existente, criando os registros correspondentes em sua zona hospedada. Entre em contato com o suporte ao cliente do atual provedor de serviço de DNS para obter um *arquivo de zona* ou uma *lista de registros*. Para mais informações sobre o formato exigido do arquivo de zona, consulte [Criar registros importando um arquivo de zona](resource-record-sets-creating-import.md). + **Se a sua configuração DNS atual for mais complexa, e você estiver interessado nos recursos de roteamento do Route 53**: analise a documentação a seguir para ver se deseja usar os recursos do Route 53 que não estão disponíveis em outros provedores de serviço DNS. Se for o caso, você pode criar registros manualmente ou pode importar um arquivo de zona e, em seguida, criar ou atualizar registros posteriormente: + [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md)explica as vantagens dos registros de alias do Route 53, que roteiam o tráfego para alguns AWS recursos, como CloudFront distribuições e buckets do Amazon S3, gratuitamente. + A [Escolher uma política de roteamento](routing-policy.md) explica as opções de roteamento do Route 53, por exemplo, roteamento com base na localização de seus usuários, roteamento com base na latência entre seus usuários e seus recursos, roteamento com base na integridade de seus recursos e roteamento para recursos com base em ponderações especificadas por você. **nota** Você também pode importar um arquivo de zona e depois alterar sua configuração de aproveitar os registros de alias e as políticas de roteamento complexas. Se não for possível obter um arquivo de zona ou se você quiser criar registros manualmente no Route 53, os registros que você vai migrar incluirão o seguinte: + **Registros A (endereço)** — associe um nome de domínio ou nome de subdomínio ao IPv4 endereço (por exemplo, 192.0.2.3) do recurso correspondente + **Registros AAAA (endereço)** — associe um nome de domínio ou nome de subdomínio ao IPv6 endereço (por exemplo, 2001:0 db 8:85 a 3:0000:0000:abcd: 0001:2345) do recurso correspondente + **Mail server (MX) records** (Registros de servidor de e-mail (MX): encaminham tráfego para os servidores de e-mail + **CNAME records** (Registros CNAME): reencaminham o tráfego de um nome de domínio (exemplo.net) para outro nome de domínio (exemplo.com) + **Records for other supported DNS record types** (Registros de outros tipos de registros DNS compatíveis): para obter uma lista de tipos de registros compatíveis, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). ## Etapa 2: criar uma zona hospedada (domínios inativos) Para informar ao Amazon Route 53 como você quer encaminhar o tráfego para seu domínio, crie uma zona hospedada com o mesmo nome que o seu domínio e, em seguida, crie registros nela. **Importante** Você pode criar uma zona hospedada somente para um domínio que você tenha permissão para administrar. Normalmente, isso significa que você tem o domínio, mas também pode estar desenvolvendo uma aplicação para o proprietário dele. Quando você cria uma zona hospedada, o Route 53 cria automaticamente um registro de servidor de nome (NS) e de início de autoridade (SOA) para a zona. O registro NS identifica os quatro servidores de nome que o Route 53 associou à sua zona hospedada. Para tornar o Route 53 o serviço de DNS do seu domínio, atualize o registro do domínio para usar esses quatro servidores de nome. **Importante** Não crie registros adicionais de NS (servidor de nome) ou SOA (início de autoridade) e não exclua os registros de NS e SOA existentes. **Para criar uma zona hospedada** 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. Se você for novo no Route 53, escolha **Get started** (Conceitos básicos). Se você já estiver usando o Route 53, escolha **Hosted zones** (Zonas hospedadas) no painel de navegação. 1. Escolha **Create hosted zone** (Criar zona hospedada). 1. No painel **Create hosted zone** (Criar zona hospedada), insira um nome de domínio e, se preferir, um comentário. Para obter mais informações sobre uma configuração, deixe o ponteiro do mouse sobre o rótulo para ver uma dica de ferramenta. Para obter informações sobre como especificar caracteres que não sejam a-z, 0-9 e - (hífen) e como especificar nomes de domínio internacionalizados, consulte [Formato de nome de domínio DNS](DomainNameFormat.md). 1. Para **Record type** (Tipo de registro), aceite o valor padrão da **Public hosted zone** (Zona hospedada pública). 1. Escolha **Create hosted zone** (Criar zona hospedada). ## Etapa 3: criar registros (domínios inativos) Depois de criar uma zona hospedada, crie registros na zona hospedada que define onde você deseja redirecionar o tráfego para um domínio (exemplo.com) ou subdomínio (www.exemplo.com). Por exemplo, se você deseja encaminhar o tráfego para exemplo.com e www.exemplo.com para um servidor Web em uma instância do Amazon EC2, crie dois registros, um chamado exemplo.com e o outro chamado www.exemplo.com. Em cada registro, especifique o endereço IP para sua instância do EC2. Você pode criar registros em uma série de formas: **Importar um arquivo de zona** Este é o método mais fácil se você tiver um arquivo de zona do seu serviço de DNS atual em [Etapa 1: descobrir a configuração atual do DNS com o provedor de serviço de DNS atual (domínios inativos)](#migrate-dns-get-zone-file-domain-inactive). O Amazon Route 53 não prevê quando deve criar registros de alias ou usar tipos de roteamento especiais, como ponderado ou failover. Como resultado, se você importar um arquivo de zona, o Route 53 cria registros de DNS padrão usando a política de roteamento simples. Para obter mais informações, consulte [Criar registros importando um arquivo de zona](resource-record-sets-creating-import.md). **Criar registros individualmente no console** Se você não obteve o arquivo de zona e apenas deseja criar alguns registros com uma política de roteamento Simples para começar, você pode criar os registros no console do Route 53. Você pode criar registros com alias e sem alias. Para mais informações, consulte os tópicos a seguir: + [Escolher uma política de roteamento](routing-policy.md) + [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md) + [Criar registros usando o console do Amazon Route 53](resource-record-sets-creating.md) **Criar registros de forma programática** Você pode criar registros usando um dos AWS SDKs AWS CLI, o ou AWS Tools for Windows PowerShell. Para obter mais informações, consulte a [Documentação do AWS](https://docs.aws.amazon.com/). Se você estiver usando uma linguagem de programação que AWS não fornece um SDK para, você também pode usar a API do Route 53. Para obter mais informações, consulte [Referência de API do Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/). ## Etapa 4: Atualizar o registro de domínio para usar servidores de nome do Amazon Route 53 (domínios inativos) Após a criação dos registros para o domínio, você pode alterar o serviço de DNS do seu domínio para o Amazon Route 53. Execute o seguinte procedimento para atualizar as configurações com o registrador de domínio. **Para atualizar os servidores de nome para o domínio** 1. No console do Route 53, obtenha os servidores de nome para sua zona hospedada do Route 53: 1. 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 **Zonas hospedadas**. 1. Na página **Hosted zones** (Zonas hospedadas), escolha o botão de opção (não o nome) da zona hospedada, depois escolha **View details** (Exibir detalhes). 1. Na página de detalhes da zona hospedada, escolha **Hosted zone details** (Detalhes da zona hospedada). 1. Anote os quatro servidores listados para **Name servers** (Servidores de nome). 1. Use o método fornecido pelo registrador para o domínio a fim de alterar os servidores de nome para o domínio usar os quatro servidores de nome do Route 53 que você obteve na etapa 2 deste procedimento. Se o domínio estiver registrado no Route 53, consulte [Adicionar ou alterar servidores de nome e registros cola de um domínio](domain-name-servers-glue-records.md). # Configurar o roteamento de DNS para um novo domínio **Um novo domínio que você comprou do Route 53** Ao registrar um domínio com o Route 53, nós automaticamente tornamos o Route 53 o serviço DNS do domínio. O Route 53 cria uma zona hospedada com o mesmo nome do domínio, atribui quatro servidores de nomes à zona hospedada e atualiza o domínio para usar esses servidores de nomes. **Um novo domínio que você comprou de outro registrador** Quando você compra um domínio de outro registrador, por exemplo, porque o domínio de primeiro nível (TLD) não é oferecido pelo Route 53, existem duas opções: + **Usar o Route 53 apenas para hospedagem de DNS:** mantenha seu registrador atual, mas delegue o gerenciamento de DNS ao Route 53. Siga o procedimento abaixo para criar uma zona hospedada e atualizar os servidores de nomes do seu registrador. + **Transfira o registro do domínio para o Route 53:** faça do Route 53 seu registrador e serviço de DNS. Consulte [Lista de verificação pré-transferência para transferências de domínios](domain-transfer-checklist.md) para pré-requisitos e [Como transferir registro de um domínio para o Amazon Route 53](domain-transfer-to-route-53.md) para o processo de transferência. Para obter mais informações sobre os TLDs compatíveis com o Route 53, consulte [Domínios que você pode registrar com o Amazon Route 53](registrar-tld-list.md). Siga estas instruções para criar uma zona hospedada pública e, em seguida, use os servidores de nomes criados com o registrador: **Para criar uma zona hospedada para um domínio que não seja o Route 53** 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 **Zonas hospedadas** e, em seguida, escolha **Criar zona hospedada**. 1. Em **Nome**, insira o nome do domínio para o qual você deseja criar uma zona hospedada, como `example.com`, uma descrição opcional, escolha **Zona hospedada pública** e, em seguida, **Criar zona hospedada**. 1. Depois de criar a zona hospedada, crie um registro para resolver o nome de domínio personalizado privado. Cada um começará com “ns-”. No registrador do seu domínio, insira os servidores de nomes acima para delegar o gerenciamento do domínio à sua zona hospedada do Route 53. **Rotear tráfego de DNS** Para especificar como você quer que o Route 53 encaminhe o tráfego da Internet para o domínio, crie registros na zona hospedada. Por exemplo, se você quiser encaminhar solicitações de example.com para um servidor da Web que é executado em uma instância do Amazon EC2, crie um registro na zona hospedada de example.com e especifique o endereço de IP elástico para a instância do EC2. Para obter mais informações, consulte os tópicos a seguir. + Para obter informações sobre como criar registros na sua zona hospedada, consulte [Trabalhar com registros](rrsets-working-with.md). + Para obter informações sobre como encaminhar o tráfego para recursos selecionados da AWS, consulte [Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). + Para informações sobre como o DNS funciona, consulte [Como o tráfego da Internet é roteado para seu site ou o aplicativo web](welcome-dns-service.md). + Para verificar a resposta de DNS, consulte [Verificar respostas do Route 53 ao DNS](dns-test.md). # Rotear tráfego para seus recursos Quando os usuários solicitam seu site ou aplicação Web, por exemplo, inserindo o nome de seu domínio em um navegador da Web, o Amazon Route 53 ajuda a encaminhar os usuários para seus recursos, como um bucket do Amazon S3 ou um servidor da Web em seu data center. Se você quiser configurar o Route 53 para encaminhar o tráfego para os seus recursos, faça o seguinte: 1. Crie uma zona hospedada. Você pode criar uma zona hospedada pública ou privada: **Zona hospedada pública** Crie uma zona hospedada pública se você quiser direcionar o tráfego da Internet para os seus recursos, por exemplo, para que seus clientes possam visualizar o site da empresa que você está hospedando nas instâncias do EC2. Para obter mais informações, consulte [Trabalhar com zonas hospedadas públicas](AboutHZWorkingWith.md). **Zonas hospedadas privadas** Crie uma zona hospedada privada se você quiser encaminhar o tráfego dentro de uma Amazon VPC. Para obter mais informações, consulte [Trabalhar com zonas hospedadas privadas](hosted-zones-private.md). 1. Crie registros na zona hospedada. Os registros definem onde você quer rotear o tráfego para cada nome de domínio ou de subdomínio. Por exemplo, para rotear o tráfego de www.example.com para um servidor da web no seu data center, você pode criar um registro www.example.com na zona hospedada example.com. Para saber mais, consulte os seguintes tópicos: + [Trabalhar com registros](rrsets-working-with.md) + [Rotear tráfego para subdomínios](dns-routing-traffic-for-subdomains.md) + [Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md) # Rotear tráfego para subdomínios Quando quiser rotear o tráfego para recursos de um subdomínio, como acme.example.com ou zenith.example.com, você terá duas opções: **Criar registros na zona hospedada para o domínio** Normalmente, para rotear o tráfego de um subdomínio, você cria um registro na zona hospedada com o mesmo nome do domínio. Por exemplo, para rotear o tráfego da Internet de acme.example.com para um servidor da web no seu data center, crie um registro denominado acme.example.com na zona hospedada example.com. Para obter mais informações, consulte o tópico [Trabalhar com registros](rrsets-working-with.md) e seus subtópicos. **Criar uma zona hospedada para o subdomínio e registros na nova zona hospedada** Você também pode criar uma zona hospedada para o subdomínio. O uso de uma zona hospedada separada para rotear o tráfego da Internet para um subdomínio às vezes é chamado de "delegar a responsabilidade por um subdomínio a uma zona hospedada" ou "delegar um subdomínio a outros servidores de nome" ou alguma combinação semelhante de termos. Esta é uma visão geral de como isso funciona: 1. Crie uma zona hospedada que tenha o mesmo nome que o subdomínio para o qual você deseja rotear o tráfego, como acme.example.com. 1. Depois, crie registros na nova zona hospedada que definam como você quer rotear o tráfego para o subdomínio (acme.example.com) e seus subdomínios, como backend.acme.example.com. 1. Você obterá os servidores de nomes que o Route 53 atribuiu à nova zona hospedada quando você a criou. 1. Você cria um novo registro NS na zona hospedada para o domínio (exemplo.com). O nome do registro NS deve ser o nome do subdomínio (acme.example.com) e você especifica os quatro servidores de nomes que você obteve na etapa 3 como os valores do registro. Quando você usa uma zona hospedada separada para rotear tráfego para um subdomínio, pode usar as permissões do IAM para restringir o acesso à zona hospedada dele. Se você tiver vários subdomínios gerenciados por grupos diferentes, a criação de uma zona hospedada para cada subdomínio pode reduzir significativamente o número de pessoas que precisam ter acesso a registros na zona hospedada para o domínio. Para implementar esse processo de delegação, você precisa das seguintes permissões do IAM. Para obter mais informações sobre as políticas do IAM do Route 53, consulte[Gerenciamento de identidade e acesso no Amazon Route 53](security-iam.md): **Conta principal (possui example.com)** O usuário ou a função precisam de permissões para modificar registros na zona hospedada do domínio principal: **Conta infantil (cria acme.example.com)** O usuário ou a função precisam de permissões para criar e gerenciar a zona hospedada do subdomínio: O uso de uma zona hospedada separada para um subdomínio também permite que você use diferentes serviços de DNS para o domínio e o subdomínio. Para obter mais informações, consulte [Como usar o Amazon Route 53 como o serviço DNS dos subdomínios sem migrar o domínio pai](creating-migrating.md). Há um pequeno impacto na performance com essa configuração na primeira consulta DNS de cada resolvedor de DNS. O resolvedor precisa obter informações da zona hospedada para o domínio raiz e, em seguida, informações da zona hospedada para o subdomínio. Após a primeira consulta DNS em um subdomínio, o resolvedor armazena em cache as informações e não precisa obtê-las novamente até que o TTL expire e outro cliente solicite o subdomínio desse resolvedor. Para obter mais informações, consulte [TTL (segundos)](resource-record-sets-values-basic.md#rrsets-values-basic-ttl) na seção [Valores que você especifica ao criar ou editar registros do Amazon Route 53](resource-record-sets-values.md). **Topics** + [Criar outra zona hospedada para rotear o tráfego de um subdomínio](#dns-routing-traffic-for-subdomains-new-hosted-zone) + [Rotear tráfego para níveis adicionais de subdomínios](#dns-routing-traffic-for-sub-subdomains) ## Criar outra zona hospedada para rotear o tráfego de um subdomínio Uma maneira de rotear o tráfego para um subdomínio é criar uma zona hospedada para o subdomínio e criar registros para o subdomínio na nova zona hospedada. (A opção mais comum é criar registros para o subdomínio na zona hospedada do domínio.) **nota** Este procedimento mostra como delegar um subdomínio ao Route 53. Você também pode delegar um subdomínio a outros serviços DNS criando registros NS que apontem para os servidores de nomes desses serviços. Aqui está uma visão geral do processo: 1. Crie uma zona hospedada do para o subdomínio. Para obter mais informações, consulte [Criar uma nova zona hospedada para um subdomínio](#dns-routing-traffic-for-subdomains-creating-hosted-zone). 1. Adicione registros à zona hospedada para o subdomínio. Se a zona hospedada do domínio contiver algum registro que pertence à zona hospedada do subdomínio, duplique esses registros na zona hospedada do subdomínio. Para obter mais informações, consulte [Criar registros na zona hospedada do subdomínio](#dns-routing-traffic-for-subdomains-creating-records) 1. Crie um registro NS para o subdomínio na zona hospedada do domínio, que delega a responsabilidade pelo subdomínio aos servidores de nome na nova zona hospedada. Se a zona hospedada do domínio contiver algum registro que pertence à zona hospedada do subdomínio, exclua os registros da zona hospedada do domínio. (Você criou cópias na zona hospedada do subdomínio na etapa 2.) Para obter mais informações, consulte [Atualizar a zona hospedada do domínio](#dns-routing-traffic-for-subdomains-delegating-responsibility). ### Criar uma nova zona hospedada para um subdomínio Para criar uma zona hospedada para um subdomínio usando o console do Route 53, execute o seguinte procedimento. **Para criar uma zona hospedada para um subdomínio (console)** 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. Se você for novo no Route 53, escolha **Get started** (Conceitos básicos). Se você já estiver usando o Route 53, escolha **Hosted zones** (Zonas hospedadas) no painel de navegação. 1. Escolha **Create hosted zone** (Criar zona hospedada). 1. No painel direito, insira o nome do subdomínio, como acme.example.com. Se preferir, você também pode inserir um comentário. Para obter informações sobre como especificar caracteres que não sejam a-z, 0-9 e - (hífen) e como especificar nomes de domínio internacionalizados, consulte [Formato de nome de domínio DNS](DomainNameFormat.md). 1. Para **Type** (Tipo), aceite o valor padrão da **Public hosted zone** (Zona pública hospedada). 1. Na parte inferior do painel à direita, escolha **Create hosted zone** (Criar zona hospedada). ### Criar registros na zona hospedada do subdomínio Para definir como você quer que o Route 53 encaminhe o tráfego para o subdomínio (acme.example.com) e seus subdomínios (backend.acme.example.com), crie registros na zona hospedada do subdomínio. Observe o seguinte sobre como criar registros na zona hospedada do subdomínio: + Não crie registros de NS (servidor de nome) ou SOA (início de autoridade) adicionais na zona hospedada do subdomínio nem exclua os registros de NS e SOA existentes. + Crie todos os registros do subdomínio na zona hospedada dele. Por exemplo, se você tiver zonas hospedadas dos domínios example.com e acme.example.com, crie todos os registros do subdomínio acme.example.com na zona hospedada de acme.example.com. Isso inclui registros como backend.acme.example.com e beta.backend.acme.example.com. + Se a zona hospedada do domínio (example.com) já contiver registros que pertencem à zona hospedada do subdomínio (acme.example.com), duplique esses registros na zona hospedada do subdomínio. Na última etapa do processo, exclua os registros duplicados da zona hospedada do domínio mais tarde. **Importante** Se você tiver alguns registros do subdomínio nas zonas hospedadas do domínio e do subdomínio, o comportamento do DNS será inconsistente. O comportamento dependerá de quais servidores de nome um resolvedor de DNS possui em cache, dos servidores de nome da zona hospedada do domínio (example.com) ou dos servidores de nome da zona hospedada do subdomínio (acme.example.com). Em alguns casos, o Route 53 retornará NXDOMAIN (domínio inexistente) quando o registro existir, mas não na zona hospedada à qual os resolvedores de DNS estão enviando a consulta. Para obter mais informações, consulte [Trabalhar com registros](rrsets-working-with.md). ### Atualizar a zona hospedada do domínio Quando você cria uma zona hospedada, o Route 53 atribui automaticamente quatro servidores de nome à zona. O registro NS de uma zona hospedada identifica os servidores de nome que respondem às consultas DNS do domínio ou do subdomínio. Para começar a usar os registros na zona hospedada do subdomínio e rotear o tráfego da Internet, crie um novo registro NS na zona hospedada do domínio (example.com) e atribua a ele o nome do subdomínio (acme.example.com). Para o valor do registro NS, especifique os nomes dos servidores de nome da zona hospedada do subdomínio. Veja o que acontece quando o Route 53 recebe uma consulta DNS de um resolvedor DNS para o subdomínio acme.example.com ou um dos seus subdomínios: 1. O Route 53 procura o domínio (example.com) na zona hospedada e localiza o registro NS para o subdomínio (acme.example.com). 1. O Route 53 obtém os servidores de nome do registro NS acme.example.com na zona hospedada do domínio, example.com, e retorna esses servidores de nome para o resolvedor de DNS. 1. O resolvedor de reenvia a consulta de acme.example.com aos servidores de nome da zona hospedada acme.example.com. 1. O Route 53 responde à consulta usando um registro na zona hospedada acme.example.com. Para configurar o Route 53 para encaminhar o tráfego para o subdomínio usando a zona hospedada do subdomínio e excluir todos os registros duplicados da zona hospedada do domínio, realize o procedimento a seguir: **Para configurar o Route 53 para usar a zona hospedada do subdomínio (console)** 1. No console do Route 53, veja os servidores de nome para a zona hospedada do subdomínio: 1. No painel de navegação, escolha **Zonas hospedadas**. 1. Na página **Hosted zones** (Zonas hospedadas), escolha o nome para a zona hospedada do subdomínio. 1. No painel direito, copie os nomes dos quatro servidores listados para **Name servers** (Servidores de nome) na seção **Hosted zones details** (Detalhes das zonas hospedadas). 1. Escolha o nome da zona hospedada para o domínio (example.com), não para o subdomínio. 1. Escolha **Create record** (Criar registro). 1. Escolha **Simple routing** (Roteamento simples) e **Next** (Próximo). 1. Escolha **Define simple record (Definir registro simples)**. 1. Especifique os seguintes valores: **Nome** Insira o nome do subdomínio (por exemplo,`acme.example.com`). Isso deve corresponder exatamente ao nome da zona hospedada do subdomínio que você criou. **Valor/Encaminhar tráfego para** Escolha **endereço IP ou outro valor dependendo do tipo de registro** e cole os nomes dos servidores de nome que você copiou na etapa 1. **Tipo de registro** Escolha **NS – Name servers for a hosted zone** (NS: servidores de nome para uma zona hospedada). **TTL (segundos)** Altere para um valor mais comum para um registro NS, como 172.800 segundos. 1. Selecione **Define simple record** (Definir registro simples) e escolha **Create records** (Criar registros). 1. Se a zona hospedada do domínio contiver algum registro que você recriou na zona hospedada do subdomínio, exclua esses registros da zona hospedada do domínio. Para obter mais informações, consulte [Excluir registros](resource-record-sets-deleting.md). Quando terminar, todos os registros do subdomínio deverão estar na zona hospedada do subdomínio. ## Rotear tráfego para níveis adicionais de subdomínios Direcione o tráfego para o subdomínio de um subdomínio, como backend.acme.example.com, da mesma forma que você direciona o tráfego para um subdomínio, como acme.example.com. Crie registros na zona hospedada do domínio ou uma zona hospedada para o subdomínio de nível inferior e, em seguida, crie registros nessa nova zona hospedada. Se você optar por criar uma zona hospedada para o subdomínio de nível inferior, crie o registro de NS para o subdomínio de nível inferior na zona hospedada para o subdomínio que está um nível mais próximo do nome de domínio. Isso ajuda a garantir que o tráfego seja roteado corretamente para os recursos. Por exemplo, suponhamos que você queira rotear o tráfego para os seguintes subdomínios: + subdomain1.example.com + subdomain2.subdomain1.example.com Se você quiser usar outra zona hospedada para rotear o tráfego para subdomínio2.subdomínio1.example.com, faça o seguinte: 1. Crie uma zona hospedada chamada subdomain2.subdomain1.example.com. 1. Crie registros na zona hospedada subdomain2.subdomain1.example.com. Para obter mais informações, consulte [Criar registros na zona hospedada do subdomínio](#dns-routing-traffic-for-subdomains-creating-records). 1. Copie os nomes dos servidores de nome para a zona hospedada subdomain2.subdomain1.example.com. 1. Na zona hospedada subdomain1.example.com, crie um registro NS denominado subdomain2.subdomain1.example.com e cole os nomes dos servidores de nome da zona hospedada subdomain2.subdomain1.example.com. Além disso, exclua todos os registros duplicados de subdomain1.example.com. Para obter mais informações, consulte [Atualizar a zona hospedada do domínio](#dns-routing-traffic-for-subdomains-delegating-responsibility). Depois de criar este registro NS, o Route 53 começa a usar a zona hospedada subdomain2.subdomain1.example.com para encaminhar o tráfego para o subdomínio subdomain2.subdomain1.example.com. # Trabalhar com zonas hospedadas Uma zona hospedada é um contêiner para registros, e os registros contêm informações sobre como você quer rotear o tráfego para um domínio específico, como example.com e seus subdomínios (apex.example.com, acme.example.com). Uma zona hospedada e o domínio correspondente têm o mesmo nome. Há dois tipos de zonas hospedadas: + *Zonas hospedadas públicas* contém registros que especificam a forma como você quer rotear o tráfego na Internet. Para obter mais informações, consulte [Trabalhar com zonas hospedadas públicas](AboutHZWorkingWith.md). + *Zonas hospedadas privadas* contém registros que especificam a forma como você quer rotear o tráfego na Amazon VPC. Para obter mais informações, consulte [Trabalhar com zonas hospedadas privadas](hosted-zones-private.md). # Trabalhar com zonas hospedadas públicas Uma zona hospedada pública é um contêiner que armazena informações sobre como você deseja rotear o tráfego de um domínio específico (como example.com) e subdomínios (como acme.example.com, zenith.example.com) na Internet. Você recebe uma zona hospedada pública de duas maneiras: + Quando você registra um domínio com o Route 53, nós criamos automaticamente uma zona hospedada para você. + Ao transferir o serviço DNS de um domínio existente para o Route 53, comece criando uma zona hospedada para o domínio. Para obter mais informações, consulte [Como transformar o Amazon Route 53 no serviço de DNS para um domínio existenteComo transformar o Route 53 no serviço de DNS para um domínio existente](MigratingDNS.md). Em ambos os casos, você cria registros na zona hospedada para especificar a maneira como deseja rotear o tráfego para o domínio e os subdomínios. Por exemplo, você pode criar um registro para rotear o tráfego de www.exemplo.com para uma CloudFront distribuição ou para um servidor web em seu data center. Para obter mais informações sobre registros de , consulte [Trabalhar com registros](rrsets-working-with.md). Este tópico explica como usar o console do Amazon Route 53 para criar, listar e excluir zonas hospedadas públicas. **nota** Você também pode usar uma zona hospedada *privada* do Route 53 para rotear o tráfego dentro de uma ou mais VPCs zonas criadas por você com o serviço Amazon VPC. Para obter mais informações, consulte [Trabalhar com zonas hospedadas privadas](hosted-zones-private.md). **Topics** + [Considerações ao trabalhar com zonas hospedadas públicas](hosted-zone-public-considerations.md) + [Criar uma zona hospedada pública](CreatingHostedZone.md) + [Obter os servidores de nome de uma zona hospedada pública](GetInfoAboutHostedZone.md) + [Listar zonas hospedadas públicas](ListInfoOnHostedZone.md) + [Visualizar métricas de consulta de DNS para uma zona hospedada pública](hosted-zone-public-viewing-query-metrics.md) + [Excluir uma zona hospedada pública](DeleteHostedZone.md) + [Verificar respostas do Route 53 ao DNS](dns-test.md) + [Configurar servidores de nome de rótulo branco](white-label-name-servers.md) + [Registros de NS e SOA que o Amazon Route 53 cria para uma zona hospedada pública](SOA-NSrecords.md) + [Habilitando a recuperação acelerada para gerenciar registros públicos de DNS](accelerated-recovery.md) # Considerações ao trabalhar com zonas hospedadas públicas Veja as seguintes considerações ao trabalhar com zonas hospedadas públicas: **Registros de NS e SOA** Quando você cria uma zona hospedada, o Amazon Route 53 cria automaticamente um registro de servidor de nome (NS) e de início de autoridade (SOA) para a zona. O registro de NS identifica os quatro servidores de nome que você fornece ao seu registrador ou ao serviço DNS, de maneira que as consultas de DNS sejam encaminhadas aos servidores de nome do Route 53. Para obter mais informações sobre registros de NS e SOA, consulte [Registros de NS e SOA que o Amazon Route 53 cria para uma zona hospedada pública](SOA-NSrecords.md). **Várias zonas hospedadas que possuem o mesmo nome** Você pode criar mais de uma zona hospedada com o mesmo nome e adicionar diferentes registros a cada zona hospedada. O Route 53 atribui quatro servidores de nome a cada zona hospedada, e os servidores de nome são diferentes para cada uma delas. Ao atualizar os registros de servidor de nome do registrador, tome cuidado para usar os servidores de nome do Route 53 para a zona hospedada correta, isto é, aquela que contém os registros que você quer que o Route 53 use ao responder às consultas do seu domínio. O Route 53 nunca retorna valores para registros em outras zonas hospedadas que têm o mesmo nome. **Conjuntos de delegações reutilizáveis** Por padrão, o Route 53 atribui um conjunto exclusivo de quatro servidores de nome (conhecido coletivamente como um conjunto de delegações) a cada zona hospedada que você cria. Se quiser criar um grande número de zonas hospedadas, você poderá criar um conjunto de delegações reutilizáveis de maneira programática. (Conjuntos de delegação reutilizáveis ​​não estão disponíveis no console do Route 53.) Em seguida, você pode criar zonas hospedadas de forma programada e atribuir o mesmo conjunto de delegações reutilizáveis, os mesmos quatro servidores de nome, a cada zona hospedada. Os conjuntos de delegações reutilizáveis simplificam a migração do serviço DNS para o Route 53 porque você pode instruir o registrador do nome do domínio a usar os mesmos quatro servidores de nome para todos os domínios para os quais você quer usar o Route 53 como o serviço DNS. Para obter mais informações, consulte [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)a *Referência de API do Amazon Route 53*. # Criar uma zona hospedada pública Uma zona hospedada pública é um contêiner que armazena informações sobre como você deseja rotear o tráfego de um domínio específico (como example.com) e subdomínios (como acme.example.com, zenith.example.com) na Internet. Depois de criar uma zona hospedada, você cria registros que especificam a maneira como deseja rotear o tráfego para o domínio e os subdomínios. **Restrições** Observe as seguintes restrições para criar zonas hospedadas com o Route 53. Você pode criar uma zona hospedada somente para um domínio que você tenha permissão para administrar. Normalmente, isso significa que você tem o domínio, mas também pode estar desenvolvendo uma aplicação para o proprietário dele. É possível criar zonas hospedadas apenas para domínios e subdomínios. O Route 53 não tem suporte para a hospedagem de domínios de primeiro nível (TLD), como `.com`. **Para criar uma zona hospedada pública usando o console do Route 53** 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. Se você for novo no Route 53, escolha **Get started** (Conceitos básicos) em **DNS Management** (Gerenciamento de DNS). Se você já estiver usando o Route 53, escolha **Hosted zones** (Zonas hospedadas) no painel de navegação. 1. Escolha **Create hosted zone** (Criar zona hospedada). 1. No painel **Create Hosted Zone (Criar zona hospedada)**, insira o nome do domínio para o qual você deseja rotear o tráfego. Se preferir, você também pode inserir um comentário. Para obter informações sobre como especificar caracteres que não sejam a-z, 0-9 e - (hífen) e como especificar nomes de domínio internacionalizados, consulte [Formato de nome de domínio DNS](DomainNameFormat.md). 1. Para **Type**, aceite o valor padrão da **Public Hosted Zone**. 1. Escolha **Criar**. 1. Crie registros que especificam a maneira como você deseja rotear o tráfego para o domínio e os subdomínios. Para obter mais informações, consulte [Trabalhar com registros](rrsets-working-with.md). 1. Para usar registros na nova zona hospedada para rotear o tráfego de seu domínio, consulte o tópico aplicável: + Se estiver tornando o Route 53 o serviço DNS de um domínio registrado em outro registrador de domínios, consulte [Como transformar o Amazon Route 53 no serviço de DNS para um domínio existenteComo transformar o Route 53 no serviço de DNS para um domínio existente](MigratingDNS.md). + Se o domínio estiver registrado no Route 53, consulte [Adicionar ou alterar servidores de nome e registros cola de um domínio](domain-name-servers-glue-records.md). # Obter os servidores de nome de uma zona hospedada pública Obtenha os servidores de nome para uma zona hospedada pública se desejar alterar o serviço de DNS para o registro de domínio. Para obter informações sobre como alterar o serviço de DNS, consulte [Como transformar o Amazon Route 53 no serviço de DNS para um domínio existenteComo transformar o Route 53 no serviço de DNS para um domínio existente](MigratingDNS.md). **nota** Alguns registradores só permitem que você especifique servidores de nome usando endereços IP; eles não permitem que você especifique nomes de domínio totalmente qualificados. Se o seu registrador requer o uso de endereços IP, você pode obter os endereços IP para os seus servidores de nome usando o utilitário dig (para Mac, Unix ou Linux) ou o utilitário nslookup (para Windows). Raramente alteramos os endereços IP de servidores de nome; se precisarmos alterar endereços IP, você será notificado com antecedência. **Para obter os servidores de nome de uma zona hospedada usando o console do Route 53** 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, clique em **Hosted zones** (Zonas hospedadas). 1. Na página **Hosted zones** (Zonas hospedadas), escolha o botão de opção (não o nome) da zona hospedada, depois escolha **View details** (Exibir detalhes). 1. Na página de detalhes da zona hospedada, escolha **Hosted zone details** (Detalhes da zona hospedada). 1. Anote os quatro servidores listados para **Name servers** (Servidores de nome). # Listar zonas hospedadas públicas Você pode usar o console do Amazon Route 53 para listar todas as zonas hospedadas que você criou com a AWS conta atual. Para obter informações sobre como listar zonas hospedadas usando a API do Route 53, consulte [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)a *Referência da API do Amazon Route 53*. **Para listar as zonas hospedadas públicas associadas a uma AWS conta usando o console do Route 53** 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 **Zonas hospedadas**. A página exibe uma lista das zonas hospedadas associadas à AWS conta com a qual você está conectado no momento. 1. Para filtrar zonas hospedadas, use a barra de pesquisa localizada na parte superior da tabela. O comportamento de pesquisa variará quando a zona hospedada tiver até 2 mil registros e mais de 2 mil registros: **Até 2 mil zonas hospedadas** + Para exibir os registros que têm valores específicos, clique na barra de pesquisa, escolha uma propriedade na lista suspensa e insira um valor. Também é possível inserir um valor diretamente na barra de pesquisa e pressionar Enter. Por exemplo, para exibir as zonas hospedadas que têm um nome começando com **abc**, insira esse valor na barra de pesquisa e pressione Enter. + Para exibir somente as zonas hospedadas que têm o mesmo tipo de zona hospedada, selecione o tipo na lista suspensa e insira o tipo. **Mais de 2 mil zonas hospedadas** + Você pode pesquisar propriedades com base no nome de domínio exato, todas as propriedades e tipo. + Pesquise usando o nome de domínio exato para obter resultados de pesquisa mais rápidos. # Visualizar métricas de consulta de DNS para uma zona hospedada pública Você pode visualizar o número total de consultas de DNS que o Route 53 está respondendo para uma zona hospedada pública especificada ou uma combinação de zonas hospedadas públicas. As métricas aparecem em CloudWatch, o que permite que você visualize um gráfico, escolha o período de tempo que deseja visualizar e personalize as métricas de várias outras maneiras. Você também pode criar alarmes e configurar notificações, para que possa ser notificado quando o número de consultas de DNS em um período especificado ficar acima ou abaixo de um nível especificado. **nota** O Route 53 envia automaticamente o número de consultas de DNS CloudWatch para todas as zonas hospedadas públicas, para que você não precise configurar nada antes de visualizar as métricas da consulta. As métricas de consulta de DNS não são cobradas. **Que consultas de DNS são contabilizadas?** As métricas incluem apenas as consultas que os resolvedores de DNS encaminham ao Route 53. Se o resolvedor de DNS já tiver armazenado em cache a resposta a uma consulta (como o endereço IP de um balanceador de carga para example.com), o resolvedor continuará retornando a resposta armazenada em cache sem encaminhar a consulta para o Route 53 até que o TTL do registro correspondente expire. Dependendo da quantidade de consultas de DNS enviadas para um nome de domínio (example.com) ou nome de subdomínio (www.example.com), de quais resolvedores seus usuários estão usando e do TTL do registro, as métricas de consulta de DNS podem conter informações apenas sobre uma das milhares de consultas que são enviadas aos resolvedores de DNS. Para mais informações sobre como o DNS funciona, consulte [Como o Amazon Route 53 encaminha tráfego para o seu domínio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). **Quando as métricas de consulta para uma zona hospedada começam a ser exibidas no CloudWatch?** Depois de criar uma zona hospedada, poderá levar várias horas para que a zona hospedada seja exibida no CloudWatch. Além disso, você deverá enviar uma consulta de DNS para um registro na zona hospedada para que haja dados a serem exibidos. **As métricas estão disponíveis somente no Leste dos EUA (Norte da Virgínia)** Para obter métricas no console, você deve escolher Leste dos EUA (Norte da Virgínia) para a região. Para obter métricas usando a AWS CLI, você deve deixar a AWS região não especificada ou especificar `us-east-1` como a região. As métricas do Route 53 não estarão disponíveis se você escolher qualquer outra região. **CloudWatch métrica e dimensão para consultas de DNS** Para obter informações sobre a CloudWatch métrica e a dimensão das consultas de DNS, consulte. [Monitoramento de zonas hospedadas usando a Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md) Para obter informações sobre CloudWatch métricas, consulte [Usando CloudWatch métricas da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) no *Guia CloudWatch do usuário da Amazon*. **Obter dados mais detalhados sobre consultas de DNS** Para obter informações mais detalhadas sobre cada consulta de DNS à qual o Route 53 responde, incluindo os seguintes valores, você pode configurar o log de consultas: + Domínio ou subdomínio que foi solicitado + Data e hora da solicitação + Tipo de registro DNS (como A ou AAAA) + Localização de borda do Route 53 que respondeu à consulta de DNS + O código de resposta DNS, como `NoError` ou `ServFail` Para obter mais informações, consulte [Log de consultas de DNS pública](query-logs.md). **Como obter métricas de consulta de DNS** Logo após você criar uma zona hospedada, o Amazon Route 53 começa a enviar métricas e dimensões uma vez por minuto para CloudWatch. Você pode usar os procedimentos a seguir para visualizar as métricas no CloudWatch console ou visualizá-las usando o AWS Command Line Interface (AWS CLI). **Topics** + [Visualizando métricas de consulta de DNS para uma zona hospedada pública no console CloudWatch](#hosted-zone-public-viewing-query-metrics-console) + [Obter métricas de consulta de DNS usando o AWS CLI](#hosted-zone-public-viewing-query-metrics-cli) ## Visualizando métricas de consulta de DNS para uma zona hospedada pública no console CloudWatch Para visualizar as métricas de consulta de DNS para zonas hospedadas públicas no CloudWatch console, execute o procedimento a seguir. **Para visualizar métricas de consulta de DNS para uma zona hospedada pública no console CloudWatch** 1. Faça login no Console de gerenciamento da AWS e abra o CloudWatch console em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. No painel de navegação, selecione **Métricas**. 1. Na lista de AWS regiões no canto superior direito do console, escolha **Leste dos EUA (Norte da Virgínia)**. As métricas do Route 53 não estarão disponíveis se você escolher qualquer outra AWS região. 1. Na guia **Todas as métricas**, escolha **Route 53**. 1. Escolha **Hosted Zone Metrics (Métricas de zona hospedada)**. 1. Marque a caixa de seleção para uma ou mais zonas hospedadas que tenham o nome da métrica **DNSQueries**. 1. Na guia **Graphed metrics (Métricas em gráfico)**, altere os valores aplicáveis para visualizar as métricas no formato desejado. Em **Estatística**, escolha **Soma** ou **SampleCount**; ambas as estatísticas exibem o mesmo valor. ## Obter métricas de consulta de DNS usando o AWS CLI Para obter métricas de consulta de DNS usando o AWS CLI, você usa o [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html)comando. Observe o seguinte: + Você especifica a maioria dos valores para o comando em um arquivo JSON separado. Para obter mais informações, consulte [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html). + O comando retorna um valor para cada intervalo especificado para `Period` no arquivo JSON. O `Period` está em segundos, portanto, se você especificar um período de cinco minutos e especificar `60` para `Period`, receberá cinco valores. Se você especificar um período de cinco minutos e especificar `300` para `Period`, receberá um valor. + No arquivo JSON, você pode especificar qualquer valor para `Id`. + Deixe a AWS região não especificada ou especifique `us-east-1` como região. As métricas do Route 53 não estarão disponíveis se você escolher qualquer outra região. Para obter mais informações, consulte [Configurando a AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) no Guia *AWS Command Line Interface do* usuário. Aqui está o AWS CLI comando que você usa para obter métricas de consulta de DNS para o período de cinco minutos entre 4:01 e 4:07 em 1º de maio de 2019. O parâmetro `metric-data-queries` faz referência ao arquivo JSON de exemplo que segue o comando. ``` aws cloudwatch get-metric-data --metric-data-queries file://./metric.json --start-time 2019-05-01T04:01:00Z --end-time 2019-05-01T04:07:00Z ``` Aqui está o arquivo JSON de exemplo: ``` [ { "Id": "my_dns_queries_id", "MetricStat": { "Metric": { "Namespace": "AWS/Route53", "MetricName": "DNSQueries", "Dimensions": [ { "Name": "HostedZoneId", "Value": "Z1D633PJN98FT9" } ] }, "Period": 60, "Stat": "Sum" }, "ReturnData": true } ] ``` Veja a saída desse comando. Observe o seguinte: + Os horários de início e de término no comando abrangem um período de sete minutos, `2019-05-01T04:01:00Z` a `2019-05-01T04:07:00Z`. + Há apenas seis valores de retorno. Não há nenhum valor para `2019-05-01T04:05:00Z` porque não houve consultas de DNS durante esse minuto. + O valor de `Period` especificado no arquivo JSON é `60` (segundos), portanto, os valores são relatados em intervalos de um minuto. ``` { "MetricDataResults": [ { "Id": "my_dns_queries_id", "StatusCode": "Complete", "Label": "DNSQueries", "Values": [ 101.0, 115.0, 103.0, 127.0, 111.0, 120.0 ], "Timestamps": [ "2019-05-01T04:07:00Z", "2019-05-01T04:06:00Z", "2019-05-01T04:04:00Z", "2019-05-01T04:03:00Z", "2019-05-01T04:02:00Z", "2019-05-01T04:01:00Z" ] } ] } ``` # Excluir uma zona hospedada pública Esta seção explica como excluir uma zona hospedada pública usando o console do Amazon Route 53. Você só pode excluir uma zona hospedada se não houver outros registros que não sejam os registros padrão de SOA e de NS. Se a sua zona hospedada contiver outros registros, você precisará excluí-los antes de excluir a zona hospedada. Isso evita que você exclua acidentalmente uma zona hospedada que ainda contém registros. **Topics** + [Impedir que o tráfego seja roteado para seu domínio](#delete-public-hosted-zone-stop-routing) + [Excluir zonas hospedadas públicas que foram criadas por outro serviço](#delete-public-hosted-zone-created-by-another-service) + [Como usar o console do Route 53 para excluir uma zona hospedada pública](#delete-public-hosted-zone-procedure) ## Impedir que o tráfego seja roteado para seu domínio Para manter o registro do domínio, mas interromper o roteamento do tráfego da Internet para seu site ou aplicativo web, recomendamos excluir os *registros* na zona hospedada em vez de excluir a zona hospedada. **Importante** Se você excluir uma zona hospedada, não será possível pode cancelar a exclusão. É necessário criar outra zona hospedada e atualizar os servidores de nome para o registro do domínio, o que pode levar até 48 horas para entrar em vigor. Além disso, se você excluir uma zona hospedada, alguém poderá sequestrar o domínio e rotear o tráfego para seus próprios recursos usando seu nome de domínio. Se você delegar a responsabilidade de um subdomínio para uma zona hospedada e quiser excluir a zona hospedada filha, será necessário atualizar a zona hospedada pai excluindo o registro NS que tenha o mesmo nome que a zona hospedada filha. Por exemplo, se quiser excluir a zona hospedada acme.example.com, será necessário excluir também o registro NS acme.example.com na zona hospedada example.com. Recomendamos excluir o registro NS primeiro e aguardar a duração do TTL no registro NS antes de excluir a zona hospedada filha. Isso garante que ninguém conseguirá sequestrar a zona hospedada filha enquanto os resolvedores DNS tiverem os servidores de nomes para a zona hospedada filha em cache. Se quiser evitar a cobrança mensal da zona hospedada, você poderá transferir o serviço de DNS do domínio para um serviço de DNS gratuito. Ao transferir o serviço de DNS, será necessário atualizar os servidores de nome do registro de domínio. Se o domínio estiver registrado no Route 53, consulte [Adicionar ou alterar servidores de nome e registros cola de um domínio](domain-name-servers-glue-records.md) para obter informações sobre como substituir servidores de nome do Route 53 por servidores de nome do novo serviço DNS. Se o domínio estiver registrado com outro registrador, use o método fornecido pelo registrador para atualizar os servidores de nome do registro de domínio. Para mais informações, faça uma pesquisa na Internet sobre "serviço DNS gratuito". ## Excluir zonas hospedadas públicas que foram criadas por outro serviço Se uma zona hospedada foi criada por outro serviço, você não pode excluí-la usando o console do Route 53. Em vez disso, você precisa usar o processo aplicável para outros serviços: + **AWS Cloud Map**— Para excluir uma zona hospedada AWS Cloud Map criada quando você criou um namespace DNS público, exclua o namespace. AWS Cloud Map exclui a zona hospedada automaticamente. Para obter mais informações, consulte [Deleting namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) (Excluir namespaces) no *AWS Cloud Map Guia do desenvolvedor*. + **Descoberta de serviço do Amazon Elastic Container Service (Amazon ECS)**: para excluir uma zona hospedada pública que o Amazon ECS criou quando você criou um serviço usando a descoberta de serviço, exclua os serviços do Amazon ECS que estão usando o namespace e exclua o namespace. Para obter mais informações, consulte [Como excluir um serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. ## Como usar o console do Route 53 para excluir uma zona hospedada pública Para usar o console do Route 53 para excluir uma zona hospedada pública, execute o procedimento a seguir. **Para excluir uma zona hospedada pública usando o console do Route 53** 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 o link destacado da zona hospedada que deseja excluir. 1. Verifique se a zona hospedada que você deseja excluir contém apenas um registro NS e SOA. Se houver registros adicionais, exclua-os. Você também precisará desabilitar a assinatura de DNSSEC: **nota** Se você tentar excluir a zona hospedada sem atender a esses requisitos, o Route 53 retornará um erro: Se a assinatura DNSSEC estiver habilitada: a zona hospedada especificada contém chaves de assinatura de chave DNSSEC e, portanto, não pode ser excluída Se houver outros conjuntos de registros de recursos (diferentes dos SOA e NS padrão): a zona hospedada especificada contém conjuntos de registros de recursos não necessários e, portanto, não pode ser excluída 1. Na página de detalhes da zona hospedada, na lista **Records** (Registros), se a lista de registros incluir quaisquer registros para os quais o valor da coluna **Type** (Tipo) for diferente de NS ou SOA, escolha a linha e depois **Delete** (Excluir). Para selecionar vários registros consecutivos, escolha a primeira linha, mantenha a tecla **Shift** pressionada e selecione a última linha. Para selecionar vários registros não consecutivos, escolha a primeira linha, mantenha a tecla **Ctrl** pressionada e selecione as demais linhas. **nota** Se você criou registros de NS para subdomínios na zona hospedada, exclua esses registros também. 1. Volte para a página **Hosted zones** (Zonas hospedadas) e escolha a linha da zona hospedada que deseja excluir. 1. Escolha **Excluir**. 1. Digite a chave de confirmação e escolha **Delete** (Excluir). 1. Se pretender tornar o domínio indisponível na Internet, recomendamos que você transfira o serviço DNS para um serviço DNS gratuito e, em seguida, elimine a zona hospedada do Route 53. Isso impede que futuras consultas DNS sejam incorretamente encaminhadas. Se o domínio estiver registrado no Route 53, consulte [Adicionar ou alterar servidores de nome e registros cola de um domínio](domain-name-servers-glue-records.md) para obter informações sobre como substituir servidores de nome do Route 53 por servidores de nome do novo serviço DNS. Se o domínio estiver registrado com outro registrador, use o método fornecido pelo registrador para alterar os servidores de nome do domínio. **nota** Se você estiver excluindo uma zona hospedada de um subdomínio (acme.example.com), não será necessário alterar os servidores de nome do domínio (example.com). # Verificar respostas do Route 53 ao DNS Se criou um zona hospedada do Amazon Route 53 para seu domínio, você poderá usar a ferramenta de verificação do DNS no console para ver como o Route 53 responderá às consultas DNS se você configurar seu domínio para usar o Route 53 como seu serviço DNS. Para registros de geolocalização, geoproximidade e latência, você também pode simular consultas de um determinado endereço IP do and/or cliente resolvedor de DNS para descobrir qual resposta o Route 53 retornaria. **Importante** A ferramenta não envia consultas ao Domain Name System (DNS). Ela só responde com base nas configurações nos registros na zona hospedada. A ferramenta retorna as mesmas informações independentemente de a zona hospedada estar sendo usada no momento para rotear o tráfego para o domínio. A ferramenta de verificação de DNS funciona apenas para zonas hospedadas públicas. **nota** A ferramenta de verificação de DNS retorna informações semelhantes às que você esperaria da seção de resposta do comando `dig`. Portanto, se você solicitar os servidores de nomes de um subdomínio que apontam para os servidores de nomes superiores, eles não serão retornados. **Topics** + [Como usar a ferramenta de verificação para ver como o Amazon Route 53 responde às consultas de DNS](#dns-test-how-route-53-responds) + [Usar a ferramenta de verificação para simular consultas de endereços IP específicos (apenas registros de latência e localização geográfica)](#dns-test-simulate-requests) ## Como usar a ferramenta de verificação para ver como o Amazon Route 53 responde às consultas de DNS Você pode usar a ferramenta para ver a resposta do Amazon Route 53 a uma consulta de DNS para um registro. **Para usar a ferramenta de verificação para ver como o Route 53 responde às consultas de DNS** 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 **Zonas hospedadas**. 1. Na página **Zonas hospedadas**, escolha o nome de uma zona hospedada. O console exibe a lista de registros para essa zona hospedada. 1. Para ir diretamente para a página **Check response from Route 53** (Verificar resposta do Route 53), escolha **Test record** (Testar registro). 1. Especifique os seguintes valores: + O nome do registro, excluindo o nome da zona hospedada. Por exemplo, para verificar **www.example.com**, insira **www**. Para verificar **example.com**, deixe o campo **Record name (Nome do registro)** em branco. + O tipo de registro que você deseja verificar, como **A** ou **CNAME**. 1. Escolha **Obter resposta**. 1. A seção **Resposta retornada pelo Route 53** inclui os seguintes valores: **Código de resposta do DNS** Um código que indica se a consulta foi válida ou não. O código de resposta mais comum é **NOERROR** e indica que a consulta é válida. Se a resposta não for válida, o Route 53 retornará um código de resposta que explicará o motivo. Para obter uma lista dos códigos de resposta possíveis, consulte [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) no site da IANA. **Protocolo** O protocolo que o Amazon Route 53 usou para responder a consulta. O protocolo pode ser **UDP** ou **TCP**. **Resposta retornada pelo Route 53** O valor que o Route 53 retornaria para uma aplicação Web. O valor é um dos seguintes: + Para registros que não sejam de alias, a resposta contém um ou mais valores no registro. + Para vários registros que têm o mesmo nome e tipo, que inclui conjuntos ponderados, de latência, localização geográfica e failover, a resposta contém o valor do registro apropriado, de acordo com a solicitação. + Para registros de alias que se referem a AWS recursos que não sejam outro registro, a resposta contém um endereço IP ou um nome de domínio para o AWS recurso, dependendo do tipo de recurso. + Para registros de alias que se referem a outros registros, a resposta contém um ou mais valores do registro referido. ## Usar a ferramenta de verificação para simular consultas de endereços IP específicos (apenas registros de latência e localização geográfica) Se você tiver criado registros de latência e localização geográfica, pode usar a ferramenta de verificação para simular consultas do endereço IP para um resolvedor de DNS e para um cliente. **Para usar a ferramenta de verificação para simular consultas de endereços IP especificados** 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 **Zonas hospedadas**. 1. Na página **Zonas hospedadas**, escolha o nome de uma zona hospedada. O console exibe a lista de registros para essa zona hospedada. 1. Para ir diretamente para a página **Verificar resposta do Route 53**, escolha **Testar conjunto de registros**. Para chegar à página **Verificar resposta do Route 53** de um registro específico, marque a caixa de seleção daquele registro e escolha **Testar conjunto de registros**. 1. Se você escolher **Test record set (Testar conjunto de registros)** sem primeiro escolher um registro, especifique os seguintes valores: + O nome do registro, excluindo o nome da zona hospedada. Por exemplo, para verificar **www.example.com**, insira **www**. Para verificar **example.com**, deixe o campo **Record name (Nome do registro)** em branco. + O tipo de registro que você deseja verificar, como **A** ou **CNAME**. 1. Especifique os valores aplicáveis: **Endereço IP do resolvedor** Especifique um IPv6 endereço IPv4 ou para simular a localização do resolvedor de DNS que um cliente usa para fazer solicitações. Isso é útil para testar registros de localização geográfica e latência. Se você omitir esse valor, a ferramenta usará o endereço IP de um resolvedor de DNS na região Leste dos AWS EUA (Norte da Virgínia) (us-east-1). **EDNS0 IP da sub-rede do cliente** Se o resolvedor suportar EDNS0, insira o IP da sub-rede do cliente para um endereço IP na localização geográfica aplicável, por exemplo, **192.0.2.0** ou **2001:db 8:85** a3: :8a2e: 370:7334. **Máscara de sub-rede** Se você especificar um endereço IP para o **IP da sub-rede EDNS0 do cliente**, você pode, opcionalmente, especificar o número de bits do endereço IP que você deseja que a ferramenta de verificação inclua na consulta de DNS. **Por exemplo, se você especificar **192.0.2.44** para **IP de sub-rede EDNS0 do cliente e **24** para máscara de sub-rede****, a ferramenta de verificação simulará** uma consulta de 192.0.2.0/24.** O valor padrão é 24 bits para IPv4 endereços e 64 bits para IPv6 endereços. 1. Escolha **Obter resposta**. 1. A seção **Resposta retornada pelo Route 53** inclui os seguintes valores: **Consulta de DNS enviada ao Route 53** A consulta, em [formato BIND](https://en.wikipedia.org/wiki/Zone_file), que a ferramenta de verificação enviou ao Route 53. Este é o mesmo formato que um aplicativo web usa para enviar uma consulta. Os três valores costumam ser o nome do registro, **IN** (para Internet) e o tipo do registro. **Código de resposta do DNS** Um código que indica se a consulta foi válida ou não. O código de resposta mais comum é **NOERROR** e indica que a consulta é válida. Se a resposta não for válida, o Route 53 retornará um código de resposta que explicará o motivo. Para obter uma lista dos códigos de resposta possíveis, consulte [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) no site da IANA. **Protocolo** O protocolo que o Amazon Route 53 usou para responder a consulta. O protocolo pode ser **UDP** ou **TCP**. **Resposta retornada pelo Route 53** O valor que o Route 53 retornaria para uma aplicação Web. O valor é um dos seguintes: + Para registros que não sejam de alias, a resposta contém um ou mais valores no registro. + Para vários registros que têm o mesmo nome e tipo, que inclui conjuntos ponderados, de latência, localização geográfica e failover, a resposta contém o valor do registro apropriado, de acordo com a solicitação. + Para registros de alias que se referem a AWS recursos que não sejam outro registro, a resposta contém um endereço IP ou um nome de domínio para o AWS recurso, dependendo do tipo de recurso. + Para registros de alias que se referem a outros registros, a resposta contém um ou mais valores do registro referido. # Configurar servidores de nome de rótulo branco Cada zona hospedada do Amazon Route 53 é associada a quatro servidores de nome, conhecidos como um conjunto de delegações. Por padrão, os servidores de nome têm nomes como ns-2048.awsdns-64.com. Para que o nome do domínio de seus servidores de nome seja o mesmo nome de domínio de sua zona hospedada, por exemplo, ns1.exemplo.com, configure os servidores de nome de rótulo branco, também conhecidos como servidores de nome privado ou servidores de nome intuitivo. As etapas a seguir explicam como configurar um conjunto de quatro servidores de nome de rótulo branco que você pode reutilizar para vários domínios. Por exemplo, suponha que você tenha os domínios exemplo.com, exemplo.org e exemplo.net. Com estas etapas, você pode configurar os servidores de nome de rótulo branco para exemplo.com e reutilizá-los para exemplo.org e exemplo.net. **Topics** + [Etapa 1: Criar um conjunto de delegações reutilizáveis do Route 53](#white-label-name-servers-create-reusable-delegation-set) + [Etapa 2: Criar ou recriar as zonas hospedadas do Amazon Route 53 e alterar o TTL dos registros de NS e SOA](#white-label-name-servers-create-hosted-zones) + [Etapa 3: recriar registros para suas zonas hospedadas](#white-label-name-servers-create-resource-record-sets) + [Etapa 4: obter endereços IP](#white-label-name-servers-get-ip-addresses) + [Etapa 5: Criar registros para servidores de nome de rótulo branco](#white-label-name-servers-create-white-label-resource-record-sets) + [Etapa 6: atualizar registros de NS e SOA](#white-label-name-servers-update-ns-soa-records) + [Etapa 7: criar registros cola e alterar os servidores de nome do registrador](#white-label-name-servers-create-glue-records) + [Etapa 8: monitorar o tráfego para o site ou a aplicação](#white-label-name-servers-monitor-traffic) + [Etapa 9: TTLs voltar aos valores originais](#white-label-name-servers-change-ttls-back) + [Etapa 10: entrar em contato com serviços de DNS recursivos (opcional)](#white-label-name-servers-contact-recursive-dns-services) ## Etapa 1: Criar um conjunto de delegações reutilizáveis do Route 53 Os servidores de nomes de rótulo branco são associados a um conjunto de delegaçõs reutilizável do Route 53. Você pode usar servidores de nomes de marca branca para uma zona hospedada somente se a zona hospedada e o conjunto de delegações reutilizáveis tiverem sido criados pela mesma conta. AWS Para criar um conjunto de delegações reutilizável, você pode usar a API do Route 53, a AWS CLI ou uma das. AWS SDKs Para saber mais, consulte a documentação a seguir: + **API do Route 53** — Veja [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)na *referência da API do Amazon Route 53* + **AWS CLI** *— Veja [create-reusable-delegation-set](https://docs.aws.amazon.com/cli/latest/reference/route53/create-reusable-delegation-set.html)na Referência de Comandos AWS CLI * + **AWS SDKs**Consulte a documentação do SDK aplicável na página de [AWS documentação](https://docs.aws.amazon.com/) ## Etapa 2: Criar ou recriar as zonas hospedadas do Amazon Route 53 e alterar o TTL dos registros de NS e SOA Criar ou recriar zonas hospedadas do Amazon Route 53: + **Se não estiver usando o Route 53 como o serviço DNS dos domínios para os quais você quer usar servidores de nome de rótulo branco**: crie as zonas hospedadas e especifique o conjunto de delegações reutilizáveis que você criou na etapa anterior com cada zona hospedada. Para obter mais informações, consulte [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)a *Referência de API do Amazon Route 53*. + **Se você estiver usando o Route 53 como o serviço DNS dos domínios para os quais você quer usar os servidores de nome de rótulo branco**: crie as zonas hospedadas para as quais você quer usar os servidores de nome de rótulo branco e especifique o conjunto de delegações reutilizáveis que você criou na etapa anterior para cada zona hospedada. **Importante** Você não pode alterar os servidores de nome associados a uma zona hospedada existente. Você pode associar um conjunto de delegações reutilizáveis a uma zona hospedada somente quando cria a zona hospedada. Quando você criar zonas hospedadas e antes de tentar acessar os recursos dos domínios correspondente, altere os seguintes valores de TTL para cada zona hospedada: + Altere o TTL do registro de NS da zona hospedada para 60 segundos ou menos. + Altere o TTL mínimo do registro de SOA da zona hospedada para 60 segundos ou menos. Este é o último valor no registro de SOA. Se, acidentalmente, você informar a seu registrador endereços IP incorretos para seus servidores de nome de rótulo branco, seu site se tornará indisponível pela duração do TTL depois que você corrigir o problema. Ao definir um TTL baixo, você reduz a quantidade de tempo que o seu site ficará indisponível. Para obter mais informações sobre a criação de zonas hospedadas e a especificação de um conjunto de delegações reutilizável para os servidores de nomes das zonas hospedadas, consulte [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)a Referência de API do *Amazon Route 53*. ## Etapa 3: recriar registros para suas zonas hospedadas Crie registros nas zonas hospedadas que você criou na etapa 2: + **Se estiver migrando o serviço DNS dos seus domínios para o Amazon Route 53**: talvez você possa criar registros importando informações sobre seus registros existentes. Para obter mais informações, consulte [Criar registros importando um arquivo de zona](resource-record-sets-creating-import.md). + **Se você estiver substituindo zonas hospedadas existentes para que possa usar os servidores de nome de rótulo branco**: as novas zonas hospedadas, recrie os registros que aparecem nas suas zonas hospedadas atuais. O Route 53 não fornece um método de exportação de registros de uma zona hospedada, mas alguns fornecedores terceirizados oferecem. Você pode usar o recurso de importação do Route 53 para importar registros que não sejam de alias para os quais a política de roteamento é simples. Não há uma maneira de exportar e reimportar registros de alias ou registros para os quais a política de roteamento não é simples. Para obter informações sobre a criação de registros usando a API do Route 53, consulte [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)a *Referência da API do Amazon Route 53*. Para obter informações sobre como criar registros usando o console do Route 53, consulte [Trabalhar com registros](rrsets-working-with.md). ## Etapa 4: obter endereços IP Obtenha os IPv6 endereços IPv4 e dos servidores de nomes no conjunto de delegações reutilizáveis e preencha a tabela a seguir. **** | Nome de um servidor de nome no conjunto de delegações reutilizáveis (exemplo: Ns-2048.awsdns-64.com) | IPv4 e IPv6 endereços                                             | Nome que você deseja atribuir ao servidor de nome de rótulo branco (exemplo: ns1.exemplo.com) | | --- | --- | --- | |   | IPv4: IPv6: |   | |   | IPv4: IPv6: |   | |   | IPv4: IPv6: |   | |   | IPv4: IPv6: |   | Por exemplo, suponha que os quatro servidores de nome do seu conjunto de delegações reutilizáveis sejam: + ns-2048.awsdns-64.com + ns-2049.awsdns-65.net + ns-2050.awsdns-66.org + ns-2051.awsdns-67.co.uk Aqui estão os comandos do Linux e do Windows que você executaria para obter os endereços IP para o primeiro dos quatro servidores de nome: **comandos dig para Linux** ``` % dig A ns-2048.awsdns-64.com +short 192.0.2.117 ``` ``` % dig AAAA ns-2048.awsdns-64.com +short 2001:db8:85a3::8a2e:370:7334 ``` **comando nslookup para Windows** ``` c:\> nslookup ns-2048.awsdns-64.com Non-authoritative answer: Name: ns-2048.awsdns-64.com Addresses: 2001:db8:85a3::8a2e:370:7334 192.0.2.117 ``` ## Etapa 5: Criar registros para servidores de nome de rótulo branco Na zona hospedada que tem o mesmo nome (como exemplo.com) que o nome do domínio dos servidores de nome de rótulo branco (como ns1.exemplo.com), crie oito registros: + Um registro A para cada servidor de nome de rótulo branco + Um registro AAAA para cada servidor de nome de rótulo branco **Importante** Se estiver usando os mesmos servidores de nome de rótulo branco para duas ou mais zonas hospedadas, não execute essa etapa para as outras zonas hospedadas. Para cada registro, especifique os valores a seguir. Consulte a tabela que você preencheu na etapa anterior: **Política de roteamento** Especifique **Simple routing** (Roteamento simples). **Nome do registro** O nome que você deseja atribuir a um dos servidores de nome de rótulo branco, por exemplo, ns1.exemplo.com. Para o prefixo (ns1 neste exemplo), você pode usar qualquer valor válido em um nome de domínio. **Valor/Encaminhar tráfego para** O IPv6 endereço IPv4 ou de um dos servidores de nomes do Route 53 em seu conjunto de delegações reutilizáveis. Se você especificar endereços IP incorretos ao criar registros para os servidores de nome de rótulo branco, seu site ou aplicativo web ficará indisponível na Internet quando você executar etapas subsequentes. Mesmo que você corrija os endereços IP imediatamente, seu site ou aplicativo web permanecerá indisponível pela duração do TTL. **Tipo de registro** Especifique **A** ao criar registros para os IPv4 endereços. Especifique **AAAA** ao criar registros para os IPv6 endereços. **TTL (segundos)** Este valor é a quantidade de tempo pela qual os resolvedores de DNS armazenam em cache as informações neste registro antes de encaminhar outra consulta de DNS ao Route 53. Recomendamos que você especifique um valor inicial igual ou inferior a 60 segundos. Assim, você poderá recuperar com rapidez se, acidentalmente, especificar valores incorretos nestes registros. ## Etapa 6: atualizar registros de NS e SOA Atualize os registros SOA e NS nas zonas hospedadas para as quais você deseja usar os servidores de nome de rótulo branco. Execute as etapa de 6 a 8 para uma zona hospedada e o domínio correspondente de cada vez. Em seguida, repita para outra zona hospedada e domínio. **Importante** Comece com a zona hospedada do Amazon Route 53 que tem o mesmo nome de domínio (como example.com) que os servidores de nome de rótulo branco (como ns1.exemplo.com). 1. Atualize o registro SOA substituindo o nome do servidor de nome do Route 53 pelo nome de um de seus servidores de nome de rótulo branco **Exemplo** Substitua o nome do servidor de nome do Route 53: `ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 60` pelo nome de um dos servidores de nome de rótulo branco: `ns1.example.com. hostmaster.example.com. 1 7200 900 1209600 60` **nota** Você alterou o último valor, a vida útil (TTL), na [Etapa 2: Criar ou recriar as zonas hospedadas do Amazon Route 53 e alterar o TTL dos registros de NS e SOA](#white-label-name-servers-create-hosted-zones). Para obter mais informações sobre como atualizar registros usando o console do Route 53, consulte [Editar registros](resource-record-sets-editing.md). 1. No registro de NS, anote os nomes dos servidores de nome atuais do domínio para que você possa reverter para esses servidores de nome se necessário. 1. Atualize o registro de NS. Substitua o nome dos servidores de nome do Route 53 pelos nomes dos quatro servidores de nome de rótulo branco, por exemplo, `ns1.example.com`, `ns2.example.com`, `ns3.example.com`, e `ns4.example.com`. ## Etapa 7: criar registros cola e alterar os servidores de nome do registrador Use o método fornecido pelo registrador para criar registros cola e alterar os servidores de nome do registrador: 1. Adicione registros cola: + **Se estiver atualizando o domínio que tem o mesmo nome de domínio que os servidores de nome de rótulo branco**: crie quatro registros cola para os quais os nomes e endereços IP correspondem aos valores que você obteve na etapa 4. Inclua o endereço IPv4 e o IPv6 endereço de um servidor de nomes com etiqueta branca no registro de cola correspondente, por exemplo: **ns1.example.com**: endereços IP = 192.0.2.117 and 2001:db8:85a3::8a2e:370:7334 Os registradores usam diversos termos para os registros cola. Os registros cola podem ser mencionados como registro de novos servidores de nome ou algo parecido. + **Se você estiver atualizando outro domínio**: se o Route 53 for seu serviço DNS, primeiro você deverá concluir a etapa do marcador anterior e criar os registros cola que correspondem ao nome do domínio. Em seguida, pule para a etapa 2 deste procedimento. 1. Altere os servidores de nome do domínio para os nomes dos servidores de nome de rótulo branco. Se estiver usando o Amazon Route 53 como o serviço DNS, consulte [Adicionar ou alterar servidores de nome e registros cola de um domínio](domain-name-servers-glue-records.md). ## Etapa 8: monitorar o tráfego para o site ou a aplicação Monitore o tráfego do site ou da aplicação para os quais você criou registros cola e alterou os servidores de nome na etapa 7: + **Se o tráfego for interrompido**: use o método fornecido pelo registrador para alterar os servidores de nome do domínio de volta para os servidores de nome anteriores do Route 53. Esses são os servidores de nome que você anotou na etapa 6b. Em seguida, determine o que deu errado. + **Se o tráfego não for afetado**: repita as etapas 6 a 8 para as demais zonas hospedadas para as quais você quer usar os mesmos servidores de nome de rótulo branco. ## Etapa 9: TTLs voltar aos valores originais Para todas as zonas hospedadas que agora estão usando os servidores de nome de rótulo branco, altere os seguintes valores: + Altere o TTL do registro de NS da zona hospedada para um valor mais comum de registros de NS. Por exemplo, 172.800 segundos (dois dias). + Altere o TTL mínimo do registro de SOA da zona hospedada para um valor mais comum de registros de SOA. Por exemplo, 900 segundos. Este é o último valor no registro de SOA. ## Etapa 10: entrar em contato com serviços de DNS recursivos (opcional) *Opcional* Se você estiver usando o roteamento de geolocalização do Amazon Route 53, entre em contato com os serviços de DNS recursivos que suportam a edns-client-subnet extensão e forneça a eles os nomes dos EDNS0 seus servidores de nomes de marca branca. Isso garante que esses serviços de DNS continuarão a encaminhar as consultas de DNS para a melhor localização do Route 53 com base na localização geográfica aproximada de origem da consulta. # Registros de NS e SOA que o Amazon Route 53 cria para uma zona hospedada pública Para cada zona hospedada pública que você cria, o Amazon Route 53 cria automaticamente um registro de servidor de nome (NS) e de início de autoridade (SOA). Raramente é necessário alterar esses registros. **Topics** + [Registro de servidor de nome (NS)](#NSrecords) + [Registro de início de autoridade (SOA)](#SOArecords) ## Registro de servidor de nome (NS) O Amazon Route 53 cria automaticamente um registro de servidor de nome (NS) que tem o mesmo nome que sua zona hospedada. Ele lista os quatro servidores de nome que são os servidores de nome autoritativos para sua zona hospedada. Exceto em circunstâncias raras, recomendamos que você não adicione, altere ou exclua servidores de nomes neste registro. Os exemplos a seguir mostram o formato dos nomes dos servidores de nome do Route 53 (esses são apenas exemplos; não os use quando atualizar seus registros de servidor de nome do registrador): + *ns-2048.awsdns-64.com* + *ns-2049.awsdns-65.net* + *ns-2050.awsdns-66.org* + *ns-2051.awsdns-67.co.uk* Para obter a lista dos servidores de nome da sua zona hospedada: 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, clique em **Hosted zones** (Zonas hospedadas). 1. Na página **Hosted zones** (Zonas hospedadas), escolha o botão de opção (não o nome) da zona hospedada, depois escolha **View details** (Exibir detalhes). 1. Na página de detalhes da zona hospedada, escolha **Hosted zone details** (Detalhes da zona hospedada). 1. Anote os quatro servidores listados para **Name servers** (Servidores de nome). Para obter informações sobre como migrar o serviço DNS de outro provedor de serviço DNS para o Route 53, consulte [Como transformar o Amazon Route 53 no serviço de DNS para um domínio existenteComo transformar o Route 53 no serviço de DNS para um domínio existente](MigratingDNS.md). ## Registro de início de autoridade (SOA) O registro de início de autoridade (SOA) identifica informações básicas de DNS sobre o domínio, por exemplo: ``` 1. ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 86400 ``` Um registro SOA inclui os seguintes elementos: + O servidor de nome do Route 53 que criou o registro SOA, por exemplo, `ns-2048.awsdns-64.net`. + O endereço de e-mail do administrador. O símbolo `@` é substituído por um ponto, por exemplo, `hostmaster.example.com`. O valor padrão é um endereço de e-mail amazon.com que não é monitorado. + Um número de série que você pode incrementar opcionalmente sempre que atualizar um registro na zona hospedada. O Route 53 não incrementa o número automaticamente. (O número de série é usado pelos serviços DNS que oferecem suporte a DNS secundário.) No exemplo, esse valor é `1`. + Um tempo de atualização em segundos que os servidores DNS secundários aguardam antes de consultar o registro SOA do servidor DNS principal para verificar as alterações. No exemplo, esse valor é `7200`. + O intervalo de repetição em segundos que um servidor secundário aguarda antes de repetir uma transferência de zona com falha. Normalmente, o tempo de repetição é menor do que o tempo de atualização. No exemplo, esse valor é `900` (15 minutos). + O tempo de expiração em segundos que um servidor secundário continuará tentando concluir uma transferência de zona. Se esse tempo decorrer antes de uma transferência de zona bem-sucedida, o servidor secundário parará de responder a consultas porque considera que seus dados são muito antigos para serem confiáveis. No exemplo, esse valor é `1209600` (duas semanas). + O tempo mínimo de vida (TTL). Esse valor ajuda a definir o período em que os resolvedores recursivos devem armazenar em cache as seguintes respostas do Route 53: **NXDOMAIN** Não há nenhum registro de qualquer tipo com o nome especificado na consulta DNS, como exemplo.com. Também não há registros que sejam filhos do nome especificado na consulta DNS, como zenith.exemplo.com. **NODATA** Há pelo menos um registro com o nome especificado na consulta DNS, mas nenhum desses registros tem o tipo (como A) especificado na consulta DNS. Quando um resolvedor DNS armazena em cache uma resposta NXDOMAIN ou NODATA, isso é conhecido como *cache negativo*. A duração do cache negativo é o menor dos seguintes valores: + Esse valor, o TTL mínimo no registro SOA. Na exemplo, o valor é `86400` (um dia). + O valor da TTL para o registro SOA. O valor de padrão é de 900 segundos. Para obter informações sobre como alterar esse valor, consulte [Editar registros](resource-record-sets-editing.md). Quando o Route 53 responde a consultas DNS com uma resposta NXDOMAIN ou NODATA (uma resposta negativa), será cobrada a taxa para consultas padrão. Consulte “Queries” (Consultas) em [Preços do Amazon Route 53](https://aws.amazon.com/route53/pricing/). Se você estiver preocupado com o custo das respostas negativas, uma opção é alterar a TTL para o registro SOA, a TTL mínima no registro SOA (esse valor) ou ambos. Observe que aumentá-las TTLs, que se aplicam às respostas negativas de toda a zona hospedada, pode ter efeitos positivos e negativos: + Resolvedores DNS na Internet armazenam em cache a não existência de registros por períodos mais longos, o que reduz o número de consultas encaminhadas para o Route 53. Isso reduz a cobrança do Route 53 de consultas DNS. + No entanto, se você excluir erroneamente um registro válido e depois recriá-lo, os resolvedores DNS armazenarão em cache a resposta negativa (esse registro não existe) por um período mais longo. Isso aumenta o tempo que seus clientes ou usuários não conseguem acessar o recurso correspondente, como um servidor web para acme.exemplo.com. **Para encontrar registros SOA no Route 53** 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 **Zonas hospedadas**. 1. Selecione o nome vinculado do domínio cujos registros você deseja visualizar. 1. Na seção **Records** (Registros), é possível ver todos os registros listados e também filtrar registros para localizar o valor do SOA. # Habilitando a recuperação acelerada para gerenciar registros públicos de DNS A recuperação acelerada do Route 53 para gerenciar registros DNS públicos foi projetada para atingir um objetivo de tempo de recuperação (RTO) de 60 minutos em caso de indisponibilidade do serviço na região Leste dos EUA (Norte da Virgínia). Quando habilitado em uma zona hospedada pública do Route 53, você poderá continuar fazendo alterações nos registros DNS na zona hospedada pública em aproximadamente 60 minutos após AWS detectar que as operações na região Leste dos EUA (Norte da Virgínia) estão comprometidas. **Importante** A recuperação acelerada está disponível somente para zonas hospedadas públicas. Não há suporte para zonas hospedadas privadas. **nota** A resolução de consultas de DNS do plano de dados do Route 53 continua funcionando normalmente durante a interrupção do serviço regional. Consulte [Resiliência no Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/disaster-recovery-resiliency.html) para entender as operações do plano de dados versus do plano de controle. **Topics** + [Como funciona a recuperação acelerada de registros DNS públicos](#accelerated-recovery-how-it-works) + [Reenviando alterações de DNS após o failover](#accelerated-recovery-resubmit) + [Failback para a região Leste dos EUA (Norte da Virgínia)](#accelerated-recovery-failback) + [Considerações adicionais](#accelerated-recovery-considerations) + [Como habilitar a recuperação acelerada para gerenciar registros públicos de DNS](#accelerated-recovery-enable) ## Como funciona a recuperação acelerada de registros DNS públicos Quando a recuperação acelerada estiver ativada, o Route 53 manterá uma cópia da sua zona hospedada pública na região Oeste dos EUA (Oregon). Se os serviços na região Leste dos EUA (Norte da Virgínia) ficarem indisponíveis por um longo período, o Route 53 executará o failover em 60 minutos, redirecionando automaticamente as operações do plano de controle de suas zonas hospedadas públicas habilitadas para recuperação acelerada para a região Oeste dos EUA (Oregon). Em seguida, você pode continuar fazendo alterações no DNS programaticamente por meio da CLI, do SDK e da API. Observe que um conjunto limitado de métodos de API estará disponível durante o failover. Consulte a seção “Considerações adicionais” para obter mais detalhes. Quando a região se recuperar, o Route 53 executará o procedimento de failback, direcionando automaticamente as operações do plano de controle de volta para a região Leste dos EUA (Norte da Virgínia). **nota** Antes que ocorra qualquer comprometimento na região Leste dos EUA (Norte da Virgínia), você deve primeiro ativar a recuperação acelerada para gerenciar registros públicos de DNS em sua zona pública hospedada. Isso pode ser feito por meio do console, da CLI, do SDK ou da API (consulte a seção intitulada *Como ativar a recuperação acelerada para gerenciar registros DNS públicos* nesta página abaixo). Você não pode ativar a recuperação acelerada para gerenciar registros DNS públicos após a ocorrência de um failover. ## Reenviando alterações de DNS após o failover Em condições normais, as alterações nas zonas hospedadas públicas com recuperação acelerada ativada serão aceitas pela região Leste dos EUA (Norte da Virgínia) e, em seguida, serão replicadas com sucesso na região Oeste dos EUA (Oregon). No entanto, quando ocorre uma interrupção do serviço na região Leste dos EUA (Norte da Virgínia), algumas alterações podem ser aceitas pela região Leste dos EUA (Norte da Virgínia), mas podem não ser replicadas na região Oeste dos EUA (Oregon). Essas mudanças durante o voo são chamadas de “mudanças ociosas”. Depois que o failover for concluído, o Route 53 recomenda que você reenvie as alterações perdidas antes de retomar seus fluxos de trabalho de DNS. Você pode conseguir isso usando a API ou usando AWS CloudFormation as que estão descritas abaixo. ### Usando a API para rastrear e enviar alterações de DNS Se você estiver usando a API, a AWS CLI do Route 53 ou AWS SDKs para gerenciar registros de DNS, precisará usar a API e a [ChangeResourceRecordSets [GetChange API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) para enviar e rastrear as alterações de DNS, respectivamente. Quando você usa a ChangeResourceRecordSets API para fazer alterações no DNS, o Route 53 retorna um identificador (ID) para a alteração que você fez (consulte [ChangeInfo](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeInfo.html)os detalhes do objeto de resposta à alteração). Você pode fornecer esse ID em uma solicitação subsequente à GetChange API e observar o status da alteração. As alterações de DNS com o status INSYNC foram replicadas para a região Oeste dos EUA (Oregon) e propagadas para todos os servidores DNS do Route 53. Não há nenhuma outra ação a ser tomada em relação a essas alterações antes ou depois de um failover. No entanto, durante uma interrupção na região Leste dos EUA (Norte da Virgínia), GetChange pode retornar PENDENTE, indicando que sua alteração pode não ter sido replicada na região Oeste dos EUA (Oregon). Se for esse o caso, quando o failover for concluído, GetChange retornará NoSuchChange, indicando que o Route 53 não conseguiu replicar essa alteração de DNS. Portanto, após o failover, você pode ignorar com segurança essas alterações de DNS isoladas e reenviá-las como novas alterações de DNS. Você saberá que o processo de failover foi concluído quando o Route 53 publicar uma mensagem no AWS Health Dashboard. ### Usando AWS CloudFormation para rastrear e enviar alterações AWS CloudFormation rastreia automaticamente o status de replicação de suas alterações de DNS utilizando a GetChange API e só conclui uma atualização depois que as alterações de DNS forem confirmadas como INSYNC. Se você estiver usando CloudFormation para gerenciar registros DNS e a região Leste dos EUA (Norte da Virgínia) ficar indisponível, as ações que você realizar usando não CloudFormation serão concluídas com êxito durante o período de indisponibilidade. No entanto, você pode simplesmente repetir as mesmas ações para permitir o reenvio das alterações de DNS, após CloudFormation a conclusão do processo de failover do Route 53. ## Failback para a região Leste dos EUA (Norte da Virgínia) O Route 53 retornará as operações do plano de controle de sua zona pública hospedada para a região Leste dos EUA (Norte da Virgínia) assim que a região se recuperar. Durante o failback, você não precisará reenviar suas alterações de DNS, pois nenhuma alteração perdida será introduzida durante esse processo. ## Considerações adicionais Há algumas considerações adicionais a serem observadas relacionadas ao recurso de recuperação acelerada: 1. Você não poderá criar novas zonas hospedadas, excluir zonas hospedadas existentes, ativar a assinatura do DNSSEC ou desativar a assinatura do DNSSEC durante o failover. 1. AWS PrivateLink as conexões não funcionarão após o failover, mas funcionarão novamente após um failback para a região Leste dos EUA (Norte da Virgínia). 1. [CloudFront planos de tarifa fixa](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html) não são suportados no momento. 1. As zonas hospedadas com recuperação acelerada ativada não podem ser excluídas. Você deve desativar a recuperação acelerada antes de tentar excluir a zona hospedada. 1. Durante o failover, os seguintes métodos de API continuarão sendo suportados em zonas públicas hospedadas com recuperação acelerada ativada. No entanto, todos os outros métodos da API do Route 53 não funcionarão até que ocorra um failback. + `ChangeResourceRecordSets` + `GetChange` + `GetGeoLocation` + `GetHostedZone` + `GetHostedZoneCount` + `GetHostedZoneLimit` + `GetReusableDelegationSet` + `GetReusableDelegationSetLimit` + `ListGeoLocations` + `ListHostedZones` + `ListHostedZonesByName` + `ListResourceRecordSets` + `ListReusableDelegationSets` ## Como habilitar a recuperação acelerada para gerenciar registros públicos de DNS Você pode ativar a recuperação acelerada para gerenciar registros DNS públicos usando o console, a API, a CLI ou o SDK do Route 53. O tempo necessário para permitir a recuperação acelerada dependerá do tamanho da sua zona pública hospedada e de outros fatores. Você deve planejar que o processo de ativação da recuperação acelerada leve várias horas. Você pode verificar o status do processo de habilitação na guia Recuperação acelerada da sua zona pública hospedada ou por meio da API. `GetHostedZone` Quando o processo for finalizado, haverá um breve período de até vários minutos em que as alterações de DNS não serão aceitas. Depois de concluídas, as alterações de DNS podem continuar normalmente. **Para ativar e desativar a recuperação acelerada usando o console do Route 53** 1. 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 **Zonas hospedadas**. 1. Escolha a zona hospedada pública para a qual você deseja ativar a recuperação acelerada. 1. Na guia **Recuperação acelerada**, escolha **Ativar**. 1. Escolha **Salvar alterações**. 1. Monitore o status da zona hospedada. O status mostra **Ativando a recuperação acelerada** durante a configuração e muda para **Ativado** quando concluído. Você pode desativar a recuperação acelerada usando as mesmas etapas acima, mas escolhendo **Desativar**. Exemplo de CLI para habilitar ``` aws route53 update-hosted-zone-features --enable-accelerated-recovery --hosted-zone-id Z123456789 ``` Exemplo de CLI para desabilitar ``` aws route53 update-hosted-zone-features --no-enable-accelerated-recovery --hosted-zone-id Z123456789 ``` # Trabalhar com zonas hospedadas privadas Uma *zona hospedada privada* é um contêiner que contém informações sobre como você deseja que o Amazon Route 53 responda às consultas de DNS para um domínio e seus subdomínios em um ou mais VPCs que você cria com o serviço Amazon VPC. Veja como as zonas hospedadas privadas funcionam: 1. Você cria uma zona hospedada privada, como example.com, e especifica a VPC que deseja associar a ela. Depois de criar a zona hospedada, você pode associar mais VPCs a ela. 1. Você cria registros na zona hospedada que determinam como o Route 53 responde às consultas de DNS de seu domínio e subdomínios em suas VPCs. Por exemplo, suponha que tenha um servidor de banco de dados que é executado em uma instância do EC2 na VPC que você associou à sua zona hospedada privada. Você cria um registro A ou AAAA, como db.example.com, e especifica o endereço IP do servidor de banco de dados. Para obter mais informações sobre registros de , consulte [Trabalhar com registros](rrsets-working-with.md). Para obter informações sobre os requisitos da Amazon VPC; para o uso de zonas hospedadas privadas, consulte [Como usar zonas hospedadas privadas](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones) no *Guia do usuário da Amazon VPC*. 1. Quando uma aplicação enviar uma consulta de DNS db.example.com, o Route 53 retornará o endereço IP correspondente. Para obter uma resposta de uma zona hospedada privada, você também precisa estar executando uma instância EC2 em uma das associadas VPCs (ou ter um endpoint de entrada de uma configuração híbrida). Se você tentar consultar uma zona hospedada privada fora da configuração híbrida VPCs ou da sua configuração híbrida, a consulta será resolvida recursivamente na Internet. 1. A aplicação usa o endereço IP que obteve do Route 53 para estabelecer uma conexão com o servidor de banco de dados. Quando você cria uma zona hospedada privada, os seguintes servidores de nomes são usados: + ns-0.awsdns-00.com + ns-512.awsdns-00.net + ns-1024.awsdns-00.org + ns-1536.awsdns-00.co.uk Esses servidores de nomes são usados porque o protocolo DNS exige que cada zona hospedada tenha um conjunto de registros de NS. Esses servidores de nomes são reservados e nunca são usados pelas zonas hospedadas públicas do Route 53. Você só pode consultar essas zonas por meio do VPC Resolver em uma VPC que tenha sido associada à zona hospedada usando um endpoint de entrada conectado ao VPCs especificado na zona hospedada privada. Embora os servidores de nomes estejam visíveis na Internet, o VPC Resolver não se conecta aos endereços dos servidores de nomes. Além disso, as informações da zona hospedada privada não são retornadas se você consultar diretamente os servidores de nomes pela Internet. Em vez disso, o VPC Resolver detecta que as consultas estão dentro de um namespace privado baseado em VPC para associações de zonas hospedadas e usa conectividade direta e privada para alcançar os servidores DNS privados. **nota** Você pode alterar o conjunto de registros NS em uma zona hospedada privada, se quiser, e a resolução de DNS privada ainda funcionará. Não recomendamos que você faça isso, mas se quiser, deve usar nomes de domínio reservados que não sejam usados por servidores DNS públicos. Se você quiser encaminhar o tráfego para o seu domínio na Internet, utilize uma zona hospedada *pública* do Route 53. Para obter mais informações, consulte [Trabalhar com zonas hospedadas públicas](AboutHZWorkingWith.md). **Topics** + [Considerações ao trabalhar com uma zona hospedada privada](hosted-zone-private-considerations.md) + [Criar uma zona hospedada privada](hosted-zone-private-creating.md) + [Listar zonas hospedadas privadas](hosted-zone-private-listing.md) + [Associando mais a VPCs uma zona hospedada privada](hosted-zone-private-associate-vpcs.md) + [Associando uma Amazon VPC e uma zona hospedada privada que você criou com contas diferentes AWS](hosted-zone-private-associate-vpcs-different-accounts.md) + [Desassociando-se VPCs de uma zona hospedada privada](hosted-zone-private-disassociate-vpcs.md) + [Excluir uma zona hospedada privada](hosted-zone-private-deleting.md) + [Permissões da VPC](hosted-zone-private-vpc-permissions.md) # Considerações ao trabalhar com uma zona hospedada privada Ao usar zonas hospedadas privadas, considere o seguinte: + [Amazon VPC settings](#hosted-zone-private-considerations-vpc-settings) + [Route 53 health checks](#hosted-zone-private-considerations-health-checks) + [Supported routing policies for records in a private hosted zone](#hosted-zone-private-considerations-routing-policies) + [Split-view DNS](#hosted-zone-private-considerations-split-view-dns) + [Public and private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-public-private-overlapping) + [Private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-private-overlapping) + [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules) + [Delegating responsibility for a subdomain](#hosted-zone-private-considerations-delegating-subdomain) + [Custom DNS servers](#hosted-zone-private-considerations-custom-dns) + [Required IAM permissions](#hosted-zone-private-considerations-required-permissions) **Configurações da Amazon VPC** Para usar zonas hospedadas privadas, é necessário definir as seguintes configurações do Amazon VPC; como `true`: + `enableDnsHostnames` + `enableDnsSupport` Para mais informações, consulte [Visualizar e atualizar atributos de DNS para a sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html) no *Guia do usuário da Amazon VPC*. **Verificações de integridade do Route 53** Em uma zona hospedada privada, as verificações de integridade do Route 53 estão associadas apenas aos registros de failover, resposta multivalor, ponderados, latência, geolocalização e geoproximidade. Para obter informações sobre a associação de verificações de integridade com registros de failover, consulte [Configurar failover em uma zona hospedada privada](dns-failover-private-hosted-zones.md). **Políticas de roteamento com suporte para registros em uma zona hospedada privada** Você pode usar as seguintes políticas de roteamento ao criar registros em uma zona hospedada privada: + [Roteamento simples](routing-policy-simple.md) + [Roteamento de failover](routing-policy-failover.md) + [Roteamento de resposta com vários valores](routing-policy-multivalue.md) + [Roteamento ponderado](routing-policy-weighted.md) + [Roteamento baseado em latência](routing-policy-latency.md) + [Roteamento de localização geográfica](routing-policy-geo.md) + [Roteamento por geoproximidade](routing-policy-geoproximity.md) Não há suporte para a criação de registros em uma zona hospedada privada usando outras políticas de roteamento. **DNS com exibição segmentada** É possível usar o Route 53 para configurar o DNS com exibição segmentada, também conhecido como DNS com horizonte segmentado. No DNS com exibição segmentada, você usa o mesmo nome de domínio (example.com) para usos internos (accounting.example.com) e para usos externos, como seu site público (www.example.com). Você também pode usar o mesmo nome de subdomínio interna e externamente, mas fornecer conteúdo diferente ou exigir autenticação diferente para usuários internos e externos. Para configurar o DNS com exibição segmentada, execute as seguintes etapas: 1. Crie zonas hospedadas públicas e privadas que tenham o mesmo nome. (O DNS com exibição segmentada ainda funcionará se você estiver usando outro serviço de DNS para a zona hospedada pública.) 1. Associe uma ou mais Amazon VPCs à zona hospedada privada. O Route 53 VPC Resolver usa a zona hospedada privada para rotear consultas de DNS no especificado. VPCs 1. Crie registros em cada zona hospedada. Os registros na zona hospedada pública controlam como o tráfego da Internet é roteado, e os registros na zona hospedada privada controlam como o tráfego é roteado na sua Amazon. VPCs Se você precisar realizar a resolução de nomes da sua VPC e das cargas de trabalho locais, você pode usar o Route 53 VPC Resolver. Para obter mais informações, consulte [O que é o Route 53 VPC Resolver?](resolver.md). **Zonas hospedadas públicas e privadas que têm namespaces sobrepostos** Se você tiver zonas hospedadas públicas e privadas com namespaces sobrepostos, como example.com e accounting.example.com, o VPC Resolver roteia o tráfego com base na correspondência mais específica. Quando os usuários estão conectados a uma instância do EC2 em uma Amazon VPC que você associou à zona hospedada privada, veja como o Route 53 VPC Resolver lida com consultas de DNS: 1. O VPC Resolver avalia se o nome da zona hospedada privada corresponde ao nome do domínio na solicitação, como accounting.example.com. Uma correspondência é definida como uma das seguintes opções: + Correspondência idêntica + O nome da zona hospedada privada é pai do nome de domínio na solicitação. Por exemplo, suponhamos que o nome de domínio na solicitação seja o seguinte: **seattle.accounting.example.com** As zonas hospedadas a seguir serão correspondentes porque são pais de seattle.accounting.example.com: + **accounting.example.com** + **example.com** Se não houver uma zona hospedada privada correspondente, o VPC Resolver encaminha a solicitação para um resolvedor de DNS público, e sua solicitação é resolvida como uma consulta DNS normal. 1. Se houver um nome de zona hospedada privada que corresponda ao nome de domínio na solicitação, será pesquisado na zona hospedada um registro que corresponda ao nome de domínio e ao tipo de DNS na solicitação, por exemplo, um registro A para accounting.example.com. **nota** Se houver uma zona hospedada privada correspondente, mas não houver nenhum registro que corresponda ao nome de domínio e ao tipo na solicitação, o VPC Resolver não encaminhará a solicitação para um resolvedor de DNS público. Em vez disso, ele retornará NXDOMAIN (domínio inexistente) para o cliente. **Zonas hospedadas privadas que têm namespaces sobrepostos** Se você tiver duas ou mais zonas hospedadas privadas com namespaces sobrepostos, como example.com e accounting.example.com, o VPC Resolver roteia o tráfego com base na correspondência mais específica. Se você tiver uma zona hospedada privada (exemplo.com) e uma regra do Route 53 VPC Resolver que roteia o tráfego para sua rede com o mesmo nome de domínio, a regra do VPC Resolver tem precedência. Consulte [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules). Quando os usuários estão conectados a uma instância do EC2 em uma Amazon VPC que você associou a todas as zonas hospedadas privadas, veja como o VPC Resolver lida com consultas de DNS: 1. O VPC Resolver avalia se o nome de domínio na solicitação, como accounting.example.com, corresponde ao nome de uma das zonas hospedadas privadas. 1. Se não houver uma zona hospedada que corresponda exatamente ao nome de domínio na solicitação, o VPC Resolver verifica se há uma zona hospedada que tenha um nome que seja o pai do nome de domínio na solicitação. Por exemplo, suponhamos que o nome de domínio na solicitação seja o seguinte: `seattle.accounting.example.com` As zonas hospedadas a seguir são correspondentes porque são pais de `seattle.accounting.example.com`: + `accounting.example.com` + `example.com` O VPC Resolver escolhe `accounting.example.com` porque é mais específico do que. `example.com` 1. O VPC Resolver pesquisa na zona `accounting.example.com` hospedada um registro que corresponda ao nome de domínio e ao tipo de DNS na solicitação, como um registro A para. `seattle.accounting.example.com` Se não houver nenhum registro que corresponda ao nome de domínio e ao tipo na solicitação, o VPC Resolver retornará NXDOMAIN (domínio inexistente) para o cliente. **Zonas hospedadas privadas e regras do Route 53 VPC Resolver** Se você tiver uma zona hospedada privada (exemplo.com) e uma regra do VPC Resolver que roteia o tráfego para sua rede com o mesmo nome de domínio, a regra do VPC Resolver tem precedência. Por exemplo, suponha que você tenha a seguinte configuração: + Você tem uma zona hospedada privada chamada example.com e a associa a uma VPC. + Você cria uma regra do Route 53 VPC Resolver que encaminha o tráfego de example.com para sua rede e associa a regra à mesma VPC. Nessa configuração, a regra do VPC Resolver tem precedência sobre a zona hospedada privada. As consultas DNS são encaminhadas para a rede em vez de serem resolvidas com base nos registros na zona hospedada privada. **Delegar responsabilidade para um subdomínio** Agora, é possível criar registros NS em uma zona hospedada privada para delegar responsabilidade de um subdomínio. Para obter mais informações, consulte [Tutorial de regras de delegação do Resolver](outbound-delegation-tutorial.md). **Servidores DNS personalizados** Se você configurou servidores DNS personalizados nas instâncias do Amazon EC2 na sua VPC, terá que configurar esses servidores DNS para encaminhar suas consultas de DNS privadas para o endereço IP dos servidores DNS fornecidos pela Amazon para a sua VPC. Esse endereço IP é o endereço IP na base do intervalo de rede da VPC "mais dois". Por exemplo, se o intervalo CIDR da sua VPC for 10.0.0.0/16, o endereço IP do servidor DNS será 10.0.0.2. Se você quiser rotear consultas de DNS entre VPCs e sua rede, você pode usar o VPC Resolver. Para obter mais informações, consulte [O que é o Route 53 VPC Resolver?](resolver.md). **Permissões obrigatórias do IAM** Para criar zonas hospedadas privadas, é necessário conceder permissões ao IAM para ações do Amazon EC2, além das permissões para ações do Route 53. Para obter mais informações, consulte [Ações, recursos e chaves de condição do Route 53](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html) na *Referência de autorização do serviço*. # Criar uma zona hospedada privada Uma zona hospedada privada é um contêiner para registros de um domínio que você hospeda em uma ou mais nuvens privadas virtuais da Amazon (VPCs). Você cria uma zona hospedada para um domínio (como example.com) e, em seguida, cria registros para informar ao Amazon Route 53 como você deseja que o tráfego seja roteado para esse domínio dentro e entre o seu. VPCs **Importante** Ao criar uma zona hospedada privada, é necessário associar uma VPC a ela. Além disso, a VPC especificada precisa ter sido criada usando a mesma conta que você está usando para criar a zona hospedada. Depois de criar a zona hospedada, você pode associar mais VPCs a ela, incluindo a VPCs que você criou usando uma AWS conta diferente. Para associar o VPCs que você criou usando uma conta a uma zona hospedada privada que você criou usando uma conta diferente, você deve autorizar a associação e, em seguida, fazer a associação programaticamente. Para obter mais informações, consulte [Associando uma Amazon VPC e uma zona hospedada privada que você criou com contas diferentes AWS](hosted-zone-private-associate-vpcs-different-accounts.md). Para obter informações sobre como criar uma zona hospedada privada usando a API do Route 53, consulte a [Referência da API do Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/). **Para criar uma zona hospedada privada usando o console do Route 53** 1. Em cada VPC que você quer associar à zona hospedada do Route 53, altere as seguintes configurações da VPC para `true`: + `enableDnsHostnames` + `enableDnsSupport` Para obter mais informações, consulte [Atualização do suporte a DNS para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) no *Manual do usuário da Amazon VPC*. 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. Se você for novo no Route 53, escolha **Get started** (Conceitos básicos) Se você já estiver usando o Route 53, escolha **Hosted zones** (Zonas hospedadas) no painel de navegação. 1. Escolha **Create hosted zone** (Criar zona hospedada). 1. No painel **Create private hosted zone** (Criar zona hospedada privada), insira um nome de domínio e, se quiser, um comentário. Para obter informações sobre como especificar caracteres que não sejam a-z, 0-9 e - (hífen) e como especificar nomes de domínio internacionalizados, consulte [Formato de nome de domínio DNS](DomainNameFormat.md). 1. Na lista **Type** (Tipo), escolha **Private Hosted Zone** (Zona hospedada privada). 1. Na lista **ID da VPC**, escolha a VPC que você deseja associar à zona hospedada. **nota** Se o console exibir a seguinte mensagem, significa que você está tentando associar uma zona hospedada que usa o mesmo namespace que o de outra zona hospedada na mesma VPC: "Um domínio conflitante já está associado à VPC ou ao conjunto de delegação especificado". Por exemplo, se a zona hospedada A e a zona B hospedadas tiverem o mesmo nome de domínio, por exemplo `example.com`, você não poderá associar ambas as zonas hospedadas à mesma VPC. 1. Escolha **Create hosted zone** (Criar zona hospedada). # Listar zonas hospedadas privadas Você pode usar o console do Amazon Route 53 para listar todas as zonas hospedadas que você criou com a AWS conta atual. Para obter informações sobre como listar zonas hospedadas usando a API do Route 53, consulte [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)a *Referência da API do Amazon Route 53*. **Para listar as zonas hospedadas associadas a uma AWS conta** 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 **Zonas hospedadas**. A página **Zonas hospedadas** exibe automaticamente uma lista de todas as zonas hospedadas que foram criadas usando a AWS conta atual. A coluna **Tipo** indica se a zona hospedada é privada ou pública. Escolha o cabeçalho da coluna para agrupar todas as zonas hospedadas privadas e públicas. # Associando mais a VPCs uma zona hospedada privada Você pode usar o console do Amazon Route 53 para associar mais VPCs a uma zona hospedada privada se tiver criado a zona hospedada e a VPCs usando a mesma AWS conta. **Importante** Se você quiser associar o VPCs que você criou usando uma conta a uma zona hospedada privada que você criou usando uma conta diferente, primeiro você deve autorizar a associação. Além disso, você não pode usar o AWS console para autorizar a associação ou associá-la à VPCs zona hospedada. Para obter mais informações, consulte [Associando uma Amazon VPC e uma zona hospedada privada que você criou com contas diferentes AWS](hosted-zone-private-associate-vpcs-different-accounts.md). Para obter informações sobre como associar mais VPCs a uma zona hospedada privada usando a API do Route 53, consulte [Associate VPCWith HostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html) in the *Amazon Route 53 API Reference*. **Para associar mais VPCs a uma zona hospedada privada usando o console do Route 53** 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 **Zonas hospedadas**. 1. Escolha o botão de rádio para a zona hospedada privada à qual você deseja se associar mais VPCs . 1. Escolha **Editar**. 1. Escolha **Add VPC** (Adicionar VPC) 1. Escolha a região e o ID da VPC que você quer associar a esta zona hospedada. 1. Para associar mais VPCs a essa zona hospedada, repita as etapas 5 e 6. 1. Escolha **Salvar alterações**. # Associando uma Amazon VPC e uma zona hospedada privada que você criou com contas diferentes AWS Se você quiser associar uma VPC criada a uma AWS conta a uma zona hospedada privada criada com uma conta diferente, execute o procedimento a seguir: **Para associar uma Amazon VPC e uma zona hospedada privada que você criou com contas diferentes AWS** 1. Usando a conta com a qual você criou a zona hospedada, autorize a associação da VPC à zona hospedada privada de uma destas formas: + **AWS CLI**— Veja [create-vpc-association-authorization](https://docs.aws.amazon.com/cli/latest/reference/route53/create-vpc-association-authorization.html)na *Referência de AWS CLI Comandos* + ** AWS SDK** ou **AWS Tools for Windows PowerShell**— Consulte a documentação aplicável na página de [AWS documentação](https://docs.aws.amazon.com/) + **API do Amazon Route 53** — Consulte [Criar VPCAssociation autorização](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) na *referência da API do Amazon Route 53* Observe o seguinte: + Se você quiser associar várias VPCs que você criou a uma conta a uma zona hospedada criada com uma conta diferente, envie uma solicitação de autorização para cada VPC. + Ao autorizar a associação, você precisa especificar o ID da zona hospedada. Por isso, a zona hospedada privada deve ser existente. + Não é possível usar o console do Route 53 para realizar ou autorizar a associação de uma VPC à zona hospedada privada. 1. Usando a conta com a qual a VPC foi criada, associe a VPC à zona hospedada. Assim como na autorização da associação, você pode usar o AWS SDK, o Tools for Windows PowerShell ou a AWS CLI API do Route 53. Se você estiver usando a API, use a VPCWith HostedZone ação [Associar](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html). 1. *Recomendado*: exclua a autorização para associar a VPC à zona hospedada. Excluir a autorização não afeta a associação. Isso apenas evita que você associe a VPC à zona hospedada novamente. Se quiser reassociar a VPC à zona hospedada, repita as etapas 1 e 2 deste procedimento. **Importante** `ListHostedZonesByVPC`Retorna as zonas hospedadas com uma VPC e a `GetHostedZone` API retorna as VPCs associadas à zona hospedada. Eles consideram APIs apenas a zona hospedada à associação VPC criada pela `AssociateVPCWithHostedZone` API ou quando a zona hospedada privada é criada. Se você quiser uma lista completa das associações de zonas hospedadas a uma VPC, ligue também. [ListProfileResourceAssociations](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53profiles_ListProfileResourceAssociations.html) **nota** Para ver o número máximo de autorizações que podem ser criadas, consulte [Cotas em entidades](DNSLimitations.md#limits-api-entities). # Desassociando-se VPCs de uma zona hospedada privada Você pode usar o console do Amazon Route 53 para se desassociar VPCs de uma zona hospedada privada. Isso faz com que o Route 53 interrompa o tráfego de roteamento usando registros na zona hospedada para consultas DNS originadas na VPC. Por exemplo, se a zona hospedada example.com estiver associada a uma VPC e você desassociar a zona hospedada dessa VPC, o Route 53 parará de resolver consultas DNS para example.com ou qualquer um dos outros registros na zona hospedada example.com. **nota** Não é possível desassociar a última VPC de uma zona hospedada privada. Se você quiser desassociar essa VPC, primeiro deverá associar outra VPC à zona hospedada. **Para se desassociar VPCs de uma zona hospedada privada** 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 **Zonas hospedadas**. 1. Escolha o botão de rádio para a zona hospedada privada da qual você deseja desassociar uma ou mais VPCs . 1. Escolha **Editar**. 1. Escolha **Remove VPC** (Remover VPC) ao lado da VPC que você quer desassociar dessa zona hospedada. 1. Escolha **Salvar alterações**. # Excluir uma zona hospedada privada Esta seção explica como excluir uma zona hospedada privada usando o console do Amazon Route 53. Você só pode excluir uma zona hospedada privada se não houver outros registros que não sejam os registros padrão de SOA e de NS. Se a sua zona hospedada contiver outros registros, você precisará excluí-los antes de excluir a zona hospedada. Isso evita que você exclua acidentalmente uma zona hospedada que ainda contém registros. **Topics** + [Excluir zonas hospedadas privadas que foram criadas por outro serviço](#delete-private-hosted-zone-created-by-another-service) + [Como usar o console do Route 53 para excluir uma zona hospedada privada](#delete-private-hosted-zone-procedure) ## Excluir zonas hospedadas privadas que foram criadas por outro serviço Se uma zona hospedada privada foi criada por outro serviço, você não pode excluí-la usando o console do Route 53. Em vez disso, você precisa usar o processo aplicável para outros serviços: + **AWS Cloud Map**— Para excluir uma zona hospedada AWS Cloud Map criada quando você criou um namespace DNS privado, exclua o namespace. AWS Cloud Map exclui a zona hospedada automaticamente. Para obter mais informações, consulte [Excluir namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) no *Guia do desenvolvedor do AWS Cloud Map *. + ** Descoberta de serviço do Amazon Elastic Container Service (Amazon ECS)**: para excluir uma zona hospedada privada que o Amazon ECS criou quando você criou um serviço usando a descoberta de serviço, exclua os serviços do Amazon ECS que estão usando o namespace e exclua o namespace. Para obter mais informações, consulte [Como excluir um serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. ## Como usar o console do Route 53 para excluir uma zona hospedada privada Para usar o console do Route 53 para excluir uma zona hospedada privada, execute o procedimento a seguir. **Para excluir uma zona hospedada privada usando o console do Route 53.** 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. Verifique se a zona hospedada que você deseja excluir contém apenas um registro NS e SOA. Se houver registros adicionais nas zonas hospedadas, exclua-os: 1. Escolha o nome da zona hospedada que você deseja excluir. 1. Na página **Record** (Registro), se a lista de registros incluir quaisquer registros para os quais o valor da coluna **Tipo** for diferente de **NS** ou **SOA**, escolha a linha e **Delete** (Excluir). Para selecionar vários registros consecutivos, escolha a primeira linha, mantenha a tecla **Shift** pressionada e selecione a última linha. Para selecionar vários registros não consecutivos, escolha a primeira linha, mantenha a tecla **Ctrl** pressionada e selecione as demais linhas. 1. Na página Zonas hospedadas, escolha a linha da zona hospedada que você deseja excluir. 1. Escolha **Excluir**. 1. Digite a chave de confirmação e escolha **Delete** (Excluir). # Permissões da VPC [As permissões de VPC usam a condição de política de gerenciamento de identidade e acesso (IAM) para permitir que você defina permissões granulares VPCs ao usar [Associar VPCWithHostedZone, [Desassociar](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisassociateVPCFromHostedZone.html)](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html), [Criar VPCAssociation Autorização VPCFromHostedZone, [Excluir VPCAssociation Autorização](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html)](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) e VPC. [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)ListHostedZonesBy](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZonesByVPC.html) APIs Com a condição de política do IAM`route53:VPCs`, você pode conceder direitos administrativos granulares a outros AWS usuários. Isso permite que você conceda a alguém permissões para associar uma zona hospedada, desassociar uma zona hospedada, criar uma autorização de associação de VPC, excluir uma autorização de associação de VPC, criar uma zona hospedada ou listar zonas hospedadas para: + Uma única VPC. + Qualquer VPCs um dentro da mesma região. + Múltiplo VPCs. Para obter mais informações sobre permissões de VPC, consulte [Uso de condições de política do IAM para controle de acesso refinado](specifying-conditions-route53.md). Para saber como autenticar AWS usuários, consulte [Autenticação com identidades](security-iam.md#security_iam_authentication) e saiba como controlar o acesso aos recursos do Route 53, consulte[Controle de acesso](security-iam.md#access-control). # Migrando uma zona hospedada para uma conta diferente AWS Ao migrar uma zona hospedada para outra Conta da AWS, siga estas etapas recomendadas. Essas etapas são mais adequadas para zonas hospedadas com alterações de registro pouco frequentes. Para zonas hospedadas com atualizações de registros frequentes, considere o seguinte: + Não atualize nenhum registro de recursos durante a migração. + Publique alterações de registros de recursos nas zonas hospedadas antigas e novas após a transferência da delegação. **Pré-requisitos** Instale ou atualize o AWS CLI: Para obter informações sobre como baixar, instalar e configurar o AWS CLI, consulte o [Guia do AWS Command Line Interface usuário](https://docs.aws.amazon.com/cli/latest/userguide/). **nota** Configure a CLI de forma que você possa usá-la quando estiver usando tanto a conta que criou a zona hospedada quanto a conta para onde está migrando a zona hospedada. Para obter mais informações, consulte [Configurar](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) no *Guia do usuário da AWS Command Line Interface *. Se você já estiver usando o AWS CLI, recomendamos que você atualize para a versão mais recente da CLI para que os comandos da CLI suportem os recursos mais recentes do Route 53. **Topics** + [Etapa 1: Preparar-se para a migração](#hosted-zones-migrating-prepare) + [Etapa 2: criar uma nova zona hospedada](#hosted-zones-migrating-create-hosted-zone) + [Etapa 3: (Opcional) Migrar verificações de integridade](#hosted-zones-migrating-health-checks) + [Etapa 4: Migrar registros da antiga zona hospedada para a nova](#hosted-zones-migrating-old-to-new) + [Etapa 5: comparar registros nas zonas hospedadas antigas e novas](#hosted-zones-migrating-compare) + [Etapa 6: Atualizar o registro do domínio para usar servidores de nomes para a nova zona hospedada](#hosted-zones-migrating-update-domain) + [Etapa 7: Alterar o TTL do registro NS de volta para um valor mais alto](#hosted-zones-migrating-change-ttl) + [Etapa 8: Reabilite a assinatura de DNSSEC e estabeleça a cadeia de confiança (se necessário)](#hosted-zones-migrating-enable-dnssec) + [Etapa 9: (opcional) excluir a antiga zona hospedada](#hosted-zones-migrating-delete-old-hosted-zone) ## Etapa 1: Preparar-se para a migração As etapas de preparação ajudam você a minimizar os riscos associados à migração de uma zona hospedada. **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 levar à reversão da migração. Você pode monitorar seus nomes de domínio com maior tráfego usando CloudWatch ou consultando o registro. 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. No entanto, ele não deve ser o único sinal para determinar a necessidade de uma reversão, pois você também pode receber feedback dos seus clientes devido à indisponibilidade de um domínio. **2. Diminuir a configuração de TTL** A configuração de TTL (vida útil) de um registro especifica por quanto tempo você deseja que os resolvedores de DNS armazenem o registro e usem as informações em cache. Quando o TTL expira, um resolvedor envia outra consulta para o provedor de serviço de DNS para um domínio a fim de obter as informações mais recentes. A configuração de TTL típica para o registro de NS é de 172.800 segundos, ou dois dias. O registro de NS lista os servidores de nome que o Sistema de Nomes de Domínio (DNS) pode usar para obter informações sobre como direcionar o tráfego para o seu domínio. Reduzir o TTL do registro de NS, tanto no provedor de serviço DNS atual quanto no Route 53, reduz o tempo de inatividade do seu domínio quando você descobre um problema durante a migração do DNS para o Route 53. Se você não reduzir o TTL, seu domínio pode ficar indisponível na Internet por até dois dias se algo der errado. **Para diminuir o TTL** 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. Escolha **Zonas hospedadas** no painel de navegação. 1. Escolha o nome da zona hospedada. 1. Escolha o registro NS e, no painel **Detalhes do registro**, escolha **Editar registro**. 1. Altere o valor de **TTL (Seconds)** (TTL [segundos]). Recomendamos que você especifique um valor entre 60 segundos e 900 segundos (15 minutos). 1. Escolha **Salvar**. **3. Remova o registro DS da zona principal (se você tiver o DNSSEC configurado).** Se você configurou o DNSSEC para seu domínio, remova o registro DS (Delegation Signer) da zona pai antes de migrar seu domínio para o Route 53. Se a zona principal estiver hospedada por meio do Route 53, consulte [Excluir chaves públicas de um domínio](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys) para saber mais. Caso a zona principal esteja hospedada em outro registrador, entre em contato com ele para remover o registro DS. Atualmente, o Route 53 não oferece suporte para a migração da configuração DNSSEC. Por isso, você precisará desabilitar a validação de DNSSEC realizada no seu domínio antes da migração, removendo o registro DS da zona principal. Após a migração, você pode reabilitar a validação de DNSSEC configurando o DNSSEC na nova zona hospedada e adicionando o respectivo registro DS à zona principal. **4. Certifique-se de que não haja outras operações em andamento que dependam da zona hospedada em migração** Algumas operações dependerão da resolução de DNS na zona hospedada em migração. Por exemplo, o processo de renovação do TLS/SSL certificado pode exigir alterações no registro DNS e o provedor tentará resolver o registro DNS como método de validação. Antes da migração, você deve se certificar de que nenhuma outra operação esteja acontecendo, a fim de evitar um impacto inesperado da migração da zona hospedada. ## Etapa 2: criar uma nova zona hospedada Crie a nova zona hospedada na conta cuja zona hospedada você deseja migrar. Escolha a guia para obter as instruções do console AWS CLI ou do console. + [CLI](#migrate-hz-cli) + [Console](#migrate-hz-console) ------ #### [ CLI ] Digite o comando: ``` aws route53 create-hosted-zone \ --name $hosted_zone_name \ --caller-reference $unique_string ``` Para obter mais informações, consulte [create-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/create-hosted-zone.html). ------ #### [ Console ] **Para criar a nova zona hospedada usando uma conta diferente** 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/). Faça login com as credenciais da conta para a qual você deseja migrar a zona hospedada. 1. Crie uma zona hospedada. Para obter mais informações, consulte [Criar uma zona hospedada pública](CreatingHostedZone.md). 1. Anote o ID da zona hospedada. Em alguns casos, você precisará dessa informação mais adiante no processo. 1. Faça logout do console do Route 53. Diminua também o NS TTL na nova zona, semelhante à configuração Diminuir TTL na Etapa de preparação 1, configuração Diminuir TTL. ------ ## Etapa 3: (Opcional) Migrar verificações de integridade Você pode associar registros de DNS na nova conta às verificações de integridade do Route 53 da conta da qual você está migrando. Para migrar uma verificação de integridade do Route 53, você precisa criar novas verificações de integridade na nova conta com a mesma configuração das existentes. Para obter mais informações, consulte [Criação de verificações de integridade do Amazon Route 53](dns-failover.md). ## Etapa 4: Migrar registros da antiga zona hospedada para a nova Você pode migrar registros de um Conta da AWS para outro usando o console ou o. AWS CLI ------ #### [ Console ] Se a sua zona contiver apenas alguns registros, considere usar o console do Route 53 para listar os registros na sua zona antiga, anotá-los e criá-los na nova zona. Se você migrou a verificação de integridade em [Etapa 3: (Opcional) Migrar verificações de integridade](#hosted-zones-migrating-health-checks), ao criar os registros na nova zona hospedada, deve especificar a nova ID da verificação de integridade. Para saber mais, consulte os seguintes tópicos: + [Listar registros](resource-record-sets-listing.md) + [Criar registros usando o console do Amazon Route 53](resource-record-sets-creating.md) + [Configurar failover de DNS](dns-failover-configuring.md) Você também deve diminuir o NS TTL na nova zona, semelhante à configuração Diminuir TTL na Etapa 1. ------ #### [ CLI ] Se sua zona contiver um grande número de registros, você poderá exportar os registros que deseja migrar para um arquivo, editar o arquivo e, em seguida, usar o arquivo editado para criar registros na nova zona hospedada. O procedimento a seguir usa comandos da AWS CLI, embora ferramentas de terceiros também estejam disponíveis para essa finalidade. **** 1. Execute este comando: . ``` aws route53 list-resource-record-sets --hosted-zone-id hosted-zone-id > path-to-output-file ``` Observe o seguinte: + Para*hosted-zone-id*, especifique o ID da antiga zona hospedada que contém os registros que você deseja migrar. + Para *path-to-output-file*, especifique o caminho do diretório e o nome do arquivo onde você deseja salvar a saída. + O caractere `>` envia a saída para o arquivo especificado. + O manipula AWS CLI automaticamente a paginação para zonas hospedadas que contêm mais de 100 registros. Para obter mais informações, consulte [Usando as opções de paginação da interface de linha de AWS comando](https://docs.aws.amazon.com/cli/latest/userguide/pagination.html) no Guia do *AWS Command Line Interface usuário*. Se você usar outro método programático para listar registros, como um dos AWS SDKs, poderá obter no máximo 100 registros por página de resultados. Se a zona hospedada contiver mais de 100 registros, você terá que enviar várias solicitações para listar todos os registros. Faça uma cópia dessa saída. Depois de criar registros na nova zona hospedada, recomendamos que você execute o AWS CLI `list-resource-record-sets` comando na nova zona hospedada e compare as duas saídas para garantir que todos os registros foram criados. 1. Edite os registros que você deseja migrar. Edite o arquivo exportado antes de usá-lo com o comando `change-resource-record-sets`. Você pode fazer essas alterações usando a função de pesquisa e substituição em um editor de texto. **nota** As etapas a seguir descrevem a edição manual conm um editor de texto. Usuários avançados podem automatizar essas transformações usando ferramentas programáticas como jq, Python ou outras linguagens de scripts. Abra uma cópia do arquivo criado na etapa 1 deste procedimento, contendo os registros que você deseja migrar, e faça as seguintes alterações: + Substitua o ResourceRecordSets elemento na parte superior do arquivo pelo `Changes` elemento. + Opcional: adicione um elemento `Comment`. + Exclua as linhas relacionadas aos registros NS e SOA do nome da zona hospedada. A nova zona hospedada já tem esses registros. + Para cada registro, adicione um `Action` e um elemento `ResourceRecordSets`, adicione colchetes de abertura e fechamento (`{ }`) conforme necessário para tornar o código JSON válido. **nota** Você pode usar um validador JSON para verificar se todas as chaves e colchetes estão nos locais corretos. Para encontrar um validador JSON online, pesquise “validador JSON” no navegador. + Se a zona hospedada contiver algum alias que faça referência a outros registros na mesma zona hospedada, faça as seguintes alterações: + Altere o ID da zona hospedada para o ID da nova zona hospedada. **Importante** Se o registro do alias estiver apontando para outro recurso, por exemplo, um balanceador de carga, não altere o ID da zona hospedada para o ID da zona hospedada do domínio. Se você alterar o ID da zona hospedada acidentalmente, reverta o ID da zona hospedada para o ID da zona hospedada do próprio recurso, não para o ID da zona hospedada do domínio. O ID da zona hospedada do recurso pode ser encontrado no AWS console em que o recurso foi criado. + Mova os registros de alias para a parte inferior do arquivo. O Route 53 deve criar o registro ao qual um registro de alias se refere antes de criar o registro de alias. **Importante** Se um ou mais registros de alias se referem a outros registros de alias, os registros que são o destino do alias devem aparecer no arquivo antes dos registros de alias que fazem a referência. Por exemplo, se `alias.example.com` for o destino de alias para `alias.alias.example.com`, `alias.example.com` deve aparecer primeiro no arquivo. + Exclua os registros de alias que roteiam o tráfego para uma instância de política de tráfego. Anote os registros para que você possa recriá-los posteriormente. + Se você migrou as verificações de saúde[Etapa 3: (Opcional) Migrar verificações de integridade](#hosted-zones-migrating-health-checks), altere os registros para associá-los à verificação IDs de saúde recém-criada. O exemplo a seguir mostra a versão editada dos registros de uma zona hospedada para example.com. O texto em itálico vermelho, é novo: ``` { "Comment": "string", "Changes": [ { "Action": "CREATE", "ResourceRecordSet":{ "ResourceRecords": [ { "Value": "192.0.2.4" }, { "Value": "192.0.2.5" }, { "Value": "192.0.2.6" } ], "Type": "A", "Name": "route53documentation.com.", "TTL": 300 } }, { "Action": "CREATE", "ResourceRecordSet":{ "AliasTarget": { "HostedZoneId": "Z3BJ6K6RIION7M", "EvaluateTargetHealth": false, "DNSName": "s3-website-us-west-2.amazonaws.com." }, "Type": "A", "Name": "www.route53documentation.com." } } ] } ``` 1. Dividir arquivos grandes em arquivos menores Se você tiver uma grande quantidade de registros ou se tiver registros que têm uma grande quantidade de valores (por exemplo, uma grande quantidade de endereços IP), pode ser necessário dividir o arquivo em arquivos menores. Os valores máximos são: + Cada arquivo pode ter um máximo de 1.000 registros. + O tamanho máximo combinado dos valores em todos os elementos `Value` é de 32.000 bytes. 1. Criar registros na nova zona hospedada Insira a seguinte CLI: ``` aws route53 change-resource-record-sets \ --hosted-zone-id new-hosted-zone-id \ --change-batch file://path-to-file-that-contains-records ``` Especifique os seguintes valores: + Para `new-hosted-zone-id`, especifique o ID da nova zona hospedada. + Para `path-to-file-that-contains-records`, especifique o caminho do diretório e o nome do arquivo que você editou nas etapas anteriores. Se você tiver excluído os registros de alias que encaminham o tráfego para uma instância de política de tráfego, recrie-os usando o console do Route 53. Para obter mais informações, consulte [Criar registros usando o console do Amazon Route 53](resource-record-sets-creating.md). ------ ## Etapa 5: comparar registros nas zonas hospedadas antigas e novas Para confirmar que você criou com êxito todos os seus registros na nova zona hospedada, digite o seguinte comando da CLI para listar os registros na nova zona hospedada e compare a saída com a lista de registros da zona hospedada antiga. ``` aws route53 list-resource-record-sets \ --hosted-zone-id new-hosted-zone-id \ --output json > path-to-output-file ``` Especifique os seguintes valores: + Para `new-hosted-zone-id`, especifique o ID da nova zona hospedada. + Para `path-to-output-file`, especifique o caminho do diretório e o nome do arquivo onde você deseja salvar a saída. Use um nome de arquivo que seja diferente do nome do arquivo que você usou na Etapa 4. O caractere `>` envia a saída para o arquivo especificado. Compare a saída obtida com a saída da Etapa 4. Além dos valores dos registros NS e SOA e de quaisquer alterações feitas na Etapa 4 (como nomes diferentes de zona hospedada IDs ou de domínio), as duas saídas devem ser idênticas. Se os registros na nova zona hospedada não correspondem aos registros na antiga zona hospedada, faça uma das seguintes ações: + Faça pequenas correções usando o console do Route 53. Para obter mais informações, consulte [Editar registros](resource-record-sets-editing.md). + Exclua todos os registros, exceto os registros NS e SOA na nova zona hospedada, e repita o procedimento na Etapa 4. ## Etapa 6: Atualizar o registro do domínio para usar servidores de nomes para a nova zona hospedada Quando terminar de migrar os registros para a nova zona hospedada, altere os servidores de nomes para o registro do domínio para usar os servidores de nomes da nova zona hospedada. Para obter mais informações, consulte Tornar o Amazon Route 53 o serviço de DNS para um domínio existente. Se sua zona hospedada estiver em uso — por exemplo, se seus usuários estiverem usando o nome de domínio para navegar em um site ou acessar uma aplicação Web —, você deve continuar monitorando o tráfego e a disponibilidade da zona hospedada, incluindo o tráfego do site ou da aplicação, e-mail etc. + **Se o tráfego diminuir ou for interrompido**: altere o serviço de nome do registro de domínio de volta para os servidores de nomes anteriores da zona hospedada antiga. Em seguida, determine o que deu errado. + **Se o tráfego não for afetado**: continue na próxima etapa. ## Etapa 7: Alterar o TTL do registro NS de volta para um valor mais alto Na nova zona hospedada, altere o TTL do registro NS para um valor mais comum, por exemplo, 172.800 segundos (dois dias). Isso melhora a latência para seus usuários, pois eles não precisam esperar que os resolvedores de DNS enviem uma consulta para os servidores de nome do seu domínio. **Para alterar o TTL** 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. Escolha **Zonas hospedadas** no painel de navegação. 1. Escolha o nome da zona hospedada. 1. Escolha o registro NS e, no painel **Detalhes do registro**, escolha **Editar registro**. 1. Altere o valor de **TTL (segundos)** para o número de segundos que você deseja que os resolvedores de DNS armazenem em cache os nomes dos servidores de nome do seu domínio. Recomendamos um valor de 172.800 segundos. 1. Escolha **Salvar**. ## Etapa 8: Reabilite a assinatura de DNSSEC e estabeleça a cadeia de confiança (se necessário) Não é possível reabilitar a assinatura de DNSSEC em duas etapas: 1. Habilitar a assinatura de DNSSEC para o Route 53 e solicitar que o Route 53 crie uma chave de assinatura da chave (KSK) com base em uma chave gerenciada pelo cliente no AWS Key Management Service. 1. Criar uma cadeia de confiança para a zona hospedada adicionando um registro DS (Delegation Signer) à zona pai, para que as respostas DNS possam ser autenticadas com assinaturas criptográficas confiáveis. Para instruções, consulte [Como habilitar a assinatura de DNSSEC e estabelecer uma cadeia de confiança](dns-configuring-dnssec-enable-signing.md). ## Etapa 9: (opcional) excluir a antiga zona hospedada Opcionalmente, quando você estiver certo de que não precisa mais da zona hospedada antiga, poderá excluí-la. Para instruções, consulte [Excluir uma zona hospedada pública](DeleteHostedZone.md). **Importante** Não exclua a zona hospedada antiga ou quaisquer registros nessa zona hospedada por pelo menos 48 horas depois de atualizar o registro do domínio para usar servidores de nome da nova zona hospedada. Se você excluir a zona hospedada antiga antes dos resolvedores DNS pararem de usar os registros nessa zona hospedada, seu domínio poderá estar indisponível na Internet até que os resolvedores comecem a usar a nova zona hospedada. # Trabalhar com registros Depois de criar uma zona hospedada para seu domínio, como exemplo.com, você cria registros para informar ao Domain Name System (DNS) como deseja que o tráfego seja roteado para esse domínio. Por exemplo, você pode criar registros que fazem com que o DNS faça o seguinte: + Roteie tráfego de Internet de exemplo.com para o endereço IP de um host no seu data center. + Roteie e-mail desse domínio (ichiro@exemplo.com) para um servidor de e-mail (mail.exemplo.com). + Roteie o tráfego de um subdomínio chamado operacoes.toquio.exemplo.com para o endereço IP de um host diferente. Cada registro inclui o nome de um domínio ou subdomínio, um tipo de registro (por exemplo, um registro com um tipo MX roteia o e-mail) e outras informações aplicáveis ao tipo de registro (para registros MX, o nome de host de um ou mais servidores de e-mail e uma prioridade para cada servidor). Para obter informações sobre os tipos diferentes de registros, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). O nome de cada registro em uma zona hospedada deve terminar com o nome da zona hospedada. Por exemplo, a zona hospedada exemplo.com pode conter registros dos subdomínios www.exemplo.com e contabilidade.toquio.exemplo.com, mas não pode conter registros de um subdomínio www.exemplo.ca. **nota** Para criar registros para configurações de roteamento complexas, você também pode usar o editor visual de Fluxo de tráfego e salvar a configuração como uma política de tráfego. Em seguida, é possível associar a política de tráfego a um ou mais nomes de domínio (como example.com) ou nomes de subdomínio (como www.example.com), na mesma ou em várias zonas hospedadas. Além disso, você poderá reverter as atualizações se a nova configuração não estiver sendo executada conforme o esperado. Para obter mais informações, consulte [Uso do Fluxo de tráfego para rotear tráfego de DNS](traffic-flow.md). O Amazon Route 53 não cobra pelos registros que você adiciona a uma zona hospedada. Para obter informações sobre o número máximo de registros que podem ser criados em uma zona hospedada, consulte [Cotas](DNSLimitations.md). **Topics** + [Escolher uma política de roteamento](routing-policy.md) + [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md) + [Tipos de registro de DNS com suporte](ResourceRecordTypes.md) + [Criar registros usando o console do Amazon Route 53](resource-record-sets-creating.md) + [Permissões do conjunto de registros de recursos](resource-record-sets-permissions.md) + [Valores que você especifica ao criar ou editar registros do Amazon Route 53](resource-record-sets-values.md) + [Criar registros importando um arquivo de zona](resource-record-sets-creating-import.md) + [Editar registros](resource-record-sets-editing.md) + [Excluir registros](resource-record-sets-deleting.md) + [Listar registros](resource-record-sets-listing.md) # Escolher uma política de roteamento Quando você cria um registro, é possível escolher uma política de roteamento, o que determina como o Amazon Route 53 responde a consultas: + **Simple routing policy** (Política de roteamento simples): use para um único recurso que executa uma determinada função para seu domínio, por exemplo, um servidor Web que oferece conteúdo para o site example.com. Você pode usar roteamento simples para criar registros em uma zona hospedada privada. + **Failover routing policy** (Política de roteamento de failover): use quando quiser configurar o failover ativo-passivo. Você pode usar roteamento com failover para criar registros em uma zona hospedada privada. + **Geolocation routing policy** (Política de roteamento de localização geográfica): use quando quiser encaminhar o tráfego com base na localização dos usuários. Você pode usar roteamento por geolocalização para criar registros em uma zona hospedada privada. + **Política de roteamento por geoproximidade**: use quando quiser rotear o tráfego de acordo com a localização dos recursos e, opcionalmente, mudar o tráfego dos recursos em um local para os recursos em outro local. Você pode usar roteamento por geoproximidade para criar registros em uma zona hospedada privada. + **Política de roteamento de latência** — Use quando você tiver vários recursos Regiões da AWS e quiser rotear o tráfego para a região que fornece a melhor latência. Você pode usar roteamento por latência para criar registros em uma zona hospedada privada. + **IP-based routing policy** (Política de roteamento baseado em IP): use quando quiser rotear o tráfego com base no local dos usuários e tiver os endereços IP de origem do tráfego. + **Multivalue answer routing policy** (Política de roteamento de resposta com vários valores): use quando quiser que o Route 53 responda a consultas de DNS com até oito registros íntegros selecionados aleatoriamente. Você pode usar roteamento com resposta multivalor para criar registros em uma zona hospedada privada. + **Weighted routing policy** (Política de roteamento ponderado): use para encaminhar o tráfego para vários recursos nas proporções que você especificar. Você pode usar roteamento ponderado para criar registros em uma zona hospedada privada. **Topics** + [Roteamento simples](routing-policy-simple.md) + [Roteamento de failover](routing-policy-failover.md) + [Roteamento de localização geográfica](routing-policy-geo.md) + [Roteamento por geoproximidade](routing-policy-geoproximity.md) + [Roteamento baseado em latência](routing-policy-latency.md) + [Roteamento baseado em IP](routing-policy-ipbased.md) + [Roteamento de resposta com vários valores](routing-policy-multivalue.md) + [Roteamento ponderado](routing-policy-weighted.md) + [Como o Amazon Route 53 usa EDNS0 para estimar a localização de um usuário](routing-policy-edns0.md) # Roteamento simples O roteamento simples permite configurar registros de DNS padrão sem roteamento especial do Route 53, como ponderados ou de latência. Com o roteamento simples, você normalmente roteia o tráfego para um único recurso, por exemplo, para um servidor web do seu site. Você pode usar uma política de roteamento simples para criar registros em uma zona hospedada privada. Se você escolher a política de roteamento simples no console do Route 53, não poderá criar vários registros com o mesmo nome e tipo, mas poderá especificar diversos valores no mesmo registro, como vários endereços IP. (Se você escolher a política de roteamento simples para um registro de alias, poderá especificar somente um AWS recurso ou um registro na zona hospedada atual.) Se você especificar diversos valores em um registro, o Route 53 retornará todos os valores para o resolvedor recursivo em ordem aleatória, e o resolvedor retornará os valores para o cliente (como um navegador da Web) que enviou a consulta de DNS. Em seguida, o cliente escolhe um valor e reenvia a consulta. Com uma política de roteamento simples, embora você possa especificar vários endereços IP, esses endereços IP não têm a integridade verificada. Para obter informações sobre os valores que você especifica ao usar a política de roteamento simples para criar registros, consulte os seguintes tópicos: + [Valores específicos para registros simples](resource-record-sets-values-basic.md) + [Valores específicos para registros de alias simples](resource-record-sets-values-alias.md) + [Valores que são comuns para todas as políticas de roteamento](resource-record-sets-values-shared.md) + [Valores que são comuns para registros de alias em todas as políticas de roteamento](resource-record-sets-values-alias-common.md) # Roteamento de failover O roteamento de failover permite rotear o tráfego para um recurso quando o recurso estiver íntegro ou para um recurso diferente quando o primeiro recurso não estiver íntegro. Os registros primários e secundários podem encaminhar o tráfego para qualquer ponto a partir de um bucket do Amazon S3 que é configurado como um site para uma árvore complexa de registros. Para obter mais informações, consulte [Failover ativo/passivo](dns-failover-types.md#dns-failover-types-active-passive). Você pode usar uma política de roteamento por failover para criar registros em uma zona hospedada privada. Para obter informações sobre os valores que você especifica ao usar a política de roteamento de failover para criar registros, consulte os seguintes tópicos: + [Valores específicos para registros de failover](resource-record-sets-values-failover.md) + [Valores específicos para registros de alias de failover](resource-record-sets-values-failover-alias.md) + [Valores que são comuns para todas as políticas de roteamento](resource-record-sets-values-shared.md) + [Valores que são comuns para registros de alias em todas as políticas de roteamento](resource-record-sets-values-alias-common.md) # Roteamento de localização geográfica O roteamento de localização geográfica permite que você escolha os recursos que atendem ao seu tráfego com base na localização geográfica dos usuários, isto é, o local de origem das consultas de DNS. Por exemplo, talvez você queira que todas as consultas da Europa sejam roteadas para um balanceador de carga de Elastic Load Balancing na região de Frankfurt. Quando você usa o roteamento de localização geográfica, pode traduzir o conteúdo e apresentar todo o seu site ou parte dele no idioma de seus usuários. Você também pode usar o roteamento de localização geográfica para restringir a distribuição de conteúdo somente aos locais em que você tem direitos de distribuição. Outro uso possível é balancear a carga entre os endpoints de forma previsível, de easy-to-manage forma que a localização de cada usuário seja roteada de forma consistente para o mesmo endpoint. Você pode especificar localizações geográficas por continente, país ou estado nos Estados Unidos. Se você criar registros separados para regiões geográficas sobrepostas, por exemplo, um registro para a América do Norte e outro para o Canadá, a prioridade será da menor região geográfica. Isso permite rotear algumas consultas de um continente para um recurso e rotear as consultas de determinados países naquele continente para outro recurso. (Para obter uma lista dos países de cada continente, consulte [Local](resource-record-sets-values-geo.md#rrsets-values-geo-location).) A localização geográfica funciona através do mapeamento de endereços IP para os locais. No entanto, alguns endereços IP não estão mapeados para localizações geográficas. Portanto, mesmo que você crie conjuntos de registros de recursos de localização geográfica que abranja os sete continentes, o Amazon Route 53 receberá algumas consultas de DNS de locais que ele não conseguirá identificar. Você pode criar um registro padrão que atenda tanto as consultas de endereços IP que não são mapeados para qualquer lugar quanto as consultas que vêm de locais para os quais você ainda não criou registros de localização geográfica. Se você não criar um registro padrão, o Route 53 retornará uma resposta “sem resposta” para as consultas provenientes desses locais. Você pode usar o roteamento por geolocalização para criar registros tanto em uma zona hospedada privada como pública. Para obter mais informações, consulte [Como o Amazon Route 53 usa EDNS0 para estimar a localização de um usuário](routing-policy-edns0.md). Para obter informações sobre os valores que você especifica ao usar a política de roteamento de geolocalização para criar registros, consulte os seguintes tópicos: + [Valores específicos para registros de localização geográfica](resource-record-sets-values-geo.md) + [Valores específicos para registros de alias de localização geográfica](resource-record-sets-values-geo-alias.md) + [Valores que são comuns para todas as políticas de roteamento](resource-record-sets-values-shared.md) + [Valores que são comuns para registros de alias em todas as políticas de roteamento](resource-record-sets-values-alias-common.md) # Roteamento de geolocalização em zonas hospedadas privadas Para zonas hospedadas privadas, o Route 53 responde às consultas de DNS com base na VPC da qual Região da AWS a consulta se originou. Para ver a lista de Regiões da AWS, consulte [Regiões e zonas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) no guia do *usuário do Amazon EC2*. Se a consulta ao DNS for originada de uma parte on-premises de uma rede híbrida, ela será considerada como tendo sido originada da Região da AWS em que a VPC está localizada. Se você incluir verificações de integridade, poderá criar registros padrão para: + Endereços IP que não são mapeados para localizações geográficas. + Consultas ao DNS provenientes de locais para os quais você não criou registros de geolocalização. Se o registro de geolocalização para a região da consulta ao DNS não estiver íntegro, o registro padrão será retornado (se estiver íntegro). No exemplo de configuração na figura a seguir, as consultas de DNS provenientes de um us-east-1 Região da AWS (Virgínia) serão roteadas para o endpoint 1.1.1.1. ![\[Uma captura de tela que mostra um registro de geolocalização para uma zona hospedada privada.\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/images/geolocation-phz.png) # Roteamento por geoproximidade O roteamento de proximidade geográfica permite que o Amazon Route 53 encaminhe o tráfego para seus recursos com base no local geográfico de seus usuários e recursos. Ele roteia o tráfego para o recurso mais próximo disponível. Você também pode optar por rotear mais ou menos tráfego para um determinado recurso especificando um valor, conhecido como *desvio*. Um desvio aumenta ou diminui o tamanho da região geográfica em que o tráfego é roteado para um recurso. Você cria regras de geoproximity para seus recursos e especifica um dos seguintes valores para cada regra: + Se você estiver usando AWS recursos, especifique o Região da AWS ou o Grupo de Zona Local no qual você criou o recurso. + Se você não estiver usando AWS recursos, especifique a latitude e a longitude do recurso. Para usar as Zonas AWS Locais, você precisa primeiro habilitá-las. Para mais informações, consulte [Getting started with Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html) no *AWS Local Zones User Guide*. Para saber mais sobre a diferença entre Zonas Locais Regiões da AWS e Zonas Locais, consulte [Regiões e Zonas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) no Guia do *Usuário do Amazon EC2*. Opcionalmente, para alterar o tamanho da região geográfica da qual o Route 53 encaminha o tráfego para um recurso, especifique o valor aplicável para o desvio: + Para aumentar o tamanho da região geográfica da qual o Route 53 encaminha o tráfego para um recurso, especifique um inteiro positivo de 1 a 99 para o desvio. O Route 53 diminui o tamanho das regiões adjacentes. + Para reduzir o tamanho da região geográfica da qual o Route 53 encaminham o tráfego para um recurso, especifique um inteiro negativo de -1 a -99 para o desvio. O Route 53 aumenta o tamanho das regiões adjacentes. **nota** Estamos atualizando o console do Fluxo de tréfego do Route 53. Durante o período de transição, você pode continuar a usar o console antigo. Escolha a guia do console que você está usando. + [Novo console](#traffic-flow-geoprox-routing-map-new) + [Console antigo](#traffic-flow-geoprox-routing-map-old) ------ #### [ New console ] O mapa a seguir mostra quatro Regiões da AWS (numerados de 1 a 5): 1. Oeste dos EUA (Oregon) 1. Europa (Frankfurt) 1. Ásia-Pacífico (Tóquio) 1. África (Cidade do Cabo) 1. Oriente Médio (Bahrein) **nota** Os mapas só estão disponíveis com Fluxo de tráfego. ![\[Um mapa do mundo que mostra como o tráfego é roteado quando você tem registros de geoproximidade para recursos nas Regiões da AWS Oeste dos EUA (Oregon), Europa (Frankfurt), Ásia-Pacífico (Tóquio), África (Cidade do Cabo) e Oriente Médio (Bahrein).\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png) O mapa a seguir mostra o que acontece se você adicionar um viés de \$125 para a região Oeste dos EUA (Oregon) (número **1** no mapa). O tráfego é direcionado para o recurso nessa região a partir de uma área maior da América do Norte e de toda a América do Sul do que antes. ![\[Um mapa do mundo que mostra como o tráfego é encaminhado quando você adiciona um desvio de +25 na região Leste dos EUA (Norte da Virgínia).\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png) O mapa a seguir mostra o que acontece quando você altera o viés para -25 para a região Oeste dos EUA (Oregon). **O tráfego é roteado para o recurso nessa região a partir de porções menores da América do Norte e do Sul do que antes, e mais tráfego é roteado para recursos nas regiões adjacentes **2**, **3** e 4.** ![\[Um mapa do mundo que mostra como o tráfego é roteado quando você adiciona um viés de -25 na região Oeste dos EUA (Oregon).\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png) ------ #### [ Old console ] O mapa a seguir mostra quatro Regiões da AWS (numerados de 1 a 4) e uma localização em Joanesburgo, África do Sul, especificada por latitude e longitude (5). **nota** Os mapas só estão disponíveis com Fluxo de tráfego. ![\[Um mapa do mundo que mostra como o tráfego é roteado quando você tem registros de geoproximidade para recursos no Oeste dos Regiões da AWS EUA (Oregon), Leste dos EUA (Norte da Virgínia), Europa (Paris) e Ásia-Pacífico (Tóquio), e você tem um registro de um não AWS recurso em Joanesburgo, África do Sul.\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png) O mapa a seguir mostra o que acontece se você adicionar um desvio de \$125 para a região Leste dos EUA (N. da Virgínia) (número **2** no mapa). O tráfego é roteado para o recurso nessa região de uma parte maior da América do Norte que anteriormente, e de toda a América do Sul. ![\[Um mapa do mundo que mostra como o tráfego é encaminhado quando você adiciona um desvio de +25 na região Leste dos EUA (Norte da Virgínia).\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png) O mapa a seguir mostra o que acontece se você alterar o desvio para -25 para a região Leste dos EUA (N. da Virgínia). O tráfego é roteado para o recurso nessa região de partes menores da América do Norte e do Sul do que anteriormente, e mais tráfego é roteado para os recursos nas regiões adjacentes **1**, **3**, e **5**. ![\[Um mapa do mundo que mostra como o tráfego é roteado quando você adiciona um desvio de -25 na região Leste dos EUA (N. da Virgínia).\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png) ------ O efeito da alteração do desvio para seus recursos depende de uma série de fatores, incluindo: + O número de recursos que você tem. + A proximidade de um para outro. + O número de usuários que você tem perto da área de borda entre as regiões geográficas. Por exemplo, suponha que você tenha recursos no Leste dos Regiões da AWS EUA (Norte da Virgínia) e no Oeste dos EUA (Oregon) e tenha muitos usuários em Dallas, Austin e San Antonio, Texas, EUA. Essas cidades são aproximadamente equidistantes entre seus recursos, portanto, uma pequena mudança no viés pode resultar em uma grande variação no tráfego de recursos de uma Região da AWS para outra. Recomendamos alterar o desvio em pequenos incrementos para evitar a sobrecarga dos recursos devido a uma oscilação imprevista no tráfego. Para obter mais informações, consulte [Como o Amazon Route 53 usa EDNS0 para estimar a localização de um usuário](routing-policy-edns0.md). ## Como o Amazon Route 53 usa o desvio para encaminhar o tráfego Esta é a fórmula que o Amazon Route 53 usa para determinar como encaminhar o tráfego: **Desvio** `Biased distance = actual distance * [1 - (bias/100)]` Quando o valor do viés é positivo, o Route 53 trata a origem de uma consulta de DNS e o recurso que você especifica em um registro de geoproximidade (como uma instância do EC2 em um Região da AWS) como se estivessem mais próximos do que realmente estão. Por exemplo, suponha que você tem uma solicitação com os seguintes registros de geoproximity: + Um registro para o servidor web A, que tem um desvio positivo de 50 + Um registro para o servidor web B, que não tem desvio Quando um registro de proximidade geográfica tem um desvio positivo de 50, o Route 53 divide a distância pela metade entre a origem de uma consulta e o recurso para esse registro. Em seguida, o Route 53 calcula qual recurso está mais próximo da origem da consulta. Suponha que o servidor web A está a 150 km da origem de uma consulta e o servidor web B está a 100 km da origem da consulta. Se nenhum dos registros tiver um desvio, o Route 53 encaminha a consulta para o servidor Web B, pois ele é o mais próximo. No entanto, como o registro do servidor Web A tem um desvio positivo de 50, o Route 53 trata o servidor Web A como se ele estivesse a 75 km da origem da consulta. Como resultado, o Route 53 encaminha a consulta para o servidor Web A. Este é o cálculo para um desvio positivo de 50: ``` Bias = 50 Biased distance = actual distance * [1 - (bias/100)] Biased distance = 150 kilometers * [1 - (50/100)] Biased distance = 150 kilometers * (1 - .50) Biased distance = 150 kilometers * (.50) Biased distance = 75 kilometers ``` # Roteamento baseado em latência Se seu aplicativo estiver hospedado em vários Regiões da AWS, você pode melhorar o desempenho de seus usuários atendendo às solicitações a partir do Região da AWS que fornece a menor latência. **nota** Os dados sobre a latência entre usuários e seus recursos são baseados totalmente no tráfego entre usuários e data centers da AWS . Se você não estiver usando recursos em um Região da AWS, a latência real entre seus usuários e seus recursos pode variar significativamente dos dados de AWS latência. Isso ocorre mesmo se os recursos estiverem na mesma cidade que uma Região da AWS. Para usar o roteamento baseado em latência, crie registros de latência para os recursos em várias Regiões da AWS. Quando o Route 53 recebe uma consulta ao DNS do seu domínio ou subdomínio (exemplo.com ou acme.exemplo.com), ele determina para quais Regiões da AWS você criou registros de latência, determina qual região oferece ao usuário a menor latência e então seleciona um registro de latência para essa região. O Route 53 responde com o valor do registro selecionado, como o endereço IP de um servidor Web. Por exemplo, suponha que você tenha balanceadores de carga de Elastic Load Balancing na região Oeste dos EUA (Oregon) e na região Ásia-Pacífico (Singapura). Você cria um registro de latência para cada balanceador de carga. Veja o que acontece quando um usuário em Londres informa o nome de seu domínio em um navegador: 1. O DNS encaminha a consulta para um servidor de nome do Route 53. 1. O Route 53 consulta seus dados sobre latência entre Londres e a região de Singapura e entre Londres e a região de Oregon. 1. Se a latência for menor entre as regiões de Londres e Oregon, o Route 53 responderá à consulta com o endereço IP do balanceador de carga de Oregon. Se a latência for menor entre Londres e a região de Singapura, o Route 53 responderá com o endereço IP do balanceador de carga de Singapura. A latência entre os hosts na Internet pode mudar com o tempo como resultado de alterações na conectividade de rede e no roteamento. O roteamento baseado em latência se baseia em medições de latência realizadas durante um período de tempo, e as medições refletem essas alterações. Uma solicitação roteada para a região de Oregon esta semana pode ser roteada para a região de Singapura a semana que vem. **nota** Quando um navegador ou outro visualizador usa um resolvedor de DNS compatível com a edns-client-subnet extensão de EDNS0, o resolvedor de DNS envia ao Route 53 uma versão truncada do endereço IP do usuário. Se você configurar o encaminhamento por latência, o Route 53 considerará esse valor ao encaminhar o tráfego para seus recursos. Para obter mais informações, consulte [Como o Amazon Route 53 usa EDNS0 para estimar a localização de um usuário](routing-policy-edns0.md). Você pode usar uma política de roteamento por latência para criar registros em uma zona hospedada privada. Para obter informações sobre os valores que você especifica ao usar a política de roteamento de latência para criar registros, consulte os seguintes tópicos: + [Valores específicos para registros de latência](resource-record-sets-values-latency.md) + [Valores específicos para registros de alias de latência](resource-record-sets-values-latency-alias.md) + [Valores que são comuns para todas as políticas de roteamento](resource-record-sets-values-shared.md) + [Valores que são comuns para registros de alias em todas as políticas de roteamento](resource-record-sets-values-alias-common.md) # Roteamento baseado em latência em zonas hospedadas privadas Para zonas hospedadas privadas, o Route 53 responde às consultas de DNS com um endpoint que está no mesmo Região da AWS ponto ou está mais próximo da VPC da qual Região da AWS a consulta se originou. **nota** Se você tiver um endpoint de saída encaminhado para um endpoint de entrada, o registro será resolvido com base na localização do endpoint de entrada, não do endpoint de saída. Se você incluir verificações de integridade e o registro com a menor latência para a origem da consulta não estiver íntegro, um endpoint íntegro com a próxima latência mais baixa será retornado. No exemplo de configuração na figura a seguir, as consultas de DNS provenientes de um us-east-1 Região da AWS, ou mais próximo a ele, serão roteadas para o endpoint 1.1.1.1. As consultas ao DNS de us-west-2, ou da região mais próxima a ela, serão roteadas para o endpoint 2.2.2.2. ![\[Uma captura de tela que mostra dois registros de latência para uma zona hospedada privada.\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/images/latency-phz.png) # Roteamento baseado em IP Com o roteamento baseado em IP no Amazon Route 53, você pode ajustar o roteamento DNS usando a compreensão que tem da rede, das aplicações e dos clientes para tomar as melhores decisões de roteamento DNS para os usuários finais. O roteamento baseado em IP oferece controle granular para otimizar o desempenho ou reduzir os custos de rede carregando seus dados para o Route 53 na forma de mapeamentos. user-IP-to-endpoint O roteamento por geolocalização e o roteamento baseado em latência são baseados em dados que o Route 53 coleta e mantém atualizados. Essa abordagem funciona bem para a maioria dos clientes, mas o roteamento baseado em IP oferece a capacidade adicional de otimizar o roteamento com base no conhecimento específico da base de clientes. Por exemplo, um provedor global de conteúdo de vídeo talvez queira rotear os usuários finais de um determinado provedor de serviços de Internet (ISP). Estes são alguns casos comuns de uso de roteamento baseado em IP: + Você deseja rotear os usuários finais de determinados endpoints ISPs para específicos para que você possa otimizar os custos ou o desempenho do trânsito da rede. + Você quer adicionar substituições aos tipos existentes de roteamento do Route 53, como roteamento por geolocalização, com base em seu conhecimento das localizações físicas dos clientes. **Gerenciando intervalos de IP e associando-os a um conjunto de registros de recursos () RRSet** Para IPv4, você pode usar blocos CIDR entre 1 e 24 bits de comprimento, inclusive, enquanto paraIPv6, você pode usar blocos CIDR entre 1 e 48 bits de comprimento, inclusive. Para definir um bloco CIDR de zero bit (0.0.0.0/0 ou ::/0), use o local padrão ("\$1"). Para consultas ao DNS com um CIDR maior que o especificado na coleção CIDR, o Route 53 fará a correspondência com o CIDR mais curto. Por exemplo, se você especificar 2001:0DB8: :/32 como o bloco CIDR em sua coleção CIDR e uma consulta se originar em 2001:0DB8: 0000:1234: :/48, ela corresponderá. Se, por outro lado, você especificar 2001:0DB8: 0000:1234: :/48 em sua coleção CIDR e uma consulta for originada em 2001:0DB8: :/32, isso não corresponderá e o Route 53 responderá com o registro do local padrão (“\$1”). Você pode agrupar conjuntos de blocos CIDR (ou intervalos IP) em locais CIDR, que, por sua vez, são agrupados em entidades reutilizáveis chamadas coleções CIDR: **CIDR block (Bloco CIDR)** Um intervalo de IP na notação CIDR, por exemplo, 192.0.2.0/24 ou 2001:: :/32. DB8 **Local CIDR** Uma lista nomeada de blocos CIDR. Por exemplo, example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001:: :/32]. DB8 Os blocos em uma lista de locais CIDR não precisam ser adjacentes ou o mesmo intervalo. Um único local pode ter IPv6 blocos A IPv4 e, respectivamente, esse local pode ser associado aos conjuntos de registros A e AAAA. O nome do local geralmente é um local, por convenção, mas pode ser qualquer string, por exemplo *Empresa-A*. **Coleção CIDR** Uma coleção nomeada de locais. Por exemplo, mycollection = [example-isp-seattle, example-isp-tokyo]. Os conjuntos de registros de recursos de roteamento baseados em IP referenciam um local em uma coleção, e todos os conjuntos de registros de recursos para o mesmo nome e tipo de conjunto de registros devem referenciar a mesma coleção. Por exemplo, se você criar sites em duas regiões e quiser direcionar consultas ao DNS de dois locais CIDR diferentes para um determinado site com base nos endereços IP de origem, ambos os locais devem estar listados na mesma coleção CIDR. Você não pode usar uma política de roteamento baseado em IP para criar registros em uma zona hospedada privada. Para obter informações sobre os valores que você especifica ao usar a política de roteamento simples para criar registros, consulte os seguintes tópicos: + [Valores específicos para registros baseados em IP](resource-record-sets-values-ipbased.md) + [Valores específicos para registros de alias baseado em IP](resource-record-sets-values-ipbased-alias.md) + [Valores que são comuns para todas as políticas de roteamento](resource-record-sets-values-shared.md) + [Valores que são comuns para registros de alias em todas as políticas de roteamento](resource-record-sets-values-alias-common.md) **Topics** + [Criar uma coleção CIDR com locais e blocos CIDR](resource-record-sets-creating-cidr-collection.md) + [Trabalhar com locais e blocos CIDR](resource-record-sets-working-with-cidr-locations.md) + [Excluir uma coleção CIDR](resource-record-sets-delete-cidr-collection.md) + [Mudar geolocalização para roteamento baseado em IP](resource-record-sets-move-geolocation-to-cidr.md) # Criar uma coleção CIDR com locais e blocos CIDR Para começar, crie uma coleção CIDR e adicione a ela blocos e locais CIDR. **Para criar uma coleção CIDR usando o console do Route 53** 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, selecione **IP-based routing**, (Roteamento baseado em IP) e depois **CIDR collections**. (Coleções CIDR). 1. Selecione **Create CIDR collection** (Criar coleção CIDR). 1. No painel **Create CIDR collection** (Criar coleção CIDR), em **Details** (Detalhes), insira um nome para a coleção. 1. Selecione **Create collection** (Criar coleção) para criar uma coleção vazia. - ou - Na seção **Create CIDR locations**, insira um nome para o local do CIDR na caixa **CIDR location**. O nome do local pode ser qualquer string de identificação, por exemplo **company 1** ou **Seattle**. Não é necessário que seja um local geográfico real. **Importante** O local do CIDR pode ter no máximo 16 caracteres. Insira os blocos de CIDR na caixa **CIDR blocks**, um em cada linha. Eles podem ser IPv4 ou IPv6 endereços que variam de /0 a /24 para IPv4 e /0 a /48 para. IPv6 1. Depois de inserir os blocos CIDR, selecione **Create CIDR collection** (Criar coleção CIDR) ou **Add another location** (Adicionar outro local) para continuar inserindo locais e blocos CIDR. Você pode inserir vários locais CIDR por coleção. 1. Após inserir os locais CIDR, selecione **Create CIDR collection** (Criar coleção CIDR). # Trabalhar com locais e blocos CIDR **Para trabalhar com locais CIDR usando o console do Route 53** 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, selecione **Roteamento baseado em IP**, **Coleções CIDR** e, na seção **Coleções CIDR**, clique em um link para uma coleção CIDR da lista **Nome da coleção**. Na página **CIDR locations** (Locais CIDR), você pode criar um local CIDR, excluí-lo ou editar um local e seus blocos. + Para criar um local, escolha **Create CIDR location** (Criar local CIDR). + No painel **Create CIDR location** (Criar local CIDR), insira um nome para o local, os blocos CIDR associados ao local e, depois, escolha **Create** (Criar). + Para exibir um local CIDR e os blocos do local, escolha o botão de opção ao lado de um local para exibir o nome e os blocos CIDR do local no painel de locais. Neste painel, você também pode escolher **Editar** para atualizar o nome e/ou os blocos CIDR do local. Quando concluir a edição, escolha **Save** (Salvar). + Para excluir um local CIDR e os blocos do local, escolha o botão ao lado do local que você deseja excluir e depois escolha **Delete** (Excluir). Para confirmar a exclusão, insira o nome do local no campo de entrada de texto e selecione **Delete** (Excluir) novamente. **Importante** A exclusão de um local CIDR não pode ser desfeita. Se você tiver algum registro DNS associado ao local, seu domínio poderá ficar inacessível. # Excluir uma coleção CIDR **Para excluir uma coleção CIDR, os locais e blocos da coleção usando o console do Route 53** 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, selecione **IP-based routing**, (Roteamento baseado em IP) e depois **CIDR collections** (Coleções CIDR). 1. Na seção **CIDR collections** (Coleções CIDR), clique no nome vinculado da coleção que você deseja excluir. 1. Na página **CIDR locations** (Locais CIDR), selecione um local de cada vez, escolha **Delete** (Excluir), insira o nome do local na caixa de diálogo e selecione **Delete** (Excluir). Você deve excluir todos os locais associados a uma coleção CIDR para poder excluí-la. 1. Após concluída a exclusão de todos os locais CIDR, na página **CIDR locations** (Locais CIDR), escolha o botão de opção ao lado da coleção que você deseja excluir e escolha **Delete** (Excluir). # Mudar geolocalização para roteamento baseado em IP Se você estiver usando políticas de roteamento por geolocalização ou geoproximidade, e perceber que clientes específicos são consistentemente roteados para um endpoint que não é o ideal com base na localização física ou na topologia da rede, você pode direcionar melhor os intervalos de IP públicos desses clientes usando roteamento baseado em IP. A tabela a seguir contém um exemplo de configuração de geolocalização para um roteamento por geolocalização existente que ajustaremos para intervalos de IP da Califórnia. | Nome do conjunto de registros | Política de roteamento e origem | Endereço IP do endpoint da aplicação | | --- | --- | --- | | exemplo.com | Roteamento por localização geográfica (EUA) | `198.51.100.1` | | exemplo.com | Roteamento por geolocalização (UE) | `198.51.100.2` | Para substituir intervalos de IP da Califórnia para ir para um novo endpoint de aplicação, primeiro, recrie o roteamento por geolocalização com um novo nome de conjunto de registros. | Nome do conjunto de registros | Política de roteamento e origem | Endereço IP do endpoint da aplicação | | --- | --- | --- | | geo.example.com | Roteamento por localização geográfica (EUA) | `198.51.100.1` | | geo.example.com | Roteamento por localização geográfica (EU) | `198.51.100.2` | Depois, crie registros de roteamento baseados em IP e um registro padrão que aponte para o conjunto recém-recriado de registros de roteamento por geolocalização. | Nome do conjunto de registros | Política de roteamento e origem | Endereço IP do endpoint da aplicação | | --- | --- | --- | | exemplo.com | Roteamento baseado em IP (padrão) | Registro de alias para o endpoint da aplicação geo.exemplo.com que você deseja que seja o padrão. Por exemplo, .`198.51.100.1` | | exemplo.com | Roteamento baseado em IP (intervalos de IP da Califórnia) | `198.51.100.3` | # Roteamento de resposta com vários valores O roteamento de resposta com valores múltiplos permite que você configure o Amazon Route 53 para retornar vários valores, como endereços IP de seus servidores Web, em resposta às consultas de DNS. Você pode especificar vários valores para praticamente qualquer registro, mas o roteamento de resposta com valores múltiplos também permite que você verifique a integridade de cada recurso de modo que o Route 53 retorna somente valores para recursos íntegros. Este tipo de roteamento não substitui o load balancer. No entanto, a capacidade de retornar vários endereços IP cuja integridade pode ser verificada é uma forma de usar o DNS para aprimorar a disponibilidade e o balanceamento de carga. Para encaminhar o tráfego de forma aproximada e aleatória para vários recursos, como servidores Web, crie um registro de resposta de múltiplos valores para cada recurso e, se desejar, associe uma verificação de integridade do Route 53 a cada registro. O Route 53 responde às consultas de DNS com até oito registros íntegros e oferece respostas diferentes para resolvedores de DNS diferentes. Se um servidor web se tornar indisponível depois que um resolvedor armazenar uma resposta em cache, o software cliente pode tentar outro endereço IP na resposta. Observe o seguinte: + Se você associar uma verificação de integridade ao registro de resposta de múltiplos valores, o Route 53 responderá às consultas de DNS com o endereço IP correspondente apenas quando a verificação de integridade for íntegra. + Se você não associar uma verificação de integridade a um registro de resposta de múltiplos valores, o Route 53 sempre considerará o registro como íntegro. + Se você tiver oito ou menos registros íntegros, o Route 53 responderá a todas as consultas de DNS com todos os registros íntegros. + Quando nenhum dos registros estiver íntegro, o Route 53 responderá às consultas DNS com até oito registros não íntegros. Você pode usar roteamento por resposta com vários valores para criar registros em uma zona hospedada privada. Para obter informações sobre os valores que você especifica ao usar a política de roteamento de resposta de vários valores para criar registros, consulte [Valores específicos para registros de resposta com valores múltiplos](resource-record-sets-values-multivalue.md) e [Valores que são comuns para todas as políticas de roteamento](resource-record-sets-values-shared.md). # Roteamento ponderado O roteamento ponderado permite que você associe vários recursos a um único nome de domínio (exemplo.com) ou subdomínio (acme.exemplo.com) e escolha a quantidade de tráfego roteado para cada recurso. Isso pode ser útil para diversas finalidades, incluindo balanceamento de carga e teste de novas versões de software. Para configurar o roteamento ponderado, crie registros que têm o mesmo nome e tipo de cada um dos seus recursos. A cada registro você atribui um peso relativo que corresponde à quantidade de tráfego que deseja enviar a cada recurso. O Amazon Route 53 envia o tráfego para um recurso com base no peso que você atribui ao registro como uma proporção do peso total para todos os registros no grupo: ![\[Fórmula para a quantidade de tráfego roteada para um determinado recurso: peso de um registro especificado/soma dos pesos de todos os registros.\]](http://docs.aws.amazon.com/pt_br/Route53/latest/DeveloperGuide/images/WRR_calculation.png) Por exemplo, se você deseja enviar uma pequena parte do seu tráfego para um recurso e o restante para outro recurso, pode especificar pesos 1 e 255. O recurso com peso 1 recebe 1/256 do tráfego (1/[1\$1255]) e o outro recurso recebe 255/256 (255/[1\$1255]). Você pode alterar gradualmente o equilíbrio alterando os pesos. Se você deseja interromper o envio de tráfego para um recurso, pode alterar o peso desse registro para 0. Para obter informações sobre os valores que você especifica ao usar a política de roteamento ponderada para criar registros, consulte os seguintes tópicos: + [Valores específicos para registros ponderados](resource-record-sets-values-weighted.md) + [Valores específicos para registros de alias ponderados](resource-record-sets-values-weighted-alias.md) + [Valores que são comuns para todas as políticas de roteamento](resource-record-sets-values-shared.md) + [Valores que são comuns para registros de alias em todas as políticas de roteamento](resource-record-sets-values-alias-common.md) Você pode usar uma política de roteamento ponderado para criar registros em uma zona hospedada privada. ## Verificações de integridade e roteamento ponderado Se você adicionar verificações de integridade a todos os registros em um grupo de registros ponderados, mas atribuir pesos diferentes de zero a alguns registros e pesos iguais a zero a outros, as verificações de integridade funcionarão da mesma maneira que todos os registros com pesos diferentes de zero com as seguintes exceções: + Inicialmente, o Route 53 considera somente os registros ponderados com valores diferentes de zero, se houver. + Se nenhum dos registros com ponderação maior que zero estiver íntegro, o Route 53 considerará os registros com ponderação igual a zero. A tabela a seguir detalha o comportamento quando o registro de peso 0 inclui uma verificação de integridade: | | Registro 1 | Registro 2 | Registro 3 | | --- |--- |--- |--- | | Weight | 1 | 1 | 0 | | Inclui verificação de integridade? | Sim | Sim | Sim | | | | --- | | Status da verificação de integridade | Não integro | Não integro | Integridade | | Consulta ao DNS respondida? | Não | Não | Sim | | | | --- | | Status da verificação de integridade | Não integro | Não integro | Não integro | | Consulta ao DNS respondida? | Sim | Sim | Não | | | | --- | | Status da verificação de integridade | Não integro | Integridade | Não integro | | Consulta ao DNS respondida? | Não | Sim | Não | | | | --- | | Status da verificação de integridade | Integridade | Integridade | Não integro | | Consulta ao DNS respondida? | Sim | Sim | Não | | | | --- | | Status da verificação de integridade | Integridade | Integridade | Integridade | | Consulta ao DNS respondida? | Sim | Sim | Não | A tabela a seguir detalha o comportamento quando o registro de peso 0 não inclui uma verificação de integridade: | | Registro 1 | Registro 2 | Registro 3 | | --- |--- |--- |--- | | Weight | 1 | 1 | 0 | | Inclui verificação de integridade? | Sim | Sim | Não | | | | --- | | Status da verificação de integridade | Integridade | Integridade | N/D | | Consulta ao DNS respondida? | Sim | Sim | Não | | | | --- | | Status da verificação de integridade | Não integro | Não integro | N/D | | Consulta ao DNS respondida? | Não | Não | Sim | | | | --- | | Status da verificação de integridade | Não integro | Integridade | N/D | | Consulta ao DNS respondida? | Não | Sim | Não | # Como o Amazon Route 53 usa EDNS0 para estimar a localização de um usuário Para melhorar a precisão do roteamento por geolocalização, geoproximidade, baseado em IP e latência, o Amazon Route 53 suporta a extensão do. edns-client-subnet EDNS0 (EDNS0 adiciona várias extensões opcionais ao protocolo DNS.) O Route 53 pode ser usado edns-client-subnet somente quando os resolvedores de DNS o suportam: + Quando um navegador ou outro visualizador usa um resolvedor de DNS que não oferece suporte edns-client-subnet, o Route 53 usa o endereço IP de origem do resolvedor de DNS para aproximar a localização do usuário e responde às consultas de geolocalização com o registro DNS da localização do resolvedor. + Quando um navegador ou outro visualizador usa um resolvedor de DNS compatível edns-client-subnet, o resolvedor de DNS envia ao Route 53 uma versão truncada do endereço IP do usuário. O Route 53 determina o local do usuário com base no endereço IP truncado, em vez de usar o endereço IP de origem do resolvedor de DNS. Geralmente, isso fornece uma estimativa mais precisa do local do usuário. O Route 53 então responde às consultas de localização geográfica com o registro de DNS do local do usuário. + EDNS0 não se aplica a zonas hospedadas privadas. Para zonas hospedadas privadas, o Route 53 usa dados dos resolvedores de VPC nos quais a Região da AWS zona hospedada privada está para tomar decisões de geolocalização e roteamento de latência. Para obter mais informações sobre edns-client-subnet, consulte RFC da sub-rede do cliente EDNS, sub-rede [do cliente](https://www.rfc-editor.org/rfc/rfc7871) em solicitações de DNS. # Escolher entre registros de alias e não alias Os *alias records* (registros de alias) do Amazon Route 53 fornecem uma extensão específica do Route 53 para a funcionalidade do DNS. Os registros de aliases permitem que você direcione o tráfego para AWS recursos selecionados, incluindo, mas não se limitando a, CloudFront distribuições e buckets do Amazon S3. Eles também permitem rotear o tráfego de um registro em uma zona hospedada para outro registro. Ao contrário do registro CNAME, você não pode criar um registro de alias no nó superior de um namespace DNS, também conhecido como o *apex da zona*. Por exemplo, se você registrar o nome do DNS exemplo.com, o apex de zona será exemplo.com. Você não pode criar um registro CNAME para exemplo.com, mas pode criar um registro de alias para exemplo.com que roteie o tráfego para www.exemplo.com (desde que o tipo de registro de www.exemplo.com não seja CNAME). Quando o Route 53 recebe uma consulta de DNS para um registro de alias, o Route 53 responde com o valor aplicável para esse recurso: + **Uma API regional personalizada do Amazon API Gateway ou uma API otimizada para bordas**: O Route 53 responde com um ou mais endereços IP para sua API. + **Um endpoint de interface da Amazon VPC**: o Route 53 responde com um ou mais endereços IP para seu endpoint de interface. + **Uma CloudFront distribuição** — o Route 53 responde com um ou mais endereços IP para servidores de CloudFront borda que podem servir seu conteúdo. + **Serviço App Runner**: o Route 53 responde com um ou mais endereços IP. + **Um ambiente do Elastic Beanstalk**: o Route 53 responde com um ou mais endereços IP para o ambiente. + **Um balanceador de carga de Elastic Load Balancing**: o Route 53 responde com um ou mais endereços IP para o balanceador de carga. Isso inclui Application Load Balancer, Classic Load Balancer e Network Load Balancer. + **Um AWS Global Accelerator acelerador** — o Route 53 responde com os endereços IP do acelerador. + **Um OpenSearch serviço** — o Route 53 responde com um ou mais endereços IP para o domínio personalizado do OpenSearch Serviço. + **Um bucket do Amazon S3 que é configurado como um site estático**: o Route 53 responde a cada consulta com um endereço IP para o bucket do Amazon S3. + **Outro registro do Route 53 do mesmo tipo na mesma zona hospedada**: o Route 53 responde como se a consulta fosse para o registro referenciado pelo registro de alias (consulte [Comparação entre registros de alias e de CNAME](#resource-record-sets-choosing-alias-non-alias-comparison)). + **AWS AppSync nome de domínio** — O Route 53 responde com um ou mais endereços IP para seu endpoint de interface. Para obter mais informações, consulte [Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). Quando você usa um registro de alias para rotear o tráfego para um AWS recurso, o Route 53 reconhece automaticamente as alterações no recurso. Por exemplo, suponhamos que um registro de alias de exemplo.com aponte para um balanceador de carga de Elastic Load Balancing em lb1-1234.us-east-2.elb.amazonaws.com. Se o endereço IP do balanceador de carga for alterado, o Route 53 será iniciado automaticamente para responder a consultas DNS usando o novo endereço IP. Se um registro de alias apontar para um AWS recurso, você não poderá definir o tempo de vida (TTL); o Route 53 usa o TTL padrão para o recurso. Se um registro de alias aponta para outro registro na mesma zona hospedada, o Route 53 usa o TTL do registro para o qual que o registro de alias aponta. Para obter mais informações sobre o valor de TTL atual do Elastic Load Balancing, acesse [Request routing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing) (Roteamento de solicitação) no *Manual do usuário do Elastic Load Balancing* e procure por “ttl”. Para obter informações sobre como criar registros usando o console do Route 53, consulte [Criar registros usando o console do Amazon Route 53](resource-record-sets-creating.md). Para obter informações sobre os valores que você especifica para registros de alias, consulte o tópico aplicável em [Valores que você especifica ao criar ou editar registros do Amazon Route 53](resource-record-sets-values.md): + [Valores específicos para registros de alias simples](resource-record-sets-values-alias.md) + [Valores específicos para registros de alias ponderados](resource-record-sets-values-weighted-alias.md) + [Valores específicos para registros de alias de latência](resource-record-sets-values-latency-alias.md) + [Valores específicos para registros de alias de failover](resource-record-sets-values-failover-alias.md) + [Valores específicos para registros de alias de localização geográfica](resource-record-sets-values-geo-alias.md) + [Valores específicos para registros de alias de geoproximidade](resource-record-sets-values-geoprox-alias.md) + [Valores que são comuns para registros de alias em todas as políticas de roteamento](resource-record-sets-values-alias-common.md) ## Comparação entre registros de alias e de CNAME Os registros de alias são semelhantes a registros CNAME, mas há algumas diferenças importantes. A lista a seguir compara registros de alias e registros CNAME. **Recursos para os quais é possível redirecionar consultas** **Registros de alias** Um registro de alias só pode redirecionar consultas para AWS recursos selecionados, incluindo, mas não se limitando ao seguinte: + Buckets do Amazon S3 + CloudFront distribuições + Outro registro na mesma zona hospedada do Route 53 Por exemplo, você pode criar um registro de alias chamado acme.example.com que redireciona as consultas para um bucket do Amazon S3 que também é chamado de acme.example.com. Você também pode criar um registro de alias acme.example.com que redireciona as consultas para um registro chamado zenith.example.com na zona hospedada exemplo.com. **Registros CNAME** Um registro CNAME pode redirecionar consultas de DNS para qualquer registro de DNS. Por exemplo, você pode criar um registro CNAME que redireciona as consultas de acme.example.com para zenith.example.com ou para acme.example.org. Você não precisa usar o Route 53 como o serviço de DNS para o domínio ao qual está redirecionando consultas. **Criar registros com o mesmo nome do domínio (registros no apex de zona)** **Registros de alias** Na maioria das configurações, você pode criar um registro de alias com o mesmo nome da zona hospedada (o apex de zona). A única exceção é quando você deseja redirecionar consultas de apex de zona (como example.com) para um registro na mesma zona hospedada com um tipo de CNAME (como zenith.example.com). O registro de alias deve ter o mesmo tipo que o registro para o qual você está roteando o tráfego e não há suporte para criar um registro CNAME para o apex de zona mesmo para um registro de alias. **Registros CNAME** Não é possível criar um registro CNAME que tenha o mesmo nome da zona hospedada (a apex de zona). Isso é válido tanto para zonas hospedadas para nomes de domínio (exemplo.com) e para zonas hospedadas para subdomínios (zenith.example.com). **Definição de preço para consultas de DNS** **Registros de alias** O Route 53 não cobra por consultas de alias aos AWS recursos. Para obter mais informações, consulte [Definição de preço do Amazon Route 53](https://aws.amazon.com/route53/pricing/). **Registros CNAME** O Route 53 cobra as consultas CNAME. Se você criar um registro CNAME que redireciona para o nome de outro registro em uma zona hospedada do Route 53 (a mesma zona hospedada ou outra zona hospedada), cada consulta de DNS será cobrada como duas consultas: + O Route 53 responde à primeira consulta de DNS com o nome do registro para o qual você deseja redirecionar. + Depois, o resolvedor de DNS deve enviar outra consulta para o registro na primeira resposta a fim de obter informações sobre o direcionamento do tráfego, por exemplo, o endereço IP de um servidor web. Se o registro CNAME for redirecionado para o nome de um registro hospedado com outro serviço de DNS, o Route 53 cobrará por uma consulta. O outro serviço de DNS pode cobrar pela segunda consulta. **Tipo de registro especificado na consulta de DNS** **Registros de alias** O Route 53 responde a uma consulta de DNS apenas quando o nome do registro de alias (como acme.example.com) e o tipo do registro de alias (como A ou AAAA) corresponder ao nome e ao tipo na consulta de DNS. **Registros CNAME** Um registro CNAME redireciona consultas de DNS para um nome de registro, independentemente do tipo de registro especificado na consulta de DNS, como A ou AAAA. **Como os registros são listados em consultas dig ou nslookup** **Registros de alias** Na resposta a uma consulta dig ou nslookup, um registro de alias é listado como o tipo de registro que você especificou ao criar o registro, como A ou AAAA. (O tipo de registro especificado para um registro de alias depende do recurso para o qual você está encaminhando o tráfego. Por exemplo, para encaminhar o tráfego para um bucket do S3, especifique A para o tipo.) A propriedade alias é visível somente no console do Route 53 ou na resposta a uma solicitação programática, como um comando da CLI AWS . `list-resource-record-sets` **Registros CNAME** Um registro CNAME é listado como um registro CNAME em resposta às consultas dig ou nslookup. # Tipos de registro de DNS com suporte O Amazon Route 53 oferece suporte aos tipos de registros de DNS listados nesta seção. Cada tipo de registro também inclui um exemplo de como formatar o elemento `Value` ao acessar o Route 53 usando a API. **nota** Para os tipos de registros que incluem um nome de domínio, digite um nome de domínio totalmente qualificado, como *www.exemplo.com*. O ponto final é opcional; o Route 53 pressupõe que o nome do domínio seja totalmente qualificado. Isso significa que o Route 53 trata *www.exemplo.com* (sem um ponto final) e *www.exemplo.com.* (com um ponto final) como valores idênticos. O Route 53 fornece uma extensão para a funcionalidade DNS conhecida como registros de alias. Semelhantes aos registros CNAME, os registros de alias permitem que você encaminhe o tráfego para recursos da AWS selecionados, como as distribuições do CloudFront e os buckets do Amazon S3. Para obter mais informações, incluindo uma comparação entre registros de alias e CNAME, consulte [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Tipo de registro A](#AFormat) + [Tipo de registro AAAA](#AAAAFormat) + [Tipo de registro CAA](#CAAFormat) + [Tipo de registro CNAME](#CNAMEFormat) + [Tipo de registro de DS](#DSFormat) + [Tipo de registro HTTPS](#HTTPSFormat) + [Tipo de registro MX](#MXFormat) + [Tipo de registro NAPTR](#NAPTRFormat) + [Tipo de registro NS](#NSFormat) + [Tipo de registro PTR](#PTRFormat) + [Tipo de registro SOA](#SOAFormat) + [Tipo de registro SPF](#SPFFormat) + [Tipo de registro SRV](#SRVFormat) + [Tipo de registro SSHFP](#SSHFPFormat) + [Tipo de registro SVCB](#SVCBFormat) + [Tipo de registro TLSA](#TLSAFormat) + [Tipo de registro TXT](#TXTFormat) ## Tipo de registro A Use um registro A para rotear o tráfego para um recurso, como um servidor web, usando um endereço IPv4 em notação decimal com ponto. **Exemplo para o console do Amazon Route 53** ``` 192.0.2.1 ``` **Exemplo para a API do Route** ``` 192.0.2.1 ``` ## Tipo de registro AAAA Use um registro AAAA para rotear o tráfego para um recurso, como servidor web, usando um endereço IPv6 em formato hexadecimal separado por dois pontos. **Exemplo para o console do Amazon Route 53** ``` 2001:0db8:85a3:0:0:8a2e:0370:7334 ``` **Exemplo para a API do Route** ``` 2001:0db8:85a3:0:0:8a2e:0370:7334 ``` ## Tipo de registro CAA Um registro CAA especifica quais autoridades de certificação (CAs) têm permissão para emitir certificados para um domínio ou subdomínio. A criação de um registro CAA ajuda a impedir que CAs incorretas emitam certificados para seus domínios. Um registro CAA não é um substituto para os requisitos de segurança que são especificados por sua autoridade de certificação, como o requisito para validar que você é o proprietário de um domínio. Você pode usar registros CAA para especificar: + Quais autoridades de certificação (CAs) podem emitir certificados SSL/TLS, se houver + O endereço de e-mail ou o URL a ser contatado quando a CA emitir um certificado para o domínio ou o subdomínio Quando você adiciona um registro CAA a sua zona hospedada, você especifica três configurações separadas por espaços: `flags tag "value"` Observe o seguinte sobre o formato dos registros CAA: + O valor de `tag` pode conter somente os caracteres A-Z, a-z e 0-9. + Sempre coloque o `value` entre aspas (""). + Algumas CAs permitem ou exigem valores adicionais para `value`. Especifique valores adicionais como pares de nome e valor, e separe-os com ponto-e-vírgula (;), por exemplo: `0 issue "ca.example.net; account=123456"` + Se um CA recebe uma solicitação de certificado para um subdomínio (como www.example.com) e se não existe nenhum registro CAA no subdomínio, o CA envia uma consulta de DNS para um registro CAA para o domínio pai (como example.com). Se existir um registro para o domínio pai e se a solicitação de certificado for válida, o CA emitirá o certificado para o subdomínio. + Recomendamos que você consulte sua CA para determinar quais valores especificar para um registro da CAA. + Não é possível criar um registro de CAA e um registro do CNAME com o mesmo nome, pois o DNS não permite usar o mesmo nome para um registro do CNAME e para qualquer outro tipo de registro ao mesmo tempo. **Topics** + [Autorizar um CA a emitir um certificado para um domínio ou subdomínio](#CAAFormat-issue) + [Autorizar um CA a emitir um certificado curinga para um domínio ou subdomínio](#CAAFormat-issue-wild) + [Impedir qualquer CA de emitir um certificado para um domínio ou subdomínio](#CAAFormat-prevent-issue) + [Solicitar que um CA entre em contato com você caso receba uma solicitação de certificado inválida](#CAAFormat-contact) + [Usar outra configuração que é compatível com o CA](#CAAFormat-custom-setting) + [Exemplos](#CAAFormat-examples) ### Autorizar um CA a emitir um certificado para um domínio ou subdomínio Para autorizar um CA a emitir um certificado para um domínio ou subdomínio, crie um registro com o mesmo nome do domínio ou do subdomínio, e especifique as seguintes configurações: + **flags** – `0` + **Tag** – `issue` + **value**: o código da CA que você autoriza para emitir um certificado para o domínio ou subdomínio Por exemplo, suponha que você deseja autorizar ca.example.net a emitir um certificado para example.com. Você cria um registro CAA para example.com com as seguintes configurações: ``` 0 issue "ca.example.net" ``` Para obter informações sobre como autorizar o AWS Certificate Manager a emitir um certificado, consulte [Configurar um registro CAA](https://docs.aws.amazon.com/acm/latest/userguide/setup-caa.html) no *AWS Certificate Manager Manual do usuário*. ### Autorizar um CA a emitir um certificado curinga para um domínio ou subdomínio Para autorizar um CA a emitir um certificado curinga para um domínio ou subdomínio, crie um registro com o mesmo nome de domínio ou subdomínio, e especifique as seguintes configurações. Um certificado curinga se aplica ao domínio ou subdomínio e a todos os seus subdomínios. + **flags** – `0` + **Tag** – `issuewild` + **value** (valor): o código da CA que você autoriza para emitir um certificado para um domínio ou subdomínio e seus subdomínios Por exemplo, suponha que você deseja autorizar ca.example.net a emitir um certificado curinga para example.com, aplicável a example.com e a todos os seus subdomínios. Você cria um registro CAA para example.com com as seguintes configurações: ``` 0 issuewild "ca.example.net" ``` Quando você quiser autorizar um CA a emitir um certificado curinga para um domínio ou subdomínio, crie um registro com o mesmo nome do domínio ou subdomínio, e especifique as seguintes configurações. Um certificado curinga se aplica ao domínio ou subdomínio e a todos os seus subdomínios. ### Impedir qualquer CA de emitir um certificado para um domínio ou subdomínio Para impedir qualquer CA de emitir um certificado para um domínio ou subdomínio, crie um registro com o mesmo nome do domínio ou subdomínio, e especifique as seguintes configurações: + **flags** – `0` + **Tag** – `issue` + **value (valor** – `";"` Por exemplo, suponha que você deseja impedir que qualquer CA emita um certificado para example.com. Você cria um registro CAA para example.com com as seguintes configurações: `0 issue ";"` Se você deseja impedir que qualquer CA emita um certificado para example.com ou seus subdomínios, crie um registro CAA para example.com com as seguintes configurações: `0 issuewild ";"` **nota** Se você criar um registro CAA para example.com e especificar os valores a seguir, um CA que esteja usando o valor ca.example.net poderá emitir o certificado para example.com: ``` 0 issue ";" 0 issue "ca.example.net" ``` ### Solicitar que um CA entre em contato com você caso receba uma solicitação de certificado inválida Se você deseja que qualquer CA que receba uma solicitação inválida para um certificado entre em contato com você, especifique as seguintes configurações: + **flags** – `0` + **Tag** – `iodef` + **value** (valor): a URL ou o endereço de e-mail que você deseja que a CA notifique quando receber uma solicitação inválida de um certificado. Use o formato aplicável: `"mailto:email-address"` `"http://URL"` `"https://URL"` Por exemplo, se você deseja que qualquer CA que receba uma solicitação inválida para um certificado envie um e-mail para admin@example.com, crie um registro de CAA com as seguintes configurações: ``` 0 iodef "mailto:admin@example.com" ``` ### Usar outra configuração que é compatível com o CA Se o seu CA oferece suporte a um recurso que não está definido na RFC para registros de CAA, especifique as seguintes configurações: + **flags**: 128 (esse valor impede que a CA emita um certificado, se ela não ela não oferecer suporte ao recurso especificado.) + **tag**: a tag que você autoriza a CA a usar + **value**: o valor que corresponde ao valor da tag Por exemplo, suponha que o CA oferece suporte ao envio de uma mensagem de texto caso receba uma solicitação inválida para certificado. (Não estamos ciente de quaisquer CAs que ofereçam suporte a essa opção.) As configurações para o registro poderiam ser: ``` 128 exampletag "15555551212" ``` ### Exemplos **Exemplo para o console do Route** ``` 0 issue "ca.example.net" 0 iodef "mailto:admin@example.com" ``` **Exemplo para a API do Route** ``` 0 issue "ca.example.net" 0 iodef "mailto:admin@example.com" ``` ## Tipo de registro CNAME Um registro CNAME mapeia consultas DNS para o nome do registro atual, como acme.example.com, para outro domínio (example.com ou example.net) ou subdomínio (acme.example.com ou zenith.example.org). **Importante** O protocolo DNS não permite que você crie um registro CNAME no nó superior de um namespace DNS, também conhecido como o apex de zona. Por exemplo, se você registrar o nome do DNS exemplo.com, o apex de zona será exemplo.com. Você não pode criar um registro CNAME para exemplo.com, mas pode criar registros CNAME para www.exemplo.com, produtonovo.exemplo.com e assim por diante. Além disso, se você criar um registro CNAME para um subdomínio, não poderá criar outros registros para esse subdomínio. Por exemplo, se você criar um CNAME para www.example.com, não poderá criar outros registros para os quais o valor do campo **Name (Nome)** é www.example.com. O Amazon Route 53 também oferece suporte para registros com alias, que permitem encaminhar consultas para recursos selecionados da AWS, como distribuições do CloudFront e buckets do Amazon S3. Os aliases têm algumas semelhanças com o tipo de registro CNAME. No entanto, você pode criar um alias para o apex de zona. Para obter mais informações, consulte [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md). **Exemplo para o console do Route** ``` hostname.example.com ``` **Exemplo para a API do Route** ``` hostname.example.com ``` ## Tipo de registro de DS Um registro de signatário de delegação (DS) refere-se a uma chave de zona para uma zona de subdomínio delegado. Você pode criar um registro de DS ao estabelecer uma cadeia de confiança ao configurar a assinatura DNSSEC. Para obter mais informações sobre como configurar o DNSSEC no Route 53, consulte [Como configurar a assinatura de DNSSEC no Amazon Route 53](dns-configuring-dnssec.md). Os três primeiros valores são números decimais que representam a tag de chave, o algoritmo e o tipo de resumo. O quarto valor é o resumo da chave de zona. Para obter mais informações sobre o formato de DS, consulte [RFC 4034](https://www.ietf.org/rfc/rfc4034.txt). **Exemplo para o console do Route** ``` 123 4 5 1234567890abcdef1234567890absdef ``` **Exemplo para a API do Route** ``` 123 4 5 1234567890abcdef1234567890absdef ``` ## Tipo de registro HTTPS Um registro de recurso HTTPS é uma forma do registro DNS Service Binding (SVCB) que fornece informações de configuração estendidas, permitindo que um cliente se conecte de forma fácil e segura a um serviço com um protocolo HTTP. As informações de configuração são fornecidas em parâmetros que permitem a conexão em uma única consulta ao DNS, em vez de exigir várias consultas ao DNS. O formato para um registro de recurso HTTPS é: `SvcPriority TargetName SvcParams(optional)` Os parâmetros a seguir estão descritos na [RFC 9460, seção 9.1](https://www.rfc-editor.org/rfc/rfc9460.html#section-9.1). **Prioridade SVC** Um número inteiro que representa a prioridade. A prioridade 0 significa modo de alias e geralmente se destina ao alias no ápex da zona. Esse valor é um número inteiro de 0 a 32767 para o Route 53, dos quais 1-32767 são registros de modo de serviço. Quanto menor a prioridade, maior a preferência. **TargetName** O nome de domínio do destino do alias (para o modo alias) ou do endpoint alternativo (para ServiceMode). **SvcParams (opcional)** Uma lista separada por espaços em branco, com cada parâmetro consistindo em um par de Chave=Valor ou em uma chave independente. Se houver mais de um valor, eles serão apresentados como uma lista separada por vírgulas. A seguir estão os SvcParams definidos: + `1:alpn`: IDs do protocolo de negociação da camada de aplicação. O padrão é HTTP/1.1, `h2` é HTTP/2 sobre TLS e `h3` é HTTP/3 (protocolo HTTP sobre QUIC). + `2:no-default-alpn`: o padrão não é compatível, e você deve fornecer um parâmetro `alpn`. + `3:port`: o endpoint alternativo ou a porta em que o serviço pode ser acessado. + `4:ipv4hint`: dicas de endereços IPv4. + `5:ech`: saudações criptografadas do cliente. + `6:ipv6hint`: dicas de endereços IPv6. + `7:dohpath`: modelo de DNS sobre HTTPS + `8:ohttp`: o serviço opera um destino HTTP inconsciente **Exemplo para o console Amazon Route 53 para o modo de alias** ``` 0 example.com ``` **Exemplo para o console Amazon Route 53 para o modo de serviço** ``` 16 example.com alpn="h2,h3" port=808 ``` **Exemplo para a API do Amazon Route 53 para o modo de alias** ``` 0 example.com ``` **Exemplo para a do API Route 53 para o modo de serviço** ``` 16 example.com alpn="h2,h3" port=808 ``` Para obter mais informações, consulte [RFC 9460, vinculação de serviços e especificação de parâmetros através do DNS (SVCB e registros de recursos HTTPS)](https://datatracker.ietf.org/doc/html/rfc9460). **nota** O Route 53 não é compatível com o formato arbitrário de apresentação de chave desconhecida `keyNNNNN` ## Tipo de registro MX Um registro MX especifica os nomes dos servidores de e-mail e, se você tiver dois ou mais servidores de e-mail, a ordem de prioridade. Cada valor de um registro MX contém dois valores, prioridade e nome de domínio. **Prioridade** Um número inteiro que representa a prioridade para um servidor de e-mail. Se você especificar somente um servidor, a prioridade pode ser qualquer inteiro entre 0 e 65535. Se você especificar vários servidores, o valor especificado para a prioridade indica para qual servidor de e-mail você deseja que o e-mail seja roteado para em primeiro lugar, em segundo e assim por diante. O servidor com o menor valor para a prioridade tem precedência. Por exemplo, se você tiver dois servidores de e-mail e especificar valores de 10 e 20 para a prioridade, o e-mail sempre vai para o servidor com uma prioridade 10, a não ser que ele esteja indisponível. Se você especificar valores de 10 e 10, o e-mail será roteado para os dois servidores de forma praticamente igual. **Nome de domínio** O nome do domínio do servidor de e-mail. Especifique o nome (como email.exemplo.com) de um registro A ou AAAA. Em [RFC 2181, Classificações para a especificação DNS](https://tools.ietf.org/html/rfc2181), a seção 10.3 proíbe especificar o nome de um registro do CNAME para o valor do nome de domínio. (Quando a RFC menciona “alias”, significa um registro do CNAME, não um registro de alias do Route 53.) **Exemplo para o console do Amazon Route 53** ``` 10 mail.example.com ``` **Exemplo para a API do Route** ``` 10 mail.example.com ``` ## Tipo de registro NAPTR O Name Authority Pointer (NAPTR – Ponteiro de autoridade de nome) é um tipo de registro usado pelas aplicações Dynamic Delegation Discovery System (DDDS – Sistema de descoberta de delegação dinâmica) para converter um valor em outro ou substituir um valor por outro. Por exemplo, um uso comum é converter números de telefone em SIP URIs. O elemento `Value` de um registro NAPTR consiste em seis valores separados por espaço: **Ordem** Quando você especifica mais de um registro, a sequência na qual deseja que a aplicação DDDS avalie os registros. Valores válidos: 0 - 65535. **Preferência** Quando você especifica dois ou mais registros que têm a mesma **ordem**, sua preferência para a sequência na qual os registros são avaliados. Por exemplo, se dois registros têm uma **ordem** de 1, a aplicação DDDS primeiro avalia o registro que tem a menor **preferência**. Valores válidos: 0 - 65535. **Sinalizadores** Uma configuração específica para as aplicações DDDS. Os valores atualmente definidos na [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt) são letras maiúsculas e minúsculas **"A"**, **"P"**, **"S"**e **"U"**e a string vazia **""**. Coloque os **sinalizadores** entre aspas. **Serviço** Uma configuração específica para as aplicações DDDS. Coloque o **serviço** entre aspas. Para obter mais informações, consulte as RFCs aplicáveis: + **Aplicação DDDS do URI**: [https://tools.ietf.org/html/rfc3404\$1section-4.4](https://tools.ietf.org/html/rfc3404#section-4.4) + **Aplicação DDDS de S-NAPTR**: [https://tools.ietf.org/html/rfc3958\$1section-6.5](https://tools.ietf.org/html/rfc3958#section-6.5) + **Aplicação DDDS de U-NAPTR**: [https://tools.ietf.org/html/rfc4848\$1section-4.5](https://tools.ietf.org/html/rfc4848#section-4.5) **Regexp** Uma expressão regular que a aplicação DDDS usa para converter um valor de entrada em um valor de saída. Por exemplo, um sistema de telefone IP pode usar uma expressão regular para converter um número de telefone inserido por um usuário em um SIP URI. Coloque **Regexp** entre aspas. Especifique um valor para **Regexp** ou um valor para **Substituição**, mas não para ambos. A expressão regular pode incluir qualquer um dos seguintes caracteres ASCII imprimíveis: + a-z + 0-9 + - (hífen) + (espaço) + \$1 \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ ] ^ \$1 ` \$1 \$1 \$1 \$1 . + " (aspas). Para incluir uma citação literal em uma string, preceda-a de um caractere \$1: \$1". + \$1 (barra invertida). Para incluir uma barra invertida em uma string, preceda-a de um caractere \$1: \$1\$1. Especifique todos os outros valores, como nomes de domínio internacionalizados, no formato octal. Para a sintaxe de **Regexp**, consulte [RFC 3402, seção 3.2, Sintaxe de expressão de substituição](https://tools.ietf.org/html/rfc3402#section-3.2) **Substituição** O nome de domínio totalmente qualificado (FQDN) do próximo nome de domínio para o qual você deseja que a aplicação DDDS envie uma consulta de DNS. A aplicação DDDS substitui o valor de entrada pelo o valor que você especifica para **Substituição**, se houver. Especifique um valor para **Regexp** ou um valor para **Substituição**, mas não para ambos. Se você especificar um valor para **Regexp**, especifique um ponto (**.**) em **Replacement (Substituição)**. O nome do domínio pode incluir a-z, 0-9 e – (hífen). Para obter mais informações sobre as aplicações DDDS e os registros NAPTR, consulte as seguintes RFCs: + [RFC 3401](https://www.ietf.org/rfc/rfc3401.txt) + [RFC 3402](https://www.ietf.org/rfc/rfc3402.txt) + [RFC 3403](https://www.ietf.org/rfc/rfc3403.txt) + [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt) **Exemplo para o console do Amazon Route 53** ``` 100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" . 100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" . 100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" . ``` **Exemplo para a API do Route** ``` 100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" . 100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" . 100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" . ``` ## Tipo de registro NS Um registro de NS identifica os servidores de nome da zona hospedada. Observe o seguinte: + O uso mais comum de um registro NS é controlar como o tráfego da Internet é roteado para um domínio. Para usar os registros em uma zona hospedada para rotear o tráfego para um domínio, atualize as configurações de registro de domínio para usar os quatro servidores de nomes no registro NS padrão. (Este é o registro NS que tem o mesmo nome que a zona hospedada.) + É possível criar uma zona hospedada separada para um subdomínio (acme.example.com) e usar essa zona hospedada para rotear o tráfego de Internet para o subdomínio e seus subdomínios (subdomain.acme.example.com). Defina esta configuração, conhecida como “delegar a responsabilidade por um subdomínio a uma zona hospedada” ao criar outro registro NS na zona hospedada para o domínio raiz (example.com). Para obter mais informações, consulte [Rotear tráfego para subdomínios](dns-routing-traffic-for-subdomains.md). + Os registros NS também são usados para configurar servidores de nomes de rótulo branco. Para obter mais informações, consulte [Configurar servidores de nome de rótulo branco](white-label-name-servers.md). + Outra utilização para um registro NS é para zonas hospedadas privadas quando você cria uma regra de delegação para delegar a autoridade de um subdomínio ao seu resolvedor on-premises. Você deve criar esse registro NS antes de criar uma regra delegada. Para obter mais informações, consulte [Como os endpoints do Resolver encaminham as consultas de DNS da sua para a sua rede VPCs](resolver-overview-forward-vpc-to-network.md). Para obter mais informações sobre registros de NS, consulte [Registros de NS e SOA que o Amazon Route 53 cria para uma zona hospedada pública](SOA-NSrecords.md). **Exemplo para o console do Amazon Route 53** ``` ns-1.example.com ``` **Exemplo para a API do Route** ``` ns-1.example.com ``` ## Tipo de registro PTR Um registro PTR mapeia um endereço IP para o nome de domínio correspondente. **Exemplo para o console do Amazon Route 53** ``` hostname.example.com ``` **Exemplo para a API do Route** ``` hostname.example.com ``` ## Tipo de registro SOA Um registro de início de autoridade (SOA) fornece informações sobre um domínio e a zona hospedada correspondente do Amazon Route 53. Para obter informações sobre os campos em um registro de SOA, consulte [Registros de NS e SOA que o Amazon Route 53 cria para uma zona hospedada pública](SOA-NSrecords.md). **Exemplo para o console do Route** ``` ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60 ``` **Exemplo para a API do Route** ``` ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60 ``` ## Tipo de registro SPF Anteriormente, os registros de SPF eram usados para verificar a identidade do remetente de mensagens de e-mail. No entanto, não recomendamos mais que você crie registros cujo tipo de registro seja SPF. A RFC 7208, *Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, versão 1*, foi atualizada para dizer "...sua existência e mecanismo definidos na [RFC4408] levaram a alguns problemas de interoperabilidade. Da mesma forma, seu uso não é mais apropriado para a SPF versão 1; as implementações não são para usá-la." Na RFC 7208, consulte a seção 14.1, [The SPF DNS Record Type](http://tools.ietf.org/html/rfc7208#section-14.1). Em vez de um registro SPF, recomendamos que você crie um registro TXT que contém o valor aplicável. Para obter mais informações sobre os valores válidos, consulte o artigo da Wikipédia [Sender Policy Framework](https://en.wikipedia.org/wiki/Sender_Policy_Framework). **Exemplo para o console do Amazon Route 53** ``` "v=spf1 ip4:192.168.0.1/16 -all" ``` **Exemplo para a API do Route** ``` "v=spf1 ip4:192.168.0.1/16 -all" ``` ## Tipo de registro SRV Um elemento `Value` de um registro SRV consiste em quatro valores separados por espaços. Os três primeiros valores são números decimais que representam prioridade, peso e porta. O quarto valor é um nome de domínio. Os registros de SRV são usados para acessar serviços, como um serviço para e-mail ou comunicações. Para obter informações sobre o formato de registros de SRV, consulte a documentação do serviço ao qual você deseja se conectar. **Exemplo para o console do Amazon Route 53** ``` 10 5 80 hostname.example.com ``` **Exemplo para a API do Route** ``` 10 5 80 hostname.example.com ``` ## Tipo de registro SSHFP Um registro de impressão digital Secure Shell (SSHFP) identifica as chaves SSH associadas ao nome de domínio. Os registros SSHFP devem ser protegidos com DNSSEC para que uma cadeia de confiança seja estabelecida. Para obter mais informações sobre DNSSEC, consulte [Como configurar a assinatura de DNSSEC no Amazon Route 53](dns-configuring-dnssec.md) O formato para um registro de recurso SSHFP é: `[Key Algorithm] [Hash Type] Fingerprint` Os parâmetros a seguir são definidos na [RFC 4255](https://datatracker.ietf.org/doc/html/rfc4255). **Algoritmo de chave** Tipo de algoritmo: + `0`: reservado e não usado. + `1: RSA`: o algoritmo Rivest–Shamir–Adleman é um dos primeiros sistemas criptográficos de chave pública e ainda está em uso para transmissão segura de dados. + `2: DSA`: o algoritmo de assinatura digital é um padrão federal de processamento de informações para assinaturas digitais. O DSA é baseado na exponenciação modular e nos modelos matemáticos de logaritmo discreto. + `3: ECDSA`: o algoritmo de assinatura digital de curva elíptica é uma variante do DSA que usa criptografia de curva elíptica. + `4: Ed25519`: o algoritmo Ed25519 é o esquema de assinatura EdDSA que usa SHA-512 (SHA-2) e Curve25519. + `6: Ed448`: o Ed448 é o esquema de assinatura EdDSA que usa SHAKE256 e Curve448. **Tipo de hash** Algoritmo usado para criar o hash de chave pública: + `0`: reservado e não usado. + `1: SHA-1` + `2: SHA-256` **Impressão digital** Representação hexadecimal do hash. **Exemplo para o console do Amazon Route 53** ``` 1 1 09F6A01D2175742B257C6B98B7C72C44C4040683 ``` **Exemplo para a API do Route** ``` 1 1 09F6A01D2175742B257C6B98B7C72C44C4040683 ``` Para obter mais informações, consulte [RFC 4255: usar o DNS para publicar com segurança as impressões digitais da chave Secure Shell (SSH)](https://datatracker.ietf.org/doc/html/rfc4255). ## Tipo de registro SVCB Você usa um registro SVCB para fornecer informações de configuração para acessar endpoints de serviço. O SVCB é um registro de DNS genérico e pode ser usado para negociar parâmetros para uma variedade de protocolos de aplicações. O formato de um registro de recurso SVCB é: `SvcPriority TargetName SvcParams(optional)` Os parâmetros a seguir estão descritos na [RFC 9460, seção 2.3](https://www.rfc-editor.org/rfc/rfc9460.html#section-2.3). **Prioridade SVC** Um número inteiro que representa a prioridade. A prioridade 0 significa modo de alias e geralmente se destina ao alias no ápex da zona. Quanto menor a prioridade, maior a preferência. **TargetName** O nome de domínio do destino do alias (para o modo alias) ou do endpoint alternativo (para ServiceMode). **SvcParams (opcional)** Uma lista separada por espaços em branco, com cada parâmetro consistindo em um par de Chave=Valor ou em uma chave independente. Se houver mais de um valor, eles serão apresentados como uma lista separada por vírgulas. Esse valor é um número inteiro de 0 a 32767 para o Route 53, dos quais 1-32767 são registros de modo de serviço. A seguir estão os SvcParams definidos: + `1:alpn`: IDs do protocolo de negociação da camada de aplicação. O padrão é HTTP/1.1, `h2` é HTTP/2 sobre TLS e `h3` é HTTP/3 (protocolo HTTP sobre QUIC). + `2:no-default-alpn`: o padrão não é compatível, e você deve fornecer um parâmetro `alpn`. + `3:port`: a porta do endpoint alternativo em que o serviço pode ser acessado. + `4:ipv4hint`: dicas de endereços IPv4. + `5:ech`: saudações criptografadas do cliente. + `6:ipv6hint`: dicas de endereços IPv6. + `7:dohpath`: modelo de DNS sobre HTTPS + `8:ohttp`: o serviço opera um destino HTTP inconsciente **Exemplo para o console Amazon Route 53 para o modo de alias** ``` 0 example.com ``` **Exemplo para o console Amazon Route 53 para o modo de serviço** ``` 16 example.com alpn="h2,h3" port=808 ``` **Exemplo para a API do Amazon Route 53 para o modo de alias** ``` 0 example.com ``` **Exemplo para a do API Route 53 para o modo de serviço** ``` 16 example.com alpn="h2,h3" port=808 ``` Para obter mais informações, consulte [RFC 9460, vinculação de serviços e especificação de parâmetros através do DNS (SVCB e registros de recursos HTTPS)](https://datatracker.ietf.org/doc/html/rfc9460). **nota** O Route 53 não é compatível com o formato arbitrário de apresentação de chave desconhecida `keyNNNNN` ## Tipo de registro TLSA Você usa um registro TLSA para usar a Autenticação de entidades nomeadas (DANE) baseada em DNS. Um registro TLSA associa um certificado/chave pública a um endpoint TLS (Transport Layer Security), e os clientes podem validar o certificado/chave pública usando um registro TLSA assinado com o DNSSEC. Registros TLSA somente podem ser confiáveis quando o DNSSEC está habilitado no seu domínio. Para obter mais informações sobre DNSSEC, consulte [Como configurar a assinatura de DNSSEC no Amazon Route 53](dns-configuring-dnssec.md) O formato para um registro de recurso TLSA é: `[Certificate usage] Selector [Matching type] [Certificate association data]` Os seguintes parâmetros são especificados na [RFC 6698, seção 3](https://datatracker.ietf.org/doc/html/rfc6698#section-3). **Utilização do certificado** Especifica a associação fornecida que será usada para corresponder ao certificado apresentado no handshake TLS: + 0: Restrição de CA: o certificado ou a chave pública devem ser encontrados em qualquer um dos caminhos de certificação da Infraestrutura de Chave Pública (PKIX) para o certificado de entidade final fornecido pelo servidor no TLS. Veja a seguir as mensagens de indicação definidas: + 1: Restrição de certificado de serviço: especifica um certificado de entidade final (ou a chave pública) que deve corresponder ao certificado de entidade final fornecido pelo servidor no TLS. Essa certificação limita qual certificado de entidade final pode ser usado por um serviço especificado em um host. + 2: Uma afirmação de âncora de confiança: especifica um certificado (ou a chave pública) que deve ser utilizado como “âncora de confiança” ao validar o certificado de entidade final fornecido pelo servidor no TLS. Permite que um administrador de domínio especifique uma âncora de confiança. + 3: Certificação emitida pelo domínio: especifica um certificado (ou a chave pública) que deve corresponder ao certificado da entidade final fornecido pelo servidor no TLS. Essa certificação permite que um administrador de domínio emita certificados para um domínio sem envolver uma CA de terceiros. Esse certificado não precisa passar pela validação do PKIX. **Seletor** Especifica qual parte do certificado apresentado pelo servidor no handshake é comparada com o valor da associação: + 0: o certificado inteiro deve ser correspondido. + 1: a chave pública do assunto, ou a estrutura binária codificada em DER, deve ser correspondida. **Tipo de correspondência** Especifica a apresentação (conforme determinado pelo campo de Seletor) da correspondência do certificado: + 0: correspondência exata do conteúdo. + 1: Hash SHA-256. + 2: Hash SHA-512. **Dados de associação de certificados** Os dados a serem correspondidos com base nas configurações dos outros campos. **Exemplo para o console do Amazon Route 53** ``` 0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971 ``` **Exemplo para a API do Route** ``` 0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971 ``` Para mais informações, consulte [RFC 6698, Protocolo TLS (Transport Layer Security) baseado em DNS: TLSA](https://datatracker.ietf.org/doc/html/rfc6698). ## Tipo de registro TXT Um registro TXT contém uma ou mais strings que estão entre aspas duplas (`"`). Quando você usar a [política de roteamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) simples, inclua todos os valores para um domínio (example.com) ou subdomínio (www.example.com) no mesmo registro TXT. **Topics** + [Inserir valores de registro TXT](#TXTformat-limits) + [Caracteres especiais em um valor de registro TXT](#TXTformat-special-characters) + [Maiúsculas e minúsculas em um valor de registro TXT](#TXTformat-case) + [Exemplos](#TXTformat-examples) ### Inserir valores de registro TXT Uma única string pode incluir até 255 caracteres, incluindo: + a-z + A-Z + 0-9 + Espaço + - (hífen) + \$1 " \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ \$1 ] ^ \$1 ` \$1 \$1 \$1 \$1 . Se for necessário inserir um valor maior que 255 caracteres, quebre o valor em strings de 255 caracteres ou menos e coloque cada string entre aspas duplas (`"`). No console, liste todas as strings na mesma linha: ``` "String 1" "String 2" "String 3" ``` Para a API, inclua todas as strings no mesmo elemento `Value`: ``` "String 1" "String 2" "String 3" ``` O tamanho máximo de um valor em um registro TXT é de 4.000 caracteres. Para inserir mais de um valor de TXT, insira um valor por linha. ### Caracteres especiais em um valor de registro TXT Se o registro TXT contém os caracteres a seguir, você deve especificar os caracteres usando códigos de escape no formato `\`*código octal de três dígitos*: + Os caracteres 000 a 040 octal (0 a 32 decimal, 0x00 a 0x20 hexadecimal) + Os caracteres 177 a 377 octal (127 a 255 decimal, 0x7F a 0xFF hexadecimal) Por exemplo, se o valor do seu registro TXT é `"exämple.com"`, você especifica `"ex\344mple.com"`. Para um mapeamento entre caracteres ASCII e códigos octais, faça uma pesquisa na Internet com "ascii octal codes." Uma referência útil é [Código ASCII – A tabela ASCII estendida](https://www.ascii-code.com/). Para incluir as aspas (`"`) em uma string, coloque um caractere de barra invertida (`\`) antes das aspas: `\"`. ### Maiúsculas e minúsculas em um valor de registro TXT O uso de maiúsculas e minúsculas é preservado, portanto, `"Ab"` e `"aB"` são valores diferentes. ### Exemplos **Exemplo para o console do Amazon Route 53** Coloque cada valor em uma linha separada: ``` "This string includes \"quotation marks\"." "The last character in this string is an accented e specified in octal format: \351" "v=spf1 ip4:192.168.0.1/16 -all" ``` **Exemplo para a API do Route** Coloque cada valor em um elemento de `Value` separado: ``` "This string includes \"quotation marks\"." "The last character in this string is an accented e specified in octal format: \351" "v=spf1 ip4:192.168.0.1/16 -all" ``` # Criar registros usando o console do Amazon Route 53 O procedimento a seguir explica como criar registros usando o console do Amazon Route 53. Para obter informações sobre como criar registros usando a API do Route 53, consulte [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)a *Referência da API do Amazon Route 53*. **nota** Para criar registros para configurações de roteamento complexas, você também pode usar o editor visual de Fluxo de tráfego e salvar a configuração como uma política de tráfego. Em seguida, é possível associar a política de tráfego a um ou mais nomes de domínio (como example.com) ou nomes de subdomínio (como www.example.com), na mesma ou em várias zonas hospedadas. Além disso, você poderá reverter as atualizações se a nova configuração não estiver sendo executada conforme o esperado. Para obter mais informações, consulte [Uso do Fluxo de tráfego para rotear tráfego de DNS](traffic-flow.md). **Para criar um registro usando o console do Route 53** 1. Se você não estiver criando um registro de alias, vá para a etapa 2. Também vá para a etapa 2 se você estiver criando um registro de alias que roteia o tráfego DNS para um AWS recurso que não seja um balanceador de carga do Elastic Load Balancing ou outro registro do Route 53. Se você estiver criando um registro de alias que roteia tráfego para um balanceador de carga de Elastic Load Balancing e tiver criado a zona hospedada e o balanceador de carga usando contas diferentes, siga o procedimento [Obter o nome do DNS para um balanceador de carga de Elastic Load Balancing](#resource-record-sets-elb-dns-name-procedure) para obter o nome DNS do balanceador de carga. 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 **Zonas hospedadas**. 1. Se você já tem uma zona hospedada para seu domínio, vá para a etapa 5. Se você não tem, siga o procedimento aplicável para criar uma zona hospedada: + Para encaminhar o tráfego de Internet para seus recursos, como buckets do Amazon S3 ou instâncias do Amazon EC2, consulte [Criar uma zona hospedada pública](CreatingHostedZone.md). + Para rotear o tráfego em sua VPC, consulte [Criar uma zona hospedada privada](hosted-zone-private-creating.md). 1. Na página **Hosted zones** (Zonas hospedadas), escolha o nome da zona hospedada na qual deseja criar os registros. 1. Escolha **Create record** (Criar registro). 1. Escolha e defina valores e política de roteamento aplicáveis. Para obter mais informações, consulte o tópico para o tipo de registro que você deseja criar: + [Valores que são comuns para todas as políticas de roteamento](resource-record-sets-values-shared.md) + [Valores que são comuns para registros de alias em todas as políticas de roteamento](resource-record-sets-values-alias-common.md) + [Valores específicos para registros simples](resource-record-sets-values-basic.md) + [Valores específicos para registros de alias simples](resource-record-sets-values-alias.md) + [Valores específicos para registros de failover](resource-record-sets-values-failover.md) + [Valores específicos para registros de alias de failover](resource-record-sets-values-failover-alias.md) + [Valores específicos para registros de localização geográfica](resource-record-sets-values-geo.md) + [Valores específicos para registros de alias de localização geográfica](resource-record-sets-values-geo-alias.md) + [Valores específicos para registros de geoproximidade](resource-record-sets-values-geoprox.md) + [Valores específicos para registros de alias de geoproximidade](resource-record-sets-values-geoprox-alias.md) + [Valores específicos para registros de latência](resource-record-sets-values-latency.md) + [Valores específicos para registros de alias de latência](resource-record-sets-values-latency-alias.md) + [Valores específicos para registros baseados em IP](resource-record-sets-values-ipbased.md) + [Valores específicos para registros de alias baseado em IP](resource-record-sets-values-ipbased-alias.md) + [Valores específicos para registros de resposta com valores múltiplos](resource-record-sets-values-multivalue.md) + [Valores específicos para registros ponderados](resource-record-sets-values-weighted.md) + [Valores específicos para registros de alias ponderados](resource-record-sets-values-weighted-alias.md) 1. Escolha **Criar registros**. **nota** Os novos registros demoram para ser propagados até os servidores DNS do Route 53. Atualmente, a única forma de verificar se as alterações se propagaram é usando a ação da [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. As alterações geralmente são propagadas para todos os servidores de nome do Route 53 em até 60 segundos. 1. Se você estiver criando vários registros, repita as etapas de 7 a 8. **Obter o nome do DNS para um balanceador de carga de Elastic Load Balancing** 1. Faça login Console de gerenciamento da AWS usando a AWS conta que foi usada para criar o Classic, o Application ou o Network Load Balancer para o qual você deseja criar um registro de alias. 1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. No painel de navegação, selecione **Load Balancers**. 1. Na lista de load balancers, selecione aquele para o qual você deseja criar um registro de alias. 1. Na guia **Descrição**, obtenha o valor de **Nome DNS**. 1. Se quiser criar registros de alias para outros balanceadores de carga de Elastic Load Balancing, repita as etapas 4 e 5. 1. Saia do Console de gerenciamento da AWS. 1. Faça login Console de gerenciamento da AWS novamente usando a AWS conta que você usou para criar a zona hospedada do Route 53. 1. Volte para a etapa 3 do procedimento [Criar registros usando o console do Amazon Route 53](#resource-record-sets-creating). # Permissões do conjunto de registros de recursos As permissões do conjunto de registros de recursos usam condições de política de gerenciamento de identidade e acesso (IAM) para permitir que você defina permissões granulares para ações no console do Route 53 ou para usar a [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)API. Um conjunto de registros de recursos é definido como vários registros de recursos com o mesmo nome e tipo (e classe, mas, para a maioria dos propósitos, a classe é sempre IN ou Internet), mas eles contêm dados diferentes. Por exemplo, se você escolher o roteamento por geolocalização, poderá ter vários registros A ou AAAA apontando para diferentes endpoints do mesmo domínio. Todos esses registros A ou AAAA se combinam para formar um conjunto de registros de recursos. Para obter mais informações sobre a terminologia DNS, consulte [RFC 7719](https://datatracker.ietf.org/doc/html/rfc7719). Com as condições da política do IAM`route53:ChangeResourceRecordSetsNormalizedRecordNames`,`route53:ChangeResourceRecordSetsRecordTypes`,, e`route53:ChangeResourceRecordSetsActions`, você pode conceder direitos administrativos granulares a outros AWS usuários em qualquer outra AWS conta. Isso permite que você conceda a alguém permissões para: + Um único conjunto de registros de recursos. + Todos os conjuntos de registros de recursos de um tipo de registro DNS específico. + Conjuntos de registros de recursos em que os nomes contêm uma string específica. + Execute uma ou todas as `CREATE | UPSERT | DELETE ` ações ao usar a [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)API ou o console do Route 53. Você também pode criar permissões de acesso que combinem qualquer uma das condições da política do Route 53. Por exemplo, você pode conceder a alguém permissões para modificar os dados do registro A para marketing-example.com, mas não permitir que esse usuário exclua nenhum registro. Para saber mais sobre permissões de conjuntos de registros de recursos e ver exemplos de como usá-las, consulte [Uso de condições de política do IAM para controle de acesso refinado](specifying-conditions-route53.md). Para saber como autenticar AWS usuários, consulte [Autenticação com identidades](security-iam.md#security_iam_authentication) e saiba como controlar o acesso aos recursos do Route 53, consulte[Controle de acesso](security-iam.md#access-control). # Valores que você especifica ao criar ou editar registros do Amazon Route 53 Quando você cria registros usando o console do Amazon Route 53, os valores que você especifica dependem da política de roteamento que você deseja usar e se você está criando registros de alias, que direcionam o tráfego para AWS os recursos. Registros de alias que roteiam o tráfego para determinados AWS recursos para os quais você especifica o recurso de destino (por exemplo, Elastic Load Balancing CloudFront , distribuição, bucket do Amazon S3). Opcionalmente, você também pode associar verificações de integridade e configurar a avaliação de integridade do destino. Os tópicos a seguir fornecem informações detalhadas sobre os valores exigidos para cada política de roteamento e tipo de registro, ajudando você a configurar seus registros do Route 53 de forma eficaz. **Topics** + [Valores que são comuns para todas as políticas de roteamento](resource-record-sets-values-shared.md) + [Valores que são comuns para registros de alias em todas as políticas de roteamento](resource-record-sets-values-alias-common.md) + [Valores específicos para registros simples](resource-record-sets-values-basic.md) + [Valores específicos para registros de alias simples](resource-record-sets-values-alias.md) + [Valores específicos para registros de failover](resource-record-sets-values-failover.md) + [Valores específicos para registros de alias de failover](resource-record-sets-values-failover-alias.md) + [Valores específicos para registros de localização geográfica](resource-record-sets-values-geo.md) + [Valores específicos para registros de alias de localização geográfica](resource-record-sets-values-geo-alias.md) + [Valores específicos para registros de geoproximidade](resource-record-sets-values-geoprox.md) + [Valores específicos para registros de alias de geoproximidade](resource-record-sets-values-geoprox-alias.md) + [Valores específicos para registros de latência](resource-record-sets-values-latency.md) + [Valores específicos para registros de alias de latência](resource-record-sets-values-latency-alias.md) + [Valores específicos para registros baseados em IP](resource-record-sets-values-ipbased.md) + [Valores específicos para registros de alias baseado em IP](resource-record-sets-values-ipbased-alias.md) + [Valores específicos para registros de resposta com valores múltiplos](resource-record-sets-values-multivalue.md) + [Valores específicos para registros ponderados](resource-record-sets-values-weighted.md) + [Valores específicos para registros de alias ponderados](resource-record-sets-values-weighted-alias.md) # Valores que são comuns para todas as políticas de roteamento Estes são os valores comuns que você pode especificar ao criar ou editar registros do Amazon Route 53. Eles são utilizados por todas as políticas de roteamento. **Topics** + [Nome do registro](#rrsets-values-common-name) + [Valor/Encaminhar tráfego para](#rrsets-values-common-value) + [TTL (segundos)](#rrsets-values-common-ttl) ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Name (Nome)**. **Registros CNAME** Se você estiver criando um registro com um valor **CNAME** para o **Record type** (Tipo de registro), o registro não poderá ter o mesmo o nome da zona hospedada. **Caracteres especiais** Para obter informações sobre como especificar caracteres que não sejam a-z, 0-9 e - (hífen) e como especificar nomes de domínio internacionalizados, consulte [Formato de nome de domínio DNS](DomainNameFormat.md). **Caracteres curinga** Você pode usar um asterisco (\$1) no nome. O DNS trata o caractere \$1 como um caractere curinga ou como o caractere \$1 (ASCII 42), dependendo de onde ele aparece no nome. Para obter mais informações, consulte [Usar um asterisco (\$1) nos nomes de zonas hospedadas e registros](DomainNameFormat.md#domain-name-format-asterisk). O curinga \$1 não pode ser usado para conjuntos de registros de recursos que tenham um tipo **NS**. ## Valor/Encaminhar tráfego para Escolha o **endereço IP ou outro valor dependendo do tipo de registro**. Insira um valor que seja adequado para o valor de **Record type** (Tipo de registro). Para todos os tipos exceto **CNAME**, é possível incorporar mais de um valor. Insira cada valor em uma linha separada. **A — IPv4 endereço** Um endereço IP no IPv4 formato, por exemplo, **192.0.2.235**. **AAAA — IPv6 endereço** Um endereço IP no IPv6 formato, por exemplo, **2001:0 db 8:85 a 3:0:0:8 a2e: 0370:7334**. **CAA: Autorização da Autoridade de Certificação** Três valores separados por vírgula que determinam quais autoridades de certificação têm permissão para emitir certificados ou certificados curinga para o domínio ou o subdomínio especificado por **Record name** (Nome do registro). Você pode usar registros CAA para especificar: + Quais autoridades de certificação (CAs) podem emitir SSL/TLS certificados, se houver + O endereço de e-mail ou o URL a ser contatado quando a CA emitir um certificado para o domínio ou o subdomínio **CNAME: Nome canônico** O nome de domínio totalmente qualificado (por *exemplo, www.example.com*) que você deseja que o Route 53 retorne em resposta a consultas de DNS para esse registro. Um ponto final é opcional; o Route 53 pressupõe que o nome de domínio seja totalmente qualificado. Isso significa que o Route 53 trata *www.exemplo.com* (sem um ponto final) e *www.exemplo.com.* (com um ponto final) como valores idênticos. **MX: Servidor de mensagens** Uma prioridade e um nome de domínio especificando um servidor de e-mail, por exemplo, **10 mailserver.example.com**. O ponto final é tratado como opcional. **NAPTR: Ponteiro de Autoridade de Nomes** Seis configurações separadas por espaço que são usadas por aplicações DDDS (Sistema de descoberta de delegação dinâmica) para um valor para outro ou para substituir um valor por outro. Para obter mais informações, consulte [Tipo de registro NAPTR](ResourceRecordTypes.md#NAPTRFormat). **PTR: Ponteiro** O nome de domínio que você deseja que o Route 53 retorne. **NS: servidor de nomes** O nome de domínio um servidor de nomes, por exemplo, **ns1.example.com**. É possível especificar um registro NS apenas com uma política de roteamento simples. **SPF: Framework de Política de Remetente** Um registro de SPF entre aspas exemplo, **"v=spf1 ip4:192.168.0.1/16-all"**. Não é recomendado usar registros de SPF. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). **SRV: Localizador de serviço** Um registro de SRV. Os registros de SRV são usados para acessar serviços, como um serviço para e-mail ou comunicações. Para obter informações sobre o formato de registros de SRV, consulte a documentação do serviço ao qual você deseja se conectar. O ponto final é tratado como opcional. O formato de um registro de SRV é: **[priority] [weight] [port] [server host name] ([prioridade] [peso] [porta] [nome de host do servidor])** Por exemplo: **1 10 5269 xmpp-server.example.com.** **TXT: Texto** Um registro de texto. Texto entre aspas, por exemplo, **“Sample text entry”** (“Exemplo de entrada de texto”). ## TTL (segundos) A quantidade de tempo, em segundos, que você deseja que os resolvedores recursivos de DNS armazenem informações em cache sobre esse registro. Se você especificar um valor mais longo (por exemplo, 172800 segundos ou dois dias), reduzirá o número de chamadas que os resolvedores recursivos de DNS devem fazer ao Route 53 para obter as informações mais recentes neste registro. Isso tem o efeito de reduzir a latência e reduzir sua fatura para o serviço do Route 53. Para obter mais informações, consulte [Como o Amazon Route 53 encaminha tráfego para o seu domínio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). No entanto, se você especificar um valor mais longo para TTL, levará mais tempo para que as alterações no registro (por exemplo, um novo endereço IP) entrem em vigor porque os resolvedores recursivos usam os valores em cache por períodos mais longos antes de solicitar as informações mais recentes ao Route 53. Se você estiver alterando as configurações de um domínio ou subdomínio que já está em uso, recomendamos que especifique inicialmente um valor mais curto, como 300 segundos, e aumente o valor depois de confirmar que as novas configurações estão corretas. Se você estiver associando esse registro a uma verificação de integridade, recomendamos especificar um TTL de 60 segundos ou menos para que os clientes respondam rapidamente a alterações no status de integridade. # Valores que são comuns para registros de alias em todas as políticas de roteamento Estes são os valores de alias comuns que você pode especificar ao criar ou editar registros do Amazon Route 53. Eles são utilizados por todas as políticas de roteamento. **Topics** + [Nome do registro](#rrsets-values-common-alias-name) + [Valor/rotear tráfego para](#rrsets-values-alias-common-target) ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Name (Nome)**. **Registros CNAME** Se você estiver criando um registro com um valor **CNAME** para o **Type** (Tipo), o registro não poderá ter o mesmo o nome da zona hospedada. **Aliases para CloudFront distribuições e buckets do Amazon S3** O valor que você especifica depende em parte do AWS recurso para o qual você está roteando o tráfego: + **CloudFront distribuição** — Sua distribuição deve incluir um nome de domínio alternativo que corresponda ao nome do registro. Por exemplo, se o nome do registro for **acme.example.com**, sua distribuição do CloudFront deve incluir **acme.example.com** como um dos nomes de domínio alternativos. Para obter mais informações, consulte [Uso de nomes de domínio alternativos (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) no *Amazon CloudFront Developer Guide*. + **Bucket do Amazon S3** (Bucket do Amazon S3): o nome do registro deve corresponder ao nome de seu bucket do Amazon S3. Por exemplo, se o nome do seu bucket for **acme.example.com**, o nome desse registro também deve ser **acme.example.com**. Além disso, você deve configurar o bucket para hospedagem de sites. Para obter mais informações, consulte o tópico sobre como [Configurar um bucket para hospedagem do sites](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html), no *Guia do usuário do Amazon Simple Storage Service*. **Caracteres especiais** Para obter informações sobre como especificar caracteres que não sejam a-z, 0-9 e - (hífen) e como especificar nomes de domínio internacionalizados, consulte [Formato de nome de domínio DNS](DomainNameFormat.md). **Caracteres curinga** Você pode usar um asterisco (\$1) no nome. O DNS trata o caractere \$1 como um caractere curinga ou como o caractere \$1 (ASCII 42), dependendo de onde ele aparece no nome. Para obter mais informações, consulte [Usar um asterisco (\$1) nos nomes de zonas hospedadas e registros](DomainNameFormat.md#domain-name-format-asterisk). ## Valor/rotear tráfego para O valor que você escolhe na lista ou digita no campo depende do AWS recurso para o qual você está roteando o tráfego. Para obter mais informações sobre como configurar o Route 53 para rotear o tráfego para AWS recursos específicos, consulte[Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). **Importante** Se você usou a mesma AWS conta para criar sua zona hospedada e o recurso para o qual você está direcionando o tráfego, e se seu recurso não aparecer na lista de **endpoints**, verifique o seguinte: Confirme se você escolheu um valor compatível em **Record type** (Tipo de registro). Os valores compatíveis são específicos do recurso para o qual o tráfego está sendo roteado. Por exemplo, para rotear o tráfego para um bucket do S3, você deve escolher **A — IPv4 endereço** para o **tipo de registro**. Verifique se a conta tem as permissões do IAM necessárias para listar os recursos aplicáveis. Por exemplo, para que as distribuições do CloudFront sejam exibidas na lista **Endpoint**, a conta deve ter permissão para realizar a seguinte ação: `cloudfront:ListDistributions`. Para ver um exemplo de política do IAM, consulte [Permissões necessárias para usar o console do Amazon Route 53](access-control-managing-permissions.md#console-required-permissions). Se você usou AWS contas diferentes para criar a zona hospedada e o recurso, a lista de **endpoints** não exibirá seu recurso. Consulte a documentação a seguir para o tipo de recurso, a fim de determinar qual valor deve ser digitado em **Endpoint**. **API Gateway: personalizado, regional APIs e otimizado para bordas APIs** Para o API Gateway, regional personalizado APIs e otimizado para bordas APIs, faça o seguinte: + **Se você usou a mesma conta para criar sua zona hospedada do Route 53 e sua API**: escolha **Endpoint** e escolha uma API na lista. Se você tiver muitos APIs, poderá inserir os primeiros caracteres do endpoint da API para filtrar a lista. **nota** O nome desse registro deve corresponder a um nome de domínio personalizado para sua API, como **api.example.com**. + **Se você usou contas diferentes para criar sua zona hospedada do Route 53 e a API**: insira o endpoint da API para a API, como **api.example.com**. Se você usou uma AWS conta para criar a zona hospedada atual e outra para criar uma API, a API não aparecerá na lista de **endpoints** em **API Gateway APIs**. Se você usou uma conta para criar a zona hospedada atual e uma ou mais contas diferentes para criar todas as suas APIs, a lista de **endpoints** mostrará **Não há destinos disponíveis** no **API Gateway APIs**. Para obter mais informações, consulte [Encaminhar o tráfego para uma API do Amazon API Gateway por meio do seu nome de domínio](routing-to-api-gateway.md). **CloudFront distribuições** Para CloudFront distribuições, faça o seguinte: + **Se você usou a mesma conta para criar sua zona hospedada do Route 53 e sua CloudFront distribuição**, escolha **Endpoint** e escolha uma distribuição na lista. Se tiver uma grande quantidade de distribuições, você poderá inserir os primeiros caracteres do nome de domínio de sua distribuição para filtrar a lista. Caso sua distribuição não apareça na lista, observe o seguinte: + O nome do registro deve corresponder a um nome de domínio alternativo em sua distribuição. + Se você acabou de adicionar um nome de domínio alternativo à sua distribuição, pode levar 15 minutos para que suas alterações se propaguem para todos os pontos de CloudFront presença. Até que as alterações tenham sido propagadas, o Route 53 não conhecerá o novo nome de domínio alternativo. + **Se você usou contas diferentes para criar sua zona hospedada do Route 53 e sua distribuição, insira o nome de CloudFront domínio da distribuição**, como **d111111abcdef8.cloudfront.net**. Se você usou uma AWS conta para criar a zona hospedada atual e uma conta diferente para criar uma distribuição, a distribuição não aparecerá na lista de **endpoints**. **Se você usou uma conta para criar a zona hospedada atual e uma ou mais contas diferentes para criar todas as suas distribuições, a lista de **endpoints** mostrará **Não há destinos disponíveis** em CloudFront distribuições.** Não encaminhe consultas para uma CloudFront distribuição que não tenha se propagado para todos os pontos de presença, ou seus usuários não conseguirão acessar o conteúdo aplicável. Sua CloudFront distribuição deve incluir um nome de domínio alternativo que corresponda ao nome do registro. Por exemplo, se o nome do registro for **acme.exemplo.com, sua CloudFront distribuição deverá incluir **acme.exemplo.com**** como um dos nomes de domínio alternativos. Para obter mais informações, consulte [Uso de nomes de domínio alternativos (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) no *Amazon CloudFront Developer Guide*. Se IPv6 estiver habilitado para a distribuição, crie dois registros, um com o valor A **— IPv4 endereço** para o **tipo de registro** e outro com o valor **AAAA — IPv6 endereço**. Para obter mais informações, consulte [Roteamento de tráfego para uma CloudFront distribuição da Amazon usando seu nome de domínio](routing-to-cloudfront-distribution.md). **Serviço do App Runner** Para o serviço App Runner, execute uma das seguintes ações: + **Se você usou a mesma conta para criar sua zona hospedada do Route 53 e seu serviço App Runner** Região da AWS, escolha o nome de domínio do ambiente para o qual você deseja rotear o tráfego na lista. + **Se você usou contas diferentes para criar sua zona hospedada do Route 53 e seu App Runner**: insira o nome do domínio personalizado. Para obter mais informações, consulte [Gerenciamento de nomes de domínio personalizados para um serviço do App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains.html). Se você usou uma AWS conta para criar a zona hospedada atual e uma conta diferente para criar um App Runner, o App Runner não aparecerá na lista de **Endpoints**. Para obter mais informações, consulte [Configurar o Amazon Route 53 para direcionar o tráfego para um serviço do App Runner](routing-to-app-runner.md#routing-to-app-runner-configuring). **Ambientes do Elastic Beanstalk com subdomínios regionalizados** Se o nome de domínio do seu ambiente do Elastic Beanstalk incluir a região na qual você implantou esse ambiente, será possível criar um registro de alias que encaminha o tráfego a esse ambiente. Por exemplo, o nome de domínio `my-environment.us-west-2.elasticbeanstalk.com` é um nome de domínio regionalizado. Para ambientes que foram criados antes do início de 2016, o nome do domínio não inclui a região. Para rotear o tráfego a esses ambientes, você deve criar um registro CNAME em vez de um registro de alias. Observe que não é possível criar um registro CNAME para o nome de domínio raiz. Por exemplo, se o nome de seu domínio for exemplo.com, você poderá criar um registro que direciona o tráfego de acme.exemplo.com para seu ambiente do Elastic Beanstalk, mas não poderá criar um registro que direcione o tráfego de exemplo.com para seu ambiente do Elastic Beanstalk. Para ambientes do Elastic Beanstalk com subdomínios regionalizados, faça o seguinte: + **Se você usou a mesma conta para criar sua zona hospedada do Route 53 e seu ambiente do Elastic Beanstalk**: escolha **Endpoint** e escolha um ambiente na lista. Se tiver uma grande quantidade de ambientes, você poderá inserir os primeiros caracteres do atributo CNAME do ambiente para filtrar a lista. + **Se você usou contas diferentes para criar sua zona hospedada do Route 53 e seu ambiente do Elastic Beanstalk**: insira o atributo CNAME para o ambiente do Elastic Beanstalk. Para obter mais informações, consulte [Roteamento do tráfego para um ambiente AWS Elastic Beanstalk](routing-to-beanstalk-environment.md). **Load balancers do ELB** Para load balancers do ELB, realize uma das seguintes ações: + **Se você usou a mesma conta para criar sua zona hospedada do Route 53 e seu balanceador de carga**: escolha **Endpoint** e escolha um balanceador de carga na lista. Se tiver uma grande quantidade de load balancers, você poderá inserir os primeiros caracteres do nome de DNS para filtrar a lista. + **Se você usou contas diferentes para criar sua zona hospedada do Route 53 e seu balanceador de carga**: insira o valor que você recebeu no procedimento [Obter o nome do DNS para um balanceador de carga de Elastic Load Balancing](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure). Se você usou uma AWS conta para criar a zona hospedada atual e outra conta para criar um balanceador de carga, o balanceador de carga não aparecerá na lista de **endpoints**. Se você usou uma conta para criar a zona hospedada atual e uma ou mais contas diferentes para criar todos os seus balanceadores de carga, a lista **Endpoints** mostrará **No targets available** (Nenhum destino disponível) em **Elastic Load Balancers** (Balanceadores de carga elásticos). O console precede **dualstack.** para o Application Load Balancer e o Classic Load Balancer de uma conta diferente. Quando um cliente, como um navegador da Web, solicita o endereço IP do seu nome de domínio (exemplo.com) ou nome de subdomínio (www.exemplo.com), o cliente pode solicitar um IPv4 endereço (um registro A), um endereço (um registro AAAA) ou ambos IPv4 e IPv6 IPv6 endereços (em solicitações separadas). A designação **dualstack.** permite que o Route 53 responda com o endereço IP apropriado ao seu balanceador de carga com base no formato de endereço IP que o cliente solicitou. Para obter mais informações, consulte [Rotear tráfego para um load balancer do ELB](routing-to-elb-load-balancer.md). **AWS Aceleradores Global Accelerator** Para aceleradores do AWS Global Accelerator, insira o nome DNS do acelerador. Você pode inserir o nome DNS de um acelerador que você criou usando a AWS conta atual ou usando uma conta diferente AWS . **Buckets do Amazon S3** Para buckets do Amazon S3 que estão configurados como endpoints de site, realize uma das seguintes ações: + **Se você usou a mesma conta para criar sua zona hospedada do Route 53 e seu bucket do Amazon S3**: escolha **Endpoint** e escolha um bucket da lista. Se tiver uma grande quantidade de buckets, você poderá inserir os primeiros caracteres do nome de DNS para filtrar a lista. O valor de **Endpoint** é alterado para o endpoint do site do Amazon S3 do seu bucket. + **Se você usou contas diferentes para criar sua zona hospedada do Route 53 e seu bucket do Amazon S3**: insira o nome da região na qual criou o bucket do S3. Use o valor exibido na coluna **Endpoint de site** na tabela [Amazon S3 website endpoints](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints) no *Referência geral da Amazon Web Services*. **Se você usou AWS contas diferentes da conta atual para criar seus buckets do Amazon S3, o bucket não aparecerá na lista de endpoints.** Você deve configurar o bucket para hospedagem de sites. Para obter mais informações, consulte o tópico sobre como [Configurar um bucket para hospedagem do sites](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html), no *Guia do usuário do Amazon Simple Storage Service*. O nome do registro deve corresponder ao nome de seu bucket do Amazon S3. Por exemplo, se o nome do seu bucket do Amazon S3 for **acme.example.com**, o nome desse registro também deve ser **acme.example.com**. Em um grupo de registros de alias ponderado, alias de latência, alias de failover ou de alias de localização geográfica, você pode criar apenas um registro que encaminhará as consultas para um bucket do Amazon S3 porque o nome do registro deve coincidir com o nome do bucket, e os nomes de bucket devem ser globalmente exclusivos. ** OpenSearch Serviço Amazon** Para OpenSearch Serviço, faça o seguinte: + **OpenSearch Domínio personalizado do serviço**: o nome do registro deve corresponder ao domínio personalizado. Por exemplo, se o nome do seu domínio personalizado for test.example.com, o nome desse registro também deve ser test.example.com. + **Se você usou a mesma conta para criar sua zona hospedada do Route 53 e seu domínio de OpenSearch serviço** Região da AWS, escolha a e escolha o nome do domínio. + **Se você usou contas diferentes para criar sua zona hospedada do Route 53 e seu domínio OpenSearch de serviço**, insira o nome de domínio personalizado. Consulte mais informações em [Criar um endpoint personalizado](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/customendpoint.html). Se você usou uma AWS conta para criar a zona hospedada atual e uma conta diferente para criar um domínio de OpenSearch serviço, o domínio não aparecerá na lista de **endpoints**. **Se você usou uma conta para criar a zona hospedada atual e uma ou mais contas diferentes para criar todos os seus domínios de OpenSearch serviço, a lista de **endpoints** mostrará **Não há destinos disponíveis** em OpenSearch Serviço.** Para obter mais informações, consulte [Configurando o Amazon Route 53 para rotear o tráfego para um endpoint de domínio do Amazon OpenSearch Service](routing-to-open-search-service.md#routing-to-open-search-service-configuring). **Endpoints de interface da Amazon VPC** Para endpoints da interface da Amazon VPC, realize um dos seguintes procedimentos: + **Se você usou a mesma conta para criar sua zona hospedada do Route 53 e seu endpoint da interface**: escolha **Endpoint** e escolha um endpoint da interface da lista. Se tiver uma grande quantidade de endpoints de interface, insira os primeiros caracteres do nome de host de DNS para filtrar a lista. + **Se você usou contas diferentes para criar sua zona hospedada do Route 53 e seu endpoint de interface, insira o nome do host DNS para o endpoint da interface****, como vpce-123456789abcdef01- -1a.elasticloadbalancing.us-east-1.vpce.amazonaws.com. example-us-east** **Se você usou uma AWS conta para criar a zona hospedada atual e outra conta para criar um endpoint de interface, o endpoint de interface não aparecerá na lista de endpoints em **VPC endpoints**.** Se tiver usado uma conta para criar a zona hospedada atual e uma ou mais contas diferentes para criar todos os seus endpoints de interface, a lista **Endpoint** mostra **No targets available** (Nenhum destino disponível) em **VPC Endpoints** (Endpoints da VPC). Para obter mais informações, consulte [Como encaminhar o tráfego para um endpoint de interface da Amazon Virtual Private Cloud por meio do seu nome de domínio](routing-to-vpc-interface-endpoint.md). **Registros nessa zona hospedada** Para registros nessa zona hospedada, escolha **Endpoint** e escolha o registro aplicável. Se tiver uma grande quantidade de registros, você poderá inserir os primeiros caracteres do nome para filtrar a lista. Se a zona hospedada contiver apenas os registros de NS e SOA padrão, a lista de **Endpoints** mostrará **No targets available** (Nenhum destino disponível). Se você estiver criando um registro de alias com o mesmo nome da zona hospedada (conhecida como *apex de zona*), não será possível escolher um registro para o qual o valor de **Record type** (Tipo de registro) seja **CNAME**. Isso ocorre porque o registro de alias deve ter o mesmo tipo que o registro para o qual você está roteando o tráfego e não há suporte para criar um registro CNAME para o apex de zona mesmo para um registro de alias. # Valores específicos para registros simples Quando você criar registros básicos, especifique os seguintes valores. **Topics** + [Política de roteamento](#rrsets-values-basic-routing-policy) + [Nome do registro](#rrsets-values-basic-name) + [Valor/Encaminhar tráfego para](#rrsets-values-basic-value) + [Tipo de registro](#rrsets-values-basic-type) + [TTL (segundos)](#rrsets-values-basic-ttl) ## Política de roteamento Escolha **Simple routing** (Roteamento simples). ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Name (Nome)**. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Valor/Encaminhar tráfego para Escolha o **endereço IP ou outro valor dependendo do tipo de registro**. Insira um valor que seja adequado para o valor de **Record type** (Tipo de registro). Para todos os tipos exceto **CNAME**, é possível incorporar mais de um valor. Insira cada valor em uma linha separada. Você pode direcionar tráfego ou especificar os seguintes valores: + **A — IPv4 endereço** + **AAAA — IPv6 endereço** + **CAA: Autorização da Autoridade de Certificação** + **CNAME: Nome canônico** + **MX: Intercâmbio de mensagens** + **NAPTR: Ponteiro de Autoridade de Nomes** + **NS: servidor de nomes** O nome de domínio um servidor de nomes, por exemplo, **ns1.example.com**. **nota** É possível especificar um registro NS apenas com uma política de roteamento simples. + **PTR: Ponteiro** + **SPF: Framework de Política de Remetente** + **SRV: Localizador de serviço** + **TXT: Texto** Para obter mais informações sobre os valores acima, consulte [valores comuns para Value/Route tráfego para](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o valor para **Record type** (Tipo de registro) com base em como deseja que o Route 53 responda a consultas de DNS. ## TTL (segundos) A quantidade de tempo, em segundos, que você deseja que os resolvedores recursivos de DNS armazenem informações em cache sobre esse registro. Se você especificar um valor mais longo (por exemplo, 172800 segundos ou dois dias), reduzirá o número de chamadas que os resolvedores recursivos de DNS devem fazer ao Route 53 para obter as informações mais recentes neste registro. Isso tem o efeito de reduzir a latência e reduzir sua fatura para o serviço do Route 53. Para obter mais informações, consulte [Como o Amazon Route 53 encaminha tráfego para o seu domínio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). No entanto, se você especificar um valor mais longo para TTL, levará mais tempo para que as alterações no registro (por exemplo, um novo endereço IP) entrem em vigor porque os resolvedores recursivos usam os valores em cache por períodos mais longos antes de solicitar as informações mais recentes ao Route 53. Se você estiver alterando as configurações de um domínio ou subdomínio que já está em uso, recomendamos que especifique inicialmente um valor mais curto, como 300 segundos, e aumente o valor depois de confirmar que as novas configurações estão corretas. # Valores específicos para registros de alias simples Quando você criar registros de alias, especifique os seguintes valores. Para obter mais informações, consulte [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md). **nota** Se você estiver usando o Route 53 no AWS GovCloud (US) Region, esse recurso tem algumas restrições. Para obter mais informações, consulte a [página do Amazon Route 53](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html) no *Guia do usuário do AWS GovCloud (US) *. **Topics** + [Política de roteamento](#rrsets-values-alias-routing-policy) + [Nome do registro](#rrsets-values-alias-name) + [Valor/rotear tráfego para](#rrsets-values-alias-alias-target) + [Tipo de registro](#rrsets-values-alias-type) + [Avaliar status do alvo](#rrsets-values-alias-evaluate-target-health) ## Política de roteamento Escolha **Simple routing** (Roteamento simples). ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Name (Nome)**. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name). ## Valor/rotear tráfego para O valor que você escolhe na lista ou digita no campo depende do AWS recurso para o qual você está roteando o tráfego. Para obter informações sobre quais AWS recursos você pode segmentar, consulte [valores comuns para registros de alias para value/route tráfego](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target). Para obter mais informações sobre como configurar o Route 53 para rotear o tráfego para AWS recursos específicos, consulte[Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o valor aplicável com base no AWS recurso para o qual você está roteando o tráfego: **API regional personalizada do API Gateway ou API otimizada para bordas** Selecione **A — IPv4 endereço**. **Endpoints de interface da Amazon VPC** Selecione **A — IPv4 endereço**. **CloudFront distribuição** Selecione **A — IPv4 endereço**. Se IPv6 estiver habilitado para a distribuição, crie dois registros, um com um valor de A **— IPv4 endereço** para **Tipo** e outro com um valor de **AAAA — IPv6 endereço**. **Serviço do App Runner** Selecione **A — IPv4 endereço** **Ambiente do Elastic Beanstalk com subdomínios regionalizados** Selecione **A — IPv4 endereço** **Load balancer do ELB** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Bucket do Amazon S3.** Selecione **A — IPv4 endereço** **OpenSearch Serviço** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Outro registro nessa zona hospedada** Selecione o tipo de registro para o qual está criando o alias. Todos os tipos são compatíveis, exceto **NS** e **SOA**. Se você estiver criando um registro de alias com o mesmo nome da zona hospedada (conhecida como *apex de zona*), não será possível rotear o tráfego para um registro para o qual o valor de **Type (Tipo)** seja **CNAME**. Isso ocorre porque o registro de alias deve ter o mesmo tipo que o registro para o qual você está roteando o tráfego e não há suporte para criar um registro CNAME para o apex de zona mesmo para um registro de alias. ## Avaliar status do alvo Quando o valor de **Política de roteamento** é **Simples**, é possível escolher **Não** ou o padrão **Sim**, pois a opção **Avaliar integridade do destino** não tem efeito para o encaminhamento **Simpes**. Se você tiver apenas um registro com um nome e um tipo, o Route 53 responderá às consultas de DNS usando os valores desse registro, independentemente da integridade dos recursos. Para outras políticas de roteamento, **Avaliar a integridade do destino** determina se o Route 53 verifica a integridade do recurso ao qual o registro de alias se refere: + **Serviços em que a opção Avaliar a integridade do destino fornece benefícios operacionais**: para balanceadores de carga (ELB) e ambientes do AWS Elastic Beanstalk com balanceadores de carga, definir **Avaliar a integridade do destino** como **Sim** permite que o Route 53 roteie o tráfego para longe de recursos não íntegros. + **Serviços de alta disponibilidade**: para serviços como buckets Amazon S3, endpoints de interface VPC, Amazon API Gateway, AWS Global Accelerator Amazon Service e Amazon VPC Lattice OpenSearch **, o Evaluate Target** Health não oferece nenhum benefício operacional porque esses serviços foram projetados para alta disponibilidade. Para cenários de failover com esses serviços, use [verificações de integridade do Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html) em vez disso. Para obter informações detalhadas sobre como o **Evaluate Target Health** funciona com diferentes AWS serviços, consulte a [ EvaluateTargetHealth](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth)documentação na referência da API. # Valores específicos para registros de failover Quando você criar registros de failover, especifique os seguintes valores. **nota** Para obter informações sobre como criar registros de failover em uma zona hospedada privada, consulte [Configurar failover em uma zona hospedada privada](dns-failover-private-hosted-zones.md). **Topics** + [Política de roteamento](#rrsets-values-failover-routing-policy) + [Nome do registro](#rrsets-values-failover-name) + [Tipo de registro](#rrsets-values-failover-type) + [TTL (segundos)](#rrsets-values-failover-ttl) + [Valor/Encaminhar tráfego para](#rrsets-values-failover-value) + [Tipo de registro de failover](#rrsets-values-failover-record-type) + [Verificação de saúde](#rrsets-values-failover-associate-with-health-check) + [ID de registro](#rrsets-values-failover-set-id) ## Política de roteamento Escolha **Failover**. ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Record name** (Nome de registro). Insira o mesmo nome para os dois registros no grupo de registros de failover. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o mesmo valor para os registros de failover primário e secundário. ## TTL (segundos) A quantidade de tempo, em segundos, que você deseja que os resolvedores recursivos de DNS armazenem informações em cache sobre esse registro. Se você especificar um valor mais longo (por exemplo, 172800 segundos ou dois dias), reduzirá o número de chamadas que os resolvedores recursivos de DNS devem fazer ao Route 53 para obter as informações mais recentes neste registro. Isso tem o efeito de reduzir a latência e reduzir sua fatura para o serviço do Route 53. Para obter mais informações, consulte [Como o Amazon Route 53 encaminha tráfego para o seu domínio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). No entanto, se você especificar um valor mais longo para TTL, levará mais tempo para que as alterações no registro (por exemplo, um novo endereço IP) entrem em vigor porque os resolvedores recursivos usam os valores em cache por períodos mais longos antes de solicitar as informações mais recentes ao Route 53. Se você estiver alterando as configurações de um domínio ou subdomínio que já está em uso, recomendamos que especifique inicialmente um valor mais curto, como 300 segundos, e aumente o valor depois de confirmar que as novas configurações estão corretas. Se você estiver associando esse registro a uma verificação de integridade, recomendamos especificar um TTL de 60 segundos ou menos para que os clientes respondam rapidamente a alterações no status de integridade. ## Valor/Encaminhar tráfego para Escolha o **endereço IP ou outro valor dependendo do tipo de registro**. Insira um valor que seja adequado para o valor de **Record type** (Tipo de registro). Para todos os tipos exceto **CNAME**, é possível incorporar mais de um valor. Insira cada valor em uma linha separada. Você pode direcionar tráfego ou especificar os seguintes valores: + **A — IPv4 endereço** + **AAAA — IPv6 endereço** + **CAA: Autorização da Autoridade de Certificação** + **CNAME: Nome canônico** + **MX: Intercâmbio de mensagens** + **NAPTR: Ponteiro de Autoridade de Nomes** + **PTR: Ponteiro** + **SPF: Framework de Política de Remetente** + **SRV: Localizador de serviço** + **TXT: Texto** Para obter mais informações sobre os valores acima, consulte [valores comuns para Value/Route tráfego para](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Tipo de registro de failover Escolha o valor aplicável a esse registro. Para que o failover funcione corretamente, você deve criar um nó principal e um registro de failover secundário. Não é possível criar registros sem failover que tenham os mesmos valores para **Record name** (Nome do registro) e **Record type** (Tipo de registro) que os registros de failover. ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) em **Evaluate Target Health** (Avaliar a integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de geolocalização, alias de latência, alias baseado em IP ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain Name (Nome de domínio)**, especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain Name (Nome de domínio)** corresponde ao nome dos registros e associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. ## ID de registro Insira um valor que identifique os registros primários e secundários de forma exclusiva. # Valores específicos para registros de alias de failover Quando você criar registros de alias de failover, especifique os seguintes valores. Para obter informações, consulte os seguintes tópicos: + Para obter informações sobre como criar registros de failover em uma zona hospedada privada, consulte [Configurar failover em uma zona hospedada privada](dns-failover-private-hosted-zones.md). + Para obter informações sobre registros de alias, consulte [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Política de roteamento](#rrsets-values-failover-alias-routing-policy) + [Nome do registro](#rrsets-values-failover-alias-name) + [Tipo de registro](#rrsets-values-failover-alias-type) + [Valor/Encaminhar tráfego para](#rrsets-values-failover-alias-alias-target) + [Tipo de registro de failover](#rrsets-values-failover-alias-failover-record-type) + [Verificação de saúde](#rrsets-values-failover-alias-associate-with-health-check) + [Avaliar status do alvo](#rrsets-values-failover-alias-evaluate-target-health) + [ID de registro](#rrsets-values-failover-alias-set-id) ## Política de roteamento Escolha **Failover**. ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Record name** (Nome de registro). Insira o mesmo nome para os dois registros no grupo de registros de failover. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o valor aplicável com base no AWS recurso para o qual você está roteando o tráfego. Selecione o mesmo valor para os registros de failover primário e secundário: **API regional personalizada do API Gateway ou API otimizada para bordas** Selecione **A — IPv4 endereço**. **Endpoints de interface da Amazon VPC** Selecione **A — IPv4 endereço**. **CloudFront distribuição** Selecione **A — IPv4 endereço**. Se IPv6 estiver habilitado para a distribuição, crie dois registros, um com um valor de A **— IPv4 endereço** para **Tipo** e outro com um valor de **AAAA — IPv6 endereço**. **Serviço do App Runner** Selecione **A — IPv4 endereço** **Ambiente do Elastic Beanstalk com subdomínios regionalizados** Selecione **A — IPv4 endereço** **Load balancer do ELB** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Bucket do Amazon S3.** Selecione **A — IPv4 endereço** **OpenSearch Serviço** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Outro registro nessa zona hospedada** Selecione o tipo de registro para o qual está criando o alias. Todos os tipos são compatíveis, exceto **NS** e **SOA**. Se você estiver criando um registro de alias com o mesmo nome da zona hospedada (conhecida como *apex de zona*), não será possível rotear o tráfego para um registro para o qual o valor de **Type (Tipo)** seja **CNAME**. Isso ocorre porque o registro de alias deve ter o mesmo tipo que o registro para o qual você está roteando o tráfego e não há suporte para criar um registro CNAME para o apex de zona mesmo para um registro de alias. ## Valor/Encaminhar tráfego para O valor que você escolhe na lista ou digita no campo depende do AWS recurso para o qual você está roteando o tráfego. Para obter informações sobre quais AWS recursos você pode segmentar, consulte [valores comuns para registros de alias para value/route tráfego](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target). Para obter mais informações sobre como configurar o Route 53 para rotear o tráfego para AWS recursos específicos, consulte[Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). **nota** Ao criar registros de failover principais e secundários, você pode criar um failover e um registro de *alias* de failover que tenham os mesmos valores de **Name** (Nome) e **Record type** (Tipo de registro). Se você combinar registros de failover e de alias de failover, qualquer um deles pode ser um registro primário. ## Tipo de registro de failover Escolha o valor aplicável a esse registro. Para que o failover funcione corretamente, você deve criar um nó principal e um registro de failover secundário. Não é possível criar registros sem failover que tenham os mesmos valores para **Record name** (Nome do registro) e **Record type** (Tipo de registro) que os registros de failover. ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) em **Evaluate Target Health** (Avaliar a integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de geolocalização, alias de latência, alias baseado em IP ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain Name (Nome de domínio)**, especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain Name (Nome de domínio)** corresponde ao nome dos registros e associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. ## Avaliar status do alvo Selecione **Yes** (Sim), se quiser que o Route 53 determine se deve responder a consultas de DNS usando esse registro, verificando a integridade do recurso especificado pelo **Endpoint**. Observe o seguinte: **API Gateway: personalizado, regional APIs e otimizado para bordas APIs** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for uma API regional personalizada do API Gateway ou uma API otimizada para bordas. **CloudFront distribuições** Você não pode definir **Avaliar a integridade do alvo** como **Sim** quando o endpoint é uma CloudFront distribuição. **Ambientes do Elastic Beanstalk com subdomínios regionalizados** Se você especificar um ambiente do Elastic Beanstalk no **Endpoint** e o ambiente contiver um load balancer do ELB, o Elastic Load Balancing encaminhará consultas apenas para as instâncias íntegras ​​do Amazon EC2 que estão registradas com o balanceador de carga. (Um ambiente contém automaticamente um load balancer do ELB se incluir mais de uma instância do Amazon EC2.) Se você definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) e nenhuma instância do Amazon EC2 estiver íntegro ou o próprio balanceador de carga não estiver íntegro, o Route 53 encaminhará as consultas para outros recursos disponíveis que sejam íntegros, se houver. Se o ambiente contiver uma única instância do Amazon EC2, não há requisitos especiais. **Load balancers do ELB** O comportamento de verificação da integridade depende do tipo do load balancer: + **Classic Load Balancers** (Balanceadores de carga clássicos): se você especificar um Balanceador de Carga Clássico do ELB em **Endpoint**, o Elastic Load Balancing encaminhará consultas apenas para instâncias do Amazon EC2 íntegras que estejam registradas com o balanceador de carga. Se você definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) e nenhuma instância do EC2 estiver íntegra, ou se o próprio balanceador de carga não estiver íntegro, o Route 53 encaminhará consultas para outros recursos. + **Application and Network Load Balancers** (Aplicação e Balanceadores de Carga de Rede) se você especificar uma Aplicação ou Balanceador de Carga de Rede do ELB e definir **Evaluate Target health** (Avaliar integridade do destino) como **Yes** (Sim), o Route 53 encaminha consultas para o balanceador de carga com base na integridade dos grupos de destino que estão associados com o balanceador de carga: + Para que um Application ou Network Load Balancer seja considerado íntegro, um grupo de destino que contenha destinos deve conter pelo menos um destino íntegro. Se qualquer grupo de destinos contiver somente destinos não íntegros, o load balancer será considerado não íntegro e o Route 53 direcionará as consultas para outros recursos. + Um grupo de destinos que não tenha destinos registrados é considerado não íntegro. Ao criar um load balancer, defina as configurações para verificações de integridade do Elastic Load Balancing; elas não são verificações de integridade do Route 53, mas executam uma função semelhante. Não crie verificações de integridade do Route 53 para as instâncias do EC2 registradas com um load balancer do ELB. **Buckets do S3** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um bucket do S3. **Endpoints de interface da Amazon VPC** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um endpoint da interface da Amazon VPC. **Outros registros na mesma zona hospedada** Se o AWS recurso que você especificar no **Endpoint** for um registro ou um grupo de registros (por exemplo, um grupo de registros ponderados), mas não for outro registro de alias, recomendamos que você associe uma verificação de saúde a todos os registros no endpoint. Para obter mais informações, consulte [O que acontece quando você omite verificações de integridade?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID de registro Insira um valor que identifique os registros primários e secundários de forma exclusiva. # Valores específicos para registros de localização geográfica Quando você criar registros de localização geográfica, especifique os seguintes valores. **Topics** + [Política de roteamento](#rrsets-values-geo-routing-policy) + [Nome do registro](#rrsets-values-geo-name) + [Tipo de registro](#rrsets-values-geo-type) + [TTL (segundos)](#rrsets-values-geo-ttl) + [Valor/Encaminhar tráfego para](#rrsets-values-geo-value) + [Local](#rrsets-values-geo-location) + [Estados dos EUA](#rrsets-values-geo-sublocation) + [Verificação de saúde](#rrsets-values-geo-associate-with-health-check) + [ID de registro](#rrsets-values-geo-set-id) ## Política de roteamento Escolha **Geolocation** (Localização geográfica). ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Name (Nome)**. Insira o mesmo nome para todos os registros no grupo de registros de localização geográfica. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o mesmo valor para todos os registros no grupo de registros de localização geográfica. ## TTL (segundos) A quantidade de tempo, em segundos, que você deseja que os resolvedores recursivos de DNS armazenem informações em cache sobre esse registro. Se você especificar um valor mais longo (por exemplo, 172800 segundos ou dois dias), reduzirá o número de chamadas que os resolvedores recursivos de DNS devem fazer ao Route 53 para obter as informações mais recentes neste registro. Isso tem o efeito de reduzir a latência e reduzir sua fatura para o serviço do Route 53. Para obter mais informações, consulte [Como o Amazon Route 53 encaminha tráfego para o seu domínio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). No entanto, se você especificar um valor mais longo para TTL, levará mais tempo para que as alterações no registro (por exemplo, um novo endereço IP) entrem em vigor porque os resolvedores recursivos usam os valores em cache por períodos mais longos antes de solicitar as informações mais recentes ao Route 53. Se você estiver alterando as configurações de um domínio ou subdomínio que já está em uso, recomendamos que especifique inicialmente um valor mais curto, como 300 segundos, e aumente o valor depois de confirmar que as novas configurações estão corretas. Se você estiver associando esse registro a uma verificação de integridade, recomendamos especificar um TTL de 60 segundos ou menos para que os clientes respondam rapidamente a alterações no status de integridade. ## Valor/Encaminhar tráfego para Escolha o **endereço IP ou outro valor dependendo do tipo de registro**. Insira um valor que seja adequado para o valor de **Record type** (Tipo de registro). Para todos os tipos exceto **CNAME**, é possível incorporar mais de um valor. Insira cada valor em uma linha separada. Você pode direcionar tráfego ou especificar os seguintes valores: + **A — IPv4 endereço** + **AAAA — IPv6 endereço** + **CAA: Autorização da Autoridade de Certificação** + **CNAME: Nome canônico** + **MX: Intercâmbio de mensagens** + **NAPTR: Ponteiro de Autoridade de Nomes** + **PTR: Ponteiro** + **SPF: Framework de Política de Remetente** + **SRV: Localizador de serviço** + **TXT: Texto** Para obter mais informações sobre os valores acima, consulte [valores comuns para Value/Route tráfego para](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Local Ao configurar o Route 53 para responder às consultas de DNS com base no local de origem das consultas, selecione o continente ou país ao qual deseja que o Route 53 responda com as configurações nesse registro. Se quiser que o Route 53 responda às consultas de DNS para estados individuais nos Estados Unidos, selecione **United States** (Estados Unidos) na lista **Location** (Localização) e, depois, selecione o estado na lista **Sublocation** (Sublocalização). Para uma zona hospedada privada, selecione o continente, o país ou a subdivisão mais próxima da zona em Região da AWS que seu recurso está. Por exemplo, se seu recurso estiver em us-east-1, você poderá especificar América do Norte, Estados Unidos ou Virgínia. **Importante** Recomendamos criar um registro de localização geográfica que tenha um valor **Default (Padrão)** para a **Location (Localização)**. Esta ação abrange as localizações geográficas para as quais você não criou registros e endereços IP para os quais o Route 53 não consiga identificar uma localização. Não é possível criar registros que não são de localização geográfica que tenham os mesmos valores para **Record name** (Nome do registro) e **Record type** (Tipo de registro) que os registros de localização geográfica. Para obter mais informações, consulte [Roteamento de localização geográfica](routing-policy-geo.md). Aqui estão os países que o Amazon Route 53 associa a cada continente. Os códigos de país são da ISO 3166. Para mais informações sobre o artigo da Wikipedia, consulte [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2): **África (AF)** AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW **Antártica (AN)** AQ, GS, TF **Ásia (AS)** AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE **Europa (EU)** AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK Alguns provedores consideram que o TR está na Ásia e os endereços IP refletirão isso. **América do Norte (AN)** AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI **Oceania (OC)** AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS **América do Sul (SA)** AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE **nota** O Route 53 não suporta a criação de registros de geolocalização para os seguintes países: Ilha Bouvet (BV), Ilha Christmas (CX), Saara Ocidental (EH) e Ilha e Ilhas Heard (HM). McDonald Não há dados disponíveis sobre endereços IP para esses países. ## Estados dos EUA Ao configurar o Route 53 para responder às consultas de DNS baseadas no estado de origem das consultas provenientes dos Estados Unidos, selecione o estado na lista **Estados dos EUA**. Os territórios dos Estados Unidos (por exemplo, Porto Rico) são listados como países na lista **Location (Localização)**. **Importante** Alguns endereços IP são associados aos Estados Unidos, mas não com um estado individual. Se você criar registros para todos os estados nos Estados Unidos, recomendamos criar também um registro para os Estados Unidos para direcionar as consultas para esses endereços IP não associados. Se você não criar um registro para os Estados Unidos, o Route 53 responderá a consultas de DNS de endereços IP dos Estados Unidos não associados com as configurações de um registro de localização geográfica padrão (se você tiver criado um) ou com uma resposta de “sem resposta”. ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) em **Evaluate Target Health** (Avaliar a integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de geolocalização, alias de latência, alias baseado em IP ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain Name (Nome de domínio)**, especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain Name (Nome de domínio)** corresponde ao nome dos registros e associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. Para registros de localização geográfica, se um endpoint não for íntegro, o Route 53 procurará um registro para a região geográfica associada de maior tamanho. Por exemplo, digamos que você tem registros para um estado nos Estados Unidos, para os Estados Unidos, para a América do Norte e para todas as localizações (**Location (Localização)** é **Default (Padrão)**). Se o endpoint do registro de estado não estiver íntegro, o Route 53 verificará os registros para os Estados Unidos, para a América do Norte e todas as localidades, nessa ordem, até encontrar um registro que tenha um endpoint íntegro. Se todos os registros aplicáveis não estiverem íntegros, incluindo o registro para todas as localizações, o Route 53 responderá à consulta de DNS usando o valor do registro da menor região geográfica. ## ID de registro Insira um valor que identifique esse registro no grupo de registros de localização geográfica de forma exclusiva. # Valores específicos para registros de alias de localização geográfica Quando você criar registros de alias de localização geográfica, especifique os seguintes valores. Para obter mais informações, consulte [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Política de roteamento](#rrsets-values-geo-alias-routing-policy) + [Nome do registro](#rrsets-values-geo-alias-name) + [Tipo de registro](#rrsets-values-geo-alias-type) + [Valor/Encaminhar tráfego para](#rrsets-values-geo-alias-alias-target) + [Local](#rrsets-values-geo-alias-location) + [Estados dos EUA](#rrsets-values-geo-alias-sublocation) + [Verificação de saúde](#rrsets-values-geo-alias-associate-with-health-check) + [Avaliar status do alvo](#rrsets-values-geo-alias-evaluate-target-health) + [ID de registro](#rrsets-values-geo-alias-set-id) ## Política de roteamento Escolha **Geolocation** (Localização geográfica). ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Record name** (Nome de registro). Insira o mesmo nome para todos os registros no grupo de registros de localização geográfica. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o valor aplicável com base no AWS recurso para o qual você está roteando o tráfego. Selecione o mesmo valor para todos os registros no grupo de registros de localização geográfica: **API regional personalizada do API Gateway ou API otimizada para bordas** Selecione **A — IPv4 endereço**. **Endpoints de interface da Amazon VPC** Selecione **A — IPv4 endereço**. **CloudFront distribuição** Selecione **A — IPv4 endereço**. Se IPv6 estiver habilitado para a distribuição, crie dois registros, um com um valor de A **— IPv4 endereço** para **Tipo** e outro com um valor de **AAAA — IPv6 endereço**. **Serviço do App Runner** Selecione **A — IPv4 endereço** **Ambiente do Elastic Beanstalk com subdomínios regionalizados** Selecione **A — IPv4 endereço** **Load balancer do ELB** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Bucket do Amazon S3.** Selecione **A — IPv4 endereço** **OpenSearch Serviço** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Outro registro nessa zona hospedada** Selecione o tipo de registro para o qual está criando o alias. Todos os tipos são compatíveis, exceto **NS** e **SOA**. Se você estiver criando um registro de alias com o mesmo nome da zona hospedada (conhecida como *apex de zona*), não será possível rotear o tráfego para um registro para o qual o valor de **Type (Tipo)** seja **CNAME**. Isso ocorre porque o registro de alias deve ter o mesmo tipo que o registro para o qual você está roteando o tráfego e não há suporte para criar um registro CNAME para o apex de zona mesmo para um registro de alias. ## Valor/Encaminhar tráfego para O valor que você escolhe na lista ou digita no campo depende do AWS recurso para o qual você está roteando o tráfego. Para obter informações sobre quais AWS recursos você pode direcionar, consulte[Valor/rotear tráfego para](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target). Para obter mais informações sobre como configurar o Route 53 para rotear o tráfego para AWS recursos específicos, consulte[Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). ## Local Ao configurar o Route 53 para responder às consultas de DNS com base no local de origem das consultas, selecione o continente ou país ao qual deseja que o Route 53 responda com as configurações nesse registro. Se quiser que o Route 53 responda às consultas de DNS para estados individuais nos Estados Unidos, selecione **United States** (Estados Unidos) na lista **Location** (Localização) e, depois, selecione o estado na lista **U. S. states** (Estados dos EUA). Para uma zona hospedada privada, selecione o continente, o país ou a subdivisão mais próxima da zona em Região da AWS que seu recurso está. Por exemplo, se seu recurso estiver em us-east-1, você poderá especificar América do Norte, Estados Unidos ou Virgínia. **Importante** Recomendamos criar um registro de localização geográfica que tenha um valor **Default (Padrão)** para a **Location (Localização)**. Esta ação abrange as localizações geográficas para as quais você não criou registros e endereços IP para os quais o Route 53 não consiga identificar uma localização. Não é possível criar registros que não são de localização geográfica que tenham os mesmos valores para **Record name** (Nome do registro) e **Record type** (Tipo de registro) que os registros de localização geográfica. Para obter mais informações, consulte [Roteamento de localização geográfica](routing-policy-geo.md). Aqui estão os países que o Amazon Route 53 associa a cada continente. Os códigos de país são da ISO 3166. Para mais informações sobre o artigo da Wikipedia, consulte [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2): **África (AF)** AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW **Antártica (AN)** AQ, GS, TF **Ásia (AS)** AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE **Europa (EU)** AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK Alguns provedores consideram que o TR está na Ásia e os endereços IP refletirão isso. **América do Norte (AN)** AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI **Oceania (OC)** AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS **América do Sul (SA)** AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE **nota** O Route 53 não suporta a criação de registros de geolocalização para os seguintes países: Ilha Bouvet (BV), Ilha Christmas (CX), Saara Ocidental (EH) e Ilha e Ilhas Heard (HM). McDonald Não há dados disponíveis sobre endereços IP para esses países. ## Estados dos EUA Ao configurar o Route 53 para responder às consultas de DNS baseadas no estado de origem das consultas provenientes dos Estados Unidos, selecione o estado na lista **Estados dos EUA**. Os territórios dos Estados Unidos (por exemplo, Porto Rico) são listados como países na lista **Location (Localização)**. **Importante** Alguns endereços IP são associados aos Estados Unidos, mas não com um estado individual. Se você criar registros para todos os estados nos Estados Unidos, recomendamos criar também um registro para os Estados Unidos para direcionar as consultas para esses endereços IP não associados. Se você não criar um registro para os Estados Unidos, o Route 53 responderá a consultas de DNS de endereços IP dos Estados Unidos não associados com as configurações de um registro de localização geográfica padrão (se você tiver criado um) ou com uma resposta de “sem resposta”. ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) em **Evaluate target health** (Avaliar a integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de geolocalização, alias de latência, alias baseado em IP ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain name** (Nome de domínio), especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain name** corresponde ao nome dos registros e, em seguida, associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. Para registros de localização geográfica, se um endpoint não for íntegro, o Route 53 procurará um registro para a região geográfica associada de maior tamanho. Por exemplo, digamos que você tem registros para um estado nos Estados Unidos, para os Estados Unidos, para a América do Norte e para todas as localizações (**Location (Localização)** é **Default (Padrão)**). Se o endpoint do registro de estado não estiver íntegro, o Route 53 verificará os registros para os Estados Unidos, para a América do Norte e todas as localidades, nessa ordem, até encontrar um registro que tenha um endpoint íntegro. Se todos os registros aplicáveis não estiverem íntegros, incluindo o registro para todas as localizações, o Route 53 responderá à consulta de DNS usando o valor do registro da menor região geográfica. ## Avaliar status do alvo Selecione **Yes** (Sim), se quiser que o Route 53 determine se deve responder a consultas de DNS usando esse registro, verificando a integridade do recurso especificado pelo **Endpoint**. Observe o seguinte: **API Gateway: personalizado, regional APIs e otimizado para bordas APIs** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for uma API Regional personalizada do API Gateway ou uma API otimizada para borda. **CloudFront distribuições** Você não pode definir **Avaliar a integridade do alvo** como **Sim** quando o endpoint é uma CloudFront distribuição. **Ambientes do Elastic Beanstalk com subdomínios regionalizados** Se você especificar um ambiente do Elastic Beanstalk no **Endpoint** e o ambiente contiver um load balancer do ELB, o Elastic Load Balancing encaminhará consultas apenas para as instâncias íntegras ​​do Amazon EC2 que estão registradas com o balanceador de carga. (Um ambiente contém automaticamente um load balancer do ELB se incluir mais de uma instância do Amazon EC2.) Se você definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) e nenhuma instância do Amazon EC2 estiver íntegro ou o próprio balanceador de carga não estiver íntegro, o Route 53 encaminhará as consultas para outros recursos disponíveis que sejam íntegros, se houver. Se o ambiente contiver uma única instância do Amazon EC2, não há requisitos especiais. **Load balancers do ELB** O comportamento de verificação da integridade depende do tipo do load balancer: + **Classic Load Balancers** (Balanceadores de carga clássicos): se você especificar um Balanceador de carga clássico do ELB no **Endpoint**, o Elastic Load Balancing encaminhará consultas apenas para instâncias do Amazon EC2 íntegras que estejam registradas no balanceador de carga. Se você definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) e nenhuma instância do EC2 estiver íntegra, ou se o próprio balanceador de carga não estiver íntegro, o Route 53 encaminhará consultas para outros recursos. + **Application and Network Load Balancers** (Aplicação e Balanceadores de carga da rede): se você especificar uma Aplicação de ELB ou Balanceador de carga da rede e definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim), o Route 53 encaminha consultas para o balanceador de carga com base na integridade dos grupos de destino que estão associados com o balanceador de carga: + Para que um Application ou Network Load Balancer seja considerado íntegro, cada grupo de destino que contenha destinos deve conter pelo menos um destino íntegro. Se qualquer grupo de destinos contiver somente destinos não íntegros, o load balancer será considerado não íntegro e o Route 53 direcionará as consultas para outros recursos. + Um grupo de destinos que não tenha destinos registrados é considerado não íntegro. Ao criar um load balancer, defina as configurações para verificações de integridade do Elastic Load Balancing; elas não são verificações de integridade do Route 53, mas executam uma função semelhante. Não crie verificações de integridade do Route 53 para as instâncias do EC2 registradas com um load balancer do ELB. **Buckets do S3** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um bucket do S3. **Endpoints de interface da Amazon VPC** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um endpoint da interface da Amazon VPC. **Outros registros na mesma zona hospedada** Se o AWS recurso que você especificar no **Endpoint** for um registro ou um grupo de registros (por exemplo, um grupo de registros ponderados), mas não for outro registro de alias, recomendamos que você associe uma verificação de saúde a todos os registros no endpoint. Para obter mais informações, consulte [O que acontece quando você omite verificações de integridade?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID de registro Insira um valor que identifique esse registro no grupo de registros de localização geográfica de forma exclusiva. # Valores específicos para registros de geoproximidade Quando você cria registros de geoproximidade, especifica os valores a seguir. **Topics** + [Política de roteamento](#rrsets-values-geoprox-routing-policy) + [Nome do registro](#rrsets-values-geoprox-name) + [Tipo de registro](#rrsets-values-geoprox-type) + [TTL (segundos)](#rrsets-values-geoprox-ttl) + [Valor/Encaminhar tráfego para](#rrsets-values-geoprox-value) + [Local do endpoint](#rrsets-values-geoprox-endpoint-location) + [Desvio](#rrsets-values-geoprox-bias) + [Verificação de saúde](#rrsets-values-geoprox-associate-with-health-check) + [ID de registro](#rrsets-values-geoprox-set-id) ## Política de roteamento Escolha **Geoproximidade**. ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Name (Nome)**. Insira o mesmo nome para todos os registros do grupo de registros de geoproximidade. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o mesmo valor para todos os registros do grupo de registros de geoproximidade. ## TTL (segundos) A quantidade de tempo, em segundos, que você deseja que os resolvedores recursivos de DNS armazenem informações em cache sobre esse registro. Se você especificar um valor mais longo (por exemplo, 172800 segundos ou dois dias), reduzirá o número de chamadas que os resolvedores recursivos de DNS devem fazer ao Route 53 para obter as informações mais recentes neste registro. Isso tem o efeito de reduzir a latência e reduzir sua fatura para o serviço do Route 53. Para obter mais informações, consulte [Como o Amazon Route 53 encaminha tráfego para o seu domínio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). No entanto, se você especificar um valor mais longo para TTL, levará mais tempo para que as alterações no registro (por exemplo, um novo endereço IP) entrem em vigor porque os resolvedores recursivos usam os valores em cache por períodos mais longos antes de solicitar as informações mais recentes ao Route 53. Se você estiver alterando as configurações de um domínio ou subdomínio que já está em uso, recomendamos que especifique inicialmente um valor mais curto, como 300 segundos, e aumente o valor depois de confirmar que as novas configurações estão corretas. Se você estiver associando esse registro a uma verificação de integridade, recomendamos especificar um TTL de 60 segundos ou menos para que os clientes respondam rapidamente a alterações no status de integridade. ## Valor/Encaminhar tráfego para Escolha o **endereço IP ou outro valor dependendo do tipo de registro**. Insira um valor que seja adequado para o valor de **Record type** (Tipo de registro). Para todos os tipos exceto **CNAME**, é possível incorporar mais de um valor. Insira cada valor em uma linha separada. Você pode direcionar tráfego ou especificar os seguintes valores: + **A — IPv4 endereço** + **AAAA — IPv6 endereço** + **CAA: Autorização da Autoridade de Certificação** + **CNAME: Nome canônico** + **MX: Intercâmbio de mensagens** + **NAPTR: Ponteiro de Autoridade de Nomes** + **PTR: Ponteiro** + **SPF: Framework de Política de Remetente** + **SRV: Localizador de serviço** + **TXT: Texto** Para obter mais informações sobre os valores acima, consulte [valores comuns para Value/Route tráfego para](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Local do endpoint Você pode especificar o local do endpoint do recurso usando um dos seguintes métodos: **Coordenadas personalizados** Especifique a longitude e a latitude de uma área geográfica. **Região da AWS** Escolha uma região disponível na lista **Localização**. Para obter mais informações sobre regiões, consulte [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). **AWS Grupo de zonas locais** Escolha um grupo de zonas locais disponível na lista **Localização**. Para ver a lista de zonas locais disponíveis, consulte [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) no *AWS Local Zones User Guide*. Um grupo de zonas local geralmente é a zona local sem o caractere final. Por exemplo, se a zona local for `us-east-1-bue-1a`, o grupo de zonas locais será `us-east-1-bue-1`. Você também pode identificar o Grupo de Zonas Locais para uma zona local específica usando o comando [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI: ``` aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName" ``` Esse comando retorna: `"GroupName": "us-west-2-den-1"`, especificando que a zona local `us-west-2-den-1a` pertence ao grupo de zonas locais `us-west-2-den-1`. Você não pode criar registros que não sejam de geoproximidade com os mesmos valores de **Nome do registro** e **Tipo de registro** dos registros de geoproximidade. Também não pode criar dois conjuntos de registros de recurso de geoproximidade que especifiquem o mesmo local para o mesmo nome de registro e o mesmo tipo de registro. ## Desvio Um desvio aumenta ou diminui o tamanho da região geográfica da qual o Route 53 roteia tráfego para um recurso. Um desvio positivo expande a área e um desvio negativo a reduz. Para obter mais informações, consulte [Como o Amazon Route 53 usa o desvio para encaminhar o tráfego](routing-policy-geoproximity.md#routing-policy-geoproximity-bias). ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Você seleciona **Sim** em **Avaliar a integridade do destino** para um registro de alias ou para os registros de um grupo de registros de alias de failover, alias de geolocalização, alias de geoproximidade, alias de latência, alias baseado em IP ou alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain Name (Nome de domínio)**, especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain Name (Nome de domínio)** corresponde ao nome dos registros e associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. Para registros de geoproximidade, se um endpoint não estiver íntegro, o Route 53 procurará o endpoint mais próximo que ainda estiver íntegro. ## ID de registro Insira um valor que identifique esse registro no grupo de registros de geoproximidade de modo exclusivo. # Valores específicos para registros de alias de geoproximidade Quando cria registros de alias de geoproximidade, você especifica os seguintes valores. Para obter mais informações, consulte [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Política de roteamento](#rrsets-values-geoprox-alias-routing-policy) + [Nome do registro](#rrsets-values-geoprox-alias-name) + [Tipo de registro](#rrsets-values-geoprox-alias-type) + [Valor/Encaminhar tráfego para](#rrsets-values-geoprox-alias-alias-target) + [Local do endpoint](#rrsets-values-geoprox-alias-endpoint-location) + [Desvio](#rrsets-values-geoprox-alias-bias) + [Verificação de saúde](#rrsets-values-geoprox-alias-associate-with-health-check) + [Avaliar status do alvo](#rrsets-values-geoprox-alias-evaluate-target-health) + [ID de registro](#rrsets-values-geoprox-alias-set-id) ## Política de roteamento Escolha **Geoproximidade**. ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Record name** (Nome de registro). Insira o mesmo nome para todos os registros do grupo de registros de geoproximidade. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o valor aplicável com base no AWS recurso para o qual você está roteando o tráfego. Selecione o mesmo valor para todos os registros do grupo de registros de geoproximidade: **API regional personalizada do API Gateway ou API otimizada para bordas** Selecione **A — IPv4 endereço**. **Endpoints de interface da Amazon VPC** Selecione **A — IPv4 endereço**. **CloudFront distribuição** Selecione **A — IPv4 endereço**. Se IPv6 estiver habilitado para a distribuição, crie dois registros, um com um valor de A **— IPv4 endereço** para **Tipo** e outro com um valor de **AAAA — IPv6 endereço**. **Serviço do App Runner** Selecione **A — IPv4 endereço** **Ambiente do Elastic Beanstalk com subdomínios regionalizados** Selecione **A — IPv4 endereço** **Load balancer do ELB** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Bucket do Amazon S3.** Selecione **A — IPv4 endereço** **OpenSearch Serviço** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Outro registro nessa zona hospedada** Selecione o tipo de registro para o qual está criando o alias. Todos os tipos são compatíveis, exceto **NS** e **SOA**. Se você estiver criando um registro de alias com o mesmo nome da zona hospedada (conhecida como *apex de zona*), não será possível rotear o tráfego para um registro para o qual o valor de **Type (Tipo)** seja **CNAME**. Isso ocorre porque o registro de alias deve ter o mesmo tipo que o registro para o qual você está roteando o tráfego e não há suporte para criar um registro CNAME para o apex de zona mesmo para um registro de alias. ## Valor/Encaminhar tráfego para O valor que você escolhe na lista ou digita no campo depende do AWS recurso para o qual você está roteando o tráfego. Para obter informações sobre quais AWS recursos você pode direcionar, consulte[Valor/rotear tráfego para](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target). Para obter mais informações sobre como configurar o Route 53 para rotear o tráfego para AWS recursos específicos, consulte[Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). ## Local do endpoint Você pode especificar o local do endpoint do recurso usando um dos seguintes métodos: **Coordenadas personalizados** Especifique a longitude e a latitude de uma área geográfica. **Região da AWS** Escolha uma região disponível na lista **Localização**. Para obter mais informações sobre regiões, consulte [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). **AWS Grupo de zonas locais** Escolha uma região da zona local disponível na lista **Localização**. Para ver a lista de zonas locais disponíveis, consulte [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) no *AWS Local Zones User Guide*. Um grupo de zonas local geralmente é a zona local sem o caractere final. Por exemplo, se a zona local for `us-east-1-bue-1a`, o grupo de zonas locais será `us-east-1-bue-1`. Você também pode identificar o Grupo de Zonas Locais para uma zona local específica usando o comando [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI: ``` aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName" ``` Esse comando retorna: `"GroupName": "us-west-2-den-1"`, especificando que a zona local `us-west-2-den-1a` pertence ao grupo de zonas locais `us-west-2-den-1`. Você não pode criar registros que não sejam de geoproximidade com os mesmos valores de **Nome do registro** e **Tipo de registro** dos registros de geoproximidade. Também não pode criar dois conjuntos de registros de recurso de geoproximidade que especifiquem o mesmo local para o mesmo nome de registro e o mesmo tipo de registro. Para obter mais informações, consulte available-local-zones .html ## Desvio Um desvio aumenta ou diminui o tamanho da região geográfica da qual o Route 53 roteia tráfego para um recurso. Um desvio positivo expande a área e um desvio negativo a reduz. Para obter mais informações, consulte [Como o Amazon Route 53 usa o desvio para encaminhar o tráfego](routing-policy-geoproximity.md#routing-policy-geoproximity-bias). ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Você seleciona **Sim** em **Avaliar a integridade do destino** para um registro de alias ou para os registros de um grupo de registros de alias de failover, alias de geolocalização, alias de geoproximidade, alias de latência, alias baseado em IP ou alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain name** (Nome de domínio), especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain name** corresponde ao nome dos registros e, em seguida, associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. Para registros de geoproximidade, se um endpoint não estiver íntegro, o Route 53 procurará o endpoint mais próximo que ainda estiver íntegro. ## Avaliar status do alvo Selecione **Yes** (Sim), se quiser que o Route 53 determine se deve responder a consultas de DNS usando esse registro, verificando a integridade do recurso especificado pelo **Endpoint**. Observe o seguinte: **API Gateway: personalizado, regional APIs e otimizado para bordas APIs** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for uma API Regional personalizada do API Gateway ou uma API otimizada para borda. **CloudFront distribuições** Você não pode definir **Avaliar a integridade do alvo** como **Sim** quando o endpoint é uma CloudFront distribuição. **Ambientes do Elastic Beanstalk com subdomínios regionalizados** Se você especificar um ambiente do Elastic Beanstalk no **Endpoint** e o ambiente contiver um load balancer do ELB, o Elastic Load Balancing encaminhará consultas apenas para as instâncias íntegras ​​do Amazon EC2 que estão registradas com o balanceador de carga. (Um ambiente contém automaticamente um load balancer do ELB se incluir mais de uma instância do Amazon EC2.) Se você definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) e nenhuma instância do Amazon EC2 estiver íntegro ou o próprio balanceador de carga não estiver íntegro, o Route 53 encaminhará as consultas para outros recursos disponíveis que sejam íntegros, se houver. Se o ambiente contiver uma única instância do Amazon EC2, não há requisitos especiais. **Load balancers do ELB** O comportamento de verificação da integridade depende do tipo do load balancer: + **Classic Load Balancers** (Balanceadores de carga clássicos): se você especificar um Balanceador de carga clássico do ELB no **Endpoint**, o Elastic Load Balancing encaminhará consultas apenas para instâncias do Amazon EC2 íntegras que estejam registradas no balanceador de carga. Se você definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) e nenhuma instância do EC2 estiver íntegra, ou se o próprio balanceador de carga não estiver íntegro, o Route 53 encaminhará consultas para outros recursos. + **Application and Network Load Balancers** (Aplicação e Balanceadores de carga da rede): se você especificar uma Aplicação de ELB ou Balanceador de carga da rede e definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim), o Route 53 encaminha consultas para o balanceador de carga com base na integridade dos grupos de destino que estão associados com o balanceador de carga: + Para que um Application ou Network Load Balancer seja considerado íntegro, cada grupo de destino que contenha destinos deve conter pelo menos um destino íntegro. Se qualquer grupo de destinos contiver somente destinos não íntegros, o load balancer será considerado não íntegro e o Route 53 direcionará as consultas para outros recursos. + Um grupo de destinos que não tenha destinos registrados é considerado não íntegro. Ao criar um load balancer, defina as configurações para verificações de integridade do Elastic Load Balancing; elas não são verificações de integridade do Route 53, mas executam uma função semelhante. Não crie verificações de integridade do Route 53 para as instâncias do EC2 registradas com um load balancer do ELB. **Buckets do S3** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um bucket do S3. **Endpoints de interface da Amazon VPC** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um endpoint da interface da Amazon VPC. **Outros registros na mesma zona hospedada** Se o AWS recurso que você especificar no **Endpoint** for um registro ou um grupo de registros (por exemplo, um grupo de registros ponderados), mas não for outro registro de alias, recomendamos que você associe uma verificação de saúde a todos os registros no endpoint. Para obter mais informações, consulte [O que acontece quando você omite verificações de integridade?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID de registro Insira um valor que identifique esse registro no grupo de registros de geoproximidade de modo exclusivo. # Valores específicos para registros de latência Quando você criar registros de latência, especifique os seguintes valores. **Topics** + [Política de roteamento](#rrsets-values-latency-routing-policy) + [Nome do registro](#rrsets-values-latency-name) + [Tipo de registro](#rrsets-values-latency-type) + [TTL (segundos)](#rrsets-values-latency-ttl) + [Valor/Encaminhar tráfego para](#rrsets-values-latency-value) + [Região](#rrsets-values-latency-region) + [Verificação de saúde](#rrsets-values-latency-associate-with-health-check) + [ID de registro](#rrsets-values-latency-set-id) ## Política de roteamento Escolha **Latency** (Latência). ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Record name** (Nome de registro). Insira o mesmo nome para todos os registros no grupo de registros de latência. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o valor para **Type** (Tipo) com base em como deseja que o Route 53 responda a consultas de DNS. Selecione o mesmo valor para todos os registros no grupo de registros de latência. ## TTL (segundos) A quantidade de tempo, em segundos, que você deseja que os resolvedores recursivos de DNS armazenem informações em cache sobre esse registro. Se você especificar um valor mais longo (por exemplo, 172800 segundos ou dois dias), reduzirá o número de chamadas que os resolvedores recursivos de DNS devem fazer ao Route 53 para obter as informações mais recentes neste registro. Isso tem o efeito de reduzir a latência e reduzir sua fatura para o serviço do Route 53. Para obter mais informações, consulte [Como o Amazon Route 53 encaminha tráfego para o seu domínio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). No entanto, se você especificar um valor mais longo para TTL, levará mais tempo para que as alterações no registro (por exemplo, um novo endereço IP) entrem em vigor porque os resolvedores recursivos usam os valores em cache por períodos mais longos antes de solicitar as informações mais recentes ao Route 53. Se você estiver alterando as configurações de um domínio ou subdomínio que já está em uso, recomendamos que especifique inicialmente um valor mais curto, como 300 segundos, e aumente o valor depois de confirmar que as novas configurações estão corretas. Se você estiver associando esse registro a uma verificação de integridade, recomendamos especificar um TTL de 60 segundos ou menos para que os clientes respondam rapidamente a alterações no status de integridade. ## Valor/Encaminhar tráfego para Escolha o **endereço IP ou outro valor dependendo do tipo de registro**. Insira um valor que seja adequado para o valor de **Record type** (Tipo de registro). Para todos os tipos exceto **CNAME**, é possível incorporar mais de um valor. Insira cada valor em uma linha separada. Você pode direcionar tráfego ou especificar os seguintes valores: + **A — IPv4 endereço** + **AAAA — IPv6 endereço** + **CAA: Autorização da Autoridade de Certificação** + **CNAME: Nome canônico** + **MX: Intercâmbio de mensagens** + **NAPTR: Ponteiro de Autoridade de Nomes** + **PTR: Ponteiro** + **SPF: Framework de Política de Remetente** + **SRV: Localizador de serviço** + **TXT: Texto** Para obter mais informações sobre os valores acima, consulte [valores comuns para Value/Route tráfego para](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Região A região do Amazon EC2 onde reside o recurso especificado nesse registro. O Route 53 recomenda uma região do Amazon EC2 com base em outros valores especificados. Isso também se aplica a zonas hospedadas privadas. Recomendamos não alterar esse valor. Observe o seguinte: + Só será possível criar um registro de latência para cada região do Amazon EC2. + Não é necessário para criar registros de latência para todas as regiões do Amazon EC2. O Route 53 seleciona a região com a melhor latência entre as regiões para as quais você cria registros de latência. + Não é possível criar registros sem latência que tenham os mesmos valores para **Record name** (Nome do registro) e **Record type** (Tipo de registro) que os registros de latência. + Se você criar um registro marcado com a região **cn-north-1**, o Route 53 sempre responderá às consultas provenientes da China usando esse registro, independentemente da latência. Para obter mais informações sobre como usar de latência, consulte [Roteamento baseado em latência](routing-policy-latency.md). ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) em **Evaluate target health** (Avaliar a integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de geolocalização, alias de latência, alias baseado em IP ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain name** (Nome de domínio), especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain name** corresponde ao nome dos registros e, em seguida, associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. ## ID de registro Insira um valor que identifique esse registro no grupo de registros de latência de forma exclusiva. # Valores específicos para registros de alias de latência Quando você criar registros de alias de latência, especifique os seguintes valores. Para obter mais informações, consulte [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Política de roteamento](#rrsets-values-latency-alias-routing-policy) + [Nome do registro](#rrsets-values-latency-alias-name) + [Tipo de registro](#rrsets-values-latency-alias-type) + [Valor/Encaminhar tráfego para](#rrsets-values-latency-alias-alias-target) + [Região](#rrsets-values-latency-alias-region) + [Verificação de saúde](#rrsets-values-latency-alias-associate-with-health-check) + [Avaliar status do alvo](#rrsets-values-latency-alias-evaluate-target-health) + [ID de registro](#rrsets-values-latency-alias-set-id) ## Política de roteamento Escolha **Latency** (Latência). ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Record name** (Nome de registro). Insira o mesmo nome para todos os registros no grupo de registros de latência. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o valor aplicável com base no AWS recurso para o qual você está roteando o tráfego: **API regional personalizada do API Gateway ou API otimizada para bordas** Selecione **A — IPv4 endereço**. **Endpoints de interface da Amazon VPC** Selecione **A — IPv4 endereço**. **CloudFront distribuição** Selecione **A — IPv4 endereço**. Se IPv6 estiver habilitado para a distribuição, crie dois registros, um com um valor de A **— IPv4 endereço** para **Tipo** e outro com um valor de **AAAA — IPv6 endereço**. **Serviço do App Runner** Selecione **A — IPv4 endereço** **Ambiente do Elastic Beanstalk com subdomínios regionalizados** Selecione **A — IPv4 endereço** **Load balancer do ELB** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Bucket do Amazon S3.** Selecione **A — IPv4 endereço** **OpenSearch Serviço** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Outro registro nessa zona hospedada** Selecione o tipo de registro para o qual está criando o alias. Todos os tipos são compatíveis, exceto **NS** e **SOA**. Se você estiver criando um registro de alias com o mesmo nome da zona hospedada (conhecida como *apex de zona*), não será possível rotear o tráfego para um registro para o qual o valor de **Type (Tipo)** seja **CNAME**. Isso ocorre porque o registro de alias deve ter o mesmo tipo que o registro para o qual você está roteando o tráfego e não há suporte para criar um registro CNAME para o apex de zona mesmo para um registro de alias. Selecione o mesmo valor para todos os registros no grupo de registros de latência. ## Valor/Encaminhar tráfego para O valor que você escolhe na lista ou digita no campo depende do AWS recurso para o qual você está roteando o tráfego. Para obter informações sobre quais AWS recursos você pode segmentar, consulte [valores comuns para registros de alias para value/route tráfego](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target). Para obter mais informações sobre como configurar o Route 53 para rotear o tráfego para AWS recursos específicos, consulte[Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). ## Região A região do Amazon EC2 onde reside o recurso especificado nesse registro. O Route 53 recomenda uma região do Amazon EC2 com base em outros valores especificados. Isso também se aplica a zonas hospedadas privadas. Recomendamos não alterar esse valor. Observe o seguinte: + Só será possível criar um registro de latência para cada região do Amazon EC2. + Não é necessário para criar registros de latência para todas as regiões do Amazon EC2. O Route 53 seleciona a região com a melhor latência entre as regiões para as quais você cria registros de latência. + Não é possível criar registros sem latência que tenham os mesmos valores para **Record name** (Nome do registro) e **Record type** (Tipo de registro) que os registros de latência. + Se você criar um registro marcado com a região **cn-north-1**, o Route 53 sempre responderá às consultas provenientes da China usando esse registro, independentemente da latência. Para obter mais informações sobre como usar de latência, consulte [Roteamento baseado em latência](routing-policy-latency.md). ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) em **Evaluate target health** (Avaliar a integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de geolocalização, alias de latência, alias baseado em IP ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain name** (Nome de domínio), especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain Name (Nome de domínio)** corresponde ao nome dos registros e associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. ## Avaliar status do alvo Selecione **Yes** (Sim), se quiser que o Route 53 determine se deve responder a consultas de DNS usando esse registro, verificando a integridade do recurso especificado pelo **Endpoint**. Observe o seguinte: **API Gateway: personalizado, regional APIs e otimizado para bordas APIs** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for uma API regional personalizada do API Gateway ou uma API otimizada para bordas. **CloudFront distribuições** Você não pode definir **Evaluate Target Health** como **Sim** quando o endpoint é uma CloudFront distribuição. **Ambientes do Elastic Beanstalk com subdomínios regionalizados** Se você especificar um ambiente do Elastic Beanstalk no **Endpoint** e o ambiente contiver um load balancer do ELB, o Elastic Load Balancing encaminhará consultas apenas para as instâncias íntegras ​​do Amazon EC2 que estão registradas com o balanceador de carga. (Um ambiente contém automaticamente um load balancer do ELB se incluir mais de uma instância do Amazon EC2.) Se você definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) e nenhuma instância do Amazon EC2 estiver íntegro ou o próprio balanceador de carga não estiver íntegro, o Route 53 encaminhará as consultas para outros recursos disponíveis que sejam íntegros, se houver. Se o ambiente contiver uma única instância do Amazon EC2, não há requisitos especiais. **Load balancers do ELB** O comportamento de verificação da integridade depende do tipo do load balancer: + **Classic Load Balancers** (Balanceadores de carga clássicos): se você especificar um Balanceador de carga clássico do ELB no **Endpoint**, o Elastic Load Balancing encaminhará consultas apenas para instâncias do Amazon EC2 íntegras que estejam registradas no balanceador de carga. Se você definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) e nenhuma instância do EC2 estiver íntegra, ou se o próprio balanceador de carga não estiver íntegro, o Route 53 encaminhará consultas para outros recursos. + **Application and Network Load Balancers** (Aplicação e Balanceadores de carga da rede): se você especificar uma Aplicação de ELB ou Balanceador de carga da rede e definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim), o Route 53 encaminha consultas para o balanceador de carga com base na integridade dos grupos de destino que estão associados com o balanceador de carga: + Para que um Application ou Network Load Balancer seja considerado íntegro, cada grupo de destino que contenha destinos deve conter pelo menos um destino íntegro. Se qualquer grupo de destinos contiver somente destinos não íntegros, o load balancer será considerado não íntegro e o Route 53 direcionará as consultas para outros recursos. + Um grupo de destinos que não tenha destinos registrados é considerado não íntegro. Ao criar um load balancer, defina as configurações para verificações de integridade do Elastic Load Balancing; elas não são verificações de integridade do Route 53, mas executam uma função semelhante. Não crie verificações de integridade do Route 53 para as instâncias do EC2 registradas com um load balancer do ELB. **Buckets do S3** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um bucket do S3. **Endpoints de interface da Amazon VPC** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um endpoint da interface da Amazon VPC. **Outros registros na mesma zona hospedada** Se o AWS recurso que você especificar no **Endpoint** for um registro ou um grupo de registros (por exemplo, um grupo de registros ponderados), mas não for outro registro de alias, recomendamos que você associe uma verificação de saúde a todos os registros no endpoint. Para obter mais informações, consulte [O que acontece quando você omite verificações de integridade?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID de registro Insira um valor que identifique esse registro no grupo de registros de latência de forma exclusiva. # Valores específicos para registros baseados em IP Quando você criar registros baseados em IP, especifique os valores a seguir. **nota** Embora a criação de registros baseados em IP em uma zona hospedada privada seja permitida, não é compatível. **Topics** + [Política de roteamento](#rrsets-values-ipbased-routing-policy) + [Nome de registro](#rrsets-values-ibased-name) + [Tipo de registro](#rrsets-values-ibased-type) + [TTL (segundos)](#rrsets-values-ibased-ttl) + [Valor/Encaminhar tráfego para](#rrsets-values-ibased-value) + [Local](#rrsets-values-ibased-location) + [Verificação de integridade](#rrsets-values-ibased-associate-with-health-check) + [ID de registro](#rrsets-values-ipbased-set-id) ## Política de roteamento Escolha **IP-based** (Baseado em IP). ## Nome de registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Record name** (Nome de registro). Insira o mesmo nome para todos os registros no grupo de registros baseados em IP. **Registros CNAME** Se você estiver criando um registro com um valor **CNAME** para o **Record type** (Tipo de registro), o registro não poderá ter o mesmo o nome da zona hospedada. **Caracteres especiais** Para obter informações sobre como especificar caracteres que não sejam a-z, 0-9 e - (hífen) e como especificar nomes de domínio internacionalizados, consulte [Formato de nome de domínio DNS](DomainNameFormat.md). **Caracteres curinga** Você pode usar um asterisco (\$1) no nome. O DNS trata o caractere \$1 como um caractere curinga ou como o caractere \$1 (ASCII 42), dependendo de onde ele aparece no nome. Para obter mais informações, consulte [Usar um asterisco (\$1) nos nomes de zonas hospedadas e registros](DomainNameFormat.md#domain-name-format-asterisk). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o valor para **Type** (Tipo) com base em como deseja que o Route 53 responda a consultas de DNS. Selecione o mesmo valor para todos os registros do grupo de registros baseados em IP. ## TTL (segundos) A quantidade de tempo, em segundos, que você deseja que os resolvedores recursivos de DNS armazenem informações em cache sobre esse registro. Se você especificar um valor mais longo (por exemplo, 172800 segundos ou dois dias), reduzirá o número de chamadas que os resolvedores recursivos de DNS devem fazer ao Route 53 para obter as informações mais recentes neste registro. Isso tem o efeito de reduzir a latência e reduzir sua fatura para o serviço do Route 53. Para obter mais informações, consulte [Como o Amazon Route 53 encaminha tráfego para o seu domínio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). No entanto, se você especificar um valor mais longo para TTL, levará mais tempo para que as alterações no registro (por exemplo, um novo endereço IP) entrem em vigor porque os resolvedores recursivos usam os valores em cache por períodos mais longos antes de solicitar as informações mais recentes ao Route 53. Se você estiver alterando as configurações de um domínio ou subdomínio que já está em uso, recomendamos que especifique inicialmente um valor mais curto, como 300 segundos, e aumente o valor depois de confirmar que as novas configurações estão corretas. Se você estiver associando esse registro a uma verificação de integridade, recomendamos especificar um TTL de 60 segundos ou menos para que os clientes respondam rapidamente a alterações no status de integridade. ## Valor/Encaminhar tráfego para Escolha o **endereço IP ou outro valor dependendo do tipo de registro**. Insira um valor que seja adequado para o valor de **Record type** (Tipo de registro). Para todos os tipos exceto **CNAME**, é possível incorporar mais de um valor. Insira cada valor em uma linha separada. Você pode direcionar tráfego ou especificar os seguintes valores: + **A: endereço IPv** + **AAAA: endereço IPv** + **CAA: Autorização da Autoridade de Certificação** + **CNAME: Nome canônico** + **MX: Intercâmbio de mensagens** + **NAPTR: Ponteiro de Autoridade de Nomes** + **PTR: Ponteiro** + **SPF: Framework de Política de Remetente** + **SRV: Localizador de serviço** + **TXT: Texto** Para obter mais informações sobre os valores acima, consulte [Valor/Encaminhar tráfego para](resource-record-sets-values-shared.md#rrsets-values-common-value) [valores comuns para os quais avaliar/rotear tráfego](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Local O nome do local CIDR onde o recurso especificado neste registro é especificado pelos valores de bloco CIDR no local CIDR. Para obter mais informações sobre o uso de registros baseados em IP [Roteamento baseado em IP](routing-policy-ipbased.md). ## Verificação de integridade Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que tem o mesmo nome, tipo e política de roteamento (como failover ou registros ponderados) e especifica IDs de verificação de integridade para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) em **Evaluate target health** (Avaliar a integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de geolocalização, alias baseado em IP, alias de latência ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain name** (Nome de domínio), especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain name** corresponde ao nome dos registros e, em seguida, associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. ## ID de registro Insira um valor que identifique exclusivamente esse registro no grupo de registros baseados em IP. # Valores específicos para registros de alias baseado em IP Quando você criar registros de alias baseado em IP, especifique os valores a seguir. **nota** Embora a criação de registros de alias baseado em IP em uma zona hospedada privada seja permitida, não é compatível. Para obter mais informações, consulte [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Política de roteamento](#rrsets-values-ipbased-alias-routing-policy) + [Nome do registro](#rrsets-values-ipbased-alias-name) + [Tipo de registro](#rrsets-values-ipbased-alias-type) + [Valor/Encaminhar tráfego para](#rrsets-values-ipbased-alias-alias-target) + [Local](#rrsets-values-ipbased-alias-location) + [Verificação de saúde](#rrsets-values-ipbased-alias-associate-with-health-check) + [Avaliar status do alvo](#rrsets-values-ipbased-alias-evaluate-target-health) + [ID de registro](#rrsets-values-ipbased-alias-set-id) ## Política de roteamento Escolha **IP-based** (Baseado em IP). **nota** Embora a criação de registros de alias baseado em IP em uma zona hospedada privada seja permitida, não é compatível. ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Record name** (Nome de registro). Insira o mesmo nome para todos os registros no grupo de registros baseados em IP. **Registros CNAME** Se você estiver criando um registro com um valor **CNAME** para o **Record type** (Tipo de registro), o registro não poderá ter o mesmo o nome da zona hospedada. **Aliases para CloudFront distribuições e buckets do Amazon S3** O valor que você especifica depende em parte do AWS recurso para o qual você está roteando o tráfego: + **CloudFront distribuição** — Sua distribuição deve incluir um nome de domínio alternativo que corresponda ao nome do registro. Por exemplo, se o nome do registro for **acme.example.com**, sua distribuição do CloudFront deve incluir **acme.example.com** como um dos nomes de domínio alternativos. Para obter mais informações, consulte [Uso de nomes de domínio alternativos (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) no *Amazon CloudFront Developer Guide*. + **Bucket do Amazon S3** (Bucket do Amazon S3): o nome do registro deve corresponder ao nome de seu bucket do Amazon S3. Por exemplo, se o nome do seu bucket for **acme.example.com**, o nome desse registro também deve ser **acme.example.com**. Além disso, você deve configurar o bucket para hospedagem de sites. Para obter mais informações, consulte o tópico sobre como [Configurar um bucket para hospedagem do sites](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html), no *Guia do usuário do Amazon Simple Storage Service*. **Caracteres especiais** Para obter informações sobre como especificar caracteres que não sejam a-z, 0-9 e - (hífen) e como especificar nomes de domínio internacionalizados, consulte [Formato de nome de domínio DNS](DomainNameFormat.md). **Caracteres curinga** Você pode usar um asterisco (\$1) no nome. O DNS trata o caractere \$1 como um caractere curinga ou como o caractere \$1 (ASCII 42), dependendo de onde ele aparece no nome. Para obter mais informações, consulte [Usar um asterisco (\$1) nos nomes de zonas hospedadas e registros](DomainNameFormat.md#domain-name-format-asterisk). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o valor aplicável com base no AWS recurso para o qual você está roteando o tráfego. Selecione o mesmo valor para todos os registros no grupo de registros baseados em IP: **API regional personalizada do API Gateway ou API otimizada para bordas** Selecione **A — IPv4 endereço**. **Endpoints de interface da Amazon VPC** Selecione **A — IPv4 endereço**. **CloudFront distribuição** Selecione **A — IPv4 endereço**. Se IPv6 estiver habilitado para a distribuição, crie dois registros, um com um valor de A **— IPv4 endereço** para **Tipo** e outro com um valor de **AAAA — IPv6 endereço**. **Serviço do App Runner** Selecione **A — IPv4 endereço** **Ambiente do Elastic Beanstalk com subdomínios regionalizados** Selecione **A — IPv4 endereço** **Load balancer do ELB** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Bucket do Amazon S3.** Selecione **A — IPv4 endereço** **OpenSearch Serviço** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Outro registro nessa zona hospedada** Selecione o tipo de registro para o qual está criando o alias. Todos os tipos são compatíveis, exceto **NS** e **SOA**. Se você estiver criando um registro de alias com o mesmo nome da zona hospedada (conhecida como *apex de zona*), não será possível rotear o tráfego para um registro para o qual o valor de **Type (Tipo)** seja **CNAME**. Isso ocorre porque o registro de alias deve ter o mesmo tipo que o registro para o qual você está roteando o tráfego e não há suporte para criar um registro CNAME para o apex de zona mesmo para um registro de alias. ## Valor/Encaminhar tráfego para O valor que você escolhe na lista ou digita no campo depende do AWS recurso para o qual você está roteando o tráfego. Para obter informações sobre quais AWS recursos você pode segmentar, consulte [valores comuns para registros de alias para value/route tráfego](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target). Para obter mais informações sobre como configurar o Route 53 para rotear o tráfego para AWS recursos específicos, consulte[Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). ## Local Quando configurar o Route 53 para responder a consultas ao DNS com base no local de origem das consultas, selecione o local CIDR ao qual deseja que o Route 53 responda com as configurações desse registro. **Importante** Recomendamos criar um registro baseado em IP que tenha um valor **Default** (Padrão) para **Location (Local)**. Essa ação abrange os locais para os quais você não criou registros e endereços IP para os quias o Route 53 não consegue identificar um local. Você não pode criar non-IP-based registros que tenham os mesmos valores para **nome** e **tipo de registro** que os registros baseados em IP. Para obter mais informações, consulte [Roteamento baseado em IP](routing-policy-ipbased.md). ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) em **Evaluate target health** (Avaliar a integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de geolocalização, alias de roteamento baseado em PI, alias de latência ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain name** (Nome de domínio), especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain name** corresponde ao nome dos registros e, em seguida, associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. Para registros de alias baseados em IP, se um endpoint não estiver íntegro, o Route 53 procurará um registro no local associado mais amplo. Por exemplo, digamos que você tem registros para um estado nos Estados Unidos, para os Estados Unidos, para a América do Norte e para todas as localizações (**Location (Localização)** é **Default (Padrão)**). Se o endpoint do registro de estado não estiver íntegro, o Route 53 verificará os registros para os Estados Unidos, para a América do Norte e todas as localidades, nessa ordem, até encontrar um registro que tenha um endpoint íntegro. Se todos os registros aplicáveis não estiverem íntegros, incluindo o registro para todas as localizações, o Route 53 responderá à consulta de DNS usando o valor do registro da menor região geográfica. ## Avaliar status do alvo Selecione **Yes** (Sim), se quiser que o Route 53 determine se deve responder a consultas de DNS usando esse registro, verificando a integridade do recurso especificado pelo **Endpoint**. Observe o seguinte: **API Gateway: personalizado, regional APIs e otimizado para bordas APIs** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for uma API regional personalizada do API Gateway ou uma API otimizada para bordas. **CloudFront distribuições** Você não pode definir **Avaliar a integridade do alvo** como **Sim** quando o endpoint é uma CloudFront distribuição. **Ambientes do Elastic Beanstalk com subdomínios regionalizados** Se você especificar um ambiente do Elastic Beanstalk no Endpoint e o **ambiente** contiver um balanceador de carga ELB, o Elastic Load Balancing roteará as consultas somente para as instâncias íntegras da Amazon registradas no EC2 load balancer. (Um ambiente contém automaticamente um balanceador de carga ELB se incluir mais de uma EC2 instância da Amazon.) Se você definir **Avaliar a integridade da meta como** **Sim** e nenhuma EC2 instância da Amazon estiver íntegra ou o próprio balanceador de carga não estiver íntegro, o Route 53 encaminhará as consultas para outros recursos disponíveis que estejam íntegros, se houver. Se o ambiente contiver uma única EC2 instância da Amazon, não haverá requisitos especiais. **Load balancers do ELB** O comportamento de verificação da integridade depende do tipo do load balancer: + **Classic Load Balancers** — Se você especificar um ELB Classic Load Balancer **no** Endpoint, o Elastic Load Balancing roteará as consultas somente para as instâncias íntegras da EC2 Amazon que estão registradas no load balancer. Se você definir **Avaliar a integridade do alvo como** **Sim** e nenhuma EC2 instância estiver íntegra ou o balanceador de carga em si não estiver íntegro, o Route 53 encaminhará as consultas para outros recursos. + **Application and Network Load Balancers** (Aplicação e Balanceadores de carga da rede): se você especificar uma Aplicação de ELB ou Balanceador de carga da rede e definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim), o Route 53 encaminha consultas para o balanceador de carga com base na integridade dos grupos de destino que estão associados com o balanceador de carga: + Para que um Application ou Network Load Balancer seja considerado íntegro, cada grupo de destino que contenha destinos deve conter pelo menos um destino íntegro. Se qualquer grupo de destinos contiver somente destinos não íntegros, o load balancer será considerado não íntegro e o Route 53 direcionará as consultas para outros recursos. + Um grupo de destinos que não tenha destinos registrados é considerado não íntegro. Ao criar um load balancer, defina as configurações para verificações de integridade do Elastic Load Balancing; elas não são verificações de integridade do Route 53, mas executam uma função semelhante. Não crie verificações de saúde do Route 53 para as EC2 instâncias que você registra com um balanceador de carga ELB. **Buckets do S3** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um bucket do S3. **Endpoints de interface da Amazon VPC** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um endpoint da interface da Amazon VPC. **Outros registros na mesma zona hospedada** Se o AWS recurso especificado no **Endpoint** for um registro ou um grupo de registros (por exemplo, um grupo de registros ponderados), mas não for outro registro de alias, recomendamos que você associe uma verificação de saúde a todos os registros no endpoint. Para obter mais informações, consulte [O que acontece quando você omite verificações de integridade?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID de registro Insira um valor que identifique exclusivamente esse registro no grupo de registros baseados em IP. # Valores específicos para registros de resposta com valores múltiplos Quando você criar conjuntos de recursos com valores múltiplos, especifique os seguintes valores. **nota** Não há suporte para a criação de recursos de alias de resposta com valores múltiplos. **Topics** + [Política de roteamento](#rrsets-values-multivalue-routing-policy) + [Nome do registro](#rrsets-values-multivalue-name) + [Tipo de registro](#rrsets-values-multivalue-type) + [TTL (segundos)](#rrsets-values-multivalue-ttl) + [Valor/Encaminhar tráfego para](#rrsets-values-multivalue-value) + [Verificação de saúde](#rrsets-values-multivalue-associate-with-health-check) + [ID de registro](#rrsets-values-multivalue-set-identifier) ## Política de roteamento Escolha **Multivalue answer** (Resposta com valores múltiplos). ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Record name** (Nome de registro). Insira o mesmo nome para todos os registros do grupo de registros multivalores. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione qualquer valor, exceto **NS** ou **CNAME**. Selecione o mesmo valor para todos os registros no grupo de registros de resposta de valores múltiplos. ## TTL (segundos) A quantidade de tempo, em segundos, que você deseja que os resolvedores recursivos de DNS armazenem informações em cache sobre esse registro. Se você especificar um valor mais longo (por exemplo, 172800 segundos ou dois dias), reduzirá o número de chamadas que os resolvedores recursivos de DNS devem fazer ao Route 53 para obter as informações mais recentes neste registro. Isso tem o efeito de reduzir a latência e reduzir sua fatura para o serviço do Route 53. Para obter mais informações, consulte [Como o Amazon Route 53 encaminha tráfego para o seu domínio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). No entanto, se você especificar um valor mais longo para TTL, levará mais tempo para que as alterações no registro (por exemplo, um novo endereço IP) entrem em vigor porque os resolvedores recursivos usam os valores em cache por períodos mais longos antes de solicitar as informações mais recentes ao Route 53. Se você estiver alterando as configurações de um domínio ou subdomínio que já está em uso, recomendamos que especifique inicialmente um valor mais curto, como 300 segundos, e aumente o valor depois de confirmar que as novas configurações estão corretas. Se você estiver associando esse registro a uma verificação de integridade, recomendamos especificar um TTL de 60 segundos ou menos para que os clientes respondam rapidamente a alterações no status de integridade. **nota** Se você criar dois ou mais registros de resposta com vários valores que possuem o mesmo nome e tipo, estiver usando o console e especificar valores diferentes para **TTL**, o Route 53 alterará o valor de **TTL** de todos os registros para o último valor especificado. ## Valor/Encaminhar tráfego para Escolha o **endereço IP ou outro valor dependendo do tipo de registro**. Insira um valor que seja adequado para o valor de **Record type** (Tipo de registro). Se você inserir mais de um valor, insira cada um dos valores em linhas separadas. Você pode direcionar tráfego ou especificar os seguintes valores: + **A — IPv4 endereço** + **AAAA — IPv6 endereço** + **CAA: Autorização da Autoridade de Certificação** + **MX: Intercâmbio de mensagens** + **NAPTR: Ponteiro de Autoridade de Nomes** + **PTR: Ponteiro** + **SPF: Framework de Política de Remetente** + **SRV: Localizador de serviço** + **TXT: Texto** Para obter mais informações sobre os valores acima, consulte [valores comuns para Value/Route tráfego para](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) para **Evaluate target health** (Avaliar integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de localização geográfica, alias de latência ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain name** (Nome de domínio), especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain name** corresponde ao nome dos registros e, em seguida, associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. ## ID de registro Insira um valor que identifique esse registro no grupo de registros de resposta de valores múltiplos de forma exclusiva. # Valores específicos para registros ponderados Quando você criar registros ponderados, especifique os seguintes valores. **Topics** + [Política de roteamento](#rrsets-values-weighted-routing-policy) + [Nome do registro](#rrsets-values-weighted-name) + [Tipo de registro](#rrsets-values-weighted-type) + [TTL (segundos)](#rrsets-values-weighted-ttl) + [Valor/Encaminhar tráfego para](#rrsets-values-weighted-value) + [Weight](#rrsets-values-weighted-weight) + [Verificação de saúde](#rrsets-values-weighted-associate-with-health-check) + [ID de registro](#rrsets-values-weighted-set-identifier) ## Política de roteamento Selecione **Weighted (Ponderado)**. ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Record name** (Nome de registro). Insira o mesmo nome para todos os registros no grupo de registros ponderados. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o mesmo valor para todos os registros no grupo de registros ponderados. ## TTL (segundos) A quantidade de tempo, em segundos, que você deseja que os resolvedores recursivos de DNS armazenem informações em cache sobre esse registro. Se você especificar um valor mais longo (por exemplo, 172800 segundos ou dois dias), reduzirá o número de chamadas que os resolvedores recursivos de DNS devem fazer ao Route 53 para obter as informações mais recentes neste registro. Isso tem o efeito de reduzir a latência e reduzir sua fatura para o serviço do Route 53. Para obter mais informações, consulte [Como o Amazon Route 53 encaminha tráfego para o seu domínio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). No entanto, se você especificar um valor mais longo para TTL, levará mais tempo para que as alterações no registro (por exemplo, um novo endereço IP) entrem em vigor porque os resolvedores recursivos usam os valores em cache por períodos mais longos antes de solicitar as informações mais recentes ao Route 53. Se você estiver alterando as configurações de um domínio ou subdomínio que já está em uso, recomendamos que especifique inicialmente um valor mais curto, como 300 segundos, e aumente o valor depois de confirmar que as novas configurações estão corretas. Se você estiver associando esse registro a uma verificação de integridade, recomendamos especificar um TTL de 60 segundos ou menos para que os clientes respondam rapidamente a alterações no status de integridade. É necessário especificar o mesmo valor de **TTL** para todos os registros nesse grupo de registros ponderados. **nota** Se você criar dois ou mais registros ponderados que tenham o mesmo nome e tipo, e especificar valores diferentes para **TTL**, o Route 53 alterará o valor de **TTL** de todos os registros para o último valor que você tiver especificado. Se um grupo de registros ponderados incluir um ou mais registro de alias ponderados que estiverem roteando um load balancer do ELB, recomendamos especificar um TTL de 60 segundos para todos os registros ponderados não de alias que tenham o mesmo nome e tipo. Valores diferentes de 60 segundos (o TTL para load balancers) alterarão o efeito dos valores especificados para **Weight (Peso)**. ## Valor/Encaminhar tráfego para Escolha o **endereço IP ou outro valor dependendo do tipo de registro**. Insira um valor que seja adequado para o valor de **Record type** (Tipo de registro). Para todos os tipos exceto **CNAME**, é possível incorporar mais de um valor. Insira cada valor em uma linha separada. Você pode direcionar tráfego ou especificar os seguintes valores: + **A — IPv4 endereço** + **AAAA — IPv6 endereço** + **CAA: Autorização da Autoridade de Certificação** + **CNAME: Nome canônico** + **MX: Intercâmbio de mensagens** + **NAPTR: Ponteiro de Autoridade de Nomes** + **PTR: Ponteiro** + **SPF: Framework de Política de Remetente** + **SRV: Localizador de serviço** + **TXT: Texto** Para obter mais informações sobre os valores acima, consulte [valores comuns para Value/Route tráfego para](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Weight Um valor que determina a proporção de consultas ao DNS às quais o Route 53 responde para usar o registro atual. O Route 53 calcula a soma dos pesos para os registros que tenham a mesma combinação de nome de DNS e tipo. Em seguida, o Route 53 responde às consultas com base na proporção entre o peso de um recurso e o total. Não é possível criar registros não ponderados que tenham os mesmos valores para **Record name** (Nome do registro) e **Record type** (Tipo de registro) que os registros ponderados. Insira um número inteiro entre 0 e 255. Para desabilitar o encaminhamento para um recurso, defina **Weight (Peso)** como 0. Se **Weight (Peso)** for definido como 0 para todos os registros no grupo, o tráfego será roteado para todos os recursos com probabilidade igual. Isso garante que você não desative acidentalmente o roteamento para um grupo de registros ponderados. O efeito de configurar **Weight (Peso)** como 0 é diferente quando as verificações de integridade são associadas com registros ponderados. Para obter mais informações, consulte [Como o Amazon Route 53 escolhe registros quando a verificação de integridade está configuradaComo o Route 53 escolhe registros quando a verificação de integridade está configurada](health-checks-how-route-53-chooses-records.md). ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) em **Evaluate target health** (Avaliar a integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de geolocalização, alias de latência, alias baseado em IP ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain name** (Nome de domínio), especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain name** corresponde ao nome dos registros e, em seguida, associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. ## ID de registro Insira um valor que identifique esse registro no grupo de registros ponderados de forma exclusiva. # Valores específicos para registros de alias ponderados Quando você criar registros de alias ponderados, especifique os seguintes valores. Para obter mais informações, consulte [Escolher entre registros de alias e não alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Política de roteamento](#rrsets-values-weighted-alias-routing-policy) + [Nome do registro](#rrsets-values-weighted-alias-name) + [Tipo de registro](#rrsets-values-weighted-alias-type) + [Valor/Encaminhar tráfego para](#rrsets-values-weighted-alias-alias-target) + [Weight](#rrsets-values-weighted-alias-weight) + [Verificação de saúde](#rrsets-values-weighted-alias-associate-with-health-check) + [Avaliar status do alvo](#rrsets-values-weighted-alias-evaluate-target-health) + [ID de registro](#rrsets-values-weighted-alias-set-identifier) ## Política de roteamento Escolha **Weighted** (Ponderado). ## Nome do registro Digite o nome de domínio ou do subdomínio para o qual deseja rotear o tráfego. O valor padrão é o nome da zona hospedada. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo **Name (Nome)**. Insira o mesmo nome para todos os registros no grupo de registros ponderados. Para obter mais informações sobre nomes de registros, consulte [Nome do registro](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) ## Tipo de registro O tipo de registro de DNS. Para obter mais informações, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). Selecione o valor aplicável com base no AWS recurso para o qual você está roteando o tráfego: **API regional personalizada do API Gateway ou API otimizada para bordas** Selecione **A — IPv4 endereço**. **Endpoints de interface da Amazon VPC** Selecione **A — IPv4 endereço**. **CloudFront distribuição** Selecione **A — IPv4 endereço**. Se IPv6 estiver habilitado para a distribuição, crie dois registros, um com um valor de A **— IPv4 endereço** para **Tipo** e outro com um valor de **AAAA — IPv6 endereço**. **Serviço do App Runner** Selecione **A — IPv4 endereço** **Ambiente do Elastic Beanstalk com subdomínios regionalizados** Selecione **A — IPv4 endereço** **Load balancer do ELB** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Bucket do Amazon S3.** Selecione **A — IPv4 endereço** **OpenSearch Serviço** Selecione **A — IPv4 endereço** ou **AAAA — IPv6 ** endereço **Outro registro nessa zona hospedada** Selecione o tipo de registro para o qual está criando o alias. Todos os tipos são compatíveis, exceto **NS** e **SOA**. Se você estiver criando um registro de alias com o mesmo nome da zona hospedada (conhecida como *apex de zona*), não será possível rotear o tráfego para um registro para o qual o valor de **Type (Tipo)** seja **CNAME**. Isso ocorre porque o registro de alias deve ter o mesmo tipo que o registro para o qual você está roteando o tráfego e não há suporte para criar um registro CNAME para o apex de zona mesmo para um registro de alias. Selecione o mesmo valor para todos os registros no grupo de registros ponderados. ## Valor/Encaminhar tráfego para O valor que você escolhe na lista ou digita no campo depende do AWS recurso para o qual você está roteando o tráfego. Para obter informações sobre quais AWS recursos você pode segmentar, consulte [valores comuns para registros de alias para value/route tráfego](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target). Para obter mais informações sobre como configurar o Route 53 para rotear o tráfego para AWS recursos específicos, consulte[Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). ## Weight Um valor que determina a proporção de consultas ao DNS às quais o Route 53 responde para usar o registro atual. O Route 53 calcula a soma dos pesos para os registros que tenham a mesma combinação de nome de DNS e tipo. Em seguida, o Route 53 responde às consultas com base na proporção entre o peso de um recurso e o total. Não é possível criar registros não ponderados que tenham os mesmos valores para **Record name** (Nome do registro) e **Record type** (Tipo de registro) que os registros ponderados. Insira um número inteiro entre 0 e 255. Para desabilitar o encaminhamento para um recurso, defina **Weight (Peso)** como 0. Se **Weight (Peso)** for definido como 0 para todos os registros no grupo, o tráfego será roteado para todos os recursos com probabilidade igual. Isso garante que você não desative acidentalmente o roteamento para um grupo de registros ponderados. O efeito de configurar **Weight (Peso)** como 0 é diferente quando as verificações de integridade são associadas com registros ponderados. Para obter mais informações, consulte [Como o Amazon Route 53 escolhe registros quando a verificação de integridade está configuradaComo o Route 53 escolhe registros quando a verificação de integridade está configurada](health-checks-how-route-53-chooses-records.md). ## Verificação de saúde Selecione uma verificação de integridade, se quiser que o Route 53 verifique a integridade de um endpoint especificado e responda a consultas de DNS usando esse registro somente quando o endpoint for íntegro. O Route 53 não verifica a integridade do endpoint especificado no registro, por exemplo, o endpoint especificado pelo endereço IP no campo **Value** (Valor). Ao selecionar uma verificação de integridade de um registro, o Route 53 verifica a integridade do endpoint especificado na verificação de integridade. Para obter informações sobre como o Route 53 determina se um endpoint é íntegro, consulte [Como o Amazon Route 53 determina a integridade de uma verificação de integridadeComo o Route 53 determina a integridade de uma verificação de integridade](dns-failover-determining-health-of-endpoints.md). Associar uma verificação de integridade a um registro é útil somente quando o Route 53 estiver escolhendo entre dois ou mais registros para responder a uma consulta de DNS, e você desejar que o Route 53 baseie a escolha, em parte, no status de uma verificação de integridade. Use as verificações de integridade somente nas seguintes configurações: + Você está verificando a integridade de todos os registros em um grupo de registros que têm o mesmo nome, tipo e política de roteamento (como registros ponderados ou de failover) e especifica a verificação de integridade IDs para todos os registros. Se a verificação de integridade de um registro especificar um endpoint que não esteja íntegro, o Route 53 para de responder às consultas, usando o valor para esse registro. + Selecione **Yes** (Sim) em **Evaluate target health** (Avaliar a integridade do destino) para um registro de alias ou os registros em um grupo de alias de failover, alias de geolocalização, alias de latência, alias baseado em IP ou registro de alias ponderado. Se o registro de alias fizer referência a registros não de alias na mesma zona hospedada, você também deve especificar as verificações de integridade para os registros mencionados. Se você associar uma verificação de integridade a um registro de alias e também selecionar **Yes** (SIM) para **Evaluate Target Health** (Avaliar integridade do destino), ambos devem ser avaliados como verdadeiros. Para obter mais informações, consulte [O que acontece quando você associa uma verificação de integridade a um registro de alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se suas verificações de integridade especificarem o endpoint apenas por nome de domínio, recomendamos que você crie uma verificação de integridade separada para cada endpoint. Por exemplo, crie uma verificação de saúde para cada servidor HTTP que esteja veiculando conteúdo para www.example.com. Para o valor **Domain name** (Nome de domínio), especifique o nome do domínio do servidor (como us-east-2-www.exemplo.com), não o nome dos registros (www.exemplo.com). **Importante** Nessa configuração, se você criar uma verificação de integridade para a qual o valor de **Domain name** corresponde ao nome dos registros e, em seguida, associar a verificação de integridade a esses registros, os resultados da verificação de integridade serão imprevisíveis. ## Avaliar status do alvo Selecione **Yes** (Sim), se quiser que o Route 53 determine se deve responder a consultas de DNS usando esse registro, verificando a integridade do recurso especificado pelo **Endpoint**. Observe o seguinte: **API Gateway: personalizado, regional APIs e otimizado para bordas APIs** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for uma API Regional personalizada do API Gateway ou uma API otimizada para borda. **CloudFront distribuições** Você não pode definir **Avaliar a integridade do alvo** como **Sim** quando o endpoint é uma CloudFront distribuição. **Ambientes do Elastic Beanstalk com subdomínios regionalizados** Se você especificar um ambiente do Elastic Beanstalk no **Endpoint** e o ambiente contiver um load balancer do ELB, o Elastic Load Balancing encaminhará consultas apenas para as instâncias íntegras ​​do Amazon EC2 que estão registradas com o balanceador de carga. (Um ambiente contém automaticamente um load balancer do ELB se incluir mais de uma instância do Amazon EC2.) Se você definir **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) e nenhuma instância do Amazon EC2 estiver íntegro ou o próprio balanceador de carga não estiver íntegro, o Route 53 encaminhará as consultas para outros recursos disponíveis que sejam íntegros, se houver. Se o ambiente contiver uma única instância do Amazon EC2, não há requisitos especiais. **Load balancers do ELB** O comportamento de verificação da integridade depende do tipo do load balancer: + **Classic Load Balancers** (Balanceadores de carga clássicos): se você especificar um Balanceador de carga clássico do ELB no **Endpoint**, o Elastic Load Balancing encaminhará consultas apenas para instâncias do Amazon EC2 íntegras que estejam registradas no balanceador de carga. Se você definir **Evaluate Target Health** (Avaliar integridade do destino) como **Yes** (Sim) e nenhuma instância do EC2 estiver íntegra, ou se o próprio balanceador de carga não estiver íntegro, o Route 53 encaminha consultas para outros recursos. + **Application e Network Load Balancers** (Aplicação e Balanceadores de Carga de Rede): se você especificar uma Aplicação ou Balanceador de Carga de Rede do ELB e definir **Evaluate Target Health** (Avaliar integridade do destino) como **Yes** (Sim), o Route 53 encaminha consultas para o balanceador de carga com base na integridade dos grupos de destino que estão associados com o balanceador de carga: + Para que um Application ou Network Load Balancer seja considerado íntegro, cada grupo de destino que contenha destinos deve conter pelo menos um destino íntegro. Se qualquer grupo de destinos contiver somente destinos não íntegros, o load balancer será considerado não íntegro e o Route 53 direcionará as consultas para outros recursos. + Um grupo de destinos que não tenha destinos registrados é considerado não íntegro. Ao criar um load balancer, defina as configurações para verificações de integridade do Elastic Load Balancing; elas não são verificações de integridade do Route 53, mas executam uma função semelhante. Não crie verificações de integridade do Route 53 para as instâncias do EC2 registradas com um load balancer do ELB. **Buckets do S3** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um bucket do S3. **Endpoints de interface da Amazon VPC** Não existem requisitos especiais para configurar **Evaluate target health** (Avaliar integridade do destino) como **Yes** (Sim) quando o endpoint for um endpoint da interface da Amazon VPC. **Outros registros na mesma zona hospedada** Se o AWS recurso que você especificar no **Endpoint** for um registro ou um grupo de registros (por exemplo, um grupo de registros ponderados), mas não for outro registro de alias, recomendamos que você associe uma verificação de saúde a todos os registros no endpoint. Para obter mais informações, consulte [O que acontece quando você omite verificações de integridade?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID de registro Insira um valor que identifique esse registro no grupo de registros ponderados de forma exclusiva. # Criar registros importando um arquivo de zona Se você estiver migrando de outro provedor de serviço de DNS, e se o provedor de serviço de DNS atual permitir que você exporte suas configurações de DNS atuais para um arquivo de zona, você poderá criar rapidamente todos os registros para uma zona hospedada do Amazon Route 53 importando um arquivo de zona. **nota** Um arquivo de zona usa um formato padrão conhecido como BIND para representar registros em um formato de texto. Para obter informações sobre o formato de um arquivo de zona, consulte a entrada [Zone file](https://en.wikipedia.org/wiki/Zone_file) na Wikipedia. Informações adicionais estão disponíveis na seção 3.6.1 da [RFC 1034, Domain Names—Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) e na seção 5 da [RFC 1035, Domain Names—Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035). Se você quiser criar registros importando um arquivo de zona, observe o seguinte: + O arquivo de zona deve estar em um formato compatível com a RFC. + O nome de domínio dos registros no arquivo de zona deve corresponder ao nome da zona hospedada. + O Route 53 oferece suporte às palavras-chave `$ORIGIN` e `$TTL`. Se o arquivo da zona incluir as palavras-chave `$GENERATE` ou `$INCLUDE`, a importação falhará e o Route 53 retornará um erro. + Quando você importa o arquivo de zona, o Route 53 ignora o registro de SOA no arquivo de zona. O Route 53 também ignora quaisquer registros de NS que têm o mesmo nome da zona hospedada. + Você pode importar um máximo de 1000 registros. + Se a zona hospedada já contiver registros que aparecem no arquivo de zona, o processo de importação falhará e nenhum registro será criado. + Para registros TXT que contêm caracteres de barra invertida, o processo de importação do arquivo de zona interpreta determinadas sequências de barras invertidas como caracteres de controle. Para incluir caracteres de barra invertida literais em valores de registros TXT: + Use barras invertidas duplas (`\\\\`) no arquivo de zona para representar uma única barra invertida literal no registro TXT final. + Por exemplo, se o seu registro TXT deve conter `\\jYTDWqH...` (com uma barra invertida literal e j), especifique `\\\\jYTDWqH...` no arquivo de zona. Isso é particularmente importante para registros de desafio ACME e outros registros TXT que contêm caracteres literais de barra invertida. + Para registros TXT longos (como registros DKIM), o processo de importação do arquivo de zona aceita a divisão do conteúdo em várias strings. Para criar registros TXT com várias strings: + Use linhas separadas no seu arquivo de zona com o mesmo nome e tipo de registro. **Example** ``` example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC" example.com. 300 IN TXT "7fCC6C13dM9tXuJmUBH7D4Vw8y1ByJ8z9QX2fvLm3pN4sR5tU6vW7xY8zA9bC0dE1f" example.com. 300 IN TXT "G2hI3jK4lM5nO6pQ7rS8tU9vW0xY1zA2bC3dE4fG5hI6jK7lM8nO9pQ0rS1tU2vW3x" ``` O processo de importação as combina automaticamente em um único registro TXT com várias strings. Cada string individual pode conter até 65.535 caracteres. Não concatene strings longas em um único valor entre aspas. + Recomendamos que você revise o conteúdo do arquivo de zona para confirmar se os nomes de registro incluem ou excluem um ponto final, conforme apropriado: + Quando o nome de um registro no arquivo de zona inclui um ponto final (`example.com.`), o processo de importação interpreta o nome como um nome de domínio totalmente qualificado e cria um registro do Route 53 com esse nome. + Quando o nome de um registro no arquivo de zona não inclui um ponto final (`www`), o processo de importação concatena esse nome com o nome do domínio no arquivo de zona (`example.com`) e cria um registro do Route 53 com o nome concatenado (`www.example.com`). Se o processo de exportação não adicionar um ponto final aos nomes de domínio totalmente qualificados de um registro, o processo de importação do Route 53 adicionará o nome de domínio ao nome do registro. Por exemplo, suponha que você esteja importando registros para a zona hospedada `example.com` e o nome de um registro MX no arquivo de zona seja `mail.example.com`, sem ponto final. O processo de importação do Route 53 cria um registro MX chamado `mail.example.com.example.com`. **Importante** Para os registros CNAME, MX, PTR e SRV, este comportamento também se aplica ao nome de domínio que está incluído no valor RDATA. Por exemplo, suponha que você tem um arquivo de zona para `example.com`. Se um registro CNAME no arquivo de zona (`support`, sem um ponto final) tiver um valor RDATA de `www.example.com` (também sem um ponto final), o processo de importação criará um registro do Route 53 com o nome `support.example.com` que encaminha o tráfego para `www.example.com.example.com`. Antes de importar seu arquivo de zona, revise o valores RDATA e atualize conforme aplicável. Para registros TXT contendo caracteres de barra invertida, use barras invertidas duplas (`\\\\`) no arquivo de zona para representar barras invertidas literais. O Route 53 não oferece suporte à exportação de registros para um arquivo de zona. **nota** Se você estiver criando um registro que tenha o mesmo nome que a zona hospedada, não insira um valor (por exemplo, um símbolo de @) no campo Name (Nome). **Para criar registros importando um arquivo de zona** 1. Obtenha um arquivo de zona a partir do provedor de serviços de DNS que está servindo o domínio. O processo e a terminologia variam de um provedor de serviços para outro. Consulte a interface e a documentação do provedor para obter informações sobre como exportar ou salvar seus registros em um arquivo de zona ou em um arquivo BIND Se o processo não for óbvio, entre em contato com o atendimento ao cliente do seu provedor de DNS atual e peça informações sobre a *lista de registros* ou o *arquivo de zona*. 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 **Zonas hospedadas**. 1. Na página **Hosted zones** (Zonas hospedadas), crie uma nova zona hospedada: 1. Escolha **Create hosted zone** (Criar zona hospedada). 1. Digite o nome do seu domínio e, se desejar, um comentário. 1. Escolha **Criar**. 1. Escolha **Import zone file** (Importar arquivo de zona). 1. No painel **Import zone file** (Importar arquivo de zona), cole o conteúdo do arquivo de zona na caixa de texto **Zone file** (Arquivo de zona). 1. Escolha **Importar**. **nota** Dependendo do número de registros em seu arquivo de zona, talvez você precise aguardar alguns minutos para que os registros sejam criados. 1. Se você estiver usando outro serviço de DNS para o domínio (que é comum se você registrou o domínio com outro registrador), migre o serviço de DNS para o Route 53. Quando essa etapa estiver concluída, o registrador começará a identificar o Route 53 como o serviço DNS em resposta às consultas DNS do seu domínio, e as consultas começarão a ser enviadas aos servidores DNS do Route 53. (Normalmente, é necessário aguardar de um a dois dias até que as consultas de DNS comecem a ser roteadas para o Route 53. Isso ocorre porque as informações sobre o serviço de DNS anterior ficam armazenadas em cache durante este período nos resolvedores do DNS.) Para obter mais informações, consulte [Como transformar o Amazon Route 53 no serviço de DNS para um domínio existenteComo transformar o Route 53 no serviço de DNS para um domínio existente](MigratingDNS.md). # Editar registros O procedimento a seguir explica como editar registros usando o console do Amazon Route 53. Para obter informações sobre como editar registros usando a API do Route 53, consulte [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)a *Referência da API do Amazon Route 53*. **nota** As alterações nos registros demoram para serem propagadas até os servidores DNS do Route 53. Atualmente, a única forma de verificar se as alterações se propagaram é usando a ação da [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. As alterações geralmente são propagadas para todos os servidores de nome do Route 53 em até 60 segundos. **Para editar registros usando o console do Route 53** 1. Se você não estiver editando registros de alias, vá para a etapa 2. Se você estiver editando registros de alias que roteiam tráfego para um Classic Load Balancer, um Application Load Balancer ou um Network Load Balancer de Elastic Load Balancing, e tiver criado a zona hospedada do Route 53 e o balanceador de carga usando contas diferentes, siga o procedimento [Obter o nome do DNS para um balanceador de carga de Elastic Load Balancing](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure) para obter o nome do DNS do balanceador de carga. Se você estiver editando registros de alias para qualquer outro AWS recurso, vá para a etapa 2. 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 **Zonas hospedadas**. 1. Na página **Hosted Zones (Zonas hospedadas)**, selecione a linha da zona hospedada que contém os registros que deseja editar. 1. Selecione a linha do registro que você deseja editar e insira suas alterações no painel **Edit record** (Editar registro). 1. Insira os valores aplicáveis. Para obter mais informações, consulte [Valores que você especifica ao criar ou editar registros do Amazon Route 53](resource-record-sets-values.md). 1. Escolha **Salvar alterações**. 1. Se você estiver editando vários registros, repita as etapas de 5 a 7. # Excluir registros O procedimento a seguir explica como excluir registros usando o console do Route 53. Para obter informações sobre como excluir registros usando a API do Route 53, consulte [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)a *Referência da API do Amazon Route 53*. **nota** As alterações nos registros demoram para serem propagadas até os servidores DNS do Route 53. Atualmente, a única forma de verificar se as alterações se propagaram é usando a ação da [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. As alterações geralmente são propagadas para todos os servidores de nome do Route 53 em até 60 segundos. **Para excluir registros** 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. Na página Zonas hospedadas, selecione a linha da zona hospedada que contém os registros que você deseja excluir. 1. Na lista de registros, selecione o registro que você quer excluir. Para selecionar vários registros consecutivos, selecione a primeira linha, mantenha a tecla **Shift** pressionada e selecione a última linha. Para selecionar vários registros não consecutivos, selecione na primeira linha, mantenha a tecla **Ctrl** pressionada e selecione as demais linhas. Você não pode excluir os registros que têm um valor de **NS** ou **SOA** para **Type (Tipo)**. 1. Escolha **Excluir**. 1. Escolha **Delete** (Excluir) para fechar a caixa de diálogo. # Listar registros O procedimento a seguir explica como usar o console do Amazon Route 53 para listar os registros em uma zona hospedada. Para obter informações sobre como listar registros usando a API do Route 53, consulte [ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html)a *Referência da API do Amazon Route 53*. **Para listar registros** 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 **Zonas hospedadas**. 1. Na página **Zonas hospedadas**, escolha o nome de uma zona hospedada. 1. Para alterar os campos da pesquisa, escolha o ícone de engrenagem no canto superior direito da tabela **Records**. Escolha uma destas opções: + **Automatic** Nesse modo, o serviço usa um filtro baseado em vários registros. Completo para menos de 2.000 e rápido para mais de 2.000 registros. + **Full** Nesse modo, todos os filtros de pesquisa estão disponíveis, mas a performance da pesquisa pode ser mais lenta. + **Fast** Nesse modo, alguns recursos avançados não estão disponíveis, mas a performance da pesquisa será mais rápida. Para exibir somente os registros selecionados, informe os critérios de pesquisa aplicáveis acima da lista de registros. No modo automático, o comportamento da pesquisa depende de a zona hospedada conter menos ou mais de 2.000 registros: **Até 2.000 registros e modo completo** + Para exibir os registros que têm valores específicos, informe um valor na barra de pesquisa e pressione **Enter**. Por exemplo, para exibir os registros com um endereço IP que começa com **192.0**, insira esse valor no campo **Search (Pesquisar)** e pressione **Enter**. + Para exibir somente os registros que têm o mesmo tipo de registro DNS, selecione **Record type** (Tipo de registro) na lista suspensa e insira o tipo de registro. + Para exibir somente registros de alias, selecione **Aliases** na lista suspensa e insira **Yes**. + Para exibir somente registros ponderados, selecione **Routing policy** (Política de roteamento) na lista suspensa e insira **WEIGHTED**. **Mais de 2.000 registros e modo rápido** + Você pode pesquisar apenas nos nomes de registros, e não nos valores de registros. Também não é possível usar filtros com base no tipo de registro, no alias ou nos registros ponderados. Para isso, coloque o cursor na caixa de texto **Filtrar**, selecione **Propriedades** e, depois, **Nome do registro**. + Em registros que possuem três rótulos (três partes separadas por pontos), quando você insere um valor no campo de pesquisa e pressiona **Enter**, o console do Route 53 executa automaticamente uma pesquisa com caracteres curinga no terceiro rótulo à direita no nome do registro. Por exemplo, suponha que a zona hospedada example.com contenha 100 registros denominados record1.example.com por meio de record100.example.com. (Record1 é o terceiro rótulo da direita.) Veja o que acontece quando você pesquisa os seguintes valores: + **record1**: o console do Route 53 procura por **record1\$1.example.com**, que retorna **record1.example.com**, **record10.example.com** a **record19.example.com** e **record100.example.com**. + **record1.example.com** – como no exemplo anterior, o console pesquisa **record1.example.com** e retorna os mesmos registros. + **1**: o console procura por **1\$1.example.com** e não retorna registros. + **example**: o console procura por **example\$1.example.com** e não retorna registros. + **example.com**: neste exemplo, o console não executa uma pesquisa com caractere curinga. Ele retorna todos os registros na zona hospedada. + **Modo de pesquisa automática**: quando usar esse modo de pesquisa, para pesquisar, você deverá primeiro fornecer uma propriedade, como nome do registro. **nota** Se o terceiro rótulo da direita contiver um ou mais hifens (por exemplo, `third-label.example.com`) e, se você pesquisar a parte do terceiro rótulo imediatamente antes do hífen (`third` neste exemplo), o Route 53 não retornará registros. Em vez disso, inclua o hífen (pesquise `third-`) ou omita o caractere imediatamente antes do hífen (pesquise `third`). + Para registros que possuem quatro ou mais rótulos, você deve especificar o nome exato do registro. Não há suporte para pesquisas curinga. Por exemplo, se a zona hospedada incluir um registro denominado label4.record1.example.com, você poderá localizar esse registro apenas se especificar **label4.record1.example.com** no campo de pesquisa. # 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). # Usar o AWS Cloud Map para criar registros e verificações de integridade Para encaminhar tráfego da Internet ou tráfego dentro de uma Amazon VPC para componentes de aplicações ou microsserviços, é possível usar o AWS Cloud Map para criar registros automaticamente e, opcionalmente, criar verificações de integridade. Para obter mais informações, consulte o [Guia do desenvolvedor do AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/). # Restrições e comportamentos de DNS As mensagens de DNS estão sujeitas a fatores que afetam a maneira como você cria e usa zonas hospedadas e registros. Esta seção explica esses fatores. ## Tamanho máximo da resposta Para fins de conformidade com os padrões de DNS, as respostas enviadas por UDP são limitadas a 512 bytes de tamanho. As respostas que excedem 512 bytes são truncadas, e o resolvedor precisa enviar a solicitação novamente por TCP. Se o Resolver oferecer suporte para EDNS0 (conforme definido na [RFC 2671](https://tools.ietf.org/html/rfc2671)) e anunciar a opção EDNS0 ao Amazon Route 53, o Route 53 permitirá respostas de até 4096 bytes por UDP, sem truncamento. ## Processamento da seção autorizada Para consultas bem-sucedidas, o Route 53 anexa registros do servidor de nomes (NS) da zona hospedada relevante à seção Authority (Autoridade) da resposta de DNS. Para nomes não encontrados (respostas NXDOMAIN), o Route 53 acrescenta o registro de início de autoridade (SOA) (conforme definido na [RFC 1035](https://tools.ietf.org/html/rfc1035)) da zona hospedada relevante à seção Authority (Autoridade) da resposta DNS. ## Processamento da seção adicional O Route 53 anexa registros à seção Additional (Adicional). Se os registros forem conhecidos e apropriados, o serviço anexará registros A ou AAAA para qualquer destino de um registro MX, CNAME, NS ou SRV citado na seção de resposta. Para obter mais informações sobre esses tipos de registro de DNS, consulte [Tipos de registro de DNS com suporte](ResourceRecordTypes.md). # Tópicos relacionados Para obter mais informações sobre os conceitos básicos do Amazon Route 53, consulte os seguintes tópicos neste guia: + [Lista de verificação pré-transferência para transferências de domínios](domain-transfer-checklist.md): complete essa lista de verificação antes de transferir o registro do domínio para evitar falhas comuns na transferência. + [Como transferir registro de um domínio para o Amazon Route 53](domain-transfer-to-route-53.md): processo passo a passo para transferir o registro de domínio de outro registrador para o Route 53. + [Transferir domínios](domain-transfer.md): visão geral de todas as opções de transferência de domínio, incluindo transferências entre contas da AWS.