dig +traceとは

Dig +traceは、対象ドメインの委任チェーンを完全に追跡します。これは、ルート・ネーム・サーバーから、トップレベル・ドメイン（TLD）サーバー、権威ネーム・サーバーに至るまで実行できます。Dig +traceは、チームがDNS解決の問題のトラブルシューティングを行うのに役立ちます。

最もすぐに明らかな問題は、障害通知画面が示すように、特定のドメインまたはサブドメインとの接続が完全に失敗することです。DNS解決の問題のもう1つのタイプは、待ち時間です。これにより、クエリ時間が通常の人間の忍耐力を超えて長くなる可能性があります。

平均DNSルックアップ時間はミリ秒（MSEC）単位で測定され、20 MSEC～120 MSECの範囲のどこかに収まる傾向にあります。最適化の取り組みにより、これらのクエリー時間をさらに短縮することを目指します。

通常のdigコマンドでは、インターネットサービスプロバイダー（ISP）のリゾルバーとして動作するDNSサーバーが再帰リクエストを発行し、ローカルキャッシュに有効期限が切れていない最新のDNSレコードがないかどうかを確認します。しかし、それは理想的な状況、すべてが形になったときに起こることです。

管理者は、「内部検証」が必要な場合に、dig +traceに目を向けます。通常、何か問題が発生したため、通常のクエリプロセスをバイパスする必要があります。ルーティング・チェーンの一部が正しく実行されていません。したがって、管理者は、そのチェーンの一部とそのさまざまな連携を分析して、何が正しく動作していないかを見つけることができる必要があります。

チームがdig +traceを使用すると、以前にキャッシュされたものを効果的に無視するため、古い既存のパスウェイに誘導されることなく、新たな反復クエリを実行できます。

Dig +traceは、DNS解決が違反している場所を確認できるため、トラブルシューティングに役立ちます。問題は、ルート、TLD、または権威レベルにある可能性があります。また、ドメインのネームサーバーレコードが正しいかどうかをチェックし、変更後にDNS伝播を検証することもできます。

dig +traceプロセスは4つのステップに分かれています。

ユーザーが以前にそのドメイン名を入力し、コンピューターがIPアドレスをキャッシュしている場合、コマンド・プロンプト（CMD）は必要なIPアドレスを即座に取得します。システムは要求されたコンテンツにアクセスしてダウンロードし、クエリ・プロセスはそこで終了します。

ただし、ドメイン名がそのデバイスにとって新しいもので未知の場合は、これらのステップの残りが実行されます。

digコマンドは、調査対象のターゲット・ドメインのトップレベル・ドメイン（TLD）に関連付けられたネーム・サーバー（NS）レコードのルート・ネーム・サーバーを探します。

digコマンドは、TLDネーム・サーバーを調査して、特定のドメインの権威ネーム・サーバーを発見します。

次に、digコマンドは権威ネームサーバーにクエリを実行して、要求されたDNSレコードにアクセスします。例えば、「Aレコード」は、人間にとって使いやすいドメイン名とIPv4またはIPv6アドレスを関連付けるリソースレコードです。一方、SOA（Start of Authority）レコードには、DNSゾーンに必要な管理データが保持されています。

提供されるDNS応答には、「回答セクション」が含まれています。これは、元のクエリーに正常に応答できるリソース・レコードです（「質問セクション」とも呼ばれます）。

さらに、応答には、権威ネームサーバーをリストする権限セクションと、場合によっては追加情報を含む「追加セクション」が含まれる場合があります。管理者は、メール・サーバー（MXレコード）とネーム・サーバー（NSレコード）のどちらを意味するかに関係なく、必要なレコードの種類を正確に選択できます。

パスに沿った各調査ステップで、管理者は出力メッセージを受け取り、各フェーズのステータスと、進行が次に進むことを意図したとおりに進んでいるかどうかを知らせます。

たとえば、管理者には「NOERROR」メッセージが表示され、テストのこの段階でインシデントが発生しなかったことが通知されます（注記：このメッセージは、全体的な運用の成功や失敗を示すものではなく、誤解すべきではありません。便利ですが、伝達できる情報は限られています）。

DNSインフラストラクチャーがDNS階層をサポートし、独創的な参照システムを使用してルックアップ・プロセスを支援していることを観察するのは興味深いことです。このようにして、あるサーバーがクエリを完了まで導くことができない場合、基本的にはクエリを別のサーバーに誘導します。このサーバーがクエリの進行を支援し、そのプロセスを拡張します。

インターネットで使用されるドメイン・ネーム・システムは、さまざまなレベルで動作するさまざまなルート・ネーム・サーバーで構成されています。特に重要なのは、最上位レベルで動作する13個の論理ルート・ネーム・サーバー（アルファベットの最初の13文字にちなんで命名）です。

これらの13個の論理ルート・ネーム・サーバーはそれぞれ、単一のコンピューターやオペレーティング・システムを参照させるのではなく、すべてのインターネットDNSクエリー・トラフィックの13分の1を管理する指定権限を表します。したがって、「サーバーA」と言及する場合は、無制限の数の個別のDNSサーバーをカバーできるサーバーA指定を指します。

また、13のルート・ネーム・サーバーが、大学や軍事組織を含めたさまざまな営利企業に委任されていることも注目に値します。当初、ほとんどの物理サーバーの場所は米国に大きく集中していましたが、その方程式は時間の経過とともにバランスが取れています。現在、物理サーバーは世界中に配置されています。

以下は、13の異なるroot-servers.net指定の実行に対する責任を維持するグループです。

• サーバーA（a.root-servers.net）：事業者：VeriSign, Inc.は、インターネット・インフラストラクチャーとドメイン名レジストリー・サービスを世界中で提供しています。

• サーバーB（b.root-servers.net）：オペレーター：南カリフォルニア大学（ISI）。USCの情報科学研究所では、高度なコンピューターおよび通信技術を研究しています。

• サーバーC（c.root-servers.net）：オペレーター：Cogent Communicationsは、充実した光ファイバー・ネットワークを管理し、コロケーション・サービスを提供する国際ISPです。

• サーバーD（d.root-servers.net）：オペレーター：メリーランド大学は、Advanced Cyberinfrastructure and Internet Global Services（ACIGS）グループによって管理されています。

• サーバーE（e.root-servers.net）：オペレーター：NASA、より具体的には米国宇宙機関のNetwork and Telecommunication Services（NaTS）サービス・ラインです。

• サーバーF（f.root-servers.net）：オペレーター：Internet Systems Consortium, Inc.は、さまざまなソフトウェアとプロトコルを提供することでインターネットをサポートする非営利企業です。

• サーバーG（g.root-servers.net）：オペレーター：米国国防総省ネットワーク情報センター（NIC）は、DoDのIPv6アドレス・プランの管理も担当しています。

• サーバーH（h.root-servers.net）：オペレーター：米国陸軍研究所（ARL、旧称弾道研究所（BRL））。

• サーバーI（i.root-servers.net）：オペレーター：Netnodはスウェーデンの非営利インターネット・インフラ組織で、北欧地域内での相互接続サービスで主に知られています。

• サーバーJ（j.root-servers.net）：オペレーター：VeriSign, Inc.（サーバーAを参照）。

• サーバーK（k.root-servers.net）：オペレーター：Reseau IP Europeens Network Coordination Center（RIPE NCC）は、ヨーロッパ、中東、アジアを対象とする非営利の地域インターネット・レジストリー（RIR）です。

• サーバーL（l.root-servers.net）：オペレーター：Internet Corporation for Assigned Names and Numbers（ICANN）は、米国政府との契約を通じて始まりましたが、現在は別の世界を中心とする組織として存在しています。

• サーバーM（m.root-servers.net）：オペレーター：WIDEプロジェクトは、「Widely Integrated Distributed Environment」の略で、このインターネット・プロジェクトは、日本の3大学の共同作業から始まりました。

クエリーのトラフィックは13台のサーバーに均等に分散され、他のサーバーの処理以上のサーバーはありません。地域の要因は、ユーザーが最も多くアクセスするサーバーに影響を与える可能性がありますが、全体的なトラフィックは同様で、そのほとんどにISPアドレスの要求が含まれます。

DNSクエリトラフィックを管理するのに13のエンティティが必要な理由は、毎年何兆件ものDNSクエリが生成されるからです。合計が100兆を超えると推定されているものもありますが、これらの数字は知識に基づいた推測です。これはあまりに大きな数で、実際には計算不能です。

また、対処すべき、直接的に関連する問題がいくつかあります。

• DNSのユーティリティーをさらに高める1つの方法は、Extension Mechanss for DNS（EDNS）を使用することです。EDNSは、DNSプロトコルの機能強化のコレクションです。管理者がより大きなDNSメッセージ・ペイロードに遭遇した場合、EDNSはこのようなサイズ超過のデータ・パッケージを伝送することに適応します。EDNSは、より大きなメッセージに対応するだけでなく、レイテンシーの問題の影響を受けることが多いアプリケーションの性能を向上させるEDNS Client Subnet（ECS）などのオプションも提供しています。

• OPT疑似セクションは、EDNSによって開始されるユニークな種類のDNSレコードです。有用なトランザクション情報を伝送しますが、標準的なDNSデータは含まれていません。OPT擬似セクションは、DNSメッセージの「追加データ」セクションに含まれています。ここには、EDNSバージョン、フラグ、一般的に使用されるクエリ形式であるユーザー・データグラム・プロトコル（UDP）の最大パケット・サイズなどの詳細が記載されています。

• Linuxオペレーティング・システムおよびUnixのような特定のシステムは、etc/resolve.conf構成ファイルを利用して、対応するホスト名のIPアドレスを検索するためにリゾルバー・ルーチンを有効化するようにシステムに通知します。このファイルの内容には、DNSサーバーのIPアドレス、検索するドメインのリスト、ローカル・ドメイン名、およびリゾルバーのアクションを決定するためのオプションが含まれます。これらのアクションには、管理者が一方的に適用できる設定であるグローバルオプションが含まれる場合があります。

• DNSを実際に使用しないUnixのようなシステムには、マニュアルページ（または「man page」）が含まれていることがよくあります。このページは、特定のコマンド・ファイル、システム・コール、または構成ファイルに関する定義済みデータの概要を説明するドキュメンテーションとして機能します。マニュアル・ページは、コマンドやプログラムの名前、概要、説明、オプションなどの情報に焦点を当て、システム・ファイルやツールに関する一般的なコンテキストを提供します。