共用方式為

  • 發行項

判斷 DNS 需求

 

上次修改主題的時間： 2012-10-16

使用下列流程圖來判斷網域名稱系統 (DNS) 需求。

DNS 需求判斷流程圖

外部使用者存取的 DNS 流程圖

important重要事項：
您指定的名稱必須與伺服器上設定的電腦名稱一模一樣。根據預設值，未加入網域的電腦，使用的是簡短的名稱，而不是完整的網域名稱 (FQDN)。拓撲產生器使用 FQDN，而不是簡短名稱。所以，如果電腦要部署成未加入網域的 Edge Server，您必須在電腦名稱設定一個 DNS 尾碼。指派 Lync Server、Edge Server 以及集區的 FQDN 時，請只使用標準字元 (包括 A–Z、a–z、0–9 以及連字號)。請勿使用 Unicode 字元或底線。外部 DNS 和公用 CA (也就是當 FQDN 必須指派至憑證的 SN 時) 通常不支援 FQDN 中的非標準字元。如需在電腦名稱中加上 DNS 尾碼的詳細資料，請參閱＜設定 Edge 支援的 DNS 記錄＞。

使用 Lync Server 2010 設定 Split-Brain DNS

如同網路位址轉譯 (NAT)，split-brain DNS 一詞有數種不同的定義。在本文中，split-brain DNS 一詞是指在內部 DNS 與外部 DNS 中，某個命名空間的 DNS 區域都相同。不過，內部 DNS 包含的許多 DNS SRV 和 A 記錄不會包含在外部 DNS 中，反之亦然。此外，如果相同的 DNS 記錄 (例如，www.contoso.com) 同時存在於內部與外部 DNS，傳回的 IP 位址會依執行 DNS 查詢的位置而不同。

如果您設定 split-brain 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、Edge Server 的 Edge 內部介面適用的 DNS A 和 SRV 記錄

    • 周邊網路中每個反向 Proxy 伺服器的反向 Proxy 內部介面適用的 DNS A 記錄

    • 周邊網路中的所有 Lync Server 2010 Edge Server 都指向內部 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、Edge Server 或硬體負載平衡器虛擬 IP (VIP) 的 Edge 外部介面適用的 DNS A 和 SRV 記錄

    • 周邊網路中每個反向 Proxy 伺服器的反向 Proxy 外部介面適用的 DNS A 記錄

執行 Microsoft Lync 2010 的用戶端如何尋找服務

在 DNS 查閱期間，會以平行的方式查詢 SRV 記錄，並依照下列順序傳回給用戶端 (如果已設定而且可以使用)：

  1. _sipinternaltls._tcp.<網域>：用於內部 TLS 連線

  2. _sipinternal._tcp. <網域> - 用於內部 TCP 連線 (只有在允許使用 TCP 時才會執行)

  3. _sip._tls. <網域> - 用於外部 TLS 連線

  4. _sip._tcp. <domain> - 適用於外部 TCP 連線 (僅於允許 TCP 時執行)

其中 <網域> 是您內部用戶端所使用的 SIP 網域。最後兩個查詢適用於從您內部網路外面連線的用戶端。建立 SRV 記錄時，請切記，這些記錄必須指向 DNS SRV 記錄建立所在相同網域中的 DNS A 記錄。例如，如果 SRV 記錄位在 contoso.com 中，則其指向的 A 記錄不可在 fabrikam.com 中，而必須在 contoso.com 中。

您第一次登入時，不論您是從您網路內部或外部登入，執行 Lync 的用戶端都會依序使用這三筆 SRV 記錄，嘗試連線至前端集區。執行 Lync 的用戶端在成功建立連線之後，便會快取 DNS 項目，並且持續使用該快取版本直到失敗為止。如果執行 Lync 的用戶端無法使用快取值，則會再次向 DNS 查詢 SRV 記錄來重新填入快取。例如，如果您在白天登入內部網路，然後將筆記型電腦帶回家，並從外部登入，則會遵循此程序進行。

在傳回 SRV 記錄之後，即會執行查詢來找出與 SRV 記錄相關聯的伺服器 (或前端集區) 的 DNS A 記錄 (依 FQDN)。如果在 DNS SRV 查詢期間找不到記錄，Lync 用戶端就會明確查閱 sipinternal.<網域>。如果明確查閱沒有結果，Lync 用戶端就會查閱 sip.<網域>。

不透過 Split-Brain DNS 執行的自動設定

如果您使用 split-brain DNS，則只要內部 DNS 區域針對每個使用中 SIP 網域分別包含一筆 _sipinternaltls._tcp SRV 記錄，從內部登入的 Lync Server 2010 使用者就可以享受到自動設定功能。不過，如果您不使用 split-brain DNS，則除非實作本節稍後說明的其中一個因應措施，否則執行 Lync 之用戶端的內部自動設定就無法運作。這是因為 Lync Server 2010 要求使用者的 SIP URI 必須符合針對自動設定所指定之前端集區的網域。舊版 Communicator 亦同。

例如，如果您有兩個使用中的 SIP 網域，則需要下列 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 登入，則下列 DNS SRV 記錄可讓第二個 SIP 網域的自動設定運作。

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

為了比較，如果使用者以 lstest01@litwareinc.com 登入，則下列 DNS SRV 記錄會讓自動設定無法運作，因為用戶端的 SIP 網域 (litwareinc.com) 不符合集區所在的網域 (fabrikam.com)：

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

如果執行 Lync 的用戶端需要自動設定，請選取下列其中一個選項：

  • 群組原則物件   使用群組原則物件 (GPO) 來填寫正確的伺服器值。

    note附註：
    此選項不會啟用自動設定，但會自動化手動組態的程序，因此，如果採用此方法，則不需要與自動設定相關聯的 SRV 記錄。

  • 相符的內部區域   在內部 DNS 中建立符合外部 DNS 區域 (例如，contoso.com) 的區域，並建立與自動設定所使用的 Lync Server 2010 集區對應的 DNS A 記錄。例如，如果使用者位於 pool01.contoso.net，但以 lstest01@contoso.com 登入 Lync，請建立名為 contoso.com 的內部 DNS 區域，然後在裡面再建立 pool01.contoso.com 的 DNS A 記錄。

  • 精確的內部區域   如果無法在內部 DNS 中建立整個區域，您可以建立與自動設定所需的 SRV 記錄對應的精確 (亦即專用) 區域，並使用 dnscmd.exe 來填寫這些區域。Dnscmd.exe 是必要的，因為 DNS 使用者介面不支援建立精確區域。例如，如果 SIP 網域是 contoso.com，且您有一個名為 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. @ A 192.168.10.91

    如果環境包含第二個 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.fabrikam.com. @ A 192.168.10.91
note附註：
前端集區 FQDN 出現兩次，但各有不同的 IP 位址。這是因為使用 DNS 負載平衡的關係，如果使用硬體負載平衡，則只會有單一前端集區項目。另外，雖然前端集區 FQDN 值在 contoso.com 範例和 fabrikam.com 範例會有不同，但 IP 位址維持不變。這是因為從這兩個 SIP 網域之一登入的使用者都是以相同的前端集區執行自動設定。

如需詳細資訊，請參閱 DMTF 部落格文章＜Communicator 自動設定和 Split-Brain DNS＞，網址為 https://go.microsoft.com/fwlink/?linkid=200707&clcid=0x404。

note附註：
每個部落格的內容及其 URL 如有變更恕不另行通知。

執行 Lync 2010 的行動裝置用戶端如何尋找服務

執行 Lync 2010 的行動裝置用戶端使用自動探索 DNS A 或 CNAME 記錄尋找行動服務。在 DNS 查閱期間，會先嘗試建立與內部 DNS 記錄相關聯之完整網域名稱 (FQDN) (亦即 lyncdiscoverinternal. <SIP 網域>) 的連線。如果無法建立內部 URL 的連線，則會嘗試建立與外部 DNS 記錄相關聯之 FQDN (亦即 lyncdiscover. <SIP 網域>) 的連線。一律優先使用內部 URL。如果內部 URL 的連線成功，用戶端會使用公司 Wi-Fi 網路。如果內部 URL 的連線失敗，但外部 URL 的連線成功，則用戶端要求會通過反向 Proxy，並路由傳送至前端伺服器或 Director。

連線成功時，自動探索服務會傳回使用者主集區的所有 Web 服務 URL，包括 Mobility Service URL。但是，內部 Mobility Service URL 和外部 Mobility Service URL 都會與外部 Web 服務 FQDN 建立關聯。因此，不論行動裝置在網路內部或外部，裝置一律會透過反向 Proxy 從外部連線至 Mobility Service。

tip提示：
雖然預設設定允許行動用戶端流量通過外部網站，但是您可以修改設定僅傳回內部 URL。透過此設定，使用者只有在公司網路內部時，才可以在其行動裝置上使用 Lync 行動應用程式。若要支援此設定，您必須執行 Set-CsMcxConfiguration Cmdlet。您也必須在前端伺服器和 Director 硬體負載平衡器上，針對 Cookie 型持續性設定內部 Web 服務虛擬 IP (VIP)。如需硬體負載平衡器需求的詳細資訊，請參閱＜硬體負載平衡器＞中的＜反向 Proxy 的硬體負載平衡器需求＞一節。如需使用 Set-CsMcxConfiguration 將行動用戶端流量限定在內部網路的詳細資訊，請參閱＜安裝 Mobility Service 與自動探索服務＞。
note附註：
雖然行動應用程式也可以連線至其他 Lync Server 2010 服務 (例如通訊錄服務)，但是只有 Mobility Service 的內部行動應用程式 Web 要求才會前往外部 Web FQDN。其他服務要求 (例如通訊錄要求) 不需要此設定。

適用於行動裝置的 Lync 2010 也支援手動探索服務。在此情況下，每位使用者必須使用完整的內部和外部自動探索服務 URI (包括通訊協定和路徑) 來設定行動裝置設定，如下所示：

  • https://<外部集區 FQDN>/Autodiscover/autodiscoverservice.svc/Root，以進行外部存取

  • https://<內部集區 FQDN>/AutoDiscover/AutoDiscover.svc/Root，以進行內部存取

強烈建議使用自動探索，而不是手動探索。不過，使用手動設定有助於對行動裝置連線問題進行疑難排解。如需用於自動探索服務之 DNS 記錄的詳細資訊，請參閱＜行動的技術需求＞。如需規劃行動性的詳細資訊，請參閱＜行動規劃＞。

DNS 負載平衡

DNS 負載平衡通常是在應用程式層級實作。應用程式 (例如，執行 Lync 2010 的用戶端) 在進行集區完整網域名稱 (FQDN) 的 DNS A 查詢後，會嘗試以所得到的其中一個 IP 位址連線至集區中的某部伺服器。

例如，如果名為 pool01.contoso.com 的集區中有三個前端伺服器，則會發生下列情形：

  • 執行 Lync 2010 的用戶端向 DNS 查詢 pool01.contoso.com，得到如下三個 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 來連線至前端伺服器。

  • 如果最後無法成功連線，則向使用者通知目前沒有執行 Lync Server 2010 的伺服器可用。

note附註：
DNS 負載平衡不同於 DNS 循環配置資源 (DNS RR)，後者通常是指依賴 DNS 提供不同順序的 IP 位址 (與集區中的伺服器對應) 來進行的負載平衡。DNS RR 通常只允許負載分散，而不允許容錯移轉。例如，如果連線至由 DNS A 查詢所傳回的一個 IP 位址失敗，則連線即告失敗。因此，DNS 循環配置資源本身比 DNS 負載平衡更不可靠。您可以搭配使用 DNS 循環配置資源和 DNS 負載平衡。

DNS 負載平衡適合用於：

  • 伺服器對伺服器的 SIP 和 HTTP 流量的負載平衡

  • 整合通訊應用程式服務 (UCAS) 應用程式 (例如會議自動語音應答、回應群組和通話駐留) 的負載平衡

  • 防止對 UCAS 應用程式建立新連線 (又稱為「清空」)

  • 用戶端與 Edge Server 之間所有用戶端對伺服器的流量的負載平衡

DNS 負載平衡不適合用於：

  • 用戶端對伺服器的網頁流量

DNS 負載平衡和同盟流量：

  • 如果多筆 DNS 記錄傳回到 DNS SRV 查詢，Access Edge Service 一定會挑選數字優先順序最低且數字加權最高的 DNS SRV 記錄。如果傳回多筆優先順序和加權相等的 DNS SRV 記錄，Access Edge Service 會挑選最先從 DNS 伺服器返回的 SRV 記錄。