FQDN フィルタリングのメリットと限界 – Juniper SSG 5 から DNS 依存の制御を考える

Juniper SSG 5 のようなファイアウォールでは、IP アドレスだけでなく FQDN（Fully Qualified Domain Name）を使ってフィルタリングできる場合があります。これは便利ですが、DNS に依存する制御である以上、万能ではありません。

この記事では、古い Juniper SSG 5 の話を出発点に、FQDN フィルタリングのメリットとデメリットを現在のネットワーク設計の観点で整理します。

FQDN フィルタリングとは何か

FQDN フィルタリングは、ルールに IP アドレスではなく example.com のような名前を指定し、その名前解決結果に基づいて通信を許可または拒否する仕組みです。

ファイアウォールは DNS サーバーへ問い合わせ、FQDN に対応する IP アドレスを取得します。その IP アドレスを内部的な許可・拒否ルールに反映し、通信を制御します。

方式	指定するもの	向いている用途
IP アドレス制御	固定 IP、ネットワークアドレス	自社拠点、固定されたサーバー、明確な宛先
FQDN 制御	ホスト名、ドメイン名	クラウドサービス、名前で管理したい外部サービス
URL / L7 制御	URL、HTTP Host、パス、カテゴリ	Web アプリケーション単位の制御

FQDN を使うメリット

FQDN フィルタリングの最大の利点は、人間が理解しやすい名前でルールを書けることです。クラウドサービスや外部 SaaS のように IP アドレスが変わる相手を、名前で扱えるのは便利です。

• IP アドレス変更に追従しやすい
• ルールの意図を読みやすい
• クラウドサービスや外部 API の宛先を管理しやすい
• 固定 IP が公開されていないサービスでも制御しやすい

特に、IP アドレスを手作業で追いかける運用は破綻しやすいため、名前で管理できること自体には意味があります。

DNS に依存することの危うさ

一方で、FQDN フィルタリングは DNS に依存します。これは、DNS の解決結果が正しいこと、ファイアウォールがその結果を適切にキャッシュすること、通信先がその解決結果と一致することを前提にしています。

• DNS キャッシュの更新タイミングによって許可・拒否の状態がずれる
• TTL が短いサービスでは追従が難しい場合がある
• CDN やクラウドでは同じ FQDN でも多数の IP に分散される
• DNS ラウンドロビンや地域別応答で解決結果が変わる
• 名前解決した IP と実際の通信先の関係が単純ではない場合がある

つまり、FQDN フィルタリングは名前を指定しているように見えて、実際にはファイアウォールが取得した IP アドレスの集合に対する制御です。この変換部分を理解していないと、意図した通りに動かないことがあります。

CDN とクラウドサービスで難しくなる

現在の Web サービスは、CDN、ロードバランサー、クラウド基盤の上で動いていることが多く、FQDN と IP アドレスが一対一で対応しません。

たとえば、ある FQDN が複数の IP アドレスを返し、その IP アドレスが他のサービスと共有されている場合、IP ベースに展開されたフィルタリングでは粒度が粗くなります。逆に、許可すべき IP が解決タイミングによって漏れると通信できなくなります。

DoH / DoT との関係

FQDN フィルタリングと DNS ベースの制御を考えるとき、DoH（DNS over HTTPS）や DoT（DNS over TLS）の存在も無視できません。クライアントがファイアウォールの想定しない DNS 経路を使うと、DNS クエリの可視性が落ちます。

ただし、FQDN フィルタリングそのものは、ファイアウォール自身が名前解決してルールを展開する方式であり、クライアントの DNS クエリを直接見ているだけとは限りません。そのため、DoH による問題は製品や構成によって変わります。

重要なのは、DNS クエリを監視・制御しているのか、ファイアウォールが FQDN を解決して IP リストへ展開しているのか、URL / SNI / HTTP Host まで見ているのかを混同しないことです。

FQDN、SNI、URL 制御は別物

制御方式	見る情報	注意点
FQDN フィルタリング	DNS 解決結果	IP への展開とキャッシュに依存する
SNI 制御	TLS ClientHello の SNI	ECH などで見え方が変わる可能性がある
URL 制御	HTTP Host、URL、カテゴリ	HTTPS では復号やプロキシ設計が関係する
IP 制御	送信元 / 宛先 IP	クラウドや CDN では粒度が粗くなる

これらは似ているようで、見ている場所が違います。FQDN フィルタリングを URL フィルタリングやアプリケーション制御と同じものとして扱うと、設計を誤ります。

Juniper SSG 5 の文脈で読む

Juniper SSG 5 は古い機器ですが、FQDN フィルタリングを使うときの注意点は現在でも通用します。むしろ現在はクラウド、CDN、DoH、SaaS が増えているため、FQDN ベース制御の限界はより意識する必要があります。

中小規模の環境では、FQDN で設定できるから便利、という理由だけで使われることがあります。しかし、DNS キャッシュ、TTL、名前解決経路、実際の通信先、ログの見え方を理解していないと、トラブル時に説明できない制御になります。

設計上の使いどころ

FQDN フィルタリングは、使ってはいけない機能ではありません。むしろ、適切な用途では便利です。ただし、制御の強度を過信しないことが重要です。

• 外部 API や SaaS への通信許可を名前で管理する
• IP アドレス変更が多いサービスへの追従を楽にする
• 完全なセキュリティ境界ではなく、運用上の許可条件として使う
• 重要な制御は、認証、プロキシ、WAF、エンドポイント制御などと組み合わせる

FQDN フィルタリングは、名前ベースの便利な補助機能として使うのが現実的です。強いセキュリティ境界として過信すると危険です。

参考書籍

関連する記事

• DoH 時代に DNS クエリ制御だけでは不十分な理由
• Palo Alto と F5 BIG-IP の責務分離
• DNSSEC と NTP 名前解決できない
• DoH 時代に DNS クエリ制御だけでは不十分な理由

まとめ

FQDN フィルタリングは、IP アドレスではなく名前で通信先を指定できる便利な機能です。しかし、その実体は DNS 解決結果に基づく制御であり、DNS キャッシュ、TTL、CDN、クラウド、DoH / DoT の影響を受けます。

Juniper SSG 5 のような古い機器の話であっても、FQDN フィルタリングの本質的な注意点は現在でも変わりません。名前で制御しているように見えて、実際にはどの情報を見て、どのタイミングで IP に展開し、どこまで信頼しているのかを理解することが重要です。