DNSクエリとドメイン名解決の動作の確認
内容
はじめに
このドキュメントでは、クライアントのオペレーティングシステム(OS)がDNSクエリを処理する方法と、Cisco IOS® Secure Clientを使用したドメイン名解決への影響について説明します。
前提条件
要件
このドキュメントに関する固有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。ラボ例では、Windows、macOS、Linux、およびApple iOS上で、セキュアファイアウォールASA/FTDグループポリシーとCisco Secure Clientを使用します。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
スプリット DNS 対標準 DNS
このドキュメントでは、スプリットトンネリングまたはフルトンネリングでCisco Secure Client（以前のCisco AnyConnect）を使用する場合に、クライアントのオペレーティングシステム(OS)がDNSクエリを処理する方法と、ドメイン名解決に与える影響について説明します。説明するVPNヘッドエンドには、Cisco Secure Firewall ASAおよびFTD（以前のASA）が含まれます。特に断りのない限り、split-dns、dns-server、split-tunnel-all-dnsなどのグループポリシー設定が両方に適用されます。
セクションが明示的に古いクライアントリリースを参照している場合、Secure Client 4.2以降（現在のSecure Client 5.xリリースを含む）で説明されている動作が適用されます。Cisco AnyConnect 4.xのサポートは終了しています。Cisco Secure Clientに移行し、サポートされているDNSおよびトンネリング機能を使用してください。
DNS解決の動作は、次の3つの要因に依存します。
- VPN DNSポリシー：ヘッドエンドで設定（スプリットDNS、tunnel-all-DNS、または標準DNS）
- スプリットトンネリングモード：Tunnel-all、split-include、またはsplit-exclude
- クライアントオペレーティングシステム：DNSリゾルバアーキテクチャ（インターフェイスごと、グローバル）
split-include tunnelingコマンドを実行する場合、グループポリシーでは次の3つのDNSオプションを使用できます。
| モード |
説明 |
|---|---|
| スプリット DNS | ヘッドエンド(split-dns)で設定されたドメイン名と一致するDNSクエリは、トンネルを介してVPN DNSサーバ(dns-server)に送信されます。 他のすべてのクエリは、クライアントOSリゾルバと物理アダプタのDNSサーバを使用します。 |
| Tunnel-all-DNS（トンネルオールDNS） | ヘッドエンドによって定義されたDNSサーバへのDNSトラフィックのみが許可されます。グループポリシーでsplit-tunnel-all-dns enableが設定されている。 |
| 標準DNS | すべてのDNSクエリは、まずヘッドエンドによって定義されたVPN DNSサーバに送信されます。否定応答（NXDOMAINまたは応答なし）では、リゾルバは物理アダプタでDNSサーバを試行することもできます。 |
注:split-tunnel-all-dnsコマンドは、ASAバージョン8.2(5)で初めて実装されました。 それ以前のバージョンでは、スプリットDNSまたは標準DNSのみを使用できました。いずれの場合も、トンネルを通過するように定義されたDNSクエリは、ヘッドエンドによって定義された任意のDNSサーバに渡されます。ヘッドエンドにDNSサーバが定義されていない場合、トンネルのDNS設定は空白です。
スプリットDNSを定義しない場合、ヘッドエンドによって定義されたDNSサーバにすべてのDNSクエリが送信されます（このドキュメントで後述するOS固有の動作に従います）。 ただし、このドキュメントで説明されている動作は、オペレーティングシステム(OS)によって異なる場合があります。
DNSのテスト – 重要
注：クライアントで名前解決をテストする際は、NSLookupやdigは使用しないでください。代わりに、Webブラウザを使用するか、pingコマンドを実行します。NSLookupとdigは、ほとんどのアプリケーションと同じようにOS DNSリゾルバをスタブとして使用しません。セキュアクライアントは、特定のインターフェイスを介してすべてのDNS要求を強制するわけではありません。スプリットDNSおよびtunnel-all-DNSポリシーに基づいて要求を許可または拒否します。
正しいフェールオーバー動作を確認するには、ネイティブOSのDNSリゾルバ（ブラウザ、ping、およびほとんどのビジネスアプリケーション）に依存するアプリケーションでのみテストを行います。 独自のDNS解決（NSLookup、dig、および一部のカスタムアプリケーション）を実行するツールでは、クライアントが正しく動作していても、誤解を招く障害が表示される可能性があります。
真のスプリット DNS とベスト エフォートのスプリット DNS
AnyConnectリリース2.4では、スプリットDNSフォールバック（ベストエフォートスプリットDNS）が導入されました。これは真のスプリットDNSではなく、レガシーIPsecクライアントでも使用されていました。
ベストエフォート（フォールバック）動作：
- 要求がスプリットDNSドメインと一致する場合、セキュアクライアントは要求をヘッドエンドにトンネリングすることを許可します。
- VPN DNSサーバがホスト名を解決できない場合、OS DNSリゾルバは続行し、物理インターフェイス上のDNSサーバに同じクエリを送信できます。
- 要求がどのスプリットDNSドメインとも一致しない場合、セキュアクライアントは要求をトンネリングしません。応答を合成できるため、リゾルバは物理インターフェイスのDNSサーバにフォールバックします。
これが、レガシー機能がスプリットトンネリング用のDNSフォールバックと呼ばれる理由で、これは真のスプリットDNSではありません。セキュアクライアントは、一致するスプリットDNSドメインクエリだけがトンネルに入ることを保証しますが、最終的な解決は引き続きOSリゾルバの動作に依存します。
セキュリティ上の問題:VPN DNSサーバがNXDOMAINを返すか、解決に失敗した場合、プライベートドメイン名がパブリックDNSサーバにリークする可能性があり、リゾルバは物理アダプタで再試行します。
真のスプリットDNS:Cisco Bug ID CSCtn14578
Microsoft WindowsではAnyConnect 3.0(4235)で解決され、Secure Client 4.2以降でも維持されています。
- 構成されたスプリットDNSドメインに対するクエリは、VPNパス経由でのみ許可されます（プラットフォームとバージョンによっては、トンネルDNSサーバ/VPNアダプタを使用します）。
- その他のクエリはすべて、非VPN DNSサーバー（物理アダプター）経由でのみ許可されます。
注:Ciscoの内部バグツールと詳細なバグ情報にアクセスできるのは、登録ユーザだけです。
Tunnel-allおよびTunnel-all DNS
スプリットトンネリングがディセーブルの場合（tunnel-all設定）、DNSトラフィックはトンネルでのみ許可されます。
tunnel-all-DNS設定（グループポリシーのsplit-tunnel-all-dns enable）では、ある形式のスプリットトンネリングも設定されている間、すべてのDNSルックアップがトンネル経由で送信され、DNSトラフィックはトンネルインターフェイスでのみ許可されます。
これは、Microsoft Windowsで1つの注意事項があり、プラットフォーム間で一貫しています。tunnel-allまたはtunnel-all-DNSが設定されている場合、セキュアクライアントは、セキュアゲートウェイで設定されたDNSサーバへのDNSトラフィックのみ許可します（VPNアダプタに適用）。 このセキュリティ強化は、真のスプリットDNSによって実装されました。これが問題になる場合（たとえば、DNSの更新/登録が非VPN DNSサーバに到達する必要がある場合）、次の手順を実行します。
- 現在の設定がtunnel-allの場合、split-exclude tunnelingを有効にします。リンクローカルアドレスなど、すべての単一ホストのスプリット除外ネットワークを使用できます。
- tunnel-all-DNSがグループポリシーで有効になっていないことを確認します(split-tunnel-all-dns disable)。
Tunnel-all-DNSおよびCisco Secure Client Umbrellaモジュール
split tunnelingとtunnel-all-DNSの両方が有効な場合、DNSはカーネルレベルで代行受信され、正しいVPNインターフェイスから出力されない場合、ブロックされます。暗号化されたDNSが使用できないネットワークでは、セキュアクライアント包括モジュール（以前のAnyConnect Roaming Security）が影響を受ける可能性があります。これは、tunnel-all-DNSではVPN経由のDNSが必要であるのに対し、モジュールはLANインターフェイス経由で標準のDNSを試行できるためです。
デフォルトでは、Umbrellaモジュールは暗号化されたDNS（UDPポート443）を使用します。これは通常、tunnel-all-DNSによってブロックされることはありません。この問題は主に、暗号化が使用できず、単純なDNSが使用されている場合に発生します。
推奨事項：Umbrellaモジュールでtunnel-all-DNSを使用する場合は、Cisco Umbrellaリゾルバアドレスをsplit-includeリストに追加します。または、「Umbrellaモジュールを使用するセキュアクライアントに対するすべてのDNSのトンネルの有効化」ドキュメント（ドキュメントID:224809）を参照してください。
AnyConnectバージョン3.0(4235)で解決されたDNSパフォーマンスの問題
このMicrosoft Windowsの問題は、次の状況で最もよく見られます。
- DNSサーバとDHCPサーバが同じIPアドレスを共有するホームルータのセットアップ（セキュアクライアントはDHCPサーバへの必要なルートを作成します）。
- グループポリシー内の多数のDNSサフィックス/ドメイン。
- tunnel-all設定。
- 名前解決では修飾されていないホスト名が使用されるため、リゾルバは使用可能なすべてのDNSサーバで複数のDNSサフィックスを試みます。
- ネイティブDNSクライアントは、物理アダプタを介してDNSクエリの送信を試みます。このアダプタは、セキュアクライアントがtunnel-allでブロックします。
これは、特にヘッドエンドが多数のDNSサフィックスをプッシュする場合に、名前解決の大幅な遅延を引き起こす可能性があります。リゾルバは、肯定応答を受信するまで、サフィクスとサーバをウォークスルーする必要があります。
この問題は、AnyConnect 3.0(4235)以降のSecure Clientリリースで解決されています。詳細については、Cisco Bug ID CSCtq02141およびCisco Bug ID CSCtn14578を参照してください。
注:Cisco Bug Toolにアクセスできるのは、登録ユーザだけです。
回避策（アップグレードできない場合）
IPアドレスのsplit-exclude tunnelingを有効にして、ローカルDNSが物理アダプタを使用できるようにします。リンクローカルサブネット169.254.0.0/16からのアドレスは、通常、これらのアドレスへのトラフィックがVPNを通過する可能性が低いため、使用されます。
split-exclude tunnelingを有効にした後、クライアントプロファイルまたはクライアントでローカルLANアクセスを有効にし、tunnel-all-DNSを無効にします。ASA/FTDの設定例を次に示します。
access-list acl_linklocal_169.254.1.1 standard permit host 169.254.1.1
group-policy gp_access-14 attributes
split-tunnel-policy excludespecified
split-tunnel-network-list value acl_linklocal_169.254.1.1
split-tunnel-all-dns disable
exit
クライアントプロファイルXML:
true
これは、セキュアクライアントGUIのPreferences→Enable local (LAN) Access when using VPNでも有効にできます。
- 修飾されていないホスト名の代わりに完全修飾ドメイン名(FQDN)を使用します。
- 物理インターフェイス上のDNSサーバに別のIPアドレスを使用します（同じサブネット上のDHCPとは別）。
異なるクライアントオペレーティングシステムでのスプリットトンネリングを使用したDNS
Secure Clientに対するスプリットトンネリング（スプリットDNSを使用しない）では、クライアントオペレーティングシステムによってDNSの処理方法が異なります。このセクションでは、それらの違いについて説明します。
Microsoft Windows（Windows 10およびWindows 11）
Windowsでは、DNS設定はネットワークインターフェイスごとに行われます。スプリットトンネリングでは、DNSクエリがVPNトンネルアダプタで失敗した後、物理アダプタのDNSサーバにフォールバックできます。スプリットDNSを使用せずにスプリットトンネリングを使用した場合、リゾルバは外部DNSサーバにフォールバックできるため、内部と外部の両方の解決が機能します。Secure Client for Windowsのリリース4.2では、Cisco Bug ID CSCuf07885の修正後、大幅な変更が行われました。この動作は、Secure Client 5.xでは変更されていません。
注:Cisco Bug Toolにアクセスできるのは、登録ユーザだけです。
Tunnel-allの設定（およびtunnel-all-DNSが有効な場合のスプリットトンネリング）
Pre-Secure Client 4.2（AnyConnect 4.1以前）:
- グループポリシーで構成されたDNSサーバー（トンネルDNSサーバー）に対するDNS要求のみが許可されます。
- Secure Clientドライバは、名前が指定されていないその他すべての要求に応答します。
- DNS解決はトンネルDNSサーバーのみを使用できます。
Secure Client 4.2以降：
- DNSサーバへのDNS要求は、VPNアダプタから発信され、トンネル経由で送信される場合に許可されます。
- その他の要求はすべて、VPNトンネルを介してのみ名前を受け取り、名前解決を行います。
- Cisco Bug ID CSCuf07885以前は、セキュアクライアントでターゲットDNSサーバが制限されていました。この修正の後、DNS要求を開始できるネットワークアダプタが制限されます。
Split-includeの設定（Tunnel-all-DNSが無効、Split-DNSなし）
セキュアクライアントドライバは、ネイティブDNSリゾルバに干渉しません。解決策はネットワークアダプタの順序に従います。VPNが接続される際は、セキュアクライアントが優先アダプタとなります。
DNSクエリは最初にトンネル経由で送信されます。解決されない場合、リゾルバはパブリックインターフェイスを試行できます。split-includeアクセスリストには、4.2より前のリリースでトンネルDNSサーバをカバーするサブネットを含める必要があります。Secure Client 4.2以降、トンネルDNSサーバのホストルートはsplit-includeネットワーク（セキュアルート）として自動的に追加されます。そのため、split-include ACLでは、明示的なトンネルDNSサーバサブネットを必要としません。
スプリット除外の設定（Tunnel-all-DNSが無効、スプリットDNSなし）
split-includeと同じリゾルバ動作が、最初にトンネルを実行し、次にパブリックインターフェイスのフォールバックを実行します。split-excludeアクセスリストには、トンネルDNSサーバをカバーするサブネットを含めることはできません。 Secure Client 4.2以降、トンネルDNSサーバの自動ホストルートにより、一般的なsplit-excludeの誤設定が防止されます。
Split-DNS（Tunnel-all-DNSは無効、Split-includeは設定済み）
WindowsのSplit-DNSにはsplit-includeトンネリングが必要です(split-tunnel-policy tunnelspecified)。 split-exclude-onlyトンネルポリシーは、split-DNS設定ではサポートされません。
Pre-Secure Client 4.2:
- スプリットDNSドメインクエリ： DNSサーバーのトンネル化のみを許可します。他のサーバーに送信する場合、そのような名前は許可されません。
- 非スプリットDNSドメインクエリ：他のDNSサーバにのみ許可されます。トンネル経由で試行された場合、そのような名前はありません。
Secure Client 4.2以降（Windowsの真のスプリットDNS）:
- スプリットDNSドメインクエリ：DNSサーバがVPNアダプタから発信されている場合にのみ、すべてのDNSサーバに許可されます。パブリックインターフェイスからのクエリは、トンネルの使用を強制する名前を受け取りません。
- 非スプリットDNSドメインクエリ：物理アダプタから発信された場合にのみ、すべてのDNSサーバに許可されます。VPNアダプタからのクエリは、パブリックインターフェイスの解決を強制する名前を受け取りません。
スプリット除外トンネリングを使用したスプリットDNS(Secure Client 5.x)
Secure Client 5.xの管理者用ドキュメントでは、split-exclude設定用のスプリットDNSが追加されています。ヘッドエンドとポリシーの要件については、『Secure Client 5.x管理者ガイド：スプリット除外トンネリングのためのスプリットDNSの設定』を参照してください。スプリットDNSがアクティブになっても、OSレベルの適用ルールは適用されます。
Windowsでの暗号化されたDNS(DoH/DoT)
DNS over HTTPS(DoH)またはDNS over TLS(DoT)を使用するアプリケーションまたはOS機能は、Secure ClientがフィルタするWindowsスタブリゾルバパスをバイパスできます。特定のアプリケーションでスプリットDNSが失敗したように見えても、ブラウザで動作する場合は、それらのアプリケーションが暗号化DNSまたはカスタムDNSを使用するかどうかを確認します。標準的なスプリットDNSテストでは、NSLookup/digではなく、OSリゾルバ（ブラウザ、ping）を使用する必要があります。
MacOS
macOSでは、DNS設定はグローバルです（インターフェイスごとではありません）。 スプリットDNSを使用せずにスプリットトンネリングを使用すると、DNSクエリがトンネル外部のDNSサーバに期待どおりに到達できないことがよくあります。パブリックパスを使用して内部名だけを解決でき、外部名は解決できません。この問題は、Cisco Bug ID CSCtf20226およびCisco Bug ID CSCtz86314に記載されています。
回避策：
- グループポリシーで外部DNSサーバのIPを指定し、内部クエリにFQDNを使用します。
- トンネルを介して外部名を解決できる場合は、グループポリシーからDNS名を削除してAdvanced > Split TunnelingでスプリットDNSを無効にし、内部クエリにFQDNを使用します。
macOSのスプリットDNSは、AnyConnect 3.1以降でサポートされています。次の条件に従う必要があります。
- 両方のIPプロトコルに対してスプリットDNSを有効にする（ASA 9.0+/同等のFTDが必要）。
- 一方のIPプロトコルに対してスプリットDNSが有効になっていて、他方のIPプロトコルに対してクライアントバイパスプロトコルが有効になっていて、バイパスされたプロトコルに対するアドレスプールがない（または、9.0より前のバージョンのASAではIPv6プールがない）場合。
注:Secure Clientは主にmacOSの/etc/resolv.confで名前解決を管理するのではなく、OSレベルのDNS設定を行います。macOSでは、互換性を確保するためにresolv.confを更新した状態で維持できます。scutil —dnsを実行し、有効なDNS設定を表示します。
Tunnel-allの設定（およびtunnel-all-DNSが有効な場合のスプリットトンネリング）
セキュアクライアントが接続されると、トンネルDNSサーバのみがシステムDNS設定に残り、要求はトンネルDNSサーバにのみ送信されます。
Split-include/Split-exclude（Tunnel-all-DNSが無効、Split-DNSなし）
セキュアクライアントはネイティブリゾルバに干渉しません。トンネルのDNSサーバはパブリックリゾルバよりも優先されるため、最初のクエリーの試行はトンネルを経由します。DNSはmacOSではグローバルであるため、トンネル外部のパブリックDNSはクエリで必ずしも確実に使用されるとは限りません(Cisco Bug ID:CSCtf20226)。
セキュアクライアント4.2以降では、トンネルDNSサーバのホストルートがセキュアルートとして自動的に追加されます。
Split-DNS（Tunnel-all-DNSは無効、Split-includeは設定済み）
真のスプリットDNS（Windowsと同様）は、次の場合に適用されます。
- スプリットDNSがIPv4とIPv6の両方で有効になっている。または、
- スプリットDNSが1つのプロトコルに対して有効であり、他のプロトコルに対してクライアントアドレスプールが存在しない。
真のスプリットDNSは、一致するスプリットDNSドメインがトンネル経由でのみ解決され、外部リゾルバにリークされないことを意味します。
split-DNSが1つのプロトコルだけに対して有効で、クライアントアドレスが他のプロトコルに割り当てられている場合、スプリットトンネリングのDNSフォールバックだけが適用されます。Secure Clientでは、トンネル経由で一致するクエリを許可しますが（他のクエリを拒否してフェールオーバーを強制できます）、パブリックアダプタ経由でクリアテキストで送信されるsplit-DNSドメインクエリのリークを完全に防止することはできません。
プラットフォームサポート（セキュアクライアント管理ガイド）：フルスプリットDNSは、WindowsおよびmacOSでサポートされています。Linuxのサポートには制限があります（Linuxの節を参照）。
Linux
Tunnel-allの設定（およびtunnel-all-DNSが有効な場合のスプリットトンネリング）
セキュアクライアントが接続されると、トンネルDNSサーバのみがシステムDNS設定で維持されます。
Split-include/Split-exclude（Tunnel-all-DNSが無効、Split-DNSなし）
セキュアクライアントはネイティブリゾルバに干渉しません。トンネルDNSサーバが優先されます。最初の解決はトンネル経由で行われます。
Split-DNS（Tunnel-all-DNSは無効、Split-includeは設定済み）
split-DNSが有効な場合、スプリットトンネリング用のDNSフォールバックだけがLinuxで適用されます。
- セキュアクライアントでは、トンネル経由でスプリットDNSドメインクエリを実行できます。
- その他のクエリは、パブリックDNSへのフェールオーバーを促す拒否を受け取る可能性があります。
- Secure Clientでは、スプリットDNSドメインクエリはパブリックアダプタを介してクリアテキストで送信されないため、完全に適用することはできません。
『Secure Client管理ガイド』では、LinuxでのスプリットDNSの制限について説明しています。トンネル化されたDNS要求だけが、スプリットDNSポリシーの完全な対象となります。トンネル外部の一部のクエリは、スプリットDNSポリシーに準拠しません。
Linux VMおよびコンテナ
セキュアクライアントはtunnel-from-any-sourceカスタム属性をサポートしているため、任意の送信元アドレスを持つパケットを、VMインスタンスまたはDockerコンテナ内のsplit-includeまたはsplit-excludeモードでルーティングできます。設定の詳細については、『Secure Client 5.x管理者ガイド』を参照してください。
Apple iOS（iPhoneおよびiPad）
iOSの動作はmacOSとは異なり、Windowsと同じではありません。スプリットDNSを使用せずにスプリットトンネリングを設定した場合、DNSクエリは通常、デバイスに対して定義されたグローバルDNSサーバを使用します。これは、Windowsと同じフォールバックパターンではありません。
実際の影響：スプリットDNSを使用せずにスプリットトンネリングを使用する場合、信頼性の高い内部名前解決を行うために、スプリットDNSドメインエントリが必要になることがよくあります。
履歴修正：Cisco Bug ID CSCtq09624（AnyConnect for iOS 2.5.4038以降） 現在のSecure Client for iOSも同じ一般的な要件に従います。split-include/splitを使用する場合は、内部ドメインにスプリットDNSを設定し、Windowsスタイルのフォールバックに依存せずに除外します。
注:iOSのDNSクエリは、.local domainsを無視します(Cisco Bug ID CSCts89292)。
Appleはこれを設計された動作として扱います。iOS上の標準スプリットDNSを介した.local解決は予期されていません。iOSでは、スプリットトンネリングが特定のsplit-DNSリスト設定と組み合わされた場合のSecure Client split-DNSの動作も、他のプラットフォームとは異なります。iOS固有のポリシーの組み合わせ（split-dns none、default-domainなど）については、『Secure Client Administrator Guide』の「Split DNS Resolution Behavior with Split Tunnel」を参照してください。
ダイナミックスプリットトンネリングとDNS(Secure Client 4.5+)
ダイナミックスプリットトンネリングは、接続時またはオンデマンドでFQDNを解決し、指定されたドメインへのトラフィックのルーティングとフィルタを調整します。これは、スタティックIPリストを使用しないトンネルに含まれるか、トンネルから除外されます。
| 機能 | 説明 |
|---|---|
| 動的分割の除外 | ドメイン(example.com)は、アプリケーションがこれらの名前を解決するときに、実行時にトンネルから除外されます。 |
| 動的分割の内容 | ドメインはトンネルに動的に含まれます。 |
| 拡張ダイナミックスプリット | 優先度規則を含む組み合わせ包含/除外ドメインリスト（example.comを除外するがmail.example.comを含む）。 |
ダイナミックスプリットトンネリングでは、DNS解決を使用してルーティングの変更が行われます。ヘッドエンドのセキュアクライアントのカスタム属性（dynamic-split-exclude-domains、dynamic-split-include-domainsなど）を使用して設定される
ダイナミックスプリットトンネリングは、tunnel-all（ダイナミック除外）とsplit-exclude（ダイナミック除外）またはsplit-include（ダイナミックインクルード）ポリシーに適用されます。これはスプリットDNSポリシーに代わるものではありませんが、これを補完します。スプリットDNSはトンネリングされるクエリを制御し、ダイナミックスプリットトンネリングは解決済みの名前に基づいてトンネリングされるIPトラフィックを制御します。設定の詳細については、「ダイナミックスプリットトンネリングの設定」および『Secure Client 5.x管理者ガイド』を参照してください。
スプリット除外フェールオーバー(Secure Client 5.x)：オプションのカスタム属性SplitExcludeFailoverEnabledは、パブリックパスにスプリット除外ターゲットへの接続がない場合、トラフィックをVPN経由でルーティングします。カスタム属性の設定については、『管理者ガイド』を参照してください。
クライアントの履歴バージョン（参照）
次の表は、古いクライアントを実行しているレガシー展開にのみ適用されます。
| バージョン | 関連性 |
|---|---|
| AnyConnect 2.4 | ベストエフォート型スプリットDNSフォールバックを導入 |
| AnyConnect 2.5(iOS) | Cisco Bug ID:CSCtq09624 iOS DNSアライメント |
| AnyConnect 3.0(4235) | Windowsでの真のスプリットDNS、DNSパフォーマンス修正 |
| AnyConnect 3.1(macOS) | IPv4/IPv6条件でのスプリットDNSサポート |
| AnyConnect 4.2 | Cisco Bug ID:CSCuf07885アダプタベースの適用、自動トンネルDNSホストルート |
現在の修正と機能をサポートしているすべてのプラットフォームにセキュアクライアント5.xを導入します。
関連するバグ情報
注:Cisco Bug Toolにアクセスできるのは、登録ユーザだけです。
- Cisco Bug ID:CSCtn14578 – 真のスプリットDNS（フォールバックなし） - Windows、3.0(4235)+
- Cisco Bug ID:CSCtq02141 - ISPのDNSがパブリックIPと同じサブネット上にある場合のDNS遅延
- Cisco Bug ID: CSCuf07885 - Windows DNS：ターゲットサーバではなくアダプタによる制限 – 4.2+
- Cisco Bug ID:CSCtf20226 - Windowsと異なるmacOSスプリットトンネルDNS
- Cisco Bug ID:CSCtz86314 - macOSスプリットDNSクエリがトンネル経由で送信されない
- Cisco Bug ID:CSCtq09624 - iOSスプリットトンネルDNSの動作
- Cisco Bug ID:CSCts89292 - iOSが.local DNSドメインを無視する
- Cisco Bug ID:CSCsv34395 - DHCPサーバへのFQDNプロキシのサポート
関連情報
- Examine the Behavior of DNS Queries and Domain Name Resolution(Cisco.com)：ドキュメントID 116016
- Cisco Secure Client 5.x管理者ガイド：VPNアクセス/スプリットDNSの設定
- ASA/AnyConnectダイナミックスプリットトンネリングの設定：ドキュメントID 215383
- Umbrellaモジュールを使用したセキュアクライアントでのTunnel All DNSの有効化：ドキュメントID 224809
- AnyConnectとOpenDNS Roaming Client間の相互運用：ドキュメントID 200395
- シスコのテクニカルサポートとダウンロード
改訂履歴
| 改訂 | 日付 | 注釈 |
|---|---|---|
| 4.0 | 2026年7月28日 | 完全な実質的更新：セキュアクライアントのブランディング、プラットフォームの更新、ダイナミックスプリットトンネリング、Umbrella/tunnel-all-DNS、誤字および設定の修正、関連リンクの修正 |
| 3.0 | 2024年5月23日 | 再認定(Cisco.com) |
| 1.0 | 2014年6月12日 | 初版リリース |
ドキュメントの適用先
- Cisco Secure Client（AnyConnectを含む）:Windows、macOS、Linux、iOS
- Cisco Secure Firewall ASAおよびFTDリモートアクセスVPNグループポリシー
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
4.0 |
10-Aug-2026
|
概要、スペル、文法、URLの修正、読みやすさを考慮したセクションへの水平線の挿入、CCWのエラーの修正を更新。 |
3.0 |
23-May-2024
|
再認定 |
1.0 |
12-Jun-2014
|
初版 |
フィードバック