スタブリゾルバー（Stub Resolver）

概要

スタブリゾルバー（Stub Resolver） は、OS に組み込まれた軽量な DNS クライアントで、アプリケーションからの名前解決要求を受け取り、設定された再帰リゾルバーに問い合わせを中継する役割を担います。RFC 1034（1987年）で定義された DNS アーキテクチャにおける「最小限のリゾルバー」であり、自身では再帰的な名前解決を行いません。

ブラウザーやメールクライアントが example.com の IP アドレスを必要とするとき、直接ルートネームサーバーに問い合わせることはしません。アプリケーションは OS の名前解決 API（Linux/macOS では getaddrinfo()、Windows では GetAddrInfoW()）を呼び出し、スタブリゾルバーが再帰リゾルバーへクエリを送信します。再帰リゾルバーがルートネームサーバーから権威ネームサーバーまでを巡回して得た最終回答を、スタブリゾルバーがアプリケーションに返します。

スタブリゾルバーは名前解決の「入口」です。DNS のトラブルシューティングでは、スタブリゾルバーがどの再帰リゾルバーを参照しているかを把握することが出発点になります。

仕組み

スタブリゾルバーの処理範囲は再帰クエリの送信に限定されており、OS ごとに実装やキャッシュの挙動が異なります。

スタブリゾルバーの動作

スタブリゾルバーが行う処理は限定的です。

1. アプリケーションから名前解決の要求を受け取る
2. /etc/resolv.conf（Linux/macOS）や OS の DNS 設定（Windows）に記載された再帰リゾルバーの IP アドレスを参照する
3. 再帰リゾルバーに対して再帰クエリ（RD ビット = 1）を送信する
4. 再帰リゾルバーから最終回答を受け取り、アプリケーションに返す

スタブリゾルバーは反復クエリを発行しません。再帰リゾルバーに「最終的な答えを返してほしい」と依頼する再帰クエリのみを送信します。ルートネームサーバーや TLD ネームサーバーへの問い合わせは再帰リゾルバーの仕事です。

OS ごとの実装

Linux では、glibc の getaddrinfo() がスタブリゾルバーとして機能します。参照先の再帰リゾルバーは /etc/resolv.conf に記載されます。systemd-resolved を使うディストリビューション（Ubuntu 18.04 以降など）では、/etc/resolv.conf が 127.0.0.53 を指し、systemd-resolved が中間キャッシュ兼スタブリゾルバーとして動作します。

macOS では、mDNSResponder がスタブリゾルバーとして動作します。DNS 設定はシステム環境設定のネットワーク設定で管理され、/etc/resolv.conf は mDNSResponder によって自動生成されます。

Windows では、DNS Client サービス（dnscache）がスタブリゾルバーとキャッシュを担当します。DNS サーバーの設定はネットワークアダプターのプロパティで管理します。

ローカルキャッシュ

スタブリゾルバー自体はキャッシュ機能を持たない「純粋なスタブ」として設計されていますが、実際の OS 実装ではローカルキャッシュが追加されています。macOS の mDNSResponder、Windows の DNS Client サービス、Linux の systemd-resolved はいずれもローカルキャッシュを持ちます。

ローカルキャッシュの存在は、DNS 変更後に「自分の環境だけ古い結果が返る」問題の原因になります。再帰リゾルバーのキャッシュが更新されても、OS のローカルキャッシュに古い結果が残っていれば、アプリケーションには古い IP アドレスが返ります。

再帰リゾルバーとの違い

項目	スタブリゾルバー	再帰リゾルバー
配置場所	クライアント OS 内	ネットワーク上（ISP、パブリック DNS）
再帰処理	行わない	行う（ルートから権威サーバーまで巡回）
クエリの種類	再帰クエリを送信	反復クエリを他のサーバーに送信
キャッシュ	OS 実装に依存（小規模）	大規模なキャッシュを保持
例	glibc resolver、mDNSResponder	8.8.8.8、1.1.1.1

確認方法

スタブリゾルバーがどの再帰リゾルバーを参照しているかを確認するには、OS の DNS 設定を確認します。

# Linux / macOS: resolv.conf の内容を確認
cat /etc/resolv.conf

nameserver 8.8.8.8
nameserver 8.8.4.4

nameserver 行に記載されている IP アドレスが、スタブリゾルバーの問い合わせ先です。

# macOS: scutil でアクティブな DNS 設定を確認
scutil --dns

# Linux (systemd-resolved): 実際のリゾルバー設定を確認
resolvectl status

dig コマンドはスタブリゾルバーを経由せず、直接 DNS クエリを送信します。スタブリゾルバーの動作を確認するには nslookup や host コマンドが有効です。

# nslookup で名前解決（スタブリゾルバー経由）
nslookup example.com

Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	example.com
Address: 93.184.216.34

Server: 行に表示されるのが、スタブリゾルバーが使用している再帰リゾルバーです。

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/dns?domain=example.com&type=A"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "A": [
        { "address": "93.184.216.34", "ttl": 3600 }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 45 }
}

手元の nslookup と Labee API で異なる結果が返る場合、スタブリゾルバーのローカルキャッシュ、または参照先の再帰リゾルバーのキャッシュに古い結果が残っています。

よくある問題

スタブリゾルバーに起因するトラブルの大半は、ローカルキャッシュや OS の DNS 設定の自動書き換えが原因です。

DNS を変更したのに自分の環境だけ古い結果が返る

OS のスタブリゾルバー（ローカルキャッシュ）に古い結果が残っている場合に発生します。キャッシュをフラッシュして解消します。

# macOS: DNS キャッシュをフラッシュ
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved): DNS キャッシュをフラッシュ
sudo resolvectl flush-caches

# Windows: DNS キャッシュをフラッシュ
ipconfig /flushdns

ブラウザーも独自の DNS キャッシュを持っています。Chrome の場合は chrome://net-internals/#dns から「Clear host cache」でフラッシュできます。

resolv.conf が書き換わる

/etc/resolv.conf を手動で編集しても、NetworkManager や systemd-resolved、DHCP クライアントが自動で上書きすることがあります。systemd-resolved 環境では /etc/systemd/resolved.conf を編集し、systemctl restart systemd-resolved で反映します。

VPN 接続時に名前解決が失敗する

VPN に接続すると、VPN ソフトウェアが /etc/resolv.conf や OS の DNS 設定を書き換え、VPN 側の DNS サーバーを参照先に設定します。VPN の DNS サーバーが社内ドメインしか解決できない構成の場合、外部ドメインの名前解決に失敗します。スプリット DNS（社内ドメインのみ VPN の DNS、それ以外は通常の DNS）を設定することで解決できます。