Comment puis-je 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’un échec de résolution DNS s’est produit. Si une application Java ne parvient pas à obtenir une réponse DNS valide, elle peut générer une erreur UnknownHostException.

Outre un problème de DNS, la cause première de cette erreur peut être :

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

Résolution

Remarque : si des erreurs surviennent lors de l’exécution des commandes de l’interface de la ligne de commande AWS (AWS CLI), vérifiez que vous utilisez la version la plus récente d’AWS CLI.

Déterminez la cause première de l’erreur

1. Utilisez le protocole RDP (Windows Remote Desktop Protocol) ou le protocole Secure Shell (SSH) pour vous connecter au serveur qui héberge l’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 des résultats, examinez les scénarios suivants :

Réponses valides provenant des commandes dig ou nslookup

Si vous obtenez des réponses valides à partir des commandes dig ou nslookup, mais que vous continuez à recevoir des erreurs UnknownHostException dans l’application Java, les 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.
• Vérifiez que le cache DNS de l’application n’est pas corrompu. Si possible, configurez votre application pour qu’elle respecte le TTL DNS. Pour utiliser un TTL fixe, spécifiez 60 secondes ou moins. Pour en savoir plus, consultez Configuration de la durée de vie de la JVM pour les recherches de noms DNS.

Dans l’exemple suivant, il existe 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 plus d’informations, consultez Serveur DNS Amazon.

Dans l’exemple suivant, la prise en charge du DNS est désactivée au niveau du VPC. Les requêtes dig et telnet sur le résolveur VPC (10.1.1.2) échouent, alors que la requête dig sur 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 stratégie de routage par géolocalisation, mais que l’enregistrement ne contient 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 des 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 le domaine par votre domaine.

dig <domain> +trace

La sortie ressemble à ce qui suit :

; <<>> 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 dig affiche NXDOMAIN pour les enregistrements DNS qui n’ont pas été créés et la DNSSEC n’est pas activée :

$ 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 la zone hébergée publique de votre DNS pour confirmer que l’enregistrement DNS est correctement configuré.

État SERVFAIL

-or-

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

Si vous utilisez une instance Amazon EC2 pour votre application Java, les pannes de 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 la présence de pannes de 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 la page Comment puis-je corriger les erreurs de délai d’expiration de connexion d’instance Amazon EC2 depuis Internet ?

Dans cet exemple, la sortie présente l’état 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 de résolution 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, vérifiez que l’adresse IP cible répond correctement. Si vous utilisez une zone hébergée privée, assurez-vous que l’enregistrement DNS est bien créé dans votre zone hébergée privée. Si l’enregistrement DNS n’est pas présent dans la zone hébergée 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.

Vérifiez les problèmes de délégation de sous-domaines

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

Si 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 l’est également dans la zone enfant (today.example.com). Pour plus d’informations, consultez Comment puis-je vérifier si mon sous-domaine délégué effectue correctement la résolution ?

Si vous obtenez l’erreur UnknownHostException par intermittence, les limites DNS d’Amazon EC2 peuvent être un facteur. La limite est fixée à 1 024 paquets par seconde par interface réseau, et elle ne peut pas être augmentée. Le nombre de requêtes DNS par seconde pris 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 ?

---