ドメインフィルタリングの仕組みと評価順序について説明します。トラフィックフィルタリングを有効化する手順やルールを追加・編集する手順については、トラフィックフィルタリングを設定する を参照してください。
ドメインフィルタリングの仕組み
ドメインフィルタリング (FQDN フィルタリング) は、デバイスと DNS サーバーの間でやり取りされる 標準的な DNS ポート (UDP/TCP 53) の平文の DNS クエリと応答 から、SORACOM が ドメイン名と解決された IP アドレスを参照 し、その IP アドレスをもとに 動的に IP ルールを生成 することで実現されます。生成されたルールはデバイスからの通信パケットの評価に利用されます。
サポートする DNS サーバー
ドメインフィルタリングは、以下のいずれの DNS サーバーを利用する場合でも動作します。
| DNS サーバー | サポート |
|---|---|
SORACOM が提供する DNS サーバー (100.127.0.53 / 100.127.1.53) | ✓ |
| グループ設定で指定したカスタム DNS サーバー | ✓ |
| デバイスに直接設定された任意の DNS サーバー | ✓ |
ドメインフィルタリングは標準的な DNS ポート (UDP/TCP 53) の平文通信が必要です
ドメインフィルタリングは、UDP/TCP 53 番ポートでやり取りされる平文の DNS クエリと応答に含まれるドメイン名と IP アドレスを SORACOM が参照することで動作します。そのため、以下のような名前解決はドメインフィルタリングの対象にならず、正しく動作しません。
- DoH (DNS over HTTPS) や DoT (DNS over TLS) などの暗号化された DNS: 通信が暗号化されており、内容を参照できません。
- 53 番以外のポートを使用する DNS: 標準的な DNS ポート (UDP/TCP 53) の通信のみを参照するためです。
デバイスやアプリケーションは、標準的な DNS ポート (UDP/TCP 53) で平文の名前解決を行うように構成してください。
動的に生成される IP ルール
1 つのドメインルールは、DNS 応答に含まれる IP アドレスごとに 1 つの動的な /32 IP ルール として展開されます。たとえば、www.example.com の名前解決で 2 つの IP アドレス (例: 163.139.174.40、163.139.174.48) が返された場合、それぞれの IP アドレスに対して /32 の IP ルールが 1 つずつ生成されます。
動的に生成される IP ルールのフィールドは、元のドメインルールから以下のように引き継がれます。
| フィールド | 値 |
|---|---|
cidr | DNS で解決した IP アドレス + /32 |
protocol | ドメインルールの値 |
fromPort / toPort | ドメインルールの値 |
action | ドメインルールの値 (allow のみ) |
動的に生成される IP ルールは IP ルールの上限にカウントされません
ドメインフィルタリングから動的に生成された IP ルールは、IP ルールの上限 (VPG ごとに 500 件) にはカウントされません。ドメインルールから多数の IP アドレスが解決されても、IP ルールの上限を消費しません。
ドメインフィルタリングで制御できない通信
ドメインフィルタリングは DNS の名前解決の結果に基づいて動作するため、HTTP のような上位レイヤーの情報 (URL のパスやクエリパラメーターなど) に基づく制御はできません。
| 制御の単位 | 対応 | 補足 |
|---|---|---|
ドメイン名 (例: api.example.com) | ✓ | DNS の名前解決時に判定されます。 |
URL のパス (例: /foo と /bar) | - | URL のパスは DNS レイヤーでは確認できません。 |
URL のクエリパラメーター (例: ?id=123) | - | クエリパラメーターは DNS レイヤーでは確認できません。 |
たとえば、https://api.example.com/foo への通信を許可しつつ https://api.example.com/bar への通信を拒否するような設定はできません。いずれも DNS の名前解決ではドメイン (api.example.com) として扱われるため、同じルールが適用されます。
ドメインルールの評価順序
ルールの並び順は評価に影響しません
ドメインルールでは、IP ルールと同様に、一覧や CSV の並び順ではなく、最も詳細に一致するルール (ロンゲストマッチ) が適用されます。評価結果を変えるためにルールを並べ替える必要はありません。
| 判定基準 | 優先される条件 |
|---|---|
| ドメイン名 | より具体的なパターンが、ワイルドカードを含むパターンに優先します (例: api.example.com は *.example.com に優先します)。 |
| プロトコル | プロトコルを指定したルールが、ALL (255) を指定したルールに優先します。 |
| ポート | ポートを指定したルールが、ポート未指定のルールに優先します。 |
| ポート範囲 | より狭いポート範囲が、より広いポート範囲に優先します。 |
例: IP ルールで広く拒否し、ドメインルールで個別に許可する
ドメインフィルタリングは IP フィルタリングと組み合わせて、「特定のサービスへの通信のみを許可する」という構成が典型的なユースケースです。以下では、IP フィルタリングですべての通信を拒否し、ドメインフィルタリングで *.example.com への HTTPS (TCP 443) 通信のみを許可します。
IP ルール (すべての通信を拒否):
# cidr, protocol, fromPort, toPort, action
0.0.0.0/0, ALL, any, any, deny
ドメインルール (*.example.com の HTTPS のみ許可):
# fqdnPattern, protocol, fromPort, toPort
*.example.com, TCP, 443, 443
この設定では、デバイスが www.example.com などを名前解決すると、その応答に含まれる IP アドレスに対して、TCP 443 を許可する動的な /32 の IP ルールが生成されます。デバイスからその IP アドレスへの HTTPS 通信は、生成された /32 の IP ルールが 0.0.0.0/0 の拒否する IP ルールよりも詳細なため、許可されます。それ以外の宛先 (*.example.com 以外のドメインなど) への通信は、0.0.0.0/0 の拒否する IP ルールが適用されて拒否されます。
ワイルドカードがマッチするサブドメインの階層について
*.example.com は www.example.com や api.example.com のように example.com の 1 階層下のサブドメイン にのみマッチします。example.com 自体や sub.www.example.com のような 2 階層以上下のサブドメインにはマッチしません。複数階層を許可する場合は、必要なパターンを個別に登録してください。