DNS (Domain Name System)
インターネット上の住所であるIPアドレスを特定するために、DNS解決が行われます。
これは一見単純な電話帳のような仕組みに見えますが、その裏側は世界規模の分散データベースと高度なキャッシュ戦略によって支えられています。
2.1 多層防御的なキャッシュ確認
ネットワークレイテンシを最小化するため、DNSクエリは可能な限り回避されるように設計されています。ブラウザは以下の順序でキャッシュを確認します。
-
ブラウザ内部DNSキャッシュ : Chromiumなどは独自のDNSキャッシュ機構を持っています。chrome://net-internals/#dns で確認可能で、TTLに従って短期間でメモリ上に保持されます。これにより、同一ドメインへの連続アクセス時のオーバーヘッドをゼロにします。
-
OSリゾルバキャッシュ : ブラウザにキャッシュがない場合、OSのシステムコール（getaddrinfo など）を通じてOSのDNSリゾルバに問い合わせます。OSもまた、独自のキャッシュ（WindowsならDNS Client Service、macOSならmDNSResponder）を持っています。
-
hostsファイル : OSはキャッシュ確認と並行して、ローカルの設定ファイル（/etc/hosts や C:\Windows\System32\drivers\etc\hosts）を参照します。開発環境で localhost を使ったり、特定のドメインを強制的に別IPに向けたりするのはこの仕組みを利用しています。
2.2 再帰的DNS解決 (Recursive Resolution) の深淵
ローカルでの解決に失敗した場合、クエリはいよいよ外部ネットワークへ出ます。ここで活躍するのが、ISP（インターネットサービスプロバイダ）やパブリックDNS（Googleの8.8.8.8やCloudflareの1.1.1.1）が提供する 再帰リゾルバ（Recursive Resolver） です。
再帰リゾルバは、クライアントの代わりに世界中のネームサーバーを巡回し、答えを見つけるまで諦めません。このプロセスを 反復的クエリ (Iterative Query) と呼びます。
2.2.1 ルートネームサーバーへの旅
まず、再帰リゾルバは「ルートヒント」と呼ばれるファイルを持ってお り、ここには世界に13種類（a.root-servers.net ～ m.root-servers.net）存在する ルートネームサーバー のIPアドレスが記載されています。
- クエリ: 「qiita.com のIPを知りたい」
- ルートサーバーの回答: 「私は知らないが、.com ドメインを管理しているTLDサーバーの住所なら知っている（IPリストを返す）」
2.2.2 TLDネームサーバーへの問い合わせ
次に、.com や .jp などのトップレベルドメイン（TLD）を管理する TLDネームサーバー へ問い合わせます。
- クエリ: 「qiita.com のIPを知りたい」
- TLDサーバーの回答: 「私は知らないが、qiita.com の権威サーバー（Authoritative Name Server）はAWSのRoute53にあるこれらだ（NSレコードを返す）」
2.2.3 権威ネームサーバーによる最終解決
最後に、ドメインの所有者が管理する 権威ネームサーバー へ問い合わせます。
- クエリ: 「qiita.com のIPを知りたい」
- 権威サーバーの回答: 「そのIPアドレスは 54.250.xx.xx です（Aレコード）」
この最終的な回答が、逆の経路を辿ってブラウザへと届けられます。この間、再帰リゾルバはこの結果を自身のキャッシュに保存し、TTLが切れるまでは他のユーザーからの同じ問い合わせに対して即答できるようにします。
2.3 最新のDNS技術：DoHとDoT
従来のDNSはUDPポート53を使用し、平文で通信されていました。これは経路上での盗聴や改ざん（DNSスプーフィング）のリスクがあります。
これを防ぐため、現代のブラウザやOSは以下の暗号化DNS技術をサポートし始めています。
- DNS over HTTPS (DoH) : HTTPS（ポート443）の中にDNSクエリを隠蔽します。Webトラフィックと区別がつかないため、プライバシー保護に優れています。
- DNS over TLS (DoT) : TLS（ポート853）を用いてDNS専用の暗号化トンネルを作ります。ネットワーク管理者によるモニタリングとセキュリティの両立に適しています。
ブラウザの設定で「セキュアDNSを使用する」などが有効になっている場合、これらのプロトコルが優先的に使用されます。