Route 53 を DNS サービスとして使用する場合の NXDOMAIN 応答のトラブルシューティング方法を教えてください。

所要時間3分
0

DNS リゾルバーから NXDOMAIN 応答を受け取るか、Amazon Route 53 レコードを解決するときに DNS_PROBE_FINISHED_NXDOMAIN エラーが表示されます。

解決策

ドメインがアクティブ状態か一時停止状態かを判断する

1.    ドメインに対して whois クエリを実行します。

注: 次のコマンドを実行する前に、whois がインストールされていることを確認します。

Windows の場合: Windows コマンドプロンプトを開き、whois-v example.com と入力します。
Linux の場合:****SSH クライアントを開きます。コマンドプロンプトwhois example.com と入力します。

**注:**ドメインが Amazon Registrar に登録されている場合は、Amazon Registrar の whois 検索ツールを使用できます。

2.    ドメインのステータスを確認する。ドメインステータスの値が clientHold の場合、ドメインは停止しています。

Whois の出力例:

whois example.com
   Domain Name: EXAMPLE.COM
   Registry Domain ID: 87023946\_DOMAIN\_COM-VRSN
   Registrar WHOIS Server: whois.godaddy.com
   Registrar URL: http://www.godaddy.com
   Updated Date: 2020-05-08T10:05:49Z
   Creation Date: 2002-05-28T18:22:16Z
   Registry Expiry Date: 2021-05-28T18:22:16Z
   Registrar: GoDaddy.com, LLC
   Registrar IANA ID: 146
   Registrar Abuse Contact Email: abuse@godaddy.com
   Registrar Abuse Contact Phone: 480-624-2505
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientHold https://icann.org/epp#clientHold  
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
   Name Server: ns-1470.awsdns-55.org.
   Name Server: ns-1969.awsdns-54.co.uk.
   Name Server: ns-736.awsdns-28.net.
   Name Server: ns-316.awsdns-39.com.

ドメインをインターネット上で再び利用できるようにするには、そのドメインを一時停止状態を解除します。ドメインが停止する最も一般的な理由は次のとおりです。

  • 新しいドメインを登録したが、確認メールのリンクをクリックしなかった。
  • ドメインの自動更新を無効にし、ドメインの有効期限が切れた。
  • 登録者の連絡先の電子メールアドレスを変更したが、新しい電子メールアドレスが有効であることを確認しなかった。

詳細については、「私のドメインは停止中です (ステータスは ClientHold)」を参照してください。

ドメインレジストラに正しいネームサーバーが設定されていることを確認する

1.    whois の出力で、ドメインの権威のあるネームサーバーを書き留めておきます。例については、前述の whois 出力を参照してください。

dig ユーティリティを使用して、設定されているネームサーバーを確認することもできます。

dig +trace 出力の例:

dig +trace example.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.2 <<>> +trace example.com
;; global options: +cmd
.                       518400  IN      NS      H.ROOT-SERVERS.NET.
.                       518400  IN      NS      I.ROOT-SERVERS.NET.
.                       518400  IN      NS      J.ROOT-SERVERS.NET.
.                       518400  IN      NS      K.ROOT-SERVERS.NET.
;; Received 239 bytes from 10.0.0.2#53(10.0.0.2) in 0 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20210329220000 20210316210000 42351 .
;; Received 1174 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 104 ms

example.com.         172800  IN      NS      ns-1470.awsdns-55.org.  	------>Name servers of interest.
example.com.         172800  IN      NS      ns-1969.awsdns-54.co.uk.
example.com.         172800  IN      NS      ns-736.awsdns-28.net.
example.com.         172800  IN      NS      ns-316.awsdns-39.com.

;; Received 732 bytes from 192.33.14.30#53(b.gtld-servers.net) in 91 ms

example.com.         3600    IN      A       104.200.22.130
example.com.         3600    IN      A       104.200.23.95
example.com.         3600    IN      NS      ns-1470.awsdns-55.org.
example.com.         3600    IN      NS      ns-1969.awsdns-54.co.uk.
example.com.         3600    IN      NS      ns-736.awsdns-28.net.
example.com.         3600    IN      NS      ns-316.awsdns-39.com.

;; Received 127 bytes from 173.201.72.25#53(ns-1470.awsdns-55.org) in 90 ms

2.    Route 53 コンソールを開きます。

3.    ナビゲーションペインで [ホストゾーン] を選択します。

4.    ホストゾーンページで、ホストゾーンのラジオボタン (名前ではなく) を選択します。次に、[詳細を表示] を選択します。

5.    ホストゾーンの詳細ページで、[ホストゾーンの詳細] を選択します。

6.    ホストゾーンの詳細に表示されているネームサーバーが、whois または dig +trace 出力のネームサーバーと同じであることを確認します。

**重要:**同じネームサーバーでない場合は、ドメインレジストラで更新してください。ドメインが Route 53 に登録されている場合は、「ドメインのネームサーバーとグルーレコードの追加または変更」を参照してください。第三者に登録されたドメインについては、ネームサーバーを更新する手順についてプロバイダーのドキュメントを参照してください。

要求されたレコードが存在することを確認する

ドメインのホストゾーンに、要求されたレコードがあることを確認します。たとえば、www.example.com を解決しようとしたときに NXDOMAIN の応答を受け取った場合は、example.com のホストゾーンに www.example.com レコードがないかどうかを確認します。Route 53 でレコードを一覧表示する方法については、「レコードを一覧表示する」を参照してください。

別のドメイン名を指している CNAME レコードがある場合は、正規名が存在し、解決可能であることを確認してください。

example.com CNAME レコードは blog.example.com という値で設定されています。この場合、blog.example.com というレコードが存在し、解決可能であることを確認してください。

サブドメイン委任の問題を確認する

1.    親ホストゾーンで、解決するドメイン名のネームサーバー (NS) レコードを確認してください。サブドメインの NS レコードが存在する場合、そのドメインとそのサブドメインの権限は別のゾーンに委任されます。たとえば、www.example.com の NS レコードが存在する場合、www の権限は NS レコード内のネームサーバーに委任されます。委任が有効な場合は、example.com の親ゾーンではなく、委任ゾーンにドメインのレコードを作成する必要があります。

2.    委任が有効でない場合は、ドメインの NS レコードを削除します。親ホストゾーン (example.com) に、解決しようとしているドメイン名のレコードが含まれていることを確認します。

3.QNAME 最小化を実装するリゾルバーは、最小限の詳細情報を各クエリに含めます。解決プロセスのそのステップでその情報が必要なためです。これにより、一部のリゾルバーで NXDOMAIN の問題が発生する場合があります。複数レベルのサブドメイン委任を設定する場合は、すべてのレベルで厳密な委任に従ってください。詳しくは、「追加レベルのサブドメインへのトラフィックのルーティング」を参照してください。

DNS 解決の問題が VPC にのみ存在するかどうかを判断する

1.    クライアントオペレーティングシステム (OS) に設定されているリゾルバー IP アドレスを確認します。Linux の場合は、/etc/resolv.conf ファイルを確認してください。Windows の場合は、ipconfig /all output の DNS サーバーを確認してください。デフォルトの仮想プライベートクラウド (VPC) DNS リゾルバー (VPC CIDR+2) を探します。たとえば、VPC CIDR が 10.0.0.0/8 の場合、DNS リゾルバー IP アドレスは 10.0.0.2 になります。/etc/resolv.conf に VPC DNS リゾルバーが表示されない場合は、カスタム DNS リゾルバーを確認してください。

2.    VPC DNS リゾルバーを使用している場合は、プライベートホストゾーンと Route 53 リゾルバールールを確認してください。

リゾルバールールとプライベートホストゾーンを使用する場合

リゾルバールールとプライベートホストゾーンのドメイン名が一致する場合、リゾルバールールが優先されます。詳細については、「プライベートホストゾーンを使用する際の考慮事項」を参照してください。この場合、DNS クエリは、リゾルバールでターゲットとして設定されているターゲット IP アドレスに送信されます。

プライベートホストゾーンを使用し、リゾルバールールを使用しない場合

VPC に関連付けられているドメイン名が一致するプライベートホストゾーンがあることを確認します。たとえば、VPC に関連付けられているドメインに、パブリックホストゾーンとプライベートホストゾーンがある場合があります。これはスプリットビューまたはスプリットホライズン DNS です。この場合、VPC のクライアントはパブリックホストゾーンで作成されたレコードを解決できません。レコードがプライベートホストゾーンに存在しない場合、VPC DNS はパブリックホストゾーンにフォールバックしません。

リゾルバールールのみを使用し、プライベートホストゾーンを使用しない場合

Route 53 リゾルバールールを確認します。ドメイン名と一致するルールがある場合、ドメインのクエリは設定されたターゲット IP アドレスにルーティングされます。つまり、クエリはデフォルトのパブリックリゾルバーにルーティングされません。

問題の原因がネガティブキャッシュにあるかどうかを確認してください

ネガティブキャッシュは、権限のあるネームサーバーからのネガティブレスポンスをキャッシュに保存するプロセスです。NXDOMAIN からのレスポンスはネガティブレスポンスとみなされます。次の例を考えてみましょう。

クライアントが neg.example.com に対して DNS クエリを実行すると、neg.example.com というレコードが存在しないため、NXDOMAIN というレスポンスコードが返されます。

このユーザーは example.com も所有しているので、neg.example.com 用に新しいレコードを作成します。他のネットワークのユーザーがレコードを正常に解決できると、ユーザーは引き続き NXDOMAIN 応答を受け取ります。

ユーザーが新しいレコードを作成する前に neg.example.com にクエリを実行すると、NXDOMAIN 応答が返ります。ユーザーがリゾルバー設定でネガティブキャッシュを有効にした場合、リゾルバーはこのレスポンスをキャッシュします。ユーザーは新しいレコードを作成した後、クエリを再度実行します。リゾルバーは以前にこのクエリを受信してキャッシュしていたため、キャッシュからの応答を返しました。

否定的な回答の回答ではレコードが返されないため、肯定的な回答と比較して TTL (Time to Live) の値はありません。この場合、リゾルバーは次のうち最も低い値を使用します。

  • 権限開始 (SOA) レコードの最小 TTL 値。
  • NXDOMAIN レスポンスをキャッシュするための SOA レコードの TTL 値。

この問題を確認するには、ネームサーバーに直接クエリを送信して、応答があるかどうかを確認します。例:

dig www.example.com @ns-1470.awsdns-55.org
AWS公式
AWS公式更新しました 1年前
コメントはありません

関連するコンテンツ