¿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 la 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 los problemas de enrutamiento a una ubicación periférica inesperada, compruebe 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 que espera

Compruebe las ubicaciones periféricas que se incluyen en la clase de precio de su distribución de CloudFront. Puede actualizar la clase de precio de su distribución si desea incluir otras ubicaciones periféricas.

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, el solucionador de DNS utiliza varias ubicaciones periféricas. Esto significa que la ubicación periférica del solicitante se basa en una latencia óptima, lo que podría provocar una ubicación inesperada para la dirección IP del solucionador.

Para comprobar si el solucionador de DNS admite la difusión por proximidadejecute uno de estos comandos varias veces:

Nota: En estos comandos de ejemplo, asegúrese de reemplazar example.com por el nombre de dominio del solucionador de DNS que está utilizando.

En Linux o macOS, ejecute un comando dig, similar al siguiente:

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

En Windows, ejecute un comando nslookup similar al siguiente:

nslookup -type=txt o-o.myaddr.l.example.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. Esto podría explicar una ubicación periférica inesperada.

El solucionador de DNS admite EDNS0-Client-Subnet

Para determinar cómo puede evitar un enrutamiento incorrecto, en primer lugar ejecute uno de los comandos a continuación para comprobar si el solucionador de DNS admite EDNS0-Client-Subnet:

Nota: En estos comandos de ejemplo, asegúrese de reemplazar example.com por el nombre de dominio del solucionador de DNS que está utilizando.

En Linux o macOS, ejecute un comando dig, similar al siguiente:

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

En Windows, ejecute un comando nslookup similar al siguiente:

nslookup -type=txt o-o.myaddr.l.example.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.example.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 usa difusión por proximidad. Este solucionador de DNS no admite EDNS0-Client-Subnet. Para evitar un enrutamiento incorrecto, puede seguir uno de estos métodos:

• Cambiar un solucionador de DNS a un solucionador de DNS recursivo que esté ubicado geográficamente más cerca de los clientes de su sitio web.
• Cambiar 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, similar a la siguiente:

$ 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"

En el ejemplo anterior, 192.0.2.1 es la dirección IP del solucionador de DNS más cercano. Además, el rango de cliente-subred es 198.51.100.0/24, que se utiliza para responder a las consultas de DNS. Para evitar un enrutamiento incorrecto cuando el solucionador de DNS sí admite EDNS0-Client-Subnet, confirme que haya una base de datos de geolocalización pública asociada al rango de cliente-subred 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. Las direcciones IP deben estar asignadas correctamente 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, para verificar la ubicación periférica a la que se dirige el tráfico, primero puede ejecutar un comando de búsqueda de DNS, como dig, para resolver su CNAME de CloudFront:

$ 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 de DNS inversa en las direcciones IP devueltas por 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 u 8.8.4.4. 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.

---