

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

# Proteção contra registros de delegação pendentes no Route 53
<a name="protection-from-dangling-dns"></a>

Com o Route 53, um cliente pode criar uma zona hospedada, como `example.com`, para hospedar os registros DNS. Cada zona hospedada vem com um "conjunto de delegação", que é um conjunto de quatro servidores de nomes que um cliente pode usar para configurar registros NS no domínio principal. Esses registros NS podem ser chamados de "registros NS de delegação" ou "registros de delegação”.

Para que a zona hospedada `example.com` do Route 53 se torne legítima, o proprietário legítimo do domínio `example.com` precisa configurar registros de delegação em seu domínio principal ".com" por meio do registrador de domínio. Quando um cliente perde o acesso aos quatro servidores de nomes configurados no domínio principal, por exemplo porque a zona hospedada associada é excluída, isso pode criar um risco que um invasor pode explorar. Isso é chamado de risco de "registros de delegação pendentes".

O Route 53 protege contra o risco de registro de delegação pendentes no caso de uma zona hospedada ser excluída. Após a exclusão, se uma nova zona hospedada estiver sendo criada com o mesmo nome de domínio, o Route 53 verificará se os registros de delegação que apontam para a zona hospedada excluída ainda estão presentes no domínio principal. Se estiverem, o Route 53 impedirá que servidores de nomes sobrepostos sejam atribuídos. Esse é o cenário 1 nos exemplos a seguir.

No entanto, existem outros riscos pendentes de registros de delegação, contra os quais o Route 53 não pode se proteger, conforme detalhado nos cenários 2 a 5 nos exemplos a seguir. Para se proteger contra esse conjunto mais amplo de riscos, verifique se os registros NS principais correspondem ao conjunto de delegação da zona hospedada do Route 53. Você pode encontrar o conjunto de delegações de uma zona hospedada por meio do console do Route 53 ou AWS CLI. Para acessar mais informações, consulte [Listar registros](resource-record-sets-listing.md) ou [get-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/get-hosted-zone.html).

Além disso, habilitar assinatura DNSSEC para uma zona hospedada do Route 53 pode servir como outra camada de proteção além das melhores práticas mencionadas acima. O DNSEC autentica que as respostas do DNS vêm da fonte legítima, protegendo eficazmente contra o risco. Para obter mais informações, consulte [Como configurar a assinatura de DNSSEC no Amazon Route 53](dns-configuring-dnssec.md).

## Exemplos
<a name="protection-from-dangling-dns-examples"></a>

Nos exemplos a seguir, pressupomos que você tenha um domínio `example.com` e seu domínio secundário `child.example.com`. Explicaremos como, em vários cenários, registros de delegação pendentes podem ser criados, como o Route 53 protege seu domínio contra abusos e como mitigar eficazmente os riscos associados a registros de delegação pendentes.

**Cenário 1:**  
Você cria uma zona hospedada `child.example.com` com quatro servidores de nomes: <ns1>, <ns2>, <ns3> e <ns4>. Você configura corretamente a delegação na zona hospedada `example.com`, criando registros NS de delegação para `child.example.com` com quatro servidores de nomes <ns1>,<ns2>, <ns3> e <ns4>. Quando a zona hospedada `child.example.com` é excluída sem remover os registros NS de delegação `example.com`, o Route 53 protege `child.example.com` contra o risco de registros de delegação pendentes, impedindo que <ns1>, <ns2>, <ns3> e <ns4> sejam atribuídos a zonas hospedadas recém-criadas com o mesmo nome de domínio.

**Cenário 2:**  
Semelhante ao cenário 1, mas, desta vez, você exclui a zona hospedada secundária E os registros NS de delegação na zona hospedada `example.com`. Porém, você adiciona novamente os registros NS da delegação <ns1>, <ns2>, <ns3> e <ns4> sem criar uma zona hospedada secundária. Aqui,<ns1>, <ns2>,<ns3> e <ns4> são registros de delegação pendentes, porque o Route 53 remove a retenção, que estava impedindo que <ns1>, <ns2>, <ns3> e <ns4> fossem atribuídos e agora permitirá que zonas hospedadas recém-criadas usem os servidores de nomes acima. Para reduzir o risco, remova <ns1>, <ns2>, <ns3> e <ns4> dos registros de delegação e só os adicione novamente depois que a zona hospedada secundária for criada.

**Cenário 3:**  
Nesse cenário, você cria um conjunto de delegação reutilizável do Route 53 com os servidores de nomes <ns1>, <ns2>, <ns3> e <ns4>. Em seguida, você delega o domínio `example.com` a esses servidores de nomes no domínio principal `.com`. Porém, você não criou a zona hospedada para `example.com` no conjunto de delegação reutilizável. Aqui, <ns1>, <ns2>, <ns3> e <ns4> são registros de delegação pendentes. Para reduzir o risco, crie a zona hospedada usando o conjunto de delegação reutilizável com os servidores de nomes <ns1>, <ns2>, <ns3> e <ns4>. 

**Cenário 4:**  
Você cria zonas hospedadas tanto `child.example.com` com servidores de nomes <ns1><ns2>,<ns3>,, <ns4>e, quanto `grandchild.child.example.com` com servidores de nomes <ns5><ns6><ns7>,, <ns8>e. No entanto, você delega ambos diretamente na `example.com` zona, o que cria um risco de delegação pendente. Para garantir que as delegações sigam a hierarquia de DNS adequada, delegue somente subdomínios por meio de suas zonas principais imediatas. Por exemplo, se você quiser delegar`grandchild.child.example.com`: primeiro delegue `child.example.com` com servidores de nomes<ns1>,, <ns2><ns3>, e <ns4>na `example.com` zona, depois delegue `grandchild.child.example.com` com servidores de nomes<ns5>,,<ns6>, <ns7>e <ns8>na `child.example.com` zona, e remova todas as delegações diretas da zona. `grandchild.child.example.com` `example.com`

**Cenário 5:**  
Você delega um domínio ou subdomínio aos servidores de nomes do Route 53 antes de criar uma zona hospedada correspondente. Isso cria registros de delegação pendentes. Isso é semelhante ao caso do Cenário 3, mas o risco também se aplica quando nenhum conjunto de delegações reutilizável é criado. Por exemplo, você delega o domínio `example.com` aos servidores de nomes<ns1>,<ns2>,<ns3>, e <ns4>no domínio principal`.com`, mas nenhum desses servidores de nomes já foi hospedado`example.com`. O Route 53 não pode se proteger contra isso porque nunca existiu nenhuma zona hospedada para estabelecer uma retenção nesses servidores de nomes para esse nome de domínio. Para reduzir o risco, delegue somente aos servidores de nomes do Route 53 que pertençam a uma zona hospedada pública que você controla.