Como soluciono problemas de roteamento por geolocalização do Route 53?
Minhas consultas de DNS retornam um endereço IP de um servidor web em uma região diferente da AWS. Por exemplo, um usuário nos Estados Unidos está sendo roteado para um endereço IP de um servidor web localizado na Europa.
Resolução
Os problemas de roteamento por geolocalização do Route 53 são causados pelos seguintes problemas:
- Há uma localização padrão ausente em sua configuração de roteamento por geolocalização.
- O resolvedor de DNS não suporta a extensão edns0-client-sub-net do EDNS0. Isso leva a uma determinação imprecisa de sua localização.
- Os resolvedores de DNS são geograficamente diversos.
- Há alterações de DNS em registros de recursos que não se propagaram globalmente.
Para resolver esses problemas, faça o seguinte:
1. Confirme se os registros de recursos da sua zona hospedada do Route 53 estão configurados corretamente para seu caso de uso. Além disso, confirme se há um conjunto de registros de recursos padrão. No console do Route 53, verifique o local padrão especificado na configuração da zona hospedada do Route 53.
Exemplo: Considere o seguinte exemplo de saída:
>> dig images.example.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.45.amzn1 <<>> images.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51385 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION ;images.example.com. IN A ;; AUTHORITY SECTION: images.example.com. 60 IN SOA ns-1875.awsdns-42.co.uk.awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ;; Query time: 65 msec ;; SERVER: 172.31.0.2#53(172.31.0.2) ;; WHEN: Tue Feb 7 22:02:30 2017 ;; MSG SIZE rcvd: 124
No exemplo anterior, não há um local padrão especificado na configuração de roteamento por geolocalização. Assim, para uma geolocalização não correspondente, a resposta do DNS retorna NOERROR para o campo rcode e não há resultado na seção ANSWER. Para corrigir esse problema, adicione um local padrão em sua configuração de roteamento por geolocalização.
2. Para verificar o intervalo de endereços IP do resolvedor de DNS, execute os seguintes comandos e anote a saída.
No Linux ou macOS, use dig:
for i in {1..10}; do dig +short resolver-identity.cloudfront.net; sleep 11; done;
No Windows, use o nslookup:
for /l %i in (1,1,10) do (nslookup resolver-identity.cloudfront.net && timeout /t 11 /nobreak)
3. Verifique se o resolvedor DNS é compatível com o edns0-Client-Subnet usando um dos seguintes comandos e anote a saída.
No Linux ou macOS, use dig:
dig +nocl TXT o-o.myaddr.l.google.com
No Windows, use o nslookup:
nslookup -type=txt o-o.myaddr.l.google.com
Examine o primeiro registro TXT na seção Answer da saída. O primeiro valor do registro TXT é o endereço IP do resolvedor de DNS. Se não houver um segundo registro TXT, o resolvedor de DNS não é compatível com edns0-client-subnet. Se houver um segundo registro TXT, o resolvedor de DNS é compatível com edns0-client-sub-net. O resolvedor fornece um endereço IP de sub-rede de cliente truncado (/24 ou /32) para o servidor de nomes autoritativo do Route 53. Para mais informações, consulte How can I determine if my public DNS resolver supports the EDNS Client Subnet (ECS) extension? (Como posso determinar se meu resolvedor DNS público é compatível com a extensão Sub-rede de cliente EDNS (ECS)?)
4. Utilize o conjunto de registros de teste do Route 53 da ferramenta de verificação para determinar os registros de recursos que são retornados para uma solicitação específica. Para mais informações, consulte Usar a ferramenta de verificação para ver como o Amazon Route 53 responde às consultas de DNS.
Se o resolvedor de DNS não for compatível com edns0-client-subnet, especifique o endereço IP do resolvedor DNS como seu valor na ferramenta.
Se o resolvedor de DNS for compatível com edns0-client-sub-net, especifique o endereço IP da sub-rede do cliente EDNS0 como seu valor na ferramenta. Escolha Mais opções, em seguida especifique a máscara Sub-rede. Não especifique um Endereço IP do resolvedor.
5. (Opcional) Se você não tiver acesso à ferramenta de verificação, use dig para consultar os servidores de nomes oficiais do Route 53 para sua zona hospedada com a EDNS0-Client-Subnet. Use a saída para determinar a resposta oficial do registro de geolocalização para seu endereço IP de origem:
dig geo.example.com +subnet=<Client IP>/24 @ns-xx.awsdns-xxx.com +short
6. Os servidores de nome do Route 53 são compatíveis com a extensão edns0-client-subnet do EDNS0. O resolvedor ou servidor DNS local anexa a edns0-client-subnet à consulta ao DNS para fazer uma pesquisa de DNS com base na sub-rede do IP de origem do cliente. Se esses dados não forem transmitidos com a solicitação, o Route 53 usará o endereço IP de origem do resolvedor de DNS para aproximar a localização do cliente. Em seguida, o Route 53 responde às consultas de geolocalização com o registro DNS da localização do resolvedor. Os dados EDNS0 devem ser passados para o Route 53 e o cliente deve usar um servidor de nomes recursivos geograficamente mais próximo. Caso contrário, o resultado é um local abaixo do ideal que serve o registro de recurso incorreto para a consulta de DNS.
Para corrigir essa configuração, altere o servidor DNS recursivo que seja compatível com edns0-client-subnet. Execute a resolução de DNS e compartilhe a saída. Se o servidor DNS recursivo não oferecer suporte à sub-rede edns0-client-subnet, tente usar um que ofereça suporte. As opções que são compatíveis com edns0-client-sub-net incluem os resolvedores DNS e OpenDNS do Google.
7. Verifique a localização geográfica do endereço IP da sub-rede do cliente usando o banco de dados GeoIP da MaxMind no site da MaxMind ou seu banco de dados GeoIP preferido. Verifique se o resolvedor de DNS está geograficamente próximo ao endereço IP público do cliente. Se a resposta ou o país no site da MaxMind não corresponderem à resposta dada pelo Route 53, os dados geográficos de produção do Route 53 podem estar obsoletos. Se houver roteamento obsoleto, entre em contato com o AWS Support.
8. Verifique se há problemas com a propagação do DNS usando uma ferramenta como CacheCheck no site OpenDNS.
9. (Opcional) Determine se os registros de roteamento baseados em geografia estão associados a uma verificação de integridade do Route 53. Além disso, determine se a opção Evaluate target health (ETH) está ativada para registros de aliases. Se algum deles for verdadeiro, o Route 53 retornará o endpoint íntegro que melhor corresponde ao local de origem.
Verifique o status da verificação de integridade do Route 53 no console do Route 53. Se o ETH estiver ativado, verifique o status de integridade do endpoint do registro. O Route 53 considera um endpoint para um Classic Load Balancer com ETH ativado como íntegro se pelo menos uma instância de back-end estiver íntegra. Para Application Load Balancers e Network Load Balancers, cada grupo-alvo com destinos deve conter pelo menos um alvo saudável para ser considerado íntegro. Um grupo-alvo sem metas registradas é considerado não íntegro. Se algum grupo-alvo contiver somente alvos não íntegros, o balanceador de carga será considerado não íntegro.
Exemplo: Você tem registros do Texas nos EUA, nos EUA, na América do Norte e em todos os locais (a localização é padrão). Além disso, você tem consultas originárias do Texas com um endpoint não íntegro. O Route 53 verifica os EUA, a América do Norte e, em seguida, todos os locais, nessa ordem, até que um registro com um endpoint íntegro seja encontrado. Se o registro dos EUA for íntegro, o Route 53 retornará esse endpoint. Caso contrário, o Route 53 retornará um registro padrão. Se todos os registros aplicáveis não estiverem íntegros, o Route 53 responderá à consulta de DNS usando o valor do registro para a menor região geográfica.
Observação: As alterações nos registros de recursos de geolocalização com aliases podem levar até 60 segundos para serem propagadas.
Informações relacionadas
Como posso solucionar problemas de verificação de saúde não íntegra do Route 53?
Conteúdo relevante
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 2 anos