Java 애플리케이션에서 발생하는 UnknownHostException 오류 문제를 해결하려면 어떻게 해야 하나요?

5분 분량

간략한 설명

UnknownHostException은 Java 애플리케이션에서 흔히 발생하는 오류 메시지입니다. 이 오류는 보통 DNS 확인에 실패했을 때 나타납니다. Java 애플리케이션에서 유효한 DNS 응답을 받지 못하는 경우 UnknownHostException 오류가 발생할 수 있습니다.

이 오류에는 DNS 문제 외에도 다음과 같은 근본 원인이 있을 수 있습니다.

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

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하는 경우, 최신 AWS CLI 버전을 사용하고 있는지 확인하세요.

오류의 근본 원인 파악

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

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

Answer 섹션이 비워져 있는 유효한 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(Domain Name System Security Extensions)가 활성화되어 있는 경우, NXDOMAIN 대신 NOERROR - NOANSWER 메시지가 반환됩니다.

DNSSEC의 상태를 확인하려면 다음 dig 명령을 실행해 NSEC를 표시하세요. 참고: 도메인을 내 도메인으로 변경하세요.

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보안 그룹, 네트워크 액세스 제어 목록(네트워크 ACL), 라우팅 테이블의 설정을 검토하세요. 지침을 확인하려면 인터넷에서 Amazon EC2 인스턴스 연결 제한 시간 초과 오류를 해결하려면 어떻게 해야 하나요?를 참고하세요.

이 예시에서 출력의 상태는 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

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

Amazon에서 제공하는 DNS 확인자는 다음과 같은 우선 순위에 따라 가장 구체적인 일치 항목부터 평가합니다.

확인자 규칙
프라이빗 호스팅 영역
퍼블릭 호스팅 영역

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 제한 때문인지 어떻게 확인할 수 있나요?를 참고하세요.

주제

네트워킹 및 콘텐츠 전송

태그

Amazon Route 53

언어

한국어

AWS 공식업데이트됨 2년 전

댓글 없음

Java 애플리케이션에서 발생하는 UnknownHostException 오류 문제를 해결하려면 어떻게 해야 하나요?

간략한 설명

해결 방법

오류의 근본 원인 파악

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

하위 도메인 위임 문제 확인

관련 콘텐츠