FortiGateのDNS設定とトラブルシューティング完全ガイド

FortiGateを運用する上で、DNS設定は最も基本的でありながら、トラブルが発生しやすいポイントの一つです。名前解決ができないとインターネットアクセスやアプリケーション連携に支障をきたすため、正確な設定方法と効果的なトラブルシューティング手順を身につけることが重要です。本記事では、FortiGateのDNS設定からトラブル時の診断方法まで、実例を交えて詳しく解説します。

FortiGateにおいてDNS設定は複数の目的で使用されます。まず、FortiGate自身が外部サービスと通信する際の名前解決、次にユーザーからのDNS問い合わせを中継するDNSプロキシ機能、そしてセキュリティ機能であるWebフィルタリングやアンチウイルスで使用するドメイン情報の取得などです。

特にFortiGate自身の名前解決は、FortiGuardサービスへの接続、NTPサーバーとの時刻同期、外部SyslogやSNMPトラップの送信など、多くの機能に影響します。そのため、DNS設定の不備は想定外の広範囲に影響を及ぼす可能性があります。

FortiGateでは主に3種類のDNS設定が存在します。以下の表で各設定の用途と優先度を整理します。

図1: DNS設定の優先順位と使用率

まずはGUIを使用した基本的なDNS設定方法を解説します。FortiGateの管理画面にログインし、System DNS設定を行う手順を見ていきましょう。

特定のインターフェースでDHCPクライアントとして動作している場合、そのインターフェース専用のDNSサーバーを設定することも可能です。これはマルチホーム環境やVPN接続時に有用です。

「Network」→「Interfaces」から対象のインターフェースを選択し、編集画面で「Retrieve default gateway from server」と「Retrieve DNS servers from server」オプションを確認します。これらが有効な場合、DHCPサーバーから取得した情報が使用されます。

CLIを使用したDNS設定は、大量の設定変更や自動化、トラブルシューティング時に非常に有効です。ここでは実際のコマンド例を交えて解説します。

System DNSの設定は以下のコマンドで行います。SSHまたはコンソールでFortiGateに接続し、以下を実行します。

config system dns
    set primary 8.8.8.8
    set secondary 8.8.4.4
    set source-ip 0.0.0.0
end

上記の設定では、Googleが提供するパブリックDNSを使用しています。企業環境では内部DNSサーバーのIPアドレスを指定するのが一般的です。

特定のインターフェースを経由してDNS問い合わせを送信したい場合は、以下のように設定します。

config system dns
    set primary 10.0.1.10
    set secondary 10.0.1.11
    set interface wan1
end

この設定により、wan1インターフェースを経由して10.0.1.10および10.0.1.11のDNSサーバーに問い合わせが送信されます。マルチホーム環境でルーティングテーブルが複雑な場合、この明示的な指定が有効です。

現在のDNS設定を確認するには、以下のコマンドを使用します。

show system dns

# 出力例
config system dns
    set primary 8.8.8.8
    set secondary 8.8.4.4
    set interface "wan1"
end

また、実際にDNS問い合わせが動作するかテストするには、以下のコマンドが有効です。

execute ping www.google.com

# 出力例
PING www.google.com (142.250.207.36): 56 data bytes
64 bytes from 142.250.207.36: icmp_seq=0 ttl=116 time=2.3 ms
64 bytes from 142.250.207.36: icmp_seq=1 ttl=116 time=2.1 ms
--- www.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss

このコマンドでFQDNに対してpingが成功すれば、DNS名前解決が正常に動作していることが確認できます。

FortiGateではDNS問い合わせの詳細なログを取得するための診断コマンドが用意されています。トラブルシューティング時に非常に有効なこれらのコマンドを詳しく見ていきましょう。

FortiGateのDNSプロキシ機能の動作をリアルタイムで確認する最も重要なコマンドが「diagnose debug application dnsproxy」です。以下の手順で実行します。

# デバッグを有効化
diagnose debug application dnsproxy -1
diagnose debug enable

# 実際の出力例
req: 192.168.1.100:54321 -> 192.168.1.1:53, len 45, cmd query
query: www.example.com type A(1) class IN(1)
try server 8.8.8.8
send to 8.8.8.8, len 45
recv from 8.8.8.8, len 61
ans: www.example.com -> 93.184.216.34, ttl 3600
send to 192.168.1.100:54321, len 61

# デバッグを無効化
diagnose debug disable
diagnose debug reset

この出力から以下の情報が読み取れます：

出力内容の詳細解説を以下の表にまとめます。

より詳細にDNSパケットの内容を確認したい場合は、FortiGate組み込みのSniffer機能を使用します。

# DNS通信のキャプチャ（port 53）
diagnose sniffer packet any "port 53" 4 0 l

# 特定のホスト名に対するDNS問い合わせのみキャプチャ
diagnose sniffer packet any "port 53 and host 8.8.8.8" 6 10 l

# 出力例
2024-01-15 10:23:45.123456 wan1 in 192.168.1.100.54321 -> 192.168.1.1.53: udp 45
2024-01-15 10:23:45.123789 wan1 out 10.1.1.1.54321 -> 8.8.8.8.53: udp 45
2024-01-15 10:23:45.126543 wan1 in 8.8.8.8.53 -> 10.1.1.1.54321: udp 61
2024-01-15 10:23:45.126789 wan1 out 192.168.1.1.53 -> 192.168.1.100.54321: udp 61

コマンドのパラメータ説明：

• 数値「4」はverboseレベル（0～6、値が大きいほど詳細）
• 数値「0」はキャプチャするパケット数（0は無制限）
• 「l」オプションはタイムスタンプ付きで表示

FortiGateはDNS問い合わせ結果をキャッシュします。このキャッシュの内容を確認するには以下のコマンドを使用します。

# DNSキャッシュの表示
diagnose test application dnsproxy 6

# 出力例
cache entry count: 45
www.example.com -> 93.184.216.34 ttl=3245
www.google.com -> 142.250.207.36 ttl=287
mail.example.com -> 93.184.216.35 ttl=1823

# DNSキャッシュのクリア
diagnose test application dnsproxy 1

キャッシュが古い情報を保持している場合、クリアすることで問題が解決する場合があります。

FortiGateのDNS機能を正常に動作させるためには、適切なファイアウォールポリシーの設定が不可欠です。特に見落としがちなのが、FortiGate自身からDNSサーバーへのアクセス許可設定です。

各インターフェースには「Allow access to DNS server on interface」という設定項目があります。これは、そのインターフェースを経由してDNS問い合わせを送信することを許可するかどうかを制御します。

GUI設定手順：
1. 「Network」→「Interfaces」を選択
2. 対象インターフェース（通常はwan1など外部接続インターフェース）を編集
3. 「Administrative Access」セクションで「DNS」にチェックを入れる
4. 設定を保存

CLIでの設定例：

config system interface
    edit "wan1"
        set allowaccess dns
    next
end

# 複数のアクセス許可を設定する場合
config system interface
    edit "wan1"
        set allowaccess ping https ssh dns
    next
end

内部ユーザーが外部DNSサーバーに直接問い合わせる場合（FortiGateをDNSプロキシとして使用しない場合）、明示的なファイアウォールポリシーが必要です。

# DNS許可ポリシーの作成例
config firewall policy
    edit 10
        set name "Allow_DNS_to_Internet"
        set srcintf "port1"
        set dstintf "wan1"
        set srcaddr "Internal_Network"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "DNS"
        set logtraffic all
        set nat enable
    next
end

このポリシーにより、内部ネットワークから外部DNSサーバーへの通信が許可されます。ログを有効にすることで、どのクライアントがどのDNSサーバーに問い合わせているかを追跡できます。

図2: DNS通信パターン別の設定要件

DNS関連のトラブルは、ネットワーク運用において最も頻繁に発生する問題の一つです。ここでは体系的なトラブルシューティング手順を解説します。

まず最初に行うべきは、DNS設定そのものが正しく構成されているかの確認です。

# System DNS設定の確認
show system dns

# 期待される出力
config system dns
    set primary 8.8.8.8
    set secondary 8.8.4.4
    set interface "wan1"
end

# インターフェースのDNSアクセス許可確認
show system interface wan1 | grep allowaccess
    set allowaccess ping https ssh dns

この時点でDNSサーバーアドレスが未設定、またはallowaccessにdnsが含まれていない場合は、それが原因です。

DNS設定が正しくても、DNSサーバーまでの通信経路に問題がある場合、名前解決は失敗します。

# DNSサーバーへのPing確認
execute ping 8.8.8.8

# 成功例
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=3.2 ms
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

# 失敗例（到達不可）
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Pingが通らない場合は、ルーティングテーブルとデフォルトゲートウェイを確認します。

# ルーティングテーブルの確認
get router info routing-table all

# デフォルトルートの確認
S*      0.0.0.0/0 [10/0] via 203.0.113.1, wan1

DNSサーバーに到達可能でも、実際のDNS問い合わせが失敗する場合があります。リアルタイムデバッグで確認します。

# DNSデバッグ開始
diagnose debug application dnsproxy -1
diagnose debug enable

# 別のSSHセッションまたはクライアントから名前解決実行
execute ping www.google.com

# 正常な出力例
req: 192.168.1.1:53 -> 8.8.8.8:53, len 32, cmd query
query: www.google.com type A(1) class IN(1)
try server 8.8.8.8
send to 8.8.8.8, len 32
recv from 8.8.8.8, len 48
ans: www.google.com -> 142.250.207.36, ttl 300

# 異常な出力例（タイムアウト）
req: 192.168.1.1:53 -> 8.8.8.8:53, len 32, cmd query
query: www.google.com type A(1) class IN(1)
try server 8.8.8.8
send to 8.8.8.8, len 32
timeout - no response from 8.8.8.8
try server 8.8.4.4
send to 8.8.4.4, len 32
recv from 8.8.4.4, len 48
ans: www.google.com -> 142.250.207.36, ttl 300

# デバッグ停止
diagnose debug disable
diagnose debug reset

タイムアウトが発生している場合、ファイアウォールポリシーまたはDNSサーバー側の問題が考えられます。

DNSパケットがポリシーで許可されているか、実際のセッションが確立されているかを確認します。

# アクティブなDNSセッションの確認
diagnose sys session filter dport 53
diagnose sys session list

# 出力例
session info: proto=17 proto_state=01 duration=2 expire=178 timeout=0
src: 192.168.1.1:54321
dst: 8.8.8.8:53
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0
state=may_dirty npu
statistic(bytes/packets): org=45/1 reply=61/1
orgin->sink: org pre->post, reply pre->post dev=5->4/4->5 gwy=203.0.113.1/192.168.1.100

セッションが表示されない場合、ポリシーで通信がブロックされている可能性があります。

# ポリシールックアップの実行
diagnose firewall iprope lookup src 192.168.1.1 dst 8.8.8.8 sport 54321 dport 53 proto 17

# 出力例
policy id: 5 (allow)
src intf: port1
dst intf: wan1

「policy id: 0 (deny)」と表示される場合、マッチするポリシーが存在しないため通信が拒否されています。