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á. # Práticas recomendadas do Amazon Route 53 Esta seção apresenta as práticas recomendadas para vários componentes do Amazon Route 53, incluindo: 1. **Práticas recomendadas de DNS:** + Entenda as compensações entre os valores de vida útil (TTL) e capacidade de resposta versus confiabilidade. + Use registros de alias em vez de registros CNAME sempre que possível para melhorar a performance e reduzir os custos. + Configure políticas de roteamento padrão para garantir que todos os clientes recebam uma resposta. + Aproveite o roteamento baseado em latência para minimizar a latência do aplicativo e o roteamento para estabilidade e geolocation/geoproximity previsibilidade. + Verifique a propagação de alterações usando a API `GetChange` para obter fluxos de trabalho automatizados. + Delegue subdomínios da zona principal para obter roteamento consistente. + Evite grandes respostas únicas usando roteamento por resposta com vários valores. 1. **Práticas recomendadas do Resolver:** + Previna loops de roteamento, evitando associar a mesma VPC a uma regra do Resolver e ao endpoint de entrada dessa regra. + Implemente regras de grupo de segurança para reduzir a sobrecarga de rastreamento de conexão e maximizar o throughput das consultas. + Configure endpoints de entrada com endereços IP em várias zonas de disponibilidade para obter redundância. + Esteja ciente dos possíveis ataques de mudança de zona de DNS e entre em contato com o AWS Support se seus endpoints sofrerem limitação. 1. **Práticas recomendadas de verificação de integridade:** + Siga as recomendações para otimizar as verificações de integridade do Amazon Route 53 e garantir o monitoramento confiável dos recursos Seguindo essas práticas recomendadas, você pode otimizar a performance, a confiabilidade e a segurança de sua infraestrutura de DNS, garantindo um roteamento eficiente e eficaz do tráfego para as aplicações e os serviços **Topics** + [Práticas recomendadas do Amazon Route 53 DNS](best-practices-dns.md) + [Melhores práticas para o VPC Resolver](best-practices-resolver.md) + [Práticas recomendadas para verificações de integridade do Amazon Route 53](best-practices-healthchecks.md) # Práticas recomendadas do Amazon Route 53 DNS Siga estas práticas recomendadas para obter os melhores resultados ao usar o serviço de DNS do Amazon Route 53. **Usar as funções do plano de dados para failover de DNS e recuperação de aplicações** Os planos de dados do Route 53, incluindo as verificações de integridade, e o controle de roteamento Amazon Application Recovery Controller (ARC) são distribuídos globalmente e foram criados para fornecer 100% de disponibilidade e funcionalidade, mesmo durante eventos críticos. Integram-se entre si e não dependem da funcionalidade do ambiente de gerenciamento. Embora os ambientes de gerenciamento desses serviços, inclusive seus consoles, sejam geralmente muito confiáveis, são projetados de maneira mais centralizada e priorizam durabilidade e consistência em vez de alta disponibilidade. Para cenários como failover durante a recuperação de desastres, recomendamos que você use recursos como as verificações de integridade e o controle de roteamento ARC do Route 53 que usam a funcionalidade do plano de dados para atualizar o DNS. Para obter mais informações, consulte [Conceitos de planos de dados e de controle](route-53-concepts.md#route-53-concepts-control-and-data-plane) e [Criar mecanismos de recuperação de desastres usando o Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/). **Escolher valores de TTL para registros de DNS** O TTL do DNS é o valor numérico (em segundos) que os resolvedores de DNS usam para decidir por quanto tempo um registro poderá ser armazenado em cache sem fazer outra consulta ao Route 53. Todos os registros de DNS devem ter um TTL especificado. O intervalo recomendado para valores de TTL é de 60 a 172.800 segundos. A escolha de um TTL envolve um equilíbrio entre latência e confiabilidade e capacidade de resposta à mudança. Com um registro mais curto TTLs , os resolvedores de DNS notam atualizações no registro mais rapidamente, pois precisam consultar com mais frequência. Isso aumenta o volume (e o custo) das consultas. Quanto mais se prolonga o TTL, maior é a frequência com que os resolvedores de DNS respondem a consultas do cache, o que geralmente é mais rápido, mais barato e, em algumas situações, mais confiável porque evita consultas na Internet. Não há valor correto, mas vale a pena pensar no que é mais importante para você: capacidade de resposta ou confiabilidade. Fatos a considerar ao definir valores de TTL: + Defina o registro de DNS TTLs pelo período de tempo que você pode esperar até que uma alteração entre em vigor. Isso se aplica principalmente a delegações (conjuntos de registros de NS) ou outros registros que raramente são alterados, como registros MX. Para esses registros, recomenda-se TTLs mais tempo. É comum escolher um valor entre uma hora (3600 s) e um dia (86.400 s). + Para registros que precisam ser alterados como parte de um mecanismo de failover rápido (especialmente registros com verificação de integridade), valores mais baixos TTLs são apropriados. Definir um TTL de 60 ou 120 segundos é comum para esse cenário. + Quando você quiser fazer alterações em entradas críticas de DNS, recomendamos que você encurte temporariamente o. TTLs Em seguida, faça as alterações, observe e reverta rapidamente, se precisar. Depois que as alterações forem finalizadas e estiverem funcionando conforme o esperado, você poderá aumentar o TTL. Para mais informações, consulte [TTL (segundos)](resource-record-sets-values-shared.md#rrsets-values-common-ttl). **Registros CNAME** Os registros CNAME ne DNS são uma forma de apontar um nome de domínio para outro. Se um resolvedor de DNS resolver domain-1.example.com e encontrar um CNAME que aponta para domain-2.example.com, o resolvedor de DNS deverá prosseguir para resolver domain-2.example.com antes de responder. Esses registros são úteis em muitas situações, por exemplo, para garantir consistência quando um site tem mais de um nome de domínio. No entanto, os resolvedores de DNS precisam fazer mais consultas para responder CNAMEs, o que aumenta a latência e os custos. Sempre que possível, uma alternativa mais rápida e mais barata é usar um registro de alias do Route 53. Os registros de aliases permitem que o Route 53 responda com uma resposta direta para AWS recursos (por exemplo, um balanceador de carga) e para outros domínios na mesma zona hospedada. Para obter mais informações, consulte [Encaminhando o tráfego da Internet para seus recursos AWS](routing-to-aws-resources.md). **Roteamento avançado de DNS** + Ao usar roteamento por geolocalização, por geoproximidade ou encaminhamento por latência, sempre defina um padrão, a menos que queira que alguns clientes recebam respostas *sem resposta*. + Para minimizar a latência da aplicação, use o encaminhamento por latência. Esse tipo de dados de roteamento pode ser alterado com frequência. + Para fornecer estabilidade e previsibilidade de roteamento, use roteamento por geolocalização ou por geoproximidade. Para obter mais informações, consulte [Roteamento de localização geográfica](routing-policy-geo.md), [Roteamento por geoproximidade](routing-policy-geoproximity.md) e [Roteamento baseado em latência](routing-policy-latency.md). **Propagação das alterações de DNS** Quando você cria ou atualiza um registro ou zona hospedada usando o console ou a API do Route 53, leva algum tempo para alteração ser refletida na Internet. Isso se chama *propagação de alterações*. Embora normalmente a propagação demore menos de um minuto globalmente, existem atrasos ocasionais, por exemplo, devido a problemas de sincronização com um local ou, em casos raros, problemas dentro do plano de controle central. Se você estiver criando fluxos de trabalho de provisionamento automatizado e for importante aguardar a conclusão da propagação das alterações antes de prosseguir com a próxima etapa do fluxo de trabalho, use a [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API para verificar se as alterações de DNS entraram em vigor (). `Status =INSYNC` **Delegação de DNS** Ao delegar vários níveis de subdomínios no DNS, é importante sempre delegar da zona pai. Por exemplo, se você estiver delegando www.dept.example.com, deverá fazê-lo a partir da zona dept.example.com, e não da zonaexample.com. As delegações de uma zona *avô* para uma zona *filho* pode não funcionar de modo algum ou funcionar apenas de forma inconsistente. Para obter mais informações, consulte [Rotear tráfego para subdomínios](dns-routing-traffic-for-subdomains.md). **Tamanho da resposta do DNS** Evite criar respostas únicas e grandes. Se as respostas forem maiores que 512 bytes, muitos resolvedores DNS devem tentar novamente por TCP em vez de UDP, o que pode reduzir a confiabilidade e levar a respostas mais lentas. Recomendamos usar o roteamento de resposta de vários valores, que escolhe oito endereços IP aleatórios íntegros para manter as respostas dentro do limite de 512 bytes. Para obter mais informações, consulte [Roteamento de resposta com vários valores](routing-policy-multivalue.md) e [DNS Reply Size Test Server](https://www.dns-oarc.net/oarc/services/replysizetest/) (Servidor de teste de tamanho de respostas de DNS). # Melhores práticas para o VPC Resolver Esta seção fornece as melhores práticas para otimizar o Amazon Route 53 VPC Resolver, abordando os seguintes tópicos: 1. **Evitar configurações em loop com os endpoints do Resolver:** + Previna loops de roteamento certificando-se de que a mesma VPC não seja associada a uma regra do Resolver e ao endpoint de entrada dessa regra. + Utilize AWS RAM para compartilhar VPCs entre contas e, ao mesmo tempo, manter as configurações de roteamento adequadas. Para obter mais informações, consulte [Evite configurações de loop com endpoints do Resolver](best-practices-resolver-endpoints.md). 1. **Escalar endpoints do Resolver:** + Implemente regras de grupo de segurança que permitam tráfego com base no estado da conexão para reduzir a sobrecarga de rastreamento de conexão + Siga as regras de grupo de segurança recomendadas para endpoints de entrada e saída do Resolver para maximizar o throughput das consultas. + Monitore as combinações exclusivas de endereço IP e porta que geram tráfego de DNS para evitar limitações de capacidade. Para obter mais informações, consulte [Escalabilidade de endpoints do Resolver](best-practices-resolver-endpoint-scaling.md). 1. **Alta disponibilidade de endpoints do Resolver:** + Crie endpoints de entrada com endereços IP em, pelo menos, duas zonas de disponibilidade para garantir redundância. + Provisione interfaces de rede adicionais para garantir a disponibilidade durante a manutenção ou os picos de tráfego Para obter mais informações, consulte [Alta disponibilidade de endpoints do Resolver](best-practices-resolver-endpoint-high-availability.md). 1. **Prevenir ataques de deslocamento de zona DNS:** + Fique alerta a possíveis ataques de deslocamento de zona DNS, nos quais invasores tentam recuperar todo o conteúdo de zonas DNS assinadas por DNSSEC. + Se seus endpoints sofrerem limitação devido à suspeita de caminhada por zona, entre em contato com o AWS Support para obter ajuda. Para obter mais informações, consulte [Deslocamento de zona DNS](best-practices-resolver-zone-walking.md). Seguindo essas melhores práticas, você pode otimizar o desempenho, a escalabilidade e a segurança de suas implantações do VPC Resolver, garantindo uma resolução de DNS confiável e eficiente para seus aplicativos e recursos. # Evite configurações de loop com endpoints do Resolver Não associe a mesma VPC a uma regra do Resolver e seu endpoint de entrada (seja um destino direto do endpoint, seja por meio de um servidor DNS on-premises). Quando o endpoint de saída em uma regra do Resolver apontar para um endpoint de entrada que compartilha uma VPC com a regra, ele pode causar um loop em que a consulta é transmitida continuamente entre os endpoints de entrada e de saída. A regra de encaminhamento ainda pode ser associada a outras VPCs que são compartilhadas com outras contas usando AWS Resource Access Manager (AWS RAM). Zonas hospedadas privadas associadas ao hub, ou a uma VPC central, ainda serão resolvidas de consultas para endpoints de entrada porque uma regra do resolvedor de encaminhamento não altera essa resolução. # Escalabilidade de endpoints do Resolver Os grupos de segurança de endpoint do Resolver usam o acompanhamento da conexão para coletar informações sobre o tráfego de entrada e saída dos endpoints. Cada interface do endpoint tem um número máximo de conexões que podem ser rastreadas, e um alto volume de consultas de DNS pode exceder as conexões e causar controle de utilização e perda de consulta. O rastreamento de conexão AWSé o comportamento padrão para monitorar o estado do tráfego que flui pelos grupos de segurança (SGs). Usar o rastreamento de conexão SGs reduzirá a taxa de transferência do tráfego, no entanto, você pode implementar conexões não rastreadas para reduzir a sobrecarga e melhorar o desempenho. Para obter mais informações, consulte [Conexões não rastreadas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections). Se o rastreamento de conexões for imposto por meio de regras restritivas de grupo de segurança ou se as consultas forem roteadas pelo Network Load Balancer (consulte [Conexões rastreadas automaticamente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking)), o máximo geral de consultas por segundo por endereço IP para um endpoint pode ser tão baixo quanto 1.500. **Recomendações sobre regras de grupo de segurança de entrada e saída para o endpoint de entrada do Resolver** **** | | | **Regras de entrada** | | --- | | Tipo de protocolo | Número da porta | IP de origem | | TCP | 53 | 0.0.0.0/0 | | UDP | 53 | 0.0.0.0/0 | | **Regras de saída** | | --- | | Tipo de protocolo | Número da porta | IP de destino | | TCP | Todos | 0.0.0.0/0 | | UDP | Todos | 0.0.0.0/0 | **Recomendações sobre regras de grupo de segurança de entrada e saída para o endpoint de saída do Resolver** **** | | | **Regras de entrada** | | --- | | Tipo de protocolo | Número da porta | IP de origem | | TCP | Todos | 0.0.0.0/0 | | UDP | Todos | 0.0.0.0/0 | | **Regras de saída** | | --- | | Tipo de protocolo | Número da porta | IP de destino | | TCP | 53 | 0.0.0.0/0 | | UDP | 53 | 0.0.0.0/0 | **nota** **Porta do grupo de segurança: requisitos necessários:** Os **endpoints de entrada** exigem regras de entrada que permitam que o TCP e o UDP na porta 53 recebam consultas ao DNS da sua rede. Regras de saída podem permitir todas as portas, pois o endpoint pode precisar responder às consultas de várias portas de origem. **Endpoints de saída** exigem regras de saída que permitam o acesso via TCP e UDP às portas que você está usando para consultas ao DNS na sua rede. A porta 53 é mostrada no exemplo acima porque é a porta de DNS mais comum, mas sua rede pode usar portas diferentes. Regras de entrada podem permitir que todas as portas acomodem as respostas dos seus servidores de DNS. **Endpoints do Resolver de entrada** Para clientes que usam um endpoint do Resolver de entrada, a capacidade da interface de rede elástica será afetada se você tiver mais de 40.000 combinações exclusivas de endereços IP e portas gerando o tráfego DNS. # Alta disponibilidade de endpoints do Resolver Quando você cria seus endpoints de entrada do VPC Resolver, o Route 53 exige que você crie pelo menos dois endereços IP para os quais os resolvedores de DNS da sua rede encaminharão as consultas. Também é necessário especificar o endereço IP em pelo menos duas zonas de disponibilidade para obter redundância. Se você precisar que mais de um endpoint da interface de rede elástica esteja disponível o tempo todo, recomendamos que você crie pelo menos uma interface de rede a mais do que a necessária, para garantir que você tenha capacidade adicional disponível para lidar com possíveis picos de tráfego. A interface de rede adicional também garante a disponibilidade durante as operações de serviço, como manutenção ou atualizações. Para obter mais informações, consulte este artigo detalhado do blog: [Como obter alta disponibilidade de DNS com endpoints Resolver](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/) e. [Valores especificados ao criar ou editar endpoints de entrada](resolver-forwarding-inbound-queries-values.md) # Deslocamento de zona DNS Um ataque de deslocamento de zona DNS tenta obter todo o conteúdo de zonas DNS assinadas pelo DNSSEC. Se a equipe do VPC Resolver detectar um padrão de tráfego que corresponda aos gerados quando as zonas DNS são percorridas em seu endpoint, a equipe de serviço limitará o tráfego em seu endpoint. Como consequência, você pode observar uma porcentagem alta de suas consultas de DNS expirando. Se você observar uma capacidade reduzida em seus endpoints e acreditar que o endpoint foi controlado erroneamente, acesse home\$1/ para https://console.aws.amazon.com/support/ criar um caso de suporte. # Práticas recomendadas para verificações de integridade do Amazon Route 53 Uma configuração de verificação de integridade eficaz é essencial para manter uma infraestrutura altamente disponível e resiliente. Veja a seguir algumas práticas recomendadas a serem consideradas ao configurar e gerenciar verificações de integridade do Amazon Route 53: 1. **Usar endereços IP elásticos para os endpoints de verificação de integridade:** + Utilize endereços IP elásticos para os endpoints de verificação de integridade para garantir monitoramento consistente. + Se você não for mais usar uma instância do Amazon EC2, lembre-se de excluir todas as verificações de integridade associadas para evitar possíveis riscos de segurança ou comprometimento de dados. Para obter mais informações, consulte [Valores que você especifica quando cria ou atualiza uma verificação de integridade](health-checks-creating-values.md). 1. **Configurar intervalos de verificação de integridade apropriados:** + Defina intervalos de verificação de integridade com base nos requisitos da aplicação e na criticidade dos recursos monitorados. + Intervalos mais curtos oferecem detecção de falhas mais rápida, mas podem aumentar os custos e a carga dos recursos do Route 53. + Intervalos mais longos reduzem os custos e a carga dos recursos, mas podem atrasar a detecção de falhas. Para obter mais informações, consulte [Configuração avançada (somente a opção "Monitorar um endpoint")](health-checks-creating-values.md#health-checks-creating-values-advanced). 1. **Implementar notificações de alarme:** + Configure CloudWatchalarms a Amazon para receber notificações quando as verificações de saúde falharem ou se recuperarem. + Defina limites de alarme apropriados com base nos requisitos da aplicação e no comportamento esperado dos recursos. + Integre as notificações aos processos de monitoramento e resposta a incidentes. Para obter mais informações, consulte [Monitorando verificações de saúde usando CloudWatch](monitoring-health-checks.md). 1. **Utilizar as regiões de verificação de integridade estrategicamente:** + Escolha regiões de verificação de integridade com base na distribuição geográfica dos usuários e dos recursos. + Considere usar várias regiões de verificação de integridade para os recursos essenciais para aumentar a confiabilidade e reduzir o impacto das interrupções nas regiões. 1. **Monitorar os logs e as métricas de verificação de integridade:** + Analise regularmente os registros e CloudWatch métricas de verificação de integridade do Route 53 para identificar possíveis problemas ou gargalos de desempenho + Analise os motivos de falha nas verificações de integridade e tome as medidas apropriadas para resolver os problemas subjacentes. 1. **Implementar estratégias de failover e failback:** + Aproveite as políticas de roteamento por failover do Route 53 para, em caso de falha, rotear automaticamente o tráfego para recursos íntegros. + Planeje e teste os processos de failover e failback para garantir uma transição sem problemas durante interrupções e recuperação. Para obter mais informações, consulte [Configurar failover de DNS](dns-failover-configuring.md). 1. **Revisar e atualizar regularmente as verificações de integridade:** + Atualize os endpoints, os intervalos e os limites de alarme da verificação de integridade conforme necessário para manter o monitoramento e a performance ideais. Seguindo essas práticas recomendadas, você pode aproveitar bem as verificações de integridade do Amazon Route 53 para monitorar a integridade e a disponibilidade de nossos recursos, garantindo uma infraestrutura confiável de alta performance para aplicações e serviços.