ドメインを Route 53 またはその他の DNS ホスティングプロバイダーに移管した後に、DNS 伝達に問題がある場合のトラブルシューティング方法を教えてください。

簡単な説明

Amazon Route 53 にドメインを移管する際、次の問題が原因で一時的にドメイン解決が中断される可能性があります。

• ネームサーバー更新の遅延
• キャッシュされた DNS レコード
• DNS レコードの構成ミス
• ドメインネームシステムセキュリティ拡張 (DNSSEC) の構成ミス
• レジストラレベルのブロック

解決策

重要: ドメインを移管する際は、次の推奨事項を遵守してください。

• トラフィックが少ない期間にドメイン移管を計画します。
• ドメインを移管する数日前に、保持期間 (TTL) の値を 60 秒以内に減らします。
• 移行中は、古い DNS レコードと新しい DNS レコードの両方をアクティブ状態に保ちます。
• ドメインを移管する前に DNSSEC を無効化します。ドメインを正常に移管した後、DNSSEC を再度有効化します。

ネームサーバー更新の遅延が原因でドメインを解決できない場合のトラブルシューティング

ドメインを解決できず、古い DNS ゾーンの SOA (start-of-authority) レコードが表示される場合は、次のいずれかの問題が発生しています。

• ネームサーバーがレジストラレベルで更新されていない。
• ローカルリゾルバーが古いネームサーバーをキャッシュしている。

dig コマンドを実行し、ドメインネームサーバー、DNS 解決、レコードの構成を確認します。

dig web.example-url.com

注: example-url を実際の URL に置き換えてください。

次の出力例は、ドメイン名情報が適切なネームサーバーに配置されていないことが原因で、ドメインを解決できなかったことを示します。

; <<>> DiG 9.18.33 <<>> web.example.com  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59604  
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1  

;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 4096  
;; QUESTION SECTION:  
;web.example.com.               IN      A  

;; AUTHORITY SECTION:  
example.com.            900     IN      SOA     ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

ドメインレジストラのネームサーバーが、新しい DNS プロバイダーまたは Route 53 のネームサーバーと一致することを確認します。次に、古いネームサーバーの TTL 値が失効するまで待機すると、変更が反映されます。問題が解決しない場合は、ローカル DNS リゾルバーで DNS をフラッシュしてください。

注: nslookup コマンドを実行してもドメイン名の DNS 解決およびレコード構成を確認できます。

DNS レコードキャッシュのドメイン解決が一貫しない場合のトラブルシューティング

ローカルマシンまたはインターネットサービスプロバイダーの DNS リゾルバーに古い DNS 情報がキャッシュされている場合、ユーザーが複数のネットワークや場所からドメインにアクセスする際に、アクセスの一貫性が失われます。

dig コマンドを実行して当該ドメインネームサーバーを表示し、ローカルまたはローカルリゾルバーレベルのキャッシュに関する出力を確認します。次の出力例には、古い DNS 情報が含まれています。

; <<>> DiG 9.18.33 <<>> example.com  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56173  
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1  

;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 4096  
;; QUESTION SECTION:  
;example.com.                   IN      A  

;; ANSWER SECTION:  
example.com.            300     IN      A       1.1.1.1  
example.com.            300     IN      A       2.2.2.2

古い DNS 情報が存在する場合は、ローカルの DNS キャッシュをクリアします。次に、複数のネットワークからドメインへのアクセスをテストし、変更が反映されたかどうかを確認します。

注: DNS サービスを移管する前に、ネームサーバーの TTL 値を 60 秒に下げることをおすすめします。

DNS レコードに構成ミスがあり、ドメインが完全に機能できない場合のトラブルシューティング

DNS レコードの移行が不完全な場合、または設定ミスがある場合、ドメインは部分的にしか機能しません (例: ウェブサイトをロードできるものの、メールサービスを実行できない場合)。

dig コマンドを実行して DNS レコードの構成をトラブルシューティングします。

レコードタイプ A

コマンド例:

dig example.com A

出力例:

; <<>> DiG 9.18.33 <<>> example.com  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56173  
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1  

;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 4096  
;; QUESTION SECTION:  
;example.com.                   IN      A  

;; ANSWER SECTION:  
example.com.            300     IN      A       1.1.1.1  
example.com.            300     IN      A       2.2.2.2

レコードタイプ MX

コマンド例:

dig web.example.com MX

出力例:

; <<>> DiG 9.18.33 <<>> web.example.com MX  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59604  
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1  

;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 4096  
;; QUESTION SECTION:  
;web.example.com.               IN      MX  

;; AUTHORITY SECTION:  
example.com.            900     IN      SOA     ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

上記の出力例は、タイプ A レコードは構成されているものの、MX レコードが欠けていることを示しています。MX レコードの欠落は、DNS 移行時に DNS レコードが正しく構成されなかったことを示唆しています。

以前の DNS 構成と Route 53 の設定を確認してください。新しい DNS プロバイダーのシステムにおいて、次のレコードが正しく設定されていることを確認します。

• A
• CNAME
• MX
• TXT

その後、DNS の変更が反映されるまで 24 ～ 48 時間待ちます。

DNSSEC に設定ミスがあり、完全に解決できない場合のトラブルシューティング

DNSSEC を使用する環境からドメインを移管した場合、ドメインを解決できない可能性があります。新しい環境で DNSSEC が正しく構成されていることを確認します。

問題が解決しない場合は、レジストラと DNS プロバイダーレベルで DNSSEC を無効にしてください。次に、新しいドメインレジストラが DNSSEC をサポートしていることを確認してから、新しい環境で DNSSEC を有効にします。

ブロックされたドメインのトラブルシューティング

**whois ** コマンドを実行し、ドメインの登録ステータスを確認します。

whois example-url.com

注: example-url.com を実際の URL に置き換えてください。

出力において、ドメインのステータスが clientHold または serverHold と表示される場合、そのドメインは管理者により、レジストラレベルでブロックされています。

出力例:

   Domain Name: EXAMPLE-URL.COM  
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited  
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited  
   Domain Status: clientHold https://icann.org/epp#clientHold  
   Domain Status: serverHold https://icann.org/epp#serverHold

ドメインのブロックを解除するには、管理者にお問い合わせください。

関連情報

Amazon Route 53 を既存のドメインの DNS サービスにする