Perguntas frequentes do Amazon Route 53

Sim. Anycast é uma tecnologia de rede e de direcionamento que ajuda que as consultas do DNS feitas pelos usuários sejam respondidas com base na localização ideal do Route 53 considerando as condições de rede. Como resultado, os usuários obtêm alta disponibilidade e um desempenho aprimorado com o Route 53.

Cada conta do Amazon Route 53 está limitada a um máximo de 500 zonas hospedadas e 10.000 conjuntos de registros de recursos por zona hospedada. Preencha a nossa solicitação de limite maior e responderemos em até dois dias úteis.

O Route 53 fornece suporte para a importação de arquivos da zona DNS padrão, que podem ser exportados de muitos provedores de DNS, bem como de um software de servidor DNS padrão como o BIND. Para zonas hospedadas recém-criadas, bem como para zonas hospedadas existentes que estejam vazias, com exceção dos registros de NS e SOA padrão, você pode colar seu arquivo de zona diretamente no console do Route 53, e ele cria automaticamente os registros em sua zona hospedada. Para começar a importação de arquivos de zona, leia nosso passo a passo no Guia do Desenvolvedor do Amazon Route 53.

Sim. A criação de várias zonas hospedadas permite que você verifique sua definição de DNS em um ambiente de "teste" e, em seguida, replique essas definições em uma zona hospedada de "produção". Por exemplo, a zona hospedada Z1234 poderá ser sua versão de teste de example.com, hospedada nos servidores designados como ns-1, ns-2, ns-3 e ns-4. Da mesma forma, a zona hospedada Z5678 poderá ser a versão de produção de example.com, hospedada em ns-5, ns-6, ns-7 e ns-8. Como cada zona hospedada tem um conjunto virtual de servidores designados com aquela zona, o Route 53 responderá as consultas do DNS com relação a example.com de forma diferente, dependendo de qual servidor designado você enviar ao DNS para consulta.

O Amazon Route 53 é um serviço DNS autoritário e não fornece hospedagem para sites. No entanto, você pode usar o Amazon Simple Storage Service (Amazon S3) para hospedar um site estático. Para hospedar um site dinâmico ou outras aplicações Web, você pode usar o Amazon Elastic Compute Cloud (Amazon EC2), que fornece flexibilidade, controle e economias de custo significativas em vez de soluções de hospedagem na web tradicionais. Saiba mais sobre o Amazon EC2 aqui. Para sites estáticos e dinâmicos, você pode fornecer entrega de baixa latência para seus usuários finais globais com o Amazon CloudFront. Saiba mais sobre o Amazon CloudFront aqui.

No momento, o Amazon Route 53 é compatível com os seguintes tipos de registro DNS:

• A (address record – registro de endereço)
• AAAA (IPv6 address record – registro de endereço IPv6)
• CNAME (canonical name record – registro de nome canônico)
• Certification authority authorization (CAA – Autorização de autoridade de certificação)
• Mail exchange record (MX – Registro de troca de e-mail)
• NAPTR (registro de Name Authority Pointer)
• NS (name server record – registro do servidor do nome)
• PTR (pointer record – registro do apontador)
• SOA (start of authority record – registro de início da autoridade)
• SPF (sender policy framework – estrutura da política do remetente)
• SRV (service locator – localizador do serviço)
• TXT (text record – registro de texto)
• O Amazon Route 53 também oferece registros de alias, que são uma extensão específica do Amazon Route 53 para DNS. É possível criar registros de alias para rotear o tráfego para recursos da AWS selecionados, incluindo load balancers do Amazon Elastic Load Balancing, distribuições do Amazon CloudFront, ambientes do AWS Elastic Beanstalk, Gateways de API, endpoints da interface da VPC e buckets do Amazon S3 configurados como websites. O registro de alias geralmente tem um tipo de A ou AAAA, mas funciona como um registro CNAME. Usando um registro de alias, você pode mapear o nome do seu registro (example.com) para o nome DNS de um recurso da AWS (elb1234.elb.amazonaws.com). Os resolvedores veem o registro A ou AAAA e o endereço IP do recurso da AWS.

Prevemos a adição de outros tipos de registro no futuro.

Sim. Para facilitar ainda mais a definição das configurações do DNS para seu domínio, o Amazon Route 53 permite usar entradas com curinga para todos os tipos de registro, exceto os registros NS. Uma entrada de wildcard é um registro em uma zona do DNS que corresponderá às solicitações de qualquer nome de domínio baseado na configuração definida. Por exemplo, um registro DNS de wildcard, como *.example.com, corresponderá as consultas para www.example.com e subdominio.example.com.

O tempo de armazenamento de uma resposta em cache pelo resolvedor DNS é determinado por um valor chamado período de ativação (TTL) associado a todo registro. O Amazon Route 53 não tem um TTL padrão para nenhum tipo de registro. Você sempre deve especificar um TTL para cada registro de forma que os resolvedores do DNS possam armazenar em cache os registros DNS durante o período especificado por meio do TTL.

Sim. Você também pode usar os registros Alias para mapear seus subdomínios (www.example.com, pictures.example.com, etc.) para os load balancers do ELB, distribuições do CloudFront ou buckets de sites do S3.

Sim. Uma alteração transacional ajuda a assegurar que a mudança seja consistente, confiável e independente de outras alterações. O Amazon Route 53 foi projetado para que as alterações sejam totalmente concluídas em qualquer servidor DNS individual, não em todos. Isso ajuda a assegurar que as consultas DNS sempre sejam respondidas de forma consistente, o que é importante ao fazer alterações como alternar entre servidores de destino. Usando a API, cada chamada ao ChangeResourceRecordSets retorna um identificador que pode ser usado para acompanhar o status da alteração. Assim que o status for informado como INSYNC, a alteração terá sido desempenhada em todos os servidores DNS do Route 53.

Sim. A associação de vários endereços IP com um único registro com frequência é usada para balancear a carga de servidores da Web distribuídos geograficamente. O Amazon Route 53 permite que você liste vários endereços IP para um registro A e responda às solicitações do DNS com a lista de todos os endereços IP configurados.

O Amazon Route 53 foi criado para propagar atualizações feitas nos registros DNS à sua rede mundial de servidores DNS autoritários em 60 segundos em condições normais. Uma alteração é propagada mundialmente de forma bem-sucedida quando a chamada de API retorna uma lista de status INSYNC.

Os resolvedores de DNS armazenados em cache estão fora do controle do serviço Amazon Route 53 e armazenarão em cache os conjuntos de registros de recursos de acordo com seu período de ativação (TTL). O status INSYNC ou PENDING de uma alteração refere-se somente ao estado dos servidores DNS autoritários do Route 53.

Sim. É possível usar o AWS CloudTrail para registrar o histórico de chamadas de APIs do Route 53. Consulte a página de produto do CloudTrail para começar a usar.

Não. Recomendamos não usar os logs do CloudTrail para reverter alterações nas suas zonas hospedadas, pois a reconstrução do histórico de alterações da sua zona usando os logs do CloudTrail pode ser incompleta.

Os logs do AWS CloudTrail podem ser usados para fins de análise de segurança, rastreamento de alteração de recursos e auditoria de conformidade.

Sim. Você pode habilitar a assinatura DNSSEC para as zonas hospedadas públicas existentes e novas e habilitar a validação DNSSEC para o Amazon Route 53 Resolver. Além disso, o Amazon Route 53 permite DNSSEC no registro de domínios.

Sim. O Amazon Route 53 é compatível com registros IPv6 de encaminhamento (AAAA) e reverso (PTR). O serviço do Amazon Route 53 em si também está disponível em IPv6. Resolvedores recursivos de DNS em redes IPv6 podem usar transporte IPv4 ou IPv6 para enviar consultas de DNS no Amazon Route 53. As verificações de saúde do Amazon Route 53 também são compatíveis com o monitoramento de endpoints usando o protocolo IPv6.

Sim. O Amazon Route 53 oferece um tipo especial de registro chamado de registro “Alias” que permite mapear o nome DNS do seu apex de zona (example.com) para o nome DNS do seu load balancer ELB (como my-loadbalancer-1234567890.us-west -2.elb.amazonaws.com). Os endereços IP associados aos load balancers podem ser alterados a qualquer momento devido à ampliação, à redução ou às atualizações de software. O Route 53 responde a cada solicitação de um registro Alias com um ou mais endereços de IP para o load balancer. O Route 53 oferece suporte a registros de alias para três tipos de load balancers: Application Load Balancer, Network Load Balancer e Classic Load Balancer. Não há custo adicional para consultas a registros Alias que são mapeados para os load balancers do AWS ELB. Essas consultas estão listadas como ''Intra-AWS-DNS-Queries'' no relatório de uso do Amazon Route 53.

Sim. O Amazon Route 53 oferece um tipo especial de registro chamado de registro "Alias" que permite o mapeamento do nome DNS (example.com) do apex da sua zona para o seu bucket de site do Amazon S3 (ou seja, example.com.s3-website-us-west-2.amazonaws.com). Os endereços IP associados aos endpoints de site do Amazon S3 podem ser alterados a qualquer momento devido à expansão, à diminuição ou a atualizações do software. O Route 53 responde a cada solicitação de um registro Alias com um endereço IP para o bucket. O Route 53 não cobra consultas de registros Alias que são mapeados para um bucket do S3 configurado como um site. Essas consultas estão listadas como ''Intra-AWS-DNS-Queries'' no relatório de uso do Amazon Route 53.

Sim. O Amazon Route 53 oferece um tipo especial de registro chamado de registro "Alias" que permite o mapeamento do nome DNS (example.com) do apex de zona para a sua distribuição do Amazon CloudFront (por exemplo, d123.cloudfront.net). Os endereços IP associados com os endpoints do Amazon CloudFront variam com base na localização do seu usuário final (para direcionar o usuário final para o ponto de presença do CloudFront mais próximo) e podem mudar a qualquer momento devido à expansão, diminuição ou atualizações do software. O Route 53 responde a cada solicitação de um registro Alias com o(s) endereço(s) IP para a distribuição. O Route 53 não cobra consultas aos registros Alias mapeados para uma distribuição do CloudFront. Essas consultas estão listadas como ''Intra-AWS-DNS-Queries'' no relatório de uso do Amazon Route 53.

Sim. O Amazon Route 53 oferece um tipo especial de registro chamado de registro "Alias" que permite o mapeamento do nome de DNS do apex de zona (example.com) para o nome DNS do AWS Elastic Beanstalk (ou seja, example.elasticbeanstalk.com). Os endereços IP associados aos ambientes do AWS Elastic Beanstalk podem ser alterados a qualquer momento para alteração de escala ou atualizações de software. O Route 53 responde a cada solicitação de registro Alias com um ou mais endereços de IP do ambiente. As consultas a registros Alias mapeados ao AWS Elastic Beanstalk são gratuitas. Essas consultas estão listadas como ''Intra-AWS-DNS-Queries'' no relatório de uso do Amazon Route 53.

Sim. O Amazon Route 53 oferece um tipo especial de registro chamado de registro "Alias" que permite o mapeamento do nome DNS (example.com) do apex da sua zona para o nome DNS do Amazon API Gateway (ou seja, api-id.execute-api.region.amazonaws.com/stage). Os endereços IP associados ao Amazon API Gateway podem ser alterados a qualquer momento devido à expansão, à diminuição ou a atualizações do software. O Route 53 responde a cada solicitação de registro Alias com um ou mais endereços de IP do API Gateway. Não há cobranças adicionais para consultas a registros Alias mapeados a Amazon API Gateways. Essas consultas estão listadas como “Intra-AWS-DNS-Queries” no relatório de uso do Route 53.

Sim. O Amazon Route 53 oferece um tipo especial de registro chamado de registro "Alias" que permite o mapeamento do nome DNS (example.com) do apex da sua zona para o nome DNS do Amazon VPC endpoint (ou seja, vpce-svc-03d5ebb7d9579a2b3.us-east-1.vpce.amazonaws.com). Os endereços IP associados aos Amazon VPC endpoints podem ser alterados a qualquer momento devido à expansão, à diminuição ou a atualizações do software. O Route 53 responde a cada solicitação de registro Alias com um ou mais endereços de IP do VPC endpoint. Não há cobranças adicionais para consultas a registros Alias mapeados a Amazon VPC endpoints. Essas consultas estão listadas como ''Intra-AWS-DNS-Queries'' no relatório de uso do Amazon Route 53.

Para sites entregues através do Amazon CloudFront ou sites estáticos hospedados no Amazon S3, você pode usar o serviço Amazon Route 53 para criar um registro Alias para seu domínio que aponta para a distribuição do CloudFront ou bucket do site do S3. Para buckets do S3 não configurados para hospedar sites estáticos, você pode criar um registro CNAME para seu domínio e o nome do bucket S3. Em todos os casos, observe que também será necessário configurar o bucket do S3 ou a distribuição do CloudFront, respectivamente, com a entrada do nome alternativo de domínio para estabelecer totalmente o Alias entre o nome de domínio e o nome de domínio da AWS para o bucket ou distribuição.

Para distribuições do CloudFront e buckets do S3 configurados para hospedar sites estáticos, recomendamos criar um registro "Alias" que mapeie para sua distribuição do CloudFront ou bucket do site do S3 em vez de usar CNAMEs. Os registros Alias têm duas vantagens: Primeira, ao contrário de CNAMEs, você pode criar um registro Alias para seu apex de zona (p. ex., example.com, em vez de www.example.com), e, segunda, as consultas a registros Alias são gratuitas.

Quando conjuntos de registros de recursos são alterados no Amazon Route 53, o serviço propaga atualizações feitas por você nos seus registros de DNS para a rede mundial de servidores DNS autorizados. Caso você teste o registro antes da propagação ser concluída, será possível ver um valor antigo ao usar os utilitários dig ou nslookup. Além disso, os resolvedores de DNS na Internet estão fora do controle do serviço Amazon Route 53 e armazenarão em cache os conjuntos de registros de recursos de acordo com sua vida útil (TTL), o que significa que o comando dig/nslookup poderá retornar um valor armazenado em cache. Você também deve verificar se o registrador de nomes de domínio está usando os servidores de nome na hosted zone do Amazon Route 53. Caso não esteja, o Amazon Route 53 não estará autorizado para fazer consultas no seu domínio.

Sim. O Weighted Round Robin permite que você designe ponderações aos conjuntos de registros de recursos para especificar a frequência com a qual diferentes respostas são correspondidas. Talvez você queira usar essa capacidade para desempenhar o teste A/B e enviar uma pequena porção do tráfego para um servidor no qual você fez uma alteração no software. Por exemplo, suponha que você tenha dois conjuntos de registros associados a um nome DNS – um com peso 3 e um com peso 1. Nesse caso, em 75% do tempo o Route 53 retornará o conjunto de registros com peso 3 e em 25% do tempo o Route 53 retornará o conjunto de registros com peso 1. Os pesos podem ser qualquer número entre 0 e 255.

O LBR (Latency Based Routing) é um novo recurso do Amazon Route 53 que ajuda a melhorar a performance do seu aplicativo para um público mundial. Você pode executar aplicativos em várias regiões da AWS e o Amazon Route 53, utilizando dezenas de pontos de presença em todo o mundo, irá rotear usuários finais para a região AWS que oferece mais baixa latência.

Você pode começar a usar o novo recurso de LBR do Amazon Route 53 com rapidez e facilidade por meio do Console de Gerenciamento da AWS ou de uma simples API. Basta criar um conjunto de registros que inclua os endereços IP ou nomes do ELB de vários endpoints da AWS e marcar esse conjunto de registros como habilitado para LBR, da mesma forma que se marca um conjunto de registros ponderado. O Amazon Route 53 fica encarregado do resto – determinar o melhor ponto de extremidade para cada solicitação e roteamento e os usuários adequadamente, da mesma forma que o Amazon CloudFront, o serviço de transferência de conteúdo global da Amazon, faz. Você pode saber mais sobre como utilizar o Latency Based Routing no Guia do Desenvolvedor do Amazon Route 53.

Assim como todos os serviços da AWS, não há tarifas iniciais ou compromissos a longo prazo para utilizar o Amazon Route 53 e o LBR. Os clientes pagam somente pelas hosted zones e consultas que realmente utilizam. Visite a página de definição de preço do Amazon Route 53para obter detalhes sobre a definição de preço para consultas de Latency Based Routing.

O Geo DNS do Route 53 permite balancear a carga, direcionado solicitações para endpoints específicos de acordo com a localização geográfica onde a solicitação foi gerada. O Geo DNS possibilita personalizar conteúdo localizado, como a apresentação de páginas de detalhes no idioma correto ou a restrição de distribuição de conteúdo aos mercados que você licenciou. Ele permite balancear a carga entre endpoints de forma previsível e fácil de gerenciar, garantindo que cada local de usuário final seja encaminha consistentemente ao mesmo endpoint. O Geo DNS oferece três níveis de granularidade geográfica: Continente, país e estado. Além disso, oferece um registro global que é retornado quando o local do usuário final não corresponde a nenhum dos registros de Geo DNS específicos criados. Você também pode combinar o Geo DNS com outros tipos de roteamento, como Latency Based Routing e failover de DNS, para possibilitar diversas arquiteturas de baixa latência e tolerantes a falhas. Para obter informações sobre como configurar vários tipos de roteamento, consulte a documentação do Amazon Route 53.

Você pode começar a usar o recurso Geo DNS do Amazon Route 53 de modo fácil e rápido por meio do Console de Gerenciamento da AWS ou da API do Route 53. Basta criar um conjunto de registros e especificar os valores aplicáveis para esse tipo de conjunto de registros, marcar esse conjunto de registros como um conjunto de registros ativado para o Geo DNS e selecionar a região geográfica (global, continente, país ou estado) à qual você deseja aplicar o registro. Você pode saber mais sobre como utilizar o Geo DNS no Amazon Route 53 Developer Guide.

Sim. Recomendamos que você configure um registro global para garantir que o Route 53 possa responder consultas de DNS de todos os locais possíveis, mesmo que você tenha criado registros específicos para cada continente, país ou estado onde espera que seus usuários finais estejam localizados. O Route 53 retornará o valor contido no registro global nos seguintes casos:

A consulta de DNS vem de um endereço IP não reconhecido pelo banco de dados de IPs do Geo do Route 53.

A consulta de DNS vem de um local não incluído em nenhum dos registros específicos do Geo DNS que você criou.

Sim, você pode ter registros de Geo DNS para regiões geográficas sobrepostas (p.ex., um continente e países dentro desse continente, ou um país e estados dentro desse país). Para cada local de usuário final, o Route 53 retornarão o registro de Geo DNS mais específico que inclua esse local. Em outras palavras, para um determinado local de usuário final o Route 53 retornará primeiro um registro de estado. Se nenhum registro de estado for encontrado, o Route 53 retornará um registro de país. Se nenhum registro de país for encontrado, o Route 53 retornará um registro de continente. Finalmente, se nenhum registro de continente for encontrado o Route 53 retornará o registro global.

Assim como todos os serviços da AWS, não há tarifas iniciais ou compromissos de longo prazo para utilizar o Amazon Route 53 e o Geo DNS. Os clientes pagam somente pelas hosted zones e consultas que realmente utilizam. Visite a página de definição de preços do Amazon Route 53 para obter detalhes sobre a definição de preços das consultas do Geo DNS.

O Geo DNS baseia suas decisões de roteamento na localização geográfica das solicitações. Em alguns casos, a geografia é um bom proxy para a latência, mas em determinadas situações ela não funciona bem. O Roteamento baseado em latência utiliza medidas da latência entre as redes do visualizador e datacenters da AWS. Essas medidas são usadas para determinar para qual endpoint os usuários deverão ser direcionados.

Se a sua meta é minimizar a latência do usuário final, nós recomendamos usar o Latency Based Routing. Se você tiver requisitos de conformidade, localização ou outros casos de uso que exijam o roteamento estável de uma região específica para um endpoint específico, nós recomendamos o uso do Geo DNS.

Agora, o Route 53 oferece suporte a respostas com vários valores para consultas de DNS. Embora esse recurso não substitua um load balancer, a capacidade de retornar vários endereços IP com integridade verificável como resposta a consultas de DNS é uma forma de usar o DNS para aprimorar a disponibilidade e o balanceamento de carga. Se você quiser encaminhar tráfego aleatoriamente para diversos recursos, como servidores web, poderá criar um registro de resposta com vários valores para cada recurso e, opcionalmente, associar uma verificação de integridade do Amazon Route 53 a cada registro. O Amazon Route 53 oferece suporte a até oito registros de integridade como resposta a cada consulta de DNS.

O fluxo de tráfego do Amazon Route 53 é um serviço de gerenciamento de tráfego global fácil de usar e econômico. Com o fluxo de tráfego do Amazon Route 53, você pode melhorar o desempenho e a disponibilidade do seu aplicativo para usuários finais executando vários endpoints em todo o mundo, usando o fluxo de tráfego do Amazon Route 53 para conectar seus usuários ao melhor endpoint com base na latência, geografia e integridade do endpoint. O fluxo de tráfego do Amazon Route 53 torna fácil para os desenvolvedores criarem políticas que roteiem o tráfego com base nas restrições que consideram mais importantes, incluindo latência, integridade do endpoint, carga, geoproximidade e geografia. Os clientes podem personalizar esses modelos ou criar políticas do zero por meio de um criador de políticas visuais fácil de usar no Console de Gerenciamento da AWS.

Uma política de tráfego é um conjunto de regras que você define para rotear as solicitações dos usuários finais para um dos seus endpoints de aplicações. Você pode criar uma política de tráfego usando o criador de política visual na seção de fluxo de tráfego do Amazon Route 53 no console do Amazon Route 53. Você também pode criar políticas de tráfego como arquivos texto formatados como JSON e carregar essas políticas usando a API do Route 53, a ILC da AWS ou os vários SDKs da AWS.

Por si só, uma política de tráfego não afeta como os usuários finais são roteados para um aplicativo, pois ela ainda não está associada ao nome de DNS do aplicativo (como www.example.com). Para começar a usar o fluxo de tráfego do Amazon Route 53 para rotear o tráfego para sua aplicação usando a política de tráfego criada, você cria um registro de política que está associado com a política de tráfego, com o nome de DNS adequado em uma zona hospedada do Amazon Route 53 de sua propriedade. Por exemplo, se você deseja usar uma política de tráfego que você chamou de my-first-traffic-policy para gerenciar o tráfego para o seu aplicativo em www.example.com, você cria um registro de política para www.example.com na zona hospedada example.com e escolhe my-first-traffic-policy como a política de tráfego.

Os registros de política são visíveis tanto nas seções de fluxo de tráfego do Amazon Route 53 quanto de hosted zone do Amazon Route 53 do console do Amazon Route 53.

Sim. Você pode reutilizar uma política para gerenciar mais de um nome de DNS de uma das duas maneiras. Primeiro, você pode criar registros de política adicional usando a política. Observe que há uma cobrança adicional para usar esse método, pois cada registro de política que você criar será cobrado.

O segundo método é criar um registro de política usando a política e, em seguida, para cada nome de DNS adicional que você deseja gerenciar usando a política, você cria um registro de CNAME padrão apontando para o nome de DNS do registro de política que você criou. Por exemplo, se você criar um registro de política para example.com, você pode então criar registros de DNS para www.example.com, blog.example.com e www.example.net com um valor de CNAME de example.com para cada registro. Observe que este método não é possível para registros no apex de zona, como example.net, example.org ou example.co.uk (sem www ou outro subdomínio na frente do nome de domínio). Para registros no apex de zona, você deve criar um registro de política usando sua política de tráfego.

Sim, é possível criar um registro Alias apontando para um nome de DNS que está sendo gerenciado por uma política de tráfego.

Não. Nós cobramos apenas por registros de política; não há cobrança pela criação da política de tráfego em si.

Você é cobrado por registro de política. Um registro de política representa a aplicação de uma política de fluxo de tráfego em um nome de DNS específico (como www.exempo.com) para poder usar a política de tráfego para gerenciar como as solicitações para esse nome de DNS são respondidas. A cobrança é mensal e rateada para meses parciais. Não há alteração às políticas de tráfego que não estejam associadas com um nome de DNS através de um registro de política. Para obter detalhes sobre a definição de preço, consulte a Página de definição de preço do Amazon Route 53.

O fluxo de tráfego oferece suporte a todas as políticas de roteamento de DNS do Amazon Route 53, incluindo latência, integridade de endpoints, respostas com vários valores, weighted round robin e geo. Além disso, o fluxo de tráfego também oferece suporte ao roteamento baseado em geoproximidade com preferências de tráfego.

Quando você cria uma política de fluxo de tráfego, pode especificar uma região da AWS (se está usando recursos da AWS) ou a latitude e longitude de cada endpoint. Por exemplo, suponha que você tem duas instâncias EC2 nas regiões da AWS Leste dos EUA (Ohio) e Oeste dos EUA (Oregon). Quando um usuário em Seattle visita o seu site, o roteamento por geoproximidade roteará a consulta de DNS às instâncias do EC2 na região Oeste dos EUA (Oregon), pois é a mais próxima em termos geográficos. Para obter mais informações, consulte a documentação sobre roteamento por geoproximidade.

A alteração do valor de preferências de geoproximidade em um endpoint aumenta ou diminui a área de onde o Route 53 direciona o tráfego para um recurso. As preferências de geoproximidade não podem prever com precisão o fator de carga, pois uma pequena mudança no tamanho das áreas geográficas pode incluir ou excluir grandes áreas geográficas que geram um grande número de consultas. Para informações adicionais, consulte nossa documentação.

A partir de hoje, as preferências somente poderão ser aplicadas a regras de geoproximidade. 

O DNS privado é um recurso do Route 53 que permite ter DNS autoritário dentro das VPCs sem expor registros de DNS (incluindo o nome do recurso e seus endereços IP) à Internet.

Sim você pode gerenciar endereços IP privados com nuvens privadas virtuais (VPCs) usando o recurso de DNS privado do Amazon Route 53. Com o DNS privado, você pode criar uma zona hospedada privada e o Route 53 retornará apenas esses registros quando consultado de dentro das VPCs que você associou à sua zona hospedada privada. Para obter mais detalhes, consulte a Documentação do Amazon Route 53.

Você pode configurar o DNS privado criando uma zona hospedada no Route 53, selecionando a opção para tornar a zona hospedada "privada" e associando a zona hospedada a uma das suas VPCs. Após criar a zona hospedada, você pode associá-la a VPCs adicionais. Consulte a documentação do Amazon Route 53 para obter detalhes completos sobre como configurar o DNS privado.

É possível resolver nomes internos de DNS referentes a recursos dentro de uma VPC sem conectividade com a Internet. No entanto, para atualizar a configuração da sua zona hospedada do DNS privado, você precisa de conectividade com a Internet para acessar o endpoint de API do Route 53, que está fora da VPC.

Não. O DNS privado do Route 53 usa a VPC para gerenciar a visibilidade e fornecer resolução de DNS para zonas hospedadas do DNS privado. Para usar o DNS privado do Route 53, você deve configurar uma VPC e migrar seus recursos para ela.

Sim, você pode associar várias VPCs a uma única zona hospedada.

Sim. Você pode associar VPCs pertencentes a contas diferentes com uma única hosted zone. Veja mais detalhes aqui.

Sim. As respostas de DNS estarão disponíveis em cada VPC associada à zona hospedada privada. Note que será necessário garantir que as VPCs em cada região tenham conectividade entre si para que os recursos de uma região possam alcançar recursos de outra região. O DNS privado do Route 53 é apoiado hoje nas regiões Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Norte da Califórnia), Oeste dos EUA (Oregon), Ásia-Pacífico (Mumbai), Ásia-Pacífico (Seul), Ásia-Pacífico (Cingapura), Ásia-Pacífico (Sydney), Ásia-Pacífico (Tóquio), UE (Frankfurt), UE (Irlanda) e América do Sul (São Paulo).

Sim, é possível configurar o failover de DNS ao associar verificações de integridade com conjuntos de registros de recursos dentro de uma zona hospedada de DNS privado. Se os seus endpoints estiverem em uma Virtual Private Cloud (VPC), você terá várias opções de configurar verificações de integridade nesses endpoints. Se os endpoints tiverem endereços IP públicos, você poderá criar uma verificação de integridade padrão no endereço IP público de cada endpoint. Se os seus endpoints só tiverem endereços IP privados, você não poderá criar verificações de integridade padrão nesses endpoints. No entanto, você pode criar verificações de saúde baseadas em métricas, que funcionem como verificações de saúde padrão do Amazon Route 53, ressaltando que elas usam uma métrica atual do Amazon CloudWatch como a origem das informações de verificação de saúde do endpoint em vez de fazer solicitações no endpoint de locais externos.

Sim, é possível bloquear domínios e nomes DNS específicos criando esses nomes em uma ou mais zonas hospedadas do DNS privado e apontando esses nomes ao seu próprio servidor (ou a outro local que você gerencie).

O failover de DNS consiste em dois componentes: Verificações de integridade e failover. As verificações de integridade são solicitações automáticas enviadas pela Internet ao seu aplicativo para verificar se está acessível, disponível e funcional. Você pode configurar as verificações de integridade para serem similares às solicitações normais efetuadas por seus usuários, como solicitar uma página da web de um URL específico. Com o DNS failover, o Route 53 somente retorna respostas para recursos que estejam saudáveis e acessíveis pelo mundo exterior e seus usuários finais são direcionados para evitar partes do seu aplicativo que apresentem problemas de saúde ou falhas.

Consulte o Guia do Desenvolvedor do Amazon Route 53 para obter detalhes sobre os conceitos básicos. Você também pode configurar o DNS Failover no console do Route 53.

Sim, você pode configurar o failover de DNS para Elastic Load Balancers (ELBs). Para ativar o failover de DNS para um endpoint do ELB, crie um registro Alias apontando para o ELB e defina o parâmetro "Evaluate Target Health" como True. O Route 53 cria e gerencia automaticamente as verificações de integridade do ELB. Não é preciso criar a sua própria verificação de integridade do ELB no Route 53. Também não é necessário associar o conjunto de registros de recursos para o ELB com a sua própria verificação de integridade porque o Route 53 faz a associação automaticamente com as verificações de integridade gerenciadas pelo Route 53 em seu nome. A verificação de integridade do ELB também herda a integridade das instâncias de back-end por trás desse ELB. Para obter mais detalhes sobre o uso do failover de DNS com endpoints do ELB, consulte o Guia do Desenvolvedor do Route 53.

Sim, você pode usar o DNS Failover para manter um site de backup (por exemplo, um site estático executando em bucket de site do Amazon S3) e executar failover para esse site caso o seu site principal fique inacessível.

Qualquer tipo de registro suportado pelo Route 53 pode ser associado, exceto registros SOA e DNS.

Sim. Você pode configurar o failover de DNS para Elastic Load Balancers e buckets de site do Amazon S3 com o Amazon Route 53 Console sem precisar criar sua própria verificação de integridade. Para esses tipos de endpoint, o Route 53 cria e gerencia verificações de saúde no seu nome automaticamente, que serão usadas ao criar um registro Alias apontando para o ELB ou bucket de site do S3 e ativar o parâmetro "Evaluate Target Health" no registro Alias.

Para todos os demais endpoints, ao criar a verificação de saúde do endpoint, você pode especificar o nome do DNS (por exemplo, www.example.com) ou o endereço IP do endpoint.

Sim. Da mesma forma que é possível criar um registro de recurso do Route 53 que aponta para um endereço fora da AWS, você pode configurar verificações de integridade para partes do seu aplicativo executadas fora da AWS e pode executar failover para qualquer endpoint desejado, qualquer que seja sua localização. Por exemplo, você pode ter um aplicativo legado executando em um datacenter fora da AWS e uma instância de backup desse aplicativo sendo executada na AWS. Você pode configurar verificações de saúde para seu aplicativo legado executado fora da AWS e, se o aplicativo falhar nas verificações de saúde, será possível executar o failover automático para a instância de backup na AWS.

Não, o Route 53 não toma decisões de roteamento com base na carga ou na capacidade de tráfego disponível nos seus endpoints. Você precisará garantir que tem capacidade disponível nos seus outros endpoints ou a capacidade de escalar nesses endpoints para tratar o tráfego que fluía no endpoint que apresentou falha.

O padrão é um limite de três verificações de integridade: Quando um endpoint falhar por três verificações seguidas, o Route 53 considerará o endpoint como falho. No entanto, o Route 53 continuará a executar verificações de integridade no endpoint e voltará a enviar tráfego a esse endpoint quando ele passar com sucesso em três verificações sucessivas. Você pode alterar este limite para qualquer valor entre 1 e 10 verificações. Para obter mais detalhes, consulte o Guia do desenvolvedor do Amazon Route 53.

Quando um endpoint falho passar pelo número de verificações de saúde consecutivas que você especificou quando criou a verificação de saúde (o limite padrão é de três verificações), o Route 53 restaurará os registros DNS automaticamente e o tráfego para aquele endpoint será retomado sem que você tenha que executar nenhuma ação.

Por padrão, as verificações de integridade são realizadas com um intervalo de 30 segundos. É possível opcionalmente selecionar um intervalo curto de 10 segundos entre verificações.

Ao verificar com uma frequência três vezes maior, as verificações curtas de saúde permite ao Route 53 confirmar mais rapidamente que um endpoint falhou, diminuindo o tempo necessário para o failover de DNS redirecionar o tráfego em resposta à falha do endpoint.

Verificações curtas de saúde também geram três vezes mais requisições ao endpoint, o que pode ser uma consideração se o endpoint tiver uma capacidade limitada de servir a tráfego da web. Visite a Página de definição de preço do Route 53 para obter mais detalhes de preços das verificações curtas de integridade e outros recursos opcionais das verificações de integridade. Para obter mais detalhes, consulte o Guia do desenvolvedor do Amazon Route 53.

Cada verificação de integridade é realizada a partir de vários locais em todo o mundo. O número e o conjunto de locais são configuráveis. Você pode modificar o número de locais em que cada uma das suas verificações de saúde será conduzida usando o console ou a API do Amazon Route 53. Cada localização verifica o endpoint independentemente no intervalo especificado: o intervalo padrão de 30 segundos ou um intervalo mais curto de 10 segundos. Com base no número padrão atual de localizações de verificações de saúde, você pode esperar que o endpoint receba uma solicitação a cada 2-3 segundos em média para verificações de saúde em intervalo padrão e uma ou mais requisições por segundo para verificações de saúde em intervalos rápidos.

Não. As verificações de integridade do Route 53 consideram um código HTTP 3xx como uma resposta bem-sucedida, portanto não seguem o redirecionamento. Isto pode causar resultados inesperados para verificações de saúde baseadas em comparação de strings. A verificação de saúde procura pela sequência de caracteres especificada no corpo do redirecionamento. Como a verificação de saúde não segue o redirecionamento, ela nunca envia uma requisição à localização para qual o redirecionamento aponta e nunca obtém uma resposta daquela localização. Para verificações de saúde baseadas em comparação de sequência de caracteres, recomendamos que seja evitado apontar a verificação de segurança para uma localização que retorna um redirecionamento HTTP.

Se uma verificação de saúde falhar e um failover for executado, ocorrerão os eventos descritos resumidamente a seguir:

O Route 53 executa uma verificação de integridade do seu aplicativo. Neste exemplo, o seu aplicativo falha em três verificações de saúde consecutivas e aciona os eventos a seguir.

O Route 53 desativa os registros de recurso do endpoint com falha e deixa de atender esses registros. Esta é a etapa de failover, onde o tráfego é encaminhado para endpoints saudáveis, em vez de para o endpoint com falha.

O tempo de armazenamento de uma resposta em cache pelo resolvedor DNS é determinado por um valor chamado período de ativação (TTL) associado a todo registro. Para usar o failover de DNS, recomendamos um TTL de 60 segundos ou menos para minimizar a quantidade de tempo necessária para que o tráfego deixe de ser roteado ao endpoint com falha. Para configurar o DNS Failover para endpoints do ELB e de sites do S3, você precisa usar registros Alias com TTL fixo de 60 segundos. Nestes tipos de endpoint, não é necessário ajustar os TTLs para usar o DNS Failover.

O Route 53 somente pode executar failover para um endpoint que esteja íntegro. Se não restarem endpoints saudáveis em um conjunto de registros de recurso, o Route 53 se comportará como se todas as verificações de saúde fossem bem-sucedidas.

Sim. Você pode configurar o failover de DNS sem usar o LBR. Especificamente, é possível usar o DNS Failover para configurar um cenário de failover simples, em que o Route 53 monitora seu site principal e executa failover para o site de backup caso o site principal fique indisponível.

Sim. O Route 53 oferece suporte a verificações de saúde via HTTPS, HTTP ou TCP.

Não, as verificações de integridade por meio de HTTPS testam se é possível se conectar ao endpoint por meio de SSL e se o endpoint retorna um código de resposta HTTP válido. Porém, elas não validam o certificado SSL retornado pelo endpoint.

Sim, as verificações de saúde por meio de HTTPS oferecem suporte ao SNI.

Você pode usar as verificações de integridade do Route 53 para testar a presença de uma determinada sequência de caracteres nas respostas do servidor selecionando a opção "Enable String Matching". Essa opção pode ser usada para checar um servidor web para verificar se o HTML que ele distribui tem uma string esperada. Você também pode criar uma página de status dedicada e usá-la para verificar a integridade do servidor a partir de uma perspectiva interna ou operacional. Para obter mais detalhes, consulte o Guia do desenvolvedor do Amazon Route 53.

Você pode visualizar o status atual de uma verificação de integridade, bem como detalhes do motivo da falha, no console do Amazon Route 53 e por meio da API do Route 53.

Além disso, cada resultado de verificação de integridade é publicado como métricas do Amazon CloudWatch que mostram a integridade do endpoint e, como opção, a latência da resposta do endpoint. Você pode exibir um gráfico da métrica do Amazon CloudWatch na guia de verificações de integridade do console do Amazon Route 53 para ver o status atual e o histórico da verificação de integridade. Também é possível criar alertas do Amazon CloudWatch sobre a métrica para enviar notificações, caso o status da verificação de integridade mude.

As métricas do Amazon CloudWatch para todas as suas verificações de integridade do Amazon Route 53 também ficam visíveis no console do Amazon CloudWatch. Cada métrica do Amazon CloudWatch contém o ID de verificação de integridade (por exemplo, 01beb6a3-e1c2-4a2b-a0b7-7031e9060a6a), que pode ser usado para identificar qual verificação de integridade a métrica está acompanhando.

As verificações de integridade do Amazon Route 53 incluem um recurso opcional de medição de latência que disponibiliza dados sobre a quantidade de tempo que leva para o seu endpoint responder a uma solicitação. Quando você ativa o recurso de medição de latência, a verificação de integridade do Amazon Route 53 gera métricas adicionais do Amazon CloudWatch mostrando o tempo exigido para que os verificadores de integridade do Amazon Route 53 estabeleçam uma conexão e comecem a receber dados. O Amazon Route 53 disponibiliza um conjunto separado de métricas de latência para cada região da AWS em que as verificações de integridade do Amazon Route 53 sejam conduzidas.

Como cada verificação de integridade do Route 53 publica seus resultados como uma métrica do CloudWatch, você pode configurar todas as notificações e ações automatizadas do CloudWatch que podem ser disparadas quando o valor da verificação de integridade ultrapassa um limite especificado. Primeiro, no console do Route 53 ou do CloudWatch, configure um alerta do CloudWatch na métrica de verificação de integridade. Depois, adicione uma ação de notificação e especifique o tópico do e-mail ou SNS no qual você deseja publicar sua notificação. Consulte o Guia do Desenvolvedor do Route 53 para obter todos os detalhes.

Os e-mails de confirmação podem ser enviados novamente por meio do console do SNS. Para encontrar o nome do tópico de SNS associado ao alarme, clique no nome do alarme no console do Route 53 e procure na caixa com o rótulo “Send notification to”.

No console do SNS, expanda a lista de tópicos e selecione o tópico para o alarme. Abra a caixa "Create Subscription", selecione "Email" como protocolo e insira o endereço de e-mail desejado. Clique em "Subscribe" para enviar novamente o e-mail de confirmação.

O método recomendado para configurar o failover de DNS com endpoints do ELB é utilizar registros Alias com a opção "Evaluate Target Health". Como ao usar essa opção você não cria suas próprias verificações de saúde para endpoints ELB, o Route 53 não gera métricas no CloudWatch para esses endpoints.

É possível obter métricas de integridade do load balancer de duas formas. Primeiro, o Elastic Load Balancing disponibiliza métricas que indicam a integridade do load balancer e a quantidade de instâncias íntegras nele. Para obter detalhes sobre a configuração de métricas do CloudWatch para ELB, consulte o the Guia do Desenvolvedor do ELB. Segundo, você pode criar a sua própria verificação de integridade com o CNAME fornecido pelo ELB, por exemplo, elb-example-123456678.us-west-2.elb.amazonaws.com. Essa verificação de saúde não será utilizada para o failover de DNS em si (já que a opção “Evaluate Target Health” fornece o failover de DNS para você), mas você pode consultar as métricas dessa verificação de saúde no CloudWatch e criar alertas para ser notificado no caso de falha na verificação de saúde.

Para obter mais detalhes sobre o uso do failover de DNS com endpoints do ELB, consulte o Guia do Desenvolvedor do Route 53.

O Amazon Route 53 executa verificações de integridade do próprio serviço do Amazon S3 em cada região da AWS. Ao ativar a verificação de integridade de avaliação em um registro de alias que indique um bucket de site do Amazon S3, o Amazon Route 53 levará em consideração a integridade do serviço do Amazon S3 na região da AWS em que o bucket está localizado. O Amazon Route 53 não verifica se um bucket específico existe ou apresenta um conteúdo de site válido. O Amazon Route 53 só realizará o failover para outra localização se o serviço do Amazon S3 em si não estiver disponível na região da AWS em que o seu bucket está localizado.

As métricas do CloudWatch para verificações do Route 53 estão disponíveis sem custo.

Sim. As verificações de saúde baseadas em métricas do Amazon Route 53 permitem que você execute o failover de DNS com base em qualquer métrica disponível no Amazon CloudWatch, como métricas disponibilizadas pela AWS e métricas personalizadas da sua própria aplicação. Ao criar uma verificação de saúde baseada em métrica no Amazon Route 53, a verificação de saúde apresentará problemas sempre que sua métrica associada do Amazon CloudWatch entrar em uma estado de alarme.

As verificações de saúde baseadas em métricas podem ser usadas para habilitar o failover de DNS para endpoints que não puderem ser acessados por uma verificação de saúde padrão do Amazon Route 53, como instâncias dentro de uma Virtual Private Cloud (VPC) que só tem endereços IP privados. Ao usar o recurso de verificação de saúde calculada do Amazon Route 53, você também consegue atingir cenários de failover mais avançados, combinando os resultados de verificações de saúde baseadas em métricas aos resultados de verificações de saúde padrão do Amazon Route 53, que faz solicitações em um endpoint por meio de uma rede de verificadores espalhados pelo mundo. Por exemplo, você pode criar uma configuração que falha em um endpoint, caso sua página da web voltada para o público esteja indisponível ou as métricas internas, como a carga de CPU, rede interna/externa ou leituras de disco, mostrem que o próprio servidor está com problemas de saúde.

Ocasionalmente os clientes do Amazon Route 53 criam verificações de saúde que especificam um endereço IP ou nome de domínio que não pertence a eles. Se o seu servidor web está recebendo solicitações HTTP(S) indesejadas, que você identificou como originárias das verificações de integridade do Amazon Route 53, forneça as informações sobre a verificação de integridade indesejada usando este formulário. Trabalharemos com nosso cliente para corrigir o problema.

Se você especificar um nome de domínio como o endpoint de uma verificação de saúde do Amazon Route 53, o Amazon Route 53 pesquisará o endereço IPv4 do nome de domínio e se conectará ao endpoint usando o IPv4. O Amazon Route 53 não tentará pesquisar pelo endereço IPv6 para um endpoint especificado pelo nome de domínio. Se você desejar executar uma verificação de saúde do IPv6 em vez do IPv4, selecione "IP address" em vez de "domain name" como seu tipo de endpoint e digite o endereço IPv6 no campo "IP address".

Agora, a AWS publica seus intervalos de endereço IP atuais no formato JSON. Para ver os intervalos atuais, faça o download do arquivo .json usando o seguinte link. Se você acessar esse arquivo de modo programático, verifique se a aplicação fez o download do arquivo só depois de ter verificado com sucesso o certificado TLS retornado pelo servidor da AWS.

Faça o download: ip-ranges.json

Para encontrar os intervalos IP dos servidores do Route 53, pesquise os seguintes valores no campo "service":

Servidores DNS do Route 53: pesquise por "ROUTE53"

Verificadores de saúde do Route 53: pesquise por "ROUTE53_HEALTHCHECKS"

Para obter mais informações, consulte AWS IP Address Ranges na Referência geral da Amazon Web Services.

É possível que os intervalos IPv6 ainda não estejam exibidos nesse arquivo. Como referência, veja a seguir os intervalos IPv6 dos verificadores de saúde do Amazon Route 53:

2600:1f1c:7ff:f800::/53
2a05:d018:fff:f800::/53
2600:1f1e:7ff:f800::/53
2600:1f1c:fff:f800::/53
2600:1f18:3fff:f800::/53
2600:1f14:7ff:f800::/53
2600:1f14:fff:f800::/53
2406:da14:7ff:f800::/53
2406:da14:fff:f800::/53
2406:da18:7ff:f800::/53
2406:da1c:7ff:f800::/53
2406:da1c:fff:f800::/53
2406:da18:fff:f800::/53
2600:1f18:7fff:f800::/53
2a05:d018:7ff:f800::/53
2600:1f1e:fff:f800::/53
2620:107:300f::36b7:ff80/122
2a01:578:3::36e4:1000/122
2804:800:ff00::36e8:2840/122
2620:107:300f::36f1:2040/122
2406:da00:ff00::36f3:1fc0/122
2620:108:700f::36f4:34c0/122
2620:108:700f::36f5:a800/122
2400:6700:ff00::36f8:dc00/122
2400:6700:ff00::36fa:fdc0/122
2400:6500:ff00::36fb:1f80/122
2403:b300:ff00::36fc:4f80/122
2403:b300:ff00::36fc:fec0/122
2400:6500:ff00::36ff:fec0/122
2406:da00:ff00::6b17:ff00/122
2a01:578:3::b022:9fc0/122
2804:800:ff00::b147:cf80/122

Sim. Você pode usar o AWS Management Console ou a API para registrar novos nomes de domínios no Route 53. Além disso, você também pode solicitar a transferência de nomes de domínio existentes de outros registradores para gerenciamento pelo Route 53. Os serviços de registro de nomes de domínio são fornecidos de acordo com nosso Acordo de registro de nomes de domínio.

O Route 53 oferece uma grande variedade de domínios de nível superior genéricos ("gTLDs" como, por exemplo, .com and .net) e domínios de nível superior com código de país ("ccTLDs" como, por exemplo .de e .fr). Para obter a lista completa, consulte a lista de preços de registro de domínio do Route 53.

Para começar a usar, faça login na sua conta e clique em "Domains". Clique no grande botão azul "Register Domain" e conclua o processo de registro.

Dependendo do TLD selecionado, o registro pode levar de alguns minutos até várias horas. Após o registro bem-sucedido do domínio, ele será exibido na sua conta.

O período de cadastro inicial geralmente é de um ano, embora os cadastros para alguns domínios de nível superior (TLDs) tenham períodos de cadastro mais longos. Quando você faz o cadastro de um domínio com o Amazon Route 53 ou transfere o cadastro do domínio para o Amazon Route 53, nós configuramos o domínio para que ele seja renovado automaticamente. Para obter mais informações, consulte Como renovar o cadastro de um domínio no Guia do desenvolvedor do Amazon Route 53.

Para registrar um nome de domínio, você precisa fornecer informações de contato para o registrador do domínio, incluindo nome, endereço, telefone e endereço de e-mail. Se os contatos administrativo e técnico forem diferentes, também será necessário fornecer essas informações de contato.

O ICANN, o órgão que rege o registro de domínios, exige que os registrantes forneçam informações de contato, incluindo nome, endereço e telefone, para cada registro de nome de domínio, e que os registrantes disponibilizem essas informações publicamente por meio de um banco de dados Whois. Para nomes de domínio que você registra como um domínio (ou seja, não uma empresa ou organização), o Route 53 oferece proteção de privacidade, que oculta gratuitamente o telefone, o endereço de e-mail e o endereço físico pessoais. Em vez disso, o Whois contém o nome e o endereço de correspondência do registrante, juntamente com um endereço de encaminhamento de e-mail gerado pelo registrante que pode ser usado por terceiros que desejam entrar em contato com você.

Sim, o Route 53 oferece proteção de privacidade sem custo adicional. A proteção de privacidade oculta o número do telefone, o endereço de e-mail e o endereço físico. O nome e o sobrenome serão ocultos se o registro de TLD e o registrador permitirem. Quando você ativa a proteção de privacidade, as consultas Whois para o domínio retornarão o endereço de correspondência do registrador em vez do seu endereço físico e o nome do registrador em vez do seu nome (se permitido). Seu endereço de e-mail será um endereço de encaminhamento de e-mail gerado pelo registrador que poderá ser usado por terceiros, caso eles desejem entrar em contato com você. Os nomes de domínio registrados por empresas ou organizações estarão qualificados para proteção de privacidade se o registro do TLD e o registrador permitirem.

Para obter uma lista de TLDs, consulte a lista de preços. Para obter os requisitos específicos de registro para cada TLD, consulte o Guia do Desenvolvedor do Amazon Route 53 e o contrato de registro de nome de domínio.

Quando o seu nome de domínio é criado, associamos automaticamente o seu domínio com quatro servidores de nome únicos do Route 53, conhecidos como um conjunto de delegação. Você pode visualizar o conjunto de delegação do seu domínio no console do Amazon Route 53. Eles estão listados na zona hospedada que criamos automaticamente quando você registrou o domínio.

Por padrão, o Route 53 atribui um conjunto de delegações novo e único para cada zona hospedada criada. No entanto, você também pode usar a API do Route 53 para criar um "conjunto de delegações reutilizável", que pode ser aplicado a várias zonas hospedadas criadas. Para clientes com grande quantidade de nomes de domínio, os conjuntos de delegações reutilizáveis facilitam a migração para o Route 53, pois você pode instruir o registrador do nome do domínio a usar o mesmo conjunto de delegações para todos os seus domínios gerenciados pelo Route 53. Esse recurso também possibilita criar endereços de servidor de nomes "rótulo branco", como ns1.example.com, ns2.example.com, etc., que você pode apontar para os seus servidores de nome do Route 53. Em seguida, você pode usar seus endereços de servidor de nomes "rótulo branco" como servidores de nome autoritários para o número de nomes de domínio desejado. Para obter mais detalhes, consulte a documentação do Amazon Route 53.

Você será cobrado pela zona hospedada que o Route 53 criou para o seu nome de domínio, bem como pelas consultas de DNS para essa zona hospedada, atendidas pelo Route 53 em seu nome. Se não deseja ser cobrado pelo serviço DNS do Route 53, você pode excluir a zona hospedada do Route 53. Note que alguns TLDs exigem que você disponha de servidores de nome válidos como parte do registro do nome de domínio. Para um nome de domínio em um desses TLDs, você precisará obter o serviço DNS de outro provedor, e inserir os endereços do servidor de nome desse provedor antes de excluir com segurança a zona hospedada do Route 53 para esse nome de domínio.

A AWS revende nomes de domínio registrados com os registradores acreditados pela ICANN. A Amazon Registrar, Inc. é uma empresa da Amazon acreditada pela ICANN para o registro de domínios. O registrador do registro é o "Registrador patrocinado" listado no registro WHOIS do seu domínio para indicar o registrador com que o seu domínio foi registrado.

A Amazon é uma revenda do registrador Gandi. O ICANN exige que o Gandi, como registrador do registro, entre em contato com os registrantes para conferir as informações de contato no momento do registro inicial. Você DEVE comprovar as suas informações de contato, se solicitado pelo Gandi, dentro dos primeiros 15 dias de registro para evitar a suspensão do seu nome de domínio. O Gandi também envia notificações de lembrete antes da renovação do domínio.

Escolhemos de forma dinâmica qual registrador subjacente usar. A maioria dos domínios é registrada por meio do Amazon Registrar. Consulte nossa documentação para obter uma lista dos domínios que estão disponíveis para registro usando o Amazon Route 53, neste momento.

O Whois é um banco de dados de nomes de domínio disponível publicamente que relaciona as informações de contato e os servidores de nome associados a um nome de domínio. Qualquer pessoa pode acessar o banco de dados Whois usando o comando WHOIS, que pode ser facilmente encontrado. Ele está incluso em vários sistemas operacionais, como também encontra-se disponível como uma aplicação da Web em diversos sites. O Internet Corporation for Assigned Names and Numbers (ICANN) exige que todos os nomes de domínio tenham informações de contato disponíveis publicamente caso alguém precise entrar em contato com o titular do nome de domínio.

Para começar a usar, faça login na sua conta e clique em "Domains". Clique no botão "Transfer Domain" na parte superior da tela e conclua o processo de transferência. Antes de iniciar o processo de transferência, verifique se (1) o seu nome de domínio está desbloqueado no registrador atual, (2) você desativou a proteção de privacidade no seu nome de domínio (se aplicável), e (3) você obteve o código de autorização válido, ou "authcode", do seu registrador atual, que será necessário informar como parte do processo de transferência.

Primeiro, é necessário obter uma lista dos dados de registro DNS referente ao nome do domínio, geralmente disponível no formato de um "arquivo da zona" que pode ser obtido junto ao provedor de DNS existente. Com os dados do registro de DNS disponíveis, você pode usar o Management Console do Route 53 ou uma interface simples de serviços web para criar uma zona hospedada que pode armazenar os registros de DNS do seu nome de domínio e acompanhar o processo de transferência, que incluirá etapas como atualização dos servidores de nome do seu nome de domínio para os associados à sua zona hospedada. Para concluir esse processo de transferência de nomes de domínio, entre em contato com o registrador onde você registrou o seu nome de domínio e siga seu processo de transferência, que incluirá etapas como a atualização dos servidores de nome do seu nome de domínio para os associados à sua zona hospedada. Assim que o registrador propagar as novas delegações dos servidores designados, as consultas do DNS dos usuários finais começarão a ser respondidas pelos servidores DNS do Route 53.

Você pode visualizar o status das transferências de nome de domínio na seção "Alerts" da página inicial do console do Route 53.

Você terá de entrar em contato com o registrador atual para determinar o motivo da falha da transferência. Depois que o registrador atual resolver o problema, você poderá enviar a solicitação de transferência novamente.

Para mover o seu nome de domínio para fora do Route 53, você precisará iniciar uma solicitação de transferência no novo registrador. Eles solicitarão o nome de domínio a ser movido para seu gerenciamento.

Cada nova conta do Amazon Route 53 está limitada a um máximo de 20 domínios. Para solicitar um limite maior, entre em contato conosco.

Sim. Você pode habilitar a assinatura do DNSSEC para as zonas hospedadas públicas e novas.

Consulte a nossa documentação para obter um guia detalhado sobre como transferir seu domínio habilitado para DNSSEC para o Amazon Route 53.

O Resolvedor do Route 53 é um serviço DNS regional que fornece pesquisas de DNS recursivos para nomes hospedados no EC2, bem como nomes públicos na Internet. Essa funcionalidade está disponível por padrão em cada Amazon Virtual Private Cloud (VPC). Para cenários de nuvem híbrida, você pode configurar regras de encaminhamento condicional e endpoints de DNS para habilitar a resolução de DNS no AWS Direct Connect e na VPN gerenciada pela AWS.

O Amazon Route 53 é um serviço DNS autoritativo e um serviço DNS recursivo. O DNS autoritativo contém a resposta final para uma consulta DNS, geralmente um endereço IP. Os clientes (dispositivos móveis, aplicativos em nuvem ou servidores no seu data center, por exemplo) não falam diretamente com serviços DNS autoritativos, exceto em casos muito raros. Em vez disso, os clientes se comunicam com serviços DNS recursivos (também conhecidos como resolvedores de DNS) que localizam a resposta autoritativa correta para qualquer consulta DNS. O Resolvedor Route 53 é um serviço DNS recursivo.

Ao receber uma consulta, um serviço DNS recursivo como o Resolvedor Route 53 pode ser configurado de modo a encaminhar a consulta direta e automaticamente para um servidor DNS recursivo específico, ou pode pesquisar de forma recursiva, começando pela raiz do domínio e continuando até encontrar a resposta final. Em ambos os casos, quando uma resposta é encontrada, o servidor DNS recursivo pode armazenar em cache a resposta durante um período de tempo para que possa responder a consultas subsequentes para o mesmo nome, mais rapidamente, no futuro.

As regras de encaminhamento condicional permitem que o Resolvedor encaminhe consultas de domínios especificados para o endereço IP de destino de sua escolha, geralmente um resolvedor de DNS no local. As regras são aplicadas no nível da VPC e podem ser gerenciadas a partir de uma conta e compartilhadas em várias contas.

Um endpoint de DNS inclui uma ou mais interfaces de rede elástica (ENI, Elastic Network Interfaces) que se anexam à sua Amazon Virtual Private Cloud (VPC). Cada ENI recebe um endereço IP do espaço de sub-rede da VPC em que está localizado. Esse endereço IP pode servir como um destino de encaminhamento de servidores DNS no local para encaminhar consultas. Os endpoints são necessários para o tráfego de consulta DNS que você está encaminhando das VPCs para a sua rede e da rede para as VPCs por meio do AWS Direct Connect e da VPN gerenciada.

O resolvedor do Route 53 é integrado ao AWS Resource Access Manager (RAM), que fornece aos clientes uma maneira simples de compartilhar seus recursos em contas da AWS ou em sua AWS Organization. As regras podem ser criadas em uma conta primária e, em seguida, compartilhadas em várias contas usando o RAM. Depois de compartilhadas, as regras ainda precisam ser aplicadas às VPCs nessas contas antes de entrar em vigor. Para obter mais informações, consulte a documentação do AWS RAM.

Essas regras não poderão mais ser usadas pelas contas com as quais você as compartilhou anteriormente. Isso significa que, se essas regras estiverem associadas a VPCs nessas contas, elas serão desassociadas dessas VPCs.

Acesse a nossa Tabela de regiões da AWS para ver em quais regiões o Resolvedor do Route 53 foi lançado.

Não. O DNS público e privado, o fluxo de tráfego, as verificações de integridade e o registro de nomes de domínio do Amazon Route 53 são todos serviços globais.

É possível usar o Route 53 Resolver para resolver consultas de Sistema de Nomes de Domínio (DNS) localmente em racks do AWS Outposts, aprimorando a disponibilidade e a performance de suas aplicações on-premises. Quando você habilita o Route 53 Resolver no Outposts, o Route 53 armazena automaticamente as respostas de DNS nos racks do Outposts e fornece resolução de DNS contínua para as aplicações, mesmo durante desconexões de rede inesperadas na região da AWS primária. Ao fornecer respostas de DNS localmente, o Route 53 Resolver no Outposts também permite resolução de DNS de baixa latência,
melhorando a performance de suas aplicações on-premises.

Além disso, é possível conectar os racks do Route 53 Resolvers no Outposts com servidores de DNS em seus datacenters on-premises por meio de endpoints do Route 53 Resolver. Isso possibilita a resolução de consultas de DNS entre os racks do Outposts e seus outros recursos on-premises.

Consulte o Guia do desenvolvedor do Amazon Route 53 para obter detalhes sobre os conceitos básicos. Você também pode configurar o Resolver no console do Amazon Route 53.

Sim, o Amazon Route 53 Resolver suporta o uso do DNS sobre o protocolo HTTPS (DoH) para endpoints de resolvers de entrada e saída.

O Firewall de DNS do Amazon Route 53 Resolver é um recurso que permite implementar proteções de DNS rapidamente em todas as suas Amazon Virtual Private Cloud (VPCs). O Firewall de DNS do Route 53 Resolver permite que você bloqueie consultas feitas para domínios mal-intencionados conhecidos (ou seja, crie “listas de recusa”) e autorize consultas para domínios confiáveis (crie “listas de permissão”) ao usar o Route 53 Resolver para resolução de DNS recursiva. Você também pode começar a usar rapidamente proteções contra ameaças de DNS comuns usando listas de domínios gerenciados da AWS. O Firewall de DNS do Amazon Route 53 Resolver funciona em conjunto com o AWS Firewall Manager para que você possa criar políticas com base nas regras do Firewall de DNS e, em seguida, aplicar essas políticas de maneira centralizada em suas VPCs e contas.

Se você deseja filtrar os nomes de domínio que podem ser consultados no DNS de dentro de suas VPCs, o Firewall de DNS é ideal para você. Ele oferece flexibilidade na escolha da configuração que funciona melhor para a postura de segurança de sua organização de duas maneiras: (1) se você tiver requisitos rígidos de exfiltração de DNS e quiser negar todas as consultas de DNS de saída para domínios que não estão em suas listas de domínios aprovados, você poderá criar essas regras para uma abordagem de “isolamento” para a segurança do DNS. (2) Se sua organização preferir permitir todas as pesquisas de DNS de saída em suas contas por padrão e exigir apenas a capacidade de bloquear solicitações de DNS para domínios mal-intencionados conhecidos, você poderá usar o Firewall de DNS para criar listas de recusa, que incluem todos os nomes de domínio mal-intencionados de que sua organização tem conhecimento. O Firewall de DNS também inclui listas de domínios gerenciados da AWS que ajudam você a se proteger contra domínios suspeitos e bots de comando e controle (C&C).

O Firewall de DNS do Route 53 Resolver complementa os serviços de segurança de rede e aplicações existentes na AWS, fornecendo controle e visibilidade ao tráfego de DNS do Route 53 Resolver (por exemplo, AmazonProvidedDNS) para toda a VPC. Dependendo do seu caso de uso, você pode optar por implementar o Firewall de DNS junto com seus controles de segurança existentes, como o AWS Network Firewall, grupos de segurança do Amazon VPC, regras do AWS Web Application Firewall ou dispositivos do AWS Marketplace.

Sim. O Firewall de DNS do Route 53 Resolver é um recurso regional e protege o tráfego de rede do DNS do Route 53 Resolver em nível de organização e conta. Para manter a política e governança em várias contas, você deve usar o AWS Firewall Manager.

O preço é baseado no número de nomes de domínio armazenados no firewall e no número de consultas de DNS inspecionadas. Acesse a Definição de preço do Amazon Route 53 para obter mais informações.

Você pode registrar sua atividade do Firewall de DNS em um bucket do Amazon S3 ou grupos de log do Amazon CloudWatch para análise e investigação adicionais. Você também pode usar o Amazon Kinesis Firehose para enviar seus logs a um provedor terceirizado.

Ambos, o firewall de Amazon Route 53 Resolver e o AWS Network Firewall, oferecem proteção contra ameaças de consulta de DNS de saída, mas para diferentes modelos de implantação. O firewall de DNS Amazon Route 53 Resolver é desenhado para fornecer controle granular para bloquear solicitações de DNS ou domínios comprometidos mal-intencionados se você estiver usando o Amazon Route 53 Resolver para resolução de DNS. O AWS Network Firewall oferece recursos semelhantes para filtrar/bloquear consultas de DNS de saída para domínios mal-intencionados conhecidos se você estiver usando um serviço de DNS externo para resolver solicitações de DNS.

Os perfis do Amazon Route 53 permitem que você gerencie facilmente as configurações de DNS em toda a sua organização criando uma ou mais configurações compartilháveis na forma de um perfil. Com os perfis, é possível combinar várias configurações, como associações de zona hospedada privada (PHZ), regras do Resolver e grupos de regras do Route 53 Resolver DNS Firewall em uma configuração compartilhável via RAM. Ao compartilhar o perfil entre contas da AWS e associá-lo às Amazon Virtual Private Clouds (VPCs), você tem uma maneira fácil de garantir que todas as VPCs tenham a mesma configuração de DNS sem a complexidade de gerenciar recursos separados.

Os perfis do Route 53 se integram nativamente ao AWS RAM, permitindo que você compartilhe perfis entre contas ou com uma organização da AWS.

Sim. Os perfis do Route 53 utilizam permissões gerenciadas pelo RAM que permitem que os usuários anexem permissões diferentes a cada recurso.

É possível associar até 5.000 VPCs a um único perfil do Route 53.

Sim, é possível criar um ou mais perfis por conta. No entanto, você só pode associar um perfil por VPC de cada vez.

Os perfis do Route 53 oferecem suporte a zonas hospedadas privadas e às configurações nelas especificadas, regras do Route 53 Resolver (tanto de encaminhamento quanto de sistema) e grupos de regras do DNS Firewall. Além disso, algumas configurações de VPC são gerenciadas diretamente nos perfis. Essas configurações incluem configuração de pesquisa reversa de DNS para regras do Resolver, configuração do modo de falha do DNS Firewall e configuração da validação de DNSSEC.

Não, não é possível compartilhar um perfil entre regiões da AWS