¿Cómo soluciono los problemas de enrutamiento de geolocalización de Route 53?

7 minutos de lectura
0

Mis consultas de DNS devuelven una dirección IP de un servidor web en otra región de AWS. Por ejemplo, un usuario de Estados Unidos está siendo redirigido a una dirección IP de un servidor web ubicado en Europa.

Resolución

Los problemas de enrutamiento por geolocalización de la Ruta 53 se deben a los siguientes problemas:

  • Falta una ubicación predeterminada en su configuración de enrutamiento por geolocalización.
  • El solucionador de DNS no admite la extensión edns0-client-subnet de EDNS0. Esto lleva a una determinación inexacta de su ubicación.
  • Los solucionadores de DNS son geográficamente diversos.
  • Hay cambios en el DNS de los registros de recursos que no se han propagado a nivel mundial.

Para resolver estos problemas, haga lo siguiente:

1.    Confirme que los registros de recursos de su zona alojada de Route 53 estén configurados correctamente para su caso de uso. Además, confirme que haya un registro de recursos predeterminado establecido. Desde la consola de Route 53, compruebe la ubicación predeterminada especificada en la configuración de la zona alojada de Route 53.

Ejemplo: Tenga en cuenta el siguiente ejemplo de resultado:

>> dig images.example.com

; <<>> DiG
9.8.2rc1-RedHat-9.8.2-0.37.rc1.45.amzn1 <<>> images.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 51385
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0

;; QUESTION SECTION
;images.example.com.    IN            A

;; AUTHORITY SECTION:
images.example.com.    60          IN           SOA        ns-1875.awsdns-42.co.uk.awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 65 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Tue Feb  7 22:02:30 2017
;; MSG SIZE  rcvd: 124

En el ejemplo anterior, no hay una ubicación predeterminada especificada en la configuración de enrutamiento de geolocalización. Por lo tanto, si la geolocalización no coincide, la respuesta de DNS devuelve NOERROR para el campo rcode y no aparece ningún resultado en la sección ANSWER. Para corregir este problema, agrega una ubicación predeterminada en la configuración de enrutamiento de geolocalización.

2.    Para comprobar el intervalo de direcciones IP del solucionador de DNS, ejecute los siguientes comandos y anote el resultado.

En Linux o macOS, use dig:

for i in {1..10}; do dig +short resolver-identity.cloudfront.net; sleep 11; done;

En Windows, utilice nslookup:

for /l %i in (1,1,10) do (nslookup resolver-identity.cloudfront.net && timeout /t 11 /nobreak)

3.    Compruebe si el solucionador de DNS admite edns0-Client-Subnet mediante uno de los siguientes comandos y anote el resultado.

En Linux o macOS, use dig:

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

En Windows, utilice nslookup:

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

Revise el primer registro TXT devuelto en la sección de Respuesta del resultado. El primer valor del registro TXT es la dirección IP del solucionador de DNS. 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. El solucionador proporciona una dirección IP de subred de cliente truncada (/24 o /32) al servidor de nombres autorizado de Route 53. Para obtener más información, consulte ¿Cómo puedo determinar si mi solucionador de DNS público admite la extensión de subred del cliente EDNS (ECS)?

4.    Utilice el conjunto de registros de prueba de Route 53 de la herramienta de comprobación para determinar los registros de recursos que se devuelven para una solicitud específica. Para obtener más información, consulte Uso de la herramienta de comprobación para ver cómo responde Amazon Route 53 a las consultas de DNS.

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

Si el solucionador de DNS admite edns0-client-subnet, especifique la dirección IP de la subred del cliente EDNS0 como valor en la herramienta. Elija Más opciones, y a continuación, especifique la máscara de Subred. No especifique una dirección IP del solucionador.

5.    (Opcional) Si no tiene acceso a la herramienta de comprobación, utilice dig para consultar los servidores de nombres autorizados de Route 53 de su zona alojada con edNS0-client-subnet. Utilice el resultado para determinar la respuesta autorizada del registro de geolocalización para su dirección IP de origen:

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

6.    Los servidores de nombres de Route 53 admiten la extensión edns0-client-subnet de EDNS0. El solucionador o servidor DNS local añade edns0-client-subnet a la consulta de DNS para realizar una búsqueda de DNS basada en la subred IP de origen del cliente. Si estos datos no se transmiten con la solicitud, Route 53 usa la dirección IP de origen del solucionador de DNS para aproximarse a la ubicación del cliente. A continuación, Route 53 responde a las consultas de geolocalización con el registro DNS de la ubicación del solucionador. Los datos del EDNS0 deben pasarse a Route 53 y el cliente debe utilizar un servidor de nombres recursivo geográficamente más cercano. De lo contrario, el resultado es una ubicación subóptima que envía el registro de recursos incorrecto a la consulta de DNS.

Para corregir esta configuración, cambie el servidor DNS recursivo que admite edns0-client-subnet. Realice la resolución de DNS y, a continuación, comparta la salida. Si el servidor DNS recursivo no admite la subred edns0-client-subred, intente utilizar uno que sí lo haga. Las opciones que admiten edns0-client-subnet incluyen los solucionadores DNS de Google y OpenDNS.

7.    Compruebe la ubicación geográfica de la dirección IP de la subred del cliente utilizando la base de datos GeoIP del sitio web de MaxMind o su base de datos GeoIP preferida. Compruebe que el solucionador de DNS esté geográficamente cerca de la dirección IP pública del cliente. Si la respuesta o el país que aparecen en el sitio web de MaxMind no coinciden con la respuesta que dio Route 53, es posible que los datos geográficos de producción de Route 53 estén obsoletos. Si hay un enrutamiento obsoleto, entonces póngase en contacto con AWS Support.

8.    Compruebe si hay problemas con la propagación del DNS mediante una herramienta como CacheCheck en el sitio de OpenDNS.

9.    (Opcional) Determine si los registros de enrutamiento basados en la geografía están asociados a una comprobación de estado de la Ruta 53. Además, determine si Evaluar el estado del destino (ETH) está activado para los registros de alias. Si alguno de los dos es verdadero, Route 53 devuelve el punto final en buen estado que mejor coincide con la ubicación de origen.

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

Ejemplo: Tiene registros de Texas en EE. UU., Norteamérica y todas las ubicaciones (la ubicación es predeterminada). Además, tiene consultas que se originan en Texas con un punto de conexión en mal estado. Route 53 comprueba EE. UU., Norteamérica y, a continuación, todas las ubicaciones, en ese orden, hasta que encuentre un registro con un punto de conexión en buen estado. Si el registro de EE. UU. está en buen estado, Route 53 devuelve este punto de conexión. De lo contrario, Route 53 devuelve un registro predeterminado. Si todos los registros aplicables no están en buen estado, Route 53 responde a la consulta de DNS utilizando el valor del registro de la región geográfica más pequeña.

Nota: Los cambios en los registros de recursos de geolocalización con alias pueden tardar hasta 60 segundos en propagarse.

Información relacionada

¿Cómo puedo solucionar problemas de comprobación de estado en la Ruta 53 en mal estado?

¿Por qué mi registro de alias apunta a un equilibrador de carga de aplicaciones marcado como en mal estado cuando utilizo «Evaluar estado del destino»?

Comprobación de las respuestas de DNS de Amazon Route 53

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace un año