DNS解決、最初から最後まで

ブラウザーにドメインを入力するたびに、目的のサイトにパケットが1つ到達する前に、一連のルックアップが実行されます。そのほとんどは目に見えず、ほとんどの説明は「電話帳のようなもの」で終わります。実際に何が起きるか、ステップバイステップで説明します。人们が通常スキップする部分も含めて。

スタブリゾルバーは賢くない

オペレーティングシステムは、単独で実DNS解決を行いません。スタブリゾルバーを実行します。これは、/etc/resolv.conf（Linux）またはネットワークアダプター設定（Windows）に設定されたDNSサーバーにクエリを転送するだけの薄いコードです。次のコマンドで確認できます：

cat /etc/resolv.conf

そのファイルは通常、ルーター（192.168.1.1など）、ISPのリゾルバー、または1.1.1.1や8.8.8.8などのパブリックリゾルバーを指します。スタブリゾルバーは、OSまたはsystemd-resolvedのようなローカルデーモンが提供する以上のキャッシュロジックを持ちません。

再帰的リゾルバーが実際の作業を行う

クエリが再帰的リゾルバーに到達すると、そのサーバーは複数の他のサーバーに問い合わせる必要があっても、答えを見つけるという仕事を引き継ぎます。答えが前回のルックアップからキャッシュされている場合、すぐに返されます。TTLは次のコマンドで確認できます：

dig example.com

ANSWER SECTIONを見てください。レコードタイプの前の数値（たとえばAの前の300）は、TTL（秒単位）です。これはリゾルバーがもう一度問い合わせる前にレコードをキャッシュできる期間です。

何もキャッシュされていない場合、再帰的リゾルバーはDNS階層の根から下へ向かう移動を開始します。

ルート、TLD、および権威ネームサーバー

13のルートサーバーアドレス（a.root-servers.netからm.root-servers.netまで）があり、各々はエニーキャストルーティングを通じた多くの物理マシンで支えられています。ルートサーバーはexample.comがどこにあるかは知りませんが、.comを扱うサーバーを知っているため、参照を返します。

その後、リゾルバーは.com TLDサーバーに問い合わせます。これは最終的な答えは知りませんが、example.comの権威ネームサーバーを知っています。この委譲を自分で確認できます：

dig +trace example.com

このコマンドはすべてのホップを表示します：ルート、次にTLD、次にドメインの権威ネームサーバー、最後に実際のAまたはAAAAレコード。これはDNSを理論的ではなく視覚的に理解するための単一の最良のコマンドです。

権威ネームサーバーは最終地点です。これはドメイン所有者が実際に設定したサーバーです。登録事業者のDNSパネルを通じてか、Route 53またはCloudflare DNSのようなサービスを通じてです。これは、キャッシュされたコピーまたは参照の代わりに、実際の正規の答えを持つチェーン全体で唯一のサーバーです。

実際に遭遇するレコードタイプ

Aレコードは名前をIPv4アドレスにマップし、AAAAはIPv6に対して同じです。CNAMEは名前を名前に別の名前をポイントします。これは、CloudflareやFastlyのようなCDNが生IPを公開せずにトラフィックをルーティングする方法です。MXレコードはメールルーティングを処理し、TXTレコードは任意のテキストを保持します。最も一般的には、SPF、DKIM、およびドメイン検証文字列に使用されます。NSレコードはどのサーバーがゾーンの権威であるかを世に知らせます。これはそもそも委譲を可能にするレコードタイプです。

キャッシングが実際に存在する場所

キャッシングは複数のレイヤーで同時に発生します：ブラウザー自体（Chromeはchrome://net-internals/#dnsで表示可能な独自のDNSキャッシュを持ちます）、OSリゾルバーキャッシュ、ローカルルーター、上流の再帰的リゾルバー。これは、DNS変更がある機器では即座に機能しているように見えるのに、別の機器で表示されるのに数時間かかる理由です。同じキャッシュにはアクセスしていません。

計画的なマイグレーション前にレコードのTTLを低下させるとき、何も即座にスピードアップしていません。変更が実際に発生したら古いデータが存在できるウィンドウを縮小しているだけです。カットオーバーの5分前ではなく、少なくとも1つのTTLサイクル先に実施してください。

これがトラブルシューティングで重要である理由

サイトに到達できない場合、dig +traceは正確にどのレイヤーが壊れているかを教えてくれます。ルート/TLD問題は、設定が誤った権威サーバーまたは自分のマシン上の古いキャッシュとはまったく異なって見えます。dig example.comをdig example.com @1.1.1.1のような既知の正常なリゾルバーと比較することで、問題がローカルリゾルバーか、ドメインの実際のDNS設定かが明確になります。

DNSは通常100ms以下で解決し、誰も考えもしないため、外からは単純に見えます。内側は、1980年代から構造的にほぼ変わらずに実行されている分散、キャッシュされた、階層的なクエリシステムです。これは元のデザインがいかによく持ちこたえたかについての非常に良い論証です。

この先へ進みたい場合、Korra StudioはDEFENSE_GRIDで関連セグメントを持っており、DNS拡張セキュリティ、外部流出技術としてのDNSトンネリング、およびPythonでのリゾルバーの構築をカバーしています。