トラブルシューティング

Google Public DNS のホームページ

Google Public DNS を使用してドメインの問題を解決できない場合は、まず https://dns.google/ で Google Public DNS のホームページを確認します。ここに示したようなシンプルな DNS ルックアップ フォームがあります。

ブラウザで dns.google サーバーが見つからない場合や、サーバーが応答しない場合は、コマンドライン診断を使用して、Google Public DNS サーバーにアクセスできることを確認します。

google.com」(または任意のドメイン名または IP アドレス)を入力し、Enter キーを押して、次のような詳細な DNS 結果ページを表示します。

Google Public DNS の詳細ページ

Google Public DNS のトラブルシューティング

さまざまな DNS 解決の問題が存在する可能性があります。問題に最も関連する見出しの下の指示に従ってください。問題を報告してヘルプを表示する必要がある場合は、診断ページのコマンドやテキストの出力をレポートに含めます。

ドメインの解決に関する問題

Google Public DNS で特定のドメイン名を解決できない場合は、dns.google 詳細ページに入力します。特定の DNS リソース レコード(RR)タイプに問題がある場合は、「RR タイプ」テキスト フィールドに入力します(数値を入力することもできます)。Enter キーを押すか、[解決] をクリックして結果を確認します。

詳細な結果では、下部に "Comment": の行と DNS クエリの診断結果が表示される場合があります。たとえば、
"DNSSEC validation failure. Check http://dnsviz.net/d/dnssec-failed.org/dnssec/ and http://dnssec-debugger.verisignlabs.com/dnssec-failed.org for errors" のように表示されます。

すべてのコメント URL(リンクではありません。コピーしてブラウザに貼り付ける)にアクセスし、詳細な診断情報を確認して問題解決の問題の原因を特定します。

次のいずれかのエントリに一致するコメント行がある場合は、対応するリンクをクリックして特定の診断手順に直接移動するか、ドメインのトラブルシューティングの最初のステップから開始します。

DNSSEC validation failure
このエラーが表示された場合は、DNSSEC トグルをクリックして検証を無効にし、[解決] をクリックしてクエリを再試行してください。成功("Status": 0)した場合は、DNSSEC の問題があります。DNSSEC のトラブルシューティングをご覧ください。それ以外の場合は、ネームサーバーのトラブルシューティングをご覧ください。
Name servers
ネームサーバーのトラブルシューティングをご覧ください。
Resolution failure または Lame delegation
委任のトラブルシューティングをご覧ください。

大きなレコード(通常は DNSSEC キーまたは TXT レコード)に問題がある場合は、大きなレスポンスのトラブルシューティングをご覧ください。

ドメインの間違った答えを返す

Google Public DNS が誤った答えを返す理由はさまざまです。ドメインに関する知識があれば、次のいずれかが可能であると考えられます。

ドメインのサーバーが最近変更された場合

特に、ドメインに新しい DNS サーバーまたは新しい DNS 登録事業者がある場合、Google Public DNS は古い(ただし有効期限内の)キャッシュに保存された回答を返すことがあります。Flush Cacheドキュメント)を使用して、登録済みのドメインと、古くなった回答を返す特定のドメイン名をフラッシュします。

フラッシュ後も最新の回答が得られた場合は、dns.google の詳細ページで登録済みドメインの SOA RR タイプに対するクエリを実行し、ゾーンのシリアル番号(&Answert\quot; "data")を確認します。異なるシリアル番号が返される場合は、権威ネームサーバーの一部が古いデータを提供している可能性があります。その場合、ドメインの DNS オペレーターで問題を解決する必要があります。

コンテンツ配信ネットワーク(CDN)ドメインのアドレスが遠い場合

より近いアドレスが返された場合は、権威ネームサーバーが EDNS クライアント サブネット(ECS)を適切に実装していない可能性があります。ドメインの DNS オペレーターは、そのページのガイドラインをすべて遵守していることを確認します。

アプリケーションに dns.google ウェブ検索結果と異なるアドレスが表示された場合

dns.google のウェブサイトがブロックされたり、検索結果が大きく異なる場合は、まず Google Public DNS を使用していることを確認してください。その場合、キャプティブ Wi-Fi ポータルによる DNS ハイジャック、ルーター、ISP、またはネットワーク上のマルウェアが原因である可能性があります。ブロックと不正使用のトラブルシューティングの説明をご覧ください。

ドメインの解決に時間がかかりすぎる

tracerouteping などのツールはネットワークのレイテンシを報告しますが、DNS の解決速度を測定するものではありません。遅延がある場所を探したときや、ネットワーク到達性を確認する場合にのみ役立ちます。Google は、ICMP またはランダムな UDP から Google Public DNS IP アドレスへのブロックは行いませんが、ICMP エラー応答にはレート制限があり、Google ネットワーク内で ICMP トラフィックの優先度が下げられる可能性があります。

DNS 解決速度を測定するには、farrokhi/dnsdiag(Python、GitHub)や dnsping(C#、SourceForge)などの DNS テストツールが必要です。Namebench や GRC DNS Benchmark(Windows 向け)などのツールを使用して、より包括的な測定を行うことができます。

クエリの大都市圏を特定する

デバイスと Google Public DNS リゾルバの間のネットワーク距離は、解決速度に直接影響します。Google は、ネームサーバー識別子オプションを実装して、DNS クエリが処理される大都市圏の空港コードを報告します。大都市圏のロケーションがロケーションからかなり遠い場合、クエリのレイテンシが長くなります。これには、ネットワークと Google の間の最適なルーティングや、大都市圏で処理能力が不足しているなど、さまざまな理由が考えられます。

空港コードを確認するには、EDNS オプション ネームサーバー識別子(NSID)を設定して、DNS リゾルバにクエリを実行します。レスポンスは gpdns-<airport code> の形式になります。次のコマンドを実行して、レスポンスがどの大都市圏から発信されているかを確認します。

macOS または Linux

$ dig @dns.google. +nsid | grep NSID
; NSID: 67 70 64 6e 73 2d 63 68 73 ("gpdns-chs")
$ dig www.google.com @dns.google. +nsid | grep NSID
; NSID: 67 70 64 6e 73 2d 63 68 73 ("gpdns-chs")

IPv6 での解決が遅い

IPv6 を介した解決のレイテンシが IPv4 よりも大幅に長い場合、ISP と Google の間の IPv6 接続が最適ではない可能性があります。

DNS クエリに(一部)応答がない

UDP DNS リクエストのうち、ごく一部が破棄されることは正常ですが、クエリで 1% 以上のクエリが減少した場合は、前のセクションのように DNS テストツールを使用してください。

DNS テストツールが高レベルの未回答のクエリを表示する場合(特に、pingtraceroute で比較可能なドロップ率が表示されない場合)は、IP アドレスによって 1 秒あたり 1,000 件を超えるクエリが生成され、レート制限がトリガーされるかどうかを確認します。該当する場合は、Issue Tracker でレート制限の増加をリクエストできます。

DNS のブロックと不正使用

DNS クエリに対する応答がまったくない場合(dns.google ページが機能した場合)、UDP クエリや TCP クエリがブロックされたり、乗っ取られたりする可能性があります。次のコマンドを実行して、UDP クエリと TCP クエリが Google Public DNS に到達するかどうかを確認します。

Windows

nslookup -debug -type=TXT test.dns.google.com. dns.google.
nslookup -debug -type=TXT -vc locations.dns.google.com. dns.google.

macOS または Linux

dig -t TXT test.dns.google.com. '@dns.google.'
dig -t TXT +tcp locations.dns.google.com. '@dns.google.'

最初のコマンドで "Thanks for using Google Public DNS." と表示された場合は、UDP クエリが Google Public DNS に到達しています。2 番目のコマンドの出力に locations.publicdns.goog. が含まれていれば、TCP クエリも Google に接続しています。

出力に NXDOMAIN と表示されている場合は、別の DNS リゾルバに到達しています。出力にタイムアウトが表示された場合、Google Public DNS への DNS クエリはブロックされます。次のセクションの UDP または DNS の traceroute コマンドを使用して、不正使用やブロックが発生している場所を確認します。

Google Public DNS サーバーに到達していることを確認する

dns.google のホームページを開くことができない場合は、ネットワークに問題があるか、Google Public DNS へのアクセスがブロックされるブロックが発生している可能性があります。

Google Public DNS を DNS リゾルバとして使用するようにシステムが構成されている場合、次のコマンドで dns.google の名前を Google Public DNS の IP アドレスに置き換える必要があります。最初に名前を使用してみてください。失敗した場合は、8.8.8.8 または別のアドレスを使用してください。

コマンド プロンプトでターミナル ウィンドウを開き、次の traceroute コマンドを実行します。

Windows

ICMP エコー リクエストを使用したトレース ルーティング:

tracert -d -w 2000 dns.google

IPv6 の接続をテストするには:

tracert -6 -d -w 2000 dns.google

macOS または Linux

DNS 以外の UDP パケットを使用したトレース ルーティング:

/usr/sbin/traceroute -n -w 2 -m 30 dns.google

IPv6 の接続をテストするには:

/usr/sbin/traceroute6 -n -w 2 -m 30 dns.google

traceroute を実行する権限がないとシステムが表示された場合は、sudo コマンドを使用して実行します。

sudo /usr/sbin/traceroute -n -w 2 -m 30 dns.google

出力の最後の行に Google Public DNS の IP アドレス(8.8.8.8、8.8.4.4、または 2001:4860:4860 で始まる IPv6 アドレス)が表示されない場合は、ネットワークの問題によって Google にアクセスできない可能性があります。

Windows 以外のシステムでは、-I オプションまたは -U オプションを使用して上記のコマンドを繰り返し、DNS ポート(53)に送信された ICMP パケットまたは DNS 以外の UDP パケットを使用します。-I オプションが認識されない場合は、ping コマンドを使用して ICMP を送信します。

macOS または Linux

ping -c 2 dns.google

ドメインの解決が遅すぎるで説明されている Farrokhi/dnsdiag DNS テストツールの dnstraceroute コマンドを使用すると、Windows でも実際の DNS クエリのルートをトレースできます。

これらのコマンドの一部が動作して、ネットワーク エラーやタイムアウトが返される場合は、ネットワーク フィルタリングにより Google Public DNS に到達していない可能性があります。詳しくは、ネットワーク管理者または ISP のサポート窓口にお問い合わせください。

どのコマンドも成功しない場合は、(アップストリーム)ISP にお問い合わせください。Google とピアリングしている ISP の場合は、Google NOC にお問い合わせください。3 つの星 * * *(一貫したタイムアウトを示す)がない traceroute 出力の最後の行に、どこで問題が発生しているかが示されている場合があります。