このドキュメントでは、Google Distributed Cloud（GDC）エアギャップの Cloud DNS に関する問題のトラブルシューティングについて説明します。DNS 構成で管理オペレーションを実行する際に発生する可能性のあるエラーと問題について説明し、DNS の解決に関する問題のデバッグに役立つヒントと提案を提供します。このドキュメントは、プロジェクト内の DNS レコードの管理を担当するプラットフォーム管理者とアプリケーション オペレーターを対象としています。
Cloud DNS 管理オペレーションのトラブルシューティング
このセクションでは、Cloud DNS ゾーンとレコードセットで作成、読み取り、更新、削除（CRUD）オペレーションを実行する際に発生する一般的な問題のトラブルシューティングについて説明します。
基本的なトラブルシューティング
- IAM 権限を準備するで説明されているように、適切な IAM ロールがあることを確認します。
gdcloudを使用している場合は、gdcloud auth loginを実行して認証トークンを更新できます。
リソースの命名と検証（RFC 1123）
問題: 無効な引数または検証エラーにより、作成または更新が失敗する。
詳細:
- リソース名: DNS ゾーンとレコードセットの名前は、RFC
- 使用できるのは、小文字の英数字または
-のみです。先頭と末尾は英数字にする必要があります。
- 使用できるのは、小文字の英数字または
- DNS 名: ドメイン名と完全修飾ドメイン名（FQDN）の値は、有効なドメイン名にする必要があります。
- 列挙値: 視認性（
PUBLIC、PRIVATE）やレコードタイプ（A、CNAMEなど）の値は、大文字と小文字が区別され、想定される文字列と完全に一致する必要があります。
空でないゾーンを削除できない
問題: マネージド ゾーンを削除できない。オペレーションが拒否される。
詳細: マネージド DNS ゾーンを削除するには、リソース レコードセットが空である必要があります。最初にゾーン内のすべてのレコードを削除する必要があります。
名前とドメインの競合
問題: 名前またはドメインがすでに使用されていることを示すエラーが発生し、リソースを作成できない。
詳細:
- Kubernetes リソース名: オブジェクトの名前（
metadata.nameの名前など）は、特定のプロジェクト Namespace 内で一意である必要があります。 - DNS 名（FQDN）: 実際のドメイン名（ゾーンまたはレコードの
dnsNameなど）は、特定の公開設定（PUBLIC または PRIVATE）内で一意である必要があります。同じ公開設定ティアに、同じドメイン名を持つ 2 つのゾーンまたは 2 つのレコードを作成することはできません。
DNS の解決に関する問題のトラブルシューティング
このセクションでは、プラットフォーム管理者とアプリケーション オペレーターが、Google Distributed Cloud でホストされているサービスにアクセスする際の DNS の解決に関する問題をトラブルシューティングする方法について説明します。
伝播を待って DNS キャッシュを消去する
DNS レコードが作成または更新されても、変更がすぐに反映されないことがあります。この遅延は通常、次の原因で発生します。
- 調整時間: システムがリクエストを処理して DNS サーバー構成を更新するまでに時間がかかります。この処理には通常、数分かかります。
- DNS 伝播遅延（キャッシュ）: DNS リゾルバとクライアントは、ルックアップを高速化するためにレコードをキャッシュに保存します。クライアントは、有効期間（TTL）が経過するまで古いレコードを引き続き使用する可能性があります。
推奨事項:
- 待機する: 調整とキャッシュの有効期限が切れるまで十分な時間を確保します。
- キャッシュをフラッシュする: ローカル DNS キャッシュをクリアして、新しいルックアップを強制します。
ローカル リゾルバの構成を確認する
クライアントが正しい DNS サーバーを使用していることを確認します。正しい IP アドレスがわからない場合は、インフラストラクチャ オペレーション（IO）チームに連絡して、正しい DNS サーバー IP を確認してください。
- Linux / macOS:
/etc/resolv.confの内容を確認します。 - Windows:
ipconfig /allを実行し、表示された DNS サーバーを確認します。
お客様のネットワーク上のプラットフォーム管理者（PA）とアプリケーション オペレーター（AO）のワークステーションは、IO WAN および OIRv2 ネットワークとは別の DNS の解決を使用する必要があります。同じ GDC ドメイン名が、クエリが IO WAN 経由で到着するか、お客様の相互接続経由で到着するかによって異なる IP アドレスに名前解決されるため、IO と PA または AO ワークステーションの両方に共有 DNS 構成を使用することはできません。詳細については、システム相互接続、DNS ドメイン命名スキーマ、DNS-R0016 ランブックをご覧ください。
標準ツールを使用して解決策をテストする
標準のコマンドライン ツールを使用して、解決をテストし、障害が発生した場所を特定します。
基本的な検索:
dig <domain_name>または
nslookup <domain_name>特定の DNS サーバーにクエリを実行する: パブリック ManagedDNS サーバーの IP がわかっている場合は、直接クエリを実行してローカル リゾルバをバイパスします。
dig @<public_dns_server_ip> <domain_name>パブリック ネームサーバーにクエリを実行する: ローカル リゾルバの問題を除外するには、Google DNS などのパブリック リゾルバにクエリを実行してみます。
dig @8.8.8.8 <domain_name>
DNS レスポンス コードを分析する
dig または nslookup を使用する場合は、レスポンスのステータス コードを確認します。
- NXDOMAIN: ドメイン名が見つかりませんでした。入力ミスがないか、レコードが存在するかどうかを確認してください。
- SERVFAIL: サーバーがクエリを処理できませんでした。多くの場合、これはサーバー側の問題、または DNS サーバー間の通信障害を示しています。
- NOERROR: クエリは成功しましたが、回答がない可能性があります。リクエストされたレコードタイプ（A、CNAME など）が存在するかどうかを確認します。
- REFUSED: サーバーがクエリへの回答を拒否しました。これは、ポリシーまたはアクセス制御の設定が原因である可能性があります。
ネットワーク接続を確認する
DNS サーバーへのネットワーク トラフィックがブロックされていないことを確認します。
- DNS は UDP と TCP の両方にポート 53 を使用します。
nc（netcat）を使用して接続をテストします。nc -zv <dns_server_ip> 53ファイアウォール ルールでポート 53 のトラフィックが許可されていることを確認します。
DNS のキャッシュをフラッシュする
DNS キャッシュをフラッシュすると、ローカル DNS キャッシュからすべてのエントリが削除されます。これにより、オペレーティング システムはドメイン名の DNS サーバーに再度クエリを実行し、古いキャッシュ レコードではなく、最新のレコードを取得します。
- Windows:
ipconfig /flushdns- 機能: DNS クライアント サービスによって保持されている DNS リゾルバ キャッシュを消去します。
- macOS:
sudo killall -HUP mDNSResponder- 機能:
mDNSResponderプロセスにハングアップ シグナル（HUP）を送信し、強制的に再読み込みしてキャッシュをクリアします。
- 機能:
- Linux（systemd-resolved）:
sudo systemd-resolve --flush-cachesまたはsudo resolvectl flush-caches- 機能:
systemd-resolvedサービスに内部 DNS キャッシュを破棄するように指示します。
- 機能:
API または gdcloud でリソースのステータスを確認する
テナントである場合、または GDC API へのアクセス権がある場合は、リソースのステータスを直接確認できます。
DNS ゾーンを確認する:
kubectl describe manageddnszone <zone_name> -n <project_namespace>リソース レコードセットを確認する:
kubectl describe resourcerecordset <record_name> -n <project_namespace>調整プロセスで障害が発生していることを示す条件やイベントを探します。
gdcloud コマンドラインにアクセスできる場合は、DNS レコードを一覧表示するまたは DNS ゾーンを一覧表示するに記載されているように、describe サブコマンドを使用できます。