¿Cómo puedo solucionar problemas con los registros de recursos basados en latencia y con Route 53?

Descripción breve

Route 53 se resuelve en la región con la latencia más baja en función de la ubicación de la consulta DNS si se cumple lo siguiente:

• Ha asociado puntos de conexión en varias regiones de AWS al mismo registro de recursos.
• Está utilizando una política de enrutamiento basada en la latencia.

Route 53 toma decisiones de enrutamiento basadas en la latencia sobre la base de:

• La dirección IP de origen del solucionador de DNS recursivo que envía la consulta al servidor de nombres autoritativo de Route 53.
• La versión truncada de la dirección IP del cliente (si el solucionador de DNS admite la extensión edns00-client-subnet).

Los servidores de nombres de Route 53 admiten edns0-client-subnet de forma predeterminada. Si un solucionador de DNS recursivo admite edns0-client-subnet, el solucionador de DNS envía a Route 53 una versión truncada de la dirección IP del cliente. A continuación, Route 53 usa esa dirección IP truncada para determinar la región de latencia más baja.

Es posible que la región con la latencia más baja no esté físicamente más cerca del solucionador de DNS. Es posible que experimente un comportamiento de enrutamiento no deseado si el cliente no está en la misma ubicación que el solucionador de DNS. También puede experimentar un comportamiento de enrutamiento no deseado si la dirección IP de la resolución tiene información de ubicación diferente.

Escenario de ejemplo

Una empresa tiene registros de enrutamiento basados en la latencia para dos equilibradores de carga elásticos, uno ubicado en Virginia (us-east-1) y el otro en Irlanda (eu-west-1). Los usuarios de EE. UU. utilizan un solucionador de DNS corporativo ubicado en Europa o se conectan a la oficina corporativa en Europa a través de una VPN.

El solucionador de DNS corporativo no puede enviar datos de la subred edns0-client-a los servidores de nombres autorizados. Por lo tanto, Route 53 considera la dirección IP del solucionador de DNS en Europa como el origen de la consulta. A continuación, Route 53 realiza una búsqueda en su base de datos de latencia y determina incorrectamente que el equilibrador de cargas de Irlanda tiene la latencia más baja.

Si el solucionador de DNS corporativo puede enviar datos de la subred edns0-client-subnet, Route 53 considera la dirección IP truncada del cliente en EE. UU. como el origen de la consulta. A continuación, Route 53 realiza una búsqueda en su base de datos de latencia y determina correctamente que el balanceador de cargas de Virginia tiene la latencia más baja.

Resolución

Siga los siguientes pasos para solucionar problemas de comportamiento de enrutamiento no deseado basado en la latencia:

1.    Compruebe el intervalo de direcciones IP utilizado por el solucionador de DNS. En Linux y macOS, ejecuta el comando dig en bucle. En Windows, ejecute el comando nslookup varias veces. Asegúrese de anotar el resultado cada vez.

En Linux o macOS, ejecute el comando dig en bucle.

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

En Windows, ejecute el comandonslookup varias veces. Asegúrese de anotar el resultado cada vez.

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

2.    Confirme que el solucionador de DNS admite Anycast mediante el resultado del comando anterior. Si la salida siempre contiene la misma dirección IP única, el solucionador de DNS no admite difusión por proximidad. Si la dirección IP cambia al ejecutar el comando varias veces, el solucionador de DNS admite difusión por proximidad.

Cuando un solucionador de DNS admite difusión por proximidad, hay varias ubicaciones periféricas para los solucionadores de DNS. La ubicación periférica de un usuario se selecciona en función de la latencia óptima, lo que puede provocar una ubicación inesperada para la dirección IP del solucionador.

3.    Busque la dirección IP del cliente. Desde el equipo cliente, abra un navegador de Internet y, a continuación, vaya a https://checkip.amazonaws.com/.

O use curl:

curl https://checkip.amazonaws.com/

4.    Compruebe si el solucionador de DNS admite edns0-client-subnet mediante uno de los siguientes comandos. Asegúrese de anotar el resultado.

En Linux o macOS, use dig:

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

En Windows, use nslookup:

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

5.    Compruebe el primer registro TXT devuelto en la sección Respuesta del resultado. Este valor es el servidor DNS más cercano que anuncia difusión por proximidad. Si no hay un segundo registro TXT, el solucionador de DNS no admite edns0-client-subnet. Si hay un segundo registro TXT, el solucionador de DNS admite edns0-client-subnet. La resolución envía una subred de cliente truncada (/24 o /32) al servidor de nombres autoritativo de Route 53.

(Opcional) Si activó el registro de consulta de DNS de Route 53 en su zona alojada, cree un registro de prueba. Realice una búsqueda de DNS para el nuevo registro. Consulte los registros de consultas para confirmar la dirección IP del solucionador y la subred edns0-client-subnet (si la hubiera) presentadas en los servidores de nombres de Route 53.

6.    Compruebe que el valor TTL de la respuesta sea de 60 segundos. Si el TTL no dura 60 segundos, la respuesta es una respuesta almacenada en caché. Repita el comando dig o nslookup hasta que el valor TTL de la respuesta sea de 60 segundos.

7.    Si puede acceder a la herramienta de comprobación de DNS Route 53, simule las consultas desde una resolución de DNS o una dirección IP de cliente específica. Utilice estas consultas para averiguar qué conjunto de registros de recursos de latencia devuelve Route 53.

Si el solucionador de DNS no admite edns0-client-subnet, especifique la dirección IP del solucionador como valor en la herramienta.

Si el solucionador de DNS admite la subred edns0-client-subnet, especifique la IP de la subred del cliente EDNS0 como valor en la herramienta. Elija Configuración adicional, y a continuación, especifique la máscara de subred.

Nota: La herramienta de comprobación de DNS de Route 53 consulta directamente la base de datos de medición de latencia de Route 53. La consulta determina la latencia precalculada entre las regiones de AWS y una red basada en Internet. La herramienta no envía consultas de DNS a través de Internet ni a los solucionadores de DNS. La herramienta no comprueba si el solucionador de DNS admite edns0-client-subnet. Los resultados de la herramienta y de una consulta DNS real pueden diferir.

8.    (Opcional) Si no puede acceder a la herramienta de comprobación de DNS de Route 53, utilicedig. Usando dig, consulte los servidores de nombres autorizados de Route 53 de su zona alojada con edns0-client-subnet. Utilice el resultado para determinar la región de latencia más baja a partir de su dirección IP de origen.

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

**Nota:**La latencia entre los servidores de Internet puede cambiar con el tiempo debido a cambios en la conectividad y el enrutamiento de la red. Por ejemplo, una solicitud que se envíe a la región de Oregón esta semana podría enviarse a la región de Ohio la próxima semana.

9.    **Para los solucionadores que no admiten edns0-client-subnet:**Cambie el solucionador de DNS del cliente por un solucionador de DNS recursivo diferente ubicado geográficamente más cerca del cliente. Si el solucionador no admite edns0-client-subnet, es posible que las consultas de DNS del cliente usen un solucionador de DNS en una ubicación geográfica diferente a la del cliente. El resultado en este escenario es un comportamiento de enrutamiento inesperado.

Si administra el solucionador de DNS, compruebe la configuración de reenvío. Confirme que no está reenviando las consultas de DNS a otro solucionador que esté más alejado de la ubicación geográfica del cliente.

**Para los solucionadores compatibles con edns0-client-subnet:**Compruebe la ubicación geográfica de la dirección IP de la subred del cliente. Para comprobar la ubicación, utilice la base de datos GeoIPdel sitio web de MaxMind o su base de datos GeoIP preferida. Si la ubicación de la dirección IP de la subred del cliente se encuentra en una ubicación geográfica diferente a la del cliente, es posible que experimente un comportamiento de enrutamiento inesperado.

10.    (Opcional) Si el solucionador de DNS no admite edns0-client-subnet, cambie a un solucionador de DNS recursivo público que admita edns0-client-subnet. A continuación, compare sus resultados de respuesta de enrutamiento de latencia anteriores de Route 53 con los nuevos resultados. Por ejemplo, dos solucionadores de DNS públicos que actualmente admiten edns0-client-subnet son GoogleDNS (8.8.8.8 y 8.8.4.4) y OpenDNS (208.67.222.222 y 208.67.220.220).

11.    (Opcional) Determine si los registros de enrutamiento basados en la latencia están asociados a una comprobación de estado de Route 53. Además, determine si Evaluate Target Health (ETH) está activado (para registros de alias). Si uno o ambos son verdaderos, entonces Route 53 devuelve el punto de conexión saludable que tiene la latencia más baja. Si todas las comprobaciones de estado fallan, solo se tiene en cuenta la política de enrutamiento.

Compruebe el estado de su Route 53 en la consola de Route 53. Si ETH está activado, compruebe el estado de salud del punto de conexión de registro. Route 53 considera que un punto de conexión para un equilibrador de carga clásico con ETH activado está en buen estado si al menos una instancia de backend está en buen estado. En el caso de los equilibradores de carga de aplicación y los equilibradores de carga de red, cada grupo de destino con destinos debe contener al menos un destino en buen estado para que se considere saludable. Un grupo de destino sin destinos registrados se considera no saludable. Si algún grupo de destino contiene solo objetivos en mal estado, el balanceador de cargas se considera no saludable.

**Excepción:**Si un equilibrador de carga de aplicaciones tiene al menos un grupo de destino saludable y todos los grupos de destino restantes están vacíos, Route 53 lo considera saludable.

Ejemplo

Tiene dos registros de enrutamiento basados en la latencia con comprobaciones de estado asociadas a la Route 53, uno en Oregón y otro en Virginia del Norte. Cuando se produce un error en la comprobación de estado del punto de conexión de Oregón, todas las solicitudes se envían al punto final de Virginia del Norte, independientemente de la ubicación del cliente.

Información relacionada

Comprobar las respuestas de DNS de Route 53

¿Cómo puedo determinar si mi solucionador de DNS público admite la extensión de subred del cliente EDNS?

¿Cómo puedo solucionar problemas de salud en la Route 53?

¿Por qué mi registro de alias apunta a un equilibrador de carga de aplicación marcado como no saludable cuando utilizo «Evaluate Target Health»?