Was this page helpful?
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Determining DNS Requirements


Topic Last Modified: 2012-10-16

Use the following flow chart to determine Domain Name System (DNS) requirements.

Determining DNS Requirements Flow Chart

DNS Flowchart for External User Access
The name you specify must be identical to the computer name configured on the server. By default the computer name of a computer that is not joined to a domain is a short name, not a fully qualified domain name (FQDN). Topology Builder uses FQDNs, not short names. So, you must configure a DNS suffix on the name of the computer to be deployed as an Edge Server that is not joined to a domain. Use only standard characters (including A–Z, a–z, 0–9, and hyphens) when assigning FQDNs of your Lync Servers, Edge Servers, and pools. Do not use Unicode characters or underscores. Nonstandard characters in an FQDN are often not supported by external DNS and public CAs (that is, when the FQDN must be assigned to the SN in the certificate). For details about adding a DNS suffix to a computer name, see Configure DNS Records for Edge Support.

Like network address translation (NAT), the term split-brain DNS is defined several different ways. For this document, the term split-brain DNS means that the DNS zone for a given namespace is the same in the internal DNS as it is in the external DNS. However, many of the DNS SRV and A records contained in the internal DNS will not be contained in the external DNS, and the reverse is also true. And in cases where the same DNS record exists in both the internal and external DNS (for example, www.contoso.com), the IP address returned will be different, depending on where the DNS query is made.

If you are configuring split-brain DNS, the following internal and external zone contain a summary of the types of DNS records required in each zone. For details, see Reference Architecture.

Internal DNS:

  • Contains a DNS zone called contoso.com for which it is authoritative

  • The internal contoso.com zone contains:

    • DNS A and SRV records for Microsoft Lync Server 2010 client autoconfiguration (optional)

    • DNS A or CNAME records for automatic discovery of Lync Server Web Services.

    • DNS A and SRV records for all internal servers running Lync Server 2010 in the corporate network

    • DNS A and SRV records for the Edge internal interface of each Lync Server 2010, Edge Server in the perimeter network

    • DNS A records for the reverse proxy internal interface of each reverse proxy server in the perimeter network

    • All Lync Server 2010 Edge Servers in the perimeter network point to the internal DNS servers for resolving queries to contoso.com

    • All servers running Lync Server 2010 and clients running Lync 2010 in the corporate network point to the internal DNS servers for resolving queries to contoso.com

External DNS:

  • Contains a DNS zone called contoso.com for which it is authoritative

  • The external contoso.com zone contains:

    • DNS A and SRV records for Lync Server 2010 client autoconfiguration (optional)

    • DNS A or CNAME records for automatic discovery of Lync Server Web Services.

    • DNS A and SRV records for the Edge external interface of each Lync Server 2010, Edge Server or hardware load balancer virtual IP (VIP) in the perimeter network

    • DNS A records for the reverse proxy external interface of each reverse proxy server in the perimeter network

During DNS lookup, SRV records are queried in parallel and returned in the following order to the client (if configured and available):

  1. _sipinternaltls._tcp.<domain> - for internal TLS connections

  2. _sipinternal._tcp. <domain> - for internal TCP connections (performed only if TCP is allowed)

  3. _sip._tls. <domain> - for external TLS connections

  4. _sip._tcp. <domain> - for external TCP connections (performed only if TCP is allowed)

Where <domain> is the SIP domain used by your internal clients. The last two queries are for clients that are connecting from outside your internal network. When creating SRV records, it is important to remember that they must point to a DNS A record in the same domain in which the DNS SRV record is created. For example, if the SRV record is in contoso.com, the A record it points to cannot be in fabrikam.com, it has to also be in contoso.com.

The first time you sign in, the client running Lync attempts to connect to a Front End pool using each of the three SRV records in order, regardless of whether you are signing in from inside our outside your network. After the client running Lync makes a successful connection, it caches the DNS entry and continues to use it until it is no longer successful. If the client running Lync cannot use the cached value, it queries DNS for the SRV records again and repopulates its cache. For example, this process is followed if you have signed in to the internal network during the day and then take your laptop home and sign in externally.

After the SRV record is returned, a query is performed for the DNS A record (by FQDN) of the server or Front End pool associated with the SRV record. If no records are found during the DNS SRV query, the Lync client performs an explicit lookup of sipinternal.<domain>. If the explicit lookup does not produce results, the Lync client performs a lookup for sip.<domain>.

If you use split-brain DNS, a Lync Server 2010 user that signs in internally can take advantage of automatic configuration if the internal DNS zone contains a _sipinternaltls._tcp SRV record for each SIP domain in use. However, if you do not use split-brain DNS, internal automatic configuration of clients running Lync will not work unless one of the workarounds described in later in this section is implemented. This is because Lync Server 2010 requires the user’s SIP URI to match the domain of the Front End pool designated for automatic configuration. This was also the case with earlier versions of Communicator.

For example, if you have two SIP domains in use, the following DNS service (SRV) records would be required:

  • If a user signs in as lstest01@contoso.com the following SRV record will work for automatic configuration because the user’s SIP domain (contoso.com) matches the domain of automatic configuration Front End pool):

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

  • If a user signs in as lstest01@fabrikam.com the following DNS SRV record will work for automatic configuration of the second SIP domain.

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

For comparison, if a user signs in as lstest01@litwareinc.com the following DNS SRV record will not work for automatic configuration, because the client’s SIP domain (litwareinc.com) does not match the domain that the pool is in (fabrikam.com):

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

If automatic configuration is required for clients running Lync, select one of the following options:

  • Group Policy Objects   Use Group Policy objects (GPOs) to populate the correct server values.

    This option does not enable automatic configuration, but it does automate the process of manual configuration, so if this approach is used, the SRV records associated with automatic configuration are not required.
  • Matching internal zone   Create a zone in the internal DNS that matches the external DNS zone (for example, contoso.com) and create DNS A records corresponding to the Lync Server 2010 pool used for automatic configuration. For example, if a user is homed on pool01.contoso.net but signs into Lync as lstest01@contoso.com, create an internal DNS zone called contoso.com and inside it, create a DNS A record for pool01.contoso.com.

  • Pin-point internal zone   If creating an entire zone in the internal DNS is not an option, you can create pin-point (that is, dedicated) zones that correspond to the SRV records that are required for automatic configuration, and populate those zones using dnscmd.exe. Dnscmd.exe is required because the DNS user interface does not support creation of pin-point zones. For example, if the SIP domain is contoso.com and you have a Front End pool called pool01 that contains two Front End Servers, you need the following pin-point zones and A records in your internal DNS:

    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
    dnscmd . /recordadd pool01.contoso.com. @ A

    If your environment contains a second SIP domain (for example, fabrikam.com), you need the following pin-point zones and A records in your internal DNS:

    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
    dnscmd . /recordadd pool01.fabrikam.com. @ A
The Front End pool FQDN appears twice, but with two different IP addresses. This is because DNS load balancing is used, but if hardware load balancing is used, there would be only a single Front End pool entry. Also, the Front End pool FQDN values change between the contoso.com example and the fabrikam.com example, but the IP addresses remain the same. This is because users signing in from either SIP domain, use the same Front End pool for automatic configuration.

For details, see the DMTF blog article, "Communicator Automatic Configuration and Split-Brain DNS," at http://go.microsoft.com/fwlink/p/?LinkId=200707.

The content of each blog and its URL are subject to change without notice.

Mobile device clients running Lync 2010 use autodiscover DNS A or CNAME records to locate mobility services. During the DNS lookup, first a connection is attempted to the fully qualified domain name (FQDN) that is associated with the internal DNS record (that is, lyncdiscoverinternal. <sipdomain>). If a connection cannot be made to the internal URL, a connection is attempted to the FQDN that is associated with the external DNS record (that is, lyncdiscover. <sipdomain>). Priority is always given to the internal URL. If a connection to the internal URL is successful, the client uses the corporate Wi-Fi network. If the connection to the internal URL is not successful, but a connection to the external URL is successful, the client request passes through the reverse proxy and is routed to the Front End Server or Director.

When a connection is successful, the Autodiscover Service returns all the Web Services URLs for the user's home pool, including the Mobility Service URLs. However, both the internal Mobility Service URL and the external Mobility Service URL are associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to the network, the device always connects to the Mobility Service externally through the reverse proxy.

Although the default configuration enables mobile client traffic to go through the external site, you can modify settings to return only the internal URL. With this configuration, users can use Lync mobile applications on their mobile devices only when they are inside the corporate network. To support this configuration, you need to run the Set-CsMcxConfiguration cmdlet. You also need to configure the internal Web Services virtual IPs (VIPs) on your Front End Server and Director hardware load balancers for cookie-based persistence. For details about hardware load balancer requirements, see the “Hardware Load Balancer Requirements for Reverse Proxy” section in Hardware Load Balancers. For details about using Set-CsMcxConfiguration to restrict mobile client traffic to the internal network, see Installing the Mobility and Autodiscover Services.
Although mobile applications can also connect to other Lync Server 2010 services, such as Address Book Service, internal mobile application web requests go to the external web FQDN only for the Mobility Service. Other service requests, such as Address Book requests, do not require this configuration.

Lync 2010 for mobile devices also supports manual discovery of services. In this case, each user must configure the mobile device settings with the full internal and external Autodiscover Service URIs, including the protocol and path, as follows:

  • https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root for external access

  • https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root for internal access

Using automatic discovery, rather than manual discovery, is highly recommended. However, using manual settings is useful for troubleshooting mobile device connectivity issues.For details about the DNS records used for the Autodiscover Service, see Technical Requirements for Mobility. For details about planning for mobility, see Planning for Mobility.

DNS load balancing is typically implemented at the application level. The application (for example, a client running Lync 2010), tries to connect to a server in a pool by connecting to one of the IP addresses resulting from the DNS A query for the pool fully qualified domain name (FQDN).

For example, if there are three front end servers in a pool named pool01.contoso.com, the following will happen:

  • Clients running Lync 2010 query DNS for pool01.contoso.com and get back three IP addresses and cache them as follows (not necessarily in this order):




  • Then, the client attempts to establish a Transmission Control Protocol (TCP) connection to one of the IP addresses. If that fails, the client tries the next IP address in the cache.

  • If the TCP connection succeeds, the client negotiates TLS to connect to the Front End Server.

  • If it gets to the end without a successful connection, the user is notified that no servers running Lync Server 2010 are available at the moment.

DNS-based load balancing is different from DNS round robin (DNS RR) which typically refers to load balancing by relying on DNS to provide a different order of IP addresses corresponding to the servers in a pool. Typically DNS RR only enables load distribution, but does not enable failover. For example, if the connection to the one IP address returned by the DNS A query fails, the connection fails. Therefore, DNS round robin by itself is less reliable than DNS-based load balancing. You can use DNS round robin in conjunction with DNS load balancing.

DNS load balancing is used for the following:

  • Load balancing server-to-server SIP and HTTP traffic

  • Load balancing Unified Communications Application Services (UCAS) applications such as Conferencing Auto Attendant, Response Group, and Call Park

  • Preventing new connections to UCAS applications (also known as "draining")

  • Load balancing all client-to-server traffic between clients and Edge Servers

DNS load balancing cannot be used for the following:

  • Client-to-server web traffic

DNS load balancing and federated traffic:

  • If multiple DNS records are returned to a DNS SRV query, the Access Edge service always picks the DNS SRV record with the lowest numeric priority and highest numeric weight. If multiple DNS SRV records with equal priority and weight are returned, the Access Edge service will pick the SRV record that came back first from the DNS server.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft