FQDN フィルタリングは、通信先を IP アドレスではなく名前で指定できるため、ファイアウォールの運用を読みやすくできます。外部サービスやクラウドサービスのように、接続先 IP アドレスが変わる環境では特に便利です。
ただし、FQDN を指定できることと、その通信を強い意味で識別できることは別です。FQDN フィルタリングは DNS の名前解決結果を利用する仕組みであり、URL フィルタリング、SNI 制御、アプリケーション制御とは役割が異なります。
この記事では、Juniper SSG 5 のような古いファイアウォールで使われていた FQDN フィルタリングを題材にしながら、DNS 依存の通信制御を現在のネットワーク設計でどう扱うべきかを整理します。
FQDN フィルタリングとは何か
FQDN フィルタリングは、ルールに example.com のような名前を指定し、ファイアウォール側で名前解決した結果の IP アドレスを通信制御に使う考え方です。人間がルールを読む時には名前で意図を理解でき、機器側では実際の宛先 IP アドレスに展開して判定します。
そのため、内部的には「名前で通信を見ている」というより、「名前から得られた IP アドレスを使って通信を許可・拒否している」と考えた方が正確です。
| 項目 | 内容 |
|---|---|
| 指定するもの | FQDN。例: updates.example.com |
| 判定に使うもの | DNS 解決で得られた IP アドレス |
| 得意なこと | 接続先 IP が変わるサービスを、名前で運用上わかりやすく扱う |
| 苦手なこと | URL パス、アプリケーションの中身、ユーザー操作単位の判定 |
FQDN を使うメリット
FQDN フィルタリングの最大の利点は、ルールの意図が読みやすくなることです。IP アドレスだけが並んだルールでは、後から見た時に何の通信を許可しているのか分かりにくくなります。名前で指定できれば、運用者は通信先の意味を追いやすくなります。
- 外部 API や更新サーバーなど、接続先の意味をルールに残しやすい
- IP アドレス変更があるサービスでも、手動更新の負担を減らせる
- 許可ルールの説明性が上がり、レビューしやすくなる
- 小規模なネットワークでは、IP ベースの静的管理より現実的な場合がある
Juniper SSG 5 の時代でも、この利点は大きかったはずです。固定 IP のサーバーだけを相手にするなら IP 指定でも十分ですが、インターネット側のサービスを扱うと、IP アドレスだけでは運用が硬すぎます。
DNS に依存することの危うさ
一方で、FQDN フィルタリングは DNS に強く依存します。ファイアウォールが名前解決した結果と、実際にクライアントが使う名前解決結果が常に一致するとは限りません。
- DNS の TTL やキャッシュにより、機器が持つ IP 情報が古くなることがある
- クライアントとファイアウォールで参照する DNS サーバーが異なる場合、解決結果がずれる
- CDN やクラウドサービスでは、接続元や時間帯により返る IP アドレスが変わる
- 同じ IP アドレスを複数サービスが共有するため、IP 単位では意図したサービスだけを区別しにくい
つまり、FQDN フィルタリングは「名前で書ける便利なルール」ではありますが、「その名前のサービスだけを確実に識別する仕組み」ではありません。ここを混同すると、設計上の期待値を誤ります。
CDN とクラウドサービスで難しくなる
現在のインターネットでは、CDN、ロードバランサー、クラウド基盤、SaaS が広く使われています。これらは、名前解決の結果として返る IP アドレスが動的で、複数のサービスを同じ基盤上で共有していることも珍しくありません。
そのため、ある FQDN を許可したつもりでも、実際には共有基盤の IP アドレスを許可しているに近い状態になることがあります。逆に、許可したいサービスの IP が変わり、通信できなくなることもあります。
FQDN フィルタリングはこの問題を完全には解決しません。IP アドレスを手で追い続けるよりは運用しやすいものの、クラウド時代の通信先識別としては限界があります。
DoH / DoT との関係
DNS over HTTPS、DNS over TLS、ブラウザ内蔵の名前解決機能が入ると、DNS 依存の制御はさらに扱いにくくなります。ファイアウォールや内部 DNS が前提としている名前解決経路と、実際のアプリケーションが使う名前解決経路が一致しないことがあるためです。
この場合、FQDN フィルタリングだけでなく、DNS クエリに頼ったセキュリティ制限も弱くなります。DNS を制御しているつもりでも、ブラウザやアプリケーションが別経路で名前解決を行えば、設計の前提が崩れます。
DNS を制御点として使う場合は、クライアントの DNS 経路、プロキシ、ファイアウォール、ブラウザ設定まで含めて考える必要があります。
FQDN、SNI、URL 制御は別物
FQDN フィルタリング、SNI 制御、URL フィルタリングは似て見えますが、見ている層が違います。ここを混ぜると、どの制御で何ができるのかが曖昧になります。
| 制御方式 | 見るもの | 主な限界 |
|---|---|---|
| FQDN フィルタリング | DNS 解決結果としての IP アドレス | DNS 経路や CDN、共有 IP の影響を受ける |
| DNS フィルタリング | クライアントの DNS クエリ | DoH / DoT や別 DNS 経路で迂回されることがある |
| SNI 制御 | TLS ClientHello のサーバー名 | ECH や非 TLS 通信、アプリケーション仕様の影響を受ける |
| URL フィルタリング | HTTP Host、パス、カテゴリなど | プロキシや TLS 復号、エンドポイント制御が必要になることが多い |
| IP 制御 | 宛先 IP アドレス | クラウド、CDN、共有基盤では粒度が粗い |
FQDN フィルタリングは、URL のパスまでは見ません。example.com は扱えても、https://example.com/admin/ と https://example.com/download/ を区別する仕組みではありません。
実際に確認する時の見方
FQDN フィルタリングを設計する時は、その FQDN がどの IP アドレスに解決されるか、IPv4 と IPv6 の両方で確認します。さらに、TLS の接続先名として何が使われるかも見ておくと、FQDN、DNS、SNI の関係を切り分けやすくなります。
コマンド
dig example.com A
dig example.com AAAA
curl -I https://example.com/
openssl s_client -connect example.com:443 -servername example.com </dev/nullここで確認しているのは、ファイアウォールの設定そのものではなく、通信制御が依存している前提です。名前解決の結果、IPv4 / IPv6 の有無、TLS のサーバー名指定がどうなっているかを見ておくと、後で通信できない理由を追いやすくなります。
Juniper SSG 5 の文脈で読む
Juniper SSG 5 は現在の視点では古い機器ですが、FQDN フィルタリングの設計上の悩みは今でも残っています。むしろ、クラウドや CDN、DoH が一般化した現在の方が、DNS 依存の制御を過信しない姿勢は重要です。
SSG 5 のような機器で FQDN を使う場合、当時は「IP アドレスが変わる外部サービスをどう扱うか」という現実的な運用課題への回答だったと思います。ただし、それは強固なセキュリティ境界というより、管理しやすい許可条件として使うものです。
設計上の使いどころ
FQDN フィルタリングは、完全なセキュリティ境界としてではなく、運用上の許可条件として使うのが自然です。特に、内部から外部の特定サービスへ出る通信を整理する用途では有効です。
- 更新サーバーや外部 API へのアウトバウンド通信を名前で管理する
- IP アドレス変更を手作業で追い続ける運用を減らす
- ルールレビュー時に通信先の意図を読みやすくする
- 厳密な制御が必要な通信は、プロキシ、認証、端末管理、ログ監査と組み合わせる
逆に、強いセキュリティ制御が必要な通信を FQDN フィルタリングだけに任せるのは危険です。名前解決の結果を利用する仕組みである以上、DNS 経路、アプリケーションの名前解決、CDN、共有 IP、TLS の変化をすべて吸収できるわけではありません。
参考書籍
書籍
DNS の仕組み、名前解決、運用、セキュリティを体系的に確認したい場合の参考書籍です。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連する記事
DNS クエリを制御点にする設計が、ブラウザ側の名前解決や DoH によってどう揺らぐかを整理しています。
ブラウザ、DNS、IPv6 ULA、HTTPS の差分が、内部サイトの到達性にどう影響するかを扱っています。
内部 DNS を構成する場合の基本的な考え方と、名前解決基盤の役割を整理しています。
まとめ
FQDN フィルタリングは、IP アドレスだけでは管理しにくい外部通信を名前で扱える便利な仕組みです。ルールの意図を残しやすく、IP アドレス変更にもある程度追従できます。
しかし、それは DNS 解決結果を利用した通信制御であり、URL フィルタリングやアプリケーション制御そのものではありません。CDN、クラウド、DoH、SNI、共有 IP の存在を考えると、FQDN フィルタリングだけで厳密な境界を作るのは無理があります。
設計上は、FQDN フィルタリングを「運用しやすい許可条件」として使い、強い制御が必要な領域ではプロキシ、認証、端末管理、ログ監査、ネットワーク分離と組み合わせるのが現実的です。
関連記事
IPv6 Router Advertisement と DHCPv6 の役割整理
IPv6/IPv4 デュアルスタックのインターネット接続を OSS で作る – NAT66 以前の試行錯誤
IPv4/IPv6 変換技術の重要性と価値
IPv6 における NAT66 再考 – ULA、GUA、Prefix 設計主権、IPv4 NAT の設計抽象
Chrome で IPv6 ULA 宛て HTTPS が開けない時に見ること – Firefox との差分を切り分ける
光 BB ユニットに感じる抵抗感 – ISP 提供ルーターと自宅ネットワーク設計の自由度
MicroK8s で IPv6 / IPv4 デュアルスタックが動かない時に見ること
TCP ECE/CWR とは何か – SYN に ECE/CWR が付く理由と ECN の仕組み