Compartir a través de

  • Artículo

Determinar los requisitos de DNS

 

Última modificación del tema: 2012-10-16

Use el diagrama de flujo siguiente para determinar los requisitos del Sistema de nombres de dominio (DNS).

Diagrama de flujo para determinar los requisitos de DNS

Diagrama de flujo de DNS para el acceso a usuarios externos

importantImportante:
El nombre que especifique debe ser idéntico al nombre del equipo configurado en el servidor. De manera predeterminada, el nombre de equipo de un equipo que no está unido a un dominio es un nombre corto, en lugar de un nombre de dominio completo (FQDN). Topology Builder utiliza nombres de dominio completos, en vez de nombres breves. Así pues, debe configurar un sufijo de DNS en el nombre del equipo para poder implementarlo como servidor perimetral no incorporado a un dominio. Utilice únicamente caracteres estándar (A–Z, a–z, 0–9 y guiones) cuando asigne los nombres de dominio completo de sus servidores Lync, servidores perimetrales y grupos de servidores. No utilice caracteres Unicode ni de subrayado. Los DNS externos y las entidades de certificación públicas no admiten caracteres que no sean estándar en un nombre de dominio completo (es decir, cuando el FQDN se debe asignar al nombre de sujeto en el certificado). Para obtener más información sobre cómo agregar un sufijo DNS al nombre de un equipo, consulte Configurar registros DNS para admitir servidores perimetrales.

Configuración de DNS de horizonte dividido en Lync Server 2010

Del mismo modo que la traducción de direcciones de red (NAT, Network address translation), el término DNS de horizonte dividido se puede definir de varias formas distintas. En este documento, el término DNS de horizonte dividido significa que la zona DNS de un determinado espacio de nombres es la misma tanto en el DNS interno como en el externo. No obstante, muchos de los registros SRV y registros A de DNS que contiene el DNS interno no se incluirán en el DNS externo, y viceversa. Además, en los casos en que el mismo registro DNS existe tanto en el DNS interno como en el externo (por ejemplo, www.contoso.com), la dirección IP devuelta será distinta, en función de dónde se realice la consulta DNS.

Si va a configurar DNS de horizonte dividido, a continuación se incluye un resumen de los tipos de registros DNS necesarios para cada zona. Para más información, consulte Arquitectura de referencia.

DNS interno:

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

  • La zona contoso.com interna contiene:

    • Registros SRV y A de DNS para la configuración automática de clientes de Microsoft Lync Server 2010 (opcional)

    • Registros A o CNAME de DNS para la detección automática de servicios web de Lync Server.

    • Registros SRV y A de DNS para todos los servidores internos que ejecutan Lync Server 2010 en la red corporativa

    • Registros SRV y A de DNS para la interfaz interna perimetral de cada Lync Server 2010 o servidor perimetral de la red perimetral

    • Registros A de DNS para la interfaz interna de proxy inverso de cada servidor de proxy inverso de la red perimetral

    • Todos los servidores perimetrales de Lync Server 2010 del punto de red a los servidores DNS internos para la resolución de consultas a contoso.com

    • Todos los servidores de Lync Server 2010 y los clientes que ejecuten Lync 2010 en el punto de red corporativo a los servidores DNS internos para la resolución de consultas de contoso.com

DNS externo:

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

  • La zona contoso.com externa contiene:

    • Registros SRV y A de DNS para la configuración automática de clientes de Lync Server 2010 (opcional)

    • Registros A o CNAME de DNS para la detección automática de servicios web de Lync Server.

    • Registros SRV y A de DNS para la interfaz externa perimetral de cada dirección IP virtual (VIP) de Lync Server 2010, servidor perimetral o equilibrador de carga de hardware de la red perimetral

    • Registros A de DNS para la interfaz externa de proxy inverso de cada servidor de proxy inverso de la red perimetral

Cómo localizan servicios los clientes que ejecutan Microsoft Lync 2010

Durante la búsqueda de DNS, de forma paralela se realizan consultas a los registros SRV que se devuelven en el orden siguiente al cliente (si está configurado y disponible):

  1. _sipinternaltls._tcp.<dominio>: para las conexiones TLS internas

  2. _sipinternal._tcp. <dominio> - para conexiones TCP internas (solamente se realiza si el protocolo TCP está permitido)

  3. _sip._tls. <dominio> - para conexiones TLS externas

  4. _sip._tcp. <dominio>: para las conexiones TCP externas (ejecutado solo si TCP está permitido)

Donde <dominio> es el dominio SIP que usan los clientes internos. Las últimas dos consultas son para clientes que se conecten desde fuera de la red interna. A la hora de crear registros SRV, es importante recordar que deben señalar a un registro A de DNS del mismo dominio donde se vaya a crear el registro SRV de DNS. Por ejemplo, si el registro SRV se encuentra en contoso.com, el registro A al que señala no puede encontrarse en fabrikam.com, sino que también debe estar en contoso.com.

La primera vez que se inicia sesión, el cliente que ejecuta Lync intenta conectarse a un grupo de servidores front-end usando los tres registros SRV por orden, independientemente de si se está iniciando sesión desde dentro o desde fuera de la red. Una vez que el cliente que ejecuta Lync realiza una conexión correcta, almacena en caché la entrada DNS y continúa usándola hasta que deja de funcionar. Si el cliente que ejecuta Lync no puede usar el valor almacenado en caché, vuelve a enviar una consulta de registros SRV al DNS y rellena la caché. Por ejemplo, se sigue este proceso si ha iniciado sesión en la red interna durante el día y después se lleva el equipo portátil a casa e inicia sesión de forma externa.

Una vez devuelto el registro SRV, se envía una consulta para obtener el registro A de DNS (mediante el FQDN) del servidor o del grupo de servidores front-end asociado con el registro SRV. Si no se encuentra ningún registro durante la consulta de registros SRV de DNS, el cliente de Lync realiza una búsqueda explícita de sipinternal.<dominio>. Si la búsqueda explícita no devuelve ningún resultado, el cliente de Lync realiza la búsqueda de sip.<dominio>.

Configuración automática sin DNS de horizonte dividido

Si usa DNS de horizonte dividido y un usuario de Lync Server 2010 inicia sesión de forma interna, este puede sacar provecho de la configuración automática, siempre que la zona DNS interna contenga un registro SRV _sipinternaltls._tcp para cada uno de los dominios en uso. No obstante, si no usa DNS de horizonte 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 es debido a que Lync Server 2010 requiere que el URI del SIP del usuario coincida con el dominio del grupo de servidores front-end designado para la configuración automática. Lo mismo sucedía en 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 lstest01@contoso.com, el registro SRV siguiente funcionará para la configuración automática porque el dominio SIP del usuario (contoso.com) 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 lstest01@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

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

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

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

  • Objetos de directiva de grupo   Use los objetos de directiva de grupo (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 registros A de DNS que se correspondan con el grupo de servidores de Lync Server 2010 usado para la configuración automática. Por ejemplo, si un usuario está hospedado en pool01.contoso.net pero inicia sesión en Lync como lstest01@contoso.com, cree una zona DNS interna llamada contoso.com y dentro de esta, cree un registro A de DNS para pool01.contoso.com.

  • Zona interna designada   Si crear una zona entera en el DNS interno no es una opción, puede crear zonas designadas (es decir, dedicadas) que correspondan a los registros SRV que son necesarios para la configuración automática y rellenar dichas zonas mediante dnscmd.exe. Dnscmd.exe es obligatorio 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 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. @ A 192.168.10.91

    Si su entorno contiene un segundo dominio SIP (por ejemplo, fabrikam.com), necesitará los siguientes registros A y 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.fabrikam.com. @ A 192.168.10.91

Nota

El FQDN del grupo de servidores front-end aparece dos veces, pero con dos direcciones IP distintas. Esto se debe a que se usa el equilibrio de carga de DNS, pero si se usara el equilibrio de carga de hardware, solo habría una entrada de grupo de servidores front-end. Asimismo, los valores de FQDN del grupo de servidores front-end cambian entre el ejemplo de contoso.com y el ejemplo de fabrikam.com, pero las direcciones IP permanecen iguales. Esto se debe a que los usuarios que inician sesión desde cualquiera de los dominios SIP, usan el mismo grupo de servidores front-end para la configuración automática.

Para obtener más información, consulte el artículo del blog DMTF "Communicator Automatic Configuration and Split-Brain DNS" en inglés (DNS de horizonte dividido y configuración automática de Communicator) en https://go.microsoft.com/fwlink/?linkid=200707&clcid=0xC0A.

Nota

El contenido de cada blog y de su dirección URL se encuentra sujeto a cambios sin previo aviso.

Cómo localizan los servicios los clientes de dispositivos móviles que ejecutan Lync 2010

Los clientes de dispositivos móviles que ejecutan Lync 2010 usan los registros A o CNAME de DNS para la detección automática a fin de localizar servicios de movilidad. Durante la búsqueda de DNS, se intenta primero una conexión al nombre de dominio completo (FQDN) asociado al registro DNS interno (es decir, lyncdiscoverinternal. <dominiosip>). Si no se puede realizar una conexión a la URL interna, se intenta una conexión al FQDN asociado al registro DNS externo (es decir, lyncdiscover. <dominiosip>). Siempre se da prioridad a la URL interna. Si la conexión a la URL interna es correcta, el cliente usa la red Wi-Fi corporativa. Si la conexión a la URL no es correcta, pero se realiza una conexión a la URL externa correctamente, la solicitud del cliente pasa a través del proxy inverso y se enruta al servidor front-end o al director.

Cuando una conexión es correcta, el servicio Detección automática devuelve todas las URL de servicios web del grupo de servidores principales del usuario, incluidas las URL del servicio de movilidad. Sin embargo, la URL interna del servicio de movilidad y la 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.

tipSugerencia:
Aunque la configuración predeterminada habilita el tráfico del cliente móvil para circular a través del sitio externo, puede modificar la configuración para devolver solamente la URL interna. Con esta configuración, los usuarios pueden usar aplicaciones móviles de Lync en sus dispositivos móviles solo cuando están dentro de la red corporativa. Para admitir esta configuración, debe ejecutar el cmdlet Set-CsMcxConfiguration. También debe configurar las IP virtuales (VIP) internas de los servicios web en los equilibradores de carga de hardware del servidor front-end o del director para la persistencia basada en cookies. Para obtener más detalles sobre los requisitos del equilibrador de carga, vea la sección “Requisitos del equilibrador de carga de hardware para un proxy inverso" en Equilibradores de carga de hardware. Para obtener más detalles sobre el uso de Set-CsMcxConfiguration para restringir el tráfico del cliente móvil a la red interna, vea Instalar los servicios de movilidad y Detección automática.

Nota

Aunque las aplicaciones móviles también pueden conectarse a otros servicios de Lync Server 2010, como el servicio de la libreta de direcciones, las solicitudes web de aplicaciones móviles internas van al FQDN de web interno solamente para el servicio de movilidad. Otras solicitudes de servicios, como las solicitudes de la libreta de direcciones, no requieren esta configuración.

Lync 2010 para dispositivos móviles también admiten la detección manual de servicios. En este caso, cada usuario debe configurar los parámetros del dispositivo móvil con las URL internas y externas completas del servicio Detección automática, incluyendo el protocolo y la ruta de acceso, de la manera siguiente:

  • https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Raíz para acceso externo

  • https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Raíz para acceso interno

El uso de la detección automática, en lugar de la detección manual, es muy recomendable. Sin embargo, el uso de parámetros manuales es útil para solucionar problemas de conectividad de dispositivos móviles. Para obtener más información sobre los registros DNS usados para el servicio Detección automática, vea Requisitos técnicos para la movilidad. Para obtener más detalles sobre la planeación de movilidad, vea Planeación de movilidad.

Equilibrio de carga de DNS

El equilibrio de carga de DNS suele implementarse en el nivel de la aplicación. La aplicación (por ejemplo, un cliente que ejecuta Lync 2010) intenta conectarse a un servidor en un grupo de servidores conectándose a una de las direcciones IP obtenidas a raíz de la consulta A de DNS para el nombre de dominio completo (FQDN) del grupo de servidores.

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

  • Los clientes que ejecutan Lync 2010 envían una consulta al DNS para pool01.contoso.com y obtendrá como resultado tres direcciones IP que almacenará en caché de la forma siguiente (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

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

  • Si la conexión TCP se establece correctamente, el cliente negociará con el TLS para conectarse al servidor front-end.

  • Si el proceso se finaliza sin establecer una conexión correctamente, se notificará al usuario que en ese momento no hay disponible ningún servidor que ejecute Lync Server 2010.

Nota

El equilibrio de carga basado en DNS es distinto al round robin de DNS (DNS RR), que normalmente hace referencia al equilibrio de carga usando el DNS para proporcionar un orden distinto de direcciones IP correspondientes a los servidores de un grupo de servidores. Por lo general, DNS RR solo habilita la distribución de carga, pero no habilita la conmutación por error. Por ejemplo, si no se consigue establecer la conexión con la dirección IP devuelta por la consulta A de DNS, la conexión será errónea. Por tanto, el round robin de DNS por sí solo es menos fiable que el equilibrio de carga basado en DNS. Puede usar el round robin de DNS junto con el equilibrio de carga de DNS.

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

  • Equilibrar la carga de tráfico HTTP y SIP entre servidores

  • Equilibrar la carga de aplicaciones de servicios de aplicaciones de comunicaciones unificadas (UCAS, Unified Communications Application Services), 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 de servidor a cliente entre clientes y servidores perimetrales

El equilibrio de carga de DNS no puede usarse para:

  • Tráfico web de servidor a cliente

Equilibrio de carga de DNS y tráfico federado:

  • Si se devuelven varios registros DNS para una consulta SRV de DNS, el servicio perimetral de acceso siempre selecciona el registro SRV DNS con la prioridad numérica más baja y con el peso numérico más alto. 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.