Cisco Jabber DNS 設定ガイド
初版：2013 年 12 月 18 日
シスコシステムズ合同会社
〒107-6227 東京都港区赤坂9-7-1 ミッドタウン・タワー
http://www.cisco.com/jp
お問い合わせ先：シスコ コンタクトセンター
0120-092-255 （フリーコール、携帯・PHS含む）
電話受付時間：平日 10:00～12:00、13:00～17:00
http://www.cisco.com/jp/go/contactcenter/
【注意】シスコ製品をご使用になる前に、安全上の注意（ www.cisco.com/jp/go/safety_warning/ ）
をご確認ください。本書は、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきま
しては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更され
ている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容
については米国サイトのドキュメントを参照ください。また、契約等の記述については、弊社販
売パートナー、または、弊社担当者にご確認ください。
このマニュアルに記載されている仕様および製品に関する情報は、予告なしに変更されることがあります。 このマニュアルに記載されている表現、情報、および推奨
事項は、すべて正確であると考えていますが、明示的であれ黙示的であれ、一切の保証の責任を負わないものとします。 このマニュアルに記載されている製品の使用
は、すべてユーザ側の責任になります。
対象製品のソフトウェア ライセンスおよび限定保証は、製品に添付された『Information Packet』に記載されています。 添付されていない場合には、代理店にご連絡く
ださい。
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version
of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
ここに記載されている他のいかなる保証にもよらず、各社のすべてのマニュアルおよびソフトウェアは、障害も含めて「現状のまま」として提供されます。 シスコお
よびこれら各社は、商品性の保証、特定目的への準拠の保証、および権利を侵害しないことに関する保証、あるいは取引過程、使用、取引慣行によって発生する保証
をはじめとする、明示されたまたは黙示された一切の保証の責任を負わないものとします。
いかなる場合においても、シスコおよびその供給者は、このマニュアルの使用または使用できないことによって発生する利益の損失やデータの損傷をはじめとする、
間接的、派生的、偶発的、あるいは特殊な損害について、あらゆる可能性がシスコまたはその供給者に知らされていても、それらに対する責任を一切負わないものと
します。
このマニュアルで使用している IP アドレスおよび電話番号は、実際のアドレスおよび電話番号を示すものではありません。 マニュアル内の例、コマンド出力、ネット
ワーク トポロジ図、およびその他の図は、説明のみを目的として使用されています。 説明の中に実際のアドレスおよび電話番号が使用されていたとしても、それは意
図的なものではなく、偶然の一致によるものです。
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http://
www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1110R)
© 2014
Cisco Systems, Inc. All rights reserved.
目次
クライアントによるドメイン ネーム サーバの使用方法 1
クライアントがネーム サーバを検索する方法 1
クライアントがサービス ドメインを取得する方法 2
クライアントによる利用可能なサービスの検出方法 2
クライアントによる HTTP クエリーの発行 3
クライアントからのネーム サーバのクエリー 4
クライアントの内部サービスへの接続 5
クライアントの Cisco Unified Communications Remote and Mobile Collaboration を介し
た接続 8
ドメイン ネーム システムの設計 11
独立ドメイン設計 11
同一ドメイン設計 12
同一ドメイン（スプリット ブレイン） 12
同一ドメイン（非スプリット ブレイン） 13
サービス（SRV）レコード 15
SRV レコードの導入 15
独立ドメイン構造での SRV レコード導入 15
サービス ドメインへの内部ゾーンの使用 16
ピンポイント サブドメイン ゾーンの使用 16
SRV レコード 17
外部レコード 18
内部レコード 18
Cisco Jabber DNS 設定ガイド
iii
目次
Cisco Jabber DNS 設定ガイド
iv
第
1
章
クライアントによるドメイン ネームサーバ
の使用方法
Cisco Jabber は、ドメイン ネーム サーバを使用して次の内容を実行します。
• 社内ネットワーク内のオンプレミス サーバを自動的に検出する。
• パブリック インターネットでの Cisco Unified Communications Remote and Mobile Collaboration
のアクセス ポイントを特定する。
• クライアントが社内ネットワークの内部か外部かを判定する。
• クライアントがネーム サーバを検索する方法, 1 ページ
• クライアントがサービス ドメインを取得する方法, 2 ページ
• クライアントによる利用可能なサービスの検出方法, 2 ページ
クライアントがネーム サーバを検索する方法
Cisco Jabber は次の場所から DNS レコードを検索します。
• 社内ネットワーク内の内部ネーム サーバ。
• パブリック インターネット上の外部ネーム サーバ。
クライアントのホストコンピュータまたはデバイスがネットワーク接続を取得すると、ホストコ
ンピュータまたはデバイスは DHCP 設定から DNS ネーム サーバのアドレスも取得します。 ネッ
トワーク接続によりますが、そのネーム サーバが社内ネットワークの内部の場合と外部の場合が
あります。
Cisco Jabber は、ホスト コンピュータまたはデバイスが DHCP 設定から取得するネーム サーバを
クエリーします。 Cisco Jabber を直接設定して特定のネーム サーバを使用させることはできませ
ん。
Cisco Jabber DNS 設定ガイド
1
クライアントによるドメイン ネーム サーバの使用方法
クライアントがサービス ドメインを取得する方法
クライアントがサービス ドメインを取得する方法
ユーザがリリース 9.2 から 9.6 にアップグレードする場合、またはブートストラップ ファイルで
アップグレードする場合、サービスドメインはキャッシュされた設定で決定されます。この情報
が見つからない場合、サービスドメインを判定するため、ユーザは電子メールアドレスを入力す
るように促されます。
（注）
このクライアントの電子メール アドレス プロンプトを回避する場合、管理者が次のガイドラ
インに沿って SERVICES_DOMAIN インストーラ スイッチを設定する必要があります。
• サービス ディスカバリ導入済み
SERVICES_DOMAIN スイッチを DNS SRV レコードが存在するドメインにセットする必要
があります。
• サービス ディスカバリ導入なし
SERVICES_DOMAIN スイッチを DNS SRV レコードが存在しない組織ドメインにセットす
る必要があります。
次に、新規インストール後にクライアントがインストールスイッチなしでサービスドメインを取
得する例を示します。
1 Adam McKenzie が Cisco Jabber を初めて起動します。
2 Cisco Jabber は、Adam に彼の電子メール アドレスの入力を促します。
3 Adam が [email protected] と入力します。
4 クライアントが電子メール アドレスから example.com を抽出します。
Cisco Jabber はサービス ドメインを取得した後、クライアント コンピュータまたはデバイスに設
定されたネーム サーバをクエリーします。
クライアントによる利用可能なサービスの検出方法
次の図は、クライアントが SRV レコードを使用してサービスに接続するのに使用するフローを示
しています。
Cisco Jabber DNS 設定ガイド
2
クライアントによるドメイン ネーム サーバの使用方法
クライアントによる HTTP クエリーの発行
使用可能なサービスを検出するため、クライアントは次のことを実行します。
1 Cisco WebEx Messenger サービスのため CAS URL に HTTP クエリーを発行します。
このクエリーによって、クライアントはドメインが有効な Cisco WebEx ドメインかどうかを判
定できます。
2 ネーム サーバをクエリーして DNS サービス（SRV）レコードを取得します。
このクエリーによって、クライアントで次のことが可能になります。
• どのサービスが利用可能なのかを判定する。
• 社内ネットワークに Cisco Unified Communications Remote and Mobile Collaboration 経由で
接続する。
クライアントによる HTTP クエリーの発行
SRV レコードのネーム サーバをクエリーして利用可能なサービスを特定することに加え、Cisco
Jabber は HTTP クエリーを Cisco WebEx Messenger サービスの CAS URL に送信します。 この要求
Cisco Jabber DNS 設定ガイド
3
クライアントによるドメイン ネーム サーバの使用方法
クライアントからのネーム サーバのクエリー
によって、クライアントは、クラウド ベースの導入が可能になり、Cisco WebEx Messenger サービ
スへのユーザ認証が可能になります。
クライアントはユーザからサービス ドメインを取得すると、次の HTTP クエリーへのドメインに
追加します。
http://loginp.webexconnect.com/cas/FederatedSSO?org=
たとえば、クライアントは example.com をそのユーザからのサービス ドメインとして取得した
場合に、次のクエリーを発行します。
http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com
クエリーは、サービス ドメインが有効な Cisco WebEx ドメインであるかどうかを判定するために
クライアントが使用する XML 応答を返します。
クライアントがサービス ドメインを有効な Cisco WebEx ドメインとして判定した場合、ユーザに
Cisco WebEx のクレデンシャルの入力を促します。 クライアントは Cisco WebEx Messenger サービ
スに対して認証します。
サービス ドメインが有効な Cisco WebEx ドメインでないと判定した場合、利用可能なサービスの
特定にネーム サーバへのクエリー結果を使用します。
（注）
クライアントは、HTTP 要求を CAS URL に送るときに、設定されたシステム プロキシを使用
します。 この要求のプロキシのサポートには、次の制約事項があります。
• プロキシ認証はサポートされていません。
• バイパス リストのワイルドカードはサポートされません。 たとえば、*.example.com
ではなく、example.com を使用します。
クライアントからのネーム サーバのクエリー
クライアントがネーム サーバをクエリーする場合、ネーム サーバにそれぞれ独立した SRV レコー
ドの要求を同時に送信します。
クライアントは、次の SRV レコードを要求します。
• _cisco-uds
• _cuplogin
• _collab-edge
ネーム サーバが次を返した場合：
Cisco Jabber DNS 設定ガイド
4
クライアントによるドメイン ネーム サーバの使用方法
クライアントの内部サービスへの接続
_cisco-udsまたは_cuplogin
クライアントは企業ネットワーク内であることを検知し、次のいずれかに接続します。
Cisco Unified Communications Manager
ネーム サーバが _cisco-uds を返した場合。
Cisco Unified Presence
ネーム サーバが _cuplogin を返した場合。
_collab-edge
クライアントは Cisco Unified Communications Remote and Mobile Collaboration を介して内部
ネットワークへに接続してサービスを検出するよう試行します。
SRV レコードが存在しない
クライアントは、手動で詳細情報のセットアップに入り、サインインするようユーザを促し
ます。
クライアントの内部サービスへの接続
次の図に、クライアントの内部サービスへの接続方法を示します。
Cisco Jabber DNS 設定ガイド
5
クライアントによるドメイン ネーム サーバの使用方法
クライアントの内部サービスへの接続
内部サービスに接続する際の目標は、オーセンティケータを決定し、ユーザをサインインし、利
用可能なサービスに接続することです。
ユーザにサインイン画面を通過させることが可能なオーセンティケータとして、次の 3 つが考え
られます。
Cisco WebEx Messenger Service
クラウドベースまたはハイブリッド クラウド ベースの導入。
Cisco Unified Presence
デフォルト製品モードのオンプレミス導入。 デフォルト製品モードはフル UC または IM の
みのいずれかです。
Cisco Unified Communications Manager
電話モードのオンプレミス導入。
クライアントが接続するサービスは、クライアントが検出したサービスに依存します。 クライア
ントが次の条件を満たしている場合：
CAS URL ルックアップが Cisco WebEx ユーザを示すことをクライアントが検出した場合
クライアントは、次のことを実行します。
Cisco Jabber DNS 設定ガイド
6
クライアントによるドメイン ネーム サーバの使用方法
クライアントの内部サービスへの接続
1 Cisco WebEx Messenger サービスを認証のプライマリ ソースと判定する。
2 自動的に Cisco WebEx Messenger サービスに接続する。
3 ユーザにクレデンシャルの入力を促す。
4 クライアント設定とサービス設定を取得する。
_cisco-uds
クライアントは、次のことを実行します。
1 Cisco Unified Communications Manager での認証のためユーザにクレデンシャルの入力を促す。
2 ユーザのホーム クラスタを特定する。
ホーム クラスタの特定によって、クライアントは自動的にユーザのデバイス リストを取得し、
Cisco Unified Communications Manager に登録することができます。
重要
複数の Cisco Unified Communications Manager クラスタがある環境では、クラスタ間検索サービ
ス（ILS）が必要です。 ILS を使用することで、クライアントはユーザのホーム クラスタの検
出が可能になります。
ILS の設定方法については、『Cisco Unified Communications Manager Features and Services Guide』
を参照してください。
3 サービス プロファイルを取得する。
サービス プロファイルは、クライアントに対しオーセンティケータと、クライアントおよび
UC サービスの設定を準備します。
クライアントは、[プレゼンス プロファイル（IM and Presence Profile）] の [製品タイプ（Product
type）] フィールドの値から、オーセンティケータを次のように決定します。
Unified CM (IM and Presence)
Cisco Unified Presence または Cisco Unified Communications Manager IM and Presence がオー
センティケータです。
Cisco Jabber DNS 設定ガイド
7
クライアントによるドメイン ネーム サーバの使用方法
クライアントの Cisco Unified Communications Remote and Mobile Collaboration を介した接続
WebEx (IM and Presence)
Cisco WebEx Messenger サービスがオーセンティケータです。
（注）
このリリースの時点では、クライアントは SRV レコードのクエリー
に加えて HTTP クエリーを発行します。 HTTP クエリーによって、ク
ライアントは Cisco WebEx Messenger サービスに対して認証するかど
うかを決定できます。
HTTP クエリーの結果として、クライアントはクラウドベースの導入
の Cisco WebEx Messenger サービスに、_cisco-uds SRV レコードの
取得前に接続します。 WebEx サービスが CAS ルックアップですでに
検出されていた場合、[製品タイプ（Product type）] フィールドを
[WebEx] にセットしても、実際には意味をなさない場合があります。
未設定（Not set）
サービス プロファイルに IM and Presence サービス設定が含まれない場合、オーセンティ
ケータは Cisco Unified Communications Manager です。
4 オーセンティケータにサイン インします。
クライアントにサインインした後、製品モードを判定できます。
_cuplogin
クライアントは、次のことを実行します。
1 Cisco Unified Presence が認証のプライマリ ソースであると決定する。
2 自動的にサーバに接続する。
3 ユーザにクレデンシャルの入力を促す。
4 クライアント設定とサービス設定を取得する。
クライアントの Cisco Unified Communications Remote and Mobile
Collaboration を介した接続
ネーム サーバが _collab-edge SRV レコードを返す場合、次のときにクライアントは Cisco
Unified Communications Remote and Mobile Collaboration を介して内部サーバに接続してサービスを
検出します。
ネーム サーバが _cisco-uds または _cuplogin を返さない。
ネーム サーバが _collab-edge SRV レコードを返す場合、クライアントは Cisco VCS Expressway、
または Cisco Expressway-E、サーバの場所を取得します。 その後、Cisco VCS Expressway、または
Cisco Jabber DNS 設定ガイド
8
クライアントによるドメイン ネーム サーバの使用方法
クライアントの Cisco Unified Communications Remote and Mobile Collaboration を介した接続
Cisco Expressway-E、サーバはクライアントに内部ネーム サーバへのクエリーの結果を提供しま
す。
（注）
Cisco VCS Control、または Cisco Expressway-C、サーバは内部 SRV レコードをルックアップ
し、レコードを Cisco VCS Expressway、または Cisco Expressway-E、サーバに提供します。
クライアントは、内部 SRV レコードを取得した後（必ず _cisco-uds が含まれている）、Cisco
Unified Communications Manager からサービス プロファイルを取得します。 その後、サービス プ
ロファイルはユーザのホームクラスタ、認証のプライマリソース、および設定をクライアントに
提供します。
メモ
_xmpp-client SRV レコードは、_collab-edge SRV レコードとともに、外部ネーム サー
バ上に存在することが可能です。
ネーム サーバが _xmpp-client SRV レコードを返す場合、クライアントは Cisco WebEx、ま
たはクラウド ベース、導入を検出します。 その結果、クライアントはユーザに Cisco WebEx
Messenger サービスへの認証を促します。
クライアントは、Cisco Unified Communications Remote and Mobile Collaboration 導入を検出する
と、内部サービスへの Cisco WebEx を介した接続を試行しません。
Cisco Jabber DNS 設定ガイド
9
クライアントによるドメイン ネーム サーバの使用方法
クライアントの Cisco Unified Communications Remote and Mobile Collaboration を介した接続
Cisco Jabber DNS 設定ガイド
10
第
2
章
ドメイン ネーム システムの設計
DNS サービス（SRV）レコードの導入場所は、DNS ネームスペースの設計に依存します。 通常、
2 種類の DNS 設計があります。
• 社内ネットワークの内外で独立したドメイン名。
• 社内ネットワークの内外で同一のドメイン名。
• 独立ドメイン設計, 11 ページ
• 同一ドメイン設計, 12 ページ
独立ドメイン設計
次の図は、独立ドメイン設計を示しています。
独立ドメインの一例として、組織が example.com を外部ドメインとしてインターネット名前登
録機関に登録したとします。
会社はまた、次のいずれかの内部ドメインも使用します。
• 外部ドメインのサブドメイン。example.local など。
• 外部ドメインと異なるドメイン。example.com など。
Cisco Jabber DNS 設定ガイド
11
ドメイン ネーム システムの設計
同一ドメイン設計
独立ドメイン設計の場合：
• 内部ネーム サーバには、内部ドメインのリソース レコードを含むゾーンがあります。 内部
ネーム サーバには、内部ドメインに対する権限があります。
• 内部ネーム サーバは、DNS クライアントが外部ドメインをクエリーすると、要求を外部ネー
ム サーバへ転送します。
• 外部ネーム サーバには、組織の外部ドメインのリソース レコードを含むゾーンがあります。
外部ネーム サーバには、そのドメインに対する権限があります。
• 外部ネーム サーバは、要求を他の外部ネーム サーバに転送できます。 ただし、外部のネー
ム サーバは内部ネーム サーバに要求を転送できません。
同一ドメイン設計
個別ドメイン設計の一例として、組織が example.com を外部ドメインとしてインターネット名
前登録機関に登録する場合があります。 組織は example.com を内部ドメイン名としても使用し
ます。
同一ドメイン（スプリット ブレイン）
次の図は、同一ドメイン（スプリット ブレイン）設計を示しています。
2 つの DNS ゾーンが同一のドメインを表します。内部ネーム サーバ内の DNS ゾーンと外部ネー
ム サーバ内の DNS ゾーンです。
内部ネーム サーバと外部ネーム サーバは、両方ともに単一のドメインに対する権限があります
が、異なるホストのコミュニティを扱います。
• 社内ネットワーク内のホストは、内部ホスト ネーム サーバだけにアクセスします。
• パブリック インターネットのホストは、外部ネーム サーバだけにアクセスします。
• 社内ネットワークとパブリック インターネットを行き来するホストは、時によって異なる
ネーム サーバにアクセスします。
Cisco Jabber DNS 設定ガイド
12
ドメイン ネーム システムの設計
同一ドメイン（非スプリット ブレイン）
同一ドメイン（非スプリット ブレイン）
次の図は、同一ドメイン（非スプリット ブレイン）設計を示しています。
同一ドメイン（非スプリット ブレイン）設計では、内部および外部ホストは 1 セットのネーム
サーバとして扱われ、同じ DNS 情報にアクセスできます。
重要
この設計は、内部ネットワークに関する多くの情報を公開し攻撃にさらすことになるため、一
般的ではありません。
Cisco Jabber DNS 設定ガイド
13
ドメイン ネーム システムの設計
同一ドメイン（非スプリット ブレイン）
Cisco Jabber DNS 設定ガイド
14
第
3
章
サービス（SRV）レコード
企業 DNS 構造のさまざまな場所に複数の DNS SRV レコードを導入します。 どのネーム サーバ
でどのレコードをプロビジョニングする必要があるかを把握します。 正しく導入するため、SRV
レコードの例を確認します。
• SRV レコードの導入, 15 ページ
• SRV レコード, 17 ページ
SRV レコードの導入
クライアントは、サービス ドメインでレコードのネーム サーバをクエリーします。 サービス ド
メインは、クライアントによる利用可能なサービスの検出方法, （2 ページ）で説明されている
方法で判定されます。
異なるサービスドメインを使用するユーザのサブセットが組織に複数存在する場合、サービスド
メインの各 DNS ゾーンに SRV レコードを導入する必要があります。
独立ドメイン構造での SRV レコード導入
独立ネーム設計では、内部ドメインと外部ドメインの 2 つのドメインがあります。 クライアント
は、サービス ドメインで SRV レコードをクエリーします。 内部ネーム サーバがサービス ドメイ
ンのレコードを扱う必要があります。しかし、独立ネーム設計では、サービスドメイン用のゾー
ンが内部ネーム サーバにない可能性があります。
サービス ドメインが内部ドメイン ネーム サーバで現在扱われていない場合、次のように処理で
きます。
• サービス ドメイン用の内部ゾーンにレコードを導入する。
• 内部ネーム サーバ上のピンポイント サブドメイン ゾーンにレコードを導入する。
Cisco Jabber DNS 設定ガイド
15
サービス（SRV）レコード
独立ドメイン構造での SRV レコード導入
サービス ドメインへの内部ゾーンの使用
内部ネーム サーバにサービス ドメイン用のゾーンがまだない場合、作成できます。 この方式で
は、内部ネーム サーバにサービス ドメインへの権限を持たせます。このため、内部ネーム サー
バはこれらのクエリーを別のネーム サーバに転送しません。
この方式は、ドメイン全体のフォワーディング関係を変え、内部DNS構造を混乱させることがあ
ります。 サービス ドメインの内部ゾーンを作成できない場合、内部ネーム サーバにピンポイン
ト サブドメイン ゾーンを作成できます。
ピンポイント サブドメイン ゾーンの使用
ピンポイント サブドメインとゾーンを内部ネーム サーバに作成できます。 ピンポイント ゾーン
は、ピンポイントサブドメインの特定のレコードを扱う、専用の場所を提供します。その結果、
内部ネーム サーバがそのサブドメインに権限を持つようになります。 内部ネーム サーバは親ド
メインには権限を持つようにならないため、親ドメインのレコードのクエリーの動作は変更され
ません。
次の図で、この手順で作成された設定について説明します。
この設定では、次の SRV レコードが内部 DNS ネーム サーバとともに導入されます:
• _cisco-uds._tcp.example.com
• _cuplogin._tcp.example.com
手順
ステップ 1
内部ネーム サーバに新しいゾーンを作成します。
重要
ピンポイント サブドメイン ゾーンには、cisco-internal.services-domain という
名前を使用する必要があります。
ピンポイントサブドメインゾーンは、内部ネットワークのホストからのクエリーに応答します。
ただし、ドメインは外部ドメインのサブドメインです。名前の最初の部分は、クライアントが予
期する固定値、cisco-internal です。
Cisco Jabber DNS 設定ガイド
16
サービス（SRV）レコード
SRV レコード
ステップ 2
ピンポイント サブドメイン ゾーンに _cisco-uds および _cuplogin SRV レコードを導入しま
す。
ピンポイント サブ ドメイン ゾーンの作成前
外部ネーム サーバは、親外部ドメイン example.com 用のゾーンを含みます。
内部ネーム サーバは、親内部ドメイン example.local 用のゾーンを含みます。
Jabber サービス ドメインは example.com です。
ピンポイント サブ ドメイン ゾーンの作成後
外部ネーム サーバは、親外部ドメイン example.com 用のゾーンを含みます。
内部ネーム サーバには次が含まれます。
親内部ドメイン用のゾーン、example.local。
ピンポイント サブドメイン ゾーン用のゾーン、cisco-internal.example.com。
内部ネーム サーバは、cisco-internal.example.com からの _cisco-uds および
_cuplogin SRV レコードを扱います。
クライアントが SRV レコードのネーム サーバをクエリーした場合、ネーム サーバが _cisco-uds
または _cuplogin を返さないときに追加クエリーを発行します。
追加クエリーは、cisco-internal.domain-name ピンポイント サブドメイン ゾーンをチェッ
クします。
たとえば、Adam McKenzie のサービス ドメインは、クライアント起動時には example.com で
す。 クライアントは次のクエリーを発効します。
_cisco-uds._tcp.example.com
_cuplogin._tcp.example.com
_collab-edge._tls.example.com
ネーム サーバが _cisco-uds または _cuplogin SRV レコードを返さない場合、クライアント
は次のクエリーを発行します。
_cisco-uds._tcp.cisco-internal.example.com
_cuplogin._tcp.cisco-internal.example.com
SRV レコード
導入が必要な SRV レコードについて理解し、それぞれの SRV レコードの例をレビューします。
Cisco Jabber DNS 設定ガイド
17
サービス（SRV）レコード
外部レコード
外部レコード
次の表に、Cisco Unified Communications Remote and Mobile Collaboration の設定の一部として外部
ネーム サーバにプロビジョニングが必要な SRV レコードの一覧を示します。
サービス レコード
説明
_collab-edge
Cisco VCS Expressway または Cisco Expressway-E サーバの場所を示し
ます。
（注）
SRV レコードでは、完全修飾ドメイン名（FQDN）をホス
ト名として使用します。
クライアントには、Cisco VCS Expressway または Cisco
Expressway-E サーバが提供する Cookie を使用するために
FQDN が必要です。
次に、_collab-edge SRV レコードの例を示します。
_collab-edge._tls.example.com
SRV service location:
priority
= 3
weight
= 7
port
= 8443
svr hostname
= vcse1.example.com
_collab-edge._tls.example.com
SRV service location:
priority
= 4
weight
= 8
port
= 8443
svr hostname
= vcse2.example.com
_collab-edge._tls.example.com
SRV service location:
priority
= 5
weight
= 0
port
= 8443
svr hostname
= vcse3.example.com
内部レコード
次の表に、クライアントがサービスを検出できるよう内部ネーム サーバにプロビジョニングする
必要がある SRV レコードの一覧を示します。
サービス レコード
説明
_cisco-uds
Cisco Unified Communications Manager バージョン 9 以降の場所を示し
ます。
メモ
_cuplogin
Cisco Jabber DNS 設定ガイド
18
複数の Cisco Unified Communications Manager クラスタがある
環境では、クラスタ間検索サービス（ILS）が必要です。 ILS
を使用することで、クライアントはユーザのホーム クラス
タの検索やサービスの検出が可能になります。
Cisco Unified Presence の場所を示します。
サービス（SRV）レコード
内部レコード
（注）
SRV レコードでは、完全修飾ドメイン名（FQDN）をホスト名として使用します。
次に、_cisco-uds SRV レコードの例を示します。
_cisco-uds._tcp.example.com
SRV service location:
priority
= 6
weight
= 30
port
= 8443
svr hostname
= cucm3.example.com
_cisco-uds._tcp.example.com
SRV service location:
priority
= 2
weight
= 20
port
= 8443
svr hostname
= cucm2.example.com
_cisco-uds._tcp.example.com
SRV service location:
priority
= 1
weight
= 5
port
= 8443
svr hostname
= cucm1.example.com
次に、_cuplogin SRV レコードの例を示します。
_cuplogin._tcp.example.com
priority
=
weight
=
port
=
svr hostname
=
_cuplogin._tcp.example.com
priority
=
weight
=
port
=
svr hostname
=
_cuplogin._tcp.example.com
priority
=
weight
=
port
=
svr hostname
=
SRV service location:
8
50
8443
cup3.example.com
SRV service location:
5
100
8443
cup1.example.com
SRV service location:
7
4
8443
cup2.example.com
Cisco Jabber DNS 設定ガイド
19
サービス（SRV）レコード
内部レコード
Cisco Jabber DNS 設定ガイド
20