Determinar los requisitos DNS para Lync Server 2013

Cómo localizan los servicios los clientes de Lync

Microsoft Lync 2010, Lync 2013 y Lync Mobile son similares en la forma en que el cliente encuentra y obtiene acceso a servicios en Lync Server 2013. La excepción notable es la aplicación lync de la Tienda Windows que usa un proceso de ubicación de servicio diferente. En esta sección se describen dos escenarios en los que los clientes localizan servicios: el primero es el método tradicional que usa una serie de SRV y registros de host A y el segundo usa únicamente los registros del servicio de detección automática. Las actualizaciones acumulativas para los clientes de escritorio cambian el proceso de ubicación DNS de Lync Server 2010 Para todos los clientes, el proceso de consulta DNS continúa hasta que se devuelve una consulta correcta o se agota la lista de posibles registros DNS y se devuelve el error final al cliente.

Para todos los clientes excepto la aplicación de la Tienda Windows de Lync Durante la búsqueda DNS, los registros SRV se consultan y devuelven al cliente en el siguiente orden:

1. lyncdiscoverinternal.< registro A (host) del dominio> para el servicio Detección automática en los servicios web internos

2. lyncdiscover.< registro A (host) del dominio> para el servicio Detección automática en los servicios web externos

3. _sipinternaltls._tcp.< registro SRV de dominio> (localizador de servicios) para conexiones TLS internas

4. _sipinternal._tcp.< registro SRV de dominio> (localizador de servicios) para conexiones TCP internas (realizadas solo si se permite TCP)

5. _sip._tls.< registro SRV (localizador de servicios) de dominio> para conexiones TLS externas

6. sipinternal.< registro A (host) del dominio> para el grupo de servidores front-end o director, que solo se puede resolver en la red interna

7. Sip.<> registro A (host) del dominio para el grupo de servidores front-end o director en la red interna, o el servicio perimetral de acceso cuando el cliente es externo

8. sipexternal.< registro A (host) del dominio> para el servicio perimetral de acceso cuando el cliente es externo

La aplicación de la Tienda Windows de Lync cambia el proceso por completo porque usa dos registros:

1. lyncdiscoverinternal.< registro A (host) del dominio> para el servicio Detección automática en los servicios web internos

2. lyncdiscover.< registro A (host) del dominio> para el servicio Detección automática en los servicios web externos

No hay reserva para los otros tipos de registros.

La diferencia entre los métodos usados para los clientes más recientes en comparación con los clientes más antiguos es que el servicio de detección automática se convierte en el método preferido para localizar todos los servicios.

Cuando una conexión se realiza correctamente, el servicio de detección automática devuelve todas las direcciones URL de servicios web del grupo de servidores principal del usuario, incluido el Servicio de movilidad (conocido como Mcx por el directorio virtual creado para el servicio en IIS), las direcciones URL de Microsoft Lync Web App y programador web. Pero, la dirección URL interna del servicio de movilidad y la dirección URL externa del servicio de movilidad se asocian al FQDN externo de los servicios web. Por lo tanto, independientemente de si un dispositivo móvil es interno o externo a la red, el dispositivo siempre se conecta al servicio de movilidad de forma externa a través del proxy inverso.

Si se ha instalado la Novedades acumulativa para Lync Server 2013: febrero de 2013, el servicio de detección automática también devuelve referencias a Internal/UCWA, External/UCWA y UCWA. Estas entradas hacen referencia al componente web de la API web de comunicaciones unificadas (UCWA). Actualmente solo se usa la entrada de UCWA y proporciona una referencia a una URL para el componente web. Los clientes móviles de Lync 2013 usan UCWA en lugar del Servicio de movilidad de Mcx que usan los clientes de Lync 2010 Mobile.

Los dispositivos móviles admiten la detección manual de servicios. En este caso, cada usuario necesita configurar los parámetros del dispositivo móvil con los URI internos y externos completos del servicio de detección automática, incluso el protocolo y la ruta de acceso, de la manera siguiente:

• <https:// ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root para acceso externo

• <https:// IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root para acceso interno

Recomendamos que use la detección automática, en lugar de la detección manual. Pero, la configuración manual puede ser útil para solucionar problemas de conectividad de los dispositivos móviles.

Configurar Split-Brain DNS con Lync Server

El término DNS de horizonte dividido se conoce con varios nombres, por ejemplo, DNS dividido o DNS de partición de red. Sencillamente describe una configuración de DNS en la que existen dos zonas de DNS con el mismo espacio de nombre, pero una zona de DNS procesa solo las solicitudes internas y la otra solo las externas. Pero, muchos de los registros SRV y los registros A de DNS que contiene el DNS interno no se incluirán en el DNS externo, y viceversa. En los casos en los que exista el mismo registro DNS tanto en el DNS interno como en el externo (por ejemplo, www.contoso.com), la dirección IP devuelta será diferente en función de dónde se inició la consulta (interna o externa).

Aquí se utilizará el término DNS de horizonte dividido.

Si va a configurar DNS de horizonte dividido, en la siguiente área interna y externa encontrará un resumen de los tipos de registros de DNS necesarios para cada zona. Para obtener más información, vea Escenarios para el acceso de usuarios externos en Lync Server 2013.

DNS interno:

• Contiene una zona de DNS llamada contoso.com sobre la que es autoritativo

• La zona contoso.com interna contiene:

  • DNS A y AAAA (si usa direcciones IPv6) y registros SRV para la configuración automática del cliente interno de Lync Server 2013 (opcional)

  • DNS A y AAAA (si usa direcciones IPv6) o registros CNAME para la detección automática de servicios web de Lync Server 2013 (opcional)

  • Registros DNS A y AAAA (si usa el direccionamiento IPv6) para el nombre del grupo de servidores front-end, el nombre del grupo de directores o directores y todos los servidores internos que ejecutan Lync Server 2013 en la red corporativa

  • Registros A y AAAA de DNS (si usa direcciones IPv6) para la interfaz interna perimetral de cada Lync Server 2013, servidor perimetral en la red perimetral

  • Registros A y AAAA (si está usando direccionamiento IPv6) de DNS para la interfaz interna de cada servidor proxy inverso en la red perimetral (opcional para la administración del proxy inverso)

  • Todas las interfaces perimetrales internas de Lync Server 2013 en la red perimetral usan la zona DNS interna para resolver consultas a contoso.com

  • Todos los servidores que ejecutan Lync Server 2013 y los clientes que ejecutan Lync 2013 en la red corporativa apuntan a los servidores DNS internos para resolver las consultas a contoso.com, o el uso del archivo HOSTS en cada servidor perimetral y muestran los registros A y AAAA (si usa el direccionamiento IPv6) para el servidor del próximo salto, específicamente el Director VIP, Front End Pool VIP o servidor Standard Edition

DNS externo:

• Contiene una zona de DNS llamada contoso.com sobre la que es autoritativo

• La zona contoso.com externa contiene:

  • DNS A y AAAA (si usa el direccionamiento IPv6) y registros SRV para la configuración automática del cliente de Lync Server 2013 (opcional)

  • Dns A y AAAA (si usa direcciones IPv6) o registros CNAME para la detección automática de servicios web de Lync Server 2013 para su uso con movilidad

  • DNS A y AAAA (si usa direcciones IPv6) y registros SRV para la interfaz externa perimetral de cada Lync Server 2013, servidor perimetral o IP virtual (VIP) del equilibrador de carga de hardware en la red perimetral

  • Registros A y AAAA (si está usando direccionamiento IPv6) de DNS para la interfaz externa del servidor proxy inverso o VIP para un grupo de servidores proxy inversos en la red perimetral

Configuración automática sin DNS de horizonte dividido

Con DNS de cerebro dividido, un usuario de Lync Server 2013 que inicia sesión internamente puede aprovechar la configuración automática si la zona DNS interna contiene un registro SRV de _sipinternaltls._tcp para cada dominio SIP en uso. Sin embargo, si no usa DNS dividido, la configuración automática interna de los clientes que ejecutan Lync no funcionará a menos que se implemente una de las soluciones alternativas descritas más adelante en esta sección. Esto se debe a que Lync Server 2013 requiere que el URI de SIP del usuario coincida con el dominio del grupo de servidores front-end designado para la configuración automática. Este era también el caso de las versiones anteriores de Communicator.

Por ejemplo, si tiene dos dominios SIP en uso, se necesitarán los registros de servicio DNS (SRV) siguientes:

• Si un usuario inicia sesión como bob@contoso.com el siguiente registro SRV funcionará para la configuración automática porque el dominio SIP (contoso.com) del usuario coincide con el dominio del grupo de servidores front-end de configuración automática:

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

• Si un usuario inicia sesión como alice@fabrikam.com el siguiente registro SRV de DNS funcionará para la configuración automática del segundo dominio SIP.

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

Para comparación, si un usuario inicia sesión como tim@litwareinc.com el siguiente registro SRV de DNS no funcionará para la configuración automática, porque el dominio SIP (litwareinc.com) del cliente no coincide con el dominio en el que se encuentra el grupo (fabrikam.com):

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

Si se requiere configuración automática para los clientes que ejecutan Lync, seleccione una de las siguientes opciones:

• directiva de grupo objetos Use directiva de grupo objetos (GPO) para rellenar los valores de servidor correctos.

  Nota

  Esta opción no habilita la configuración automática, pero automatiza el proceso de configuración manual, de modo que si se usa este enfoque, no se requerirán los registros SRV asociados con la configuración automática.

• Zona interna coincidente Cree una zona en el DNS interno que coincida con la zona DNS externa (por ejemplo, contoso.com) y cree los registros A y AAAA de DNS (si usa el direccionamiento IPv6) correspondientes al grupo de Lync Server 2013 usado para la configuración automática. Por ejemplo, si un usuario está alojado en pool01.contoso.net pero inicia sesión en Lync como bob@contoso.com, cree una zona DNS interna denominada contoso.com y dentro de ella, cree un registro DNS A y AAAA (si se usa el direccionamiento IPv6) para pool01.contoso.com.

• Zona interna de puntos de chincheta Si va a crear una zona completa en el DNS interno no es una opción, puede crear zonas de pin-point (es decir, dedicadas) que se correspondan con los registros SRV necesarios para la configuración automática y rellenar esas zonas con dnscmd.exe. Dnscmd.exe es necesario porque la interfaz de usuario de DNS no admite la creación de zonas designadas. Por ejemplo, si el dominio SIP es contoso.com y dispone de un grupo de servidores front-end llamado pool01 que contiene dos servidores front-end, necesitará los siguientes registros A y las siguientes zonas designadas en el DNS interno:

  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>
  

  Si su entorno contiene un segundo dominio SIP (por ejemplo, fabrikam.com), necesitará los siguientes registros A y las siguientes zonas designadas en el DNS interno:

  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>
  

Para obtener más información, consulte el artículo del blog de DMTF, "Communicator Automatic Configuration and Split-Brain DNS", en https://go.microsoft.com/fwlink/p/?linkId=200707.

Configuración del sistema de nombres de dominio (DNS) para la recuperación ante desastres

Para configurar dns para redirigir el tráfico web de Lync Server 2013 a los sitios de recuperación ante desastres y conmutación por error, debe usar un proveedor de DNS compatible con GeoDNS. Puede configurar los registros DNS para la Web para que admitan la recuperación ante desastres, de modo que las características que usan los servicios web continúen incluso si un grupo de servidores front-end completos desaparece. Esta característica de recuperación ante desastres admite direcciones URL sencillas de detección automática (URL de Lyncdiscover), de reunión y de acceso telefónico.

Los registros de host DNS adicionales (A y AAAA si se usa IPv6) se definen y se configuran para la resolución interna y externa de servicios web en su proveedor de GeoDNS. En la información siguiente se presupone que su proveedor admite grupos emparejados, geográficamente dispersos, y GeoDNS con round robin de DNS o configurados para usar Pool1 como grupo principal y conmutar por error a Pool2 en caso de pérdida de comunicaciones o error de hardware.

Equilibrio de carga de DNS

El equilibrio de carga de DNS suele implementarse en la aplicación. La aplicación (por ejemplo, un cliente que ejecuta Lync) intenta conectarse a un servidor de un grupo mediante la conexión a una de las direcciones IP devueltas de la consulta de registros DNS A y AAAA (si se usa la dirección IPv6) para el nombre de dominio completo (FQDN) del grupo.

Por ejemplo, si hay tres servidores front-end en un grupo denominado pool01.contoso.com, pasará lo siguiente:

• Clientes que ejecutan DNS de consulta de Lync para pool01.contoso.com. La consulta devuelve tres direcciones IP y las almacena en caché de la siguiente manera (no necesariamente en este orden):

  pool01.contoso.com 192.168.10.90

  pool01.contoso.com 192.168.10.91

  pool01.contoso.com 192.168.10.92

• Luego, el cliente intenta establecer una conexión del Protocolo de control de transmisión (TCP) con una de las direcciones IP. Si no funciona, lo intenta con la siguiente dirección IP almacenada en caché.

• Si la conexión TCP se establece correctamente, el cliente negocia con el TLS para conectarse con el registrador principal en pool01.contoso.com.

• Si el cliente prueba todas las entradas almacenadas en caché sin una conexión correcta, se notifica al usuario que no hay servidores que ejecuten Lync Server 2013 están disponibles en este momento.

El equilibrio de carga de DNS se usa para lo siguiente:

• Equilibrar la carga SIP de servidor a servidor con los servidores perimetrales

• Equilibrar la carga de aplicaciones de servicios de aplicaciones de comunicaciones unificadas (UCAS) como Operador automático de conferencia, Grupo de respuesta y Estacionamiento de llamadas

• Impedir el establecimiento de nuevas conexiones con aplicaciones UCAS (proceso también conocido como "purga").

• Equilibrar la carga de todo el tráfico desde el servidor al cliente entre clientes y servidores perimetrales

El equilibrio de carga de DNS no puede usarse para:

• Tráfico web de cliente a servidor al director o a los servidores front-end

Equilibrio de carga de DNS y tráfico federado:

Si una consulta SRV de DNS devuelve varios registros de DNS, el servicio perimetral de acceso siempre selecciona el registro SRV de DNS con la prioridad numérica más baja y con el peso numérico más alto. El documento del grupo de tareas de ingeniería de Internet "Un RR de DNS para especificar la ubicación de los servicios (DNS SRV)" http://www.ietf.org/rfc/rfc2782.txt especifica que, si hay varios registros SRV dns definidos, primero se usa la prioridad y, a continuación, el peso. Por ejemplo, el registro A de SRV de DNS tiene un peso de 20 y una prioridad de 40, y el registro B de SRV de DNS tiene un peso de 10 y una prioridad de 50. Se seleccionará el registro A de SRV de DNS con una prioridad de 40. Las siguientes reglas se aplican a la selección de registros SRV de DNS:

• La prioridad se considera primero. Un cliente TIENE QUE intentar contactar con el host de destino definido por el registro SRV de DNS con la menor prioridad numerada que pueda alcanzar. Los destinos con la misma prioridad NECESITAN intentarse siguiendo el orden definido por el campo de peso.

• El campo de peso especifica un peso relativo para las entradas que tienen la misma prioridad. Es PRECISO que a los pesos más grandes se les otorgue una probabilidad proporcionalmente mayor para ser seleccionados. Los administradores de DNS TIENEN QUE usar el peso 0 cuando no hay ninguna selección de servidor que hacer. Cuando existen registros con pesos superiores a 0, los registros con peso 0 necesitan tener una oportunidad muy pequeña de ser elegidos.

Si se devuelven varios registros SRV de DNS con la misma prioridad y el mismo peso, el servicio perimetral de acceso seleccionará el registro SRV que se haya obtenido en primer lugar del servidor DNS.