このページは Cloud Translation API によって翻訳されました。

ドメインに関するトラブルシューティング

Google Public DNS がドメインを解決できない場合は、多くの場合、そのドメインまたはその権威ネームサーバーの問題が原因です。次の手順では、ドメイン管理者が自分で問題を解決できるように、問題の原因を特定できます。

この手順を開始する前に、一般的なトラブルシューティングのページの説明に沿って dns.google でドメインを確認します。このページでは、下記の診断手順を確認できます。それ以外の場合は、原因が見つかるまで次の手順をすべて試してください。

ステップ 1: DNSSEC 検証に関する問題を確認する

ドメインの dns.google ウェブ検索に "Status": 2（SERVFAIL）が表示され、DNSSEC のないクエリが成功すると、ドメインのネームサーバーまたはそのトップレベルドメイン（TLD）レジストリ（登録済みドメインの DNSSEC 検証用に DS レコードが公開）に DNSSSEC の問題が存在する可能性があります。

登録事業者または DNS サービスの変更

DNSSEC に関する問題は、ドメインが DNSSEC をサポートする登録事業者または DNS サービスから、それがサポートされない登録事業者サービスに切り替えられた後に発生する可能性があります。以前のサービスが TLD レジストリに古い DS レコードを残し、新しいサービスが TLD レジストリに一致する DS レコードと一致する新しい DS レコードを作成しない場合は、Google Public DNS などのリゾルバを検証してもドメインを解決できません。

この場合は、ドメイン登録事業者から、TLD レジストリから古い DS レコードを削除するようご依頼ください。

DNSSEC レスポンスが大きすぎる

DNSSEC の問題のもう 1 つの原因として、DNSSEC レスポンスが大きすぎて 1 つの IP パケットに収まらない場合があり、断片化されたレスポンスが作成されて破棄される可能性があります。DNSViz に、「UDP ペイロードサイズが縮小されるまでレスポンスを受信しなかった」というメッセージが表示される場合は、DNSSEC の失敗が大きなレスポンスで発生している可能性があります。レスポンスのサイズは、次のうち 1 つ以上のアクションによって削減できます。

権威ネームサーバー向けの「最小限の応答」を設定する
アクティブな DNSKEY レコードの数を 2 つまたは 3 つに減らす
1280 ビットまたは 2, 048 ビットの DNSKEY レコード（RFC 6781、StackExchange）を使用します。
RSA 署名から ECDSA 署名をより小さくする（RFC 8624）

また、ステップ 2 で、ツールから報告された他の DNSSEC の問題がないか確認します。たとえば、不正な NSEC または NSEC3 不在証明レコードに、サブドメインが存在しないことが証明される（外部データベースに格納されたゾーンがある PowerDNS の可能性がある）か、期限切れの RRSIG 署名（手動で構成された署名プロセス）があります。

ステップ 2: 権威ネームサーバーを確認する

Google Public DNS（または開いているリゾルバ）でドメインの解決に問題がある場合、DNSViz では、ドメインとネームサーバーの原因となっているドメインの問題が表示されます。DNSViz のウェブページにアクセスし、問題のあるドメイン名を入力します。 DNSViz に過去のデータがない場合や、1 日以上前のデータ（このページなど）のみが存在する場合は、大きな [Analyze] ボタンをクリックして、下にある [Analyze] ボタンを表示します（まだ表示されていない場合）。分析が完了したら、[続行] をクリックして結果を表示します。左のサイドバーにある赤色のエラーと黄色の警告をクリックして詳細を表示するか、図の中のオブジェクトの上にポインタを置いてコンテキスト内にその情報を表示します。

前述の診断でドメインの DNSSEC に関する問題が示されている場合は、DNSSEC Analyzer のウェブページに移動し、ドメイン名を入力します。このアナライザが DNSSEC のエラーまたは警告を報告する場合は、赤色の ⊗ アイコンまたは黄色の ⚠️ アイコンの上にポインタを置いて修正方法の提案を確認してください。

intoDNS ウェブページには、メインページで入力されたドメインに関する DNSSEC 以外の問題が報告され、修正候補も表示されます。

ドメイン管理者はこれらのツールによって報告されるエラーのほとんどを修正する必要があります。これらのエラーは Google Public DNS だけでなく、その他のリゾルバでも問題を引き起こす可能性があります。

ステップ 3: 委任に関する問題を確認する

Google Public DNS は「親中心」のリゾルバで、親ドメインの参照で返されるネームサーバーのみを使用します。TLD のネームサーバー名とグルーアドレスが最新でないか、間違っていると、委任に関する問題が発生する可能性があります。

DNSViz または intoDNS が、TLD で委任されたネームサーバーと子ドメイン自体に存在するネームサーバー間の不整合性に関する警告を報告した場合、Google Public DNS がドメインを解決する前に、そうした問題に対処する必要があります。これらのツールが、登録されているドメインが存在しないと報告している場合（NXDOMAIN）は、なんらかの理由でドメインの有効期限が切れていないこと、または登録が保留中でないことを確認します。

委任に関する問題は、ドメインのネームサーバーの名前の解決に失敗することでも発生します。dns.google でネームサーバーの A レコードと AAAA レコードを調べて、ネームサーバーとドメインに問題があるかどうかを確認します。

ステップ 4: 大きなレスポンスを確認する

DNS は、トラフィックの大半を処理するために UDP を使用します。サイズの大きい UDP データグラムは、断片化や UDP の断片化によって信頼性の低い配信の影響を受けます。これこそが、DNS の信頼性をグローバルに改善するための取り組みである DNS Flag Day 2020 の焦点でした。Google Public DNS はこの取り組みに参加しており、UDP を介して受け入れる UDP レスポンスのサイズを制限しています。独自のコマンドプロンプトまたは Google Cloud Shell を使用して、次のようなクエリを試してください。

$ dig +short example.com NS
ns1.example.com
ns2.example.com
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY
...

さまざまなレコードタイプに対するこれらのクエリは、以下を指定しています。

+dnssec: DNSSEC を有効にします。特に、DNSSEC 検証が利用可能な場合は、DNSSEC 検証に必要なレコードを返します。これにより、結果のサイズが大幅に拡大します。これは、Google Public DNS の動作をエミュレートします。
+bufsize=1400: 許可される UDP バッファサイズを制限します。これは、DNS Flag Day 2020 の努力の時点で、Google Public DNS の動作をエミュレートします。
+timeout=1: タイムアウトを 1 秒に設定します。これは、Google Public DNS の動作をエミュレートします。
@ns1.example.com: クエリを実行する権威サーバー。@ 記号は残します。それ以外の場合は、最初のコマンドで示したように、自身のドメインの権威サーバーに置き換えます。

出力を確認します。次のような行が表示されます。

;; Truncated, retrying in TCP mode.: これは、レスポンスがリクエストされた UDP バッファサイズより大きいため、切り捨てられたため、クライアントが TCP に切り替えたことを示します。権威サーバーは、TCP ポート 53 で DNS トラフィックを処理できる必要があります。（実装が UDP と TCP の両方のトランスポートをサポートしなければならない RFC 7766 を参照）
;; MSG SIZE rcvd: 2198: 1,400 より大きい数字を表示する場合これは、レスポンスが大きいことを示しています。
;; Query time: 727 msec: 500 件を超える電話番号の場合は、遅いレスポンス（特に 1 秒に近いレスポンス）は、Google Public DNS によって破棄される可能性があります。これは、特に UDP の試行に時間が費やされ、その後に TCP の試行が続く場合に発生する可能性があります。サーバーとクライアントの地理的位置は、レイテンシに大きく影響します。
;; connection timed out; no servers could be reached: 特に、一部のクエリについてのみ、サーバーが DNS クエリに適時に応答できないという問題を示します。

次のクエリバリエーションをお試しください。

+tcp パラメータを追加する。: これにより、dig は直ちに TCP を使用し、権威サーバーがこのように TCP クエリを直接処理しているかどうかを確認できます。
+bufsize=1400 パラメータを削除する。: これにより、dig のデフォルトの動作（バッファサイズ 4096）が復元されます。この設定でクエリが失敗しても、その設定を行わなければ、サーバーは TCP フェイルオーバーを適切に処理できません。大規模なレスポンスの転送には UDP を使用する必要があります。DNS 用の TCP トランスポートをサポートすることをおすすめします。
各ネームサーバーで繰り返し。: 上の例では、2 つの権威ネームサーバー（ns1 と ns2）を使用しています。一部のサーバーでは、異なる回答が返されることが原因です。すべての権威サーバーで同じクエリを繰り返し、すべての答えが一貫していることを確認します。

すべてのクエリとレスポンスが小さく（1,400 バイト以下）、高速で（できれば 500 ミリ秒以上）、信頼性が高い（TCP と UDP で一貫して動作する）場合、レスポンスのサイズは問題になりません。他のトラブルシューティングのセクションをお読みください。レスポンスが速くても、地理的に離れた場所からのクエリのほうが遅くなる場合があります。

これらのチェックのいずれかが失敗した場合（ラージ？遅い、信頼できない、など）は、A）レスポンスがリクエストされた UDP バッファサイズを超えたときに UDP の切り捨てで応答し、B）以降の TCP クエリの再試行を処理できることを確認します。DNS の信頼性に関する問題の診断に役立つツール:

DNSViz
DNSSEC デバッガ
EDNS コンプライアンステスター
DNS Checker -- 必ず [CD] チェックボックスをオフにします（DNSSEC のチェックを無効にします）。

これらのツールでエラーや警告が見つかった場合は、必ず対処してください。また、このサイトに記載されている他のトラブルシューティングの手順も、必ずお読みください。

ステップ 5: 他のパブリックリゾルバがドメインを解決するかどうかを確認する

上記の手順を行っても問題の原因が見つからなかった場合は、コマンドプロンプトで次のコマンドを実行します。example.test. は、対象のドメインに置き換えます（末尾のドットは残します）。

Windows

nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.

macOS または Linux

dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'

これらのコマンドでは、OpenDNS、Quad9、Cloudflare 1.1.1.1 の DNS リゾルバを使用します。Google Public DNS だけでなく、この 2 つから解決エラーが発生した場合も、ドメインまたはそのネームサーバーに問題がある可能性があります。

複数のパブリックリゾルバから正常な結果が返された場合、Google Public DNS に問題がある可能性があります。Issue Tracker でドメイン（またはその TLD）に関する同様の問題が報告されていない場合は、コマンドの出力、診断ページのテキストまたはスクリーンショットを含め、問題を報告してください。