DNS フォワーダー（DNS Forwarder）
概要
DNS フォワーダー（DNS Forwarder） は、クライアントから受け取った DNS クエリを別の再帰リゾルバーに転送し、その応答をクライアントに返す DNS サーバーです。自身ではルートネームサーバーから権威ネームサーバーまでの再帰的な名前解決を行いません。RFC 5625（2009年）で DNS プロキシの動作要件が規定されています。
フォワーダーは企業ネットワーク、家庭のルーター、VPN 環境で広く使われています。企業では社内の DNS サーバーがフォワーダーとして動作し、社内ドメインは自身の権威データから応答し、外部ドメインは ISP やパブリック DNS（8.8.8.8、1.1.1.1）に転送する構成が一般的です。
家庭のブロードバンドルーターも DNS フォワーダーとして動作します。PC やスマートフォンの DNS 設定がルーターの IP（例: 192.168.1.1）を指し、ルーターが ISP の DNS サーバーにクエリを転送します。
仕組み
フォワーダーの処理フロー、再帰リゾルバーとの違い、条件付きフォワーディングの活用パターンを解説します。
フォワーダーの動作
フォワーダーの処理フローは再帰リゾルバーと比べてシンプルです。
- クライアントが DNS クエリをフォワーダーに送信する
- フォワーダーは自身のキャッシュを確認する
- キャッシュにヒットすればクライアントに返す
- キャッシュになければ、設定された転送先リゾルバーにクエリを転送する
- 転送先から応答を受け取り、キャッシュに保存してクライアントに返す
再帰リゾルバーとの違いは、ステップ 4 です。再帰リゾルバーはルートネームサーバーから順に反復クエリを行いますが、フォワーダーは設定された転送先に再帰クエリをそのまま送信します。
再帰リゾルバーとの比較
| 項目 | DNS フォワーダー | 再帰リゾルバー |
|---|---|---|
| 再帰解決 | 行わない（転送先に依存） | 行う（ルートから権威サーバーまで巡回） |
| クエリの送信先 | 設定された転送先リゾルバー | ルート → TLD → 権威サーバー |
| キャッシュ | 持つ（転送先から得た結果） | 持つ（再帰解決した結果） |
| 必要なネットワーク接続 | 転送先への到達性のみ | インターネット全体への到達性 |
| 用途 | 社内 DNS、ルーター、DNS フィルタリング | ISP、パブリック DNS |
フォワーダーは転送先リゾルバーへの到達性さえあれば動作するため、ファイアウォールの制約が厳しい環境でも導入しやすい利点があります。
条件付きフォワーディング（Conditional Forwarding）
フォワーダーの中でも、ドメインごとに転送先を分ける「条件付きフォワーディング」が実務で広く使われています。
社内ドメイン（internal.corp.） → 社内 DNS サーバー（10.0.0.53）
外部ドメイン（その他） → パブリック DNS（8.8.8.8）VPN 環境でもよく利用されます。VPN 接続先の社内ドメインだけを VPN 側の DNS に転送し、それ以外のクエリは通常のリゾルバーに送る「スプリット DNS」は、条件付きフォワーディングの一形態です。
フォワーダーを使う場面
企業ネットワーク: Active Directory 環境では、ドメインコントローラーが DNS サーバーとフォワーダーの両方の役割を担います。AD のドメインは自身の権威データから応答し、外部ドメインは社外の DNS に転送します。
DNS フィルタリング: Pi-hole や AdGuard Home は DNS フォワーダーとして動作し、広告やマルウェアのドメインをブロックします。ブロック対象でないクエリは上位の DNS サーバーに転送されます。
DNS 暗号化のプロキシ: ローカルに DoH / DoT 対応のフォワーダーを配置し、クライアントからは平文 DNS でクエリを受け、上流への転送を暗号化する構成があります。cloudflared（Cloudflare のツール）や dnscrypt-proxy がこの用途で使われています。
設定例
BIND、Unbound、dnsmasq の 3 つの DNS ソフトウェアでのフォワーダー設定例を示します。
BIND でのフォワーダー設定
// /etc/named.conf
options {
directory "/var/named";
forwarders {
8.8.8.8;
8.8.4.4;
};
forward only; // 転送先に到達できない場合は SERVFAIL を返す
// forward first; // 転送先に到達できない場合は自分で再帰解決する
};forward only は転送先が応答しない場合に SERVFAIL を返します。forward first は転送先が応答しない場合に自身で再帰解決を試みます。
Unbound でのフォワーダー設定
# /etc/unbound/unbound.conf
server:
interface: 0.0.0.0
access-control: 192.168.1.0/24 allow
forward-zone:
name: "."
forward-addr: 1.1.1.1
forward-addr: 8.8.8.8
# 条件付きフォワーディング
forward-zone:
name: "internal.corp."
forward-addr: 10.0.0.53dnsmasq でのフォワーダー設定
# /etc/dnsmasq.conf
server=8.8.8.8
server=1.1.1.1
# 特定ドメインの転送先を指定
server=/internal.corp/10.0.0.53dnsmasq は軽量なフォワーダーとして Linux ルーターや組み込み機器でよく使われています。
確認方法
自分が使っている DNS サーバーがフォワーダーかどうかを確認するには、DNS クエリの応答ヘッダーを見ます。
# DNS サーバーの応答ヘッダーを確認
dig A example.com @192.168.1.1;; flags: qr rd ra; QUERY: 1, ANSWER: 1ra（Recursion Available）フラグが立っていれば、再帰クエリに対応しています。ただしフォワーダーも ra フラグを返すため、このフラグだけではフォワーダーか再帰リゾルバーかを区別できません。
フォワーダーの転送先を推測するには、応答の TTL を手がかりにします。
# 同じクエリを短い間隔で 2 回実行し、TTL の減少量を比較
dig A example.com @192.168.1.1フォワーダーは転送先のキャッシュ TTL をそのまま転送するため、TTL の減少パターンが転送先リゾルバーの挙動に依存します。
外部の視点からも確認したい場合は、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 }
}手元のフォワーダー経由の dig と Labee API で異なる結果が返る場合、フォワーダーまたは転送先リゾルバーのキャッシュに古い結果が残っています。
よくある問題
フォワーダーの運用では転送先の障害、キャッシュの二重構造、ルーターの TTL 無視が代表的なトラブル原因です。
フォワーダーの転送先が応答しない
転送先リゾルバー（ISP の DNS やパブリック DNS）がダウンしている場合、forward only 設定のフォワーダーは全クエリに SERVFAIL を返します。転送先を複数設定し、1 台目が応答しない場合に 2 台目にフォールバックする構成にしてください。forward first 設定であれば、転送先が応答しない場合に自身で再帰解決を試みますが、ファイアウォールの制約で外部の DNS サーバーに到達できない環境ではこのフォールバックも失敗します。
キャッシュの二重構造による遅延
フォワーダーと転送先リゾルバーの両方がキャッシュを持つため、DNS 変更後に二重のキャッシュが問題になることがあります。転送先リゾルバーのキャッシュが更新されても、フォワーダーのキャッシュに古い結果が残っていれば古い応答が返り続けます。フォワーダーのキャッシュをフラッシュするには、フォワーダーソフトウェアの再起動や rndc flush（BIND）などのコマンドを使います。
ルーターのフォワーダーが TTL を無視する
一部のブロードバンドルーターは DNS フォワーダーとして動作する際、レコードの TTL を無視して独自の長い期間キャッシュします。TTL を短く設定しても効果がないケースがあります。PC やスマートフォンの DNS 設定をルーター経由ではなく、パブリック DNS（8.8.8.8 や 1.1.1.1）に直接向けることで回避できます。