Come posso risolvere l'errore UnknownHostException nella mia applicazione Java?

Breve descrizione

UnknownHostException è un messaggio di errore comune nelle applicazioni Java. Questo messaggio indica in genere che si è verificato un errore nella risoluzione DNS. Se un'applicazione Java non riesce a ottenere una risposta DNS valida, potrebbe generare un errore UnknownHostException.

Oltre a un problema legato al DNS, l'errore potrebbe anche dipendere da:

• Un problema con il software che ha influito sulla risoluzione DNS
• Problemi con i driver
• Interruzione della rete in un'istanza Amazon Elastic Compute Cloud (Amazon EC2)

Risoluzione

Nota: se visualizzi errori durante l'esecuzione dei comandi dell'Interfaccia della linea di comando AWS (AWS CLI), assicurati di utilizzare la versione più recente di AWS CLI.

Determina la causa principale dell'errore

1. Usa il protocollo Windows Remote Desktop Protocol (RDP) o Secure Shell (SSH) per connetterti al server che ospita l'applicazione Java.
2. Esegui il comando dig (Linux) o nslookup (Windows) sul nome DNS che ha causato l'errore.
3. In base all'output, esamina i seguenti scenari:

Risposte valide dai comandi dig o nslookup

Se si ottengono risposte valide dai comandi dig o nslookup, ma si continua a ricevere errori UnknownHostException nell'applicazione Java, è probabile che i problemi siano a livello di applicazione. Per risolvere i problemi a livello di applicazione, prova i metodi seguenti:

• Riavvia l'applicazione.
• Verifica che l'applicazione Java non abbia una cache DNS errata. Se possibile, configura l'applicazione in modo che aderisca al valore DNS TTL. Per utilizzare un TTL fisso, specifica 60 secondi o un valore inferiore. Per ulteriori informazioni, consulta la pagina Impostazione di JVM TTL per le ricerche del nome DNS.

Nell'esempio seguente è presente un problema di rete sul server o sul resolver DNS. L'applicazione non riesce a connettersi e quindi si verifica il timeout:

$ dig timeout.example.com

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

Se il comando dig delle istanze Amazon EC2 visualizza no servers could be reached (non è stato possibile raggiungere alcun server), verifica se l'opzione di supporto DNS è attiva per il VPC di origine. Per ulteriori informazioni, consulta la pagina Server DNS Amazon.

Nell'esempio seguente, il supporto DNS è disabilitato a livello di VPC. La query dig e telnet per il resolver VPC (10.1.1.2) dà esito negativo, mentre la query dig per il server DNS cloud-flare (1.1.1.1) completa la risoluzione.

$ 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

Risposta valida NOERROR con sezione Risposta valida mancante

Questo scenario si verifica in genere quando esiste una policy di instradamento basato sulla geolocalizzazione, ma il record non ha una risposta DNS per la posizione geografica del server. È possibile creare un record e definire i record di geolocalizzazione oppure creare un record predefinito.

Di seguito è riportato un esempio di output relativo a questo scenario:

$ 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

Inoltre, se il record DNS non viene creato in una zona ospitata pubblica e le Domain Name System Security Extensions (DNSSEC) sono attivate, verrà restituito NOERROR - NOANSWER anziché NXDOMAIN.

Per verificare lo stato delle DNSSEC, esegui il comando dig seguente per visualizzare NSEC: Nota: sostituisci domain con il tuo dominio.

dig <domain> +trace

L'output è simile al seguente:

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

Nell'esempio seguente, l'output del comando dig mostra NXDOMAIN per i record DNS che non vengono creati e il DNSSEC non attivato:

$ 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

Risposta NXDOMAIN o NOERROR (senza risposta)

Controlla la tua zona ospitata pubblica DNS per assicurarti che il record DNS sia configurato correttamente.

Stato SERVFAIL

-oppure-

Impossibile connettersi al resolver o al server DNS

Se utilizzi un'istanza Amazon EC2 per la tua applicazione Java, le interruzioni di rete sono rare, tuttavia possono verificarsi. Le risposte ai comandi dig o nslookup mostrano che non è possibile connettersi ripetutamente al resolver o al server DNS. In questo caso, verifica la presenza di eventuali interruzioni di rete attive nella tua Regione AWS.

Se utilizzi un server on-premises che si connette a una zona ospitata privata di Route 53 tramite un endpoint resolver di Route 53, controlla la configurazione dell'endpoint sul VPC. Controlla le impostazioni per il gruppo di sicurezza, la lista di controllo degli accessi alla rete (ACL) e la tabella di routing. Per maggiori istruzioni consulta la pagina Come posso risolvere gli errori di timeout della connessione dell'istanza Amazon EC2 da Internet?

In questo esempio, l'output presenta lo stato 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

Controlla se la zona ospitata privata e la regola del resolver sono associate al VPC di origine

Il resolver DNS fornito da Amazon valuta la corrispondenza più specifica con il seguente ordine di priorità:

1. Regola del resolver
2. Zona ospitata privata
3. Zona ospitata pubblica

Se la query DNS corrisponde alla regola del resolver, verifica che l'indirizzo IP di destinazione fornisca la risposta corretta. Se utilizzi una zona ospitata privata, assicurati che il record DNS sia stato creato in essa. Se il record DNS non è presente nella zona ospitata privata, non eseguirà il fallback in una zona ospitata pubblica e restituirà NXDOMAIN.

Per ulteriori informazioni, consulta la pagina Risoluzione di query DNS tra i VPC e la rete.

Verifica eventuali problemi correlati alla delega del sottodominio

Verifica che sia stata creata la delega del sottodominio corretta tra zona padre, zona figlio e zona nipote. Se i server dei nomi (NS) della zona nipote sono presenti nella zona padre ma mancano nella zona figlio, si riceverà l'errore NXDOMAIN intermittente. Ogni record NS della zona figlio deve essere presente nella zona ospitata padre.

Per evitare problemi intermittenti di risoluzione DNS

Di seguito è riportato un esempio di delega del dominio:

• Zona padre: example.com
• Zona figlio: today.example.com
• Zona nipote: api.today.example.com

Se il record NS della zona nipote (api.today.example.com) è presente nella zona padre (example.com), assicurati che sia presente anche nella zona figlio (today.example.com). Per ulteriori informazioni, consulta la pagina Come posso verificare se il mio sottodominio delegato si risolve correttamente?

Se ricevi a intermittenza l'errore UnknownHostException, il problema potrebbe risiedere nei limiti DNS di Amazon EC2. Il limite è di 1.024 pacchetti al secondo per interfaccia di rete e non può essere aumentato. Il numero di query DNS al secondo supportate dal server DNS fornito da Amazon varia in base al tipo di query, alla dimensione della risposta e al tipo di protocollo. Per maggiori informazioni, consulta la pagina Come faccio a stabilire se le mie query DNS inoltrate al server DNS fornito da Amazon non vanno a buon fine a causa della limitazione applicata al DNS per il VPC?

---