[アーティクル]
08/09/2014

DNS 要件の確認

トピックの最終更新日: 2012-10-16

次のフローチャートを使用してドメインネームシステム (DNS) の要件を判断します。

DNS 要件の判断フローチャート

外部ユーザーアクセスに対する DNS フローチャート

重要:
指定する名前が、サーバーに構成されているコンピューター名と同じである必要があります。既定では、ドメインに参加していないコンピューターのコンピューター名は、完全修飾ドメイン名 (FQDN) ではなく短い名前です。トポロジビルダーは、短い名前ではなく FQDN を使用します。そのため、エッジサーバーとして展開する、ドメインに参加していないコンピューターの名前には、DNS サフィックスを構成する必要があります。Lync Server、エッジサーバー、およびプールの FQDN を割り当てる場合に使用できる文字は、標準文字のみ (A ～ Z、a ～ z、0 ～ 9、およびハイフン) です。Unicode 文字およびアンダースコアは使用しないでください。一般に、外部 DNS および公的 CA では、FQDN に非標準文字はサポートされていません (証明書で FQDN を SN に割り当てることが必要になります)。DNS サフィックスをコンピューター名に追加する方法の詳細については、「エッジサポートの DNS レコードの構成」を参照してください。

指定する名前が、サーバーに構成されているコンピューター名と同じである必要があります。既定では、ドメインに参加していないコンピューターのコンピューター名は、完全修飾ドメイン名 (FQDN) ではなく短い名前です。トポロジビルダーは、短い名前ではなく FQDN を使用します。そのため、エッジサーバーとして展開する、ドメインに参加していないコンピューターの名前には、DNS サフィックスを構成する必要があります。Lync Server、エッジサーバー、およびプールの FQDN を割り当てる場合に使用できる文字は、標準文字のみ (A ～ Z、a ～ z、0 ～ 9、およびハイフン) です。Unicode 文字およびアンダースコアは使用しないでください。一般に、外部 DNS および公的 CA では、FQDN に非標準文字はサポートされていません (証明書で FQDN を SN に割り当てることが必要になります)。DNS サフィックスをコンピューター名に追加する方法の詳細については、「エッジサポートの DNS レコードの構成」を参照してください。

Lync Server 2010 によるスプリットブレイン DNS の構成

スプリットブレイン DNS は、ネットワークアドレス変換 (NAT) の場合と同様に、いくつかの異なる方法で定義されています。このドキュメントでは、スプリットブレイン DNS という言葉は、個々の名前空間の DNS ゾーンが、外部 DNS 内にある場合と内部 DNS 内にある場合で同じという意味で使用されます。ただし、内部 DNS 内の DNS SRV レコードおよび A レコードの多くは、外部 DNS には存在せず、この逆の場合も同様です。また、内部 DNS と外部 DNS の両方に同じ DNS レコードが存在する場合 (www.contoso.com など)、返される IP アドレスは DNS クエリが実行された場所によって異なります。

スプリットブレイン DNS を構成する場合、次の内部ゾーンと外部ゾーンには、各ゾーンで必要な DNS レコードの種類の概要が含まれます。詳細については、「関連アーキテクチャ」を参照してください。

内部 DNS

contoso.com という信頼できる DNS ゾーンを含みます。
内部の contoso.com ゾーンの内容
- Microsoft Lync Server 2010 クライアントの自動構成用の DNS A レコードと SRV レコード (オプション)
- Lync Server Web サービスの自動検出用の DNS A レコードまたは CNAME レコード
- 企業ネットワーク内で Lync Server 2010 を実行するすべての内部サーバーの DNS A レコードと SRV レコード
- 境界ネットワークの Lync Server 2010 ごとのエッジサーバーの内部インターフェイスの DNS A レコードと SRV レコード
- 境界ネットワークのリバースプロキシサーバーごとの内部インターフェイスの DNS A レコード
- 境界ネットワークのすべての Lync Server 2010 エッジサーバーは、内部 DNS サーバーを参照して contoso.com のクエリを解決します。
- 企業ネットワーク内の Lync Server 2010 を実行しているサーバーおよび Lync 2010 を実行しているクライアントはすべて、内部 DNS サーバーを参照して contoso.com のクエリを解決します。

外部 DNS

contoso.com という信頼できる DNS ゾーンを含みます。
外部の contoso.com ゾーンの内容
- Lync Server 2010 クライアントの自動構成 (オプション) 用の DNS A レコードと SRV レコード
- Lync Server Web サービスの自動検出用の DNS A レコードまたは CNAME レコード
- 境界ネットワークの Lync Server 2010 ごとのエッジサーバーの外部インターフェイスまたはハードウェアロードバランサーの仮想 IP (VIP) の DNS A レコードと SRV レコード
- 境界ネットワークのリバースプロキシサーバーごとの外部インターフェイスの DNS A レコード

Microsoft Lync 2010 を実行するクライアントがサービスを見つける方法

DNS 参照中に、SRV レコードのクエリは並行して実行され、次の順序でクライアントに返されます (構成済みで使用可能な場合)。

_sipinternaltls._tcp.<ドメイン> - 内部 TLS 接続の場合
_sipinternal._tcp. <ドメイン> : 内部 TCP 接続の場合 (TCP が許可されている場合のみ実行)
_sip._tls. <ドメイン> : 外部 TLS 接続の場合
_sip._tcp. <ドメイン> : 外部 TCP 接続の場合 (TCP が許可されている場合のみ実行)

<ドメイン> は、内部クライアントが使用する SIP ドメインです。最後の 2 つのクエリは、クライアントが内部ネットワークの外から接続する場合です。 SRV レコードを作成する場合は、DNS SRV レコードが作成されている同じドメインの DNS A レコードを指す必要があります。たとえば、SRV レコードが contoso.com にある場合、A レコードが指す先は fabrikam.com 内ではなく、contoso.com 内である必要があります。

初めてサインインすると、ネットワークの内側または外側からサインインするかどうかにかかわらず、Lync を実行するクライアントは 3 つの各 SRV レコードを順番に使用してフロントエンドプールへの接続を試みます。Lync を実行するクライアントが正常に接続を確立すると、その DNS エントリはキャッシュに格納され、正常に接続できなくなるまで使用され続けます。Lync を実行するクライアントがキャッシュされた値を使用できない場合は、DNS に対して SRV レコードについてクエリが実行され、キャッシュが再設定されます。たとえば、日中に内部ネットワークからサインインした後に、ラップトップを自宅に持ち帰り、外部からサインインした場合のプロセスは次のとおりです。

SRV レコードが返された後、SRV レコードに関連付けられたサーバーまたはフロントエンドプールの DNS A レコードについて (FQDN による) クエリが実行されます。 DNS SRV クエリでレコードが見つからなかった場合、Lync クライアントは sipinternal.<ドメイン> の明示的な参照を実行します。明示的な参照でもレコードが見つからなかった場合、Lync クライアントは sip.<ドメイン> の参照を実行します。

スプリットブレイン DNS なしの自動構成

スプリットブレイン DNS を使用する場合、使用されている各 SIP ドメインの _sipinternaltls._tcp SRV レコードが内部 DNS ゾーンに含められていれば、内部からサインインする Lync Server 2010 ユーザーは自動構成を利用できます。ただし、スプリットブレイン DNS を使用しない場合、後ほど説明する解決法の 1 つを実装しない限り、Lync を実行するクライアントの内部での自動構成は機能しません。Lync Server 2010 では、ユーザーの SIP URI が、自動構成用に指定されたフロントエンドプールのドメインと一致する必要があるためです。これは、Communicator の旧バージョンの場合でも同様です。

たとえば、使用されている SIP ドメインが 2 つある場合、次の DNS サービス (SRV) レコードが必要です。

ユーザーが lstest01@contoso.com としてサインインした場合、次の SRV レコードは、ユーザーの SIP ドメイン (contoso.com) が自動構成用に指定されたフロントエンドプールのドメインと一致するため、自動構成が機能します。

_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com
ユーザーが lstest01@fabrikam.com としてサインインした場合、次の SRV レコードは、2 つ目の SIP ドメインの自動構成について機能します。

_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

これに対して、ユーザーが lstest01@litwareinc.com としてサインインした場合、次の SRV レコードは、クライアントの SIP ドメイン (litwareinc.com) がプールのドメイン (fabrikam.com) と一致しないため、自動構成が機能しません。

_sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Lync を実行するクライアントについて自動構成が必要な場合は、次のオプションのいずれかを選択します。

グループポリシーオブジェクト グループポリシーオブジェクト (GPO) を使用して、適切なサーバーの値を設定します。

注:
このオプションは自動構成を有効にしませんが、手動構成のプロセスを自動化するので、この方法を使用した場合、自動構成に関連付ける SRV レコードは必要ありません。

内部ゾーンの一致 外部 DNS ゾーン (contoso.com など) と一致するゾーンを内部 DNS に作成し、自動構成に使用する Lync Server 2010 のプールに対応する DNS A レコードを作成します。たとえば、pool01.contoso.net に所属するユーザーが Lync に lstest01@contoso.com としてサインインする場合、contoso.com という内部 DNS ゾーンを作成し、その中に pool01.contoso.com の DNS A レコードを作成します。
ピンポイントの内部ゾーン 内部 DNS にゾーン全体を作成することができない場合は、自動構成に必要な SRV レコードに対応するピンポイント (つまり専用) のゾーンを作成し、dnscmd.exe を使用してこれらのゾーンを設定できます。 dnscmd.exe が必要なのは、DNS のユーザーインターフェイスでは、ピンポイントのゾーン作成がサポートされていないからです。たとえば、SIP ドメインが contoso.com で、2 つのフロントエンドサーバーが含まれる pool01 というフロントエンドプールがある場合、次のピンポイントのゾーンと A レコードが内部 DNS に必要です。
```
dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com.
dnscmd . /zoneadd pool01.contoso.com. /dsprimary
dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90
dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91
```
現在の環境に 2 つ目の SIP ドメイン (fabrikam.com など) がある場合は、次のピンポイントのゾーンと A レコードが内部 DNS に必要です。
```
dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary
dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com.
dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary
dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90
dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
```

注:
フロントエンドプールの FQDN は 2 つ表示されますが、これには 2 つの異なる IP アドレスが対応しています。これは DNS 負荷分散が使用されているためですが、ハードウェアロードバランサーが使用される場合は、フロントエンドプールのエントリが 1 つのみになります。また、フロントエンドプールの FQDN 値は contoso.com の例と fabrikam.com の例で異なりますが、IP アドレスは同じです。これは、いずれの SIP ドメインからサインインするユーザーも、自動構成に同じフロントエンドプールを使用するためです。

フロントエンドプールの FQDN は 2 つ表示されますが、これには 2 つの異なる IP アドレスが対応しています。これは DNS 負荷分散が使用されているためですが、ハードウェアロードバランサーが使用される場合は、フロントエンドプールのエントリが 1 つのみになります。また、フロントエンドプールの FQDN 値は contoso.com の例と fabrikam.com の例で異なりますが、IP アドレスは同じです。これは、いずれの SIP ドメインからサインインするユーザーも、自動構成に同じフロントエンドプールを使用するためです。

詳細については、DMTF のブログ記事「Communicator Automatic Configuration and Split-Brain DNS」 (https://go.microsoft.com/fwlink/?linkid=200707&clcid=0x411) を参照してください。

注:
各ブログの内容と URL は、将来予告なしに変更されることがあります。

Lync 2010 を実行するモバイルデバイスクライアントがサービスを見つける方法

Lync 2010 を実行するモバイルデバイスクライアントは、自動検出の DNS A レコードまたは CNAME レコードを使用して、モビリティサービスを見つけます。DNS の参照中に、まず、内部 DNS レコードに関連付けられた完全修飾ドメイン名 (FQDN) への接続が試みられます (つまり、lyncdiscoverinternal. <sipdomain>)。内部 URL に接続できない場合は、外部 DNS レコードに関連付けられた FQDN への接続が試みられます (つまり、lyncdiscover. <sipdomain>)。優先されるのは、常に内部 URL です。内部 URL への接続に成功した場合、クライアントは企業の Wi-Fi ネットワークを使用します。内部 URL への接続に失敗し、外部 URL への接続に成功した場合、クライアントの要求はリバースプロキシを経由してフロントエンドサーバーまたはディレクターにルーティングされます。

接続に成功すると、自動検出サービスは、Mobility Service の URL を含め、ユーザーのホームプール用のすべての Web サービス URL を返します。ただし、Mobility Service の内部 URL と Mobility Service の外部 URL は共に Web サービスの外部 FQDN に関連付けられます。したがって、モバイルデバイスがネットワークの内部または外部のどちらにあるかどうかに関係なく、デバイスは、常に、リバースプロキシ経由で Mobility Service に外部から接続します。

ヒント:
既定の構成では、モバイルクライアントのトラフィックは外部サイトを通過できますが、設定を変更して内部 URL のみを返すようにできます。この構成では、ユーザーは、企業ネットワークの内側にいる場合にのみ、モバイルデバイスで Lync モバイルアプリケーションを使用できます。この構成をサポートするには、Set-CsMcxConfiguration コマンドレットを実行する必要があります。また、フロントエンドサーバーおよびディレクターのハードウェアロードバランサーで内部 Web サービス仮想 IP (VIP) を構成し、Cookie ベースの永続性を確保する必要があります。ハードウェアロードバランサーの要件の詳細については、「ロードバランサー機器」の「リバースプロキシに対するハードウェアロードバランサーの要件」を参照してください。Set-CsMcxConfiguration を使用してモバイルクライアントのトラフィックを内部ネットワークに制限する方法の詳細については、「Mobility Service と自動検出サービスのインストール」を参照してください。

既定の構成では、モバイルクライアントのトラフィックは外部サイトを通過できますが、設定を変更して内部 URL のみを返すようにできます。この構成では、ユーザーは、企業ネットワークの内側にいる場合にのみ、モバイルデバイスで Lync モバイルアプリケーションを使用できます。この構成をサポートするには、Set-CsMcxConfiguration コマンドレットを実行する必要があります。また、フロントエンドサーバーおよびディレクターのハードウェアロードバランサーで内部 Web サービス仮想 IP (VIP) を構成し、Cookie ベースの永続性を確保する必要があります。ハードウェアロードバランサーの要件の詳細については、「ロードバランサー機器」の「リバースプロキシに対するハードウェアロードバランサーの要件」を参照してください。Set-CsMcxConfiguration を使用してモバイルクライアントのトラフィックを内部ネットワークに制限する方法の詳細については、「Mobility Service と自動検出サービスのインストール」を参照してください。

注:
モバイルアプリケーションは、他の Lync Server 2010 サービス (アドレス帳サービスなど) にも接続できますが、Mobility Service に対する内部のモバイルアプリケーション Web 要求に限っては、外部 Web FQDN に送信されます。他のサービス要求 (アドレス帳要求など) では、この構成は必要ありません。

モバイルデバイス向けの Lync 2010 では、サービスの手動検出もサポートされます。この場合、次のように、プロトコルおよびパスを含む、自動検出サービスの完全な内部 URL および外部 URL を使用して、各ユーザーがモバイルデバイスの設定を構成する必要があります。

https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root for external access
https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root for internal access

手動検出ではなく自動検出を使用することを強くお勧めします。ただし、モバイルデバイスの接続の問題についてトラブルシューティングを行うには、手動設定の使用が役に立ちます。自動検出サービスで使用される DNS レコードの詳細については、「モビリティの技術要件」を参照してください。モビリティの計画の詳細については、「モビリティの計画」を参照してください。

DNS 負荷分散

DNS ロードバランシングは一般的に、アプリケーションレベルで実装されます。アプリケーション (Lync 2010 を実行するクライアントなど) は、プールの完全修飾ドメイン名 (FQDN) に対する DNS A クエリで得られた IP アドレスの 1 つに接続することで、プール内のサーバーへの接続を試みます。

たとえば、pool01.contoso.com という名前のプールに 3 つのフロントエンドサーバーがある場合、次のようになります。

Lync 2010 を実行するクライアントは DNS に対して pool01.contoso.com についてクエリを実行し、3 つの IP アドレスを受け取って、それらを次のようにキャッシュに格納します (この順序になるとは限りません)。

pool01.contoso.com      192.168.10.90

pool01.contoso.com      192.168.10.91

pool01.contoso.com      192.168.10.92
次に、クライアントは IP アドレスの 1 つに対して伝送制御プロトコル (TCP) 接続を確立しようとします。それが失敗した場合は、キャッシュ内の次の IP アドレスで試します。
TCP 接続が成功した場合、クライアントは TLS のネゴシエーションを行い、フロントエンドサーバーに接続します。
正常な接続を確立できないまま終了した場合は、その時点で利用できる Lync Server 2010 を実行しているサーバーがないことがユーザーに通知されます。

注:
DNS ベースの負荷分散は、一般的に、DNS を利用してプール内のサーバーに対応する IP アドレスを別の順序で提供させて負荷分散を行うことを指す DNS ラウンドロビン (DNS RR) と異なります。一般的に、DNS RR は負荷分散のみが可能で、フェールオーバー機能は提供されません。たとえば、DNS A クエリで返された 1 つの IP アドレスに対する接続が失敗した場合、その接続は失敗します。したがって、DNS ラウンドロビン自体は DNS ベースの負荷分散より信頼性が劣ります。 DNS ラウンドロビンは、DNS 負荷分散と共に使用することができます。

DNS ベースの負荷分散は、一般的に、DNS を利用してプール内のサーバーに対応する IP アドレスを別の順序で提供させて負荷分散を行うことを指す DNS ラウンドロビン (DNS RR) と異なります。一般的に、DNS RR は負荷分散のみが可能で、フェールオーバー機能は提供されません。たとえば、DNS A クエリで返された 1 つの IP アドレスに対する接続が失敗した場合、その接続は失敗します。したがって、DNS ラウンドロビン自体は DNS ベースの負荷分散より信頼性が劣ります。 DNS ラウンドロビンは、DNS 負荷分散と共に使用することができます。

DNS 負荷分散は次のような状況で使用されます。

サーバー間の SIP および HTTP トラフィックのロードバランシング
会議自動アテンダント、応答グループ、コールパークなどの統合コミュニケーションアプリケーションサービス (UCAS) アプリケーションの負荷分散
UCAS アプリケーションへの新規接続 (別名 "ドレイン") の禁止
クライアントとエッジサーバー間における、クライアントとサーバー間のすべてのトラフィックのロードバランシング

DNS 負荷分散は次のような状況では使用できません。

クライアントとサーバー間の Web トラフィック

DNS 負荷分散とフェデレーショントラフィック

DNS SRV クエリで複数の DNS レコードが返された場合、アクセスエッジサービスは、優先度の数値が最も小さく、重みの数値が最も大きい DNS SRV レコードを選択します。同じ優先度と重みを持つ複数の DNS SRV レコードが返された場合、アクセスエッジサービスは、DNS サーバーから最初に返された SRV レコードを選択します。

次の方法で共有

DNS 要件の確認

Lync Server 2010 によるスプリットブレイン DNS の構成

Microsoft Lync 2010 を実行するクライアントがサービスを見つける方法

スプリットブレイン DNS なしの自動構成

Lync 2010 を実行するモバイルデバイスクライアントがサービスを見つける方法

DNS 負荷分散

その他のリソース

次の方法で共有

DNS 要件の確認

Lync Server 2010 によるスプリットブレイン DNS の構成

Microsoft Lync 2010 を実行するクライアントがサービスを見つける方法

スプリットブレイン DNS なしの自動構成

Lync 2010 を実行するモバイル デバイス クライアントがサービスを見つける方法

DNS 負荷分散

その他のリソース

Lync 2010 を実行するモバイルデバイスクライアントがサービスを見つける方法