确定 Lync Server 2013 的 DNS 要求

  • 项目

 

上次修改的主题： 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 要求流程图

175782ac-363e-408a-912f-8991bf152970

重要

默认情况下，未加入域的计算机的计算机名是主机名，而不是 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 记录并将其返回到客户端：

  1. lyncdiscoverinternal.<域> A (主机) 内部 Web 服务上的自动发现服务记录

  2. lyncdiscover.<域> A (主机) 外部 Web 服务上的自动发现服务记录

  3. _sipinternaltls._tcp。<域> SRV (服务定位器) 内部 TLS 连接的记录

  4. _sipinternal._tcp。<域> SRV (服务定位器) 记录，仅当允许 TCP) 时才 (执行内部 TCP 连接

  5. _sip._tls。<域> SRV (服务定位器) 外部 TLS 连接的记录

  6. sipinternal.<域> A (主机) 前端池或 Director 的记录，只能在内部网络上解析

  7. Sip。<域> A (主机) 内部网络上前端池或 Director 的记录，或客户端为外部的 Access Edge 服务的域

  8. sipexternal.<域> A (主机) 客户端外部时访问 Edge 服务的记录

Lync Windows 应用商店应用完全更改了该过程，因为它使用两条记录：

  1. lyncdiscoverinternal.<域> A (主机) 内部 Web 服务上的自动发现服务记录

  2. lyncdiscover.<域> A (主机) 外部 Web 服务上的自动发现服务记录

不回退到其他记录类型。

用于较新客户端和较旧客户端的方法的区别在于，自动发现服务将成为定位所有服务的首选方法。

连接成功后，自动发现服务将返回用户主池的所有 Web 服务 URL，包括移动服务 (由 IIS) 、Microsoft Lync Web 应用和 Web 计划程序 URL 中为服务创建的虚拟目录称为 Mcx。 但是，内部 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 区域包含：

    • 如果使用 IPv6 寻址内部 Lync Server 2013 客户端自动配置) 和 SRV 记录，则 DNS A 和 AAAA ( (可选)

    • 如果使用 IPv6 寻址) 或 CNAME 记录自动发现 Lync Server 2013 Web Services (可选) ，DNS A 和 AAAA (

    • 如果使用 IPv6 来寻址前端池名称、Director 或 Director 池名称以及公司网络中运行 Lync Server 2013 的所有内部服务器的) 记录，则 DNS A 和 AAAA (

    • 如果使用 IPv6 寻址每个 Lync Server 2013 的 Edge 内部接口的) 记录，则 DNS A 和 AAAA (， 外围网络中的边缘服务器

    • 外围网络中每台反向代理服务器的内部接口的 DNS A 和 AAAA（如果使用的是 IPv6 寻址）记录（仅对反向代理的管理是可选的）

    • 外围网络中的所有 Lync Server 2013 Edge Server 内部边缘接口都使用内部 DNS 区域解析查询以 contoso.com

    • 所有运行 Lync Server 2013 的服务器以及在公司网络中运行 Lync 2013 的客户端都指向内部 DNS 服务器，用于解析查询以 contoso.com，或者在每个 Edge 服务器上使用 HOSTS 文件并列出 A 和 AAAA (（如果使用 IPv6 寻址下一跃点服务器的) 记录，特别是目录或目录 VIP）。 前端池 VIP 或 Standard Edition 服务器

外部 DNS：

  • 包含名为 contoso.com 且受其管辖的 DNS 区域

  • 外部 contoso.com 区域包含：

    • 如果使用 IPv6 寻址 Lync Server 2013 客户端自动配置) 和 SRV 记录，则 DNS A 和 AAAA ( (可选)

    • 如果使用 IPv6 寻址) 或 CNAME 记录自动发现 Lync Server 2013 Web Services 以用于移动性，则 DNS A 和 AAAA (

    • 如果在外围网络中为每个 Lync Server 2013、Edge Server 或硬件负载均衡器虚拟 (IP) 的 Edge 外部接口使用 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) 记录：

  • 如果用户登录为 bob@contoso.com 以下 SRV 记录将适用于自动配置，因为用户的 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

若要进行比较，如果用户登录为 tim@litwareinc.com 以下 DNS SRV 记录将不适用于自动配置，因为客户端的 SIP 域 (litwareinc.com) 与池所在的域不匹配 (fabrikam.com) ：

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

如果运行 Lync 的客户端需要自动配置，请选择以下选项之一：

  • 组策略对象使用 GPO (组策略对象) 填充正确的服务器值。

    注意

    此选项不会启用自动配置，但可以自动化手动配置的过程，因此，使用这种方法时不需要与自动配置关联的 SRV 记录。

  • 匹配内部区域 在内部 DNS 中创建与外部 DNS 区域匹配的区域 (，例如，如果使用 IPv6 寻址与用于自动配置的 Lync Server 2013 池对应的) 记录，则 contoso.com) 和创建 DNS A 和 AAAA (。 例如，如果用户驻留在 pool01.contoso.net 但登录到 Lync， bob@contoso.com则创建名为 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 域登录的用户使用相同的前端池进行自动配置。

有关详细信息，请参阅 DMTF 博客文章“Communicator Automatic Configuration and Split-Brain DNS”，内容如下 https://go.microsoft.com/fwlink/p/?linkId=200707。

注意

每个博客的内容及其 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) 的客户端，如果) 将 IPv6 寻址用于池完全限定的域名 (FQDN) ，则通过连接到 DNS A 和 AAAA (返回的 IP 地址之一，尝试连接到池中的服务器。

例如，如果名为 pool01.contoso.com 的池中有三个前端服务器，则会发生以下情况：

  • 为 pool01.contoso.com 运行 Lync 查询 DNS 的客户端。 查询返回三个 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 负载均衡不能用于以下各项：

  • 到 Director 或前端服务器的客户端到服务器的 Web 流量

DNS 负载均衡和联合流量：

如果 DNS SRV 查询返回了多个 DNS 记录，则 Access Edge 服务始终选择数值优先级最低且数值权重最高的 DNS SRV 记录。 Internet 工程任务组文档“用于指定服务 (DNS SRV) 位置的 DNS RR” 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 记录。