Como soluciono o erro UnknownHostException na minha aplicação Java?

Breve descrição

**UnknownHostException ** é uma mensagem de erro comum em aplicações Java. Esse erro normalmente indica que houve uma falha na resolução do DNS. Se uma aplicação Java não conseguir obter uma resposta de DNS válida, ela poderá gerar um erro UnknownHostException.

Além de um problema de DNS, a causa raiz desse erro pode ser:

• Um problema de software que afetou a resolução do DNS
• Problemas com o driver
• Uma interrupção de rede em uma instância do Amazon Elastic Compute Cloud (Amazon EC2).

Resolução

Observação: se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), certifique-se de estar usando a versão mais recente da AWS CLI.

Determine a causa raiz do erro

1. Use o protocolo Windows Remote Desktop Protocol (RDP) ou Secure Shell (SSH) para se conectar ao servidor que hospeda sua aplicação Java.
2. Execute um comando dig (Linux) ou um comando upsilon (Windows) no nome DNS que causou o erro.
3. Com base na saída, analise os seguintes cenários:

Respostas válidas dos comandos dig ou nslookup

É provável que haja problemas no nível da aplicação se você obtiver respostas válidas dos comandos dig ou nslookup , mas continuar recebendo erros de UnknownHostException em sua aplicação Java. Para resolver problemas no nível da aplicação, tente os seguintes métodos:

• Reinicie sua aplicação.
• Confirme se sua aplicação Java não tem um cache de DNS incorreto. Se possível, configure sua aplicação para aderir ao TTL do DNS. Para usar um TTL fixo, especifique 60 segundos ou menos. Para mais informações, consulte Setting the JVM TTL for DNS name lookups.

No exemplo a seguir, há um problema de rede no servidor ou no resolvedor de DNS. A aplicação não consegue se conectar e, em seguida, atinge o tempo limite:

$ dig timeout.example.com

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

Se o comando ** dig** das instâncias do Amazon EC2 mostrar que nenhum servidor pôde ser acessado, verifique se a opção de suporte de DNS está ativada para a VPC de origem. Para mais informações, consulte Servidor DNS da Amazon.

No exemplo a seguir, o suporte ao DNS está desativado no nível da VPC. A consulta da dig e o telnet contra o resolvedor de VPC (10.1.1.2) estão falhando, enquanto o servidor DNS do dig para cloud-flare (1.1.1.1) está sendo resolvido.

$ 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

**Resposta NOERROR válida sem seção de resposta válida **

Esse cenário geralmente é causado quando há uma política de roteamento de geolocalização, mas o registro não tem uma resposta de DNS para a localização geográfica do servidor. Você pode criar um registro e definir os registros de geolocalização ou criar um registro padrão.

Veja a seguir um exemplo de saída desse cenário:

$ 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

Além disso, se o registro DNS não for criado em uma zona hospedada pública e as Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC) estiverem ativadas, NOERROR -NOANSWER será retornado em vez de NXDOMAIN.

Para verificar o status do DNSSEC, execute o seguinte comando dig para mostrar o NSEC: **Observação:**substitua o domínio pelo seu domínio.

dig <domain> +trace

A saída é semelhante a:

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

No exemplo a seguir, a saída dig mostra NXDOMAIN para registros DNS que não foram criados e o DNSSEC não está ativado:

$ 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

Resposta NXDOMAIN ou NOERROR (sem resposta)

Verifique sua zona pública hospedada de DNS para confirmar se o registro DNS está configurado corretamente.

Status SERVFAIL

-ou-

Não é possível se conectar ao resolvedor ou servidor DNS

Se você usa uma instância do Amazon EC2 para sua aplicação Java, as interrupções de rede são raras, mas podem acontecer. As respostas dig ou nslookup mostram que você não consegue se conectar repetidamente ao resolvedor ou servidor DNS. Nesse caso, verifique se há interrupções de rede ativas na sua região da AWS.

Se você usa um servidor local que se conecta a uma zona hospedada privada do Route 53 por meio de um endpoint de resolução do Route 53, verifique a configuração do endpoint na VPC. Revise as configurações do grupo de segurança, da lista de controle de acesso à rede (ACL de rede) e da tabela de rotas. Para resolver esse erro, consulte Como soluciono problemas de tempo de conexão expirado da instância do Amazon EC2 na Internet?

Neste exemplo, a saída tem um 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

Verifique se a zona hospedada privada e a regra do resolvedor estão associadas à VPC de origem

O resolvedor de DNS fornecido pela Amazon avalia a correspondência mais específica, na seguinte ordem de prioridade:

1. Regra do resolvedor
2. Zona hospedada privada
3. Zona hospedada pública

Se a consulta de DNS corresponder à regra do resolvedor, confirme se o endereço IP de destino está respondendo com a resposta correta. Se você estiver usando uma zona hospedada privada, certifique-se de que o registro DNS seja criado na sua zona hospedada privada. Se o registro DNS não estiver presente na zona hospedada privada, ele não retornará para uma zona hospedada pública e retornará NXDOMAIN.

Para mais informações, consulte Resolver consultas de DNS entre VPCs e sua rede.

Verifique se há problemas de delegação de subdomínios

Verifique se a delegação de subdomínio adequada foi criada entre as zonas principais, secundárias e terciárias. Se servidores de nomes de zonas terciárias (NS) estiverem presentes na zona principal, mas estiverem ausentes na zona secundária, espera-se um NXDOMAIN intermitente. Cada registro NS da zona secundária deve estar presente em sua zona hospedada principal.

Para evitar problemas intermitentes de resolução de DNS

Veja a seguir um exemplo de delegação de domínio:

• Zona principal: example.com
• Zona secundária: today.example.com
• Zona de terciária: api.today.example.com

Quando o registro NS da zona terciária (api.today.example.com) estiver presente na zona principal (example.com), verifique se ele também está presente na zona secundária (today.example.com). Para mais informações, consulte Como faço para testar se meu subdomínio delegado é resolvido corretamente?

Se você receber o erro UnknownHostException de forma intermitente, os limites de DNS do Amazon EC2 podem ser um fator. O limite é de 1.024 pacotes por segundo por interface de rede, e esse limite não pode ser aumentado. O número de consultas de DNS por segundo suportado pelo servidor DNS fornecido pela Amazon varia de acordo com o tipo de consulta, tamanho da resposta e tipo de protocolo. Para mais informações, consulte Como faço para determinar se minhas consultas de DNS ao servidor DNS fornecido pela Amazon estão falhando devido à limitação do DNS da VPC?

---