Java アプリケーションで UnknownHostException エラーをトラブルシューティングするにはどうすればよいですか?
所要時間3分
0
Java アプリケーションで UnknownHostException エラーをトラブルシューティングするにはどうすればよいですか?
簡単な説明
UnknownHostException は、Java アプリケーションの一般的なエラーメッセージです。このエラーは、通常、DNS 解決に失敗したことを示します。Java アプリケーションが有効なDNS応答を取得できない場合、 UnknownHostException エラーがスローされる可能性があります。
DNS の問題に加えて、このエラーの根本原因として考えられるものは次のとおりです。
注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、 最新の AWS CLI バージョンを使用していることを確認してください 。
エラーの根本原因を特定する
dig または nslookup コマンドからの有効な回答
アプリケーションレベルの問題は、 dig コマンドまたは nslookup コマンドから有効な回答を得たが、Java アプリケーションで UnknownHostException エラーを引き続き受け取る場合に発生する可能性が高いです。アプリケーションレベルの問題を解決するには、次の方法をお試しください。
次の例では、サーバーまたは 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 レベルで無効になっています。クラウドフレア DNS サーバー (1.1.1.1) の dig が解決している間、VPC リゾルバー (10.1.1.2) に対する dig クエリと telnet は失敗しています。
$ 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) が有効になっている場合、 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)、およびルートテーブルの設定を確認します。手順については、「 インターネットからの 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 解決の問題を回避するには
以下は、ドメイン委任の例です。