¿Por qué el tráfico de mi contenido web se dirige a la ubicación periférica de CloudFront incorrecta?

Descripción corta

CloudFront dirige el tráfico en función de la clase de precio de la distribución, las bases de datos de geolocalización asociadas y la compatibilidad con EDNS0-Client-Subnet. Según una combinación de estos factores, es posible que los visitantes de su sitio web se dirijan a una ubicación periférica inesperada. Esto puede aumentar la latencia general para recuperar un objeto de una ubicación periférica de CloudFront.

Para solucionar problemas con el tráfico que se dirige a una ubicación periférica inesperada, confirme lo siguiente:

• La clase de precio admite la ubicación periférica que se espera.
• El solucionador de DNS admite el enrutamiento de difusión por proximidad.
• El solucionador de DNS admite EDNS0-Client-Subnet.

Resolución

La clase de precio admite la ubicación periférica esperada

Compruebe las ubicaciones periféricas que se incluyen en la clase de precio de su distribución de CloudFront. Para incluir otras ubicaciones periféricas, cambie su clase de precio.

El solucionador de DNS admite el enrutamiento de difusión por proximidad

Si el solucionador de DNS admite el enrutamiento de difusión por proximidad, entonces el solucionador de DNS utiliza varias ubicaciones periféricas. Como la ubicación periférica del solicitante se basa en una latencia óptima, es posible que la dirección IP del solucionador se encuentre en una ubicación inesperada.

Para comprobar si el solucionador de DNS admite la difusión por proximidad, ejecute uno de los siguientes comandos varias veces.

Sistemas operativos (SO) distintos de Windows:

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

Windows:

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

Si el resultado incluye la misma dirección IP cada vez que ejecuta el comando, el solucionador de DNS no admite la difusión por proximidad. Si el resultado incluye una dirección IP diferente cada vez que ejecuta el comando, el solucionador de DNS admite la difusión por proximidad. 

El solucionador de DNS admite EDNS0-Client-Subnet

Ejecute uno de los siguientes comandos para comprobar si el solucionador de DNS admite EDNS0-Client-Subnet.

Sistemas operativos distintos de Windows:

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

Windows:

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

Nota: Compruebe el valor del TTL y asegúrese de ejecutar el comando cuando el TTL caduque. De lo contrario, es posible que obtenga una respuesta en caché del solucionador recursivo.

Si el solucionador de DNS no admite EDNS0-Client-Subnet, el resultado es similar al siguiente:

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

En el ejemplo anterior, 192.0.2.1 es la dirección IP del servidor DNS más cercano que usó la difusión por proximidad. El solucionador de DNS no admite EDNS0-Client-Subnet.

Para asegurarse de que el tráfico del sitio web se enruta a la ubicación correcta, realice una de las siguientes acciones:

• Cambie el solucionador de DNS a un solucionador de DNS recursivo que esté ubicado geográficamente más cerca de los clientes de su sitio web.
• Cambie a un solucionador de DNS que sí admita EDNS0-Client-Subnet.

Si el solucionador de DNS admite EDNS0-Client-Subnet, el resultado contiene una subred de cliente truncada (/24 o /32) para el servidor de nombres autorizados de CloudFront:

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

En el ejemplo anterior, 192.0.2.1 es la dirección IP del solucionador de DNS más cercano. El rango de subredes de cliente que se usa para responder a la consulta de DNS es 198.51.100.0/24.

Incluso si su solucionador de DNS admite EDNS0-Client-Subnet, es posible que el tráfico de su sitio web siga enrutándose incorrectamente. Para resolver este problema, asocie una base de datos de geolocalización pública al rango de subredes del cliente que envía la consulta al solucionador de DNS. Si el solucionador de DNS reenvía la versión truncada de las direcciones IP del cliente a los servidores de nombres de CloudFront, CloudFront comprueba una base de datos que se basa en varias bases de datos de geolocalización públicas.

Debe asignar correctamente las direcciones IP en la base de datos de geolocalización para que las solicitudes se envíen correctamente.

Si el solucionador de DNS admite EDNS0-Client-Subnet, ejecute el siguiente comando de búsqueda de DNS para determinar la ubicación periférica a la que se dirige el tráfico:

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

A continuación, ejecute una búsqueda DNS inversa en las direcciones IP que devuelva el comando anterior:

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

En el ejemplo anterior, el tráfico se dirige a la ubicación periférica de Mánchester.

Consejo: Para realizar una prueba adicional, puede utilizar un solucionador de DNS público que admita EDNS0-Client-Subnet, como 8.8.8.8, 8.8.4.4 o 1.1.1.1. Envíe consultas con direcciones IP de ubicación periférica al solucionador de DNS público. A continuación, compruebe los resultados de las consultas de DNS para comprobar si CloudFront tiene la información correcta sobre EDNS0-Client-Subnet.