トピック最終更新日: 2013-02-22
次のフローチャートを使用して、ドメイン ネーム システム (DNS) の要件を決定します。 Lync Server 2013 の累積的なUpdatesの変更: 2013 年 2 月は、適用される場所に記載されています。
Important
Microsoft Lync Server 2013 では、IPv6 アドレス指定の使用がサポートされています。 IPv6 アドレスを使用するには、IPv6 DNS のサポートを提供し、DNS ホスト AAAA ("quad-A" と呼ばれる) レコードを構成する必要もあります。 IPv4 と IPv6 の両方が使用されているデプロイでは、IPv4 のホスト A レコードと IPv6 用のホスト AAAA の両方を構成して維持することをお勧めします。 デプロイが IPv6 に完全に移行した場合でも、外部ユーザーがまだ IPv4 を使用している場合は、IPv4 DNS ホスト レコードが必要になることがあります。
DNS 要件の決定フロー チャート
.jpg "175782ac-363e-408a-912f-8991bf152970")
Important
既定では、ドメインに参加していないコンピューターのコンピューター名はホスト名であり、完全修飾ドメイン名 (FQDN) ではありません。 トポロジ ビルダーでは、ホスト名ではなく FQDN が使用されます。 そのため、エッジ サーバーとして展開する、ドメインに参加していないコンピューターの名前で DNS サフィックスを構成する必要があります。 Lync Server、エッジ サーバー、およびプールの FQDN を割り当てる場合に使用できる文字は、標準文字のみ (A ～ Z、a ～ z、0 ～ 9、およびハイフン) です。 Unicode 文字およびアンダースコアは使用しないでください。 一般に、外部 DNS および公的 CA では、FQDN に非標準文字はサポートされていません (証明書で FQDN を SN に割り当てることが必要になります)。 詳細については、「Lync Server 2013 の DNS ホスト レコードを構成する」を参照してください。
Lync クライアントがサービスを検索する方法
Microsoft Lync 2010、Lync 2013、および Lync Mobile は、クライアントが Lync Server 2013 でサービスを検索してアクセスする方法に似ています。 注目すべき例外は、別のサービスの場所プロセスを使用する Lync Windows ストア アプリです。 このセクションでは、クライアントがサービスを検索する方法の 2 つのシナリオについて詳しく説明します。最初に、一連の SRV レコードと A ホスト レコードを使用する従来の方法、2 つ目は自動検出サービス レコードのみを使用します。 デスクトップ クライアントの累積的な更新により、Lync Server 2010 から DNS の場所プロセスが変更されます。すべてのクライアントの場合、DNS クエリ プロセスは、クエリが正常に返されるか、可能な DNS レコードの一覧が使い果たされ、最終的なエラーがクライアントに返されるまで続行されます。
Lync Windows ストア アプリを 除く すべてのクライアントの DNS 参照中に、SRV レコードがクエリされ、次の順序でクライアントに返されます。
lyncdiscoverinternal.<domain> 内部 Web サービス上の自動検出サービスの A (ホスト) レコード
lyncdiscover.<domain> 外部 Web サービス上の自動検出サービスの A (ホスト) レコード
_sipinternaltls._tcp.<domain> 内部 TLS 接続の SRV (サービス ロケーター) レコード
_sipinternal._tcp.<domain> 内部 TCP 接続の SRV (サービス ロケーター) レコード (TCP が許可されている場合にのみ実行)
_sip._tls.<domain> 外部 TLS 接続の SRV (サービス ロケーター) レコード
sipinternal.<domain> フロントエンド プールまたはディレクターの (ホスト) レコード(内部ネットワークでのみ解決可能)
sip.<domain> 内部ネットワーク上のフロントエンド プールまたはディレクターの (ホスト) レコード、またはクライアントが外部にある場合は Access Edge サービス
sipexternal.<domain> クライアントが外部にある場合の Access Edge サービスの (ホスト) レコード
Lync Windows ストア アプリは、次の 2 つのレコードを使用するため、プロセスを完全に変更します。
lyncdiscoverinternal.<domain> 内部 Web サービス上の自動検出サービスの A (ホスト) レコード
lyncdiscover.<domain> 外部 Web サービス上の自動検出サービスの A (ホスト) レコード
他のレコード型へのフォールバックはありません。
古いクライアントと比較して新しいクライアントに使用される方法の違いは、自動検出サービスがすべてのサービスを検索する推奨される方法になりつつあります。
接続が成功すると、自動検出サービスは、モビリティ サービス (IIS のサービス用に作成された仮想ディレクトリによって Mcx と呼ばれます)、Microsoft Lync Web App、Web スケジューラ URL など、ユーザーのホーム プールのすべての Web サービス URL を返します。 ただし、内部モビリティ サービス URL と外部モビリティ サービス URL の両方が外部 Web サービス FQDN に関連付けられています。 そのため、モバイル デバイスがネットワークの内部か外部かに関係なく、デバイスは常にリバース プロキシを介してモビリティ サービスに外部接続します。
Lync Server 2013 の累積的なUpdates: 2013 年 2 月がインストールされている場合、自動検出サービスは、内部/UCWA、外部/UCWA、UCWA への参照も返します。 これらのエントリは、ユニファイド コミュニケーション Web API (UCWA) Web コンポーネントを参照します。 現時点では、エントリ UCWA のみが使用され、Web コンポーネントの URL への参照が提供されます。 UCWA は、Lync 2010 Mobile クライアントで使用される Mcx Mobility Service ではなく、Lync 2013 Mobile クライアントによって使用されます。
注意
SRV レコードを作成する場合は、DNS SRV レコードが作成されるのと同じドメイン内の DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコードを指す必要があります。 たとえば、SRV レコードが contoso.com にある場合、A レコードと AAAA レコード (IPv6 アドレッシングを使用している場合) は、fabrikam.com に含めることはできません。
ヒント
既定の構成では、すべてのモバイル クライアント トラフィックを外部サイト経由で転送します。 要件に適している場合は、内部 URL のみを返すように設定を変更できます。 この構成では、ユーザーは会社のネットワーク内にある場合にのみ、モバイル デバイスで Lync モバイル アプリケーションを使用できます。 この構成を定義するには、 Set-CsMcxConfiguration コマンドレットを 使用します。
注意
モバイル アプリケーションは、アドレス帳サービスなどの他の Lync Server 2013 サービスにも接続できますが、内部モバイル アプリケーション Web 要求はモビリティ サービスの外部 Web FQDN にのみ送信されます。 アドレス帳要求などの他のサービス要求では、この構成は必要ありません。
モバイル デバイスでは、サービスの手動検出がサポートされます。 この場合、各ユーザーは、次のように、プロトコルとパスを含む完全な内部および外部の自動検出サービス URI を使用してモバイル デバイス設定を構成する必要があります。
外部アクセス用の https://<ExtPoolFQDN>/自動検出/自動検出サービス.svc/Root
https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root for internal access
手動検出ではなく、自動検出を使用することをお勧めします。 ただし、手動設定は、モバイル デバイスの接続に関する問題のトラブルシューティングに役立ちます。
Lync Server Split-Brain DNS の構成
スプリット ブレイン DNS は、スプリット DNS やスプリットホライズン DNS など、さまざまな名前で認識されます。 単純に、同じ名前空間を持つ 2 つの DNS ゾーンがありますが、1 つの DNS ゾーン サービスの内部専用要求と、他の DNS ゾーン サービスの外部専用要求がある DNS 構成について説明します。 ただし、内部 DNS に含まれる DNS SRV レコードと A レコードの多くは外部 DNS に含まれません。逆も当てはまります。 内部 DNS と外部 DNS の両方に同じ DNS レコードが存在する場合 (たとえば、 www.contoso.com)、返される IP アドレスは、クエリが開始された場所 (内部または外部) に基づいて異なります。
Important
現時点では、Split-Brain DNS はモビリティではサポートされていません。具体的には、LyncDiscover と LyncDiscoverInternal DNS レコードです。 LyncDiscover は外部 DNS サーバーで定義する必要があり、LyncDiscoverInternal は内部 DNS サーバーで定義する必要があります。
これらのトピックでは、スプリット ブレイン DNS という用語が使用されます。
スプリットブレイン DNS を構成する場合、次の内部ゾーンと外部ゾーンには、各ゾーンで必要な DNS レコードの種類の概要が含まれます。 詳細については、「 Lync Server 2013 の外部ユーザー アクセスのシナリオ」を参照してください。
内部 DNS:
権限を持つ contoso.com という DNS ゾーンが含まれています
内部 contoso.com ゾーンには、次のものが含まれます。
内部 Lync Server 2013 クライアント自動構成の DNS A と AAAA (IPv6 アドレス指定を使用している場合) と SRV レコード (省略可能)
Lync Server 2013 Web Services の自動検出に DNS A と AAAA (IPv6 アドレス指定を使用している場合) または CNAME レコード (省略可能)
フロントエンド プール名、ディレクターまたはディレクター プール名、および企業ネットワークで Lync Server 2013 を実行しているすべての内部サーバーの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード
境界ネットワーク内の各 Lync Server 2013 エッジ サーバーのエッジ内部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード
境界ネットワーク内の各リバース プロキシ サーバーの内部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード (リバース プロキシの管理には省略可能)
境界ネットワーク内のすべての Lync Server 2013 Edge Server 内部エッジ インターフェイスは、クエリを解決するために内部 DNS ゾーンを使用 contoso.com
Lync Server 2013 を実行しているすべてのサーバーと、企業ネットワークで Lync 2013 を実行しているクライアントは、内部 DNS サーバーをポイントして、クエリを contoso.com に解決したり、各エッジ サーバーで HOSTS ファイルを使用したり、A と AAAA (IPv6 アドレス指定を使用している場合)、次ホップ サーバー (特にディレクターまたはディレクター VIP) のレコードを一覧表示します。 フロントエンド プール VIP、または Standard Edition サーバー
外部 DNS:
権限を持つ contoso.com という DNS ゾーンが含まれています
外部 contoso.com ゾーンには、次のものが含まれます。
Lync Server 2013 クライアント自動構成の DNS A と AAAA (IPv6 アドレス指定を使用している場合) と SRV レコード (省略可能)
モビリティで使用する Lync Server 2013 Web Services の自動検出用の DNS A と AAAA (IPv6 アドレス指定を使用している場合) または CNAME レコード
境界ネットワーク内の各 Lync Server 2013、Edge Server、またはハードウェア ロード バランサー仮想 IP (VIP) のエッジ外部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) と SRV レコード
境界ネットワーク内のリバース プロキシ サーバーのプールのリバース プロキシ サーバーまたは VIP の外部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード
Split-Brain DNS を使用しない自動構成
スプリットブレイン DNS を使用すると、内部でサインインする Lync Server 2013 ユーザーは、内部 DNS ゾーンに使用中の SIP ドメインごとに _sipinternaltls._tcp SRV レコードが含まれている場合、自動構成を利用できます。 ただし、スプリットブレイン DNS を使用しない場合、このセクションで後述する回避策の 1 つが実装されていない限り、Lync を実行しているクライアントの内部自動構成は機能しません。 これは、Lync Server 2013 では、ユーザーの SIP URI が、自動構成用に指定されたフロントエンド プールのドメインと一致する必要があるためです。 これは、以前のバージョンの Communicator の場合にも当てはっていました。
たとえば、2 つの SIP ドメインが使用されている場合は、次の DNS サービス (SRV) レコードが必要になります。
ユーザーが bob@contoso.com としてサインインすると、ユーザーの SIP ドメイン (contoso.com) が自動構成フロントエンド プールのドメインと一致するため、次の SRV レコードが自動構成で機能します。
_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com
ユーザーが alice@fabrikam.com サインインした場合、次の DNS SRV レコードは、2 つ目の SIP ドメインの自動構成に対して機能します。
_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
比較のために、ユーザーが tim@litwareinc.com としてサインインした場合、クライアントの SIP ドメイン (litwareinc.com) がプール内のドメイン (fabrikam.com) と一致しないため、次の DNS SRV レコードは自動構成では機能しません。
_sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
Lync を実行しているクライアントに自動構成が必要な場合は、次のいずれかのオプションを選択します。
グループ ポリシー オブジェクト グループ ポリシー オブジェクト (GPO) を使用して、正しいサーバー値を設定します。
注意
このオプションは自動構成を有効にしませんが、手動構成のプロセスを自動化するため、この方法を使用する場合、自動構成に関連付けられている SRV レコードは必要ありません。
内部ゾーンの照合 外部 DNS ゾーン (たとえば、contoso.com) に一致するゾーンを内部 DNS に作成し、自動構成に使用される Lync Server 2013 プールに対応する DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコードを作成します。 たとえば、ユーザーが pool01.contoso.net に所属していても、 bob@contoso.comとして Lync にサインインする場合は、contoso.com という内部 DNS ゾーンを作成し、その中に、pool01.contoso.com の DNS A と AAAA (IPv6 アドレス指定が使用されている場合) レコードを作成します。
ピンポイント内部ゾーン 内部 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 ドメイン (fabrikam.com など) が含まれている場合は、内部 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>
注意
フロントエンド プールの FQDN は 2 回表示されますが、2 つの異なる IP アドレスが表示されます。 これは、DNS 負荷分散が使用されるためですが、ハードウェア負荷分散を使用する場合、フロントエンド プール エントリは 1 つだけです。 また、フロントエンド プールの FQDN 値は、contoso.com の例と fabrikam.com の例の間で変化しますが、IP アドレスは変わりません。 これは、ユーザーがいずれかの SIP ドメインからサインインし、自動構成に同じフロントエンド プールを使用するためです。
詳細については、の DMTF ブログ記事「Communicator の自動構成と Split-Brain DNS」を参照してください。
注意
各ブログの内容と URL は、将来予告なしに変更されることがあります。
ディザスター リカバリー用のドメイン ネーム システム (DNS) の構成
Lync Server 2013 Web トラフィックをディザスター リカバリーおよびフェールオーバー サイトにリダイレクトするように DNS を構成するには、GeoDNS をサポートする DNS プロバイダーを使用している必要があります。 ディザスター リカバリーをサポートするように Web 用の DNS レコードを設定して、フロントエンド プール全体がダウンした場合でも Web サービスを使用する機能が続行されるようにすることができます。 このディザスター リカバリー機能では、自動検出 (Lyncdiscover URL)、Meet、Dial-In の単純な URL がサポートされています。
GeoDNS プロバイダーでの Web サービスの内部および外部解決のために、追加の DNS ホスト (IPv6 を使用する場合は A および AAAA) レコードを定義して構成します。 次の詳細では、ラウンド ロビン DNS を使用してプロバイダーによってサポートされているペアプール、地理的分散プール、GeoDNS、または Pool1 をプライマリとして使用するように構成されており、通信の損失やハードウェア障害が発生した場合に Pool2 にフェールオーバーすることを前提としています。
| GeoDNS レコード (例) | プール レコード (例) | CNAME レコード (例) | DNS 設定 (オプションを 1 つ選択する) |
|---|---|---|---|
Meet-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
エイリアス Meet.contoso.com を Pool1InternalWebFQDN.contoso.com に指定 エイリアス Meet.contoso.com を Pool2InternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン プライマリを使用し、障害が発生した場合はセカンダリに接続する |
Meet-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
エイリアス Meet.contoso.com を Pool1ExternalWebFQDN.contoso.com に指定 エイリアス Meet.contoso.com を Pool2ExternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン プライマリを使用し、障害が発生した場合はセカンダリに接続する |
Dialin-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
エイリアス Dialin.contoso.com を Pool1InternalWebFQDN.contoso.com に指定 エイリアス Dialin.contoso.com を Pool2InternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン プライマリを使用し、障害が発生した場合はセカンダリに接続する |
Dialin-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
エイリアス Dialin.contoso.com を Pool1ExternalWebFQDN.contoso.com に指定 エイリアス Dialin.contoso.com を Pool2ExternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン プライマリを使用し、障害が発生した場合はセカンダリに接続する |
Lyncdiscoverint-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
エイリアス Lyncdiscoverinternal.contoso.com を Pool1InternalWebFQDN.contoso.com に指定 エイリアス Lyncdiscoverinternal.contoso.com を Pool2InternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン プライマリを使用し、障害が発生した場合はセカンダリに接続する |
Lyncdiscover-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
エイリアス Lyncdiscover.contoso.com を Pool1ExternalWebFQDN.contoso.com に指定 エイリアス Lyncdiscover.contoso.com を Pool2ExternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン プライマリを使用し、障害が発生した場合はセカンダリに接続する |
Scheduler-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
エイリアス Scheduler.contoso.com を Pool1InternalWebFQDN.contoso.com に指定 エイリアス Scheduler.contoso.com を Pool2InternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン プライマリを使用し、障害が発生した場合はセカンダリに接続する |
Scheduler-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
エイリアス Scheduler.contoso.com を Pool1ExternalWebFQDN.contoso.com に指定 エイリアス Scheduler.contoso.com を Pool2ExternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン プライマリを使用し、障害が発生した場合はセカンダリに接続する |
DNS Load Balancing
DNS 負荷分散は通常、アプリケーション レベルで実装されます。 アプリケーション (たとえば、Lync を実行しているクライアント) は、プール完全修飾ドメイン名 (FQDN) のレコード クエリ (IPv6 アドレス指定が使用されている場合) と DNS A から返される IP アドレスのいずれかに接続することで、プール内のサーバーへの接続を試みます。
たとえば、pool01.contoso.com という名前のプールに 3 つのフロントエンド サーバーがある場合、次のことが発生します。
Lync を実行しているクライアントは、pool01.contoso.com の DNS クエリを実行します。 クエリは 3 つの IP アドレスを返し、次のようにキャッシュします (必ずしもこの順序ではありません)。
pool01.contoso.com 192.168.10.90
pool01.contoso.com 192.168.10.91
pool01.contoso.com 192.168.10.92
クライアントは、いずれかの IP アドレスへの伝送制御プロトコル (TCP) 接続の確立を試みます。 失敗した場合、クライアントはキャッシュ内の次の IP アドレスを試行します。
TCP 接続が成功した場合、クライアントは TLS のネゴシエーションを行い、pool01.contoso.com のプライマリ レジストラーに接続します。
クライアントが接続に成功せずにキャッシュされたすべてのエントリを試みると、現時点では Lync Server 2013 を実行しているサーバーが使用できないという通知がユーザーに通知されます。
注意
DNS ベースの負荷分散は、DNS ラウンド ロビン (DNS RR) とは異なります。これは通常、DNS に依存してプール内のサーバーに対応する異なる IP アドレスの順序を提供することで負荷分散を指します。 通常、DNS RR では負荷分散のみが有効になりますが、フェールオーバーは有効になりません。 たとえば、DNS A と AAAA によって返される 1 つの IP アドレス (IPv6 アドレッシングを使用している場合) への接続が失敗した場合、接続は失敗します。 そのため、DNS ラウンド ロビン自体の信頼性は、DNS ベースの負荷分散よりも低くなります。 DNS ラウンド ロビンは、DNS 負荷分散と組み合わせて使用できます。
DNS 負荷分散は、次の目的で使用されます。
サーバー間 SIP をエッジ サーバーに負荷分散する
会議自動応答、応答グループ、コール パークなどのユニファイド コミュニケーション アプリケーション サービス (UCAS) アプリケーションの負荷分散
UCAS アプリケーションへの新しい接続の防止 ("ドレイン" とも呼ばれます)
クライアントとエッジ サーバー間のすべてのクライアント間トラフィックの負荷分散
DNS 負荷分散は、次の場合に使用できません。
- Director またはフロントエンド サーバーへのクライアントからサーバーへの Web トラフィック
DNS 負荷分散とフェデレーション トラフィック:
DNS SRV クエリによって複数の DNS レコードが返される場合、Access Edge サービスは常に、数値の優先順位が最も低く、数値の重みが最も高い DNS SRV レコードを選択します。 インターネット エンジニアリング タスク フォースのドキュメント「サービスの場所を指定するための DNS RR (DNS SRV)」 http://www.ietf.org/rfc/rfc2782.txt では、複数の DNS SRV レコードが定義されている場合は、優先順位が最初に使用され、重みが使用されます。 たとえば、DNS SRV レコード A の重みは 20、優先順位は 40、DNS SRV レコード B の重みは 10、優先順位は 50 です。 優先順位 40 の DNS SRV レコード A が選択されます。 DNS SRV レコードの選択には、次の規則が適用されます。
優先順位は最初に考慮されます。 クライアントは、DNS SRV レコードによって定義されたターゲット ホストに、到達できる最も低い番号の優先順位で接続を試みる必要があります。 同じ優先度のターゲットは、重みフィールドで定義された順序で試行する必要があります。
重みフィールドは、同じ優先順位のエントリの相対的な重みを指定します。 重みが大きい場合は、選択される確率が比例的に高くなります。 DNS 管理者は、実行するサーバーの選択がない場合は、Weight 0 を使用する必要があります。 重みが 0 より大きいレコードがある場合、重み 0 のレコードは選択される可能性が非常に小さいはずです。
優先度と重みが等しい複数の DNS SRV レコードが返された場合、Access Edge サービスは、最初に DNS サーバーから受信した SRV レコードを選択します。