Java 애플리케이션의 UnknownHostException 오류를 해결하려면 어떻게 해야 합니까?

간략한 설명

UnknownHostException은 Java 애플리케이션의 일반적인 오류 메시지입니다. 이 오류는 일반적으로 DNS 확인 오류가 있음을 나타냅니다. Java 애플리케이션에서 유효한 DNS 응답을 받지 못하는 경우, UnknownHostException 오류가 발생할 수 있습니다.

DNS 문제에 더해 이 오류의 근본 원인은 다음과 같습니다.

• DNS 확인에 영향을 미치는 소프트웨어 문제
• 드라이버 문제
• Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 네트워크 중단

해결 방법

참고: AWS 명령줄 인터페이스(AWS CLI) 명령을 실행할 때 오류가 발생할 경우 AWS CLI의 최신 버전을 사용하고 있는지 확인하세요.

오류의 근본 원인 결정

1. Windows 원격 데스크톱 프로토콜(RDP) 또는 Secure Shell(SSH) 프로토콜을 사용하여 Java 애플리케이션을 호스팅하는 서버에 연결합니다.
2. 오류를 일으킨 DNS 이름에 대해 dig 명령(Linux) 또는 nslookup 명령(Windows)을 실행합니다.
3. 결과에 따라 다음 시나리오를 검토합니다.

dig 또는 nslookup 명령의 유효한 답변

dig 또는 nslookup 명령에서 유효한 응답을 받았지만 Java 애플리케이션에서 UnknownHostException 오류가 계속 발생하는 경우 애플리케이션 수준 문제일 수 있습니다. 애플리케이션 수준 문제를 해결하려면 다음 방법을 시도해 보세요.

• 애플리케이션을 다시 시작합니다.
• Java 애플리케이션에 잘못된 DNS 캐시가 없는지 확인합니다. 가능하면 DNS TTL을 준수하도록 애플리케이션을 구성합니다. 고정 TTL을 사용하려면 60초 이하를 지정합니다. 자세한 내용은 DNS 이름 조회에 대한 JVM TTL 설정을 참조하십시오.

다음 예제에서는 서버 또는 DNS 확인자에서 네트워킹 문제가 있습니다. 애플리케이션이 연결하지 못해 제한 시간이 초과됩니다.

$ dig timeout.example.com

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

Amazon EC2 인스턴스의 dig 명령에 연결할 수 있는 서버가 없다고 표시되면, 원본 VPC에 대해 DNS 지원 옵션이 켜져 있는지 확인합니다. 자세한 내용은 Amazon DNS 서버를 참조하십시오.

다음 예제에서는 DNS 지원이 VPC 수준에서 비활성화되어 있습니다. VPC 확인자(10.1.1.2) 에 대한 dig 쿼리 및 telnet이 클라우드 플레어 DNS 서버(1.1.1.1) 에 대한 dig를 확인하는 동안 실패합니다.

$ 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

유효한 답변 섹션이 누락된 유효한 NOERROR 응답

이 시나리오는 일반적으로 지리적 위치 라우팅 정책이 있지만 레코드에 서버의 지리적 위치에 대한 DNS 응답을 보유하지 않은 경우에 발생합니다. 레코드를 생성하고, 지리적 위치 레코드를 정의하거나, 기본 레코드를 생성할 수 있습니다.

다음은 이 시나리오의 출력 예입니다.

$ 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

또한 DNS 레코드가 퍼블릭 호스팅 영역에서 생성되지 않고 DNSSEC(도메인 이름 시스템 보안 확장)이 켜져 있으면 NOERROR - NOANSWER가 NXDOMAIN 대신 반환됩니다.

DNSSEC의 상태를 확인하려면 다음 dig 명령을 실행하여 NSEC를 표시합니다. 참고: domain을 사용자의 도메인으로 변겨합니다.

dig <domain> +trace

출력은 다음과 유사합니다.

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

다음 예제에서 dig 출력은 생성되지 않으며 DNSSEC가 켜져있지 않은 DNS 레코드에 대한 NXDOMAIN을 보여줍니다.

$ 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

NXDOMAIN 또는 NOERROR(응답 없음) 응답

DNS 퍼블릭 호스팅 영역을 확인하여 DNS 레코드가 올바르게 구성되었는지 확인합니다.

SERVFAIL 상태

또는

DNS 확인자 또는 서버에 연결할 수 없음

Java 애플리케이션에 Amazon EC2 인스턴스를 사용하는 경우 드물지만 네트워크 중단이 발생할 수 있습니다. dig 또는 nslookup 응답에서 DNS 확인자 또는 서버에 반복적으로 연결할 수 없다는 것을 확인할 수 있습니다. 이 경우 AWS 리전에 활성 네트워크 중단이 발생하는지 확인합니다.

Route 53 확인자 엔드포인트를 통해 Route 53 프라이빗 호스팅 영역에 연결하는 온프레미스 서버를 사용하는 경우 VPC에 있는 엔드포인트의 구성을 확인합니다. 보안 그룹, 네트워크 액세스 제어 목록(네트워크 ACL) 및 라우팅 테이블에 대한 설정을 검토합니다. 지침이 필요하면 인터넷에서 발생하는 Amazon EC2 인스턴스 연결 시간 초과 오류를 해결하려면 어떻게 해야 합니까?를 참조하십시오.

이 예제에서, 출력의 상태는 SERBFAIL입니다.

$ 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

프라이빗 호스팅 영역 및 확인자 규칙이 소스 VPC에 연결되어 있는지 확인

Amazon 제공 DNS 해석기는 다음과 같은 우선순위로 가장 구체적인 쌍을 평가합니다.

1. Resolver 규칙
2. 프라이빗 호스팅 영역
3. 퍼블릭 호스팅 영역

DNS 쿼리가 해석기 규칙과 일치하면 대상 IP 주소가 정답으로 회신하는지 확인합니다. 프라이빗 호스팅 영역을 사용하는 경우, DNS 레코드가 프라이빗 호스팅 영역에 생성되었는지 확인합니다. DNS 레코드가 프라이빗 호스팅 영역에 없으면 퍼블릭 호스팅 영역으로 폴백하지 않고 NXDOMAIN을 반환합니다.

자세한 내용은 VPC와 네트워크 간 DNS 쿼리 확인을 참조하십시오.

하위 도메인 위임 문제 확인

상위, 하위 및 손자 영역 간에 적절한 하위 도메인 위임이 생성되었는지 확인합니다. 손자 영역 이름 서버(NS)가 상위 영역에는 있지만 하위 영역에는 없는 경우, NXDOMAIN이 간헐적으로 발생할 것으로 예상됩니다. 모든 하위 영역 NS 레코드는 상위 호스팅 영역에 존재해야 합니다.

간헐적인 DNS 확인 문제를 방지하려면

다음은 도메인 위임의 예입니다.

• 상위 영역: example.com
• 하위 영역: today.example.com
• 손자 존: api.today.example.com

손자 영역 (api.today.example.com) NS 레코드가 상위 영역 (example.com)에 있는 경우, 하위 영역 (today.example.com)에도 있는지 확인합니다. 자세한 내용은 내 위임된 하위 도메인이 올바르게 확인되는지 테스트하는 방법은 무엇입니까?를 참조하십시오.

UnknownHostException 오류가 간헐적으로 발생하는 경우 Amazon EC2 DNS 한도가 요인일 수 있습니다. 이 한도는 각 네트워크 인터페이스에서 초당 1,024개 패킷이며 이 한도를 늘릴 수는 없습니다. Amazon에서 제공하는 DNS 서버에서 지원하는 초당 DNS 쿼리 수는 쿼리 유형, 응답 크기 및 프로토콜 유형에 따라 다릅니다. 자세한 내용은 Amazon에서 제공한 DNS 서버에 대한 내 DNS 쿼리가 VPC DNS 제한으로 인해 실패하는지 확인하려면 어떻게 해야 합니까?를 참조하십시오.

---