上次修改的主题: 2013-02-22
使用以下流程图确定域名系统 (DNS) 要求。 Lync Server 2013 累积汇报更改:2013 年 2 月的更改将记录在适用位置。
重要
Microsoft Lync Server 2013 支持使用 IPv6 寻址。 要使用 IPv6 地址,还必须提供 IPv6 DNS 支持和配置 DNS 主机 AAAA(称为“4 A”)记录。 在使用 IPv4 和 IPv6 的部署中,最好为 IPv4 配置和维护 A 记录,并为 IPv6 配置主机 AAAA。 即使您的部署已完全转换为 IPv6,当外部用户仍在使用 IPv4 时,也仍需要 IPv4 DNS 主机记录。
确定 DNS 要求流程图
重要
默认情况下,未加入域的计算机的计算机名称是主机名,而不是 FQDN) (完全限定的域名。 拓扑生成器使用 FQDN,而不是主机名。 因此,您必须在要部署为域外边缘服务器的计算机的名称上配置 DNS 后缀。 分配您的 Lync Server、边缘服务器和池的 FQDN 时,只使用标准字符(包括 A–Z、a–z、0–9 和连字符)。 不要使用 Unicode 字符或下划线。 外部 DNS 和公共 CA(即,在 FQDN 必须分配给证书中的 SN 时)通常不支持在 FQDN 中使用非标准字符。 有关其他详细信息,请参阅 为 Lync Server 2013 配置 DNS 主机记录
Lync 客户端如何查找服务
Microsoft Lync 2010、Lync 2013 和 Lync Mobile 在客户端在 Lync Server 2013 中查找和访问服务的方式类似。 显著例外是使用不同服务位置进程的 Lync Windows 应用商店应用。 本节详细介绍客户端定位服务的两种方案,第一种为传统方法,使用一系列 SRV 和 A 主机记录,第二种只使用自动发现服务记录。 桌面客户端的累积更新更改了 Lync Server 2010 中的 DNS 位置进程 对于所有客户端,DNS 查询过程会一直持续到返回成功的查询或可能 DNS 记录的列表已用完,最后一个错误将返回到客户端。
对于除 Lync Windows 应用商店应用程序 之外 的所有客户端,在 DNS 查找期间,SRV 记录将按以下顺序查询并返回到客户端:
lyncdiscoverinternal。<域> 内部 Web 服务上自动发现服务的 (主机) 记录
lyncdiscover。<域> (主机) 外部 Web 服务上的自动发现服务的记录
_sipinternaltls._tcp。<域> SRV (服务定位符) 内部 TLS 连接的记录
_sipinternal._tcp。<域> SRV (服务定位符) 记录的内部 TCP 连接 (仅在允许 TCP 的情况下执行)
_sip._tls。<域> SRV (服务定位符) 外部 TLS 连接的记录
sipinternal。<域> 前端池或控制器的 (主机) 记录,只能在内部网络上解析
啜。<域> 当客户端位于外部时, (主机) 前端池或控制器的记录,或者访问边缘服务
sipexternal。<域> 当客户端位于外部时, (主机) Access Edge 服务的记录
Lync Windows 应用商店应用完全更改了进程,因为它使用两条记录:
lyncdiscoverinternal。<域> 内部 Web 服务上自动发现服务的 (主机) 记录
lyncdiscover。<域> (主机) 外部 Web 服务上的自动发现服务的记录
不回退到其他记录类型。
用于较新客户端和较旧客户端的方法的区别在于,自动发现服务将成为定位所有服务的首选方法。
连接成功后,自动发现服务将返回用户主池的所有 Web 服务 URL,包括 IIS) 中为该服务创建的虚拟目录 (移动服务 (称为 Mcx,Microsoft Lync Web App 和 Web 计划程序 URL。 但是,内部 Mobility Service URL 和外部 Mobility Service URL 都与外部 Web 服务 FQDN 关联。 因此,不管移动设备是在网络内部还是外部,该设备都始终从外部通过反向代理连接到 Mobility Service。
如果已安装 Lync Server 2013 的累积汇报:2013 年 2 月,则自动发现服务还会返回对 Internal/UCWA、External/UCWA 和 UCWA 的引用。 这些条目是指统一通信 Web API (UCWA) Web 组件。 目前,只使用条目 UCWA,它提供对该 Web 组件 URL 的引用。 UCWA 由 Lync 2013 移动客户端使用,而不是 Lync 2010 移动客户端使用的 Mcx 移动服务。
注意
创建 SRV 记录时,请务必记住,这些记录必须指向在其中创建了 DNS SRV 记录的同一域中的 DNS A 和 AAAA(如果您使用的是 IPv6 寻址)记录。 例如,如果 SRV 记录位于 contoso.com 中,则 A 和 AAAA (如果使用 IPv6 寻址) 记录,则它指向 fabrikam.com。
提示
默认配置是使所有移动客户端流量通过外部网站。 您可以修改设置,以便仅返回内部 URL(如果这更符合您的需求)。 在此配置下,仅当用户位于企业网络内部时才能在其移动设备上使用 Lync 移动应用程序。 若要定义此配置,需要使用 Set-CsMcxConfiguration cmdlet。
注意
尽管移动应用程序还可以连接到其他 Lync Server 2013 服务(如通讯簿服务),但内部移动应用程序 Web 请求仅针对移动服务转到外部 Web FQDN。 其他服务请求(如通讯簿请求)不需要此配置。
移动设备支持手动发现服务。 在此情况下,每个用户必须使用整个内部和外部自动发现服务 URI(包括协议和路径)配置移动设备设置,如下所示:
<https:// ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root 进行外部访问
<https:// IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root 进行内部访问
建议使用自动发现而非手动发现。 但是,手动设置对解决移动设备连接问题很有用。
使用 Lync Server 配置 Split-Brain DNS
拆分式 DNS 以名称编号得名,例如,拆分 DNS 或水平拆分 DNS。 它仅仅描述其中具有相同命名空间的两个 DNS 区域(其中一个 DNS 区域仅为内部请求提供服务,而另一个 DNS 区域仅为外部请求提供服务)的 DNS 配置。 但是,内部 DNS 所包含的许多 DNS SRV 和 A 记录不包含在外部 DNS 中,反之亦然。 例如,如果内部和外部 DNS (中存在相同的 DNS 记录, www.contoso.com
) ,则返回的 IP 地址将取决于启动查询 (内部或外部) 的位置。
重要
当前,移动性(或者更具体讲,LyncDiscover 和 LyncDiscoverInternal DNS 记录)不支持拆分式 DNS。 必须在外部 DNS 服务器上定义 LyncDiscover,在内部 DNS 服务器上定义 LyncDiscoverInternal。
出于这些主题的目的,将使用术语“拆分式 DNS”。
如果要配置拆分式 DNS,以下内部和外部区域包含每个区域所需的 DNS 记录类型的摘要。 有关详细信息,请参阅 Lync Server 2013 中的外部用户访问方案。
内部 DNS:
包含名为 contoso.com 且受其管辖的 DNS 区域
内部 contoso.com 区域包含:
如果对内部 Lync Server 2013 客户端自动配置使用 IPv6 寻址) 和 SRV 记录,则 DNS A 和 AAAA ( (可选)
如果使用 IPv6 寻址 () 或 CNAME 记录自动发现 Lync Server 2013 Web Services (可选)
如果对前端池名称、控制器或控制器池名称以及公司网络中运行 Lync Server 2013 的所有内部服务器使用 IPv6 寻址) 记录,则 DNS A 和 AAAA (
如果对外围网络中每个 Lync Server 2013(边缘服务器)的边缘内部接口使用 IPv6 寻址) 记录,则 DNS A 和 AAAA (
外围网络中每台反向代理服务器的内部接口的 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 客户端自动配置使用 IPv6 寻址) 和 SRV 记录,则 DNS A 和 AAAA ( (可选)
如果使用 IPv6 寻址) 或 CNAME 记录自动发现 Lync Server 2013 Web 服务以用于移动性,则 DNS A 和 AAAA (
如果对外围网络中每个 Lync Server 2013、边缘服务器或硬件负载均衡器虚拟 IP (VIP) 使用 IPv6 寻址) 和 SRV 记录,则 DNS A 和 AAAA (
外围网络中反向代理服务器的外部接口的 DNS A 和 AAAA(如果使用的是 IPv6 寻址)记录或反向代理服务器池的 VIP
没有拆分式 DNS 时的自动配置
使用拆分式 DNS,如果内部 DNS 区域包含每个 SIP 域的 _sipinternaltls._tcp SRV 记录,则内部登录的 Lync Server 2013 用户可以利用自动配置。 但是,如果不使用拆分脑 DNS,则运行 Lync 的客户端的内部自动配置将不起作用,除非实现本节后面所述的解决方法之一。 这是因为 Lync Server 2013 要求用户的 SIP URI 与为自动配置指定的前端池的域匹配。 早期版本的 Communicator 也是如此。
例如,如果正在使用两个 SIP 域,则需要以下 DNS 服务 (SRV) 记录:
如果用户以以下 SRV 记录身份 bob@contoso.com 登录,则会自动配置,因为用户的 SIP 域 (contoso.com) 与自动配置的域匹配,前端池) :
_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com
如果用户以以下 DNS SRV 记录身份 alice@fabrikam.com 登录,则适用于第二个 SIP 域的自动配置。
_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
相比之下,如果用户以以下 DNS SRV 记录登录 tim@litwareinc.com ,则无法自动配置,因为客户端的 SIP 域 (litwareinc.com) 与池 (fabrikam.com) 中的域不匹配:
_sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
如果运行 Lync 的客户端需要自动配置,请选择以下选项之一:
组策略对象 使用组策略对象 (GPO) 填充正确的服务器值。
注意
此选项不会启用自动配置,但可以自动化手动配置的过程,因此,使用这种方法时不需要与自动配置关联的 SRV 记录。
匹配的内部区域 例如,如果使用的是 IPv6 寻址) 与用于自动配置的 Lync Server 2013 池对应的记录, (请在内部 DNS 中创建与外部 DNS 区域匹配的区域,contoso.com) 并创建 DNS A 和 AAAA (。 例如,如果用户位于 pool01.contoso.net 但以 身份 bob@contoso.com登录到 Lync,则创建名为 contoso.com 的内部 DNS 区域,并在其中创建 DNS A 和 AAAA (如果使用 IPv6 寻址) 记录 pool01.contoso.com。
固定点内部区域 如果不是在内部 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. @ AAAA <IPv6 address> dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91 dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
如果环境中包含第二个 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 出现两次,但两次的 IP 地址不同。 这是因为使用了 DNS 负载平衡,但如果使用硬件负载平衡,则只有一个前端池条目。 并且,前端池 FQDN 值因 contoso.com 示例和 fabrikam.com 示例的不同而变化,但 IP 地址保持不变。 这是因为从任一 SIP 域登录的用户使用同一前端池进行自动配置。
有关详细信息,请参阅上的 https://go.microsoft.com/fwlink/p/?linkId=200707DMTF 博客文章“Communicator 自动配置和 Split-Brain DNS”。
注意
每个博客的内容及其 URL 如有更改,恕不另行通知。
为灾难恢复配置域名系统 (DNS)
若要配置 DNS 以将 Lync Server 2013 Web 流量重定向到灾难恢复和故障转移站点,必须使用支持 GeoDNS 的 DNS 提供程序。 可以设置 Web 的 DNS 记录以支持灾难恢复,以便即使整个前端池出现故障,使用 Web 服务的功能也能继续。 此灾难恢复功能支持自动发现 (Lyncdiscover URL)、会议和拨入式简单 URL。
您可以在 GeoDNS 提供程序上为 Web 服务的内部和外部解决方案定义和配置其他 DNS 主机(如果使用的是 IPv6 地址,则为 A 和 AAAA)记录。 以下详细信息假定池已配对,地理位置分散,且 GeoDNS 支持的提供程序使用循环 DNS 或被配置为使用 Pool1 作为主池,并且在发生通信丢失或硬件失败时故障转移到 Pool2。
GeoDNS 记录 (示例) | 池记录 (示例) | CNAME 记录 (示例) | DNS 设置(选择一个选项) |
---|---|---|---|
Meet-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Pool1InternalWebFQDN.contoso.com 的 Meet.contoso.com 别名 Pool2InternalWebFQDN.contoso.com 的 Meet.contoso.com 别名 |
在池之间启用循环 使用主数据库,如果失败,则连接到辅助数据库 |
Meet-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Pool1ExternalWebFQDN.contoso.com 的 Meet.contoso.com 别名 Pool2ExternalWebFQDN.contoso.com 的 Meet.contoso.com 别名 |
在池之间启用循环 使用主数据库,如果失败,则连接到辅助数据库 |
Dialin-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Pool1InternalWebFQDN.contoso.com 的 Dialin.contoso.com 别名 Pool2InternalWebFQDN.contoso.com 的 Dialin.contoso.com 别名 |
在池之间启用循环 使用主数据库,如果失败,则连接到辅助数据库 |
Dialin-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Pool1ExternalWebFQDN.contoso.com 的 Dialin.contoso.com 别名 Pool2ExternalWebFQDN.contoso.com 的 Dialin.contoso.com 别名 |
在池之间启用循环 使用主数据库,如果失败,则连接到辅助数据库 |
Lyncdiscoverint-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Pool1InternalWebFQDN.contoso.com 的 Lyncdiscoverinternal.contoso.com 别名 Pool2InternalWebFQDN.contoso.com 的 Lyncdiscoverinternal.contoso.com 别名 |
在池之间启用循环 使用主数据库,如果失败,则连接到辅助数据库 |
Lyncdiscover-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Pool1ExternalWebFQDN.contoso.com 的 Lyncdiscover.contoso.com 别名 Pool2ExternalWebFQDN.contoso.com 的 Lyncdiscover.contoso.com 别名 |
在池之间启用循环 使用主数据库,如果失败,则连接到辅助数据库 |
Scheduler-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Pool1InternalWebFQDN.contoso.com 的 Scheduler.contoso.com 别名 Pool2InternalWebFQDN.contoso.com 的 Scheduler.contoso.com 别名 |
在池之间启用循环 使用主数据库,如果失败,则连接到辅助数据库 |
Scheduler-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Pool1ExternalWebFQDN.contoso.com 的 Scheduler.contoso.com 别名 Pool2ExternalWebFQDN.contoso.com 的 Scheduler.contoso.com 别名 |
在池之间启用循环 使用主数据库,如果失败,则连接到辅助数据库 |
DNS Load Balancing
DNS 负载均衡通常在应用程序级别实现。 应用程序 (例如,运行 Lync) 的客户端尝试通过连接到从 DNS A 和 AAAA (返回的 IP 地址之一来尝试连接到池中的服务器,前提是使用 IPv6 寻址) 记录查询来查询池的完全限定域名 (FQDN) 。
例如,如果名为 pool01.contoso.com 的池中有三台前端服务器,则会发生以下情况:
运行 Lync 的客户端查询 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
客户端尝试建立传输控制协议 (TCP) 连接到其中一个 IP 地址。 如果失败,客户端将尝试缓存中的下一个 IP 地址。
如果 TCP 连接成功,则客户端与 TLS 协商连接到 pool01.contoso.com 上的主注册器。
如果客户端在没有成功连接的情况下尝试所有缓存条目,则通知用户目前没有运行 Lync Server 2013 的服务器可用。
注意
基于 DNS 的负载均衡不同于 DNS 轮循机制 (DNS RR) 通常指负载均衡,它依赖于 DNS 来提供与池中的服务器相对应的不同顺序的 IP 地址。 通常,DNS RR 仅启用负载分发,但不启用故障转移。 例如,如果使用 IPv6 寻址) 查询,则与 DNS A 和 AAAA 返回的一个 IP 地址的连接 (失败,则连接将失败。 因此,DNS 轮循机制本身不如基于 DNS 的负载均衡可靠。 可以将 DNS 轮循机制与 DNS 负载均衡结合使用。
DNS 负载均衡用于以下各项:
将服务器到服务器 SIP 负载均衡到边缘服务器
统一通信应用程序服务 (UCAS) 应用程序(例如会议自动助理、响应组和呼叫寄存)进行负载均衡
阻止与 UCAS 应用程序的新连接 (也称为“清空”)
对客户端和边缘服务器之间的所有客户端到服务器流量进行负载均衡
DNS 负载均衡不能用于以下各项:
- 到控制器或前端服务器的客户端到服务器的 Web 流量
DNS 负载均衡和联合流量:
如果 DNS SRV 查询返回了多个 DNS 记录,则 Access Edge 服务始终选取具有最低数值优先级和最高数值权重的 DNS SRV 记录。 Internet 工程任务组文档“用于指定服务位置的 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 管理员应使用权重 0。 如果存在权重大于 0 的记录,则权重为 0 的记录的选择机会应很小。
如果返回多个优先级和权重相等的 DNS SRV 记录,则访问边缘服务将选择先从 DNS 服务器收到的 SRV 记录。