2026.06.18 2026.06.19

【SASE実践】[障害シナリオ] DNS障害による「LBO不発」

buffoon

企業のOA環境において、Cisco Catalyst SD-WANやZscalerを組み合わせたSASE構成を導入するケースが増えています。その中で最も期待される機能の1つが、M365などの通信を拠点から直接インターネットへ逃がす「LBO」です。

しかし、一見完璧に見えるネットワーク設計でも「DNS」という別レイヤーの不具合によってLBOが完全に機能しなくなるという障害シナリオが存在します。

今回はこの「DNS障害によるLBO不発」のメカニズムとそれを防ぐための設計・運用アプローチについて、Catalyst SD-WANの仕様も交えて解説します。

なぜDNSの不調でLBOが不発するのか？

そもそも、SD-WANルーターがDNS情報をトリガーにしてLBOを行うのは、以下のような仕組み（DNS Snooping）に基づいています。

あらかじめLBO対象アプリケーションのFQDN（ドメイン名）をルーターに登録しておく。
端末が発したDNSクエリに対し、返ってきたDNS応答パケット（Aレコード）をルーター自身が盗み見（Snooping）して、そこに記載されている「IPアドレス」を自身のキャッシュテーブルに保持する。
端末からそのIPアドレス宛ての通信が発生した際、ルーターはキャッシュと照合して「LBO対象アプリへの通信だ」と判別し、直接インターネットへブレークアウトさせる。

この際、ルーターはDNS応答に含まれるTTL（Time To Live：有効期限）も含めてキャッシュします。これにより、端末側に残るDNSキャッシュの有効期限とルーター側のキャッシュが連動し、キャッシュが有効な間は常に正しくLBOができる、という無駄のない仕組みになっています。

この仕組みだからこそ、「DNSの不調」がSD-WANの機能不全と疑われることがあります。

障害シナリオ：SD-WANに異常がないのにLBOが全滅

ターゲット環境の構成

端末のDNS設定： 常に社内の「内部DNSサーバー」を指定している。
内部DNSの挙動： * 自社ドメイン（社内システム）の名前解決は、自ら応答する。
- インターネット宛て（外部ドメイン）の名前解決は「外部DNS参照用のプロキシサーバー」へフォワードする。

悲劇の始まり：外部DNS用プロキシの障害

ある日、この「外部DNS用のプロキシサーバー」だけが障害でダウンしました。

この時、ネットワーク内では以下のような非常に中途半端な現象が発生します。

社内システム宛ての名前解決は、内部DNSが即答するので正常に成功する。
インターネット（Office 365など）宛ての名前解決は、プロキシが死んでいるため応答が返ってこない（タイムアウトする）。

一見すると「インターネットに繋がらない」という単純な障害に見えますが、現場のエンジニアは「社内DNSへの疎通はあるし、社内サイトは開ける。なのにインターネット（LBO対象）だけが通信できない＝ SD-WANのLBO判定がおかしくなって、通信をドロップしているのでは？」という仮説を立ててしまったのです。

結果として、SD-WANのルーティングやポリシー設定を徹底的に調査することになり、原因がプロキシサーバーのハングアップだと気づくまでに膨大な時間を要してしまいました。

泥沼から脱出するための「切り分けアプローチ」

今後同じような事象に直面した際、インフラエンジニアが最短で原因に辿り着くための切り分けステップは以下の通りです。

「DNS自体が部分死していないか」の確認（最優先）
- nslookup や dig を使い、社内ドメインだけでなく、外部ドメイン（google.com など）を叩いてみて、応答が「Time out」にならないかを確認する。
SD-WANルーター上でのDNSスヌーピングテーブルの確認
- ルーターのキャッシュやログを確認し、対象のFQDNに対するIPアドレスの紐付け（マッピング）が生成されているかを見る。ここが空っぽなら、SD-WANのポリシーではなく、DNS側の問題と疑える。
SD-WANルーター上でDNSに関する通信をリアルタイムで可視化して確認
- ルーターでリアルタイムに通信フローを可視化する機能（catalyst sd-wanだとNWPI）を有効にして、UDP53（=DNS）の通信のフローを確認する。内部DNSに関する通信が成功しているが、外部DNSに関する通信が失敗しているログが見れるため、成功と失敗の条件を確認することでDNSの問題だと確信できる。

救済策

プロキシサーバの復旧が見込まれない状況でこのシナリオを救済するために、アプローチは主に2つあります。

アプローチA：SD-WAN側でDNSクエリを「捻じ曲げる」

端末からのDNS通信のうち、内部DNS宛てのものだけをSD-WANルーター側で強制的にインターセプトし、内部DNSサーバへ無理やりルーティングを捻じ曲げて外へ出す、それ以外の外部DNS向けの通信についてはSD-WANルータでLBOさせる設計です。これにより、インターネット宛ての名前解決だけは最短ルートでルーターが成立させることができます。

逆の設計も可能で常時は内部DNSだけを参照するような設定にしておき、緊急時に外部向けだけ再定義する設計を適用させればこのシナリオの回避も可能です。※これは実装したことがありません。

ただし、これは導入するソリューションによって動作が可能か慎重に検証する必要があります。

注意：Cisco Catalyst SD-WANにおける仕様

Catalyst SD-WANでは「DNSリダイレクト機能」がこれに類似します。しかし、動作モードによって挙動が異なります。

無条件リダイレクト（ルーターを常時プロキシとして動作させる＝端末の参照先のDNSはSD-WAN）： DNSのリダイレクト先はオーバーレイ（VPN）上にしか転送できません。そのため、転送先がセンター等の内部DNSになっている場合、その内部DNS自体が障害点になっていると事象を解決できません。

条件付きリダイレクト（端末のDNS指定をISP等の外部DNSにする場合）： 「内部宛てのクエリであれば宛先を内部へ捻じ曲げ、それ以外はインターネットへブレークアウトする」といった使い分けが可能になります。

現在の制限 : 運用回避として、障害発生時にこの転送先を手動で「生きているDNSサーバー」へ切り替えることで通信を迂回させることが可能です。ただし本記事記載時点の仕様では、転送先のDNSのIPアドレスは1つしか選択できません。 セカンダリDNSを指定して自動冗長化できない点は今後のアップデートに期待したい残念なポイントです。

参考：Cisco公式：Redirect DNSの構成ガイド