Comment résoudre l'erreur UnknownHostException dans mon application Java ?

Dernière mise à jour : 14/06/2022

Comment résoudre l'erreur UnknownHostException dans mon application Java ?

Brève description

UnknownHostException est un message d'erreur courant dans les applications Java. Cette erreur indique généralement qu'une résolution DNS a échoué. Si une application Java ne parvient pas à obtenir une réponse DNS valide, elle peut générer une erreur UnknownHostException.

En plus d'un problème DNS, la cause racine de cette erreur peut être :

  • Un problème logiciel qui a affecté la résolution DNS
  • Des problèmes de pilote
  • Une panne réseau dans une instance Amazon Elastic Compute Cloud (Amazon EC2)

Solution

Remarque : en cas d'erreurs lors de l'exécution de commandes depuis l'interface de ligne de commande AWS (AWS CLI), vérifiez que vous utilisez la version la plus récente d'AWS CLI.

Déterminer la cause racine de l'erreur

  1. Utilisez le protocole RDP (Windows Remote Desktop Protocol) ou SSH (Secure Shell) pour vous connecter au serveur qui héberge votre application Java.
  2. Exécutez une commande dig (Linux) ou nslookup (Windows) sur le nom DNS à l'origine de l'erreur.
  3. Sur la base de la sortie, examinez les scénarios suivants :

Réponses valides à partir des commandes dig ou nslookup

Si vous obtenez des réponses valides à partir des commandes dig ou nslookup, mais continuez à recevoir des erreurs UnknownHostException dans votre application Java, vos problèmes se situent probablement au niveau de l'application. Pour résoudre les problèmes au niveau de l'application, essayez les méthodes suivantes :

  • Redémarrez votre application.
  • Confirmez que votre application Java n'a pas de cache DNS défectueux. Si possible, configurez votre application pour qu'elle adhère à la durée de vie (TTL) DNS. Pour utiliser une TTL fixe, spécifiez 60 secondes ou moins. Pour plus d'informations, consultez Définition de la TTL JVM pour les recherches de noms DNS.

Dans l'exemple suivant, il y a un problème de réseau au niveau du serveur ou du résolveur DNS. L'application ne parvient pas à se connecter, puis expire :

$ dig timeout.example.com

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

Si la commande dig des instances Amazon EC2 montre qu'aucun serveur n'a pu être atteint, vérifiez alors si l'option de prise en charge de DNS est activée pour le VPC source. Pour en savoir plus, consultez Serveur Amazon DNS.

Dans l'exemple suivant, la prise en charge de DNS est désactivée au niveau du VPC. La requête de dig et telnet contre le résolveur VPC (10.1.1.2) échoue, alors que la requête de dig pour le serveur DNS cloud-flare (1.1.1.1) se résout.

$ 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

Réponse NOERROR valide avec section de réponse valide manquante

Ce scénario se produit généralement lorsqu'il existe une politique de routage de géolocalisation, mais que l'enregistrement n'a pas de réponse DNS pour l'emplacement géographique du serveur. Vous pouvez soit créer un enregistrement et définir les enregistrements de géolocalisation, soit créer un enregistrement par défaut.

Voici un exemple de sortie de ce scénario :

$ 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

De plus, si l'enregistrement DNS n'est pas créé dans une zone hébergée publique et que les extensions de sécurité du système de noms de domaine (DNSSEC) sont activées, alors NOERROR - NOANSWER est renvoyé au lieu de NXDOMAIN.

Pour vérifier l'état de DNSSEC, exécutez la commande dig suivante, pour afficher NSEC : Remarque : remplacez domain par votre domaine.

dig <domain> +trace

La sortie ressemble à :

; <<>> 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

Dans l'exemple suivant, la sortie de dig indique NXDOMAIN pour les enregistrements DNS qui n'ont pas été créés et DNSSEC n'est pas activé :

$ 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

Réponse NXDOMAIN ou NOERROR (sans réponse)

Vérifiez votre zone hébergée publique DNS pour confirmer que l'enregistrement DNS est correctement configuré.

Statut SERVFAIL

-ou-

Impossible de se connecter au résolveur ou au serveur DNS

Si vous utilisez une instance Amazon EC2 pour votre application Java, les pannes réseau sont rares, mais elles peuvent se produire. Les réponses de dig ou nslookup montrent que vous ne pouvez pas vous connecter au résolveur ou au serveur DNS de façon répétée. Dans ce cas, vérifiez les pannes réseau en cours dans votre région AWS.

Si vous utilisez un serveur sur site qui se connecte à une zone hébergée privée Route 53 via un point de terminaison du résolveur Route 53, vérifiez la configuration du point de terminaison sur le VPC. Vérifiez les paramètres du groupe de sécurité, de la liste de contrôle d'accès au réseau (ACL réseau) et de la table de routage. Pour obtenir des instructions, consultez Comment résoudre les erreurs de délai d'expiration de connexion d'instance Amazon EC2 depuis Internet ?

Dans cet exemple, la sortie a le statut 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

Vérifiez si la zone hébergée privée et la règle du résolveur sont associées au VPC source

Le résolveur DNS fourni par Amazon évalue la correspondance la plus spécifique, dans l'ordre de priorité suivant :

  1. Règle du résolveur
  2. Zone hébergée privée
  3. Zone hébergée publique

Si la requête DNS correspond à la règle du résolveur, confirmez alors que la réponse de l'adresse IP cible est correcte. Si vous utilisez une zone hébergée privée, assurez-vous que l'enregistrement DNS est créé dans votre zone hébergée privée. Si l'enregistrement DNS n'est pas présent dans la zone d'hébergement privée, le système ne bascule pas vers une zone hébergée publique et renvoie NXDOMAIN.

Pour plus d'informations, consultez Résolution des requêtes DNS entre les VPC et votre réseau.

Rechercher des problèmes de délégation de sous-domaine

Vérifiez que la délégation de sous-domaine appropriée est créée entre la zone parent, enfant et petit-enfant. Si les serveurs de noms (NS) de la zone petit-enfant sont présents dans la zone parent mais manquent dans la zone enfant, il faut s'attendre à un NXDOMAIN intermittent. Chaque enregistrement NS de la zone enfant doit être présent dans sa zone parent hébergée.

Pour éviter les problèmes de résolution DNS intermittents

Voici un exemple de délégation de domaine :

  • Zone parent : example.com
  • Zone enfant : today.example.com
  • Zone petit-enfant : api.today.example.com

Lorsque l'enregistrement NS de la zone petit-enfant (api.today.example.com) est présent dans la zone parent (example.com), assurez-vous qu'il est également présent dans la zone enfant (today.example.com). Pour plus d'informations, consultez Comment tester si mon sous-domaine délégué effectue correctement la résolution ?

Si vous obtenez par intermittence l'erreur UnknownHostException, les limites DNS Amazon EC2 peuvent être un facteur. La limite est fixée à 1 024 paquets par seconde et par interface réseau, et elle ne peut pas être augmentée. Le nombre de requêtes DNS par seconde prises en charge par le serveur DNS fourni par Amazon varie selon le type de requête, la taille de réponse et le type de protocole. Pour plus d'informations, consultez Comment puis-je déterminer si mes requêtes DNS envoyées vers le serveur DNS fourni par Amazon échouent en raison de limitations DNS du VPC ?


Cet article vous a-t-il été utile ?


Avez-vous besoin d'aide pour une question technique ou de facturation ?