ネームリゾルバ（DNSリゾルバ）完全ガイド：種類・仕組み・セキュリティと運用
エバープレイ編集部ネームリゾルバとは — 概要
ネームリゾルバ（name resolver）は、ホスト名やドメイン名をIPアドレスに変換し、また逆にIPアドレスから名前を得るためのソフトウェアや仕組みを指します。日常的には「DNSリゾルバ（DNS resolver）」として使われることが多く、インターネットや社内ネットワークでの名前解決に不可欠な役割を担います。
ネームリゾルバの主要な種類
- スタブリゾルバ（Stub resolver）：OSやアプリケーション側に組み込まれた軽量なクライアント部分。ユーザーの問い合わせを受け取り、ローカルに設定されたDNSサーバ（通常は再帰的リゾルバ）に問い合わせを投げます。
- 再帰的リゾルバ（Recursive resolver）：クライアントからの問い合わせに対して、ルートサーバから順に辿って最終的な正引き/逆引きの結果を取得し、キャッシュして返すサーバ側の処理。ISPや企業内DNS、公共DNS（Google、Cloudflare等）がこの機能を担います。
- 権威サーバ（Authoritative nameserver）：特定のゾーンについて正しい情報を保持するサーバ。再帰的リゾルバは最終的にこの権威サーバから正式な応答を得ます。
名前解決の基本フロー
典型的な正引き（example.com → IP）フローは次の通りです。
- アプリがホスト名でアクセスを試みる。OSのスタブリゾルバが起動。
- まず /etc/hosts やローカル名前解決サービス（mDNS、LLMNR 等）を参照することがある（OSの設定に依存）。
- ローカルで解決できない場合、スタブリゾルバは /etc/resolv.conf 等で設定された再帰的リゾルバにUDP/TCPで問い合わせを送る。
- 再帰的リゾルバはキャッシュに結果があれば応答し、無ければルート → TLD → 権威の順に問い合わせ（繰り返し問い合わせ／反復問い合わせ）し、最終的な応答をクライアントに返す。
技術的詳細：再帰と反復、キャッシュ、TTL、ネガティブキャッシュ
- 再帰問い合わせ：クライアントが再帰的リゾルバに「最終的な答えを返して欲しい」と要求する形式。再帰的リゾルバは必要な一連の問い合わせを自ら行う。
- 反復問い合わせ（Iterative / Referral）：リゾルバ同士のやり取りで使われ、問い合わせを受けたサーバは最も近い情報（または次に問い合わせるべきネームサーバの情報）を返す。権威サーバは自分が担当するゾーン内の情報を返す。
- キャッシュとTTL：権威サーバが返すリソースレコードにはTTLが設定され、再帰的リゾルバはこれを使って応答をキャッシュする。TTLが切れると再取得が行われる。
- ネガティブキャッシュ：存在しない名前（NXDOMAIN）や存在しないレコードの結果も一定時間キャッシュされる（RFC 2308）。これにより同様の無駄な問い合わせを防ぐ。
セキュリティとプライバシー
ネームリゾルバは攻撃対象やプライバシー懸念の源にもなります。代表的な対策や技術は以下の通りです。
- DNSキャッシュポイズニング対策：トランザクションIDや送信ポートのランダム化により、偽応答を受け取るリスクを減らす。さらにDNSSECによる署名検証を導入すればデータの真正性を検証できる。
- DNSSEC：DNS応答の整合性と完全性を保証するための仕組み。再帰的リゾルバが検証を行うか、スタブが検証済み情報を受け取る運用がある。
- 暗号化（DoT / DoH）：DNS over TLS（DoT, RFC 7858）やDNS over HTTPS（DoH, RFC 8484）により、クライアントとリゾルバ間の問い合わせの盗聴や改竄を防ぐ。プライバシー向上だが、トラフィックの中央集約といった運用上の影響もある。
- EDNS(0)、DNS Cookies、Response Rate Limiting：拡張機能やクライアント識別、レート制限などにより、拡張レスポンスや攻撃耐性が向上する。
OSレベルの名前解決：hosts、nsswitch、systemd-resolved など
名前解決は単にDNSの話だけではありません。代表的なOS側の要素：
- /etc/hosts：固定的な名前解決のためのファイル。DNSより優先される設定もある。
- nsswitch.conf（LinuxのName Service Switch）：どの順番でhosts、dns、nis、ldapなどを参照するかを決める。
- systemd-resolved：近年のLinuxディストリビューションで使われることが多い、ローカルキャッシュやDNS-over-TLS/HTTPSの中継を行えるサービス。
- mDNS／LLMNR：ローカルネットワーク内で名前を解決するプロトコル（例：Avahi、Bonjour）。DNSとは別のローカル解決手段。
主要なリゾルバ実装とその特徴
- BIND：長年使われてきたフル機能のDNSサーバ。権威・再帰双方を提供可能で、豊富な設定と拡張性を持つ。
- Unbound：シンプルで高速な再帰的リゾルバ。DNSSEC検証を標準でサポートし、キャッシュ効率が高い。
- PowerDNS（Recursor/Authoritative）：DBバックエンドやスクリプト連携に強みがある。
- dnsmasq：軽量でDHCPと統合できるためSOHO用途に適する。キャッシュDNSとしても利用される。
- Public DNS（例：Google Public DNS、Cloudflare 1.1.1.1）：大規模で高速、DoH/DoT対応やプライバシー方針を打ち出す例が多い。
運用上のポイントとベストプラクティス
- 再帰的リゾルバは公開する際に不正利用（DNS増幅攻撃等）されないよう、再帰を内部クライアントのみに限定する。
- キャッシュ設定（TTLやプリフェッチ）を調整して性能を最適化する。極端に長いTTLは変更反映遅延を招く。
- DNSSECを導入して整合性を確保する。ただし鍵管理や署名更新の運用負荷を考慮すること。
- DoH/DoTの採用はプライバシー向上に有効だが、トラブルシューティングやアクセス制御に影響するためポリシー設計が必要。
- 監視（キャッシュヒット率、レイテンシ、エラーレート）、ログの保管と分析は問題検知に不可欠。
トラブルシューティングの基本的な手順とコマンド
問題発生時の一般的な診断手順：
- /etc/hosts と nsswitch.conf の確認
- /etc/resolv.conf や systemd-resolved のステータス確認（systemd-resolve --status など）
- dig を使った直接問い合わせ（例：dig @8.8.8.8 example.com +trace +dnssec）でどこで失敗しているかを特定
- nslookup や host、getent hosts でアプリケーションからの見え方をチェック
- 再帰的リゾルバのログやキャッシュ統計の確認（Unbound の unbound-control、BIND の rndc stats など）
まとめ
ネームリゾルバは、インターネットや社内ネットワークでの通信を支える基盤技術です。単に「名前をIPに変える部分」というだけでなく、キャッシュ、セキュリティ（DNSSEC、暗号化）、プライバシー、運用性（キャッシュ戦略、アクセス制御）など多面的な要素が絡みます。システム設計者・運用者は、用途に応じてスタブと再帰の役割分担、暗号化や検証の導入、監視とログ管理を設計する必要があります。
参考文献
- RFC 1034 - Domain Names - Concepts and Facilities
- RFC 1035 - Domain Names - Implementation and Specification
- RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE)
- RFC 4033 - DNS Security Introduction and Requirements (DNSSEC)
- RFC 6891 - Extension Mechanisms for DNS (EDNS(0))
- RFC 7858 - DNS over TLS (DoT)
- RFC 8484 - DNS over HTTPS (DoH)
- RFC 7873 - DNS Cookies
- Wikipedia: Domain Name System — Resolvers
- IANA — Root Name Server Operators
投稿者プロフィール
