Skype for Business Serverの高度なエッジ サーバー DNS 計画

概要：Skype for Business Server展開オプションのシナリオを確認します。 単一サーバーを使用したいと考えている場合も、DNS または HLB と共にサーバー プールを使用することを優先する場合も、このトピックは役に立ちます。

Skype for Business Serverのドメイン ネーム システム (DNS) 計画に関しては、多くの要因が決定に影響する可能性があります。 組織のドメイン構造が既に確立されている場合は、どのように作業を進めるか確認するための考慮事項になる可能性があります。 最初に、以下に示すトピックについて説明します。

• Walkthrough of Skype for Business clients locating services

• Split-brain DNS

• Automatic configuration without split-brain DNS

• DNS disaster recovery

• DNS load balancing

Walkthrough of Skype for Business clients locating services

Skype for Businessクライアントは、Skype for Business Serverでサービスを検索してアクセスする方法で、以前のバージョンの Lync クライアントと似ています。 ここではサーバー検索の詳細について説明します。

1. lyncdiscoverinternal。<ドメイン>

   これは、内部 Web サービスを対象とした自動検出サービスの A ホスト レコードです。

2. lyncdiscover。<ドメイン>

   これは、外部 Web サービスを対象とした自動検出サービスのホスト レコードです。

3. _sipinternaltls._tcp。<ドメイン>

   これは、内部 TLS 接続の SRV レコードです。

4. _sip._tls。<ドメイン>

   これは、外部 TLS 接続の SRV レコードです。

5. sipinternal。<ドメイン>

   これはフロントエンド プールまたはディレクターのホスト レコードであり、内部ネットワークでのみ解決できます。

6. Sip。<ドメイン>

   これはフロントエンド プールまたはディレクターのホスト レコードであり、内部ネットワークでのみ解決できます。

7. sipexternal。<ドメイン>

   これは、クライアントが外部にある場合の Access Edge サービスの A ホスト レコードです。

常に自動検出サービスを使用することが望まれます。これはサービス検出に関して優先される方法であり、他の方法はフォールバックの方法です。

必要に応じて、サービスを手動で検出できるようにモバイル デバイスを設定できます。 この方法を採用しようとする場合は、各ユーザーが自らのモバイル デバイスで、次のようにプロトコルとパスを含め、内部と外部の完全な自動検出サービス URL を構成する必要があります。

• 外部アクセスの場合: https://< ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root

• 内部アクセスの場合: https://< IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root

手動検出ではなく、自動検出を使用することを強くお勧めします。 ただし、トラブルシューティングやテストを行っている場合は、手動設定が役立ちます。

スプリットブレイン DNS

これは、2 つの DNS ゾーンが同じ名前空間に存在する DNS 構成です。 一方の DNS ゾーンは内部要求のみ、他方の DNS ゾーンは外部要求のみを処理します。

会社がこれを行う理由 内部および外部で同じ名前空間を使用する必要がある場合がありますが、もちろん、多くの DNS SRV と A レコードが 1 つのゾーンまたは別のゾーンに固有であり、重複がある場合、これらのレコードに関連付けられている IP アドレスは一意になります。

この状況にはいくつかの課題があります。 最も重要なのは、スプリットブレイン DNS がモビリティ でサポートされていないこと です。 これは、LyncDiscover と LyncDiscoverInternal の各 DNS レコードが原因です (LyncDiscover は外部 DNS サーバー上で、また LyncDiscoverInternal は内部 DNS サーバー上で定義する必要があります)。

ここでは、内部ゾーンと外部ゾーンの DNS レコードの一覧を示しますが、詳細な例については、Edge Server の環境要件に関するセクションを参照してください。

内部 DNS

• (たとえば) contoso.com という信頼できる DNS ゾーンが含まれています。

• 以下は、内部 contoso.com の内容です。

  • フロントエンド プール、ディレクター プールまたはディレクター プール名、およびorganizationのネットワークでSkype for Business Server実行されているすべての内部サーバーの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード。

  • 境界ネットワーク内の各エッジ サーバーのエッジ内部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコードSkype for Business Server。

  • 境界ネットワーク内の各リバース プロキシ サーバーの内部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード (リバース プロキシの管理には 省略可能 )。

  • DNS A と AAAA (IPv6 アドレッシングを使用している場合) と SRV レコードは、内部Skype for Business Serverクライアントの自動構成 (省略可能) です。

  • DNS A と AAAA (IPv6 アドレス指定を使用している場合) または CNAME レコードを使用して、Skype for Business Server Web サービスの自動検出 (省略可能) します。

• 境界ネットワーク内のすべてのSkype for Business Server内部エッジ インターフェイスは、この内部 DNS ゾーンを使用して、クエリを contoso.com に解決します。

• Skype for Business Serverを実行しているすべてのサーバーと、企業ネットワークでSkype for Business Serverを実行しているクライアントは、クエリを contoso.com に解決するために内部 DNS サーバーをポイントするか、各エッジ サーバーのホスト ファイルを使用して、次ホップ サーバー (特にディレクターまたはディレクター プール用) の A レコードと AAAA レコードを一覧表示します (IPv6 アドレス指定を使用している場合)。VIP、フロントエンド プール VIP、または Standard Edition サーバー)。

外部 DNS

• (たとえば) contoso.com という信頼できる DNS ゾーンが含まれています。

• 以下は、外部 contoso.com の内容です。

  • DNS A と AAAA (IPv6 アドレス指定を使用している場合)、または CNAME レコード (Skype for Business Server Web サービスの自動検出用)。 これはモビリティで使用するために使用されます。

  • 境界ネットワーク内の各 Skype for Business Server エッジ サーバーまたはハードウェア負荷分散 (HLB) VIP のエッジ外部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) と SRV レコード。

  • 境界ネットワークのリバース プロキシ サーバーの外部インターフェイスまたは (リバース プロキシ サーバーのプールの VIP) の DNS A と AAAA (IPv6 アドレス指定を使用している場合) と SRV レコード。

  • DNS A と AAAA (IPv6 アドレス指定を使用している場合) と、Skype for Business Server クライアントの自動構成 (省略可能) の SRV レコード。

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

スプリットブレイン DNS を使用しない場合、ここで用意されている回避策のいずれかを使用しない限り、Skype for Businessを実行しているクライアントの内部自動構成は機能しません。 なぜでしょうか。 Skype for Business Serverでは、ユーザーの SIP URI が、自動構成用に指定されたフロントエンド プールのドメインと一致する必要があるためです。 これは以前のバージョンの Lync Server から変更されていません。

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

• _sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com

  としてサインイン bob@contoso.comすると、ユーザーの SIP ドメインがフロントエンド プール (contoso.com) のドメインと一致する場合、このレコードは自動構成で機能します。

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

  ユーザーが として alice@fabrikam.comサインインすると、SIP ドメインがそのドメインのフロントエンド プールと一致するため、このレコードは 2 番目のドメインの自動構成で機能します。

ここまでの例を使用すると、次のレコードは機能しません。

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

  SIP ドメイン (litwareinc.com) がプール内のドメイン (fabrikam.com) と一致しないため、ユーザーが として tim@litwareinc.com サインインしても自動構成では機能しません。

これで、スプリットブレイン DNS を使用しないSkype for Business クライアントの自動要件が必要な場合は、次のオプションがあります。

• グループ ポリシー オブジェクト

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

  注意

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

• 内部ゾーンの一致

  外部 DNS ゾーン (contoso.com など) に一致するゾーンを内部 DNS に作成し、自動構成に使用されるSkype for Business Server プールに対応する DNS A (および IPv6 アドレス指定を使用している場合は AAAA) レコードを作成する必要があります。

  たとえば、ユーザーが pool01.contoso.net に所属していても、 としてbob@contoso.comSkype for Businessにサインインしている場合は、contoso.com という内部 DNS ゾーンを作成し、その中に pool01.contoso.com の DNS A (IPv6 アドレス指定が使用されている場合は AAAA) レコードを作成する必要があります。

• ピンポイントの内部ゾーン

  内部 DNS 内にゾーン全体を作成することが適切なオプションではない場合は、自動構成で必要とされる複数の SRV レコードに対応するピンポイント (専用) ゾーンを作成し、dnscmd.exe を使用してそれらのゾーンを設定することができます。 DNS ユーザー インターフェイスはピンポイント ゾーンの作成をサポートしていないため、Dnscmd.exe が必須です。

  たとえば、SIP ドメインが contoso.com で、2 つのフロントエンド サーバーを含む pool01 というフロントエンド プールがある場合、内部 DNS には次のピンポイント ゾーンと A レコードが必要です。

  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. @ AAAA <IPv6 address>
  dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91 
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  

  環境内で 2 番目の SIP ドメインを用意することもできます。 この場合は、内部 DNS 内で以下のピンポイント ゾーンと A レコードが必要になります。

  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.contoso.com. @ AAAA <IPv6 address>
  dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  

DNS 障害復旧

web トラフィックSkype for Business Serverディザスター リカバリー (DR) サイトとフェールオーバー サイトにリダイレクトするように DNS を構成するには、GeoDNS をサポートする DNS プロバイダーを使用する必要があります。 ディザスター リカバリーをサポートするように DNS レコードを設定すると、フロントエンド プール全体がダウンしても Web サービスを使用する機能が続行されます。 この DR 機能では、自動検出、会議、ダイヤルインの単純な URL がサポートされています。

You define and configure additional DNS host A (AAAA if using IPv6) records for internal and external resolution of web services at your GeoDNS provider. The following details assume paired pools, geographically dispersed, and that the GeoDNS supported by your provider either has round-robin DNS or is configured to use Pool1 as primary and fails over to Pool2 in the event of any communications loss or power failure.

この表の DNS レコードは、いずれも例です。

DNS 負荷分散

DNS 負荷分散は一般的に、アプリケーション レベルで実装されます。 アプリケーション (たとえば、Skype for Businessを実行しているクライアント) は、プール FQDN の DNS A および AAAA (IPv6 アドレス指定が使用されている場合) レコード クエリから返されるいずれかの IP アドレスに接続することで、プール内のサーバーへの接続を試みます。

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

• Skype for Business実行されているクライアントは、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 のネゴシエーションを行い、pool01.contoso.com のプライマリ レジストラーに接続します。

• クライアントが接続に成功せずにキャッシュされたすべてのエントリを試みると、ユーザーはSkype for Business Serverを実行しているサーバーが現時点で使用できないという通知を受け取ります。

DNS 負荷分散の用途:

• サーバー間 SIP をエッジ サーバーに負荷分散します。

• 会議自動アテンダント、応答グループ、コール パークなどの統合コミュニケーション アプリケーション サービス (UCAS) アプリケーションの負荷分散

• UCAS アプリケーションへの新規接続の禁止(ドレインとも呼ばれます)

• クライアントとエッジ サーバー間のすべてのクライアントとサーバー間のトラフィックを負荷分散します。

DNS 負荷分散を使用できない用途:

• フロントエンド サーバーまたはディレクターへのクライアントからサーバーへの Web トラフィック。

クエリによって複数の DNS レコードが返されたときに DNS SRV レコードがどのように選択されるかについてもう少し詳しく説明するために、Access Edge サービスは常に最も低い数値の優先順位でレコードを選択し、タイ ブレーカーが必要な場合は最も高い数値の重みを取得します。 これは、 インターネット エンジニアリング タスク フォースのドキュメントと一致します。

そのため、たとえば最初の DNS SRV レコードの重み付けが 20 で、優先順位が 40、また 2 番目の DNS SRV レコードの重み付けが 10 で、優先順位が 50 の場合は、優先順位が 40 である最初のレコードが選択されます。 常に優先順位が最初に考慮され、クライアントが最初にターゲットにするホストになります。 同じ優先順位を持つターゲットが 2 つ存在する場合はどうなるでしょうか。

この場合は、重み付けが考慮されます。 この状況では、重み付けが大きいほど、選択される確率が高くなります。 サーバー選択を行わない場合は、DNS 管理者は重み付け 0 を使用する必要があります。 0 より大きい重み付けを持つレコードが存在するとき、重み付け 0 のレコードが選択される可能性は非常に小さくなります。

同じ優先度と重み付けを持つ複数の DNS SRV レコードが返された場合は、どうなるでしょうか。 この状況では、Access Edge サービスは最初に DNS サーバーから取得した SRV レコードを選択します。