Wie behebe ich den Fehler UnknownHostException in meiner Java-Anwendung?

Kurzbeschreibung

UnknownHostException ist eine häufige Fehlermeldung in Java-Anwendungen. Dieser Fehler weist in der Regel auf einen Fehler bei der DNS-Auflösung hin. Wenn eine Java-Anwendung keine gültige DNS-Antwort erhält, wird möglicherweise der Fehler UnknownHostException ausgelöst.

Zusätzlich zu einem DNS-Problem könnte die Hauptursache für diesen Fehler eine der folgenden sein:

• Ein Softwareproblem, das sich auf die DNS-Auflösung ausgewirkt hat
• Treiberprobleme
• Ein Netzwerkausfall in einer Amazon Elastic Compute Cloud (Amazon EC2) Instance

Lösung

Hinweis: Wenn Sie beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehler auftreten, stellen Sie sicher, dass Sie die neueste Version von AWS CLI verwenden.

Ermitteln der Fehlerursache

1. Verwenden Sie das Windows Remote Desktop Protocol (RDP) oder Secure Shell (SSH)-Protokoll, um eine Verbindung zu dem Server herzustellen, der Ihre Java-Anwendung hostet.
2. Führen Sie den Befehl dig (Linux) oder nslookup (Windows) für den DNS-Namen aus, der den Fehler verursacht hat.
3. Überprüfen Sie auf der Grundlage der Ergebnisse die folgenden Szenarien:

Gültige Antworten aus den Befehlen dig oder nslookup

Probleme auf Anwendungsebene sind wahrscheinlich, wenn Sie gültige Antworten von den Befehlen dig oder nslookup erhalten, aber weiterhin Fehler des Typs UnknownHostException in Ihrer Java-Anwendung auftreten. Probieren Sie die folgenden Methoden, um Probleme auf Anwendungsebene zu lösen:

• Starten Sie die Anwendung neu.
• Vergewissern Sie sich, dass Ihre Java-Anwendung keinen fehlerhaften DNS-Cache hat. Wenn möglich, konfigurieren Sie die Anwendung so, dass sie die DNS TTL einhält. Um eine feste TTL zu verwenden, geben Sie 60 Sekunden oder weniger an. Weitere Informationen finden Sie unter Einstellen der JVM TTL für DNS-Namensabfragen.

Im folgenden Beispiel liegt ein Netzwerkproblem auf dem Server oder dem DNS Resolver vor. Die Anwendung kann keine Verbindung herstellen und es kommt zu einem Timeout:

$ dig timeout.example.com

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

Wenn der Befehl dig von Amazon EC2 Instances aus anzeigt, dass keine Server erreicht werden konnten, überprüfen Sie, ob die DNS-Unterstützungsoption für die Quell-VPC aktiviert ist. Weitere Informationen finden Sie unter Amazon DNS Server.

Im folgenden Beispiel ist die DNS-Unterstützung auf VPC-Ebene deaktiviert. Die Abfrage dig und telnet gegen den VPC Resolver (10.1.1.2) schlagen fehl, während der Befehl dig für den Cloud-Flare-DNS-Server (1.1.1.1) aufgelöst wird.

$ 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

Gültige Antwort des Typs NOERROR mit fehlendem gültigen Antwortabschnitt

Dieses Szenario wird in der Regel verursacht, wenn es eine Geolocation-Routing-Richtlinie gibt, der Datensatz jedoch keine DNS-Antwort für den geografischen Standort des Servers enthält. Sie können entweder einen Datensatz erstellen und die Geolocation-Datensätze definieren oder einen Standarddatensatz erstellen.

Das Folgende ist eine Beispielausgabe dieses Szenarios:

$ 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

Wenn der DNS-Eintrag nicht in einer öffentlich gehosteten Zone erstellt wurde und Domain Name System Security Extensions (DNSSEC) aktiviert ist, wird NOERROR - NOANSWER anstelle von NXDOMAIN zurückgegeben.

Um den Status von DNSSEC zu überprüfen, führen Sie den folgenden Befehl des Typs dig aus, um NSEC anzuzeigen: **Hinweis:**Ersetzen Sie domain durch Ihre Domain.

dig <domain> +trace

Die Ausgabe sieht etwa so aus:

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

Im folgenden Beispiel zeigt die Ausgabe für dig NXDOMAIN für DNS-Einträge an, die nicht erstellt wurden und für die DNSSEC nicht aktiviert ist:

$ 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

Antwort NXDOMAIN oder NOERROR (ohne Antwort)

Überprüfen Sie Ihre öffentliche gehostete DNS Zone, um sicherzustellen, dass der DNS-Eintrag korrekt konfiguriert ist.

SERVFAIL Status

-oder-

Es kann keine Verbindung zum DNS Resolver oder Server hergestellt werden

Wenn Sie eine Amazon EC2 Instance für Ihre Java-Anwendung verwenden, sind Netzwerkausfälle selten, können aber vorkommen. Die Antworten von dig oder nslookup zeigen, dass Sie wiederholt keine Verbindung zum DNS Resolver oder Server herstellen können. Suchen Sie in diesem Fall nach aktiven Netzwerkausfällen in Ihrer AWS-Region.

Wenn Sie einen On-Premises-Server verwenden, der über einen Route-53-Resolver-Endpunkt eine Verbindung zu einer privat gehosteten Route 53 Zone herstellt, überprüfen Sie die Konfiguration des Endpunkts auf der VPC. Überprüfen Sie die Einstellungen für die Sicherheitsgruppe, die Netzwerk-Zugriffssteuerungsliste (Netzwerk-ACL) und die Routing-Tabelle. Eine Anleitung finden Sie unter Wie behebe ich Timeout-Fehler bei Verbindungen zu Amazon EC2 Instances aus dem Internet?

In diesem Beispiel hat die Ausgabe den Status 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

Prüfen, ob die private gehostete Zone und die Resolver-Regel der Quell-VPC zugeordnet sind

Der von Amazon bereitgestellte DNS Resolver bewertet die spezifischste Übereinstimmung in der folgenden Prioritätsreihenfolge:

1. Resolver-Regel
2. Private gehostete Zone
3. Öffentliche gehostete Zone

Wenn die DNS-Abfrage der Resolver-Regel entspricht, stellen Sie sicher, dass die Ziel-IP-Adresse die richtige Antwort zurückgibt. Wenn Sie eine privat gehostete Zone verwenden, stellen Sie sicher, dass der DNS-Eintrag in Ihrer privat gehosteten Zone erstellt wurde. Wenn der DNS-Eintrag in der privaten gehosteten Zone nicht vorhanden ist, kommt es nicht zu einem Fallback auf eine öffentlich gehostete Zone und NXDOMAIN wird zurückgegeben.

Weitere Informationen finden Sie unter Lösen von DNS-Abfragen zwischen VPCs und Ihrem Netzwerk.

Suchen nach Problemen mit der Subdomain-Delegierung

Stellen Sie sicher, dass die richtige Subdomain-Delegierung zwischen der übergeordneten Zone, untergeordneten Zone und untergeordneten Zone der zweiten Ebene erstellt wurde. Wenn Name Server (NS) der untergeordneten Zone der zweiten Ebene in der übergeordneten Zone vorhanden sind, in der untergeordneten Zone aber fehlen, wird ein zeitweiliges NXDOMAIN erwartet. Jeder NS-Eintrag einer untergeordneten Zone muss in der übergeordneten gehosteten Zone vorhanden sein.

So vermeiden Sie zeitweilige Probleme mit der DNS-Auflösung

Das Folgende ist ein Beispiel für eine Domain-Delegierung:

• Übergeordnete Zone: example.com
• Untergeordnete Zone: today.example.com
• Untergeordnete Zone der zweiten Ebene: api.today.example.com

Wenn der NS-Eintrag der untergeordneten Zone der zweiten Ebene (api.today.example.com) in der übergeordneten Zone (example.com) vorhanden ist, stellen Sie sicher, dass er auch in der untergeordneten Zone (today.example.com) vorhanden ist. Weitere Informationen finden Sie unter Wie teste ich, ob meine delegierte Subdomain korrekt aufgelöst wird?

Wenn Sie zeitweise den Fehler UnknownHostException erhalten, können Amazon-EC2-DNS-Grenzwerte eine Rolle spielen. Das Limit liegt bei 1.024 Paketen pro Sekunde pro Netzwerkschnittstelle und kann nicht erhöht werden. Die Anzahl der DNS-Abfragen pro Sekunde, die vom von Amazon bereitgestellten DNS-Server unterstützt werden, variiert je nach Abfragetyp, Antwortgröße und Protokolltyp. Weitere Informationen finden Sie unter Wie kann ich feststellen, ob meine DNS-Abfragen an den von Amazon bereitgestellten DNS Server aufgrund einer VPC-DNS-Drosselung fehlschlagen?

---