Cloud DNS設定ドメインの名前解決問題解決までの道のり
Cloud DNS設定ドメインの名前解決問題解決までの道のり
こんにちは!今回は、ドメイン「example-domain.com」とそのサブドメイン「service.example-domain.com」の
名前解決がうまくいかなかった際のトラブルシューティング事例をご紹介します。同じような問題に直面した方の参考になれば幸いです。
はじめに
このドキュメントは、ドメイン example-domain.com 及びそのサブドメイン service.example-domain.com の名前解決ができない問題に対し、
Google Cloud DNSを利用した設定のトラブルシューティングを行い、解決に至るまでの過程を記録したものです。同様の問題に直面した際の参考情報となることを目的としています。
2.初期状況と問題点
- ドメイン: example-domain.com
- サブドメイン (名前解決対象): service.example-domain.com
- 発生していた問題: service.example-domain.com の名前解決ができず、意図したIPアドレスにアクセスできない。
- 利用環境:
- ドメイン example-domain.com はGoogle Workspace契約時に取得。
- DNSホスティングサービスとしてGoogle Cloud DNSを利用。
3.初期設定の確認 (Google Cloud DNS)
問題発生当初、Google Cloud DNSの example-domain.com ゾーンには以下のレコードが設定されていました。
- SOAレコード: ns-cloud-a1.googledomains.com. cloud-dns-hostmaster.google.com. … (標準的なSOAレコード)
- NSレコード (ネームサーバー):
- ns-cloud-a1.googledomains.com.
- ns-cloud-a2.googledomains.com.
- ns-cloud-a3.googledomains.com.
- ns-cloud-a4.googledomains.com.
- Aレコード (対象サブドメイン):
- DNS名: service.example-domain.com.
- 種類: A
- TTL: 300 (秒)
- レコードデータ: 203.0.113.100 (例示用のIPアドレス)
Cloud DNS上のこれらのレコード設定自体には、一見して誤りはありませんでした。
4.トラブルシューティングの経緯
4.1. ドメイン管理プロバイダの特定
DNSの名前解決問題を解決する上で最も重要なのは、ドメインのネームサーバー設定がどこで行われているか(=ドメイン登録業者/レジストラはどこか)を特定することです。
- Google Workspaceでドメインを取得したとのことから、Google Workspaceの管理コンソールを確認。
- 「ドメインの管理」セクションで example-domain.com の詳細情報を確認すると、「ドメインの管理には「Google でログイン」を使用します。」という記述と共に、「ドメインを管理(Squarespace を利用)」というリンクが見つかりました。
- これにより、example-domain.com の実際のドメイン登録・管理は Squarespace によって行われていることが判明しました。
4.2. ネームサーバー設定の確認と修正 (at Squarespace)
Cloud DNSでDNSレコードを管理する場合、ドメイン登録業者(この場合は Squarespace)側で、ネームサーバーをCloud DNSから指定されたものに設定する必要があります。
- Squarespaceのドメイン管理画面にアクセス。
- example-domain.com の「ドメイン ネームサーバー」設定セクションを確認。
- ここに、Google Cloud DNSから指定されたネームサーバー(上記3で確認したaシリーズNS: ns-cloud-a1.googledomains.com から ns-cloud-a4.googledomains.com)を正しく入力し、設定を更新・保存しました。
- 当初、ここがSquarespaceのデフォルトNSや、異なるCloud DNSのNSセット(後述するcシリーズNS)になっていた場合、Cloud DNS側の設定は有効になりません。
4.3. Squarespace側の関連設定について (不要な設定)
- ネームサーバーの登録(ホストレコード/グルーレコード): Squarespaceの画面に「ネームサーバーの登録」といった項目がありましたが、これはネームサーバー自体が自ドメインのサブドメイン(例: ns1.example-domain.com)である場合にのみ必要な設定です。今回はGoogleのドメイン (googledomains.com) 上のネームサーバーを使用するため、この設定は不要でした。
- DNS設定(Aレコード、CNAMEレコードなど): Squarespaceの管理画面にもDNSレコードを設定するセクションがありましたが、「カスタム ネームサーバーを使用しています。DNSレコードは、サードパーティーのネームサーバー プロバイダーで管理されます。」との注意書きがありました。これは、ネームサーバーを外部(今回はGoogle Cloud DNS)に設定している場合、Squarespace側のDNSレコード設定は無効になることを意味します。したがって、ここでレコードを追加・変更する必要はありませんでした。全てのレコード管理はGoogle Cloud DNSで行います。
4.4. DNSプロパゲーションの確認 ( nslookup コマンドの活用)
ネームサーバーの変更後、その情報がインターネット全体に広まる(DNSプロパゲーション)までには時間がかかります。この状況を確認するために nslookup コマンドを使用しました。
詳細な確認方法については、元のドキュメントに記載されている `nslookup` コマンドの実行例をご参照ください。
5.解決と最終確認
`nslookup` の結果から、以下のことが確認できました。
- Squarespaceでのネームサーバー設定は正しく行われ、インターネットに伝播し始めている。
- Google Cloud DNSに設定された service.example-domain.com のAレコードは有効であり、Google Public DNS経由で名前解決が可能になっている。
まとめと教訓
今回のトラブルシューティングから得られた主な教訓は以下の通りです。
- ドメイン管理プロバイダの正確な特定: DNS設定問題の解決には、ドメインが実際にどこで管理されているか(レジストラはどこか)を正確に把握することが不可欠です。
- ネームサーバー設定の二重確認: DNSレコードをホストするサービス(例: Cloud DNS)と、そのネームサーバー情報を登録する場所(例: Squarespace)の両方で設定が正しく行われている必要があります。
- DNSプロパゲーションの理解と確認方法: 設定変更が即座に反映されるわけではないことを理解し、nslookup などのツールを用いて、異なるDNSリゾルバ(ローカル、パブリックDNSなど)からの応答を確認することが、状況把握に非常に有効です。
- ツールの有効活用: nslookup コマンドは、DNS設定のトラブルシューティングにおいて非常に強力なツールです。