Por que o tráfego do meu conteúdo da web está sendo roteado para o local da borda errado do CloudFront?

Breve descrição

O CloudFront direciona o tráfego com base na classe de preço da distribuição, nos bancos de dados de geolocalização associados e no suporte a EDNS0-Client-Subnet. Dependendo da combinação desses fatores, os visualizadores do seu site podem ser direcionados para um local da borda inesperado. Isso pode aumentar a latência geral para recuperar um objeto de um local da borda do CloudFront.

Para solucionar problemas de roteamento para um local da borda inesperado, verifique o seguinte:

• A classe de preço suporta o local da borda que você espera.
• O resolvedor de DNS suporta roteamento Anycast.
• O resolvedor de DNS suporta EDNS0-Client-Subnet.

Resolução

A classe de preço suporta o local da borda que você espera

Verifique os locais da borda que estão incluídos na classe de preço da sua distribuição do CloudFront. Você pode atualizar a classe de preço de sua distribuição se quiser incluir outros locais de borda.

O resolvedor de DNS suporta roteamento Anycast

Se o resolvedor de DNS suportar o roteamento Anycast, então há vários locais da borda que o resolvedor de DNS usa. Isso significa que o local da borda de um solicitante é baseado na latência ideal, o que pode resultar em um local inesperado para o endereço IP do resolvedor.

Para verificar se o resolvedor de DNS é compatível com Anycast, execute um desses comandos várias vezes:

Observação: nesses comandos de exemplo, certifique-se de substituir example.com pelo nome de domínio do resolvedor de DNS que você está usando.

No Linux ou no macOS, execute um comando dig, semelhante ao seguinte:

dig +nocl TXT o-o.myaddr.l.example.com

No Windows, execute um comando nslookup, semelhante ao seguinte:

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

Se a saída incluir o mesmo endereço IP toda vez que você executar o comando, o resolvedor de DNS não suportará Anycast. Se a saída incluir um endereço IP diferente toda vez que você executar o comando, o resolvedor de DNS suportará Anycast. Isso pode explicar um local da borda inesperado.

O resolvedor de DNS suporta EDNS0-Client-Subnet

Para determinar como você pode evitar o roteamento incorreto, primeiro verifique se o resolvedor de DNS oferece suporte a EDNS0-Client-Subnet executando um destes comandos:

Observação: nesses comandos de exemplo, certifique-se de substituir example.com pelo nome de domínio do resolvedor de DNS que você está usando.

No Linux ou no macOS, execute um comando dig, semelhante ao seguinte:

dig +nocl TXT o-o.myaddr.l.example.com

No Windows, execute um comando nslookup, semelhante ao seguinte:

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

Observação: verifique o valor do TTL e certifique-se de executar o comando quando o TTL expirar. Caso contrário, você poderá obter uma resposta em cache do resolvedor recursivo.

Se o resolvedor de DNS não suportar EDNS0-Client-Subnet, a saída será semelhante à seguinte:

$ dig +nocl TXT o-o.myaddr.l.example.com  +short
"192.0.2.1"

No exemplo anterior, 192.0.2.1 é o endereço IP do servidor DNS mais próximo que está usando o Anycast. Esse resolvedor de DNS não suporta EDNS0-Client-Subnet. Para evitar o roteamento incorreto, você pode fazer o seguinte:

• Mude para um resolvedor de DNS para uma resolução de DNS recursivo que está localizada geograficamente mais próxima dos clientes do seu site.
• Mude para um resolvedor de DNS que suporte EDNS0-Client-Subnet.

Se o resolvedor de DNS suportar EDNS0-Client-Subnet, a saída conterá uma sub-rede cliente truncada (**/24 ** ou /32) para o servidor de nomes com autoridade do CloudFront, semelhante à seguinte:

$ dig +nocl TXT o-o.myaddr.l.example.com @8.8.8.8 +short
"192.0.2.1"
"edns0-client-subnet 198.51.100.0/24"

No exemplo anterior, 192.0.2.1 é o endereço IP do resolvedor de DNS mais próximo. Além disso, o intervalo de cliente-sub-rede é 198.51.100.0/24, que é usado para responder a consultas de DNS. Para evitar o roteamento incorreto quando o resolvedor de DNS oferece suporte a EDNS0-Client-Subnet, confirme se um banco de dados de geolocalização público está associado ao intervalo de cliente-sub-rede que envia a consulta ao resolvedor de DNS. Se o resolvedor de DNS estiver encaminhando a versão truncada dos endereços IP do cliente para os servidores de nomes do CloudFront, o CloudFront verificará um banco de dados baseado em vários bancos de dados de geolocalização públicos. Os endereços IP devem ser mapeados corretamente no banco de dados de geolocalização para que as solicitações sejam roteadas corretamente.

Se o resolvedor de DNS suportar EDNS0-Client-Subnet, você poderá verificar o local da borda para o qual o tráfego é roteado resolvendo primeiro seu CNAME do CloudFront executando um comando de pesquisa de DNS como dig:

$ dig dftex7example.cloudfront.net. +short
13.224.77.109
13.224.77.62
13.224.77.65
13.224.77.75

Em seguida, execute uma pesquisa reversa de DNS nos endereços IP retornados pelo comando anterior:

$ dig -x 13.224.77.62 +short
server-13-224-77-62.man50.r.cloudfront.net.

No exemplo anterior, o tráfego é direcionado para o local da borda de Manchester.

Dica: para um teste adicional, você pode usar um resolvedor de DNS público que suporte EDNS0-client-subnet, como 8.8.8.8 ou 8.8.4.4. Envie consultas com endereços IP de local da borda para o resolvedor de DNS público. Em seguida, verifique os resultados das consultas de DNS para ver se o CloudFront tem as informações corretas sobre EDNS0-client-subnet.

---