Como soluciono problemas com registros de recursos baseados em latência e com o Route 53?

Breve descrição

O Route 53 é resolvido para a região com a menor latência, com base na localização da consulta de DNS, se o seguinte for verdadeiro:

• Você associou endpoints em várias regiões da AWS ao mesmo registro de recursos.
• Você está usando uma política de roteamento baseada em latência.

O Route 53 toma decisões de roteamento com base em latência com base em:

• O endereço IP de origem do resolvedor de DNS recursivo que envia a consulta ao servidor de nomes autoritativo do Route 53.
• A versão truncada do endereço IP do cliente (se o resolvedor de DNS suportar a extensão edns00-client-subnet).

Por padrão, os servidores de nomes Route 53 suportam edns0-client-subnet. Se um resolvedor de DNS recursivo suportar edns0-client-subnet, o resolvedor de DNS enviará ao Route 53 uma versão truncada do endereço IP do cliente. Em seguida, o Route 53 usa esse endereço IP truncado para determinar a região de menor latência.

A região com a menor latência pode não estar fisicamente mais próxima do resolvedor de DNS. Você pode ter um comportamento de roteamento indesejado se o cliente não estiver no mesmo local do resolvedor de DNS. Você também pode ter um comportamento de roteamento indesejado se o endereço IP do resolvedor tiver informações de localização diferentes.

Exemplo de cenário

Uma empresa tem registros de roteamento baseados em latência para dois Elastic Load Balancers, um localizado na Virgínia (us-east-1) e outro na Irlanda (eu-west-1). Os usuários nos EUA usam um resolvedor de DNS corporativo localizado na Europa ou se conectam ao escritório corporativo na Europa por meio de uma VPN.

O resolvedor de DNS corporativo não pode enviar dados da edns0-client-subnet para os servidores de nomes autorizados. Portanto, o Route 53 considera o endereço IP do resolvedor de DNS na Europa como a origem da consulta. Em seguida, o Route 53 realiza uma pesquisa em seu banco de dados de latência e determina incorretamente que o balanceador de carga na Irlanda tem a menor latência.

Se o resolvedor de DNS corporativo puder enviar dados da edns0-client-subnet, o Route 53 considerará o endereço IP truncado do cliente nos EUA como a origem da consulta. Em seguida, o Route 53 realiza uma pesquisa em seu banco de dados de latência e determina corretamente que o balanceador de carga na Virgínia tem a menor latência.

Resolução

Use as etapas a seguir para solucionar o comportamento indesejado de roteamento baseado em latência:

1.    Verifique o intervalo de endereços IP usado pelo resolvedor de DNS. No Linux e no macOS, execute o comando dig em um loop. No Windows, execute o comando nslookup várias vezes. Certifique-se de anotar a saída todas as vezes.

No Linux ou no macOS, execute o comando dig em um loop.

for i in {1..10}; do dig TXT o-o.myaddr.l.google.com +short; sleep 61; done;

No Windows, execute o comando nslookup várias vezes. Certifique-se de anotar a saída todas as vezes.

nslookup -type=txt o-o.myaddr.l.google.com

2.    Confirme se o resolvedor de DNS suporta Anycast usando a saída do comando anterior. Se a saída sempre contiver o mesmo endereço IP único, o resolvedor de DNS não é compatível com Anycast. Se o endereço IP mudar ao executar o comando várias vezes, o resolvedor de DNS oferece suporte ao Anycast.

Quando um resolvedor de DNS oferece suporte ao Anycast, há vários pontos de extremidade para resolvedores de DNS. A localização periférica de um usuário é selecionada com base na latência ideal, o que pode resultar em uma localização inesperada para o endereço IP do resolvedor.

3.    Encontre o endereço IP do cliente. Na máquina cliente, abra um navegador da Internet e navegue até https://checkip.amazonaws.com/.

Ou use curl:

curl https://checkip.amazonaws.com/

4.    Verifique se o resolvedor de DNS suporta edns0-client-subnet usando um dos seguintes comandos. Certifique-se de anotar a saída.

No Linux ou macOS, use dig:

dig +nocl TXT o-o.myaddr.l.google.com @<DNS Resolver>

No Windows, use o nslookup:

nslookup -type=txt o-o.myaddr.l.google.com <DNS Resolver>

5.    Verifique o primeiro registro TXT retornado na seção Resposta da saída. Esse valor é o servidor DNS mais próximo que anuncia o Anycast. Se não houver um segundo registro TXT, o resolvedor de DNS não suporta edns0-client-subnet. Se houver um segundo registro TXT, o resolvedor de DNS suporta edns0-client-subnet. O resolvedor envia uma sub-rede de cliente truncada (/24 ou /32) para o servidor de nomes autoritativo do Route 53.

(Opcional) Se você ativou o registro de consultas ao DNS do Route 53 em sua zona hospedada, crie um registro de teste. Execute uma pesquisa de DNS para o novo registro. Verifique os registros de consulta para confirmar o endereço IP e a edns0-client-subnet (se houver) do resolvedor apresentados aos servidores de nomes do Route 53.

6.    Verifique se o valor TTL da resposta é de 60 segundos. Se o TTL não for de 60 segundos, a resposta será uma resposta em cache. Repita o comando dig ou nslookup até que o valor TTL da resposta seja 60 segundos.

7.    Se você puder acessar a ferramenta de verificação do DNS do Route 53, simule consultas de um resolvedor de DNS específico ou endereço IP do cliente. Use essas consultas para descobrir qual conjunto de registros de recursos de latência que o Route 53 retorna.

Se o resolvedor de DNS não suportar edns0-client-subnet, especifique o endereço IP do resolvedor como seu valor na ferramenta.

Se o resolvedor de DNS suportar edns0-client-sub-net, especifique o IP da sub-rede do cliente EDNS0 como seu valor na ferramenta. Selecione Configuração adicional e especifique a máscara de sub-rede.

Observação: a ferramenta de verificação de DNS do Route 53 consulta diretamente o banco de dados de medição de latência do Route 53. A consulta determina a latência pré-calculada entre as regiões da AWS e uma rede baseada na Internet. A ferramenta não envia consultas de DNS pela Internet ou para resolvedores de DNS. A ferramenta não verifica se o resolvedor de DNS é compatível com edns0-client-subnet. Os resultados da ferramenta e de uma consulta de DNS real podem ser diferentes.

8.    (Opcional) Se você não conseguir acessar a ferramenta de verificação de DNS do Route 53, use dig. Usando dig, consulte os servidores de nomes oficiais do Route 53 para sua zona hospedada com edns0-client-subnet. Use a saída para determinar a região de menor latência do seu endereço IP de origem.

dig lbr.example.com +subnet=<Client IP>/24 @ns-xx.awsdns-xxx.com +short

Observação: a latência entre hosts na Internet pode mudar com o tempo devido a mudanças na conectividade e no roteamento da rede. Por exemplo, uma solicitação encaminhada para a região do Oregon nesta semana pode ser encaminhada para a região de Ohio na próxima semana.

9.    Para resolvedores que não oferecem suporte a edns0-client-subnet: Altere o resolvedor de DNS do cliente para um resolvedor de DNS recursivo diferente localizado geograficamente mais próximo do cliente. Se o resolvedor não suportar edns0-client-subnet, as consultas de DNS do cliente poderão usar um resolvedor de DNS em uma localização geográfica diferente do cliente. O resultado nesse cenário é um comportamento de roteamento inesperado.

Se você gerencia o resolvedor de DNS, verifique a configuração de encaminhamento. Confirme que você não está encaminhando consultas de DNS para outro resolvedor que esteja mais longe da localização geográfica do cliente.

Para resolvedores que oferecem suporte a edns0-client-subnet: Verifique a localização geográfica do endereço IP da sub-rede do cliente. Para verificar a localização, use o banco de dados GeoIP no site da MaxMind ou seu banco de dados GeoIP preferido. Se a localização do endereço IP da sub-rede do cliente estiver em uma localização geográfica diferente da do cliente, você poderá ter um comportamento de roteamento inesperado.

10.    (Opcional) Se o resolvedor de DNS não suportar edns0-client-sub-net, mude para um resolvedor de DNS recursivo público que suporte edns0-client-subnet. Em seguida, compare seus resultados antigos de resposta de roteamento de latência do Route 53 com seus novos resultados. Por exemplo, dois resolvedores de DNS públicos que atualmente oferecem suporte à edns0-client-subnet são GoogleDNS (8.8.8.8 e 8.8.4.4) e OpenDNS (208.67.222.222 e 208.67.220.220).

11.    (Opcional) Determine se os registros de roteamento baseados em latência estão associados a uma verificação de integridade do Route 53. E determine se o Evaluate Target Health (ETH) está ativado (para registros de aliases). Se um ou ambos forem verdadeiros, o Route 53 retornará o endpoint saudável com menor latência. Se todas as verificações de integridade falharem, somente a política de roteamento será considerada.

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 saudável 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 saudável. Um grupo-alvo sem metas registradas é considerado como não íntegro. Se algum grupo-alvo contiver somente alvos não íntegros, o balanceador de carga será considerado não íntegro.

Exceção: Se um Application Load Balancer tiver pelo menos um grupo-alvo íntegro e todos os grupos-alvo restantes estiverem vazios, o Route 53 o considerará íntegro.

Exemplo

Você tem dois registros de roteamento baseados em latência com verificações de integridade associadas ao Route 53, um no Oregon e outro na Virgínia do Norte. Quando a verificação de integridade do endpoint do Oregon falha, todas as solicitações são encaminhadas para o endpoint da Virgínia do Norte, independentemente da localização do cliente.

Informações relacionadas

Verificação das respostas de DNS do Route 53

Como posso determinar se meu resolvedor de DNS público suporta a extensão de sub-rede do cliente EDNS?

Como posso solucionar problemas de verificação de integridade não íntegra do Route 53?

Por que meu registro de alias apontando para um Application Load Balancer está marcado como não íntegro quando estou usando “Evaluate Target Health”?