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, inclusive verificações de integridade, e o controle de roteamento do Amazon Route 53 Application Recovery Controller são distribuídos globalmente e foram projetados para fornecer 100% de disponibilidade e funcionalidade, mesmo durante eventos graves. 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 recuperação de desastres, recomendamos usar recursos como as verificações de integridade do Route 53 e o controle de roteamento do Route 53 ARC que contam com a funcionalidade de plano de dados para atualizar o DNS. Para obter mais informações, consulte Conceitos de planos de dados e de controle e Criar mecanismos de recuperação de desastres usando o 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 TTLs mais curtos em um registro, os resolvedores de DNS perceberão atualizações no registro mais rapidamente, pois deverão 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 TTLs de registro de DNS pelo tempo que você pode esperar para 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, TTLs mais longos são recomendados. É 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 (principalmente registros com verificação de integridade), convém usar TTLs mais curtos. Definir um TTL de 60 ou 120 segundos é comum para esse cenário.

• Quando quiser fazer alterações em entradas DNS críticas, recomendamos que você reduza temporariamente os 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).

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.

Porém, os resolvedores de DNS devem fazer mais consultas para responder aos 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 ter mais informações, consulte Encaminhando o tráfego da Internet para seus recursos AWS.

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, Roteamento por geoproximidade e Roteamento baseado em latência.

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 GetChangeAPI 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 ter mais informações, consulte Rotear tráfego para subdomínios.

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 e DNS Reply Size Test Server (Servidor de teste de tamanho de respostas de DNS).