¿Cómo soluciono el error UnknownHostException en mi aplicación Java?

Breve descripción

UnknownHostException es un mensaje de error habitual en las aplicaciones Java. Este error suele indicar que se ha producido un error en la resolución de DNS. Si una aplicación Java no obtiene una respuesta de DNS válida, es posible que emita un error UnknownHostException.

Además de un problema de DNS, la causa principal de este error puede ser:

• Un problema de software que ha afectado a la resolución de DNS
• Problemas con los controladores
• Interrupción de la red en una instancia de Amazon Elastic Compute Cloud (Amazon EC2)

Solución

Nota: Si se muestran errores al ejecutar comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), asegúrese de utilizar la versión más reciente de AWS CLI.

Cómo determinar la causa principal del error

1. Utilice el protocolo de escritorio remoto (RDP) o Secure Shell (SSH) de Windows para conectarse al servidor que aloja la aplicación Java.
2. Ejecute un comando dig (Linux) o nslookup (Windows) en el nombre de DNS que provocó el error.
3. En función del resultado, revise las siguientes situaciones:

Respuestas válidas de los comandos dig o nslookup

Es probable que surjan problemas a nivel de aplicación si obtiene respuestas válidas de los comandos dig o nslookup, pero sigue recibiendo errores de UnknownHostException en su aplicación Java. Para resolver problemas a nivel de aplicación, pruebe los métodos siguientes:

• Reinicie la aplicación.
• Confirme que la aplicación Java no tenga una caché de DNS defectuosa. Si es posible, configure la aplicación para que se adhiera al TTL de DNS. Para usar un TTL fijo, especifique 60 segundos o menos. Para obtener más información, consulte Setting the JVM TTL for DNS name lookups.

En el siguiente ejemplo, hay un problema de red en el servidor o en el solucionador de DNS. La aplicación no se conecta y, a continuación, se agota el tiempo de espera:

$ dig timeout.example.com

;; global options: +cmd
;; connection timed out; no servers could be reached

Si el comando dig de las instancias de Amazon EC2 muestra que no se pudo acceder a ningún servidor, compruebe si la opción de compatibilidad de DNS está activada para la VPC de origen. Para obtener más información, consulte Amazon DNS server.

En el siguiente ejemplo, la compatibilidad con DNS está deshabilitada a nivel de VPC. La consulta dig y telnet están fallando con el solucionador de VPC (10.1.1.2), mientras que dig se está resolviendo para el servidor DNS de Cloudflare (1.1.1.1).

$ dig google.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

$ telnet 10.1.1.2 53
Trying 10.1.1.2...
telnet:connect to address 10.1.1.2: No route to host

$ dig google.com @1.1.1.1 +short
142.251.16.102
142.251.16.139
142.251.16.138
142.251.16.113
142.251.16.101
142.251.16.100

Respuesta NOERROR válida a la que le falta una sección de respuesta válida

Esta situación suele producirse cuando hay una política de enrutamiento de geolocalización, pero el registro no tiene una respuesta de DNS para la ubicación geográfica del servidor. Puede crear un registro y definir los registros de geolocalización o crear un registro predeterminado.

A continuación se muestra un ejemplo de resultado en este caso:

$ dig noanswer.example.com

;; ->>HEADER<<- opcode: QUERY, <b>status: NOERROR</b>, id: 49948
;; flags: qr rd ra; QUERY: 1,
    ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.   
    300    IN    SOA    ns1.example.com. ns2.example.com. 1 7200 900 1209600 86400

Además, si el registro DNS no se crea en una zona alojada pública y las extensiones de seguridad del sistema de nombres de dominio (DNSSEC) están activadas, se muestra NOERROR - NOANSWER en lugar de NXDOMAIN.

Para verificar el estado de DNSSEC, ejecute el siguiente comando dig para mostrar NSEC: Nota: Sustituya el dominio por su dominio.

dig <domain> +trace

El resultado es similar al siguiente:

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> example.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43917
;; flags: qr rd ra; QUERY: 1, ANSWER:0, AUTHORITY: 1, ADDITIONAL: 1
;; AUTHORITY SECTION:
example.co.uk. 300 IN SOA ns-1578.awsdns-05.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

En el siguiente ejemplo, el resultado de dig muestra NXDOMAIN para los registros DNS que no se han creado y que DNSSEC no está activado:

$ dig example.amazon.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>>
    example.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64351
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; AUTHORITY SECTION:
amazon.com. 24 IN SOA dns-external-master.amazon.com. root.amazon.com. 2010158906 180 60 3024000 60

Respuesta NXDOMAIN o NOERROR (sin respuesta)

Compruebe su zona alojada pública de DNS para confirmar que el registro DNS esté configurado correctamente.

Estado SERVFAIL

Alternativa:

No puedo conectarme al servidor o al solucionador de DNS

Si utiliza una instancia de Amazon EC2 para su aplicación Java, las interrupciones de la red son poco frecuentes, pero pueden ocurrir. Las respuestas dig o nslookup muestran que no se puede conectar repetidamente al servidor o al solucionador de DNS. En este caso, compruebe si hay interrupciones de red activas en su región de AWS.

Si usa un servidor local que se conecta a una zona alojada privada de Route 53 a través de un punto de enlace de Route 53 Resolver, compruebe la configuración del punto de enlace en la VPC. Revise la configuración del grupo de seguridad, la lista de control de acceso de la red (ACL de la red) y la tabla de enrutamiento. Para obtener instrucciones, consulte ¿Cómo soluciono los errores de tiempo de espera de conexión de las instancias de Amazon EC2 desde Internet?

En este ejemplo, el resultado tiene el estado SERVFAIL:

$ dig servfail.example.com

;; ->>HEADER<<- opcode: QUERY, <b>status: SERVFAIL</b>, id: 57632
;; flags: qr rd ra;
    QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Cómo comprobar si la zona alojada privada y la regla del solucionador están asociadas a la VPC de origen

El solucionador de DNS proporcionado por Amazon evalúa la coincidencia más específica en el siguiente orden de prioridad:

1. Regla del solucionador
2. Zona alojada privada
3. Zona alojada pública

Si la consulta de DNS coincide con la regla del solucionador, confirme que la dirección IP de destino responda con la respuesta correcta. Si está utilizando una zona alojada privada, asegúrese de que el registro DNS se haya creado en su zona alojada privada. Si el registro DNS no está presente en una zona alojada privada, no recurre a una zona alojada pública y devuelve NXDOMAIN.

Para obtener más información, consulte Resolving DNS queries between VPCs and your network.

Cómo comprobar si hay problemas de delegación de subdominios

Verifique que se haya creado la delegación de subdominio adecuada entre la zona principal, secundaria y terciaria. Si los servidores de nombres de zona (NS) terciaria están presentes en la zona principal pero faltan en la zona secundaria, se espera que NXDOMAIN sea intermitente. Todos los registros NS de la zona secundaria deben estar presentes en su zona alojada principal.

Cómo evitar problemas intermitentes de resolución de DNS

A continuación se muestra un ejemplo de delegación de dominio:

• Zona principal: example.com
• Zona secundaria: today.example.com
• Zona terciaria: api.today.example.com

Cuando el registro NS de la zona terciaria (api.today.example.com) esté presente en la zona principal (example.com), asegúrese de que también esté presente en la zona secundaria (today.example.com). Para obtener más información, consulte ¿Cómo compruebo si el subdominio delegado se resuelve correctamente?

Si aparece el error UnknownHostException de forma intermitente, puede que los límites de DNS de Amazon EC2 estén contribuyendo a ello. El límite es de 1024 paquetes por segundo por interfaz de red, y no se puede aumentar. La cantidad de consultas de DNS por segundo que admite el servidor DNS proporcionado por Amazon varía según el tipo de consulta, el tamaño de la respuesta y el tipo de protocolo. ¿Cómo puedo determinar si mis consultas de DNS al servidor DNS proporcionado por Amazon dan error debido a la limitación de DNS de la VPC?

---